Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 16:56, John Casey  wrote:
>
>
> On 6/13/11 11:06 AM, Stephen Connolly wrote:
>>
>> On 13 June 2011 15:43, John Casey  wrote:
>>>
>>>
>>> On 6/13/11 10:40 AM, Stephen Connolly wrote:
>>>>
>>>> On 13 June 2011 15:36, John Casey    wrote:
>>>>>
>>>>>
>>>>> On 6/13/11 8:45 AM, Stephen Connolly wrote:
>>>>>>
>>>>>> On 13 June 2011 12:48, Benson Margulies
>>>>>>  wrote:
>>>>>>>
>>>>>>> Let's be specific about a few classes.
>>>>>>>
>>>>>>> CollectionUtil has an @author of olamy and an apache notice, so I
>>>>>>> grabbed it rather than try to recreate it.
>>>>>>
>>>>>> did you check the svn log?
>>>>>>
>>>>>>>
>>>>>>> FastMap and CachedMap are grabbed from javolution. We can call the
>>>>>>> current javolution from the bridge.
>>>>>>
>>>>>> That seems fine by me
>>>>>>
>>>>>>>
>>>>>>> StringInputStream and StringOutputStream are deprecated, have an
>>>>>>> Apache 1.1 license, have no obvious author, and known-busted. They
>>>>>>> are
>>>>>>> also so trivial that I claim that copying their source for interim
>>>>>>> compatibility is harmless, given the license notice.
>>>>>>>
>>>>>>
>>>>>> OK, if we have tests.
>>>>>>
>>>>>>> StringUtils is a large collection of fiddly functions. Again, an
>>>>>>> Apache license, and a claim of provenance from Apache Turbine. Do we
>>>>>>> really need to recreate it due to license considerations?
>>>>>>
>>>>>> Can we copy the turbine code instead?
>>>>>
>>>>> I've been trying for some time now to wean myself off of plexus-utils'
>>>>> StringUtils class using commons-lang, and it works pretty well. I think
>>>>> it'd
>>>>> be pretty easy to provide some sort of remapping/redirection
>>>>> implementation
>>>>> of plexus-utils StringUtils ->    commons-lang StringUtils.
>>>>
>>>> That is what a Shim layer is supposed to be.
>>>>
>>>> The JVM will inline the calls anyway once you are up and running a few
>>>> minutes
>>>>
>>>> Have a look at the shim layer I created for IOUtil
>>>>
>>>> The only extras in that shim are that I have the reproduce plexus bugs
>>>> switch set for reproducing them... once I throw the switch for IOUtil
>>>> then the shim will reduce down to straight calls of IOUtils from
>>>> commons.
>>>
>>> Sure, my only point was that it'll probably be relatively easy to write
>>> the
>>> shim for p-u StringUtils
>>
>> Cool... when will you have it done ;-)
>
> I can work on it, if you all can be patient...I've got back-burner projects
> for my back-burner projects ATM. ;-)

I have back burner projects for my back burner projects' back-burner
projects ;-) so I hear you!

>
>>
>>>>
>>>>>
>>>>> Just FWIW.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>>>>>>> If nothing else, Herve could commit a copy of it to the sandbox and
>>>>>>> we'd be good to go.
>>>>>>
>>>>>> Lets see if Hervé will cooperate ;-)
>>>>>>
>>>>>>>
>>>>>>> SweeperPool: does anything use this? It would be somewhat scary to
>>>>>>> recreate.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>>>>>>       wrote:
>>>>>>>>
>>>>>>>> It's tempting... but I fear all that will happen is nobody will
>>>>>>>> switch
>>>>>>>> to the new impl...
>>>>>>>>
>>>>>>>> the WHOLE point of this bridge is to remove any depen

Re: Truly awful code in plexus...

[John Casey]

On 6/13/11 11:06 AM, Stephen Connolly wrote:

On 13 June 2011 15:43, John Casey  wrote:



On 6/13/11 10:40 AM, Stephen Connolly wrote:


On 13 June 2011 15:36, John Caseywrote:



On 6/13/11 8:45 AM, Stephen Connolly wrote:


On 13 June 2011 12:48, Benson Margulies  wrote:


Let's be specific about a few classes.

CollectionUtil has an @author of olamy and an apache notice, so I
grabbed it rather than try to recreate it.


did you check the svn log?



FastMap and CachedMap are grabbed from javolution. We can call the
current javolution from the bridge.


That seems fine by me



StringInputStream and StringOutputStream are deprecated, have an
Apache 1.1 license, have no obvious author, and known-busted. They are
also so trivial that I claim that copying their source for interim
compatibility is harmless, given the license notice.



OK, if we have tests.


StringUtils is a large collection of fiddly functions. Again, an
Apache license, and a claim of provenance from Apache Turbine. Do we
really need to recreate it due to license considerations?


Can we copy the turbine code instead?


I've been trying for some time now to wean myself off of plexus-utils'
StringUtils class using commons-lang, and it works pretty well. I think
it'd
be pretty easy to provide some sort of remapping/redirection
implementation
of plexus-utils StringUtils ->commons-lang StringUtils.


That is what a Shim layer is supposed to be.

The JVM will inline the calls anyway once you are up and running a few
minutes

Have a look at the shim layer I created for IOUtil

The only extras in that shim are that I have the reproduce plexus bugs
switch set for reproducing them... once I throw the switch for IOUtil
then the shim will reduce down to straight calls of IOUtils from
commons.


Sure, my only point was that it'll probably be relatively easy to write the
shim for p-u StringUtils


Cool... when will you have it done ;-)


I can work on it, if you all can be patient...I've got back-burner 
projects for my back-burner projects ATM. ;-)








Just FWIW.





ReaderFactory: has an Apache notice, a Maven committer's name on it.
If nothing else, Herve could commit a copy of it to the sandbox and
we'd be good to go.


Lets see if Hervé will cooperate ;-)



SweeperPool: does anything use this? It would be somewhat scary to
recreate.






On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
  wrote:


It's tempting... but I fear all that will happen is nobody will switch
to the new impl...

the WHOLE point of this bridge is to remove any dependency on
plexus-utils in core... and how we class-load plexus-utils is IIRC
that we force the core version on all plugins no matter what they
use... so if we remove a deprecated method and a plugin is expecting
it then that plugin breaks.

On 13 June 2011 10:41, Mark Struberg  wrote:


Hi!

If those methods are already deprecated, then I'd say we should drop
them now.

Most times those methods didn't got deprecated because they are
'unpretty' but because they are seriously flawed. Like missing
encoding
parameter, missing timezone, not multithreading capable, etc.

So if those methods are deprecated for more than a year now (or<
  maven-2.2.1 and maven-3.0), then I'd say lets drop them now.

LieGrue,
strub

--- On Mon, 6/13/11, Stephen
Connolly
  wrote:


From: Stephen Connolly
Subject: Re: Truly awful code in plexus...
To: "Maven Developers List"
Date: Monday, June 13, 2011, 5:55 AM
if we knew the provenance of the
plexus code, yes... but we don't

- Stephen

---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 13 Jun 2011 00:12, "Benson Margulies"
wrote:


If we want to keep the broken behavior of these


already @Deprecated


classes, then I'd think we'd just copy them wholesale


from plexus to


the bridge. There's no advantage in replacing an old


broken version


with a new broken, and they're already deprecated, and


the right thing


to do to callers is to make them use modern methods.

On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly



wrote:


thanks

- Stephen

---
Sent from my Android phone, so random spelling


mistakes, random nonsense


words and other nonsense are a direct result of


using swype to type on
the


screen
On 12 Jun 2011 23:25, "Hervé BOUTEMY"


wrote:


strategy added in the proposal [1], for future


reference


Regards,

Hervé

[1]





https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement


Le lundi 13 juin 2011, Stephen Connolly a


écrit :


here is my thoughts, for first release we


need to have a drop in


replacement that works exactly the same as


the original... that gives
us


a


