Markus, Paul,
please see one comment inline regarding the javadoc plugin....
On Sat, Jan 24, 2009 at 05:58:31PM +0100, Markus KARG wrote:
> 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.
Given that individual modules use different javadoc config,
(look at excludePackageNames option at jersey-core, jersey-server, ...)
it is anyway needed to include the javadoc plugin config in individual
poms. But you might be right there is a chance to consolidate a bit.
Probably mainly in the contribs area, where i did not pay much attention
yet to the poms there.
I will try to have a look at there before the next release and remove possible
redundancies.
~Jakub
>
> > > 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
>