db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Maven debug and source artifacts for Derby
Date Fri, 04 May 2012 09:40:03 GMT
On 03.05.12 21:52, Rick Hillegas wrote:
> 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.

Hi Rick,

That last statement is certainly valid, but I prefer that we produce the 
artifacts our users need rather than focus too much on keeping the 
number down to a minimum. If the resulting process is too hard on the 
community, and more specifically the release manager, we have to 
simplify it with better scripting/tooling to make it bearable.
Now, actually finding out which artifacts are needed isn't necessarily easy.

Let me explain why I brought up the topic of Maven artifacts:
There are a lot of Maven users out there, and the central Maven 
repository contains a huge amount of software. Further, there are 
several other systems/tools that can integrate with Maven, for instance 
Apache Buildr, Apache Ivy, Groovy Grape, Grails, and Scala SBT.
By having good Maven artifacts for Derby, we make it easier for people 
to use Derby. If it's too hard, and I don't think it takes much to reach 
this state, people may very well simply switch to another database 
system - for new projects with little current investment in Derby that's 
a matter of changing a few dependency definitions.

Apache is all about open-source, communities and involvement.
In my opinion, not distributing a source bundle in Maven makes it harder 
for Maven users to get involved. Not including line numbers in the class 
files makes it harder for someone new to understand what's going on and 
to debug the code ([1]). If their application fails because of Derby, 
seeing the Derby source code on line X, where the NPE happened, may 
convince them that this is indeed a Derby bug and not their own "silly 
mistake". The result may be that we get a JIRA report and can fix a bug.
This isn't about what these users are able to do or not, it's about how 
much effort it takes for them to get involved. Too much effort means no 
involvement ([2]). Derby is only one project out of a large number of 
open-source projects that are fighting for involvement from contributers.
I'm not saying we'll see a flurry of new contributions if we fix these 
issues, but at least we remove some obstacles for those who have a 
little bit of curiosity in them.

Based on your reply I think it would be best to discuss items (2) and 
(3) first. Given that we are getting close to a new release, I'm 
suggesting that we let this discussion live for a while and that we 
don't change anything before 10.9 goes out.

Even if the above means postponing any actions on these topics, people 
are very welcome to present their opinions on these topics.

Kristian, with his community hat on :)

[1] I know we have a source zip and debug bundles on the web site, and I 
know people can access the Subversion repository if they want to. But 
it's more tedious than clicking "Download Sources" in my IDE and 
double-clicking on the class I'm interested in.

[2] I've seen this myself, where I have given up on reporting a 
[potential] bug in a piece of software because I couldn't find the 
information I needed, or because filling out the bug report would take 
me hours...

< snip - lots of points for discussion >

View raw message