On Jan 31, 2009, at 11:35 AM, Markus KARG wrote:
> 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?
>
That would be up to the developers leading the project i.e. it could
be you :-) i would be supportive of such a project.
> 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.
>
OK. Please ping back when you have the project set up.
Paul.
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>