way to kill the old version (otherwise


people will just say, "I'm not


going to f

Re: Truly awful code in plexus...

[Benson Margulies]

My thought exactly!

On Mon, Jun 13, 2011 at 11:06 AM, Stephen Connolly
 wrote:
> On 13 June 2011 15:43, John Casey  wrote:
>>
>>
>> On 6/13/11 10:40 AM, Stephen Connolly wrote:
>>>
>>> On 13 June 2011 15:36, John Casey  wrote:
>>>>
>>>>
>>>> On 6/13/11 8:45 AM, Stephen Connolly wrote:
>>>>>
>>>>> On 13 June 2011 12:48, Benson Margulies    wrote:
>>>>>>
>>>>>> Let's be specific about a few classes.
>>>>>>
>>>>>> CollectionUtil has an @author of olamy and an apache notice, so I
>>>>>> grabbed it rather than try to recreate it.
>>>>>
>>>>> did you check the svn log?
>>>>>
>>>>>>
>>>>>> FastMap and CachedMap are grabbed from javolution. We can call the
>>>>>> current javolution from the bridge.
>>>>>
>>>>> That seems fine by me
>>>>>
>>>>>>
>>>>>> StringInputStream and StringOutputStream are deprecated, have an
>>>>>> Apache 1.1 license, have no obvious author, and known-busted. They are
>>>>>> also so trivial that I claim that copying their source for interim
>>>>>> compatibility is harmless, given the license notice.
>>>>>>
>>>>>
>>>>> OK, if we have tests.
>>>>>
>>>>>> StringUtils is a large collection of fiddly functions. Again, an
>>>>>> Apache license, and a claim of provenance from Apache Turbine. Do we
>>>>>> really need to recreate it due to license considerations?
>>>>>
>>>>> Can we copy the turbine code instead?
>>>>
>>>> I've been trying for some time now to wean myself off of plexus-utils'
>>>> StringUtils class using commons-lang, and it works pretty well. I think
>>>> it'd
>>>> be pretty easy to provide some sort of remapping/redirection
>>>> implementation
>>>> of plexus-utils StringUtils ->  commons-lang StringUtils.
>>>
>>> That is what a Shim layer is supposed to be.
>>>
>>> The JVM will inline the calls anyway once you are up and running a few
>>> minutes
>>>
>>> Have a look at the shim layer I created for IOUtil
>>>
>>> The only extras in that shim are that I have the reproduce plexus bugs
>>> switch set for reproducing them... once I throw the switch for IOUtil
>>> then the shim will reduce down to straight calls of IOUtils from
>>> commons.
>>
>> Sure, my only point was that it'll probably be relatively easy to write the
>> shim for p-u StringUtils
>
> Cool... when will you have it done ;-)
>
>>>
>>>>
>>>> Just FWIW.
>>>>
>>>>>
>>>>>>
>>>>>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>>>>>> If nothing else, Herve could commit a copy of it to the sandbox and
>>>>>> we'd be good to go.
>>>>>
>>>>> Lets see if Hervé will cooperate ;-)
>>>>>
>>>>>>
>>>>>> SweeperPool: does anything use this? It would be somewhat scary to
>>>>>> recreate.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>>>>>     wrote:
>>>>>>>
>>>>>>> It's tempting... but I fear all that will happen is nobody will switch
>>>>>>> to the new impl...
>>>>>>>
>>>>>>> the WHOLE point of this bridge is to remove any dependency on
>>>>>>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>>>>>>> that we force the core version on all plugins no matter what they
>>>>>>> use... so if we remove a deprecated method and a plugin is expecting
>>>>>>> it then that plugin breaks.
>>>>>>>
>>>>>>> On 13 June 2011 10:41, Mark Struberg    wrote:
>>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> If those methods are already deprecated, then I'd say we should drop
>>>>>>>> them now.
>>>>>>>>
>&

Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 15:43, John Casey  wrote:
>
>
> On 6/13/11 10:40 AM, Stephen Connolly wrote:
>>
>> On 13 June 2011 15:36, John Casey  wrote:
>>>
>>>
>>> On 6/13/11 8:45 AM, Stephen Connolly wrote:
>>>>
>>>> On 13 June 2011 12:48, Benson Margulies    wrote:
>>>>>
>>>>> Let's be specific about a few classes.
>>>>>
>>>>> CollectionUtil has an @author of olamy and an apache notice, so I
>>>>> grabbed it rather than try to recreate it.
>>>>
>>>> did you check the svn log?
>>>>
>>>>>
>>>>> FastMap and CachedMap are grabbed from javolution. We can call the
>>>>> current javolution from the bridge.
>>>>
>>>> That seems fine by me
>>>>
>>>>>
>>>>> StringInputStream and StringOutputStream are deprecated, have an
>>>>> Apache 1.1 license, have no obvious author, and known-busted. They are
>>>>> also so trivial that I claim that copying their source for interim
>>>>> compatibility is harmless, given the license notice.
>>>>>
>>>>
>>>> OK, if we have tests.
>>>>
>>>>> StringUtils is a large collection of fiddly functions. Again, an
>>>>> Apache license, and a claim of provenance from Apache Turbine. Do we
>>>>> really need to recreate it due to license considerations?
>>>>
>>>> Can we copy the turbine code instead?
>>>
>>> I've been trying for some time now to wean myself off of plexus-utils'
>>> StringUtils class using commons-lang, and it works pretty well. I think
>>> it'd
>>> be pretty easy to provide some sort of remapping/redirection
>>> implementation
>>> of plexus-utils StringUtils ->  commons-lang StringUtils.
>>
>> That is what a Shim layer is supposed to be.
>>
>> The JVM will inline the calls anyway once you are up and running a few
>> minutes
>>
>> Have a look at the shim layer I created for IOUtil
>>
>> The only extras in that shim are that I have the reproduce plexus bugs
>> switch set for reproducing them... once I throw the switch for IOUtil
>> then the shim will reduce down to straight calls of IOUtils from
>> commons.
>
> Sure, my only point was that it'll probably be relatively easy to write the
> shim for p-u StringUtils

Cool... when will you have it done ;-)

>>
>>>
>>> Just FWIW.
>>>
>>>>
>>>>>
>>>>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>>>>> If nothing else, Herve could commit a copy of it to the sandbox and
>>>>> we'd be good to go.
>>>>
>>>> Lets see if Hervé will cooperate ;-)
>>>>
>>>>>
>>>>> SweeperPool: does anything use this? It would be somewhat scary to
>>>>> recreate.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>>>>     wrote:
>>>>>>
>>>>>> It's tempting... but I fear all that will happen is nobody will switch
>>>>>> to the new impl...
>>>>>>
>>>>>> the WHOLE point of this bridge is to remove any dependency on
>>>>>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>>>>>> that we force the core version on all plugins no matter what they
>>>>>> use... so if we remove a deprecated method and a plugin is expecting
>>>>>> it then that plugin breaks.
>>>>>>
>>>>>> On 13 June 2011 10:41, Mark Struberg    wrote:
>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> If those methods are already deprecated, then I'd say we should drop
>>>>>>> them now.
>>>>>>>
>>>>>>> Most times those methods didn't got deprecated because they are
>>>>>>> 'unpretty' but because they are seriously flawed. Like missing
>>>>>>> encoding
>>>>>>> parameter, missing timezone, not multithreading capable, etc.
>>>>>>>
>>>>>>> So if those methods are deprecated for more than a year now (or<
>>>>>>>  maven-2.2.1 and maven

Re: Truly awful code in plexus...

[John Casey]

On 6/13/11 10:40 AM, Stephen Connolly wrote:

On 13 June 2011 15:36, John Casey  wrote:



On 6/13/11 8:45 AM, Stephen Connolly wrote:


On 13 June 2011 12:48, Benson Margulieswrote:


Let's be specific about a few classes.

CollectionUtil has an @author of olamy and an apache notice, so I
grabbed it rather than try to recreate it.


did you check the svn log?



FastMap and CachedMap are grabbed from javolution. We can call the
current javolution from the bridge.


That seems fine by me



StringInputStream and StringOutputStream are deprecated, have an
Apache 1.1 license, have no obvious author, and known-busted. They are
also so trivial that I claim that copying their source for interim
compatibility is harmless, given the license notice.



OK, if we have tests.


StringUtils is a large collection of fiddly functions. Again, an
Apache license, and a claim of provenance from Apache Turbine. Do we
really need to recreate it due to license considerations?


Can we copy the turbine code instead?


I've been trying for some time now to wean myself off of plexus-utils'
StringUtils class using commons-lang, and it works pretty well. I think it'd
be pretty easy to provide some sort of remapping/redirection implementation
of plexus-utils StringUtils ->  commons-lang StringUtils.


That is what a Shim layer is supposed to be.

The JVM will inline the calls anyway once you are up and running a few minutes

Have a look at the shim layer I created for IOUtil

The only extras in that shim are that I have the reproduce plexus bugs
switch set for reproducing them... once I throw the switch for IOUtil
then the shim will reduce down to straight calls of IOUtils from
commons.


Sure, my only point was that it'll probably be relatively easy to write 
the shim for p-u StringUtils




Just FWIW.





ReaderFactory: has an Apache notice, a Maven committer's name on it.
If nothing else, Herve could commit a copy of it to the sandbox and
we'd be good to go.


Lets see if Hervé will cooperate ;-)



SweeperPool: does anything use this? It would be somewhat scary to
recreate.






On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
wrote:


It's tempting... but I fear all that will happen is nobody will switch
to the new impl...

the WHOLE point of this bridge is to remove any dependency on
plexus-utils in core... and how we class-load plexus-utils is IIRC
that we force the core version on all plugins no matter what they
use... so if we remove a deprecated method and a plugin is expecting
it then that plugin breaks.

On 13 June 2011 10:41, Mark Strubergwrote:


Hi!

If those methods are already deprecated, then I'd say we should drop
them now.

Most times those methods didn't got deprecated because they are
'unpretty' but because they are seriously flawed. Like missing encoding
parameter, missing timezone, not multithreading capable, etc.

So if those methods are deprecated for more than a year now (or<
  maven-2.2.1 and maven-3.0), then I'd say lets drop them now.

LieGrue,
strub

--- On Mon, 6/13/11, Stephen Connolly
  wrote:


From: Stephen Connolly
Subject: Re: Truly awful code in plexus...
To: "Maven Developers List"
Date: Monday, June 13, 2011, 5:55 AM
if we knew the provenance of the
plexus code, yes... but we don't

- Stephen

---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 13 Jun 2011 00:12, "Benson Margulies"
wrote:


If we want to keep the broken behavior of these


already @Deprecated


classes, then I'd think we'd just copy them wholesale


from plexus to


the bridge. There's no advantage in replacing an old


broken version


with a new broken, and they're already deprecated, and


the right thing


to do to callers is to make them use modern methods.

On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly



wrote:


thanks

- Stephen

---
Sent from my Android phone, so random spelling


mistakes, random nonsense


words and other nonsense are a direct result of


using swype to type on
the


screen
On 12 Jun 2011 23:25, "Hervé BOUTEMY"


wrote:


strategy added in the proposal [1], for future


reference


Regards,

Hervé

[1]




https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement


Le lundi 13 juin 2011, Stephen Connolly a


écrit :


here is my thoughts, for first release we


need to have a drop in


replacement that works exactly the same as


the original... that gives
us


a


