On Jan 17, 2009, at 6:23 PM, Markus KARG wrote:
> Paul,
>
> thank you very much for inspecting the WebDAV pom.xml. Your ideas
> are very
> valueable for the WebDAV project, but some aspects that you
> addressed need
> further discussion. More inlined. :-)
>
>> - you need to keep the version the same as Jersey. That way we keep
>> everything in sync (see later in reference to the sample).
>
> I've chosen a different version for WebDAV to express that it is not
> production ready yet but still under heavy change. Using the same
> version
> than Jersey uses could make people think that it is as mature as
> Jersey
> itself is, what is far away from being the case. Also, this would
> provide
> changing version numbers to WebDAV JAR even in times of no change in
> the
> WebDAV JAR at all, what looks some kind of odd for the user (a
> changing
> version number with an empty change set?). So is this a must, or
> wouldn't
> you agree that the WebDAV JAR lives with its own, independent
> version number
> indicating its actual maturity to the user?
>
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.
>> - all other Jersey modules depend on Java SE 5. Are you using any SE
>> 6 specific features? If so we need to make sure the
>> dependencies are set up correctly for that. I am no maven expert
>> but i not sure the compiler plugin declares such a
>> dependency.
>
> Well, Java SE 6 since lots of months is the "current" version of Java
> available for virtually all operating systems and development
> platforms, and
> with upcoming Java EE 6 (which will be the container around JAX-RS
> and such
> beeing the most essential publication vehicle for JAX-RS), Java SE 6
> is
> enforced to be existing in enterprise environments, too. So all my
> local
> development is made on machines that solely have Java SE 6
> installed. I do
> not own Java SE 5. Or in other words: I do not care about whether I
> _need_
> any Java SE 6 things or not since it is my default, and I just don't
> know
> whether I've actually used them or not, and I do not have any chance
> to
> ensure that it will run on Java SE 5 without adding more capacity to
> the
> WebDAV project (which is beyond of my budget). So from my view, it
> was the
> correct decision of mine to declare that version of Java that I can
> actually
> ensure it compiles and runs fine upon. If I shall change the version
> to 5
> just because Jersey is using this elder JRE, then I must either take
> a lot
> of care each time at development to not use any Java SE 6 feature
> (what is
> weird since in a few months Java EE 6 will be shipped and one big
> advantage
> explicitly is the Java SE 6 foundation), and I must extra test on
> Java SE 5
> in addition to my existing Java SE 6 tests, which is an effort that
> I cannot
> spend. So, if you want WebDAV to work on archaic ;-) JREs in the
> Java SE 6
> age then I want to suggest that you do the extra testing on your
> side, since
> you seem to have a machine that has Java SE 5 installed already and
> will run
> a complete Jersey test suite anyways (so it is no extra effort for
> you).
> See, I just have to keep things profitable on my side, what is no
> more given
> if I have to take extra care for Java SE 5 in addition to donating
> my code
> to the open source community already. So if you say that you will do
> that
> tests and take the expenses that emerge from the extra Java SE 5
> support,
> then tell me and I will reduce the needed version from 6 to 5. If
> not, then
> I will keep it as it is, since I do not see any problems in Maven 2:
> WebDAV
> technically is not bound in any way on Jersey code or its
> dependencies but
> solely on pure JAX-RS and Grizzly, and compiles, tests and runs
> pretty fine
> on Java SE 6, so I do not share your concerns. If _real_ problems
> arise,
> then we can solve it. But there just are none yet, and as soon as
> Java EE 6
> is shipping, you must move to Java SE 6 anyways, since you must
> ensure that
> it runs on Java SE 6 then -- which will be in a few months. I hope you
> understand my concerns, this is just an economic decision as I am
> doing this
> in my very scarce spare time.
>
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.
>> - add java doc dependency. See the contribs/jersey-multpart/pom.xml
>> for use of the "maven-javadoc-plugin".
>
> This is a great idea, which I just committed to SVN. :-)
>
> There are two things to mention here: First, I did not provide the
> groupId,
> since it seems to default to the correct one already. So following
> the idea
> of convention of configuration (one of Maven's core principles as I
> learned
> shortly), adding it seems to be obsolete. If that is not true or
> implies an
> actual failure, please let me know (I am still a Maven learner,
> since I am
> used to ANT for years).
>
> Second, I wonder why this is not added to the parent pom but done in
> each
> single contrib project again? If you like to have it done for all
> projects
> (what makes pretty good sense as javadoc JARs are valueable obviously)
> wouldn't it make more sense to provide this in Jersey's topmost pom?
> (As I
> said, this might be a silly Maven beginner's question).
>
Jakub will know more, he is our Maven guru :-)
>> - observation: other Jersey modules use the com.sun.jersey package
>> name as the base. I have no big issue with using
>> "net.java.dev.jersey" for modules in contrib.
>
> If you have no issue with that, then I will stick with
> net.java.dev.jersey,
> since my code was not developed by Sun Microsystems (com.sun), but
> mostly by
> java.net members (net.java.dev). In fact, from a legal point of
> view, I
> actually think that it would be forbidden that I write my own code
> with
> com.sun since I then use their domain or brand name without written
> permission (only the sun lawyers could allow that; see, I am not a Sun
> employee but just a java.net member and have no rights to write code
> on my
> own decision and use Sun's name inside, even if Sun later
> incorporates it
> into Jersey's SVN trunk -- only Sun may do that, from my legal
> understanding).
>
IANAL but since you signed the SCA i don't think the package name
matters in terms of committing code.
>> - i would prefer to keep the version of the dependent 311 module
>> exact, namely 1.0 rather than 1.0 plus anything else.
>> That we we know for sure what are depending on. Developers can of
>> course change this for their own projects.
>
> The idea of the version range "1.0+" was to always link to the
> latest bug
> fixes. I don't like the idea to link always to exactly 1.0.0 and
> then have
> to change the to 1.0.1 to 1.0.2 all the time imposing SVN revisions
> without
> a code change in WebDAV. As I am assuming that API changes in JAX-RS
> will
> imply at least a minor (1.1.0, 1.2.0) version change, can we agree
> on a
> range that would allow automatic bug fixes but stick with the major
> and
> minor version, e. g. "[1.0, 1.1)"? I fixed that so far in SVN. But
> if you
> insist on "[1.0]" then just tell me and I will change it. :-)
>
>> samples pom.xml
>>
>> - we need to keep the versions of dependency jersey stuff exact, and
>> the same as what it corresponds to for other modules. See the
>> helloworld/pom.xml file. Also for certain dependencies we need to
>> be exact e.g. Grizzly so we know what we test against. Notice the
>> use of ${project.version} which means you do not have to be
>> explicit on the version of the webdav module.
>
> For the version of the sample, I'd suggest to keep it as 1.0-
> SNAPSHOT due to
> the same reason as above. If it is a must, then just tell me.
>
> For the version ranges I suggest the improved range "[1.0, 1.1)" due
> to the
> same justification as above, but just tell me if you insist on exactly
> "[1.0]".
>
> In fact I do not really understand what you mean with "exact": Your
> code
> uses version numbers like "1.0" which as it seems is just a
> suggestion to
> Maven but not a constraint (to write a constraint it must be "[1.0]"
> -- only
> this really prevents usage of different versions in the end, see
> http://maven.apache.org/plugins/maven-enforcer-plugin/rules/versionRanges.ht
> ml: "1.0 means x >= 1.0 * The default Maven meaning for 1.0 is
> everything
> (,) but with 1.0 recommended. Obviously this doesn't work for
> enforcing
> versions here, so it has been redefined as a minimum version."). So
> your
> current code is not exact, too, or we have different interpretation
> of what
> "exact" means and what it shall be good for to use "1.0" instead of
> "[1.0"]". Can you elaborate on this so I can understand what you
> like to
> reach and what I must do in the end? 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.
>> - samples are also required to be assembled as a downloadable zip
>> file, and require unit tests, the other samples
>> can be used as templates for such purposes. The unit tests for
>> samples actually serve as functional tests and ensure that
>> we do not need to manually test before we release.
>
> I have to look what can be provided. As I have scarce time so I
> asked Daniel
> Manzke to contribute a few tests. If he succeeds in providing those,
> maybe
> it is an option to ask him to provide tests for the sample, too. I
> understand that you want to automate the release process, but I have
> to deal
> with the scarce time somehow and like to concentrate my own
> workforce on
> WebDAV itself instead of the surrounding infrastructe. Mabye we have
> to live
> for some time without unit tests until one can provide them. As long
> as I am
> the sole contributor of WebDAV the risk of breaking WebDAV or the
> sample is
> rather low (in the past 25 years it was seldom the case that I broke
> my own
> code, happily).
>
> Thanks for all your ideas, it is very valueable to discuss with
> you. :-)
>
Likewise :-)
Paul.