Markus KARG wrote:
>
> *Paul,*
>
> * *
>
> *see inlined. :-)*
>
>
>
> 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.
>
>
>
> *It was not clear that "contribution to jersey" means "contributing
> MODULES to jersey that give up their indepency" (sorry for assuming
> that my code could stay independent -- I am living in a federal nation
> so I just assumed this principle. My fault.).*
>
>
>
> 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.
>
>
>
> *I also want the project to stay part of the Jersey project, but not
> necessarily of the Jersey product, but I do not agree with what this
> means in the end for users of other JAX-RS implementations. Beeing "a
> module" means to give up the idea that other JAX-RS implementations
> can run my WebDAV code, or at least, it would be harder to identify
> what JARs are needed and what version number contains which changes. I
> do not want that WebDAV is "a non-standalone module", but it is and
> shall stay ONTOP of the jersey core (why not? what would be the
> benefit of doing that for the user?).*
>
> * *
>
> *So actually for me this reads like "don't be easily useable with
> other JAX-RS implementations or we will kick you out", which would be
> a rather strange decision for an open project (or maybe this is not an
> open project but just a project producing open source? Sorry, my fault.).*
>
> * *
>
I do not see where that follows from what I said. Your pom.xml makes it
clear that you don't depend on any Jersey internals, which means the
module is indeed able to be used with other JAX-RS implementations.
What I proposed is that, if you're going to live in the jersey SVN
repository, you're going to be considered by the rest of the world as
"part of jersey" -- and we should not be surprising people by violating
that expectation.
>
> *Why can't we just add a folder to the SVN tree that contains JAX-RS
> related, standalone projects which can run with any JAX-RS
> implementation but are not forced to have the Java Version and project
> version be in line with Jersey's core? That would be an easy, simple
> solution with which we all could be live, and I would be happy if
> WebDAV would not be the only one -- ATOM support would be absolutely
> correctly located there, too, and a lot of other JAX-RS implementation
> users would be happy to download jersey-atom.jar and jersey-webdav.jar
> and use it with any implementation they like. :-)*
>
Frankly, that sounds like you want it to be a separate project. If so,
that's certainly your choice. By the way, the current ATOM support (in
both jersey-atom based on Rome, and jersey-atom-abdera based on Abdera)
do have dependencies on jersey-core -- it saved a bunch of extra coding
to do this -- so they wouldn't really fit your definitlion of a "JAX-RS
related" set of projects that is not implementation dependent.
> * *
>
> *What do you think about this?*
>
Personally, I really hope you choose to stay part of Jersey -- working
with other implementations too is a nice bonus, but Jersey would
definitely benefit by having WebDAV support as part of its releases.
>
> * *
>
> *Regards*
>
> *Markus*
>
>
>
Craig
>
> 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 <mailto: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 <mailto: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
> <mailto:dev-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> <mailto:dev-help_at_jersey.dev.java.net>
>
>
>
>
>
>
>