Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of rick.hillegas@oracle.com
 designates 141.146.126.227 as permitted sender)
Message-ID: <4FA2E217.8030308@oracle.com>
Date: Thu, 03 May 2012 12:52:55 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Maven debug and source artifacts for Derby
References: <4F98202A.3010305@oracle.com> <x6wr4tobml.fsf@oracle.com>
In-Reply-To: <x6wr4tobml.fsf@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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