I wouldn't mind looking into this.  I'm sure it's something I can handle.

(In reply to comment #1)
> I wouldn't mind looking into this.  I'm sure it's something I can handle.

If you would like to work on it, please assign that bug to yourself. In this way we know that you a re working on it and you can put here question, progress and what not.

(In reply to comment #0)
> Java artifacts should be accessibla through standard maven repositories, i.
> e. jenkins-ci maven repository

I have little knowledge of Maven, so am not sure what it means for the public URE jars available via the LO SDK to be accessible via Maven.

But do note that those jars are not designed to work in isolation from a complete URE installation.  (For example, for some functionality they expect native libraries located at specific relative paths next to themselves, where those native libraries expect further files at specific relative paths next to themselves; or in the future they might rely on binary UNOIDL type information files at specific relative paths next to themselves, etc.)

(In reply to comment #3)
> But do note that those jars are not designed to work in isolation from a
> complete URE installation. 

I've been thinking about that, and it does raise the question of the benefit of having a maven entry for just a few jars.  I guess it's more of a development and compile time benefit, even if execution or debugging is pointless with just those.  Does Maven allow for passing additional flags to the JVM, where the LO installation can be configured?  The biggest benefit would be seen with Jenkins, where LO installations are not necessary, but the UNO jars are needed for the build.  

Can maven be used to specify a local installation path?  Maybe that is an alternative...

(In reply to comment #3)
> (In reply to comment #0)
> > Java artifacts should be accessibla through standard maven repositories, i.
> > e. jenkins-ci maven repository
> 
> I have little knowledge of Maven, so am not sure what it means for the
> public URE jars available via the LO SDK to be accessible via Maven.

Differentiate between two different use cases: compilation, i. e. creation of binaries optionally combined with unit/functional/smoke tests and real usage/production.

Check this:
https://github.com/davido/gerrit-buildbot-plugin/blob/master/pom.xml#L100

to create gerrit-plugin you don't need gerrit.
All you need is java & maven installed on your machine and this line in your pom.xml:

    <dependency>
      <groupId>com.google.gerrit</groupId>
      <artifactId>gerrit-${Gerrit-ApiType}-api</artifactId>
      <version>${Gerrit-ApiVersion}</version>
      <scope>provided</scope>
    </dependency>

that all.

see it here in action on this jenkins instance:
https://ci.idaia.de/job/gerrit-buildbot/131/console

Note three facts here: 

1. there is nothing installed on that machine besides Java & Maven
2. Source tree include *no* gerrit binary artifacts at all.
3. to switch to different Version to gerrit you change one line: 

<Gerrit-ApiVersion>2.6-SNAPSHOT</Gerrit-ApiVersion>

And the dependency above does the magic for you.
The only requirement is that on some maven repository it can find that binary artifact.

To translate it to LO it would mean, to define a couple of modules

    <dependency>
      <groupId>org.libreoffice</groupId>
      <artifactId>libreoffice-odk-{juh|jurt|ridl|unoil|...}</artifactId>
      <version>4.1</version>
    </dependency>

And upload the artifacts to some maven repository (for each release version)

Then you can take something like that:

http://sourceforge.net/projects/lopdfconverter/

and migrate it to maven tool chain and compile it on clean machine with two dependencies installed:
java & maven and nothing else, and that for all LO releases (for which of course maven artifacts can be found and fetched from some maven repo).

http://repo.jenkins-ci.org/webapp/home.html

Another Maven hosting service for open source projects: https://oss.sonatype.org/.
Here you can find step for step guide how to set it all up:

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
This NEW Message was generated on: 2015-02-19