way to kill the old version (otherwise


people will just say, "I'm not


going to fix my code when it works fine


with plexus utils... ok maybe


I'll


fix it later")

we will mark every method and class in the


bridge as deprecated, but we


need the recommendations for each


replacement to put in the deprecated


tags.

for the se

Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 15:36, John Casey  wrote:
>
>
> On 6/13/11 8:45 AM, Stephen Connolly wrote:
>>
>> On 13 June 2011 12:48, Benson Margulies  wrote:
>>>
>>> Let's be specific about a few classes.
>>>
>>> CollectionUtil has an @author of olamy and an apache notice, so I
>>> grabbed it rather than try to recreate it.
>>
>> did you check the svn log?
>>
>>>
>>> FastMap and CachedMap are grabbed from javolution. We can call the
>>> current javolution from the bridge.
>>
>> That seems fine by me
>>
>>>
>>> StringInputStream and StringOutputStream are deprecated, have an
>>> Apache 1.1 license, have no obvious author, and known-busted. They are
>>> also so trivial that I claim that copying their source for interim
>>> compatibility is harmless, given the license notice.
>>>
>>
>> OK, if we have tests.
>>
>>> StringUtils is a large collection of fiddly functions. Again, an
>>> Apache license, and a claim of provenance from Apache Turbine. Do we
>>> really need to recreate it due to license considerations?
>>
>> Can we copy the turbine code instead?
>
> I've been trying for some time now to wean myself off of plexus-utils'
> StringUtils class using commons-lang, and it works pretty well. I think it'd
> be pretty easy to provide some sort of remapping/redirection implementation
> of plexus-utils StringUtils -> commons-lang StringUtils.

That is what a Shim layer is supposed to be.

The JVM will inline the calls anyway once you are up and running a few minutes

Have a look at the shim layer I created for IOUtil

The only extras in that shim are that I have the reproduce plexus bugs
switch set for reproducing them... once I throw the switch for IOUtil
then the shim will reduce down to straight calls of IOUtils from
commons.

>
> Just FWIW.
>
>>
>>>
>>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>>> If nothing else, Herve could commit a copy of it to the sandbox and
>>> we'd be good to go.
>>
>> Lets see if Hervé will cooperate ;-)
>>
>>>
>>> SweeperPool: does anything use this? It would be somewhat scary to
>>> recreate.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>>   wrote:
>>>>
>>>> It's tempting... but I fear all that will happen is nobody will switch
>>>> to the new impl...
>>>>
>>>> the WHOLE point of this bridge is to remove any dependency on
>>>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>>>> that we force the core version on all plugins no matter what they
>>>> use... so if we remove a deprecated method and a plugin is expecting
>>>> it then that plugin breaks.
>>>>
>>>> On 13 June 2011 10:41, Mark Struberg  wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> If those methods are already deprecated, then I'd say we should drop
>>>>> them now.
>>>>>
>>>>> Most times those methods didn't got deprecated because they are
>>>>> 'unpretty' but because they are seriously flawed. Like missing encoding
>>>>> parameter, missing timezone, not multithreading capable, etc.
>>>>>
>>>>> So if those methods are deprecated for more than a year now (or<
>>>>>  maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>> --- On Mon, 6/13/11, Stephen Connolly
>>>>>  wrote:
>>>>>
>>>>>> From: Stephen Connolly
>>>>>> Subject: Re: Truly awful code in plexus...
>>>>>> To: "Maven Developers List"
>>>>>> Date: Monday, June 13, 2011, 5:55 AM
>>>>>> if we knew the provenance of the
>>>>>> plexus code, yes... but we don't
>>>>>>
>>>>>> - Stephen
>>>>>>
>>>>>> ---
>>>>>> Sent from my Android phone, so random spelling mistakes,
>>>>>> random nonsense
>>>>>> words and other nonsense are a direct result of using swype
>>>>>> to type on the
>>>>>> screen
>>>>>> On 13 Jun 2011 00:12, "Benson Margulies"
>>>>>> wrote:
&

Re: Truly awful code in plexus...

[John Casey]

On 6/13/11 8:45 AM, Stephen Connolly wrote:

On 13 June 2011 12:48, Benson Margulies  wrote:

Let's be specific about a few classes.

CollectionUtil has an @author of olamy and an apache notice, so I
grabbed it rather than try to recreate it.


did you check the svn log?



FastMap and CachedMap are grabbed from javolution. We can call the
current javolution from the bridge.


That seems fine by me



StringInputStream and StringOutputStream are deprecated, have an
Apache 1.1 license, have no obvious author, and known-busted. They are
also so trivial that I claim that copying their source for interim
compatibility is harmless, given the license notice.



OK, if we have tests.


StringUtils is a large collection of fiddly functions. Again, an
Apache license, and a claim of provenance from Apache Turbine. Do we
really need to recreate it due to license considerations?


Can we copy the turbine code instead?


I've been trying for some time now to wean myself off of plexus-utils' 
StringUtils class using commons-lang, and it works pretty well. I think 
it'd be pretty easy to provide some sort of remapping/redirection 
implementation of plexus-utils StringUtils -> commons-lang StringUtils.


Just FWIW.





ReaderFactory: has an Apache notice, a Maven committer's name on it.
If nothing else, Herve could commit a copy of it to the sandbox and
we'd be good to go.


Lets see if Hervé will cooperate ;-)



SweeperPool: does anything use this? It would be somewhat scary to recreate.






On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
  wrote:

It's tempting... but I fear all that will happen is nobody will switch
to the new impl...

the WHOLE point of this bridge is to remove any dependency on
plexus-utils in core... and how we class-load plexus-utils is IIRC
that we force the core version on all plugins no matter what they
use... so if we remove a deprecated method and a plugin is expecting
it then that plugin breaks.

On 13 June 2011 10:41, Mark Struberg  wrote:

Hi!

If those methods are already deprecated, then I'd say we should drop them now.

Most times those methods didn't got deprecated because they are 'unpretty' but 
because they are seriously flawed. Like missing encoding parameter, missing 
timezone, not multithreading capable, etc.

So if those methods are deprecated for more than a year now (or<  maven-2.2.1 
and maven-3.0), then I'd say lets drop them now.

LieGrue,
strub

--- On Mon, 6/13/11, Stephen Connolly  wrote:


From: Stephen Connolly
Subject: Re: Truly awful code in plexus...
To: "Maven Developers List"
Date: Monday, June 13, 2011, 5:55 AM
if we knew the provenance of the
plexus code, yes... but we don't

- Stephen

---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 13 Jun 2011 00:12, "Benson Margulies"
wrote:

If we want to keep the broken behavior of these

already @Deprecated

classes, then I'd think we'd just copy them wholesale

from plexus to

the bridge. There's no advantage in replacing an old

broken version

with a new broken, and they're already deprecated, and

the right thing

to do to callers is to make them use modern methods.

On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly


wrote:

thanks

- Stephen

---
Sent from my Android phone, so random spelling

mistakes, random nonsense

words and other nonsense are a direct result of

using swype to type on
the

screen
On 12 Jun 2011 23:25, "Hervé BOUTEMY"

wrote:

strategy added in the proposal [1], for future

reference


Regards,

Hervé

[1]



https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement


Le lundi 13 juin 2011, Stephen Connolly a

écrit :

here is my thoughts, for first release we

need to have a drop in

replacement that works exactly the same as

the original... that gives
us

a

way to kill the old version (otherwise

people will just say, "I'm not

going to fix my code when it works fine

with plexus utils... ok maybe

I'll

fix it later")

we will mark every method and class in the

bridge as deprecated, but we

need the recommendations for each

replacement to put in the deprecated

tags.

for the second release we flip the

@reproducesplexusbug rule and fix
all

those test cases

for the third release, everything is

deprecated


- Stephen

---
Sent from my Android phone, so random

spelling mistakes, random
nonsense

words and other nonsense are a direct

result of using swype to type on

the

screen
On 12 Jun 2011 21:24, "Benson Margulies"


wrote:





-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org







---

Re: Truly awful code in plexus...

[Stephen Connolly]

Lets get a list of the cases we want to copy. keep the list in the
wiki page, and when we have the full list we will review.

On 13 June 2011 14:45, Benson Margulies  wrote:
> Keep in mind that I am not proposing that we bulk-copy from the plexus
> code. I'm proposing that for classes where (1) there's no drop-in
> replacement from commons, (2) they are labelled with a Apache license,
> and (3) they are small and hard to recreate without effectively
> copying them, that we take them without complex analysis of
> provenance.
>
> I'm happy to open a ticket if anyone would prefer backup, and I'm
> happy to shut up if a consensus exists already not to do this.
>
>
>
>
> On Mon, Jun 13, 2011 at 9:25 AM, Mark Struberg  wrote:
>> Well, from the legal pov we are on the safe side because the sources we took 
>> the code from are ALv2. If this ALv2 license tag is not appropriate then we 
>> are still on the safe side and no one could sue us!
>>
>> The only thing we would need to do in this case is that we'd have to rewrite 
>> those tiny fractions where a 3rd party could clearly prove his ownership! So 
>> in practice there is imo a kind of reversal of evidence in place thus it's 
>> 'pretty' safe to use that code. Especially since this code is already in the 
>> public domain since many years with the ALv2 sticker on it...
>>
>> LieGrue,
>> strub
>>
>> --- On Mon, 6/13/11, Benson Margulies  wrote:
>>
>>> From: Benson Margulies 
>>> Subject: Re: Truly awful code in plexus...
>>> To: "Maven Developers List" 
>>> Date: Monday, June 13, 2011, 1:15 PM
>>> Mark,
>>>
>>> I think it appropriate to mix in the scale. I bet you that
>>> if we
>>> opened a ticket on legal-discuss that said, 'there's a
>>> 50-line java
>>> source file with an Apache license sitting at Codehaus, can
>>> we
>>> incorporate it?' that the answer would be yes.
>>>
>>> If someone then wanted to show up and specifically claim
>>> copyright and
>>> that the licence notice was a usurpation, well, something
>>> would
>>> happen.
>>>
>>> I'd open the ticket before I'd spend time recoding very
>>> simple classes
>>> where the original author might well claim copyright
>>> infringement of
>>> any version we came up with anyway.
>>>
>>> --benson
>>>
>>>
>>> On Mon, Jun 13, 2011 at 9:03 AM, Mark Struberg 
>>> wrote:
>>> > I think there are 2 sides of the story.
>>> > If you know who applied the ALv2 license to the code
>>> in question, then you're fine.
>>> > If you don't have any provenance then you better back
>>> off from taking the sources.
>>> >
>>> > I think it's pretty safe to take ALv2 licensed sources
>>> from codehaus.org Plexus project, since all the history is
>>> available and 80% of the committers are Apache committers
>>> (with an iCLA on file) anyway.
>>> >
>>> > LieGrue,
>>> > strub
>>> >
>>> > --- On Mon, 6/13/11, Benson Margulies 
>>> wrote:
>>> >
>>> >> From: Benson Margulies 
>>> >> Subject: Re: Truly awful code in plexus...
>>> >> To: "Maven Developers List" 
>>> >> Date: Monday, June 13, 2011, 12:54 PM
>>> >> There's an IP principle that is
>>> >> escaping me here.
>>> >>
>>> >> According to the previous answered legal questions
>>> page, as
>>> >> I read it,
>>> >> if you find a small amount of source anywhere, and
>>> it has
>>> >> an Apache
>>> >> license notice on it, you can incorporate it into
>>> an Apache
>>> >> project
>>> >> without any further research into provenance.
>>> This
>>> >> discussion seems to
>>> >> be predicated on a stricter policy, or perhaps on
>>> some
>>> >> particular
>>> >> reason to think that someone grabbed what didn't
>>> belong to
>>> >> them,
>>> >> slapped an Apache notice on it, and committed it
>>> to this
>>> >> project.
>>> >>
>>> >> ?
>>> >>
>>> >>
>>> >> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy
>>> 
>>> >> wrote:
>>&g

Re: Truly awful code in plexus...

[Benson Margulies]

Keep in mind that I am not proposing that we bulk-copy from the plexus
code. I'm proposing that for classes where (1) there's no drop-in
replacement from commons, (2) they are labelled with a Apache license,
and (3) they are small and hard to recreate without effectively
copying them, that we take them without complex analysis of
provenance.

I'm happy to open a ticket if anyone would prefer backup, and I'm
happy to shut up if a consensus exists already not to do this.




On Mon, Jun 13, 2011 at 9:25 AM, Mark Struberg  wrote:
> Well, from the legal pov we are on the safe side because the sources we took 
> the code from are ALv2. If this ALv2 license tag is not appropriate then we 
> are still on the safe side and no one could sue us!
>
> The only thing we would need to do in this case is that we'd have to rewrite 
> those tiny fractions where a 3rd party could clearly prove his ownership! So 
> in practice there is imo a kind of reversal of evidence in place thus it's 
> 'pretty' safe to use that code. Especially since this code is already in the 
> public domain since many years with the ALv2 sticker on it...
>
> LieGrue,
> strub
>
> --- On Mon, 6/13/11, Benson Margulies  wrote:
>
>> From: Benson Margulies 
>> Subject: Re: Truly awful code in plexus...
>> To: "Maven Developers List" 
>> Date: Monday, June 13, 2011, 1:15 PM
>> Mark,
>>
>> I think it appropriate to mix in the scale. I bet you that
>> if we
>> opened a ticket on legal-discuss that said, 'there's a
>> 50-line java
>> source file with an Apache license sitting at Codehaus, can
>> we
>> incorporate it?' that the answer would be yes.
>>
>> If someone then wanted to show up and specifically claim
>> copyright and
>> that the licence notice was a usurpation, well, something
>> would
>> happen.
>>
>> I'd open the ticket before I'd spend time recoding very
>> simple classes
>> where the original author might well claim copyright
>> infringement of
>> any version we came up with anyway.
>>
>> --benson
>>
>>
>> On Mon, Jun 13, 2011 at 9:03 AM, Mark Struberg 
>> wrote:
>> > I think there are 2 sides of the story.
>> > If you know who applied the ALv2 license to the code
>> in question, then you're fine.
>> > If you don't have any provenance then you better back
>> off from taking the sources.
>> >
>> > I think it's pretty safe to take ALv2 licensed sources
>> from codehaus.org Plexus project, since all the history is
>> available and 80% of the committers are Apache committers
>> (with an iCLA on file) anyway.
>> >
>> > LieGrue,
>> > strub
>> >
>> > --- On Mon, 6/13/11, Benson Margulies 
>> wrote:
>> >
>> >> From: Benson Margulies 
>> >> Subject: Re: Truly awful code in plexus...
>> >> To: "Maven Developers List" 
>> >> Date: Monday, June 13, 2011, 12:54 PM
>> >> There's an IP principle that is
>> >> escaping me here.
>> >>
>> >> According to the previous answered legal questions
>> page, as
>> >> I read it,
>> >> if you find a small amount of source anywhere, and
>> it has
>> >> an Apache
>> >> license notice on it, you can incorporate it into
>> an Apache
>> >> project
>> >> without any further research into provenance.
>> This
>> >> discussion seems to
>> >> be predicated on a stricter policy, or perhaps on
>> some
>> >> particular
>> >> reason to think that someone grabbed what didn't
>> belong to
>> >> them,
>> >> slapped an Apache notice on it, and committed it
>> to this
>> >> project.
>> >>
>> >> ?
>> >>
>> >>
>> >> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy
>> 
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > 2011/6/13 Benson Margulies :
>> >> >> Let's be specific about a few classes.
>> >> >>
>> >> >> CollectionUtil has an @author of olamy
>> and an
>> >> apache notice, so I
>> >> >> grabbed it rather than try to recreate
>> it.
>> >> >
>> >> > Doh I don't remember why it's here :-) . In
>> fact not
>> >> sure it was for
>> >> > Maven (maybe written long time ago for
>> continuum )
>>

