[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?
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.
It may make sense to include maven stuff in the Jersey zip distribution,
for example:
jersey-0.8-ea/
maven/
pom.xml
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. That provides a convenient mechanism for others to locally
install as well for the spring-based hudson building and testing tasks.
>> 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.
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.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109