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. > 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. > >> - I'd like to introduce a "description" tag into the dependencies (this > >> is more for the maven people): > >> > >> <dependency> > >> <id>mail</id> > >> <version>1.2</version> > >> <description>Java Mail API</description> > >> </dependency> > > >-1 > > >This should come from the <shortDescription> of the dependent project. > > -1 on that idea. > > Consider the case when a developer is _not_ online. In some countries > (and not only 3rd world telecommunications countries like Germany), > being online is expensive. How would you get all the related > <shortDescription> tags while building a project. Consider being > behind a 56k modem connection. > > Consider a case where someone is behind a firewall and simply can't > access all of the project pages because of firewall rules (/me winks > to the S*emens SmartFilter people... :-) ) 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. > 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. > 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 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. The share database of information can provide not only short, but full descriptions and pointers to any other resources the dependency may provide. Like I said, this mechanism doesn't work yet which is why I didn't mind the <url> element in the dependency but there won't be any more. 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. > > >> - SNAPSHOT and DEV > >> > >> We had the confusion about <version>SNAPSHOT</version>. > >> Make this a formal, allowed version tag which enforces > >> reloading of the jars (maven people). > > >I will summarize in another document and we can vote on it. I realize > >this has become a problem. > > Cool, thanks. > > Regards > Henning > > -- > 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]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