Re: Truly awful code in plexus...

[Mark Struberg]

Well, from the legal pov we are on the safe side because the sources we took 
the code from are ALv2. If this ALv2 license tag is not appropriate then we are 
still on the safe side and no one could sue us! 

The only thing we would need to do in this case is that we'd have to rewrite 
those tiny fractions where a 3rd party could clearly prove his ownership! So in 
practice there is imo a kind of reversal of evidence in place thus it's 
'pretty' safe to use that code. Especially since this code is already in the 
public domain since many years with the ALv2 sticker on it...

LieGrue,
strub

--- On Mon, 6/13/11, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: Re: Truly awful code in plexus...
> To: "Maven Developers List" 
> Date: Monday, June 13, 2011, 1:15 PM
> Mark,
> 
> I think it appropriate to mix in the scale. I bet you that
> if we
> opened a ticket on legal-discuss that said, 'there's a
> 50-line java
> source file with an Apache license sitting at Codehaus, can
> we
> incorporate it?' that the answer would be yes.
> 
> If someone then wanted to show up and specifically claim
> copyright and
> that the licence notice was a usurpation, well, something
> would
> happen.
> 
> I'd open the ticket before I'd spend time recoding very
> simple classes
> where the original author might well claim copyright
> infringement of
> any version we came up with anyway.
> 
> --benson
> 
> 
> On Mon, Jun 13, 2011 at 9:03 AM, Mark Struberg 
> wrote:
> > I think there are 2 sides of the story.
> > If you know who applied the ALv2 license to the code
> in question, then you're fine.
> > If you don't have any provenance then you better back
> off from taking the sources.
> >
> > I think it's pretty safe to take ALv2 licensed sources
> from codehaus.org Plexus project, since all the history is
> available and 80% of the committers are Apache committers
> (with an iCLA on file) anyway.
> >
> > LieGrue,
> > strub
> >
> > --- On Mon, 6/13/11, Benson Margulies 
> wrote:
> >
> >> From: Benson Margulies 
> >> Subject: Re: Truly awful code in plexus...
> >> To: "Maven Developers List" 
> >> Date: Monday, June 13, 2011, 12:54 PM
> >> There's an IP principle that is
> >> escaping me here.
> >>
> >> According to the previous answered legal questions
> page, as
> >> I read it,
> >> if you find a small amount of source anywhere, and
> it has
> >> an Apache
> >> license notice on it, you can incorporate it into
> an Apache
> >> project
> >> without any further research into provenance.
> This
> >> discussion seems to
> >> be predicated on a stricter policy, or perhaps on
> some
> >> particular
> >> reason to think that someone grabbed what didn't
> belong to
> >> them,
> >> slapped an Apache notice on it, and committed it
> to this
> >> project.
> >>
> >> ?
> >>
> >>
> >> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy
> 
> >> wrote:
> >> > Hello,
> >> >
> >> > 2011/6/13 Benson Margulies :
> >> >> Let's be specific about a few classes.
> >> >>
> >> >> CollectionUtil has an @author of olamy
> and an
> >> apache notice, so I
> >> >> grabbed it rather than try to recreate
> it.
> >> >
> >> > Doh I don't remember why it's here :-) . In
> fact not
> >> sure it was for
> >> > Maven (maybe written long time ago for
> continuum )
> >> >
> >> > Someone know a place where it's used in maven
> source
> >> code ? (sorry as
> >> > usual I have a small memory fooprint :-) )
> >> >
> >> >>
> >> >> FastMap and CachedMap are grabbed from
> javolution.
> >> We can call the
> >> >> current javolution from the bridge.
> >> >>
> >> >> StringInputStream and StringOutputStream
> are
> >> deprecated, have an
> >> >> Apache 1.1 license, have no obvious
> author, and
> >> known-busted. They are
> >> >> also so trivial that I claim that copying
> their
> >> source for interim
> >> >> compatibility is harmless, given the
> license
> >> notice.
> >> >>
> >> >> StringUtils is a large collection of
> fiddly
> >> functions. Again, an
> >> >> Apache li

Re: Truly awful code in plexus...

[Benson Margulies]

Mark,

I think it appropriate to mix in the scale. I bet you that if we
opened a ticket on legal-discuss that said, 'there's a 50-line java
source file with an Apache license sitting at Codehaus, can we
incorporate it?' that the answer would be yes.

If someone then wanted to show up and specifically claim copyright and
that the licence notice was a usurpation, well, something would
happen.

I'd open the ticket before I'd spend time recoding very simple classes
where the original author might well claim copyright infringement of
any version we came up with anyway.

--benson


On Mon, Jun 13, 2011 at 9:03 AM, Mark Struberg  wrote:
> I think there are 2 sides of the story.
> If you know who applied the ALv2 license to the code in question, then you're 
> fine.
> If you don't have any provenance then you better back off from taking the 
> sources.
>
> I think it's pretty safe to take ALv2 licensed sources from codehaus.org 
> Plexus project, since all the history is available and 80% of the committers 
> are Apache committers (with an iCLA on file) anyway.
>
> LieGrue,
> strub
>
> --- On Mon, 6/13/11, Benson Margulies  wrote:
>
>> From: Benson Margulies 
>> Subject: Re: Truly awful code in plexus...
>> To: "Maven Developers List" 
>> Date: Monday, June 13, 2011, 12:54 PM
>> There's an IP principle that is
>> escaping me here.
>>
>> According to the previous answered legal questions page, as
>> I read it,
>> if you find a small amount of source anywhere, and it has
>> an Apache
>> license notice on it, you can incorporate it into an Apache
>> project
>> without any further research into provenance. This
>> discussion seems to
>> be predicated on a stricter policy, or perhaps on some
>> particular
>> reason to think that someone grabbed what didn't belong to
>> them,
>> slapped an Apache notice on it, and committed it to this
>> project.
>>
>> ?
>>
>>
>> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy 
>> wrote:
>> > Hello,
>> >
>> > 2011/6/13 Benson Margulies :
>> >> Let's be specific about a few classes.
>> >>
>> >> CollectionUtil has an @author of olamy and an
>> apache notice, so I
>> >> grabbed it rather than try to recreate it.
>> >
>> > Doh I don't remember why it's here :-) . In fact not
>> sure it was for
>> > Maven (maybe written long time ago for continuum )
>> >
>> > Someone know a place where it's used in maven source
>> code ? (sorry as
>> > usual I have a small memory fooprint :-) )
>> >
>> >>
>> >> FastMap and CachedMap are grabbed from javolution.
>> We can call the
>> >> current javolution from the bridge.
>> >>
>> >> StringInputStream and StringOutputStream are
>> deprecated, have an
>> >> Apache 1.1 license, have no obvious author, and
>> known-busted. They are
>> >> also so trivial that I claim that copying their
>> source for interim
>> >> compatibility is harmless, given the license
>> notice.
>> >>
>> >> StringUtils is a large collection of fiddly
>> functions. Again, an
>> >> Apache license, and a claim of provenance from
>> Apache Turbine. Do we
>> >> really need to recreate it due to license
>> considerations?
>> >>
>> >> ReaderFactory: has an Apache notice, a Maven
>> committer's name on it.
>> >> If nothing else, Herve could commit a copy of it
>> to the sandbox and
>> >> we'd be good to go.
>> >>
>> >> SweeperPool: does anything use this? It would be
>> somewhat scary to recreate.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>> >> 
>> wrote:
>> >>> It's tempting... but I fear all that will
>> happen is nobody will switch
>> >>> to the new impl...
>> >>>
>> >>> the WHOLE point of this bridge is to remove
>> any dependency on
>> >>> plexus-utils in core... and how we class-load
>> plexus-utils is IIRC
>> >>> that we force the core version on all plugins
>> no matter what they
>> >>> use... so if we remove a deprecated method and
>> a plugin is expecting
>> >>> it then that plugin breaks.
>> >>>
>> >>> On 13 June 2011 10:41,

Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 14:03, Mark Struberg  wrote:
> I think there are 2 sides of the story.
> If you know who applied the ALv2 license to the code in question, then you're 
> fine.
> If you don't have any provenance then you better back off from taking the 
> sources.
>
> I think it's pretty safe to take ALv2 licensed sources from codehaus.org 
> Plexus project, since all the history is available and 80% of the committers 
> are Apache committers (with an iCLA on file) anyway.

