You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Ewins <Br...@i-documentsystems.com> on 2003/01/10 17:58:45 UTC
Re: A tale of two builds (or: Why I don't like the =?iso-8859-1?q?SNAPSHOT
sematics?=)
Peter Donald wrote:
>On Wed, 8 Jan 2003 21:44, Brian Ewins wrote:
>
>
>>I don't think indirect dependencies are quite so straightforward. [snip]
>>
>I would highly recomend that you use the JDK "Optional Package" or "Extension"
>mechanisms for this. Basically for each jar you define a set of extensions
>that the jar provides and a set of extensions that the jar needs.
>
Well its the jar versioning mechanism spec you mean[1], but yes, that's
exactly what I was referring to when I wrote: " I tried to identify jar
versions and was disappointed with the practically nonexistent
information in most manifests (including Sun's jars of javax.* stuff)".
I wrote a version of the axis fingerprint which extracted this info from
every jar, only to find that only a couple of jars had anything worth
reporting. IIRC this included things like the servlet APIs distributed
from tomcat, which being the reference impl should know better.
Unfortunately this mechanism is currently a fiction created to torment
writers of build tools ;)
Its a good discussion point actually - since maven provides some help in
generating manifests, over time the info available to maven will
improve. Support could be improved though. Here's what the ear plugin does:
<manifest>
<attribute name="Built-By" value="${user.name}" />
<section name="${pom.package}">
<attribute name="Specification-Title" value="${pom.id}" />
<attribute name="Specification-Version"
value="${pom.currentVersion}" />
<attribute name="Specification-Vendor"
value="${pom.organization.name}" />
<attribute name="Implementation-Title"
value="${pom.package}" />
<attribute name="Implementation-Version"
value="${pom.currentVersion}" />
<attribute name="Implementation-Vendor"
value="${pom.organization.name}" />
</section>
</manifest>
Note several POM entries are reused, instead of having separate entries
in the POM for the different pieces, and use the values above as
defaults. The only way to override the info at present is to write a
manifest by hand. It seems to me like it should be possible - compulsory
even ;) - to have this info in the POM since maven is targeted at
producing a single artifact per project.
Cheers,
Baz
[1]
http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html
. the optional/extension bit just depends on the versioning spec for
version info. Maven should probably not be in the game of writing info
from the extension spec into the manifest unless the user explicitly
requests it, because that's supposed to install jars on the fly into
lib/ext!
Privacy and Confidentiality Notice
------------------------------------------------
The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses).
Re: A tale of two builds (or: Why I don't like the =?utf-8?q?SNAPSHOT
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 11 Jan 2003 03:58, Brian Ewins wrote:
> Peter Donald wrote:
> >On Wed, 8 Jan 2003 21:44, Brian Ewins wrote:
> >>I don't think indirect dependencies are quite so straightforward. [snip]
> >
> >I would highly recomend that you use the JDK "Optional Package" or
> > "Extension" mechanisms for this. Basically for each jar you define a set
> > of extensions that the jar provides and a set of extensions that the jar
> > needs.
>
> Well its the jar versioning mechanism spec you mean[1],
No its not ;) It is the spec that was called "Extension" spec in JDK1.2 and
got renamed to the "Optional Package" specification in JDK1.3. It is the same
extension that servlet engines and EJB engines must support.
See;
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
> Unfortunately this mechanism is currently a fiction created to torment
> writers of build tools ;)
Its a bit like that. A worst thing is that some things that actually implement
it (ie Tomcat) are broken with transitive dependencies in some arrangments ;(
> <manifest>
> <attribute name="Built-By" value="${user.name}" />
> <section name="${pom.package}">
> <attribute name="Specification-Title" value="${pom.id}" />
> <attribute name="Specification-Version"
> value="${pom.currentVersion}" />
> <attribute name="Specification-Vendor"
> value="${pom.organization.name}" />
> <attribute name="Implementation-Title"
> value="${pom.package}" />
> <attribute name="Implementation-Version"
> value="${pom.currentVersion}" />
> <attribute name="Implementation-Vendor"
> value="${pom.organization.name}" />
> </section>
> </manifest>
The Extension spec has a slightly different format. Namely it replaces
"Specification-Title" with "Extension-Name" and allows you to specify
dependencies via something like
Extension-List: trax velocity
velocity-Extension-Name: org.apache.velocity
velocity-Specification-Version: 1.0
trax-Extension-Name: Java API for XML Parsing
trax-Specification-Version: 1.1
trax-Implementation-Title: org.apache.xalan.xslt
trax-Implementation-Version: 2.1.0
trax-Implementation-Vendor: Apache Software Foundation
Maven could add those dependencies by scanning and selecting dependencies from
its POM. Though I am not sure how to determine which dependencies are runtime
... does Maven have a way to do this?
> Note several POM entries are reused, instead of having separate entries
> in the POM for the different pieces, and use the values above as
> defaults. The only way to override the info at present is to write a
> manifest by hand. It seems to me like it should be possible - compulsory
> even ;) - to have this info in the POM since maven is targeted at
> producing a single artifact per project.
+1
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
Re: A tale of two builds (or: Why I don't like the SNAPSHOT sematics)
Posted by di...@multitask.com.au.
Gotta patch we can look at?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Brian Ewins <Br...@i-documentsystems.com> wrote on 11/01/2003
03:58:45 AM:
>
>
> Peter Donald wrote:
>
> >On Wed, 8 Jan 2003 21:44, Brian Ewins wrote:
> >
> >
> >>I don't think indirect dependencies are quite so straightforward.
[snip]
> >>
> >I would highly recomend that you use the JDK "Optional Package" or
> "Extension"
> >mechanisms for this. Basically for each jar you define a set of
extensions
> >that the jar provides and a set of extensions that the jar needs.
> >
> Well its the jar versioning mechanism spec you mean[1], but yes, that's
> exactly what I was referring to when I wrote: " I tried to identify jar
> versions and was disappointed with the practically nonexistent
> information in most manifests (including Sun's jars of javax.* stuff)".
> I wrote a version of the axis fingerprint which extracted this info from
> every jar, only to find that only a couple of jars had anything worth
> reporting. IIRC this included things like the servlet APIs distributed
> from tomcat, which being the reference impl should know better.
>
> Unfortunately this mechanism is currently a fiction created to torment
> writers of build tools ;)
>
> Its a good discussion point actually - since maven provides some help in
> generating manifests, over time the info available to maven will
> improve. Support could be improved though. Here's what the ear plugin
does:
>
> <manifest>
> <attribute name="Built-By" value="${user.name}" />
> <section name="${pom.package}">
> <attribute name="Specification-Title" value="${pom.id}" />
> <attribute name="Specification-Version"
> value="${pom.currentVersion}" />
> <attribute name="Specification-Vendor"
> value="${pom.organization.name}" />
> <attribute name="Implementation-Title"
> value="${pom.package}" />
> <attribute name="Implementation-Version"
> value="${pom.currentVersion}" />
> <attribute name="Implementation-Vendor"
> value="${pom.organization.name}" />
> </section>
> </manifest>
>
> Note several POM entries are reused, instead of having separate entries
> in the POM for the different pieces, and use the values above as
> defaults. The only way to override the info at present is to write a
> manifest by hand. It seems to me like it should be possible - compulsory
> even ;) - to have this info in the POM since maven is targeted at
> producing a single artifact per project.
>
> Cheers,
> Baz
>
> [1]
> http://java.sun.com/j2se/1.
> 3/docs/guide/versioning/spec/VersioningSpecification.html
> . the optional/extension bit just depends on the versioning spec for
> version info. Maven should probably not be in the game of writing info
> from the extension spec into the manifest unless the user explicitly
> requests it, because that's supposed to install jars on the fly into
> lib/ext!
>
>
>
> Privacy and Confidentiality Notice
>
> ------------------------------------------------
>
> The information contained in this E-Mail message is intended only
> for the person or persons to whom it is addressed. Such information
> is confidential and privileged and no mistake in transmission is
> intended to waive or compromise such privilege. If you have
> received it in error, please destroy it and notify us on the
> telephone number printed above. If you do not receive complete and
> legible copies, please telephone us immediately. Any opinions
> expressed herein including attachments are those of the author only.
> i-documentsystems Ltd. does not accept responsibility for the
> accuracy or completeness of the information provided or for any
> changes to this Email, however made, after it was sent. (Please note
> that it is your responsibility to scan this message for viruses).
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> help@jakarta.apache.org>
>
> ForwardSourceID:NT000A1B3E