Sahoo wrote:
> I agree a released artifact should be regarded as immutable. Therefore,
> the artifact must be produced such that it never references any SNAPSHOT
> versions of other artifacts. Unfortunately, that has not happened for
> this artifact, javax.activation:activation:1.1. Now, if we bump the
> version and produce new versions, all the existing dependent artifacts
> must be also changed to refer to the new version, right? e.g.,
> javax.xml.bind:jaxb-api:2.1 depends on javax.activation:activation:1.1.
> Unless we fix pom.xml of javax.xml.bind:jaxb-api:2.1 to refer to this
> new version, we can never safely reproduce jaxb-api-2.1.jar, can we?
Just to recap, it used to be that all our API modules were producing
non-SNAPSHOT versions, as various people pointed out, this is not a good
idea in the Maven world. We are expected to have SNAPSHOT versions
almost all the time, and the non-SNAPSHOT versions should only show up
in a tag. I'm not sure why it has been set up that way, but it's most
likely an oversight.
While recently working on updating POMs, I noticed this problem, so I
corrected them. That was just a few days ago. With this change, at least
we are now producing SNAPSHOT versions.
Now, we still have other problems to correct. For example, these POMs,
when crept into people's local repositories, do active harm. For
example, JAXB users out there depend on activation 1.1, and if that
started depending on SNAPSHOT that would be a mess.
So we'd like to think about removing them, but to do that we need to
have some stable versions of these APIs so that GFv3 build can depend on.
A part of this is about educating people that API modules need to be
maintained and released separately from the main GFv3 build.
> Thanks,
> Sahoo
>
> Wayne Fay wrote:
>> Released artifacts should be regarded as immutable. So, the only way
>> to "fix" this is to release a version-bumped activation jar/pom.
>>
>> In an ideal world, this would result in a new jar/pom being deployed
>> with an updated version eg 1.1.1.
>>
>> Wayne
>>
>> On 3/4/08, Sahoo <Sahoo_at_sun.com> wrote:
>>
>>> I think we are not being careful enough while using Maven. I just
>>> noticed that javax/activation/activation/1.1/activation-1.1.pom [1] is
>>> referencing org.glassfish.api:api:10.0-SNAPSHOT:
>>> <parent>
>>> <artifactId>api</artifactId>
>>> <groupId>org.glassfish.api</groupId>
>>> <version>10.0-SNAPSHOT</version>
>>> </parent>
>>>
>>> Why? How can anyone reproduce 1.1 version of
>>> javax.activation:activation? I won't be surprised if there are more than
>>> one such pom.xml. I think artifact owners need to review the poms and
>>> fix them.
>>>
>>> I came across this when I saw these log messages while running maven
>>> without having Internet access:
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get
>>> dependency information: Unable to read the metadata file for artifact
>>> 'javax.activation:activation:jar': Cannot find parent:
>>> org.glassfish.api:api for project: javax.activation:activation:jar:1.1
>>> for project javax.activation:activation:jar:1.1
>>> javax.activation:activation:jar:1.1
>>>
>>> from the specified remote repositories:
>>> central (http://repo1.maven.org/maven2),
>>> glassfish-repository (http://download.java.net/maven/glassfish),
>>> maven2-repository.dev.java.net (http://download.java.net/maven/2/),
>>> java.net-m2-repository (http://download.java.net/maven/2),
>>> java.net-m1-repository (http://download.java.net/maven/1),
>>> maven-repository.dev.java.net (http://download.java.net/maven/1/)
>>> Path to dependency:
>>> 1) com.sun.enterprise:auto-depends-plugin:jar:0.2-SNAPSHOT
>>> 2) com.sun.xml.bind:jaxb-xjc:jar:2.1.3
>>> 3) com.sun.xml.bind:jaxb-impl:jar:2.1.3
>>> 4) javax.xml.bind:jaxb-api:jar:2.1
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> [1]
>>> http://download.java.net/maven/glassfish/javax/activation/activation/1.1/activation-1.1.pom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com