On Fri, 2008-04-25 at 15:19 +0200, Paul Sandoz wrote:
> Martin Grotzke wrote:
> >> I think we should use the jersey/maven/pom.xml as a starting point
> >> (which defers to ant) and use the jersey/pom.xml (that Doug has done)
> >> as the goal to head towards (i.e. doing everything in maven). We can
> >> keep the existing build.xml in place without modification so we do not
> >> break anything.
> > This would be good.
> >
> > Why do you want to have a jersey/pom.xml? Why is jersey/maven/pom.xml
> > not sufficient?
>
> Because i forgot that "jersey/maven/pom.xml" was there and Doug has done
> some good work on a more maven like maven pom.xml that he committed
> recently to "jersey/pom.xml".
Uups, I missed that now there's a jersey/pom.xml, sorry!
>
>
> > Having build.xml directly in jersey and pom.xml in jersey/maven shows
> > what is the "primary" build tool. Having pom.xml directly in jersey I
> > would prefer to do the build with maven and not to invoke some ant
> > stuff.
> >
>
> I think we should move "jersey/pom.xml" to
> "jersey/maven/pom-less-ant.xml", or something like that, so we don't
> loose it.
Yes, if this is the candidate for the future jersey/pom.xml it shouldn't
get lost :)
> > So I would suggest to keep the whole jersey build as it is, see above.
> >
> > Then if you want to switch to maven I would create a pom.xml that does
> > not depend on ant.
> >
> >
> >> Perhaps you could look at the trunk/jersey/maven/pom.xml and see if
> >> that is sufficient for our needs. Then we could have have a
> >> trunk/pom.xml that would invoke the trunk/jersey/maven/pom.xml and the
> >> trunk/contrib/spring/pom.xml. For the jersey-spring Hudson task we can
> >> obtain the built snapshot of jersey and do the jersey/maven/pom.xml
> >> install and then it can checkout/build/run/test the contrib/spring
> >> stuff.
> > Obtaining stuff from somewhere sound like manual work, the concepts of
> > maven are different: maven uses the maven-repo, dependencies are fetched
> > automatically.
>
> OK. So you think we should push jersey SNAPSHOT artifacts to the
> java.net maven repo for every set of commits detected? (like we do for
> the jersey.zip distribution to java.net)
Yes. Another advantage of this is that really brave users could depend
on these SNAPSHOTs.
> >
> >
> >> Does that sound like a plan?
> > Hmm, I would do it like this:
> > - don't touch jersey build scripts
>
> OK.
>
>
> > - add a hudson job for "mvn install" with jersey/maven/pom.xml
> > ("mvn-install-jersey")
> > - add a hudson job for "mvn install" with jersey/contribs/spring/pom.xml
> > ("mvn-install-jersey-spring")
> > - add two post-build actions to the "ant-build-jersey" hudson job:
> > - mvn-install-jersey
> > - mvn-install-jersey-spring
> >
> > What do you think?
> >
>
> I don't see the point of the another "mvn-install-jersey" if we are
> already building Jersey with Hudson. We easily can modify the existing
> Jersey build hudson job to execute mvn install, as long as that results
> in the jersey-*.zips being generated as well (so they get pushed to
> java.net).
You're right, that's the better way.
> Perhaps we could modify the package phase to call "ant dist"
> then we are fully backwards compatible with the generated bits?
Ok.
>
> Note the 311 and jersey poms currently reference the java.net maven 1
> repo, so we should change that to use the maven 2 repo. Actually do we
> need to do "mvn deploy" to push stuff to the maven 2 repo?
This should be to thing to do, but to be honest I haven't published some
maven artifact to a repo until now ;)
Cheers,
Martin
>
>
> >
> >> After that we need to split Jersey into separate modules each with
> >> their own pom.xml. I would like to use grizzly.dev.java.net as the
> >> template we copy (i have been looking at how that works with help from
> >> Jeanfrancois). Grizzly provides a jar per-module as well as jars for
> >> bundles of modules. We can have a bundle for jersey.jar as well as say
> >> jersey-runtime.jar, jersey-servlet.jar, jersey-json.jar etc.
> > Ok. I would suggest that we discuss how to restructure jersey after the
> > jersey-spring build is configured/integrated, ok?
> >
>
> Yes.
>
> Paul.