Kohsuke Kawaguchi wrote:
> 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.
It's already a mess. activation:1.1 is already depending on
org.glassfish.api:api:10.0-SNAPSHOT and that's exactly what I am
reporting here. I am of the opinion that we should either violate the
immutable principle and fix the dependency in 1.1 version or remove 1.1
version altogether and add a new version of the aforementioned artifact.
The same applies to all other artifacts that have the same issue.
>
> 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.
>
In addition to that, as Wayne suggested, let's use the maven release
plugin to release our artifacts so that we catch such errors much earlier.
Thanks,
Sahoo