Jürgen, What I understand you are saying is that the jars provided in the SDK are not part of the SDK project, but are part of some other project outside of 'api'? Regardless, they must have a version number associated with them, no?
A maven repository forces you to have version information associated with the jars that are made available, so unless I'm not understanding what you are saying, this shouldn't be an issue. As I have stated before, maven is slowly but surely taking the java development community by storm (btw, I am in no way associated with the Maven project). Besides this, it would make it easier and clearer for java developers to write OOo applications, which generally facilitates more development and could only be of benefit to the OOo community. Thanks, Mike --- Jürgen Schmidt <[EMAIL PROTECTED]> wrote: > 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] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
