On 13 June 2011 15:36, John Casey <[email protected]> wrote: > > > On 6/13/11 8:45 AM, Stephen Connolly wrote: >> >> On 13 June 2011 12:48, Benson Margulies<[email protected]> 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 >>> <[email protected]> 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<[email protected]> 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<[email protected]> >>>>> wrote: >>>>> >>>>>> From: Stephen Connolly<[email protected]> >>>>>> Subject: Re: Truly awful code in plexus... >>>>>> To: "Maven Developers List"<[email protected]> >>>>>> 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"<[email protected]> >>>>>> 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 >>>>>>> <[email protected]> >>>>>> >>>>>> 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"<[email protected]> >>>>>> >>>>>> 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" >>>>>> >>>>>> <[email protected]> >>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
