Stephan Bergmann wrote:
Mike Traum wrote:

Stephan,
Maven (a top level Apache project - http://maven.apache.org/ ) is a
next generation java build system, which takes ant and makes it much
more feature rich. It has nothing to do with runtime - just building.


In my opinion, it will eventually replace ant. Most of the Apache Jakarta (java) projects are moving towards using maven instead of ant. Struts and many other high profile projects are also moving towards it. To see only some of the projects that have been made available through a maven repository, look here: http://www.ibiblio.org/maven/ .

So, it comes down to this: the whole sdk is not relevant to build a
java client - only juh.jar, jurt.jar, ridl.jar, unoil.jar, and the
loader classes, which I have called loader.jar. If you make these
available through a maven repository, someone building a project with
maven can just add those dependencies to their maven project (xml
file) and they can be automatically downloaded and added to the
classpath when java compiles. It makes it MUCH easier to do team
development or for someone who is not familiar with a project to
build  it. It all becomes automatic, without the need to locate and
download all of the jar's, setup properties files pointing to them,
etc.

Additionally, it would be very easy (and I would likely do it because
I basically have all of the code for it) to make a maven plugin which
would deal with adding the Loader classes to an executable jar and
generating the proper Manifest, all pretty much transparently to the
end user (developer).

The reason I don't want to create the repository myself is exactly
what you pointed out - OOo controls api releases and it would be
prudent for OOo to take this on. Maven repositories all do have
versioning, though. So, whenever you release a new sdk, you add the
new version of the jar's to the repository. A developer using maven
states what version of the dependencies (the OOo jar's, in this case)
they want their project to be built with.

Finally, for the people still using ant, is makes it easier on them
as well. It's becoming more and more popular to automatically
download dependencies through ant. Maven repositories are simply a
structured directory available over http, so this would allow a
developer using ant to automatically download compile-time
dependencies.

Hope that clarifies,
Mike


Mike,

Thanks for this additional information. This appears to be an SDK issue, so maybe someone from the SDK can comment (personally, I'm rather indifferent on this subject, now that I understand it).

-Stephan

The SDK provides no API jars, it is more an extension to an existing office installation and uses the jars from exactly this office. I don't like the idea to have somewhere in the web some UNO APIs and nobody really knows to which office version they belong to. I don't want to maintain this.


Juergen


--- Stephan Bergmann <[EMAIL PROTECTED]> wrote:


Mike Traum wrote:

As suggested, I'm putting this up here again because it went
unanswered.


Frankly, I have no idea what maven is and how it could be useful
for us (and http://maven.apache.org/about/whatismaven.html does not really


given me more of a clue, and I am too lazy to check out your
project to find out how you use it  ;)  ).

Hence, I do not know how much the following relates to this: I am currently working on ideas to improve the Java UNO runtime in such
a way that one can get rid of CLASSPATH and still have Java UNO
components that bring with them their own (Java classes representing) UNO
types. This probably means that there will be one small additional JAR
through which all all of Java UNO (including components) is loaded. At
runtime, an application will thus only have to access this one JAR. (However, at compile time, all the current JARs have to be available, and it
looks to me that what you are doing with maven is directed to compile time,
right?)


In case you feel the need to set something up for maven and just
want to go ahead: I would like to strongly discourage you from taking any deliverables from OOo (i.e., some JARs) and making them available somewhere else---those deliverables will be outdated quickly, and
it can become a nightmare if people use that external, outdated stuff,
have problems with it, and come here at OOo to complain about it...


-Stephan


Thanks,
Mike

--- Mike Traum <[EMAIL PROTECTED]> wrote:


I was wondering if it would be possible for you to start making


the

api jars available through a maven repository, either your own,


or

ibiblio. This would make it MUCH easier to develop a java client
app,
as a plugin could easily be developed to create the jar (and I
would
probably do this right after they arrive in a repo, as I


basically

already have the code for this in my project).

The maven repo could also get used by developers who use ant,


where

it is becoming increasingly more common to use the ant:get task


to

retrieve build dependencies.

The only change, as I can see, would be that you would want the
Bootstrap in a jar as well.

If you're interested in what this looks like using maven, see the
CVS
for my http://oogalleryimport.sourceforge.net project. It would


be

much simpler, though, if we could get a repo going because I


would

then rip out all of that code in maven.xml which help's add the
Bootstrap to my app and create a plugin.

Thanks,
mike


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to