--
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
--- Begin Message ---
On Wed, 2002-07-17 at 10:31, Henning P. Schmiedehausen wrote:
> [ Jason asked me to repost this here ]
>
> We already went into violent agreement that jars like JAF or Javamail
> should have an <id></id> like <id>JAF</id> or <id>Java Activation Framework</id>.
Should be <id>jaf</id>. We agreed on lower-case, hyphenated ids.
> My problem with this is, that it is killing the ability of using the <version>
> tag, because <id> + <version> == jarname. So you must write the id either twice
> (in <jar> and <id>) or we should introduce a new field, called <name> or <jarname>
> which allows this:
>
> <dependency>
> <id>Java Activation Framework</id>
> <jarname>activation</jarname>
> <version>1.0.2</version>
> </dependency>
<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.
Most projects we can probably influence to settle on a unique project id
and have that be used when publishing project artifacts. The <id> +
<version> combination works in most cases and in the cases it doesn't
the <jar> can be used to override.
> --- cut ---
> Hi,
>
> while trying to keep the various dependency files in Turbine-2 and
> Fulcrum in sync, I found out that there seems to be a lot of confusion
> about how to write a dependency. Everyone uses his own style.
That's not entirely true. We have had some agreement when discussing
things. Albeit this happens in IRC a lot, and granted a document does
need to be made but we have had some agreement.
> I found no docs on the turbine / maven site either, so it seems that
> there is none. I wrote down a few guidelines for discussion. We should
> make this (just like coding style) a guideline to avoid confusion.
Cool.
> Please comment.
>
> 1) Every dependency must have an <id> tag (I think this is already
> enforced by Maven itself but not in the Maven docs).
+1
> 2) All dependencies are ordered in ascending alphabetical sequence
> of their <id> tags. This is "0-9a-zA-Z".
+1
We might even be able to adapt the tool Stephane made to do this.
> 3) No arbitrary rename of jars should happen. Only if a vendor
> distributed jar does not contain a version number, renaming
> is allowed but not required.
In the cases where I've changed it, it has been to make the project id
lowercase and hyphenated. In some cases I have renamed the JARs like the
xerces JARs. We can certainly choose an id and use the <jar> element if
we are to decide never to change the base name of the published JAR. So
for example always using XercesImpl as opposed to xerces.
> 4) Whenever possible, the <id></id> <version></version> form
> should be used. Only if the name of the jar is widely different
> from the <id> or does not contain a version number,
> the <jar></jar> statement should be used.
>
> Good:
>
> <dependency>
> <id>activation</id>
> <version>1.0.2</version>
> <jar>activation.jar</jar>
> </dependency>
-1
JARs have to have versions or the whole retrieval mechanism becomes
inefficient because you can never tell if you have the latest version of
a JAR without checking the repository. When building Maven can see in
the dependencies that foo-1.1.jar is required but you don't have it in
the repository. Maven can fetch it. If it sees activation.jar Maven
can't tell if you have the right version. And in the case of the
activation jar the information isn't even in the manifest.
Again, I think this is required:
<dependency>
<id>jaf</id>
<version>1.0.2</version>
<jar>activation-1.0.2.jar</version>
</dependency>
Where we have to rename the JAR in order for things to work properly.
> Good, with renaming:
>
> <dependency>
> <id>activation</id>
> <version>1.0.2</version>
> </dependency>
Fine, except that this doesn't work in this particular case because the
id = jaf. This case is the worst case scenerio actually. Sun releases a
JAR not based on the product name, like most other products, they don't
put a version on the JAR and the information is not in the manifest.
> Bad:
>
> <dependency>
> <id>bsf</id>
> <version>2.2</version>
> <jar>bsf-2.2.jar</jar>
> </dependency>
>
> <dependency>
> <id>bsf</id>
> <version>2.4</version>
> <jar>bsf-2.2-dev.jar</jar>
> </dependency>
Yes, those are bad.
> 5) If an URL is given and does not end in a explicit page reference,
> the URL must end with a "/"
>
> Good: <url>http://jakarta.apache.org/commons/collections.html</url>
> Good: <url>http://jakarta.apache.org/commons/</url>
>
> Bad: <url>http://jakarta.apache.org/commons</url>
We talk briefly about this before but dependency information will be
retrieved from a shared database of project information so that you
don't have to duplicate information in the <dependency> elements. No no
<url> and no other replication of information that should be taken from
the dependent project's POM.
> 6) The <required></required> Tag is not to be used. All jars must
> be present.
+1
> 7) Confusion about some commonly used names:
>
> Java Activation Framework (JAF):
>
> The JAF is distributed in a jar called "activation.jar" from SUN.
>
> It should be named like this:
>
> <dependency>
> <id>activation</id>
> <version>1.0.2</version>
> <jar>activation.jar</jar>
> <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
> </dependency>
-1
For reasons listed above.
> Renaming of the jar is acceptable (and preferred):
>
> <dependency>
> <id>activation</id>
> <version>1.0.2</version>
> <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
> </dependency>
>
> Java Mail API (JavaMail):
>
> The Java Mail API is distributed in a jar called "mail.jar" from SUN.
>
> It should be named like this:
>
> <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.
> Renaming of the jar is acceptable (and preferred):
>
> <dependency>
> <id>mail</id>
> <version>1.2</version>
> <url>http://java.sun.com/products/javamail/</url>
> </dependency>
>
> The jar should _not_ be renamed "javamail.jar"
I think we're gravitating toward not changing the base name and adding
versions if necessary.
> Xerces XML Parser
>
> The Xerces API consists of two jars. The following naming is
> to be used:
>
> <dependency>
> <id>xml-xerces</id>
> <type>required</type>
> <version>2.0.2</version>
> <jar>xercesImpl-2.0.2.jar</jar>
> <url>http://xml.apache.org/xerces2-j/index.html</url>
> </dependency>
> <dependency>
> <id>xml-apis</id>
> <type>required</type>
> <version>2.0.2</version>
> <jar>xmlParserAPIs-2.0.2.jar</jar>
> <url>http://xml.apache.org/xerces2-j/index.html</url>
> </dependency>
Here I've been using xerces and xml-apis. Though I don't care as long as
we agree on something.
>
> Things we need to clear up:
>
> - JvZ wrote me about "going to split the dependencies into compile and
> runtime dependencies (runtime == testing)". This would be really
> great to have.
>
> - 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.
> Which shows up in the dependency list on the maven generated web site.
>
> Alternatively:
>
> <dependency>
> <id>Java MAIL API</id>
> <jarname>mail</jarname>
> <version>1.2</version>
> </dependency>
>
> Where <jarname> is used instead of <id> when present.
>
> - 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.
> Regards
> Henning
>
> --- cut ---
>
> --
> 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
--- End Message ---
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
