Re: Regression in model interpolation coming from using JSR-330?
The index generator is very simple and just indexes named classes, which makes it very fast with negligible impact on the build. To spot this kind of ambiguity at generation time would require a deep analysis of the type hierarchy and caching of those hierarchies to check for overlaps. This would quickly become messy (especially for the case where we're indexing via an annotation processor) compared to checking at runtime. Also in some ways this is better handled by application ITs. The container doesn't really have enough context to definitively say "this is wrong" because it could be that the developer intended to have multiple implementations and plans to have them all injected into a list. It could also be that two implementations happen to share the same superclass or interface which would make them ambiguous if someone asked for an implementation at that particular type level, but in reality they are only ever injected as different sub-types where there is no ambiguity. Compare this to checking at the application level: when adding a replacement component you'd just need an IT confirming that new component is being used. Most of the time the replacement is there to fix a bug, so you'd expect regression tests to catch if it wasn't used. Other reasons to rewrite or replace a component are performance related, in which case you might also expect a performance related IT to verify the new implementation is having an effect. On Thu, 7 Nov 2019 at 03:08, Gabriel Belingueres wrote: > @Hervé: The patch worked fine. Thanks! > > @Stuart: In the light that the model interpolator was the only case found, > that is, both equally qualifying classes were located inside the same > javax.injected.Named file, I wonder if it would be easier to check for > ambiguities at generation time, in the sisu-maven-plugin (adding an > optional parameter to fail the build if this kind of case is found). WDYT? > > Regards, > Gabriel > > > El mié., 6 de nov. de 2019 a la(s) 13:39, Herve Boutemy ( > hbout...@apache.org) > escribió: > > > MNG-6799 issue created [1] > > proposed fix added to the reproducible branch [2] by simply removing the > > @Named annotation for the deprecated StringSearchModelInterpolator: CI > > seems ok > > ok for merge? > > > > Regards, > > > > Hervé > > > > [1] https://issues.apache.org/jira/browse/MNG-6799 > > > > [2] > > > https://github.com/apache/maven/commit/16961b32b7dccbc9447ed4e18b4e0949d5fe3b56 > > > > On 2019/11/03 21:27:21, Stuart McCulloch wrote: > > > I did a quick review of the various components in core > > > and StringVisitorModelInterpolator / StringSearchModelInterpolator > > appears > > > to be the only case where a role (ModelInterpolator) has two > non-default > > > implementations and another component only asks for the first > > > implementation. There are other roles which have multiple > > implementations, > > > but in those cases that's expected because each implementation has a > > > specific name and handles a specific case (see the various > > ProfileActivator > > > implementations which are all then injected into a list in > > > DefaultProfileSelector.) > > > > > > It also appears that StringVisitorModelInterpolator was only added > > recently > > > - if it's meant to be a replacement of StringSearchModelInterpolator > then > > > one option would be to simply remove StringSearchModelInterpolator. > > > Alternatively if StringSearchModelInterpolator is needed to be kept > > around > > > for compatibility reasons (such as someone directly extending it > outside > > of > > > Maven) then the Named annotation could be removed > > > from StringSearchModelInterpolator so it isn't automatically picked up. > > > > > > Wrt. extra checks, checking for multiple implementations in the same > > > realm/classloader that haven't been given specific names is a > > possibility - > > > you can open feature requests at > > > https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu > > > > > > On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres < > belingue...@gmail.com> > > > wrote: > > > > > > > Hi Hervé: > > > > > > > > I was thinking in the lines of some checking at the maven core level > > only, > > > > enough to detect problems and ensure there are no regressions. > > > > > > > > At the plugin level, I guess the assurance that the right component > is > > > > injected can be checked with an integration test. > > > > > > > > The way I realized the problem was that I was adding some logging > > traces > > > > into the StringVisitorModelInterpolator class but *nothing* showed > > (even > > > > the build was successful and the interpolation indeed was happening > > > > somewhere). Then added the same logging lines to > > > > StringSearchModelInterpolator, and the logging appeared in the build, > > which > > > > confirmed the issue. (I didn't test if there are any other component > > with > > > > the same problem.) > > > > > > > > El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé
Re: Regression in model interpolation coming from using JSR-330?
@Hervé: The patch worked fine. Thanks! @Stuart: In the light that the model interpolator was the only case found, that is, both equally qualifying classes were located inside the same javax.injected.Named file, I wonder if it would be easier to check for ambiguities at generation time, in the sisu-maven-plugin (adding an optional parameter to fail the build if this kind of case is found). WDYT? Regards, Gabriel El mié., 6 de nov. de 2019 a la(s) 13:39, Herve Boutemy (hbout...@apache.org) escribió: > MNG-6799 issue created [1] > proposed fix added to the reproducible branch [2] by simply removing the > @Named annotation for the deprecated StringSearchModelInterpolator: CI > seems ok > ok for merge? > > Regards, > > Hervé > > [1] https://issues.apache.org/jira/browse/MNG-6799 > > [2] > https://github.com/apache/maven/commit/16961b32b7dccbc9447ed4e18b4e0949d5fe3b56 > > On 2019/11/03 21:27:21, Stuart McCulloch wrote: > > I did a quick review of the various components in core > > and StringVisitorModelInterpolator / StringSearchModelInterpolator > appears > > to be the only case where a role (ModelInterpolator) has two non-default > > implementations and another component only asks for the first > > implementation. There are other roles which have multiple > implementations, > > but in those cases that's expected because each implementation has a > > specific name and handles a specific case (see the various > ProfileActivator > > implementations which are all then injected into a list in > > DefaultProfileSelector.) > > > > It also appears that StringVisitorModelInterpolator was only added > recently > > - if it's meant to be a replacement of StringSearchModelInterpolator then > > one option would be to simply remove StringSearchModelInterpolator. > > Alternatively if StringSearchModelInterpolator is needed to be kept > around > > for compatibility reasons (such as someone directly extending it outside > of > > Maven) then the Named annotation could be removed > > from StringSearchModelInterpolator so it isn't automatically picked up. > > > > Wrt. extra checks, checking for multiple implementations in the same > > realm/classloader that haven't been given specific names is a > possibility - > > you can open feature requests at > > https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu > > > > On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres > > wrote: > > > > > Hi Hervé: > > > > > > I was thinking in the lines of some checking at the maven core level > only, > > > enough to detect problems and ensure there are no regressions. > > > > > > At the plugin level, I guess the assurance that the right component is > > > injected can be checked with an integration test. > > > > > > The way I realized the problem was that I was adding some logging > traces > > > into the StringVisitorModelInterpolator class but *nothing* showed > (even > > > the build was successful and the interpolation indeed was happening > > > somewhere). Then added the same logging lines to > > > StringSearchModelInterpolator, and the logging appeared in the build, > which > > > confirmed the issue. (I didn't test if there are any other component > with > > > the same problem.) > > > > > > El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé BOUTEMY ( > > > herve.bout...@free.fr) escribió: > > > > > > > nice idea, but overriding by adding a new implementation in > classpath is > > > > the > > > > normal overriding way: not sure how "ambiguity checker" could make a > > > > difference > > > > between such wanted override vs unwanted ambiguity > > > > > > > > BTW, how did you see that StringVisitorModelInterpolator was not > used but > > > > StringSearchModelInterpolator instead, please? > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a > écrit : > > > > > Thanks Stuart. > > > > > > > > > > The reproducibility PR you mention helps in having a deterministic > > > > ordering > > > > > inside the Named components file to buld exactly the same > executable, > > > but > > > > > it does not mean it is the right priority for component injection. > > > > > > > > > > Do you know if it is possible to configure sisu to throw an > exception > > > if > > > > > trying to inject an ambiguous component? Otherwise, I guess we must > > > > > implement some sort of "ambiguity checker", either as an > integration > > > test > > > > > (don't know if it is possible) or either built-it into maven > > > executable. > > > > > > > > > > > > > > > > > > > > > > > > > El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch ( > > > > > > > > > > mccu...@gmail.com) escribió: > > > > > > Yes, when there are multiple non-default implementations with the > > > same > > > > > > priority then it will pick the first in the list (where the > "list" in > > > > > > question is actually a combination of plugins + extensions + core > > > > > > bindings for the given type) > > > > > > > > > > > > If
compiler uses Jar instead of target/classes
I have a problem with maven-compiler-plugin in multimodule project where the Jar files appear in classpath and not target/classes. Module B depends on A but A uses maven-shade-plugin to relocate Shared Utils dependency in A. Suddenly B fails because cannot find relocated packages of Shared Utils. The compiler uses A.jar instead of A/target/classes. Cheers Tibor17
Re: Regression in model interpolation coming from using JSR-330?
MNG-6799 issue created [1]
proposed fix added to the reproducible branch [2] by simply removing the @Named
annotation for the deprecated StringSearchModelInterpolator: CI seems ok
ok for merge?
Regards,
Hervé
[1] https://issues.apache.org/jira/browse/MNG-6799
[2]
https://github.com/apache/maven/commit/16961b32b7dccbc9447ed4e18b4e0949d5fe3b56
On 2019/11/03 21:27:21, Stuart McCulloch wrote:
> I did a quick review of the various components in core
> and StringVisitorModelInterpolator / StringSearchModelInterpolator appears
> to be the only case where a role (ModelInterpolator) has two non-default
> implementations and another component only asks for the first
> implementation. There are other roles which have multiple implementations,
> but in those cases that's expected because each implementation has a
> specific name and handles a specific case (see the various ProfileActivator
> implementations which are all then injected into a list in
> DefaultProfileSelector.)
>
> It also appears that StringVisitorModelInterpolator was only added recently
> - if it's meant to be a replacement of StringSearchModelInterpolator then
> one option would be to simply remove StringSearchModelInterpolator.
> Alternatively if StringSearchModelInterpolator is needed to be kept around
> for compatibility reasons (such as someone directly extending it outside of
> Maven) then the Named annotation could be removed
> from StringSearchModelInterpolator so it isn't automatically picked up.
>
> Wrt. extra checks, checking for multiple implementations in the same
> realm/classloader that haven't been given specific names is a possibility -
> you can open feature requests at
> https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu
>
> On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres
> wrote:
>
> > Hi Hervé:
> >
> > I was thinking in the lines of some checking at the maven core level only,
> > enough to detect problems and ensure there are no regressions.
> >
> > At the plugin level, I guess the assurance that the right component is
> > injected can be checked with an integration test.
> >
> > The way I realized the problem was that I was adding some logging traces
> > into the StringVisitorModelInterpolator class but *nothing* showed (even
> > the build was successful and the interpolation indeed was happening
> > somewhere). Then added the same logging lines to
> > StringSearchModelInterpolator, and the logging appeared in the build, which
> > confirmed the issue. (I didn't test if there are any other component with
> > the same problem.)
> >
> > El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé BOUTEMY (
> > herve.bout...@free.fr) escribió:
> >
> > > nice idea, but overriding by adding a new implementation in classpath is
> > > the
> > > normal overriding way: not sure how "ambiguity checker" could make a
> > > difference
> > > between such wanted override vs unwanted ambiguity
> > >
> > > BTW, how did you see that StringVisitorModelInterpolator was not used but
> > > StringSearchModelInterpolator instead, please?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> > > > Thanks Stuart.
> > > >
> > > > The reproducibility PR you mention helps in having a deterministic
> > > ordering
> > > > inside the Named components file to buld exactly the same executable,
> > but
> > > > it does not mean it is the right priority for component injection.
> > > >
> > > > Do you know if it is possible to configure sisu to throw an exception
> > if
> > > > trying to inject an ambiguous component? Otherwise, I guess we must
> > > > implement some sort of "ambiguity checker", either as an integration
> > test
> > > > (don't know if it is possible) or either built-it into maven
> > executable.
> > > >
> > > >
> > > >
> > > >
> > > > El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> > > >
> > > > mccu...@gmail.com) escribió:
> > > > > Yes, when there are multiple non-default implementations with the
> > same
> > > > > priority then it will pick the first in the list (where the "list" in
> > > > > question is actually a combination of plugins + extensions + core
> > > > > bindings for the given type)
> > > > >
> > > > > If a particular implementation should be treated as the default then
> > it
> > > > > should either start with "Default" or be annotated with
> > > @Named("default")
> > > > > -
> > > > > the benefit of this approach is that it documents that this is the
> > > default
> > > > > implementation, to be favoured over the others. Alternatively if you
> > > want
> > > > > to have an ordering between implementations then you can use
> > @Priority
> > > to
> > > > > assign specific priorities and favour one over the other.
> > > > >
> > > > > If you don't mark an implementation as default and don't define any
> > > > > priorities then the only current guarantees are that implementations
> > in
> > > > > plugins and extensions will be favoured
Re: Apache Wagon vs maven-shade vs embedded licenses
Hervè can we fix this issue before releasing this version of Wagon ? this way we can update Wagon in Maven Core Enrico Il giorno mer 6 nov 2019 alle ore 11:06 ha scritto: > issue created: https://issues.apache.org/jira/browse/WAGON-574 > > Regards, > > Hervé > > - Mail original - > De: "Enrico Olivelli" > À: "Maven Developers List" > Cc: "Hervé BOUTEMY" > Envoyé: Mercredi 6 Novembre 2019 09:53:29 > Objet: Re: Apache Wagon vs maven-shade vs embedded licenses > > > > > > > > Il giorno mer 6 nov 2019 alle ore 09:03 Vladimir Sitnikov < > sitnikov.vladi...@gmail.com > ha scritto: > > > Enrico>(I apologize, I don't want to pollute the vote thread, but this is > somehow > related) > > I've altered the subject. > > Enrico> For binary release (that actually is not part of the official > VOTE) > > I'm not a lawyer, but: > > > http://www.apache.org/legal/release-policy.html#what > > WHAT IS A RELEASE? > > Releases are, by definition, anything that is published beyond the group > that owns it > > > > > http://www.apache.org/legal/release-policy.html#what-must-every-release-contain > > Every ASF release must comply with ASF licensing policy > > release-policy.html does not make a distinction between "part of the > official vote" and "not a part of the official vote". > It just stays "whatever is released must comply with ASF licensing > policy". > > > > > > Totally agree > > > > In other words, the VOTE thread looks to me like "we are about to release > Apache Maven Wagon, please check the artifacts". > -shaded artifact is a part of the release (because it is "anything that is > published beyond the group that owns it"), > and -shaded does not comply with jsoup's license ==> I suggest that > there's > an "utmost importance" issue with the artifacts. > > >I wonder if we could enhance the pom in the future to report machiene > >readable statements like 'the artifact will include a binary copy of this > >other third party pom' > > That would be nice. I'm not sure everything comes from a pom though. > For instance, -shaded, -sources, -javadoc and other "classifier-based > artifacts" miss their respective poms. > However, they all might re-distribute different third-party dependencies. > > > > Yes, it is not so simply as I said. > > > > Then people do not always consume artifacts as jar/pom files. > For instance, apache-maven-3.6.2-bin.zip does not have a pom file. > > In my opinion, the licensing conditions should be embedded into each > archive if that is possible. > > > > I think this is the only viable option nowadays > > > > There's spdx.org effort, however, I don't think it is ready for use. > > Vladimir > > > > > > Thanks > > > Enrico > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Apache Wagon vs maven-shade vs embedded licenses
issue created: https://issues.apache.org/jira/browse/WAGON-574 Regards, Hervé - Mail original - De: "Enrico Olivelli" À: "Maven Developers List" Cc: "Hervé BOUTEMY" Envoyé: Mercredi 6 Novembre 2019 09:53:29 Objet: Re: Apache Wagon vs maven-shade vs embedded licenses Il giorno mer 6 nov 2019 alle ore 09:03 Vladimir Sitnikov < sitnikov.vladi...@gmail.com > ha scritto: Enrico>(I apologize, I don't want to pollute the vote thread, but this is somehow related) I've altered the subject. Enrico> For binary release (that actually is not part of the official VOTE) I'm not a lawyer, but: > http://www.apache.org/legal/release-policy.html#what > WHAT IS A RELEASE? > Releases are, by definition, anything that is published beyond the group that owns it > http://www.apache.org/legal/release-policy.html#what-must-every-release-contain > Every ASF release must comply with ASF licensing policy release-policy.html does not make a distinction between "part of the official vote" and "not a part of the official vote". It just stays "whatever is released must comply with ASF licensing policy". Totally agree In other words, the VOTE thread looks to me like "we are about to release Apache Maven Wagon, please check the artifacts". -shaded artifact is a part of the release (because it is "anything that is published beyond the group that owns it"), and -shaded does not comply with jsoup's license ==> I suggest that there's an "utmost importance" issue with the artifacts. >I wonder if we could enhance the pom in the future to report machiene >readable statements like 'the artifact will include a binary copy of this >other third party pom' That would be nice. I'm not sure everything comes from a pom though. For instance, -shaded, -sources, -javadoc and other "classifier-based artifacts" miss their respective poms. However, they all might re-distribute different third-party dependencies. Yes, it is not so simply as I said. Then people do not always consume artifacts as jar/pom files. For instance, apache-maven-3.6.2-bin.zip does not have a pom file. In my opinion, the licensing conditions should be embedded into each archive if that is possible. I think this is the only viable option nowadays There's spdx.org effort, however, I don't think it is ready for use. Vladimir Thanks Enrico - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Wagon vs maven-shade vs embedded licenses
Il giorno mer 6 nov 2019 alle ore 09:03 Vladimir Sitnikov < sitnikov.vladi...@gmail.com> ha scritto: > Enrico>(I apologize, I don't want to pollute the vote thread, but this is > somehow > related) > > I've altered the subject. > > Enrico> For binary release (that actually is not part of the official VOTE) > > I'm not a lawyer, but: > > > http://www.apache.org/legal/release-policy.html#what > > WHAT IS A RELEASE? > > Releases are, by definition, anything that is published beyond the group > that owns it > > > > > http://www.apache.org/legal/release-policy.html#what-must-every-release-contain > > Every ASF release must comply with ASF licensing policy > > release-policy.html does not make a distinction between "part of the > official vote" and "not a part of the official vote". > It just stays "whatever is released must comply with ASF licensing policy". > Totally agree > > In other words, the VOTE thread looks to me like "we are about to release > Apache Maven Wagon, please check the artifacts". > -shaded artifact is a part of the release (because it is "anything that is > published beyond the group that owns it"), > and -shaded does not comply with jsoup's license ==> I suggest that there's > an "utmost importance" issue with the artifacts. > > >I wonder if we could enhance the pom in the future to report machiene > >readable statements like 'the artifact will include a binary copy of this > >other third party pom' > > That would be nice. I'm not sure everything comes from a pom though. > For instance, -shaded, -sources, -javadoc and other "classifier-based > artifacts" miss their respective poms. > However, they all might re-distribute different third-party dependencies. > Yes, it is not so simply as I said. > > Then people do not always consume artifacts as jar/pom files. > For instance, apache-maven-3.6.2-bin.zip does not have a pom file. > > In my opinion, the licensing conditions should be embedded into each > archive if that is possible. > I think this is the only viable option nowadays > > There's spdx.org effort, however, I don't think it is ready for use. > > Vladimir > Thanks Enrico
Apache Wagon vs maven-shade vs embedded licenses
Enrico>(I apologize, I don't want to pollute the vote thread, but this is somehow related) I've altered the subject. Enrico> For binary release (that actually is not part of the official VOTE) I'm not a lawyer, but: > http://www.apache.org/legal/release-policy.html#what > WHAT IS A RELEASE? > Releases are, by definition, anything that is published beyond the group that owns it > http://www.apache.org/legal/release-policy.html#what-must-every-release-contain > Every ASF release must comply with ASF licensing policy release-policy.html does not make a distinction between "part of the official vote" and "not a part of the official vote". It just stays "whatever is released must comply with ASF licensing policy". In other words, the VOTE thread looks to me like "we are about to release Apache Maven Wagon, please check the artifacts". -shaded artifact is a part of the release (because it is "anything that is published beyond the group that owns it"), and -shaded does not comply with jsoup's license ==> I suggest that there's an "utmost importance" issue with the artifacts. >I wonder if we could enhance the pom in the future to report machiene >readable statements like 'the artifact will include a binary copy of this >other third party pom' That would be nice. I'm not sure everything comes from a pom though. For instance, -shaded, -sources, -javadoc and other "classifier-based artifacts" miss their respective poms. However, they all might re-distribute different third-party dependencies. Then people do not always consume artifacts as jar/pom files. For instance, apache-maven-3.6.2-bin.zip does not have a pom file. In my opinion, the licensing conditions should be embedded into each archive if that is possible. There's spdx.org effort, however, I don't think it is ready for use. Vladimir
