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?
> - 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.
> - 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).
> - 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).
> - 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. :-)
> For the 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,)"...?!
> - 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. :-)
Have Fun
Markus