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
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
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
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,
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
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
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
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.
>
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
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
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
11 matches
Mail list logo