MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Stephen Connolly
Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2] I understand why the change[3] was made... but this change breaks about 80-90% of the use cases for the shade plugin... Is there any way we can consider a compromise? I think it should be permitted for a plugin to replace the

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Jason van Zyl
The core model has to be mutable. I think there can be an ancillary model that carried other types of information like the dependency reduction. But mutation and re-consumption within the reactor I think is a bad idea and the complication enumerated below seems fairly extreme. Do you have a

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Stephen Connolly
I like the idea of a shaded-jar if we can make it work... though it does mean that anyone consuming poms outside of Maven will no longer be able to build the dependency graph without being aware of this special packaging... (plus there is also a set of use-cases from the flatten-maven-plugin and

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Igor Fedorenko
I think this only highlights the need to have immutable core model. The bundle plugin has no way to know how the shade plugin manipulates the pom and the generated bundle manifest will be based on original project model. (assuming I understand your suggested usecase) -- Regards, Igor On Tue,

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Jason van Zyl
So I think we have then opportunity to model this correctly and we have something similar already in a WAR. We have a handler that clips all transitive dependencies. There would be a bit more work but if we make a separate packaging, build out the classpath correctly during the build we can

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Uwe Barthel
On October 27, 2015 4:08:11 PM Jason van Zyl wrote: So I think we have then opportunity to model this correctly and we have something similar already in a WAR. We have a handler that clips all transitive dependencies. There would be a bit more work but if we make a separate

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Benson Margulies
On Tue, Oct 27, 2015 at 10:40 AM, Igor Fedorenko wrote: > I think this only highlights the need to have immutable core model. The > bundle plugin has no way to know how the shade plugin manipulates the > pom and the generated bundle manifest will be based on original project

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Jason van Zyl
If we went this route, it would be a new packaging type you opt into. It would purely be an additive change so wouldn’t affect any existing behaviour but only taking advantage of what we have for something like the WAR file. We may find this is insufficient but I don’t know without trying. >

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Jason van Zyl
No, I meant immutable. > On Oct 27, 2015, at 6:58 AM, Igor Fedorenko wrote: > > Did you really mean "the core model has to be mutable"? The rest of your > message appears to suggest you do not want the model to be mutable, but > I am not sure. > > In any case, I think the

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Benson Margulies
On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko wrote: > Did you really mean "the core model has to be mutable"? The rest of your > message appears to suggest you do not want the model to be mutable, but > I am not sure. > > In any case, I think the core model must not be

Re: MNG-5899 Project models are no longer mutable in reactor

2015-10-27 Thread Igor Fedorenko
Did you really mean "the core model has to be mutable"? The rest of your message appears to suggest you do not want the model to be mutable, but I am not sure. In any case, I think the core model must not be mutable. If the core model is mutable, this means pom.xml is not the ultimate source of