Well, such a project would be nice since it could be an incubator for JAX-RS
based applications that not yet are mature enough for their own web site,
like WebDAV was in late 2008. The question is what the conditions for the
projects would be and how the management of the site would be like?
Meanwhile I will start my own java.net project to host the WebDAV related
stuff (my core and Daniel's Microsoft-Interop stuff) to be able to
independently release and publish as often as possible.
Have Fun
Markus
> -----Original Message-----
> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Sent: Freitag, 30. Januar 2009 22:11
> To: dev_at_jersey.dev.java.net
> Subject: Re: [Jersey] WebDAV pom.xml
>
> Maybe we should start a new "JAX-RS Commons" project to act as an
> umbrella for non-implementation-specific projects. It should be pretty
> straightforward to get something going on java.net. Would sharing
> resources (subversion, bug tracker etc) between a number of projects
> be an issue ?
>
> Failing that I think it would be good if we have an area on the jsr311
> site that points to related projects to make it easy for developers to
> find them.
>
> Marc.
>
> On Jan 30, 2009, at 3:26 PM, Markus KARG wrote:
>
> > Paul,
> >
> > thank you for frankly describing the facts. Yes it is true, I
> > incorrectly understood what the Jersey projects' target is when
> > reading about all the existing contribs.
> >
> > Now it is clear, and also is the future of my WebDAV code. I will
> > restart it as a standalone project in the next days. After due
> > consideration of all pros and cons, it seems I have to abstain from
> > all that really good-looking vantages that would arise from staying
> > a part of the Jersey project, like the marketing aspects, the
> > implied downloads and distribution, and the GlassFish integration.
> > That all is really great and it pains to abstain from that. But from
> > my innermost belief in what is the best for the WebDAV code and its
> > potential users, it does not outweigh the negative side effects that
> > it would have and in part have been mentioned in you posting.
> >
> > I am really thankful for all the help I received in the past, and
> > as thankful I will also be in future for your offer to still help us
> > even after a split and for the permission to use the Jersey mailing
> > list. Actually I am convinced that the WebDAV code WILL be part of
> > Jersey in some form in future, but just in a different form, not
> > being a synchronized module but an independent, bundled third-party
> > JAR or alike; we just have to find the technical form that will
> > allow this, and maybe in some months you find the time to workout
> > the details of some glue code together with me. I do not see that
> > being a separate project circumvents this, since obviously Jersey
> > already is using other third party binaries already (like JAXB for
> > example).
> >
> > Also I want to express explicitly that my decision has nothing to do
> > with any person or comment in this mailing list. You all are very
> > kind and this decision really is purely basing on the different
> > targets that our projects do have. I tell this because in the past
> > there was a similar situation in a different open source project and
> > I want to prevent people from thinking I cannot work with them or
> > something (After founding and leading a project for many months I
> > had to yield leadership to another person due to family commitments;
> > since there had been some disputes before, people thought I did it
> > for personal dislikes or something).
> >
> > As soon as I have set up the new location, I'll let you know,
> > certainly. BTW, you all are invited to join. :-)
> >
> > Thanks a lot, and have a great time!
> > Markus
> >
> > From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> > Sent: Freitag, 30. Januar 2009 10:38
> > To: dev_at_jersey.dev.java.net
> > Subject: Re: [Jersey] WebDAV pom.xml
> >
> > Hi Marcus,
> >
> > Sorry for the late reply and thanks for your understanding.
> >
> > I got the impression, perhaps incorrectly, that you may have thought
> > the Jersey project as something different or expected to be
> > something that it is not.
> >
> > Jersey is not about the hosting of JAX-RS projects with their own
> > development, build and release constraints and ultimately their own
> > identity. Jersey is about the co-ordinated and synchronized
> > development, building, testing, sustaining and releasing of a high-
> > quality JAX-RS implementation and useful extensions be they JAX-RS
> > specific or not.
> >
> > Note that on a practical level we simply do not have the resources
> > to maintain such a hosting environment even if we wanted to
> > (especially one that requires testing and sustaining using multiple
> > JAX-RS implementations).
> >
> > Given that your primary goal is for a cross-platform implementation
> > and marketing of that then being part of Jersey "brand" may actually
> > hinder your progress as Jersey is fundamentally bound to a
> > particular JAX-RS implementation.
> >
> > I think maybe a good solution is for you to create project where you
> > push releases to a maven repository, and Jersey can provide a sample
> > using the WebDAV module (with the version and constraints you have
> > defined) perhaps with other JAX-RS/Jersey features. If you do that
> > then i do not think the WebDAV code needs to be "copied/forked" in
> > some sense and consumed into the Jersey build and release process (i
> > would prefer to avoid such additional integration work and rely on
> > the build, testing releasing performed by the WebDAV project).
> >
> > Of course Craig and I would be very happy if WebDAV is core part of
> > Jersey. One advantage of that is once WebDAV moves into the trunk
> > and stable releases it will get sustained. And, may potentially get
> > distributed with GlassFish (we currently release Jersey to the
> > GlassFish v2/v3 update centers and Jersey will get distributed as
> > part of Glassfish for EE 6). A possible disadvantage is might take
> > longer to reach a stable release with Jersey than as an independent
> > project.
> >
> > Even if you have a separate project i have no objections to you
> > using the Jersey users/dev list for discussions on WebDAV design/
> > development/issues. But, just speaking for myself, i cannot give
> > those discussions a priority over Jersey-specific discussions.
> >
> > So as you say there are pros and cons.
> >
> > Hope that clarifies things a bit: i am trying to be as open as
> > possible within the constraints of what Jersey is.
> >
> > Paul.
> >
> > On Jan 27, 2009, at 6:01 PM, Markus KARG wrote:
> >
> >
> > Paul,
> >
> > thanks for your clarification, maybe I misunderstood some of the
> > arguments (for example, why it shall be any kind of problem that
> > jersey-webdav.jar has a different version number that jersey-
> > core.jar or that it uses another Java SE generation).
> >
> > I have to think about the pros and cons. As I said, being part of
> > the jersey project is nice, but WebDAV shall keep its status of a
> > product that will run on any JAX-RS implementation, this is the
> > topmost priority. Maybe we could do it this way: I develop WebDAV in
> > a separate project with Java SE 6 and its own versioning schema,
> > which you can bundle with Jersey -- or mirror a copy of the my
> > latest release (or any of your choice) in the jersey svn tree which
> > has the exact jersey version number and gets actively checked
> > against Java SE 5 by you (as you have Java SE 5 while I do not)? So
> > the active development of WebDAV and Jersey go with different
> > versioning speed, but both projects can have the latest WebDAV
> > features. Maybe this is the best solution?
> >
> > Regards
> > Markus
> >
> > From: Craig.McClanahan_at_Sun.COM [mailto:Craig.McClanahan_at_Sun.COM]
> > Sent: Montag, 26. Januar 2009 22:23
> > To: dev_at_jersey.dev.java.net
> > Subject: Re: [Jersey] WebDAV pom.xml
> >
> > 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
> > 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
> >
> >
> >
> >
> >
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net