Thanks for starting this conversation, Kristian. Here's my $0.02:
I see a number of issues here:
1) An impedance mismatch between the Derby and Maven concepts of release
artifacts.
2) The bewildering number of Derby release artifacts today.
3) A request for different Derby release artifacts.
4) A request for a source Maven artifact.
Just to be clear, I think we should try to drive our release process
toward producing fewer artifacts, not more.
------- Impedance Mismatch Between Derby and Maven ----------
For Derby, a release artifact is a zip (or tar) ball containing a
complete system of jar files which cohere with one another. For Maven, a
release artifact is a single jar file which can be mixed and matched
with other jar files at different rev levels. The two world views
diverge at a very high level:
a) For Derby, jar files are children of version numbers
b) For Maven, version numbers are children of jar files
I don't know how we go about bridging this gap. The Maven model allows
for mixing Derby jars from different versions, something which we don't
generally allow. Maybe there is a way in Maven to declare that the
version numbers of derbynet.jar and derby.jar must agree.
------- Bewildering Number of Derby Release Artifacts ----------
IMHO we already produce too many Derby artifacts. Do we really need bin
and lib artifacts? Do we really need zips and tarballs? I'd be happy
with zip-only artifacts representing the following:
i) Source (I believe this is the only artifact required by Apache)
ii) Docs, templates, and demos
iii) Bin (executable code, including jars and shell scripts)
iv) Debug-bin
That's 4 artifacts rather than the 8 we produce today (remember, we're
deprecating the Eclipse bits).
------- Different Derby Artifacts ----------
There's a request to produce an artifact which is half-way between our
bin and debug-bin artifact, viz., executable code which includes line
numbers but no assertions. How much extra value does this add?
I think this would provide extra information for heisenbugs which don't
have repros, but in my experience we don't make much headway on those
bugs, with or without line numbers.
For bugs which have repros, we (the Derby developers who do almost all
of the bug fixing around here) see the line numbers as soon as we run
the repro, because we're all using sane builds in our sandboxes.
So who is this new artifact for? Are there other developers out there
who would be contributing fixes back to the community if we provided an
artifact with line numbers? These would be people who would take the
time to script, debug, and fix an issue. To do this, they would need to
download the source distro or set up a subversion client on one of our
branches. But they wouldn't be willing to download a debug distro.
------- Source Maven Artifacts ----------
I don't have any objection to providing a source Maven artifact for the
purposes described by DERBY-5668. Does the source artifact need to be in
some special format to be usable by IDEs?
Thanks,
-Rick
