dev@glassfish.java.net

Re: Why is a non-SNAPSHOT pom.xml referencing a SNAPSHOT version artifact?

From: Sahoo <Sahoo_at_Sun.COM>
Date: Wed, 05 Mar 2008 10:58:12 +0530

Thanks, Wayne for confirming. But, the set of consumers of that bad
artifact is (theoritically) open ended. How can all of them be fixed?
1.1 version of that artifact is really a bad artifact and hence must not
be used any more. Is there a way to hide it to prevent it from being
used any further? Or, is there a way for the maven repository to issue a
warning whenever it is used?

I don't know why the release plugin has not been used by us. BTW, why is
it not used by Maven by default?

Thanks,
Sahoo

Wayne Fay wrote:
> That is correct, Sahoo. So you'll want to version-bump those as well,
> and specify activation-1.1.1 instead of 1.1.
>
> If you use the release plugin to manage your releases of Maven
> artifacts, it will not allow you to release if you are using snapshot
> dependencies or plugins.
>
> Wayne
>
> On 3/4/08, Sahoo <Sahoo_at_sun.com> 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?
>>
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>