commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [ALL] Non-standard maven source and test directories
Date Sun, 11 Apr 2010 13:54:55 GMT
Luc Maisonobe wrote:
> Phil Steitz a écrit :
>> Torsten Curdt wrote:
>>>> I think tomcat may still build repackaged versions of dbcp and pool
>>>> classes from source and this change might break their builds.  So -1
>>>> for now for changing those.
>>> As much as I am for cross-project collaboration this reason for a "-1"
>>> takes it a step too far IMO. If they really want to keep using the
>>> repackaged versions (why?)
>> Mark or someone else can confirm, but I think the repackaging is to
>> avoid conflicts between the bundled versions and user-supplied
>> replacements.
>>
>>  they can probably adjust their build within
>>> minutes to work with a new project layout.
>> But why force that?  I see know value to this change from a [pool]
>> or [dbcp] perspective.  What exactly do we gain from it?  I know
>> that tomcat is not the only user who builds classes from these
>> sources from source.  Why force this change on everyone who does
>> that?  If I am missing some benefit other than adhering to a
>> (changed) maven standard, I would like to know what that is.
> 
> I think it is the first time I disagree with you, Phil

I don't think so :)
, I'm sorry for
> that. 

Please never apologize for that.  I am often wrong.

I think going back to accepted standards instead of having our own
> way is good.

Its not so much "having our own way" as implementing change to
adhere to "standards" that I don't see any value in beyond
supporting brittle plugins. That is a side rant issue, so basically
I am agreeing with you on this point.

 People and quality assurance teams often build lots of
> scripts to check source trees, so having a directories tree that is
> similar to trees from other project adds value and remove some burden to
> users.

I get that part.  I have built and maintained these scripts.  I was
 trying to be nice to those who have scripts in place that work with
our sources. Doing work to make work for existing users so new users
can have an easier time can be seen either way.  (See point below on
2.x vs 1.x versions.)

I do agree with Torsten that it is in general beyond reasonable for
users to expect that the structure of our sources will not change.
I did not mean to imply that we should in general try to maintain
backward compatibility wrt source organization (or supported build
tools).  My point was just that I do not personally see enough value
in this particular change to justify *any* work required by users
who have to support it.  Based on what everyone else is saying on
this thread, I see I am in the minority on this, so probably wrong.
> 
> We already did the move for [math], due to some maven plugin (I don't
> remember which one). It was an easy move and nobody complained. I agree
> the users base is smaller than for other commons components, though.
> 
And we did it as part of a move to 2.0, which had lots of other
changes.  Pool and dbcp are much older and trunk is still 1.x.  I
would be happier to postpone this change until 2.x; but I see I am
odd man out on this, so if someone wants to do the work, fully test
all of the builds, I am OK with it - i.e., now just -0.  Please do
it as part of a JIRA though so we don't forget to include mention of
the change in release notes.

Phil
> Luc
> 
>> Phil
>>> cheers
>>> --
>>> Torsten
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message