I wrote up the current status in our Wiki https://cwiki.apache.org/confluence/display/MAVEN/MavenSharedUtils
I've not yet finished the whole class matrix, will do that in the afternoon. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: Maven Developers List <[email protected]> > Cc: > Sent: Thursday, August 30, 2012 12:01 PM > Subject: Re: Any maven-shared or maven-core release pending? > > >> Shading/delegating is the road to hell, later on it becomes easier to just > add >> one method implementation there and the show starts. > > Nope, with shading in the source/class dynamically it will _not_ kept in our > SVN! Thus noone could tweak em ;) > > >> Directly using commons-* >> wherever needed should be the preferred way. > That's the reason why I did NOT add any Base64 nor similar to m-shared-utils > yet. > One counter argument could be binary compatibility. We need some test project > with _very_ old plugins to check if we are still fine. > If maven-core brings in commons libs as dependencies, then we might clash > with > very old plugins which need ancient versions of commons as well. > That kind of stuff is the the reason why framework projects most times shade > those classes away into own packages which do not create classpath clashes. > Even Sun does that with lots of Apache classes which get shipped inside the > JRE > jars. > But we will for sure always take the original sources from commons and not > maintain them ourselfs! > >> In short I'm looking for smth. like https://live.gnome.org/GnomeGoals > list > > I already added a table to the javadocs package.html. Not sure if this will > remain there, but for now it's fine. > > LieGrue, > strub > > > ----- Original Message ----- >> From: Aleksandar Kurtakov <[email protected]> >> To: Maven Developers List <[email protected]> >> Cc: >> Sent: Thursday, August 30, 2012 11:40 AM >> Subject: Re: Any maven-shared or maven-core release pending? >> >> >> >> ----- Original Message ----- >>> From: "Mark Struberg" <[email protected]> >>> To: "Maven Developers List" <[email protected]> >>> Sent: Thursday, August 30, 2012 12:12:49 PM >>> Subject: Re: Any maven-shared or maven-core release pending? >>> >>> yes, that is exactly the goal. E.g. instead of imlementing our own >>> Base64 stuff we will either shade in parts or delegate over to >>> commons-io. >> >> Shading/delegating is the road to hell, later on it becomes easier to just > add >> one method implementation there and the show starts. Directly using > commons-* >> wherever needed should be the preferred way. Not to mention that it will be > way >> more familiar for people when they see org.apache.commons and having dealt > with >> it instead of org.apache.maven.shared.utils. At least for people like me it > will >> not make me move away because of the 48th Base64 implementation I see this >> month. Even if it's simply calling commons-codec, different >> class/method/parameter names make it a different API. >> >>> >>> After the initial switch from p-u to m-s-u we will review all code >>> and make a major upgrade and drop obsolete parts. >> Doesn't that mean that this shading library will stay forever in >> Maven+plugins deps just like plexus-containers-default 1.0 alpha(5...30)? >> Also is the effort to moving to Apache commons ongoing? >> Is there some page containing the pending conversions, what is the > preferred >> replacement, status of core components? >> In short I'm looking for smth. like https://live.gnome.org/GnomeGoals > list >> and https://live.gnome.org/GnomeGoals/GSettingsMigration as a detailed > example. >> Are you actively looking for external help in this direction? Maybe I can >> promote it to Fedora Java people as we already have done a lot of work to >> streamline the dependencies so it becomes supportable for people building > from >> source and this is something that Linux distro guys are doing with or > without >> upstream so happening upstream would benefit everyone. But for this to > happen >> there needs to be an active upstream developer willing to review/commit > patches. >> >> P.S My colleague Stanislav meant something like that when he wrote about > porting >> plugins away of maven-compat, when he wrote to that list sometime ago. >> >> Regards, >> Alexander Kurtakov >> Red Hat Eclipse Team >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> ----- Original Message ----- >>> > From: Aleksandar Kurtakov <[email protected]> >>> > To: Maven Developers List <[email protected]>; Mark > Struberg >>> > <[email protected]> >>> > Cc: >>> > Sent: Thursday, August 30, 2012 11:07 AM >>> > Subject: Re: Any maven-shared or maven-core release pending? >>> > >>> > >>> > >>> > ----- Original Message ----- >>> >> From: "Mark Struberg" <[email protected]> >>> >> To: "Maven Dev" <[email protected]> >>> >> Sent: Thursday, August 30, 2012 11:55:13 AM >>> >> Subject: Any maven-shared or maven-core release pending? >>> >> >>> >> Hi folks! >>> >> >>> >> Is there any maven-core or maven-shared release pending? >>> >> I'd like to start with moving all maven stuff from >> plexus-utils >>> >> to >>> >> maven-shared-utils. >>> >> >>> >> The reason is simple: >>> >> 1.) It always got argued that we cannot just replace > plexus-utils >>> >> because we don't know how many plugins are using it. And > >> people >>> >> feared about side effects which could harm stability. >>> >> As we do this now in a whole new module with a new package > name >>> >> we >>> >> can really easily upgrade that stuff to proper 2012 style > and >>> >> don't >>> >> need to keep em 2005ish anymore ;) >>> >> >>> >> 2.) For implementing the incremental build stuff I need a > few >>> >> classes >>> >> extended, and the only way we can guarantee this to be > reliably >>> >> available is to host this stuff in maven itself (where it > was >>> >> originally hosted btw - 80% of the plexus utils code is a > fork of >>> >> old ant/jakarta/commons stuff). And since the codehaus repo > got >>> >> closed down silently I have no confidence in that stuff > anymore. >>> >> >>> > Can we hope that stuff that belongs to Apache commons will be > used >>> > from there or >>> > contributed back instead of growing yet another utility library >>> > that duplicates >>> > commons-[io|lang|codec|beanutils|..]? >>> > Java land is already full of such util libraries serving same >>> > purposes but with >>> > different problems and bugs, so let's try to not do it again. >>> > >>> > Regards, >>> > Alexander Kurtakov >>> > Red Hat Eclipse Team >>> > >>> > >>> >> >>> >> I locally already upgraded a few maven-shared libs without > any >>> >> problems. I think we can get this done in 1 week + another > week >>> >> of >>> >> cleaning up the obsolete code as Kristian proposed in the > other >>> >> mail. >>> >> >>> >> Wdyt? When may I start with the transition? >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >> >> --------------------------------------------------------------------- >>> >> 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]
