On Aug 30, 2012, at 9:07 AM, Mark Struberg wrote: >> If you are attempting to remove plexus-utils initially without a > >> binary compatible drop-in replacement with code from Apache then I'm -1. > > Please re-read my previous mail. We will NOT drop plexus-utils! We will just > move maven core off it for most parts. >
Hmm, what's the difference exactly? > >> we've had incremental build support in m2e forever > You don't see most of the 'incremental' problems in m2 because the recompile > already gets done by eclipse itself I assume. E.g. the maven-compiler-plugin > until recently failed to detect cross-class relations and did only recompile > the file which got changed. I changed that only recently. > The compiler is not the problem, even for large code bases the compiler is incredibly fast. Profile your average build and it's not the compilation that's the bottleneck. But again I would argue you don't need to make drastic changes in the core to make incremental builds work. Some, but they are few. > > LieGrue, > strub > > >> ________________________________ >> From: Jason van Zyl <ja...@tesla.io> >> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg >> <strub...@yahoo.de> >> Sent: Thursday, August 30, 2012 2:49 PM >> Subject: Re: Removing unused code from maven-shared-utils >> >> You need to do one thing at time and not conflate the replacement of the >> plexus-utils code with anything else you want to implement. Mixing the two >> will almost certainly lead to problems. >> >> If you are attempting to remove plexus-utils initially without a binary >> compatible drop-in replacement with code from Apache then I'm -1. I'm not >> going to change that position because I think you're needlessly causing >> problems. If you want to replace the code go for it, just do it safely. >> >> Incremental builds are a separate matter all together and can be done in a >> branch, we've had incremental build support in m2e forever and you don't >> need to massively change the core at all to do it. In fact it works right >> now with the core as it is. Put a complete proposal together (I've seen the >> initial ideas) because if you think you need to drastically change the core >> for incremental builds I believe you are incorrect. >> >> At any rate, one thing at a time. If you want to replace the code in >> plexus-utils with something else do that first as a separate, clear endeavor. >> >> On Aug 30, 2012, at 8:40 AM, Mark Struberg wrote: >> >>> I fear my perspective is pretty different. >>> >>> >>> To _not_ produce a 1:1 drop in replacement gives us a few benefits. >>> Actually it doesn't matter which version maven itself uses as this wont >>> affect user builds. >>> >>> BUT it would _heavily_ affect users if their old builds wont work anymore >>> because we dropped some ancient signature. >>> >>> And there is a well cast technical reason for this change: I need >>> new/improved functionality for the incremental build. >>> >>> >>> My proposal is to move maven itself to a much more progressive/improved >>> version (thus off plexus-utils) but keep the old signatures and the >>> original plexus-utils around for plugins which still uses it. >>> >>> If a plugin likes to use the new maven-core-utils then this is perfectly >>> possible as well of course. >>> >>> LieGrue, >>> strub >>> >>>> ________________________________ >>>> From: Jason van Zyl <ja...@tesla.io> >>>> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg >>>> <strub...@yahoo.de> >>>> Sent: Thursday, August 30, 2012 2:24 PM >>>> Subject: Re: Removing unused code from maven-shared-utils >>>> >>>> >>>> If you can create a drop-in replacement for the plexus-utils code go for >>>> it. I believe this exercise is of little value users and you run the real >>>> risk of introducing problems for no technical reason, but if you want to >>>> do the work that's your prerogative. >>>> >>>> >>>> So much time was spent to preserve the existing signatures and behaviour >>>> in the container swap and this is not something to be taken lightly, and >>>> you should do what has been done in the past. >>>> >>>> >>>> I think the path to do this if you want to get rid of the plexus-utils >>>> reference is to reduce the foot print to the classes being used in the >>>> core and then drop in that reduced JAR. Create a replacement with the code >>>> you've copied, reimplemented, improved yet binary compatible and test that >>>> for a while. Binary compatible in all respects, package and signature. And >>>> from there then make any subsequent changes. >>>> >>>> >>>> I honestly am not overly concerned with plugins because they can be fixed >>>> relatively quickly, but doing low value changes in the core for swapping >>>> out one set of code for another is seriously playing with fire. >>>> >>>> >>>> If you initially are intending to change code in the core to accommodate >>>> this change I see no technical reason for it, is dangerous and I'm -1. >>>> >>>> >>>> On Aug 30, 2012, at 8:03 AM, Mark Struberg wrote: >>>> >>>> While digging thru the plexus-utils usage I wonder whether we should place >>>> the maven-utils in maven-core or maven-shared. >>>>> >>>>> maven-core doesn't yet have any maven-shared dependency it seems. Which >>>>> means if we like to use them in maven-core as well we should relocate >>>>> maven-shared-utils to the maven-3 core module. >>>>> >>>>> wdyt? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> From: Kristian Rosenvold <kristian.rosenv...@gmail.com> >>>>>> >>>>> To: Maven Developers List <dev@maven.apache.org> >>>>>> >>>>> Cc: >>>>>> >>>>> Sent: Thursday, August 30, 2012 10:48 AM >>>>>> >>>>> Subject: Re: Removing unused code from maven-shared-utils >>>>>> >>>>> >>>>>> >>>>> Well obviously given the current number of failing >>>>>> >>>>> tests,maven-shared-utils is going nowhere right now ;) >>>>>> >>>>> >>>>>> >>>>> I will do a test-migration and remove unused code in >>>>>> >>>>> org.apache.maven.shared.utils.io before we release. >>>>>> >>>>> >>>>>> >>>>> Kristian >>>>>> >>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>>> >>>>> 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 >>>>> >>>>> >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder & CTO, Sonatype >>>> Founder, Apache Maven >>>> http://twitter.com/jvanzyl >>>> --------------------------------------------------------- >>>> >>>> >>>> What matters is not ideas, but the people who have them. Good people can >>>> fix bad ideas, but good ideas can't save bad people. >>>> >>>> -- Paul Graham >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> happiness is like a butterfly: the more you chase it, the more it will >> elude you, but if you turn your attention to other things, it will come >> and sit softly on your shoulder ... >> >> -- Thoreau >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
