There is no way to prevent people from using the "bad" 1.1 artifact.
However, if people are using Maven for their builds as well as their
releases, then the release plugin will not allow them to release with
a dependency on 1.1 due to the SNAPSHOT. (Maven resolves all the
dependencies including transitives and does not allow the release to
succeed if there are any snapshots involved.)
There are lots of ways to get Maven artifacts into a directory
structure. There is no absolute requirement that you use the release
plugin process etc. It seems likely that someone simply copied files
out of their local cache/repo and into this directory structure to
"release" them.
As a general rule, if you want these kinds of checks applied during
the release process (and you really should if you care about long-term
repeatability of your build process), you should probably be using the
release plugin.
Wayne
On 3/4/08, Sahoo <Sahoo_at_sun.com> wrote:
> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>