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 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'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'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... :-) ) 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? 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? >> - 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]>