I'd rather do an svn log and check that the only committers are ones
with an iCLA on file... for thew few cases we find where there is no
iCLA on file we can evaluate them as we find them.

>
> LieGrue,
> strub
>
> --- On Mon, 6/13/11, Benson Margulies  wrote:
>
>> From: Benson Margulies 
>> Subject: Re: Truly awful code in plexus...
>> To: "Maven Developers List" 
>> Date: Monday, June 13, 2011, 12:54 PM
>> There's an IP principle that is
>> escaping me here.
>>
>> According to the previous answered legal questions page, as
>> I read it,
>> if you find a small amount of source anywhere, and it has
>> an Apache
>> license notice on it, you can incorporate it into an Apache
>> project
>> without any further research into provenance. This
>> discussion seems to
>> be predicated on a stricter policy, or perhaps on some
>> particular
>> reason to think that someone grabbed what didn't belong to
>> them,
>> slapped an Apache notice on it, and committed it to this
>> project.
>>
>> ?
>>
>>
>> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy 
>> wrote:
>> > Hello,
>> >
>> > 2011/6/13 Benson Margulies :
>> >> Let's be specific about a few classes.
>> >>
>> >> CollectionUtil has an @author of olamy and an
>> apache notice, so I
>> >> grabbed it rather than try to recreate it.
>> >
>> > Doh I don't remember why it's here :-) . In fact not
>> sure it was for
>> > Maven (maybe written long time ago for continuum )
>> >
>> > Someone know a place where it's used in maven source
>> code ? (sorry as
>> > usual I have a small memory fooprint :-) )
>> >
>> >>
>> >> FastMap and CachedMap are grabbed from javolution.
>> We can call the
>> >> current javolution from the bridge.
>> >>
>> >> StringInputStream and StringOutputStream are
>> deprecated, have an
>> >> Apache 1.1 license, have no obvious author, and
>> known-busted. They are
>> >> also so trivial that I claim that copying their
>> source for interim
>> >> compatibility is harmless, given the license
>> notice.
>> >>
>> >> StringUtils is a large collection of fiddly
>> functions. Again, an
>> >> Apache license, and a claim of provenance from
>> Apache Turbine. Do we
>> >> really need to recreate it due to license
>> considerations?
>> >>
>> >> ReaderFactory: has an Apache notice, a Maven
>> committer's name on it.
>> >> If nothing else, Herve could commit a copy of it
>> to the sandbox and
>> >> we'd be good to go.
>> >>
>> >> SweeperPool: does anything use this? It would be
>> somewhat scary to recreate.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>> >> 
>> wrote:
>> >>> It's tempting... but I fear all that will
>> happen is nobody will switch
>> >>> to the new impl...
>> >>>
>> >>> the WHOLE point of this bridge is to remove
>> any dependency on
>> >>> plexus-utils in core... and how we class-load
>> plexus-utils is IIRC
>> >>> that we force the core version on all plugins
>> no matter what they
>> >>> use... so if we remove a deprecated method and
>> a plugin is expecting
>> >>> it then that plugin breaks.
>> >>>
>> >>> On 13 June 2011 10:41, Mark Struberg 
>> wrote:
>> >>>> Hi!
>> >>>>
>> >>>> If those methods are already deprecated,
>> then I'd say we should drop them now.
>> >>>>
>> >>>> Most times those methods didn't got
>> deprecated because they are 'unpretty' but because they are
>> seriously flawed. Like missing encoding paramet

Re: Truly awful code in plexus...

[Mark Struberg]

I think there are 2 sides of the story. 
If you know who applied the ALv2 license to the code in question, then you're 
fine. 
If you don't have any provenance then you better back off from taking the 
sources.

I think it's pretty safe to take ALv2 licensed sources from codehaus.org Plexus 
project, since all the history is available and 80% of the committers are 
Apache committers (with an iCLA on file) anyway.

LieGrue,
strub 

--- On Mon, 6/13/11, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: Re: Truly awful code in plexus...
> To: "Maven Developers List" 
> Date: Monday, June 13, 2011, 12:54 PM
> There's an IP principle that is
> escaping me here.
> 
> According to the previous answered legal questions page, as
> I read it,
> if you find a small amount of source anywhere, and it has
> an Apache
> license notice on it, you can incorporate it into an Apache
> project
> without any further research into provenance. This
> discussion seems to
> be predicated on a stricter policy, or perhaps on some
> particular
> reason to think that someone grabbed what didn't belong to
> them,
> slapped an Apache notice on it, and committed it to this
> project.
> 
> ?
> 
> 
> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy 
> wrote:
> > Hello,
> >
> > 2011/6/13 Benson Margulies :
> >> Let's be specific about a few classes.
> >>
> >> CollectionUtil has an @author of olamy and an
> apache notice, so I
> >> grabbed it rather than try to recreate it.
> >
> > Doh I don't remember why it's here :-) . In fact not
> sure it was for
> > Maven (maybe written long time ago for continuum )
> >
> > Someone know a place where it's used in maven source
> code ? (sorry as
> > usual I have a small memory fooprint :-) )
> >
> >>
> >> FastMap and CachedMap are grabbed from javolution.
> We can call the
> >> current javolution from the bridge.
> >>
> >> StringInputStream and StringOutputStream are
> deprecated, have an
> >> Apache 1.1 license, have no obvious author, and
> known-busted. They are
> >> also so trivial that I claim that copying their
> source for interim
> >> compatibility is harmless, given the license
> notice.
> >>
> >> StringUtils is a large collection of fiddly
> functions. Again, an
> >> Apache license, and a claim of provenance from
> Apache Turbine. Do we
> >> really need to recreate it due to license
> considerations?
> >>
> >> ReaderFactory: has an Apache notice, a Maven
> committer's name on it.
> >> If nothing else, Herve could commit a copy of it
> to the sandbox and
> >> we'd be good to go.
> >>
> >> SweeperPool: does anything use this? It would be
> somewhat scary to recreate.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
> >> 
> wrote:
> >>> It's tempting... but I fear all that will
> happen is nobody will switch
> >>> to the new impl...
> >>>
> >>> the WHOLE point of this bridge is to remove
> any dependency on
> >>> plexus-utils in core... and how we class-load
> plexus-utils is IIRC
> >>> that we force the core version on all plugins
> no matter what they
> >>> use... so if we remove a deprecated method and
> a plugin is expecting
> >>> it then that plugin breaks.
> >>>
> >>> On 13 June 2011 10:41, Mark Struberg 
> wrote:
> >>>> Hi!
> >>>>
> >>>> If those methods are already deprecated,
> then I'd say we should drop them now.
> >>>>
> >>>> Most times those methods didn't got
> deprecated because they are 'unpretty' but because they are
> seriously flawed. Like missing encoding parameter, missing
> timezone, not multithreading capable, etc.
> >>>>
> >>>> So if those methods are deprecated for
> more than a year now (or < maven-2.2.1 and maven-3.0),
> then I'd say lets drop them now.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>> --- On Mon, 6/13/11, Stephen Connolly
> 
> wrote:
> >>>>
> >>>>> From: Stephen Connolly 
> >>>>> Subject: Re: Truly awful code in
> plexus...
> >>>>> To: "Maven Developers List" 
> >>>>> Date: Monday, June 13, 2011, 5:55 AM
> >>>>>

Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 13:54, Benson Margulies  wrote:
> There's an IP principle that is escaping me here.
>
> According to the previous answered legal questions page, as I read it,
> if you find a small amount of source anywhere, and it has an Apache
> license notice on it, you can incorporate it into an Apache project
> without any further research into provenance. This discussion seems to
> be predicated on a stricter policy, or perhaps on some particular
> reason to think that someone grabbed what didn't belong to them,
> slapped an Apache notice on it, and committed it to this project.

Some people have called into question the IP provenance of
plexus-utils... as a result we can;t just co-opt the whole thing in
one go so it would be nice if we could have some certainty rather
than have somebody call the new ip into question again!

