Jason van Zyl <[EMAIL PROTECTED]> writes: >On Wed, 2002-07-17 at 12:19, Henning P. Schmiedehausen wrote: >> Jason van Zyl <[EMAIL PROTECTED]> writes: >> >> Hi, >> >> ><dependency> >> > <id>jaf</id> >> > <version>1.0.2</version> >> > <jar>activation-1.0.2.jar</version> >> ></dependency> >> >> >And if the jar is renamed to jaf-1.0.2.jar then you don't need the <jar> >> >entry. The id is the unique identifier which will eventually be used to >> >look up information about the dependency: the url or the description if >> >you want that included on your project's page of listed dependencies. >> >> Ok, I can live with that. So let's call it jaf-1.0.2.jar >> >> What I don't like is this: >> >> >Again, I think this is required: >> >> ><dependency> >> > <id>jaf</id> >> > <version>1.0.2</version> >> > <jar>activation-1.0.2.jar</version> >> ></dependency> >> >> -1
>The <jar> is a general override to deal with exceptional cases. I can >live with putting the full name of the JAR in there for the exceptional >cases. >> We have the version information twice. This is unnecessary. Either we >> split the <id> from the jar name or we find a better solution. >> >> >> <dependency> >> >> <id>mail</id> >> >> <version>1.2</version> >> >> <jar>mail.jar</jar> >> >> <url>http://java.sun.com/products/javamail/</url> >> >> </dependency> >> >> >I've been using id = javamail, though to follow the pattern used by the >> >other projects we could use jma for Java Mail API. >> >> I'm not too happy with arbitrary renaming of jars (as I told you >> before). Those jars come from defined providers such as Sun who >> almost surely won't accept advice or even rules from us (well, >> actually I'd say that Sun is one of the few that will listen to the >> Jakarta community, but there are lots and lots of other projects out >> there). >> >> When people adapt to the Jakarta framework and develop stuff, they >> will suddently have a "jaf-1.0.2.jar", a "activation.jar" and a >> "activation-1.0.1.jar" as requirement because various projects supply >> this. And then let's get fun with "loader constraint violated" and >> friends. >I am fine with the rule to never rename a jar, we will just have to poke >the repo when there is no version information. We can decide to take the >JAR as it comes or fix it completely. Actually, I do understand what maven is trying to do. The idea of a shared database, while appealing, will be a maintenance nightmare, once the people who conceived the idea, moved on to other projects and stop maintaining it. And there will be the case of proprietary jars which simply can't be put into the "shared repository offered by maven". I have some jars which I will not put on the Net. At the moment, I have a local repository which all our projects use. You can't poke a repo for these jars. At least not the global maven repo. And you will again have the case of the commons-lang disaster where one developer updates a jar on the global repo with an incompatible one and suddently not just one or two but dozens of projects no longer compile. Nightmare city. :-) You will need an 'institution' (most of the time: one developer) handing out the id's. You will (yes, you definitely will, like it or not), clashes with id's which must be sorted out. Especially when legacy projects are moved onto Maven. >> I'm happy with Jakarta projects to embrace a certain style. I'm >> unhappy with Jakarta (or especially maven), pushing a "style" or >> "naming scheme" onto 3rd party developers. I'm sure, lots of people >> who never have used maven before, have "activation.jar" or "mail.jar" >> in their classpath. It might even have come with their IDE. >I have no problems pushing style as it's the only was the gigantic >morass of trying to find/build anything will be solved. I disagree with >just about everyone on this. :-) [...] >You don't understand how the shared information mechanism will work. I >said shared project database, not go poking around the entire net for >short descriptions. That would be ridiculous. At one point, I must transfer this database onto my development system. This must happen either from a central repository (which must be actively maintained or is useless) or from the various project sites which are maintained by the project people themselves. There must be verification that my local information is still valid. If I can control when this happens, fine. >> And many of the jars we require don't even have a project.xml nor will >> the authors probably ever be using maven to build. Who will provide >> project.xml descriptions for these? >Again, you don't understand. The JARs that will be available via Maven >will all have project.xml files like we have in the descriptor >repository. We are trying to clean them up in order to offer them to >their respective projects. A lot of work has been done on this front >from the start it's just not publicly discussed because we don't have a >working version of the share info mechanism. Sounds cool. Will the project.xml be actually _in_ the jars? Or will maven just provide a reference for the jars on a repository site? What if you get the following dependency graph: project -+--- depends_on ---- 111.jar --- depends_on --- aaa-1.0.jar | +--- depends_on ---- 222.jar --- depends_on --- aaa-2.0.jar ( aaa-1.0.jar == xerces-j-1.4.4.jar aaa-2.0.jar == xerces-j-2.0.2.jar ) or (even worse) project -+--- depends_on ---- 111.jar --- depends_on --- aaa.jar | +--- depends_on ---- 222.jar --- depends_on --- bbb.jar where bbb conflicts with aaa. (e.g. different JCS providers). I unfortunately doubt that you can solve these things automatically or even satisfying for all projects. >> Why should having a short description in the dependency hurt? You >> readily agreed to duplicate the (much more important) version >> information in the dependencies but consider <desc>Java Activation >> Framework from SUN</desc> too much? >Those are not even vaguely similiar, poor analogy. The dependency >version being required twice is for exceptional situations, it is not Maybe I'm not looking for a "end all, solve all" solution but simply a way to "pack" an application with jars. Give an application a way to specify a (two? three?) repository where the user can pull the jars needed for that application and be done with it. I'm feel vagely uncomfortable with a huge mechanism pulling jars and resolving dependencies. I still ask myself, why every single compile and build-run must check, whether there is a new version of maven is available to upgrade the project.xml descriptor (in b4). Compile time actually went up with maven. Comfort went up with maven, too (finally unified build.xml! No more build.xml with b5! Java Heaven. :-) ) But nevertheless, some things I did regulary with ant, I can't do with maven (yet?) [1][2][3]. So I might strive for a 'smaller solution' first. >necessary in most cases and hopefully it will happen almost never in the >future. The <jar> element is a catchall that will work to provide what >maven needs to build the classpath. The use of <jar> should eventually >be phased out. The short description on the other hand is maintained in >entirely another descriptor under the domain of another project and if >replicated across n project it would not only be a waste but when it was >changed in the actual project that is a dependency you have n projects >that don't have the description as published by the project. Hm. Looking at the commons-lang case, I'm not happy that, if any developer around the world decides to change a method name in one of the 20+ jars I depend on, suddently all of my build system will decide to blow up. (Today I had to recompile maven, torque, fulcrum, turbine-2 and two or three commons packages _again_ just to keep going, because the commons-lang people changed their package names). >I will finish the naming-conventions xdoc and post a link to it when I'm >done and we can settle the naming difficulties people are having. I'm still not convinced, that we actually have reached an agreement of what to write into this document. :-) I'd like to hear some more voices (we seem to have scared everyone off...) Regards Henning [1] I jar up my application before deploying it as a war. I jar up my templates, too and use the jar loader. This might be possible with the before-war-callback. [2] I'd like to distribute some jars with my application locally (the famous lib dir case). I don't seem to be able to add them to the classpath before compiling and deploying (deploying works. compiling does not). [3] I want to have different deployment targets. One that does not jar up all my classes and templates and uses a different configuration directory for the web.xml and the Turbine/Fulcrum/Torque configuration files than the real deployment target. One target is for local debugging, the other for actual release deployment. -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
