On Jan 26, 2009, at 12:06 AM, Craig McClanahan wrote:
> Markus KARG wrote:
>>
>> Well, this depends on what Paul and Marc want to make out of
>> Jersey: If they want to make it a collection of JAX-RS utilities
>> ontop of a JAX-RS implementation, then I do not see that a split is
>> needed. Actually it was a standalone project before (internally
>> hosted by us, not publicly available) and I asked whether I shall
>> make a standalone project or contribute to Jersey. It was Paul that
>> said that he likes it to be part of Jersey. So I have to wait for
>> his decision how he will deal with the fact that it can run with
>> other JAX-RS implementations and has its own version schema and
>> livecycle.
>>
> My personal feelings about this -- if a module lives in a Jersey
> namespace (Java package name and/or Maven group and artifact
> identifiers), ships with Jersey (presumably a goal at some point in
> the development process), and has its source somewhere in the Jersey
> trunk (presumably would happen with a merge to trunk from the
> current branch), then that module should carry the same version
> number (and release timelines) as the rest of Jersey. Further, I
> would think the package names, as well as other conventions such as
> JDK dependencies and common build plugins, should also match.
>
> The fact that the module may or may not have any dependencies on
> Jersey internals is an implementation detail (and that of course
> gets reflected in the <dependencies> section of its POM) that may or
> may not change in the future. That by itself should not be a
> deciding factor on versioning, or for that matter naming.
>
> If the module wants the "marketing" benefits :-) of being part of
> Jersey, instead of being standalone, then it should really *be* part
> of Jersey. Even if (at the moment) it will actually run on any JAX-
> RS implemenetation (and therefore declare only the API jar in its
> dependencies).
>
> This particular codebase is off to a very promising start, and is
> something I would personally like to see in Jersey (with, as usual
> for me, some love for the client side too :-). But I'd prefer to
> see it "all in" rather than being perceived as straddling a fence.
>
I agree with Craig.
I would like to see this as part of Jersey under the same constraints
as other modules in the contribs. I assumed that this would be the
case, but i did not communicate this assumption before hand, but
sometimes these discussions take time to reveal themselves and
solidify :-) as a result i think we should change the contribution
page to detail the constraints for modules.
Markus, i think you have to decide whether you want the WebDAV module
to be part of Jersey or as a separate project. Obviously you know
which decision i would prefer but whatever decision you make you have
my support in terms of helping out.
Paul.
> Craig
>
>> Regards
>> Markus
>>
>> From: Edelson, Justin [mailto:Justin.Edelson_at_mtvstaff.com]
>> Sent: Samstag, 24. Januar 2009 22:45
>> To: dev_at_jersey.dev.java.net
>> Subject: RE: [Jersey] WebDAV pom.xml
>>
>> Just my 2 cents (and feel free to ignore), but it seems like this
>> needs to be separated from Jersey and made a standalone project at
>> java.net (or somewhere else).
>>
>> Justin
>>
>> From: Markus KARG [mailto:markus.karg_at_gmx.net]
>> Sent: Sat 1/24/2009 11:58 AM
>> To: dev_at_jersey.dev.java.net
>> Subject: RE: [Jersey] WebDAV pom.xml
>> Paul,
>>
>> first of all, thank you for your ideas and sorry for not answering
>> earlier.
>> Once more I catched a cold and so I did not find the power to spend
>> my
>> evenings with complex issues. More inline.
>>
>> > Every time we release Jersey we do the following:
>> > - make a tag of the trunk;
>> > - change the version in the trunk of all modules from "xxx-
>> > SNAPSHOT" to "yyy-SNAPSHOT"; and
>> > - change the version in the tag of all modules to "xxx" and
>> deploy
>> > the maven artifacts to the repo.
>> > It makes it a lot easier to manage releases if all module
>> versions are
>> > in sync and we release at the same time. Generally all Jersey
>> modules
>> > tend to have a coupling of Jersey APIs where we also tend to, at
>> least
>> > currently, have a fast update between components to fix issues and
>> > support features. So i would prefer to retain this approach.
>> > Do you envisage having a different release cycle to that of
>> Jersey as
>> > well as a different version number?
>> > Maybe the contribs area is not really suitable in this respect
>> and we
>> > need another area separate from Jersey for components that can be
>> > versioned and released independently? e.g.
>> > trunk/components
>> > I think that may better suit your requirements based on what you
>> say
>> > above and below. i.e. i don't want to unduly constrain your
>> > development and what you depend on. We can set up separate Hudson
>> jobs
>> > to build components.
>>
>> In fact, WebDAV stuff is not related to Jersey in any way. The
>> project was
>> build solely on JAX-RS 1.0, and does not know about any Jersey
>> specific
>> thing. So from a technical aspect, it is not a Jersey component in
>> the
>> narrow sense, but more a usage of Jersey, just as it could be a
>> usage of any
>> other JAX-RS 1.0 implementation. This is the reason why the release
>> politics
>> makes sense to stay different from Jersey's. WebDAV just has no
>> technical
>> need to keep anything in sync with Jersey. The problem is that it
>> seems
>> there is no really good place to put it. Actually WebDAV is neither a
>> contrib to the Jersey engine while it IS one to the Jersey project
>> as a pool
>> of RESTful technology projects, and it neither is a component of
>> the Jersey
>> engine. I wouldn't say that it would be best to put it into its own
>> top
>> level project, but maybe it would be good to have a new folder
>> containing
>> projects like mine which just USES JAX-RS but not directly Jersey,
>> and which
>> could be downloaded separately? I'd like people of other JAX-RS
>> implementations being able to use WebDAV, and that would be the
>> best way for
>> that. So Jersey could be two things: A JAX-RS implementation with
>> additional
>> features PLUS a set of JAX-RS components independent of the JAX-RS
>> implementation. This would also be a good place to put Daniel
>> Manzke's
>> "Microsoft Interoperability" stuff. What do you think about that?
>>
>> > Note that JAX-RS does require support on SE 5, so the additional
>> > Jersey modules require it as well. In IDEs (at least in NetBeans)
>> you
>> > can set a project to use SE 6 but compile SE 5 constrained source
>> to
>> > catch errors.
>>
>> Actually what your wrote into the spec is that SE 5 OR LATER is
>> needed, so
>> it is not a constraint to exactly match SE 5 in all projects that
>> are USING
>> JAX-RS -- and my code just USES Jersey. My WebDAV code targets in
>> Java EE 6
>> contained JAX-RS, so SE 6 is what I develop and test upon (and what
>> I can
>> afford -- I have no time to explicitly test drive on SE 5). Again,
>> WebDAV is
>> nothing that is inside of Jersey, and it sits ontop of it, so if
>> somebody
>> wants to use WebDAV he must use SE 6 (which is not a problem in
>> times of SE
>> 6 everywhere and EE 6 published soon). I do not see the actual
>> problem right
>> now. Can you elaborate on this so I could understand (anyways I
>> have no time
>> to check SE 5, and my Eclipse will not know what APIs are not
>> existing in SE
>> 5 unless I install SE 5 in addition to SE 6, which I just will not
>> due since
>> I do not understand the need)?
>>
>> > Jakub will know more, he is our Maven guru :-)
>>
>> Did not hear anything from him so far, so it seems it was OK what I
>> did.
>>
>> > > As "1.0" effectively means
>> > > "[1.0,)" I
>> > > do not see why it is better than my explicit "[1.0,)"...?!
>> > Oh! i guess i do not understand maven version declarations :-) i
>> want
>> > to be clear under what conditions Jersey has been tested against
>> but
>> > did not want to necessarily restrict developers to using other
>> > versions.
>>
>> Then you should change from your "1.0" (i. e. "1.0, or later than
>> 1.0") to
>> my "[1.0;2.0)" (i. e. "anything in the range from 1.0 to but not
>> including
>> 2.0"), which more clearly says that API changes (2.x, 3.x) are not
>> accepted,
>> while bug fixes are.
>>
>> Have Fun
>> Markus
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
>