>
> ?
>
>
> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy  wrote:
>> Hello,
>>
>> 2011/6/13 Benson Margulies :
>>> Let's be specific about a few classes.
>>>
>>> CollectionUtil has an @author of olamy and an apache notice, so I
>>> grabbed it rather than try to recreate it.
>>
>> Doh I don't remember why it's here :-) . In fact not sure it was for
>> Maven (maybe written long time ago for continuum )
>>
>> Someone know a place where it's used in maven source code ? (sorry as
>> usual I have a small memory fooprint :-) )
>>
>>>
>>> FastMap and CachedMap are grabbed from javolution. We can call the
>>> current javolution from the bridge.
>>>
>>> StringInputStream and StringOutputStream are deprecated, have an
>>> Apache 1.1 license, have no obvious author, and known-busted. They are
>>> also so trivial that I claim that copying their source for interim
>>> compatibility is harmless, given the license notice.
>>>
>>> StringUtils is a large collection of fiddly functions. Again, an
>>> Apache license, and a claim of provenance from Apache Turbine. Do we
>>> really need to recreate it due to license considerations?
>>>
>>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>>> If nothing else, Herve could commit a copy of it to the sandbox and
>>> we'd be good to go.
>>>
>>> SweeperPool: does anything use this? It would be somewhat scary to recreate.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>>  wrote:
>>>> It's tempting... but I fear all that will happen is nobody will switch
>>>> to the new impl...
>>>>
>>>> the WHOLE point of this bridge is to remove any dependency on
>>>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>>>> that we force the core version on all plugins no matter what they
>>>> use... so if we remove a deprecated method and a plugin is expecting
>>>> it then that plugin breaks.
>>>>
>>>> On 13 June 2011 10:41, Mark Struberg  wrote:
>>>>> Hi!
>>>>>
>>>>> If those methods are already deprecated, then I'd say we should drop them 
>>>>> now.
>>>>>
>>>>> Most times those methods didn't got deprecated because they are 
>>>>> 'unpretty' but because they are seriously flawed. Like missing encoding 
>>>>> parameter, missing timezone, not multithreading capable, etc.
>>>>>
>>>>> So if those methods are deprecated for more than a year now (or < 
>>>>> maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>> --- On Mon, 6/13/11, Stephen Connolly  
>>>>> wrote:
>>>>>
>>>>>> From: Stephen Connolly 
>>>>>> Subject: Re: Truly awful code in plexus...
>>>>>> To: "Maven Developers List" 
>>>>>> Date: Monday, June 13, 2011, 5:55 AM
>>>>>> if we knew the provenance of the
>>>>>> plexus code, yes... but we don't
>>>>>>
>>>>>> - Stephen
>>>>>>
>>>>>> ---
>>>>>> Sent from my Android phone, so random spelling mistakes,
>>>>>> random nonsense
>>>>>> words and other nonsense are a direct result of using swype
>>>>>> to type on the
>>>>>> screen
>>>>

Re: Truly awful code in plexus...

[Benson Margulies]

There's an IP principle that is escaping me here.

According to the previous answered legal questions page, as I read it,
if you find a small amount of source anywhere, and it has an Apache
license notice on it, you can incorporate it into an Apache project
without any further research into provenance. This discussion seems to
be predicated on a stricter policy, or perhaps on some particular
reason to think that someone grabbed what didn't belong to them,
slapped an Apache notice on it, and committed it to this project.

?


On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy  wrote:
> Hello,
>
> 2011/6/13 Benson Margulies :
>> Let's be specific about a few classes.
>>
>> CollectionUtil has an @author of olamy and an apache notice, so I
>> grabbed it rather than try to recreate it.
>
> Doh I don't remember why it's here :-) . In fact not sure it was for
> Maven (maybe written long time ago for continuum )
>
> Someone know a place where it's used in maven source code ? (sorry as
> usual I have a small memory fooprint :-) )
>
>>
>> FastMap and CachedMap are grabbed from javolution. We can call the
>> current javolution from the bridge.
>>
>> StringInputStream and StringOutputStream are deprecated, have an
>> Apache 1.1 license, have no obvious author, and known-busted. They are
>> also so trivial that I claim that copying their source for interim
>> compatibility is harmless, given the license notice.
>>
>> StringUtils is a large collection of fiddly functions. Again, an
>> Apache license, and a claim of provenance from Apache Turbine. Do we
>> really need to recreate it due to license considerations?
>>
>> ReaderFactory: has an Apache notice, a Maven committer's name on it.
>> If nothing else, Herve could commit a copy of it to the sandbox and
>> we'd be good to go.
>>
>> SweeperPool: does anything use this? It would be somewhat scary to recreate.
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>>  wrote:
>>> It's tempting... but I fear all that will happen is nobody will switch
>>> to the new impl...
>>>
>>> the WHOLE point of this bridge is to remove any dependency on
>>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>>> that we force the core version on all plugins no matter what they
>>> use... so if we remove a deprecated method and a plugin is expecting
>>> it then that plugin breaks.
>>>
>>> On 13 June 2011 10:41, Mark Struberg  wrote:
>>>> Hi!
>>>>
>>>> If those methods are already deprecated, then I'd say we should drop them 
>>>> now.
>>>>
>>>> Most times those methods didn't got deprecated because they are 'unpretty' 
>>>> but because they are seriously flawed. Like missing encoding parameter, 
>>>> missing timezone, not multithreading capable, etc.
>>>>
>>>> So if those methods are deprecated for more than a year now (or < 
>>>> maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>> --- On Mon, 6/13/11, Stephen Connolly  
>>>> wrote:
>>>>
>>>>> From: Stephen Connolly 
>>>>> Subject: Re: Truly awful code in plexus...
>>>>> To: "Maven Developers List" 
>>>>> Date: Monday, June 13, 2011, 5:55 AM
>>>>> if we knew the provenance of the
>>>>> plexus code, yes... but we don't
>>>>>
>>>>> - Stephen
>>>>>
>>>>> ---
>>>>> Sent from my Android phone, so random spelling mistakes,
>>>>> random nonsense
>>>>> words and other nonsense are a direct result of using swype
>>>>> to type on the
>>>>> screen
>>>>> On 13 Jun 2011 00:12, "Benson Margulies" 
>>>>> wrote:
>>>>> > If we want to keep the broken behavior of these
>>>>> already @Deprecated
>>>>> > classes, then I'd think we'd just copy them wholesale
>>>>> from plexus to
>>>>> > the bridge. There's no advantage in replacing an old
>>>>> broken version
>>>>> > with a new broken, and they're already deprecated, and
>>>>> the right thing
>>>>> > to do to callers is to make them use modern methods.
>>>>> >
>>>>> > On S

Re: Truly awful code in plexus...

[Olivier Lamy]

Hello,

2011/6/13 Benson Margulies :
> Let's be specific about a few classes.
>
> CollectionUtil has an @author of olamy and an apache notice, so I
> grabbed it rather than try to recreate it.

Doh I don't remember why it's here :-) . In fact not sure it was for
Maven (maybe written long time ago for continuum )

Someone know a place where it's used in maven source code ? (sorry as
usual I have a small memory fooprint :-) )

>
> FastMap and CachedMap are grabbed from javolution. We can call the
> current javolution from the bridge.
>
> StringInputStream and StringOutputStream are deprecated, have an
> Apache 1.1 license, have no obvious author, and known-busted. They are
> also so trivial that I claim that copying their source for interim
> compatibility is harmless, given the license notice.
>
> StringUtils is a large collection of fiddly functions. Again, an
> Apache license, and a claim of provenance from Apache Turbine. Do we
> really need to recreate it due to license considerations?
>
> ReaderFactory: has an Apache notice, a Maven committer's name on it.
> If nothing else, Herve could commit a copy of it to the sandbox and
> we'd be good to go.
>
> SweeperPool: does anything use this? It would be somewhat scary to recreate.
>
>
>
>
>
>
> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>  wrote:
>> It's tempting... but I fear all that will happen is nobody will switch
>> to the new impl...
>>
>> the WHOLE point of this bridge is to remove any dependency on
>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>> that we force the core version on all plugins no matter what they
>> use... so if we remove a deprecated method and a plugin is expecting
>> it then that plugin breaks.
>>
>> On 13 June 2011 10:41, Mark Struberg  wrote:
>>> Hi!
>>>
>>> If those methods are already deprecated, then I'd say we should drop them 
>>> now.
>>>
>>> Most times those methods didn't got deprecated because they are 'unpretty' 
>>> but because they are seriously flawed. Like missing encoding parameter, 
>>> missing timezone, not multithreading capable, etc.
>>>
>>> So if those methods are deprecated for more than a year now (or < 
>>> maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Mon, 6/13/11, Stephen Connolly  
>>> wrote:
>>>
>>>> From: Stephen Connolly 
>>>> Subject: Re: Truly awful code in plexus...
>>>> To: "Maven Developers List" 
>>>> Date: Monday, June 13, 2011, 5:55 AM
>>>> if we knew the provenance of the
>>>> plexus code, yes... but we don't
>>>>
>>>> - Stephen
>>>>
>>>> ---
>>>> Sent from my Android phone, so random spelling mistakes,
>>>> random nonsense
>>>> words and other nonsense are a direct result of using swype
>>>> to type on the
>>>> screen
>>>> On 13 Jun 2011 00:12, "Benson Margulies" 
>>>> wrote:
>>>> > If we want to keep the broken behavior of these
>>>> already @Deprecated
>>>> > classes, then I'd think we'd just copy them wholesale
>>>> from plexus to
>>>> > the bridge. There's no advantage in replacing an old
>>>> broken version
>>>> > with a new broken, and they're already deprecated, and
>>>> the right thing
>>>> > to do to callers is to make them use modern methods.
>>>> >
>>>> > On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
>>>> > 
>>>> wrote:
>>>> >> thanks
>>>> >>
>>>> >> - Stephen
>>>> >>
>>>> >> ---
>>>> >> Sent from my Android phone, so random spelling
>>>> mistakes, random nonsense
>>>> >> words and other nonsense are a direct result of
>>>> using swype to type on
>>>> the
>>>> >> screen
>>>> >> On 12 Jun 2011 23:25, "Hervé BOUTEMY" 
>>>> wrote:
>>>> >>> strategy added in the proposal [1], for future
>>>> reference
>>>> >>>
>>>> >>> Regards,
>>>> >>>
>>>> >>> Hervé
>>>> >>>
>>>> >>> [1]
>>>> >>
>>>> https://cwiki.apa

Re: Truly awful code in plexus...

[Stephen Connolly]

On 13 June 2011 12:48, Benson Margulies  wrote:
> Let's be specific about a few classes.
>
> CollectionUtil has an @author of olamy and an apache notice, so I
> grabbed it rather than try to recreate it.

did you check the svn log?

>
> FastMap and CachedMap are grabbed from javolution. We can call the
> current javolution from the bridge.

That seems fine by me

>
> StringInputStream and StringOutputStream are deprecated, have an
> Apache 1.1 license, have no obvious author, and known-busted. They are
> also so trivial that I claim that copying their source for interim
> compatibility is harmless, given the license notice.
>

OK, if we have tests.

> StringUtils is a large collection of fiddly functions. Again, an
> Apache license, and a claim of provenance from Apache Turbine. Do we
> really need to recreate it due to license considerations?

Can we copy the turbine code instead?

>
> ReaderFactory: has an Apache notice, a Maven committer's name on it.
> If nothing else, Herve could commit a copy of it to the sandbox and
> we'd be good to go.

Lets see if Hervé will cooperate ;-)

