On Wed, 2008-04-23 at 19:06 +0200, Paul Sandoz wrote:
> [There is at least a 3 hour delay for me receiving this email]
>
> Martin Grotzke wrote:
> > On Wed, 2008-04-23 at 12:50 +0200, Paul Sandoz wrote:
> >> Martin Grotzke wrote:
> >>> I just wanted to mention it, so that it's clear that the nightly build
> >>> of jersey should also install jersey as an artifact in the maven
> >>> repository that is used for the jersey-spring build.
> >>>
> >> We don't have nightly builds (yet). We currently have:
> >>
> >> - latest builds, built every time a set of commits is detected; and
> >>
> >> - stable builds, the artifacts of which are pushed to maven.
> >>
> >> I would prefer if we can test the spring stuff every time a set of
> >> commits is detected to the Jersey repo. Rather than doing it on a
> >> nightly basis, as we can catch failures and resolve them much faster.
> > Ok, so the best solution for this would be if hudson could run a certain
> > job after another job completed successfully. I just had a look at
> > hudson, and at the job configuration there's a section "Post-build
> > Actions" with the option to "Build other projects"... :)
> >
>
> Yes, we already do that trick for running the unit tests.
>
> We execute a shell and do this:
>
>
> rm -fr jersey*
> wget -q
> http://kohsuke.sfbay/hudson/job/Jersey/lastSuccessfulBuild/artifact/jersey/dist/jersey-snapshot.zip
> unzip jersey-snapshot.zip
> cd jersey
> JERSEY_HTTP_SLEEP=2000 JERSEY_HTTP_STOPSEC=2
> /files/hudson/tools/ant-1.6.2-junit/bin/ant hudson-unit-tests
>
>
> so the unit test task does not have to rebuild.
>
>
> >
> >>>> The spring tests need to depend on the latest built artifacts from
> >>>> the jersey directory. Do we need some "maven glue" for installing
> >>>> jersey.jar et. al. to the local file based repository? e.g. look at
> >>>> the maven/pom.xml that creates the jersey and 311 poms and uses the
> >>>> version obtained from the build.properties.
> >>> Yes, we need this. I think s.th. like a simple exec in the maven dir
> >>> with executable mvn and argument install should be enough.
> >>>
> >> Can that be configured in a pom.xml and done by maven itself? Could we
> >> supply a pom.xml with the jersey distribution that installs the jars
> >> locally?
> > You already have this, don't you? I can go to jersey/maven and just type
> > `mvn install`, which does exactly what we want.
> >
>
> This builds the distribution by referring back to the build.xml...
>
>
> > So the dist target of jersey would simply exec(ute) exactly this (of
> > course including some test if mvn is available, selecting the correct
> > executable and stuff, somehow like it's shown here [1]).
> >
>
> ...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.?
>
> In terms of Hudson execution it would be more efficient to work from the
> pre-built snapshot or jersey distribution and execute a pom.xml that
> performs just installation.
This is what the maven/pom.xml (of jersey) is doing right now, isn't it?
>
> It may make sense to include maven stuff in the Jersey zip distribution,
> for example:
>
> jersey-0.8-ea/
> maven/
> pom.xml
Sounds good!
>
> and executing mvn install on the jersey-0.8-ea/maven/pom.xml would
> install jersey and 311 snapshots from the jar files in the lib
> directory.
In which lib directory?
mvn install should install the artifact of subject in the maven
repository.
> 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?
>
>
> >> That way we could configure the spring Hudson task to depend on the
> >> jersey Hudson task. The former will obtain the built distribution from
> >> the latter, run mvn on say "install-pom.xml" to install the jars.
> >>
> >> Would that work? or am i complicating matters?
> > I think simply invoking mvn install from ant dist should do the trick,
> > in combination with the post-build hook of hudson.
> >
> >>
> >>> I just had a look at the build.xml and found the target
> >>> "push-to-maven-prepare" - what is this and has it anything to do with
> >>> the things we are talking about?
> >>>
> >> Only if we want to push nightly builds to maven. There is a little
> >> java.net tool that listens to SVN commits to that location and then
> >> pushes updates to the java.net repo.
> > Ok, publishing must also be done for jersey-spring...
> >
>
> Yes.
I don't know much about the current setup of jersey builds in hudson,
but to me it seems to be a little bit complex - I simply don't
understand the whole process. Perhaps this could be simplified a little
bit, to have more simplicity and maintainability with the cost of
efficiency.
Having said this - don't take my comments regarding how to integrate the
build of jersey-spring into the build of jersey itself too serious, I
might make wrong assumptions about what is happening right now :)
Cheers,
Martin
>
> Paul.
>
> >>
> >>>>> What about the maven groupId "com.sun.ws.rest" and the artifactId
> >>>>> "jersey-spring"?
> >>>>>
> >>>> Currently we use "jersey" as the artifactId when we push stable
> >>>> builds. Perhaps we should stick to that for now.
> >>> Probably you refering to the groupId?
> >>>
> >> No, see here:
> >>
> >> http://download.java.net/maven/1/jersey/poms/jersey-0.7-ea.pom
> > Yes, the artifactId for jersey is jersey, the artifactId for
> > jersey-spring should be jersey-spring. But what about the groupId of
> > both (which should be shared between jersey and jersey-spring)?
> > I think jersey as groupId is not really mvn-conform (in respect to
> > qualified groupIds).
> >
> >
> >>> When do you plan to change this? AFAIK the whole maven world is trying
> >>> to fix things that were wrong when maven started, and one thing is to
> >>> have fully qualified groupIds (unfortunately I couln't find a reference
> >>> for this within 5 seconds, I just remember this).
> >>>
> >>> Perhaps this would be a chance to change the groupId jersey to a fully
> >>> qualified one :)
> >>>
> >>>> Before we named the project we used "com.sun.ws.rest" and it sort of
> >>>> stuck but i would prefer to rename packages to start with
> >>>> "com.sun.jersey" and use that as the artifactId.
> >>> Do you have an idea when you would change this?
> >>>
> >> We could do this for the 0.8 release. I think we should send a new email
> >> giving a heads up about this, as it will be a rather disruptive change.
> > Yes, I totally agree!
> >
> >
> >>> Perhaps we could already use com.sun.jersey as groupId for maven then...
> >>>
> >> I don't have strong preference, but i would prefer to wait until we make
> >> the actual change.
> > Ok. Just to have the groupId of jersey-spring in sync with the one of
> > jersey I would change it to jersey for now.
> >
> > Cheers,
> > Martin
> >
> >
> > [1] http://www.ant-tasks.com/msg/28434.html
> >
> >
> >> Paul.
> >