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