Hi Paul,
On Fri, 2008-04-25 at 09:18 +0200, Paul Sandoz wrote:
>
> On Apr 24, 2008, at 3:51 PM, Martin Grotzke wrote:
>
> > On Thu, 2008-04-24 at 09:46 +0200, Paul Sandoz wrote:
> > > On Apr 23, 2008, at 8:59 PM, Martin Grotzke wrote:
> > > > > would that result in an infinite regress of building?
> > > > AFAICS the mvn install does not invoke a dist, but only jar
> > > > (during
> > > > mvn
> > > > compile). Am I missing s.th.?
> > > >
> > > >
> > >
> > >
> > > No, i think i am *very* confused.... so you mean modify the ant
> > > dist
> > > to invoke maven which invokes the other ant clean/build/compile
> > > etc
> > > tasks.
> > Exactly :)
> >
> >
>
>
> Got it now :-) IMHO to keep things "clean" we should probably avoid a
> two way maven<->ant dependency and instead have the maven stuff depend
> on ant stuff (like maven/pom.xml) and step by step reduce that ant
> dependency.
So we could leave the ant build.xml as it is and let hudson do this job
via a post build action that invokes another job
"install-jersey-in-mvn-repo" (mvn install) after jersey has been built
successfully.
With this we would not have do change the build files of jersey...
> > > >
> > > >
> > > >
> > > > > That provides a convenient mechanism for others to locally
> > > > > install as well for the spring-based hudson building and
> > > > > testing
> > > > > tasks.
> > > > I'm somehow confused. What do you mean with spring-based hudson
> > > > building?
> > > >
> > > >
> > >
> > >
> > > I mean a Hudson task to build jersey-spring and test it.
> > Ok, that's a job that invokes mvn install.
> >
> >
>
>
> Yes.
>
>
>
>
> > >
> > > You are right we do need to tidy all this up. I think the right
> > > solution is to transfer over to maven, but it would be nice to do
> > >
> > > this in smaller steps if we can. I was hoping the first step could
> > > be
> > > to do what is required to get the jersey-spring build/testing to
> > > use
> > > locally installed artifacts produced from the jersey install.
> > Sounds good.
> >
> >
> > I'm just asking myself how I could help with this, what's the best
> > way
> > to get this running. Do you have a suggestion?
> >
> >
>
>
> 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?
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.
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.
> Does that sound like a plan?
Hmm, I would do it like this:
- don't touch jersey build scripts
- 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?
> 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?
Cheers,
Martin
>
>
> Paul.