On Aug 30, 2012, at 9:16 AM, Mark Struberg wrote:

> 
> 
> If the compiler doesn't reliably detect changes, then it is a HUGE problem!
> 

In what cases does that happen?

Your document[1] doesn't indicate this is a problem.

[1]: https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds


> All the later stages can only depend on the results of the previous ones. To 
> not trigger a necessary rebuild is WAY worse than to rebuild a few classes 
> too much.
> 
> Exactly that is the reason why most people always use "mvn CLEAN install" all 
> the time currently.
> 
> 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 3:11 PM
>> Subject: Re: Removing unused code from maven-shared-utils
>> 
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

We know what we are, but know not what we may be.

  -- Shakespeare





Reply via email to