> 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]
