users@jersey.java.net

Re: spring-integration tested and described

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 22 Apr 2008 14:28:10 +0200

On Apr 21, 2008, at 9:55 PM, Martin Grotzke wrote:

> On Mon, 2008-04-21 at 14:45 +0200, Paul Sandoz wrote:
>> Martin Grotzke wrote:
>>> I will update the ant build.xml in the jersey-spring module so that
>>> there's an `ant dist` and `ant -Dprofile=spring20 test`...
>>>
>> I think just using Maven is OK. The most important thing is to
>> make sure
>> we can add this as a Hudson task so it will get built/tested/packaged
>> every time we make changes to jersey or to jersey spring.
> Well, of course this is ok for me, I'm not begging for work :-D
> I removed build.properties and build.xml so that nobody tries to use
> them :)
>

LOL!


> I just ran the hudson webstart test drive, configured the spring
> package
> of the spring-integration branch, ran a test - and everything was
> fine!
>

Wow!


> As the spring-package has a dependency on jersey, I would say that
> jersey must have been installed in the repo that is used by hudson, I
> think this will be the only requirement.
>

Hmm... are the tests using Jersey 0.7? I am guessing the tests are
not depending on any API changes you made e.g ResourceContext.

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.


>
>>> What has to be clarified is the project structure, currently the
>>> trunk
>>> contains these directories:
>>>
>>> commons
>>> \- spring
>>> jersey
>>> \- <everything related directly to jersey like src, build, dist
>>> etc.>
>>> repo
>>> www
>>>
>>> To the question is if we replace commons/spring with the new spring
>>> package or if we create a jersey-spring package at the root level.
>>> IMHO a container for contrib modules is useful, so we could use the
>>> commons folder or rename it to contrib or s.th. else.
>>>
>>
>> Renaming "common" to "contribs" is fine my be and we can delete
>> "commons/spring".
> Done
>
>
>> We can mandate that everything in "contribs" should use maven.
> Ok.
>
>
>>> Before doing the merge we should also make sure that classes are
>>> at the
>>> correct place (like e.g. ResourceContext, the package of the
>>> SpringServlet, the groupId and artifactId of the jersey-spring
>>> module
>>> etc.). Can you check these things, Paul?
>>>
>>
>> OK. It would be good if other "mavenintes" could have a quick look at
>> the maven stuff.
> Yes, feedback welcome!
>
>
>> The location of ResourceContext is fine.
>>
>> If we are going to keep a similar naming scheme then i recommend
>> using
>> the following for the Servlet:
>>
>> com/sun/ws/rest/spi/spring/container/servlet/
>>
>> and the following for the annotations:
>>
>> com/sun/ws/rest/api/spring/
> Ok, I renamed/moved SpringServlet and annotations.
>

OK.


> 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.

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.

Paul.