On 8/8/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
> Gregory Kick wrote:
> > Kohsuke,
> >
> > I looked over the poms that you pointed out and found that there is a
> > difference in how the different artifacts are versioned. I just used
> > 2.0.2 for everything, but you seemed to keep things like the api on a
> > separate track. That seems to be the only thing that really needs to
> > be resolved. Otherwise, feel free to update your poms with what I sent.
>
> This is because APIs are rev-ed differently from the RI. For example,
> when the RI 2.0.2 shipped, it still uses API 2.0. API is owned by the
> JCP, whereas the RI is owned by this project.
The same versioning schema is used for jaxb-1.x. All are rev'ed
separately, except from the API jar which sticks to the same varsion
number. This choice creates problems with maven, since each new JAXB
release ovewrites the same old API jar inside the repository.
I see 3 ways to work around it:
* It maybe better to use a version pattern for the api jar like that:
jaxb-api-2.0-2.0.9.jar.
* Another solution would be to embed the first '2.0' version nuber
into the artifactId,
like that:
jaxb-api2.0-2.0.9.jar
I find the second solution technically more correct than the first,
although it looks a bit ugly.
* The seconf solution may get improved by separating the 'jaxb-api'
with '2.0' with a dash, resulting in the final name of the first
solution but with diferent name components.
I'm not sure that the third solution won't have any side-effects, as
i remember while scanning through maven's core code, an algorithm
scanning for patterns like that:
<artifaxtName>-<version>-(SNAPSHOT|RELEASE).xxx.
Anyway, my memory is to vague about this issue, feel free to choose
the appropriate one, or none, if you see no reason to (for instance,
the jaxb-api.jar contents and deps never change)!
Regards,
Kostis
>
> > As far as improving the build script, I'd think that the best first
> > step towards updating the build script would be to convert to maven
> > for builds... I know that it's a lot of work (I'd certainly be
> > willing to help), but the rewards are tremendous when the entire
> > process is simplified down to "mvn deploy". Otherwise, a lot of
> > energy is spent trying to recreate a lot of the functionality
> > provided by wagon.
>
> Yeah. I see what you mean. It's just that between all the code
> generators, custom document formatter, strange re-jarring, and samples
> generators that we use, I wonder how many maven plugins we need to write...
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
>