>
> SweeperPool: does anything use this? It would be somewhat scary to recreate.
>
>
>
>
>
>
> On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
>  wrote:
>> It's tempting... but I fear all that will happen is nobody will switch
>> to the new impl...
>>
>> the WHOLE point of this bridge is to remove any dependency on
>> plexus-utils in core... and how we class-load plexus-utils is IIRC
>> that we force the core version on all plugins no matter what they
>> use... so if we remove a deprecated method and a plugin is expecting
>> it then that plugin breaks.
>>
>> On 13 June 2011 10:41, Mark Struberg  wrote:
>>> Hi!
>>>
>>> If those methods are already deprecated, then I'd say we should drop them 
>>> now.
>>>
>>> Most times those methods didn't got deprecated because they are 'unpretty' 
>>> but because they are seriously flawed. Like missing encoding parameter, 
>>> missing timezone, not multithreading capable, etc.
>>>
>>> So if those methods are deprecated for more than a year now (or < 
>>> maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Mon, 6/13/11, Stephen Connolly  
>>> wrote:
>>>
>>>> From: Stephen Connolly 
>>>> Subject: Re: Truly awful code in plexus...
>>>> To: "Maven Developers List" 
>>>> Date: Monday, June 13, 2011, 5:55 AM
>>>> if we knew the provenance of the
>>>> plexus code, yes... but we don't
>>>>
>>>> - Stephen
>>>>
>>>> ---
>>>> Sent from my Android phone, so random spelling mistakes,
>>>> random nonsense
>>>> words and other nonsense are a direct result of using swype
>>>> to type on the
>>>> screen
>>>> On 13 Jun 2011 00:12, "Benson Margulies" 
>>>> wrote:
>>>> > If we want to keep the broken behavior of these
>>>> already @Deprecated
>>>> > classes, then I'd think we'd just copy them wholesale
>>>> from plexus to
>>>> > the bridge. There's no advantage in replacing an old
>>>> broken version
>>>> > with a new broken, and they're already deprecated, and
>>>> the right thing
>>>> > to do to callers is to make them use modern methods.
>>>> >
>>>> > On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
>>>> > 
>>>> wrote:
>>>> >> thanks
>>>> >>
>>>> >> - Stephen
>>>> >>
>>>> >> ---
>>>> >> Sent from my Android phone, so random spelling
>>>> mistakes, random nonsense
>>>> >> words and other nonsense are a direct result of
>>>> using swype to type on
>>>> the
>>>> >> screen
>>>> >> On 12 Jun 2011 23:25, "Hervé BOUTEMY" 
>>>> wrote:
>>>> >>> strategy added in the proposal [1], for future
>>>> reference
>>>> >>>
>>>> >>> Regards,
>>>> >>>
>>>> >>> Hervé
>>>> >>>
>>>> >>> [1]
>>>> >>
>>>> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replaceme

Re: Truly awful code in plexus...

[Altuğ Bilgin Altıntaş]

Hi all;

We have created new Maven screencast  (Turkish version). This video anwers
below questions
1 - What is Maven
2  -How can you set up it
3 - Maven integration - pom.xml explanatation

Here is the link :
http://www.kodcu.com/2011/03/apache-maven-teknolojisine-giris-video/

How can we add this articles to  http://maven.apache.org/articles.html

Thanks.

2011/6/13 Hervé BOUTEMY 

> > plexus-utils in core... and how we class-load plexus-utils is IIRC
> > that we force the core version on all plugins no matter what they
> > use... so if we remove a deprecated method and a plugin is expecting
> > it then that plugin breaks.
> no, this is not the case since Maven 2.0.6: see MNG-2892
>
> FYI, in Maven 2.x, this is done with shade plugin in apache-maven module.
> In Maven 3, this is treated in maven-core with ClassRealmManager component.
>
> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
*Altuğ*
*www.kodcu.com* **

Re: Truly awful code in plexus...

[Benson Margulies]

Let's be specific about a few classes.

CollectionUtil has an @author of olamy and an apache notice, so I
grabbed it rather than try to recreate it.

FastMap and CachedMap are grabbed from javolution. We can call the
current javolution from the bridge.

StringInputStream and StringOutputStream are deprecated, have an
Apache 1.1 license, have no obvious author, and known-busted. They are
also so trivial that I claim that copying their source for interim
compatibility is harmless, given the license notice.

StringUtils is a large collection of fiddly functions. Again, an
Apache license, and a claim of provenance from Apache Turbine. Do we
really need to recreate it due to license considerations?

ReaderFactory: has an Apache notice, a Maven committer's name on it.
If nothing else, Herve could commit a copy of it to the sandbox and
we'd be good to go.

SweeperPool: does anything use this? It would be somewhat scary to recreate.






On Mon, Jun 13, 2011 at 5:46 AM, Stephen Connolly
 wrote:
> It's tempting... but I fear all that will happen is nobody will switch
> to the new impl...
>
> the WHOLE point of this bridge is to remove any dependency on
> plexus-utils in core... and how we class-load plexus-utils is IIRC
> that we force the core version on all plugins no matter what they
> use... so if we remove a deprecated method and a plugin is expecting
> it then that plugin breaks.
>
> On 13 June 2011 10:41, Mark Struberg  wrote:
>> Hi!
>>
>> If those methods are already deprecated, then I'd say we should drop them 
>> now.
>>
>> Most times those methods didn't got deprecated because they are 'unpretty' 
>> but because they are seriously flawed. Like missing encoding parameter, 
>> missing timezone, not multithreading capable, etc.
>>
>> So if those methods are deprecated for more than a year now (or < 
>> maven-2.2.1 and maven-3.0), then I'd say lets drop them now.
>>
>> LieGrue,
>> strub
>>
>> --- On Mon, 6/13/11, Stephen Connolly  
>> wrote:
>>
>>> From: Stephen Connolly 
>>> Subject: Re: Truly awful code in plexus...
>>> To: "Maven Developers List" 
>>> Date: Monday, June 13, 2011, 5:55 AM
>>> if we knew the provenance of the
>>> plexus code, yes... but we don't
>>>
>>> - Stephen
>>>
>>> ---
>>> Sent from my Android phone, so random spelling mistakes,
>>> random nonsense
>>> words and other nonsense are a direct result of using swype
>>> to type on the
>>> screen
>>> On 13 Jun 2011 00:12, "Benson Margulies" 
>>> wrote:
>>> > If we want to keep the broken behavior of these
>>> already @Deprecated
>>> > classes, then I'd think we'd just copy them wholesale
>>> from plexus to
>>> > the bridge. There's no advantage in replacing an old
>>> broken version
>>> > with a new broken, and they're already deprecated, and
>>> the right thing
>>> > to do to callers is to make them use modern methods.
>>> >
>>> > On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
>>> > 
>>> wrote:
>>> >> thanks
>>> >>
>>> >> - Stephen
>>> >>
>>> >> ---
>>> >> Sent from my Android phone, so random spelling
>>> mistakes, random nonsense
>>> >> words and other nonsense are a direct result of
>>> using swype to type on
>>> the
>>> >> screen
>>> >> On 12 Jun 2011 23:25, "Hervé BOUTEMY" 
>>> wrote:
>>> >>> strategy added in the proposal [1], for future
>>> reference
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Hervé
>>> >>>
>>> >>> [1]
>>> >>
>>> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
>>> >>>
>>> >>> Le lundi 13 juin 2011, Stephen Connolly a
>>> écrit :
>>> >>>> here is my thoughts, for first release we
>>> need to have a drop in
>>> >>>> replacement that works exactly the same as
>>> the original... that gives
>>> us
>>> >> a
>>> >>>> way to kill the old version (otherwise
>>> people will just say, "I'm not
>>> >>>> going to fix my code when it works fine
>>> with plexus utils... ok maybe
>>> >> I'll
>>> >>>> fix it later"

Re: Truly awful code in plexus...

[Hervé BOUTEMY]

> plexus-utils in core... and how we class-load plexus-utils is IIRC
> that we force the core version on all plugins no matter what they
> use... so if we remove a deprecated method and a plugin is expecting
> it then that plugin breaks.
no, this is not the case since Maven 2.0.6: see MNG-2892

FYI, in Maven 2.x, this is done with shade plugin in apache-maven module.
In Maven 3, this is treated in maven-core with ClassRealmManager component.

Regards,

Hervé

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Stephen Connolly]

It's tempting... but I fear all that will happen is nobody will switch
to the new impl...

the WHOLE point of this bridge is to remove any dependency on
plexus-utils in core... and how we class-load plexus-utils is IIRC
that we force the core version on all plugins no matter what they
use... so if we remove a deprecated method and a plugin is expecting
it then that plugin breaks.

On 13 June 2011 10:41, Mark Struberg  wrote:
> Hi!
>
> If those methods are already deprecated, then I'd say we should drop them now.
>
> Most times those methods didn't got deprecated because they are 'unpretty' 
> but because they are seriously flawed. Like missing encoding parameter, 
> missing timezone, not multithreading capable, etc.
>
> So if those methods are deprecated for more than a year now (or < maven-2.2.1 
> and maven-3.0), then I'd say lets drop them now.
>
> LieGrue,
> strub
>
> --- On Mon, 6/13/11, Stephen Connolly  wrote:
>
>> From: Stephen Connolly 
>> Subject: Re: Truly awful code in plexus...
>> To: "Maven Developers List" 
>> Date: Monday, June 13, 2011, 5:55 AM
>> if we knew the provenance of the
>> plexus code, yes... but we don't
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes,
>> random nonsense
>> words and other nonsense are a direct result of using swype
>> to type on the
>> screen
>> On 13 Jun 2011 00:12, "Benson Margulies" 
>> wrote:
>> > If we want to keep the broken behavior of these
>> already @Deprecated
>> > classes, then I'd think we'd just copy them wholesale
>> from plexus to
>> > the bridge. There's no advantage in replacing an old
>> broken version
>> > with a new broken, and they're already deprecated, and
>> the right thing
>> > to do to callers is to make them use modern methods.
>> >
>> > On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
>> > 
>> wrote:
>> >> thanks
>> >>
>> >> - Stephen
>> >>
>> >> ---
>> >> Sent from my Android phone, so random spelling
>> mistakes, random nonsense
>> >> words and other nonsense are a direct result of
>> using swype to type on
>> the
>> >> screen
>> >> On 12 Jun 2011 23:25, "Hervé BOUTEMY" 
>> wrote:
>> >>> strategy added in the proposal [1], for future
>> reference
>> >>>
>> >>> Regards,
>> >>>
>> >>> Hervé
>> >>>
>> >>> [1]
>> >>
>> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
>> >>>
>> >>> Le lundi 13 juin 2011, Stephen Connolly a
>> écrit :
>> >>>> here is my thoughts, for first release we
>> need to have a drop in
>> >>>> replacement that works exactly the same as
>> the original... that gives
>> us
>> >> a
>> >>>> way to kill the old version (otherwise
>> people will just say, "I'm not
>> >>>> going to fix my code when it works fine
>> with plexus utils... ok maybe
>> >> I'll
>> >>>> fix it later")
>> >>>>
>> >>>> we will mark every method and class in the
>> bridge as deprecated, but we
>> >>>> need the recommendations for each
>> replacement to put in the deprecated
>> >>>> tags.
>> >>>>
>> >>>> for the second release we flip the
>> @reproducesplexusbug rule and fix
>> all
>> >>>> those test cases
>> >>>>
>> >>>> for the third release, everything is
>> deprecated
>> >>>>
>> >>>> - Stephen
>> >>>>
>> >>>> ---
>> >>>> Sent from my Android phone, so random
>> spelling mistakes, random
>> nonsense
>> >>>> words and other nonsense are a direct
>> result of using swype to type on
>> >> the
>> >>>> screen
>> >>>> On 12 Jun 2011 21:24, "Benson Margulies"
>> 
>> wrote:
>> >>>
>> >>>
>> >>>
>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >>> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>>
>> >>
>> >
>> >
>> -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Mark Struberg]

Hi!

If those methods are already deprecated, then I'd say we should drop them now. 

Most times those methods didn't got deprecated because they are 'unpretty' but 
because they are seriously flawed. Like missing encoding parameter, missing 
timezone, not multithreading capable, etc.

So if those methods are deprecated for more than a year now (or < maven-2.2.1 
and maven-3.0), then I'd say lets drop them now.

LieGrue,
strub  

--- On Mon, 6/13/11, Stephen Connolly  wrote:

> From: Stephen Connolly 
> Subject: Re: Truly awful code in plexus...
> To: "Maven Developers List" 
> Date: Monday, June 13, 2011, 5:55 AM
> if we knew the provenance of the
> plexus code, yes... but we don't
> 
> - Stephen
> 
> ---
> Sent from my Android phone, so random spelling mistakes,
> random nonsense
> words and other nonsense are a direct result of using swype
> to type on the
> screen
> On 13 Jun 2011 00:12, "Benson Margulies" 
> wrote:
> > If we want to keep the broken behavior of these
> already @Deprecated
> > classes, then I'd think we'd just copy them wholesale
> from plexus to
> > the bridge. There's no advantage in replacing an old
> broken version
> > with a new broken, and they're already deprecated, and
> the right thing
> > to do to callers is to make them use modern methods.
> >
> > On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
> > 
> wrote:
> >> thanks
> >>
> >> - Stephen
> >>
> >> ---
> >> Sent from my Android phone, so random spelling
> mistakes, random nonsense
> >> words and other nonsense are a direct result of
> using swype to type on
> the
> >> screen
> >> On 12 Jun 2011 23:25, "Hervé BOUTEMY" 
> wrote:
> >>> strategy added in the proposal [1], for future
> reference
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> [1]
> >>
> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
> >>>
> >>> Le lundi 13 juin 2011, Stephen Connolly a
> écrit :
> >>>> here is my thoughts, for first release we
> need to have a drop in
> >>>> replacement that works exactly the same as
> the original... that gives
> us
> >> a
> >>>> way to kill the old version (otherwise
> people will just say, "I'm not
> >>>> going to fix my code when it works fine
> with plexus utils... ok maybe
> >> I'll
> >>>> fix it later")
> >>>>
> >>>> we will mark every method and class in the
> bridge as deprecated, but we
> >>>> need the recommendations for each
> replacement to put in the deprecated
> >>>> tags.
> >>>>
> >>>> for the second release we flip the
> @reproducesplexusbug rule and fix
> all
> >>>> those test cases
> >>>>
> >>>> for the third release, everything is
> deprecated
> >>>>
> >>>> - Stephen
> >>>>
> >>>> ---
> >>>> Sent from my Android phone, so random
> spelling mistakes, random
> nonsense
> >>>> words and other nonsense are a direct
> result of using swype to type on
> >> the
> >>>> screen
> >>>> On 12 Jun 2011 21:24, "Benson Margulies"
> 
> wrote:
> >>>
> >>>
> >>>
> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>
> >
> >
> -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Stephen Connolly]

if we knew the provenance of the plexus code, yes... but we don't

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 13 Jun 2011 00:12, "Benson Margulies"  wrote:
> If we want to keep the broken behavior of these already @Deprecated
> classes, then I'd think we'd just copy them wholesale from plexus to
> the bridge. There's no advantage in replacing an old broken version
> with a new broken, and they're already deprecated, and the right thing
> to do to callers is to make them use modern methods.
>
> On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
>  wrote:
>> thanks
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on
the
>> screen
>> On 12 Jun 2011 23:25, "Hervé BOUTEMY"  wrote:
>>> strategy added in the proposal [1], for future reference
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> [1]
>>
https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
>>>
>>> Le lundi 13 juin 2011, Stephen Connolly a écrit :
 here is my thoughts, for first release we need to have a drop in
 replacement that works exactly the same as the original... that gives
us
>> a
 way to kill the old version (otherwise people will just say, "I'm not
 going to fix my code when it works fine with plexus utils... ok maybe
>> I'll
 fix it later")

 we will mark every method and class in the bridge as deprecated, but we
 need the recommendations for each replacement to put in the deprecated
 tags.

 for the second release we flip the @reproducesplexusbug rule and fix
all
 those test cases

 for the third release, everything is deprecated

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random
nonsense
 words and other nonsense are a direct result of using swype to type on
>> the
 screen
 On 12 Jun 2011 21:24, "Benson Margulies"  wrote:
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Truly awful code in plexus...

[Benson Margulies]

If we want to keep the broken behavior of these already @Deprecated
classes, then I'd think we'd just copy them wholesale from plexus to
the bridge. There's no advantage in replacing an old broken version
with a new broken, and they're already deprecated, and the right thing
to do to callers is to make them use modern methods.

On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly
 wrote:
> thanks
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 12 Jun 2011 23:25, "Hervé BOUTEMY"  wrote:
>> strategy added in the proposal [1], for future reference
>>
>> Regards,
>>
>> Hervé
>>
>> [1]
> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
>>
>> Le lundi 13 juin 2011, Stephen Connolly a écrit :
>>> here is my thoughts, for first release we need to have a drop in
>>> replacement that works exactly the same as the original... that gives us
> a
>>> way to kill the old version (otherwise people will just say, "I'm not
>>> going to fix my code when it works fine with plexus utils... ok maybe
> I'll
>>> fix it later")
>>>
>>> we will mark every method and class in the bridge as deprecated, but we
>>> need the recommendations for each replacement to put in the deprecated
>>> tags.
>>>
>>> for the second release we flip the @reproducesplexusbug rule and fix all
>>> those test cases
>>>
>>> for the third release, everything is deprecated
>>>
>>> - Stephen
>>>
>>> ---
>>> Sent from my Android phone, so random spelling mistakes, random nonsense
>>> words and other nonsense are a direct result of using swype to type on
> the
>>> screen
>>> On 12 Jun 2011 21:24, "Benson Margulies"  wrote:
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Stephen Connolly]

thanks

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jun 2011 23:25, "Hervé BOUTEMY"  wrote:
> strategy added in the proposal [1], for future reference
>
> Regards,
>
> Hervé
>
> [1]
https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
>
> Le lundi 13 juin 2011, Stephen Connolly a écrit :
>> here is my thoughts, for first release we need to have a drop in
>> replacement that works exactly the same as the original... that gives us
a
>> way to kill the old version (otherwise people will just say, "I'm not
>> going to fix my code when it works fine with plexus utils... ok maybe
I'll
>> fix it later")
>>
>> we will mark every method and class in the bridge as deprecated, but we
>> need the recommendations for each replacement to put in the deprecated
>> tags.
>>
>> for the second release we flip the @reproducesplexusbug rule and fix all
>> those test cases
>>
>> for the third release, everything is deprecated
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on
the
>> screen
>> On 12 Jun 2011 21:24, "Benson Margulies"  wrote:
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Truly awful code in plexus...

[Hervé BOUTEMY]

strategy added in the proposal [1], for future reference

Regards,

Hervé

[1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement

Le lundi 13 juin 2011, Stephen Connolly a écrit :
> here is my thoughts, for first release we need to have a drop in
> replacement that works exactly the same as the original... that gives us a
> way to kill the old version (otherwise people will just say, "I'm not
> going to fix my code when it works fine with plexus utils... ok maybe I'll
> fix it later")
> 
> we will mark every method and class in the bridge as deprecated, but we
> need the recommendations for each replacement to put in the deprecated
> tags.
> 
> for the second release we flip the @reproducesplexusbug rule and fix all
> those test cases
> 
> for the third release, everything is deprecated
> 
> - Stephen
> 
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 12 Jun 2011 21:24, "Benson Margulies"  wrote:


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Benson Margulies]

Then we will need the bridged FastMap I described. I'll take care of it.

On Sun, Jun 12, 2011 at 6:03 PM, Stephen Connolly
 wrote:
> here is my thoughts, for first release we need to have a drop in replacement
> that works exactly the same as the original... that gives us a way to kill
> the old version (otherwise people will just say, "I'm not going to fix my
> code when it works fine with plexus utils... ok maybe I'll fix it later")
>
> we will mark every method and class in the bridge as deprecated, but we need
> the recommendations for each replacement to put in the deprecated tags.
>
> for the second release we flip the @reproducesplexusbug rule and fix all
> those test cases
>
> for the third release, everything is deprecated
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 12 Jun 2011 21:24, "Benson Margulies"  wrote:
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Truly awful code in plexus...

[Stephen Connolly]

here is my thoughts, for first release we need to have a drop in replacement
that works exactly the same as the original... that gives us a way to kill
the old version (otherwise people will just say, "I'm not going to fix my
code when it works fine with plexus utils... ok maybe I'll fix it later")

we will mark every method and class in the bridge as deprecated, but we need
the recommendations for each replacement to put in the deprecated tags.

for the second release we flip the @reproducesplexusbug rule and fix all
those test cases

for the third release, everything is deprecated

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jun 2011 21:24, "Benson Margulies"  wrote: