Re: [VOTE] Release Maven Project Info Reports Plugin version 3.6.1

[Gabriel Belingueres]

+1

El dom, 23 jun 2024 a la(s) 4:12 p.m., Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12354845
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2154/
>
> https://repository.apache.org/content/repositories/maven-2154/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.1/maven-project-info-reports-plugin-3.6.1-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.6.1-source-release.zip
> sha512:
>
> b9f3b470184dbbe11f4a9a2fdfd782425debed63fbc9f36043c82f476b537b46f258a719d2465d8c7baeb3cc4ca58103931977b4e90adfa5752fcab5ee975542
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Shared JAR version 3.1.1

[Gabriel Belingueres]

+1

El jue, 20 jun 2024 a la(s) 5:47 p.m., Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12354836
>
> There is one issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-jar
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2153/
>
> https://repository.apache.org/content/repositories/maven-2153/org/apache/maven/shared/maven-shared-jar/3.1.1/maven-shared-jar-3.1.1-source-release.zip
>
> Source release checksum(s):
> maven-shared-jar-3.1.1-source-release.zip
> sha512:
>
> ceb9b5cd717a2c9facae5908b7cbd7ff840933c153af367a41418371780ac4fbd5b09d733274ba272f5f37a2d03be6366d2195173cd723fcfb0089b28ed2aa1f
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Gabriel Belingueres]

+1

Thanks!

El jue, 13 jun 2024 a la(s) 1:49 p.m., Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12354774
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2147/
>
> https://repository.apache.org/content/repositories/maven-2147/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.6.0-source-release.zip
> sha512:
>
> 72691f1affac507ccbaa908d1c03386accaf59384ec7b388c8b944389074861b334fd306af00d2b706a99401bd4c29f650f594dbc1cf22c3fecd1d3e7e7c140d
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Shared JAR version 3.1.0

[Gabriel Belingueres]

+1


El sáb, 1 jun 2024 a la(s) 4:57 p.m., Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12353160
>
> There are no issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-jar
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2137/
>
> https://repository.apache.org/content/repositories/maven-2137/org/apache/maven/shared/maven-shared-jar/3.1.0/maven-shared-jar-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-shared-jar-3.1.0-source-release.zip
> sha512:
>
> 1b8d9c03a09681ab0e1a4c5ecbe8b26fd2b5d44eab2364d4bc81fc058d0f2ddde2ed09acc88582fd875a41fc5eb49b7d21c9a39c25b9aa496e97435fafbbd20e
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.5

[Gabriel Belingueres]

+1


El sáb, 3 jun 2023 a la(s) 10:10, Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12353297
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1951/
>
> https://repository.apache.org/content/repositories/maven-1951/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.5/maven-project-info-reports-plugin-3.4.5-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.4.5-source-release.zip
> sha512:
>
> 75631dc43b83190bceab61f7311d620824bf1d8c8efd406014c287021fa4aeedb6fc40fd111f8ecc7c742bc1ae55ba039fec65bb3bba3cf6a8f514cb9bbc44e6
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4

[Gabriel Belingueres]

+1

Thanks!

El vie, 26 may 2023 a la(s) 16:29, Michael Osipov (micha...@apache.org)
escribió:

> Hi,
>
> we solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12353222
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1948/
>
> https://repository.apache.org/content/repositories/maven-1948/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-reports-plugin-3.4.4-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.4.4-source-release.zip
> sha512:
>
> c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Shared Dependency Tree 3.3.1

[Gabriel Belingueres]

+1

Kind regards,
Gabriel

El sáb, 14 may 2022 a la(s) 08:00, Slawomir Jaranowski (
s.jaranow...@gmail.com) escribió:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12350387
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-tree
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1751/
>
> https://repository.apache.org/content/repositories/maven-1751/org/apache/maven/shared/maven-dependency-tree/3.1.1/maven-dependency-tree-3.1.1-source-release.zip
>
> Source release checksum(s):
> maven-dependency-tree-3.1.1-source-release.zip - SHA-512 :
>
> 237bf7a64082d13955c2fdcf52da032b960501551d9ea76e6ecc262be9cd1c60c3830f5a223b803d04888e3654e9fcdb87f9904c36b0bc58def7425b030fe900
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-tree-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>

Re: [CANCELLED] [VOTE] Release Apache Maven Shared Component: Maven Artifact Transfer Version 0.13.0

[Gabriel Belingueres]

Hi Karl:

IIRC the way to give access to the classes in the aether-utils package is
to invoke

MavenAetherUtils.importAetherLibrary();

inside the plugin.

HTH.
Gabriel

El sáb., 2 de may. de 2020 a la(s) 16:17, Karl Heinz Marbaise (
khmarba...@gmx.de) escribió:

> Hi,
>
> so after bisecting the issue in artifact-transfer I found the problem..
>
>Revert "[MSHARED-817] Change eclipse aether dependency scope to
> provided"
>
>  This reverts commit 5d86480fcdf4f7ae779aec9c7444ad7b709eaa04.
>
>
> Using this will run fine with maven-deploy-plugin with all IT's
> ok...which fails several IT's in maven-deploy-plugin if using
> artifact-transfer without the revert...
>
> Related to that there was a discussion on GitHub[3] about the change in
> artifact-transfer which is related to [2]...I'm diving more into
> that...and trying to find out what the real issue is based on that
> commit. Changing the scope from compile to provided of
> org.eclipse.aether:aether-util which contains the missed class
> (SubArtifact.class) or is it related no more shading and transporting
> that class as part of artifact transfer...
>
> What I've understood so far is that shading this class makes it working
> with Maven versions from 3.1.1 up to 3.3.3(?) related to [1]...which is
> related to the part that it has been excluded via
> maven-core/src/main/resources/META-INF/maven/extension.xml
>
>
> Currently I'm figuring out why some core IT's are failing on my machine
> (Mac OS)...needs more testing...(investigating).
>
> Furthermore it showed that we need more IT's in artifact-transfer to see
> such issues earlier...
>
>
> Kind regards
> Karl Heinz Marbaise
> [1]: https://issues.apache.org/jira/browse/MNG-5901
> [2]: https://issues.apache.org/jira/browse/MSHARED-817
> [3]: https://github.com/apache/maven-artifact-transfer/pull/2
>
>
> On 02.05.20 11:58, Karl Heinz Marbaise wrote:
> > Hi,
> > I cancel the VOTE based on the found issues.
> >
> > Thanks Michael for finding this.
> >
> >
> > On 01.05.20 20:39, Karl Heinz Marbaise wrote:
> >> Hi,
> >>
> >> We have solved 17 issues:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12346567
> >>
> >>
> >>
> >> There are still a couple of issues left in JIRA:
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >>
> >>
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-1570
> >>
> >>
> https://repository.apache.org/service/local/repositories/maven-1570/content/org/apache/maven/shared/maven-artifact-transfer/0.13.0/maven-artifact-transfer-0.13.0-source-release.zip
> >>
> >>
> >>
> >> Source release checksum(s):
> >> maven-artifact-transfer-0.13.0-source-release.zip sha512:
> >>
> d4a99a889f31c14c9234e744830e55a09535f21eb35125d02677de85180821c516f41f7ee914370bf432edd171f87d485a7464a4a42ccb2c192e1a92fb5d00bdtarget
> >>
> >>
> >>
> >> Staging site:
> >>
> https://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/
> >>
> >> Guide to testing staged releases:
> >> https://maven.apache.org/guides/development/guide-testing-releases.html
> >>
> >> Vote open for at least 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> -
> >> 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
> >
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen   https://www.soebes.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Proposal to deprecate Maven 3.0.x

[Gabriel Belingueres]

+1 to deprecate 3.0.x to get rid of Sonatype Aether, which would
considerably simplify the dependency handling code base.

Not my use case, but,just to put it over the table, we should check the
Eclipse Aether New and Noteworthy page [1] to see if there is some
particular requirement over aether library that we want to take for granted.

I've looked for each aether version used by maven and I came up with the
following list:

"3.0.0" <-- Sonatype Aether 1.7
"3.0.1" <-- Sonatype Aether 1.8
"3.0.2" <-- Sonatype Aether 1.9
"3.0.3" <-- Sonatype Aether 1.11
"3.0.4" <-- Sonatype Aether 1.13.1
"3.0.5" <-- Sonatype Aether 1.13.1

"3.1.0" <-- Eclipse Aether 0.9.0M2
"3.1.1" <-- Eclipse Aether 0.9.0M2
"3.2.1" <-- Eclipse Aether 0.9.0M2
"3.2.2" <-- Eclipse Aether 0.9.0M2
"3.2.3" <-- Eclipse Aether 0.9.0M2

"3.2.5" <-- Eclipse Aether 1.0.0.v20140518

"3.3.1" <-- Eclipse Aether 1.0.2.v20150114
"3.3.3" <-- Eclipse Aether 1.0.2.v20150114
"3.3.9" <-- Eclipse Aether 1.0.2.v20150114

"3.5.0" <-- Maven Resolver 1.0.3

"3.5.2" <-- Maven Resolver 1.1.0

"3.5.3" <-- Maven Resolver 1.1.1
"3.5.4" <-- Maven Resolver 1.1.1

"3.6.0" <-- Maven Resolver 1.3.1

"3.6.1" <-- Maven Resolver 1.3.3

"3.6.2" <-- Maven Resolver 1.4.1
"3.6.3" <-- Maven Resolver 1.4.1


so for example, let's say if it is really important that the CollectResult
class keeps the detected dependency cycles (0.0.9-M4) then we should think
in deprecating until maven 3.2.3.

Again, not my use case. I'm fine with deprecating 3.0.x.

Best regards,
Gabriel

[1] https://wiki.eclipse.org/Aether/New_and_Noteworthy

El mié., 15 de abr. de 2020 a la(s) 17:39, Tibor Digana (
tibordig...@apache.org) escribió:

> Some users still use Maven 3.0.5 and they require a support for
> compatibility reasons between nowadays Maven plugins and the Maven
> 3.0.x.
>
> We have a couple of reasons to deprecate this version (JSR-330,
> Components injection, Logger) and we have discussed this issue in
> https://github.com/apache/maven-surefire/pull/274
>
> Let's discuss it.
>
> Cheers
> Tibor17
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Eclipse import

[Gabriel Belingueres]

You need to import and open the eclipse projects for each unresolved
dependency.

El jue., 19 de diciembre de 2019 19:28, Elliotte Rusty Harold <
elh...@ibiblio.org> escribió:

> There seems to be something I'm missing about importing projects into
> Eclipse. I can build them at the command line, but they're full of
> errors like
>
> BookModel cannot be resolved to a typeBookContext.java
> /doxia-book-renderer/src/main/java/org/apache/maven/doxia/book/context
>line 113Java Problem
>
> when I import them into Eclipse. m2e seems really confused about
> missing lifecycle configurations.
>
> Is there something I'm missing here?
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven version 3.6.3

[Gabriel Belingueres]

+1 (non binding)

- Built some projects and plugins.
- Built current maven 3.7.0-SNAPSHOT and core ITs.

Environment:
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/gabriel/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: es_AR, platform encoding: UTF-8
OS name: "linux", version: "5.0.0-36-generic", arch: "amd64", family: "unix"

Thanks!
Gabriel

El jue., 21 de nov. de 2019 a la(s) 17:06, Robert Scholte (
rfscho...@apache.org) escribió:

> Hi,
>
> This will be a regression release based on some critical issues discovered
> in Maven 3.6.2
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12346152&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1542/
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.zip
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.tar.gz
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.zip
>
>
> Source release checksum(s):
>
> apache-maven-3.6.3-bin.tar.gz sha512: 
> c35a1803a6e70a126e80b2b3ae33eed961f83ed74d18fcd16909b2d44d7dada3203f1ffe726c17ef8dcca2dcaa9fca676987befeadc9b9f759967a8cb77181c0
>
> apache-maven-3.6.3-bin.zip sha512: 
> 1c095ed556eda06c6d82fdf52200bc4f3437a1bab42387e801d6f4c56e833fb82b16e8bf0aab95c9708de7bfb55ec27f653a7cf0f491acebc541af234eded94d
>
>
> apache-maven-3.6.3-src.tar.gz sha512: 
> 14eef64ad13c1f689f2ab0d2b2b66c9273bf336e557d81d5c22ddb001c47cf51f03bb1465d6059ce9fdc2e43180ceb0638ce914af1f53af9c2398f5d429f114c
>
>
> apache-maven-3.6.3-src.zip sha512: 
> b23b7ae7392eca28ec124cf8ad24bb27405aea5d252d9305bb37a6e317947cc7dc15a564958a113ab75e2010e16c293d6e7c44f7d41d7bad7635d2d76eb4d1ac
>
> Staging site:
> http://maven.apache.org/ref/3-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Regression in model interpolation coming from using JSR-330?

[Gabriel Belingueres]

Thank you Stuart for your in deep explanations.
I agree runtime checking is the way to go. I was looking for a shorter path
but I see it would become problematic.

El jue., 7 de nov. de 2019 a la(s) 00:48, Stuart McCulloch (
mccu...@gmail.com) escribió:

> 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 spe

Re: Regression in model interpolation coming from using JSR-330?

[Gabriel Belingueres]

@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
> e

Re: Regression in model interpolation coming from using JSR-330?

[Gabriel Belingueres]

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 over implementations in core
> (to
> > > allow overriding). But there is an upcoming improvement to sort the
> list
> > > inside each module that would make this more deterministic from build
> to
> > > build, at least when ranking implementations inside a particular
> module:
> > > https://github.com/eclipse/sisu.inject/pull/5 - with that change then
> > > you'll get an extra guarantee that inside a module it will be ordered
> by
> > > package+name.
> > >
> > > PS. even with the old Plexus runtime annotations you could be at the
> whim
> > > of classpath ordering, similarly Plexus XML descriptors are influenced
> by
> > > classpath resource ordering - so ideally it's better to be explicit
> about
> > > ordering
> > >
> > > On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres <
> belingue...@gmail.com>
> > >
> > > wrote:
> > > > Hi:
> > > >
> > > > I just built maven core from source and found that it was using
> > > > StringSearchModelInterpolator instead of
> StringVisitorModelInterpolator,
> > >
> > > a
> > >
> > > > regression from the last 3.6.2 release.
> > > >
> > > > I found that in
> maven-model-builder/META-INF/sisu/javax.injected.Named
> > > > file, both interpolators are listed but in reverse order (comparing
> it
> > >
> > > with
> > >
> > > > the same file in 3.6.2), that is StringSearchModelInt

Re: Regression in model interpolation coming from using JSR-330?

[Gabriel Belingueres]

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 over implementations in core (to
> allow overriding). But there is an upcoming improvement to sort the list
> inside each module that would make this more deterministic from build to
> build, at least when ranking implementations inside a particular module:
> https://github.com/eclipse/sisu.inject/pull/5 - with that change then
> you'll get an extra guarantee that inside a module it will be ordered by
> package+name.
>
> PS. even with the old Plexus runtime annotations you could be at the whim
> of classpath ordering, similarly Plexus XML descriptors are influenced by
> classpath resource ordering - so ideally it's better to be explicit about
> ordering
>
> On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres 
> wrote:
>
> > Hi:
> >
> > I just built maven core from source and found that it was using
> > StringSearchModelInterpolator instead of StringVisitorModelInterpolator,
> a
> > regression from the last 3.6.2 release.
> >
> > I found that in maven-model-builder/META-INF/sisu/javax.injected.Named
> > file, both interpolators are listed but in reverse order (comparing it
> with
> > the same file in 3.6.2), that is StringSearchModelInterpolator appear
> first
> > in the file and StringVisitorModelInterpolator second.
> >
> > (I believe the dependency injection picks up the first one it finds with
> > the right type.)
> >
> > Deleting the @Named annotation from StringSearchModelInterpolator solved
> > the issue, as this make the entry disappear from the javax.injected.Named
> > file. Then the dependency injection uses the
> > StringVisitorModelInterpolator.
> >
> > Can anyone confirm this issue?
> > And if so, how to best prevent in the future that this type of dependency
> > injection regressions from happening?
> >
> > Kind regards,
> > Gabriel
> >
>

Regression in model interpolation coming from using JSR-330?

[Gabriel Belingueres]

Hi:

I just built maven core from source and found that it was using
StringSearchModelInterpolator instead of StringVisitorModelInterpolator, a
regression from the last 3.6.2 release.

I found that in maven-model-builder/META-INF/sisu/javax.injected.Named
file, both interpolators are listed but in reverse order (comparing it with
the same file in 3.6.2), that is StringSearchModelInterpolator appear first
in the file and StringVisitorModelInterpolator second.

(I believe the dependency injection picks up the first one it finds with
the right type.)

Deleting the @Named annotation from StringSearchModelInterpolator solved
the issue, as this make the entry disappear from the javax.injected.Named
file. Then the dependency injection uses the StringVisitorModelInterpolator.

Can anyone confirm this issue?
And if so, how to best prevent in the future that this type of dependency
injection regressions from happening?

Kind regards,
Gabriel

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Gabriel Belingueres]

+1

Kind regards
Gabriel

El mar., 29 de octubre de 2019 17:11, Karl Heinz Marbaise 
escribió:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Merging PR for MSHARED-817

[Gabriel Belingueres]

Hi!

Is there any chance to merge PR for MSHARED-817 [1]?
I would need that change in place as base to make a final commit for
MSHARED-801 [2].

[1] https://github.com/apache/maven-artifact-transfer/pull/2
[2] https://github.com/apache/maven-artifact-transfer/pull/1

Kind regards,
Gabriel

Re: [VOTE] Release Apache Maven Version 3.6.2

[Gabriel Belingueres]

+1

Kind regards.
Gabriel


El mié., 28 de ago. de 2019 a la(s) 16:18, Enrico Olivelli (
eolive...@gmail.com) escribió:

> Hi,
>
> We have solved 52 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12345234
>
> There are issues left in JIRA for Maven core:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1529
>
> The distributable binaries and sources can be found here:
>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/
>
> Specifically the zip, tarball and source archives can be found here:
>
>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz
>
>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip
>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz
>
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2
>
> Source release checksum(s):
> apache-maven-3.6.2-src.tar.gz
>
>sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade
> sha512:
>
> 235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7
>
> apache-maven-3.6.2-src.zip:
>
>sha1: c6c5bd9828b3350905e97177978724eed0698de3
> sha512:
>
> d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Enrico Olivelli
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.0.1

[Gabriel Belingueres]

Hi:

Regarding the exception, there were several cases I checked:

Case 1:


  

  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.0.1
  


org.eclipse.m2e

  

  


it was not finding the very same plugin I was testing:
"org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find
org.apache.maven.plugins:maven-project-info-reports-plugin:pom:3.0.1 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced for project
org.apache.maven.plugins:maven-project-info-reports-plugin:pom:3.0.1"

The reason for this exception is that it could not find it when declared in
the pluginManagement section, because it tries to get it as an artifact and
it was not found. Adding the same plugin staging repo like this solved the
exception:
  

  same-staged-repo
  https://repository.apache.org/content/repositories/maven-1528


  

I think this condition should dissapear as soon as the plugin is deployed
to Central repo?

Case 2:
Executing again with the artifact repo added caused this exception:
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure
to find org.eclipse.m2e:lifecycle-mapping:pom:1.0.0 in http:// was
cached in the local repository, resolution will not be reattempted until
the update interval of central has elapsed or updates are forced

which is what is expected as the 'mvn site' execution does not set the
parameters in the plugin configuration section of plugins.

Case 3:
Leave the pluginManagement section but configure it in the reporting
section:

  

  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.0.1

  

  


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  


org.eclipse.m2e

  


  

Works OK as long as the artifact repository is kept.

Case 4:
If I delete the artifact repository, to avoid the exception "...Failure to
find
org.apache.maven.plugins:maven-project-info-reports-plugin:pom:3.0.1..." I
excluded the plugin in the configuration (showing that the added
functionality works for the plugin itself):
  


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  


org.eclipse.m2e

org.apache.maven.plugins:maven-project-info-reports-plugin

  


  

HTH
Gabriel

El lun., 26 de ago. de 2019 a la(s) 09:59, Tibor Digana (
tibordig...@apache.org) escribió:

> I was waiting this this issue. Now it is clear for me too.
> So we are missing this commit, right? It's worth to complete the PR#7 and
> restart the vote.
>
> Gabriel, why the exception with plugin version 3.0.1 appears on your box?
> T
>
> On Mon, Aug 26, 2019 at 2:49 PM Gabriel Belingueres  >
> wrote:
>
> > Created https://issues.apache.org/jira/browse/MPIR-384
> >
> > Kind regards,
> > Gabriel
> >
> > El lun., 26 de ago. de 2019 a la(s) 05:21, Michael Osipov (
> > micha...@apache.org) escribió:
> >
> > > Am 2019-08-26 um 04:14 schrieb Gabriel Belingueres:
> > > > Hi:
> > > >
> > > > In the light of what Michael clarified, and after some doc reading
> [1],
> > > > quoting the following about 'mvn site':
> > > > "It uses *only* the parameters defined in the  element
> > of
> > > > each reporting Plugin specified in the  element, i.e. site
> > > > always *ignores* the parameters defined in the 
> element
> > of
> > > > each plugin specified in ."
> > > >
> > > > After testing with the plugin configuration in the 
> section,
> > > it
> > > > worked OK. Why it does not apply the reporting configuration when the
> > > > plugin is declared and configured in both the pluginManagement and
> > > > repoorting sections is another matter.
> > > >
> > > > I created a gist with the log files as it seems the mailing does not
> > > allow
> > > > attachments. Please see [2], but it seems less useful now.
> > > >
> > > > Regarding the missing commit, it was an improvement over the first
> > commit
> > > > (which already had the IT in place). The feature is already there and
> > > > working. I have no problem to  raise a new issue for the next
> release.
> > >
> > > Please do so.
> > >
> > > @Tibor. Do you still insist on -1?
> > >
> > > @all if Tibor reverts his one, I still need another binding vote.
> > >
> >
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.0.1

[Gabriel Belingueres]

Created https://issues.apache.org/jira/browse/MPIR-384

Kind regards,
Gabriel

El lun., 26 de ago. de 2019 a la(s) 05:21, Michael Osipov (
micha...@apache.org) escribió:

> Am 2019-08-26 um 04:14 schrieb Gabriel Belingueres:
> > Hi:
> >
> > In the light of what Michael clarified, and after some doc reading [1],
> > quoting the following about 'mvn site':
> > "It uses *only* the parameters defined in the  element of
> > each reporting Plugin specified in the  element, i.e. site
> > always *ignores* the parameters defined in the  element of
> > each plugin specified in ."
> >
> > After testing with the plugin configuration in the  section,
> it
> > worked OK. Why it does not apply the reporting configuration when the
> > plugin is declared and configured in both the pluginManagement and
> > repoorting sections is another matter.
> >
> > I created a gist with the log files as it seems the mailing does not
> allow
> > attachments. Please see [2], but it seems less useful now.
> >
> > Regarding the missing commit, it was an improvement over the first commit
> > (which already had the IT in place). The feature is already there and
> > working. I have no problem to  raise a new issue for the next release.
>
> Please do so.
>
> @Tibor. Do you still insist on -1?
>
> @all if Tibor reverts his one, I still need another binding vote.
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.0.1

[Gabriel Belingueres]

Hi:

In the light of what Michael clarified, and after some doc reading [1],
quoting the following about 'mvn site':
"It uses *only* the parameters defined in the  element of
each reporting Plugin specified in the  element, i.e. site
always *ignores* the parameters defined in the  element of
each plugin specified in ."

After testing with the plugin configuration in the  section, it
worked OK. Why it does not apply the reporting configuration when the
plugin is declared and configured in both the pluginManagement and
repoorting sections is another matter.

I created a gist with the log files as it seems the mailing does not allow
attachments. Please see [2], but it seems less useful now.

Regarding the missing commit, it was an improvement over the first commit
(which already had the IT in place). The feature is already there and
working. I have no problem to  raise a new issue for the next release.

With this new information, my vote now is a +1.

Kind regards,
Gabriel

[1]
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Configuring_Reporting_Plugins
[2] https://gist.github.com/belingueres/8ceb548e2ef43dca3687d3bd6eaa93ef

El dom., 25 de ago. de 2019 a la(s) 13:04, Tibor Digana (
tibordig...@apache.org) escribió:

> Michael, this is true but the second problem is a missed commit? Where is
> the commit? It is not in the PR.
> Gabriel, the log file was not attached.
> And the third problem is an exception which we could not see because the
> log is not in the attachements.
>
> On Sun, Aug 25, 2019 at 5:14 PM Michael Osipov 
> wrote:
>
>> Am 2019-08-24 um 21:41 schrieb Gabriel Belingueres:
>> > Hi:
>> >
>> > Regarding MPIR-375, I noted that the merge of the PR into master branch
>> was
>> > done *before* I made changes using PatternExcludesArtifactFilter based
>> on
>> > the reviews.
>> >
>> > See https://github.com/apache/maven-project-info-reports-plugin/pull/7.
>> > The commit in master is:
>> >
>> https://github.com/apache/maven-project-info-reports-plugin/commit/82f4bf23b79fe87d2e414c70ab2058e8f1b4146b
>> >
>> > The patch should work anyway so I decided to test it with the
>> > maven-shared-utils library.
>> > I added this to the pom.xml file (in addition to adding the
>> staged-releases
>> > profile to settings.xml with the staged repo):
>> >
>> >  
>> >
>> >  
>> >org.apache.maven.plugins
>> >maven-project-info-reports-plugin
>> >3.0.1
>> >
>> >  
>> >
>> > org.eclipse.m2e
>> >  
>> >
>> >  
>> >
>> >  
>> >
>> > With version 3.0.1, running 'mvn -V -Pstaged-releases clean site >
>> > 3.0.1.log' throws an exception. (see 3.0.1.log attached file)
>> >
>> > However, when building 3.0.2-SNAPSHOT and installing in the local repo
>> > (please see that in git repo there are no new commits after the 3.0.1
>> > release), changing the version to 3.0.2-SNAPSHOT works as expected:
>> >
>> > mvn -V -Pstaged-releases clean site > 3.0.2-SNAPSHOT.log
>> >
>> > Does anyone else is having this problem? Or am I doing something wrong?
>>
>> I cannot confirm:
>> > $ mvn -V -Pstaged-releases clean site
>> > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
>> 2018-06-17T20:33:14+02:00)
>> > Maven home: D:\Entwicklung\Programme\apache-maven-3.5.4
>> > Java version: 1.8.0_192, vendor: Oracle Corporation, runtime:
>> C:\Program Files\Java\jdk1.8.0_192\jre
>> > Default locale: de_DE, platform encoding: Cp1252
>> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> > [INFO] Scanning for projects...
>> > [INFO]
>> > [INFO] -< org.apache.maven.shared:maven-shared-utils
>> >-
>> > [INFO] Building Apache Maven Shared Utils 3.2.2-SNAPSHOT
>> > [INFO] [ jar
>> ]-
>> > [INFO]
>> > [INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @
>> maven-shared-utils ---
>> > [INFO] Deleting D:\Entwicklung\Projekte\maven-shared-utils\target
>> > [INFO]
>> > [INFO] --- maven-site-plugin:3.7.1:site (default-site) @
>> maven-shared-utils ---
>> > [INFO] configuring report plugin
>> org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.1
>> > [INFO] 15 reports 

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.0.1

[Gabriel Belingueres]

Hi Tibor:

Please note I don't know if it's a plugin issue. Further tests shows that
it works OK when configuring the plugin in the reporting section:

  


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.0.1
  


org.eclipse.m2e

  


  

*BUT* if I configure the plugin in BOTH the pluginManagement and reporting
section, then it fails again.
Sounds to me like some plugin resolution condition that causes the
pluginManagementExcludes list parameter to not be set.


El sáb., 24 de ago. de 2019 a la(s) 17:32, Tibor Digana (
tibordig...@apache.org) escribió:

> that's bad. We were too fast :-)
> Although my build passed but in this case as I saw the commit I have to
> give my -1, sorry!
>
> On Sat, Aug 24, 2019 at 9:41 PM Gabriel Belingueres  >
> wrote:
>
> > Hi:
> >
> > Regarding MPIR-375, I noted that the merge of the PR into master branch
> > was done *before* I made changes using PatternExcludesArtifactFilter
> based
> > on the reviews.
> >
> > See https://github.com/apache/maven-project-info-reports-plugin/pull/7.
> > The commit in master is:
> >
> https://github.com/apache/maven-project-info-reports-plugin/commit/82f4bf23b79fe87d2e414c70ab2058e8f1b4146b
> >
> > The patch should work anyway so I decided to test it with the
> > maven-shared-utils library.
> > I added this to the pom.xml file (in addition to adding the
> > staged-releases profile to settings.xml with the staged repo):
> >
> > 
> >   
> > 
> >   org.apache.maven.plugins
> >   maven-project-info-reports-plugin
> >   3.0.1
> >   
> > 
> >
> > org.eclipse.m2e
> > 
> >   
> > 
> >   
> > 
> >
> > With version 3.0.1, running 'mvn -V -Pstaged-releases clean site >
> > 3.0.1.log' throws an exception. (see 3.0.1.log attached file)
> >
> > However, when building 3.0.2-SNAPSHOT and installing in the local repo
> > (please see that in git repo there are no new commits after the 3.0.1
> > release), changing the version to 3.0.2-SNAPSHOT works as expected:
> >
> > mvn -V -Pstaged-releases clean site > 3.0.2-SNAPSHOT.log
> >
> > Does anyone else is having this problem? Or am I doing something wrong?
> >
> > Kind regards,
> > Gabriel
> >
> > El vie., 23 de ago. de 2019 a la(s) 16:33, Michael Osipov (
> > micha...@apache.org) escribió:
> >
> >> Hi,
> >>
> >> We solved 5 issues:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12344828
> >>
> >> There are still a couple of issues left in JIRA:
> >> https://issues.apache.org/jira/projects/MPIR/issues
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-1528/
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1528/org/apache/maven/plugins/maven-project-info-reports-plugin/3.0.1/maven-project-info-reports-plugin-3.0.1-source-release.zip
> >>
> >> Source release checksum(s):
> >> maven-project-info-reports-plugin-3.0.1-source-release.zip
> >> sha512:
> >>
> >>
> 7145430a6999ed65a886ac503793f0aa9488b6853431c494c3dee6360c05f3db53fe46ff77bd41514002e8c320b0f4623d23b85d3a9373450c90bb713d3e50be
> >>
> >> Staging site:
> >>
> >>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
> >>
> >> Guide to testing staged releases:
> >> https://maven.apache.org/guides/development/guide-testing-releases.html
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> -
> >> 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
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.0.1

[Gabriel Belingueres]

Hi:

Regarding MPIR-375, I noted that the merge of the PR into master branch was
done *before* I made changes using PatternExcludesArtifactFilter based on
the reviews.

See https://github.com/apache/maven-project-info-reports-plugin/pull/7.
The commit in master is:
https://github.com/apache/maven-project-info-reports-plugin/commit/82f4bf23b79fe87d2e414c70ab2058e8f1b4146b

The patch should work anyway so I decided to test it with the
maven-shared-utils library.
I added this to the pom.xml file (in addition to adding the staged-releases
profile to settings.xml with the staged repo):


  

  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.0.1
  


org.eclipse.m2e

  

  


With version 3.0.1, running 'mvn -V -Pstaged-releases clean site >
3.0.1.log' throws an exception. (see 3.0.1.log attached file)

However, when building 3.0.2-SNAPSHOT and installing in the local repo
(please see that in git repo there are no new commits after the 3.0.1
release), changing the version to 3.0.2-SNAPSHOT works as expected:

mvn -V -Pstaged-releases clean site > 3.0.2-SNAPSHOT.log

Does anyone else is having this problem? Or am I doing something wrong?

Kind regards,
Gabriel

El vie., 23 de ago. de 2019 a la(s) 16:33, Michael Osipov (
micha...@apache.org) escribió:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12344828
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1528/
>
> https://repository.apache.org/content/repositories/maven-1528/org/apache/maven/plugins/maven-project-info-reports-plugin/3.0.1/maven-project-info-reports-plugin-3.0.1-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.0.1-source-release.zip
> sha512:
>
> 7145430a6999ed65a886ac503793f0aa9488b6853431c494c3dee6360c05f3db53fe46ff77bd41514002e8c320b0f4623d23b85d3a9373450c90bb713d3e50be
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> 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

Re: [VOTE] Retire Maven Repository Builder

[Gabriel Belingueres]

+1

Kind regards,
Gabriel

El mié., 7 de ago. de 2019 a la(s) 16:13, Robert Scholte (
rfscho...@apache.org) escribió:

> Hi,
>
> The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects,
> including our ambitious ideas for the next major version(s) of Maven
> itself.
> To be able to gain more focus we need to criticize the current
> subprojects
> and decide if it is worth maintaining.
>
> https://maven.apache.org/shared/maven-repository-builder/ describes the
> main purpose in one line: Maven shared components. Okay, that's actually
> quite bad.
> Based on
>
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-repository-builder
>
> the library isn't used a lot. Both maven-assembly-plugin and
> maven-plugin-testing-tools don't use this library anymore.
> The sourcecode looks a bit like it has the same purpose as
> dependency:copy-dependencies.
>
> I therefore propose that we retire the maven-repository-builder.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> [https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

[Gabriel Belingueres]

Before the release of 3.6.2 please consider to cut a release of
plexus-utils, which has PRs for two important issues:

DirectoryScanner traverses directories despite limited inclusions

XML processing instructions with embedded '>' fail to parse


TIA,
Gabriel

El mié., 26 de jun. de 2019 a la(s) 18:18, Enrico Olivelli (
eolive...@gmail.com) escribió:

> Il mer 26 giu 2019, 22:39 Michael Osipov  ha scritto:
>
> > Am 2019-06-26 um 16:51 schrieb Mickael Istria:
> > > Hi all,
> > >
> > > Eclipse m2e did include a newer release of Maven in order to greatly
> > > improve its performances. This release was 3.6.1 (3.6.0 had a bug
> making
> > > some of its APIs unusable by m2e internals).
> > > However, Maven 3.6.1 also breaks compatibility with Eclipse Tycho. It
> was
> > > the topic of a Jira, that was fixed.
> > > The only way to get it all working would be to adopt a newer version of
> > > Maven in next release of m2e (in September).
> > >
> > > Is there a date already set for 3.6.2 release?
> > > Could it be pretty soon as this issue is basically hurting all Eclipse
> > > plugin developers (which we assume 99% use the Eclipse IDE and Eclipse
> > > Tycho) ?
> >
> > I don't see anything blocking this. We just need someone to be the
> > release manager for 3.6.2. Any volunteers?
> >
>
> I will be happy to try, but I will be on vacation next week
> I have already managed releases for plugins I guess the procedure is
> somehow more complex.
>
> If I understand correctly there is a bit of hurry, If any other volunteer
> steps in I can do the next time.
>
>
> Enrico
>
>
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Retire Maven Ant Plugin

[Gabriel Belingueres]

+1

Regards
Gabriel

El mar., 28 de may. de 2019 15:54, Robert Scholte 
escribió:

> Hi,
>
> The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The goal of the Apache Maven Ant Plugin it to generate Ant build files
> based on a pom.xml and was released for the last time in December 2014. Due
> to the different ways that Ant and Maven work I don't think it makes
> sense anymore to maintain a plugin to transform Maven files to Ant.
> See https://maven.apache.org/plugins/maven-ant-plugin/ [
> https://maven.apache.org/plugins/maven-ant-plugin/]
>
> To be clear, this is NOT the plugin you can use to run Ant within Maven;
> that's the maven-antrun-plugin.
>
> I therefore propose that we retire the maven-ant-plugin.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.3

[Gabriel Belingueres]

+1 (non-binding)

Regards,
Gabriel

El jue., 23 de may. de 2019 a la(s) 14:56, Karl Heinz Marbaise (
khmarba...@gmx.de) escribió:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12343424
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1505/
>
> https://repository.apache.org/content/repositories/maven-1505/org/apache/maven/plugins/maven-war-plugin/3.2.3/maven-war-plugin-3.2.3-source-release.zip
>
> Source release checksum(s):
> maven-war-plugin-3.2.3-source-release.zip
> sha1:803bac9ea7942b84d3dd602b30b4dd58cc03a521
> maven-war-plugin-3.2.3-source-release.zip sha512:
>
> b72b7c9e4770df7dd933bef05a343cc90314f28eb5b385aa21febbadeabcf25a3e619af44c5e9d0367193e63d9ccba3c0a79775e17032272a75032489496970c
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Gabriel Belingueres]

+1

Regards,
Gabriel

El mié., 8 de may. de 2019 a la(s) 15:25, Robert Scholte (
rfscho...@apache.org) escribió:

> Hi,
>
> The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
> component that could be used to easily resolve Maven project dependencies.
> The last (and only) released version is 1.0 in September 2009.(
> https://maven.apache.org/shared/maven-artifact-resolver/ [
> https://maven.apache.org/shared/maven-artifact-resolver/] ).
> This library should not be confused with Artifact Resolver
> (maven-resolver), previously known as Aether. As you can see the naming
> will cause confusion.
> The library that aims the same goal for Artifact Resolver is another
> shared component called maven-artifact-transfer (which by now is not just
> the transfer part or Artifact Resolver, but a bridge for both Sonatype
> Aether as used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+.
> This way Maven plugins and extensions can be compatible with any Maven 3
> release)
>
> I therefore propose that we retire the maven-artifact-resolver.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...

Avoiding to shade aether classes in shared/artifact-transfer

[Gabriel Belingueres]

Hi!
I resumed work on MSHARED-801 and I saw that for collecting dependencies I
need access to many aether classes. The current strategy is to shade the
necessary classes into the artifact-transfer jar file but this won't work
for collecting because it will actually force to use that classes of the
specific aether 0.90M2 version shaded.

In contrast I found a solution without shading (that is, with all aether
dependencies with provided scope) but I need to import those aether classes
from the Maven core ClassRealm to be available to the caller plugin. This
require injecting a PluginDescriptor and executing something like this
before calling the particular artifact-transfer component:

public static void importAetherLibrary( PluginDescriptor
pluginDescriptor )
throws MojoExecutionException
{
try
{
pluginDescriptor.getClassRealm().importFrom( "plexus.core",
"org.eclipse.aether.util" );
}
catch ( NoSuchRealmException e )
{
throw new MojoExecutionException( "NoSuchRealmException", e );
}
}

The question is if there exists a better (more "automagic"?) way to gain
access to the aether classes in the user's maven distribution that not
depends on a plugin explicitly importing the classes from the core
classRealm?

BTW: it seems Maven 3.0.x does not require such a package import.

Kind regards,
Gabriel

Re: [VOTE] Release Apache Maven Help Plugin version 3.2.0

[Gabriel Belingueres]

+1

Tested on Linux (3.0.5, 3.5.4, 3.6.1) and Windows (3.6.1).

Good job!
Gabriel

El sáb., 13 de abr. de 2019 a la(s) 08:03, Hervé BOUTEMY (
herve.bout...@free.fr) escribió:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522&version=12345382&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1498/
>
> https://repository.apache.org/content/repositories/maven-1498/org/apache/maven/plugins/maven-help-plugin/3.2.0/maven-help-plugin-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-help-plugin-3.2.0-source-release.zip sha512:
> fdaebd6a0aaccd61d7bdf7c0e1bcacc83fee7491199e111fe4dd767b46a288a3eb415734c2cf8d7ab05508099ef967d03ff02c04ae02e617d477aa4358a4a7a9
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-help-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Testing Maven 3.6.1 with Maven Site - Issue

[Gabriel Belingueres]

Hi Karl. I can reproduce this issue running with 'mvn validate' too.

I think it is related to [MNG-6601]? Hervé can you confirm this?

Regards,
Gabriel

El jue., 11 de abr. de 2019 a la(s) 15:04, Karl Heinz Marbaise (
khmarba...@gmx.de) escribió:

> Hi,
>
> can someone please check the following:
>
> Use the maven-site repository and just try a:
>
> mvn site
>
> with the Maven 3.6.1 Release cause at the moment I'm getting the following:
>
> maven-site (master *)$ mvn site site:stage
>
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:498)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>  at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: java.lang.NullPointerException
>  at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
>  at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
>  at
> org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
>  at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
>  at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
>  at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
>  at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
>  at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
>  at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
>  at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
>  at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:498)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>  at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
>
> If I use Maven 3.6.0 for the same I don't get any issue.
>
> Can someone please recheck this?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Version 3.6.1

[Gabriel Belingueres]

Hi:

Please advise that the solved issue URL (JIRA Release notes) for 3.6.1 is:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344378&projectId=12316922

My vote: +1 non-binding

Thanks for the hard work!

Gabriel

El jue., 4 de abr. de 2019 a la(s) 16:55, Karl Heinz Marbaise (
khmarba...@gmx.de) escribió:

> Hi,
>
> We have solved 42 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12338966
>
> There are issues left in JIRA for Maven core:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1496
>
> The distributable binaries and sources can be found here:
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/
>
> Specifically the zip, tarball and source archives can be found here:
>
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.tar.gz
>
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.tar.gz
>
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.0
>
> Source release checksum(s):
> apache-maven-3.6.1-src.tar.gz
>
>sha1: 4e87c962ed505a0158085f99d92a0ade8c7fd197
> sha512:
>
> 11a31022cffa0518584703fffd9fce998332ac5f6c2a50db3b590e90f3bdd1508d9e0cb5ba89a699ef6536b237bcc96166cfde3d45bce6346fa21b05b4d12bf8
>
> apache-maven-3.6.1-src.zip:
>
>sha1: ec0618f981f9367f133a29fbfcaa8e073cb8ac85
> sha512:
>
> b92d8ed72585c4e05debe4d15eb9ae5dd72e814b6413bcba78d01282c9eccc38e79755654e0d0b4e5a650f0226c116a4a4faad731918a465ad424a2a81582a67
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: seconders for MNG-6572?

[Gabriel Belingueres]

Hi:

I did ran a quick JMH micro-benchmark (for what it's worth) on both approaches.
The results favor StringUtils.stripStart() over regex.

(attached benchmark project .zip file)

Output:

# JMH version: 1.21
# VM version: JDK 10.0.2, Java HotSpot(TM) 64-Bit Server VM, 10.0.2+13
# VM invoker: /usr/lib/jvm/java-10-oracle/bin/java
# VM options: 
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.testRegex

# Run progress: 0,00% complete, ETA 00:16:40
# Fork: 1 of 5
# Warmup Iteration   1: 115592,945 ops/s
# Warmup Iteration   2: 122466,987 ops/s
# Warmup Iteration   3: 122168,413 ops/s
# Warmup Iteration   4: 123296,590 ops/s
# Warmup Iteration   5: 121609,324 ops/s
Iteration   1: 122126,768 ops/s
Iteration   2: 123127,808 ops/s
Iteration   3: 122700,768 ops/s
Iteration   4: 123601,980 ops/s
Iteration   5: 123357,611 ops/s

# Run progress: 10,00% complete, ETA 00:15:06
# Fork: 2 of 5
# Warmup Iteration   1: 115779,273 ops/s
# Warmup Iteration   2: 122535,724 ops/s
# Warmup Iteration   3: 123753,240 ops/s
# Warmup Iteration   4: 122713,109 ops/s
# Warmup Iteration   5: 123618,475 ops/s
Iteration   1: 123314,055 ops/s
Iteration   2: 123142,400 ops/s
Iteration   3: 121928,614 ops/s
Iteration   4: 122214,377 ops/s
Iteration   5: 123543,852 ops/s

# Run progress: 20,00% complete, ETA 00:13:25
# Fork: 3 of 5
# Warmup Iteration   1: 114917,291 ops/s
# Warmup Iteration   2: 121140,667 ops/s
# Warmup Iteration   3: 118295,250 ops/s
# Warmup Iteration   4: 118386,423 ops/s
# Warmup Iteration   5: 118439,461 ops/s
Iteration   1: 117842,336 ops/s
Iteration   2: 118337,507 ops/s
Iteration   3: 118294,871 ops/s
Iteration   4: 118656,349 ops/s
Iteration   5: 118558,792 ops/s

# Run progress: 30,00% complete, ETA 00:11:44
# Fork: 4 of 5
# Warmup Iteration   1: 115428,718 ops/s
# Warmup Iteration   2: 121519,510 ops/s
# Warmup Iteration   3: 123656,289 ops/s
# Warmup Iteration   4: 123731,525 ops/s
# Warmup Iteration   5: 123664,813 ops/s
Iteration   1: 122795,328 ops/s
Iteration   2: 123292,329 ops/s
Iteration   3: 123914,332 ops/s
Iteration   4: 123725,241 ops/s
Iteration   5: 123525,873 ops/s

# Run progress: 40,00% complete, ETA 00:10:03
# Fork: 5 of 5
# Warmup Iteration   1: 114873,436 ops/s
# Warmup Iteration   2: 120492,746 ops/s
# Warmup Iteration   3: 122673,036 ops/s
# Warmup Iteration   4: 121569,231 ops/s
# Warmup Iteration   5: 122378,009 ops/s
Iteration   1: 121805,248 ops/s
Iteration   2: 122254,162 ops/s
Iteration   3: 122293,226 ops/s
Iteration   4: 121449,921 ops/s
Iteration   5: 121989,101 ops/s


Result "org.sample.MyBenchmark.testRegex":
  121911,714 ±(99.9%) 1456,002 ops/s [Average]
  (min, avg, max) = (117842,336, 121911,714, 123914,332), stdev = 1943,721
  CI (99.9%): [120455,712, 123367,716] (assumes normal distribution)


# JMH version: 1.21
# VM version: JDK 10.0.2, Java HotSpot(TM) 64-Bit Server VM, 10.0.2+13
# VM invoker: /usr/lib/jvm/java-10-oracle/bin/java
# VM options: 
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.testStringUItilsStripStart

# Run progress: 50,00% complete, ETA 00:08:23
# Fork: 1 of 5
# Warmup Iteration   1: 1039951,283 ops/s
# Warmup Iteration   2: 1079678,801 ops/s
# Warmup Iteration   3: 903261,012 ops/s
# Warmup Iteration   4: 926671,364 ops/s
# Warmup Iteration   5: 933659,789 ops/s
Iteration   1: 884965,824 ops/s
Iteration   2: 889218,414 ops/s
Iteration   3: 936928,275 ops/s
Iteration   4: 884544,948 ops/s
Iteration   5: 910224,385 ops/s

# Run progress: 60,00% complete, ETA 00:06:42
# Fork: 2 of 5
# Warmup Iteration   1: 962278,822 ops/s
# Warmup Iteration   2: 988250,807 ops/s
# Warmup Iteration   3: 870544,716 ops/s
# Warmup Iteration   4: 863789,867 ops/s
# Warmup Iteration   5: 864501,466 ops/s
Iteration   1: 863536,313 ops/s
Iteration   2: 868579,343 ops/s
Iteration   3: 868197,634 ops/s
Iteration   4: 866415,349 ops/s
Iteration   5: 866593,399 ops/s

# Run progress: 70,00% complete, ETA 00:05:01
# Fork: 3 of 5
# Warmup Iteration   1: 1041356,608 ops/s
# Warmup Iteration   2: 1053943,657 ops/s
# Warmup Iteration   3: 965779,373 ops/s
# Warmup Iteration   4: 974967,751 ops/s
# Warmup Iteration   5: 969837,627 ops/s
Iteration   1: 951069,998 ops/s
Iteration   2: 970677,240 ops/s
Iteration   3: 951033,637 ops/s
Iteration   4: 951622,347 ops/s
Iteration   5: 955366,302 ops/s

# Run progress: 80,00% complete, ETA 00:03:21
# Fork: 4 of 5
# Warmup Iteration   1: 909946,836 ops/s
# Warmup Iteration   2: 944886,834 ops/s
# Warmup Iteration   3: 850848,610 ops/s
# Warmup Iteration   4: 852793,912 ops/s
# Warmup Iteration   5: 852968,776 ops/s
Iteration   1: 842741,985 ops/s
Iteration   2: 849709,794 ops/s
Iteration   

Re: Releasing Maven enforcer plugin

[Gabriel Belingueres]

+1 all 3 points.

Regards,
Gabriel

El vie., 22 de feb. de 2019 a la(s) 18:17, Enrico Olivelli (
eolive...@gmail.com) escribió:

> Hi folks,
> I am scanning the list of open JIRAs,
> there are a bunch of 'In progress' JIRA, most of them are assigned to Karl
>
> Jenkins builds are broken since we have added JDK12
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project enforcer-api: Compilation failure:
> Compilation failure:
> [ERROR] Source option 6 is no longer supported. Use 7 or later.
> [ERROR] Target option 6 is no longer supported. Use 7 or later.
>
> I would like to cut a release, so this is my proposal:
> 1) Switch to at least Java 7 in order to support jdk12 at build time
> 2) Check "in progress" JIRAs
> 3) Release with the '-M3' suffix
>
> thoughs ?
>
> Enrico
>
>
> Il giorno ven 18 gen 2019 alle ore 10:58 Gabriel Belingueres
>  ha scritto:
> >
> > Will move it.
> > Meanwhile, +1 for another milestone release of enforcer.
> >
> > El jue., 17 de ene. de 2019 14:43, Robert Scholte 
> > escribió:
> >
> > > Hi Gabriel,
> > >
> > > I think you missed the message that this code doesn't belong to
> > > m-dependency-tree, but to m-artifact-transfer.
> > > Would be great if you could move the code.
> > >
> > > thanks,
> > > Robert
> > >
> > > On Thu, 17 Jan 2019 16:13:15 +0100, Gabriel Belingueres
> > >  wrote:
> > >
> > > > I've made progress with the m-dependency-tree [1] shared library
> which
> > > > should help unblock some issues in enforcer. It needs review though
> > > (and
> > > > a
> > > > release)
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MSHARED-788
> > > >
> > > > El jue., 17 de ene. de 2019 06:25, Tibor Digana <
> tibordig...@apache.org>
> > > > escribió:
> > > >
> > > >> To lookup easy or fast fixes, and +1 to perform a release then.
> > > >> T
> > > >>
> > > >> On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli <
> eolive...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > An user is asking for a release of the enforcer plugin
> > > >> >
> > > >> >
> > > >>
> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
> > > >> >
> > > >> > I can prepare the release
> > > >> >
> > > >> > Thoughts?
> > > >> > Enrico
> > > >> > --
> > > >> >
> > > >> >
> > > >> > -- Enrico Olivelli
> > > >> >
> > >
> > > -
> > > 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
>
>

Migrating code from m-dependency-tree to m-artifact-transfer (was: Releasing Maven enforcer plugin)

[Gabriel Belingueres]

)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NoSuchMethodError:
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyNode.(Lorg/apache/maven/shared/dependency/graph/DependencyNode;Lorg/apache/maven/artifact/Artifact;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;)V
at
org.apache.maven.shared.transfer.dependencies.collect.internal.Maven31CollectorResult.buildDependencyNode
(Maven31CollectorResult.java:121)
at
org.apache.maven.shared.transfer.dependencies.collect.internal.Maven31CollectorResult.getDependencyGraphRoot
(Maven31CollectorResult.java:100)
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.getNode
(RequireUpperBoundDeps.java:123)
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.execute
(RequireUpperBoundDeps.java:149)
at org.apache.maven.plugins.enforcer.EnforceMojo.execute
(EnforceMojo.java:205)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)


Testing in other projects, I found the offending issue is the dependeny to
m-dependency-tree 2.1 coming from the extra-enforcer-rules additional
dependency (declared in org.apache.maven:maven-parent:33 parent pom)

Note: when implemented the same functionality in m-dependency-tree
3.0.2-SNAPSHOT this problem didn't show (I suppose because
m-dependency-tree 3.0.2-SNAPSHOT was a direct dependency for enforcer
plugin?)

Is there some classloading trick I could add so that execution does not
interfere with m-dependency-tree 2.1?

TIA,
Gabriel

El jue., 17 de ene. de 2019 a la(s) 14:43, Robert Scholte (
rfscho...@apache.org) escribió:

> Hi Gabriel,
>
> I think you missed the message that this code doesn't belong to
> m-dependency-tree, but to m-artifact-transfer.
> Would be great if you could move the code.
>
> thanks,
> Robert
>
> On Thu, 17 Jan 2019 16:13:15 +0100, Gabriel Belingueres
>  wrote:
>
> > I've made progress with the m-dependency-tree [1] shared library which
> > should help unblock some issues in enforcer. It needs review though
> (and
> > a
> > release)
> >
> > [1] https://issues.apache.org/jira/browse/MSHARED-788
> >
> > El jue., 17 de ene. de 2019 06:2

Re: Releasing Maven enforcer plugin

[Gabriel Belingueres]

Will move it.
Meanwhile, +1 for another milestone release of enforcer.

El jue., 17 de ene. de 2019 14:43, Robert Scholte 
escribió:

> Hi Gabriel,
>
> I think you missed the message that this code doesn't belong to
> m-dependency-tree, but to m-artifact-transfer.
> Would be great if you could move the code.
>
> thanks,
> Robert
>
> On Thu, 17 Jan 2019 16:13:15 +0100, Gabriel Belingueres
>  wrote:
>
> > I've made progress with the m-dependency-tree [1] shared library which
> > should help unblock some issues in enforcer. It needs review though
> (and
> > a
> > release)
> >
> > [1] https://issues.apache.org/jira/browse/MSHARED-788
> >
> > El jue., 17 de ene. de 2019 06:25, Tibor Digana 
> > escribió:
> >
> >> To lookup easy or fast fixes, and +1 to perform a release then.
> >> T
> >>
> >> On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli 
> >> wrote:
> >>
> >> > An user is asking for a release of the enforcer plugin
> >> >
> >> >
> >> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
> >> >
> >> > I can prepare the release
> >> >
> >> > Thoughts?
> >> > Enrico
> >> > --
> >> >
> >> >
> >> > -- Enrico Olivelli
> >> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releasing Maven enforcer plugin

[Gabriel Belingueres]

I've made progress with the m-dependency-tree [1] shared library which
should help unblock some issues in enforcer. It needs review though (and a
release)

[1] https://issues.apache.org/jira/browse/MSHARED-788

El jue., 17 de ene. de 2019 06:25, Tibor Digana 
escribió:

> To lookup easy or fast fixes, and +1 to perform a release then.
> T
>
> On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli 
> wrote:
>
> > An user is asking for a release of the enforcer plugin
> >
> > https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
> >
> > I can prepare the release
> >
> > Thoughts?
> > Enrico
> > --
> >
> >
> > -- Enrico Olivelli
> >
>

Re: Update versions of all plugins in default-bindings.xml

[Gabriel Belingueres]

Hi Tibor:
So Java version is a concern.
By API version do you mean Maven API version? I believe this is controlled
with the  tag inside the plugin's pom file?

An even simpler solution is to publish a "plugin compatibility matrix" page
in the web site as some companies do. Check for example Sonarqube [1]. It
should be easy to create a Java version (columns) vs Plugin version (rows)
matrix. Same for API version. So to guide the user to pinpoint an specific
version is to present that URL as part of the warning message.

[1] https://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix

El lun., 14 de ene. de 2019 a la(s) 23:30, Tibor Digana (
tibordig...@apache.org) escribió:

> >> However, it seems that the only use case for upgrading the default
> plugin versions is compatibility with some specific Java version?
>
> Gabriel, Java version is not the only one reason.
> There is API version as well and bug fixing.
> These plugins are especially important because they are bound to the build
> life cycle.
> Scaring with making new plugin updates in Maven Core by the same
> development group would mean almost the same that we did not trust the
> plugin releases we have made.
>
> >> added value by updating this service from outside of either a maven core
> I agree with Robert. The XML should be externalized.
> I understand it the way that this XML would be in the Maven distribution
> and not in JAR file.
> There is a similarity with JavaEE idea where configuration is not embedded
> in the software - apart, but that's a different story.
>
>
>
>
>
> On Mon, Jan 14, 2019 at 11:59 PM Gabriel Belingueres <
> belingue...@gmail.com>
> wrote:
>
> > I think I'm joining late to this thread. +1 to showing a warning message.
> >
> > However, it seems that the only use case for upgrading the default plugin
> > versions is compatibility with some specific Java version?
> >
> > How about developing a plugin that "recommends" specific plugin versions
> > based on the source/target java version? recommendation can be based on a
> > downloaded file/database/artifact/web service that the plugin parses?
> This
> > way you can add some added value by updating this service from outside of
> > either a maven core or specific plugin's release cycle.
> >
> > El lun., 14 de ene. de 2019 a la(s) 10:34, Hervé BOUTEMY (
> > herve.bout...@free.fr) escribió:
> >
> > > PR also created :)
> > > https://github.com/apache/maven/pull/233
> > >
> > > Le lundi 14 janvier 2019, 12:06:40 CET Hervé BOUTEMY a écrit :
> > > > MNG-6562 Jira issue [1] and Git branch [2] created: please review and
> > > > comment
> > > >
> > > > I'll start to work on the new parent POM that locks down versions of
> > > plugins
> > > > from default lifecycle bindings: see MPOM-215 [3] I'll do it in a
> > > personal
> > > > GitHub git repo first while we choose the final name:
> > > > maven-default-plugins?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MNG-6562
> > > >
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/maven/commit/05bc5c15dd37290e51190c6aa3fe4eb4a5bc
> > > > e62c
> > > >
> > > > [3] https://issues.apache.org/jira/browse/MPOM-215
> > > >
> > > > Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > > > > This is indeed a good approach.
> > > > > The first group doesn't care about this warning, the second one
> > should.
> > > > >
> > > > > Hervé, can you confirm that in case of *only* specifying the latest
> > > > > maven-jar-plugin or maven-war-plugin or other packaging plugin, you
> > > won't
> > > > > get these warnings.
> > > > > It really matters where the default lifecycle bindings are comings
> > > from:
> > > > > maven-core or packaging plugin.
> > > > >
> > > > > All this is an interesting feature worth for 3.7.0
> > > > >
> > > > > thanks,
> > > > > Robert
> > > > >
> > > > > On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY <
> > > herve.bout...@free.fr>
> > > > >
> > > > > wrote:
> > > > > > we have 2 opposite objectives:
> > > > > > - make default near-empty pom work at best,
> >

Re: Update versions of all plugins in default-bindings.xml

[Gabriel Belingueres]

I think I'm joining late to this thread. +1 to showing a warning message.

However, it seems that the only use case for upgrading the default plugin
versions is compatibility with some specific Java version?

How about developing a plugin that "recommends" specific plugin versions
based on the source/target java version? recommendation can be based on a
downloaded file/database/artifact/web service that the plugin parses? This
way you can add some added value by updating this service from outside of
either a maven core or specific plugin's release cycle.

El lun., 14 de ene. de 2019 a la(s) 10:34, Hervé BOUTEMY (
herve.bout...@free.fr) escribió:

> PR also created :)
> https://github.com/apache/maven/pull/233
>
> Le lundi 14 janvier 2019, 12:06:40 CET Hervé BOUTEMY a écrit :
> > MNG-6562 Jira issue [1] and Git branch [2] created: please review and
> > comment
> >
> > I'll start to work on the new parent POM that locks down versions of
> plugins
> > from default lifecycle bindings: see MPOM-215 [3] I'll do it in a
> personal
> > GitHub git repo first while we choose the final name:
> > maven-default-plugins?
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6562
> >
> > [2]
> >
> https://github.com/apache/maven/commit/05bc5c15dd37290e51190c6aa3fe4eb4a5bc
> > e62c
> >
> > [3] https://issues.apache.org/jira/browse/MPOM-215
> >
> > Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > > This is indeed a good approach.
> > > The first group doesn't care about this warning, the second one should.
> > >
> > > Hervé, can you confirm that in case of *only* specifying the latest
> > > maven-jar-plugin or maven-war-plugin or other packaging plugin, you
> won't
> > > get these warnings.
> > > It really matters where the default lifecycle bindings are comings
> from:
> > > maven-core or packaging plugin.
> > >
> > > All this is an interesting feature worth for 3.7.0
> > >
> > > thanks,
> > > Robert
> > >
> > > On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > >
> > > wrote:
> > > > we have 2 opposite objectives:
> > > > - make default near-empty pom work at best,
> > > > - but force people to have defined plugins versions (then not really
> > > > empty pom) to get stable build
> > > >
> > > > and I checked about the warning message: I was wrong, there is no
> > > > warning message when plugins without versions are injected by default
> > > > lifecycle bindings
> > > >
> > > > Just test for yourself following pom.xml from any beginner:
> > > >   
> > > >
> > > > 4.0.0
> > > > com.mycompany.app
> > > > my-app
> > > > 1.0-SNAPSHOT
> > > >
> > > >   
> > > >
> > > > it works = what we expect to ease newcomers experience
> > > > but there is no warning...
> > > >
> > > > IMHO, this is where we need to improve the tool, by adding a warning:
> > > > I worked on a PoC of DefaultLifecycleBindingsInjector improvement
> that
> > > > displays:
> > > > [WARNING]
> > > > [WARNING] Some problems were encountered while building the effective
> > > > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> > > > [WARNING] Using default plugins versions from bindings:
> > > > [org.apache.maven.plugins:maven-clean-plugin,
> > > > org.apache.maven.plugins:maven-install-plugin,
> > > > org.apache.maven.plugins:maven-resources-plugin,
> > > > org.apache.maven.plugins:maven-surefire-plugin,
> > > > org.apache.maven.plugins:maven-compiler-plugin,
> > > > org.apache.maven.plugins:maven-jar-plugin,
> > > > org.apache.maven.plugins:maven-deploy-plugin,
> > > > org.apache.maven.plugins:maven-site-plugin]
> > > > [WARNING]
> > > > [WARNING] It is highly recommended to fix these problems because they
> > > > threaten the stability of your build.
> > > > [WARNING]
> > > > [WARNING] For this reason, future Maven versions might no longer
> support
> > > > building such malformed projects.
> > > > [WARNING]
> > > >
> > > > With this warning, and a parent pom to have an easy fix (instead of 8
> > > > plugins versions definition), IMHO, we have what we strongly need.
> > > >
> > > > And even better, with this warning in place to avoid people to
> continue
> > > > to rely on default plugins versions (because of the nasty warning), I
> > > > could find upgrading default plugins versions not an issue any
> more!!!
> > > >
> > > > Should we try to go this route?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit :
> > > >> The original plan was to make plugin version mandatory. Perhaps
> 3.7.0
> > > >> is
> > > >> the time to do that, with a CLI option (to be removed after 3.7.x)
> to
> > > >> pull
> > > >> in the 3.6.x default versions if your pom is missing plugin
> versions.
> > > >>
> > > >> The warning has been there long enough. Let’s pull the trigger.
> > > >>
> > > >> On Sat 12 Jan 2019 at 21:34, Tibor Digana 
> > > >>
> > > >> wrote:
> > > >> > I have a strong reason to update 

enforcer plugin: which dependency to get the complete raw tree

[Gabriel Belingueres]

Hi:

I'm trying to upgrade enforcer's shared dependency-tree library to 3.0.0
but as said in MENFORCER-277 [1], there are some rules that require to have
access to the complete, unresolved dependency tree. For what I saw this
functionality is not currently present (that is, accessing the correct
aether API).

Is the maven-artifact-transfer library a better fit than the shared
dependency-tree? and is the 0.10.1 version production-ready?

TIA,
Gabriel

[1] https://issues.apache.org/jira/projects/MENFORCER/issues/MENFORCER-277

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Gabriel Belingueres]

I'll go for a minimal patch commenting with the rationale, and then build
upon that.

I also tested it will work if execute maven disabling string concatenation
optimization:
MAVEN_OPTS=-XX:-OptimizeStringConcat
which could used as a workaround for the short term.

El vie., 30 de nov. de 2018 a la(s) 06:18, Robert Scholte (
rfscho...@apache.org) escribió:

> Interesting if that works, but if the concatenation is the issue, we
> could
> also try:
>
> write( " write( elementStack.removeLast() );
> write( ">" );
>
> If this doesn't work but your proposed code does, it must have a good
> comment that this is a Java 7 workaround and can only be optimized once
> we
> require Java 8.
>
> I have also another idea: replace LinkedList with ArrayDeque, since it is
> really a LinkedList implementation issue. Also, according to the docs:
> "this class is likely to be faster than Stack when used as a stack, and
> faster than LinkedList when used as a queue."
>
> thanks,
> Robert
>
> On Fri, 30 Nov 2018 07:38:38 +0100, Hervé BOUTEMY 
>
> wrote:
>
> > wow, nice idea
> > I noticed the issue for a long time, but never figured out the link
> with
> > Java
> > 7 nor this idea of fix that is so "magic"...
> >
> > thank you for the help
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 30 novembre 2018, 05:11:56 CET Gabriel Belingueres a écrit :
> >> Indeed, that seems to be the case. It magically worked after replacing
> >> the
> >> following line:
> >>
> http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/
> >> xml/PrettyPrintXMLWriter.html#L307
> >>
> >> with this:
> >> String element = elementStack.removeLast();
> >> write( "" );
> >>
> >> I will soon create the issue and PR.
> >>
> >> Gabriel
> >>
> >> El jue., 29 de nov. de 2018 a la(s) 15:25, Robert Scholte (
> >>
> >> rfscho...@apache.org) escribió:
> >> > At builds.apache.org:
> >> > Java version: 1.7.0_79, vendor: Oracle Corporation
> >> >
> >> > Local
> >> > Java version: 1.7.0_80, vendor: Oracle Corporation
> >> >
> >> > does seem to be Java7 only...
> >> > I need to check this for a longer period, but might be a good
> >> conclusion.
> >> >
> >> > thanks,
> >> > Robert
> >> >
> >> >
> >> > On Thu, 29 Nov 2018 04:54:59 +0100, Gabriel Belingueres
> >> >
> >> >  wrote:
> >> > > Hi Robert:
> >> > >
> >> > > I'm testing it and getting *consistently* the same exception with
> >> this
> >> > > config:
> >> > >
> >> > > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> > > 2018-10-24T15:41:47-03:00)
> >> > > Maven home: C:\productos\apache-maven-3.6.0\bin\..
> >> > > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime:
> >> C:\Program
> >> > > Files\Java\jdk1.7.0_80\jre
> >> > > Default locale: es_AR, platform encoding: Cp1252
> >> > > OS name: "windows 8.1", version: "6.3", arch: "amd64", family:
> >> "windows"
> >> > >
> >> > > (actually it is a win 10 but it fails to recognze it).
> >> > >
> >> > > It works OK when remote debugging with mvnDebug.
> >> > >
> >> > > Don't know why throws a NoSuchElementException when trying to
> >> remove an
> >> > > element on a non empty LinkedList...my best guess is that it is some
> >> > > sort
> >> > > of bug in the hotspot optimization of the JVM.
> >> > >
> >> > > Which Java 7 specific update is running on Jenkins?
> >> > >
> >> > > Gabriel
> >> > >
> >> > > El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte (
> >> > >
> >> > > rfscho...@apache.org) escribió:
> >> > >> Hi,
> >> > >>
> >> > >> sometimes the maven-plugin-plugin fails to write the plugin
> >> descriptor
> >> > >> and
> >> > >> exits with the exception below.
> >> > >> I see the same unreliable behavior on our Jenkins servers too,
> >> > >> re-running
> >> > >> often fixes the issue.
> >> &g

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Gabriel Belingueres]

Indeed, that seems to be the case. It magically worked after replacing the
following line:
http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L307

with this:
String element = elementStack.removeLast();
write( "" );

I will soon create the issue and PR.

Gabriel

El jue., 29 de nov. de 2018 a la(s) 15:25, Robert Scholte (
rfscho...@apache.org) escribió:

> At builds.apache.org:
> Java version: 1.7.0_79, vendor: Oracle Corporation
>
> Local
> Java version: 1.7.0_80, vendor: Oracle Corporation
>
> does seem to be Java7 only...
> I need to check this for a longer period, but might be a good conclusion.
>
> thanks,
> Robert
>
>
> On Thu, 29 Nov 2018 04:54:59 +0100, Gabriel Belingueres
>  wrote:
>
> > Hi Robert:
> >
> > I'm testing it and getting *consistently* the same exception with this
> > config:
> >
> > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> > 2018-10-24T15:41:47-03:00)
> > Maven home: C:\productos\apache-maven-3.6.0\bin\..
> > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program
> > Files\Java\jdk1.7.0_80\jre
> > Default locale: es_AR, platform encoding: Cp1252
> > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> >
> > (actually it is a win 10 but it fails to recognze it).
> >
> > It works OK when remote debugging with mvnDebug.
> >
> > Don't know why throws a NoSuchElementException when trying to remove an
> > element on a non empty LinkedList...my best guess is that it is some sort
> > of bug in the hotspot optimization of the JVM.
> >
> > Which Java 7 specific update is running on Jenkins?
> >
> > Gabriel
> >
> > El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte (
> > rfscho...@apache.org) escribió:
> >
> >> Hi,
> >>
> >> sometimes the maven-plugin-plugin fails to write the plugin descriptor
> >> and
> >> exits with the exception below.
> >> I see the same unreliable behavior on our Jenkins servers too,
> >> re-running
> >> often fixes the issue.
> >> I have seen the issue several times locally when running with mvn.cmd,
> >> so
> >> far never with mvnDebug.cmd and always running with default #threads.
> >> I can't find a reason why elementStack[1] gets out of sync.
> >>
> >> If there are others experiencing the same or similar issues, please
> >> share
> >> your analysis.
> >> Hopefully we can solve this instability issue soon.
> >>
> >> thanks,
> >> Robert
> >>
> >> [1]
> >>
> >>
> http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L40
> >>
> >>
> >>
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor
> >> (default-descriptor) on project maven-javadoc-plugin: Execution
> >> default-descriptor of goal
> >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed.
> >> NoSuchElementException -> [Help 1]
> >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> >> execute
> >> goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor
> >> (default-descriptor) on project maven-javadoc-plugin: Execution
> >> default-descriptor of goal
> >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed
> >>
> >>
> >>
> >> Caused by: java.util.NoSuchElementException
> >>  at java.util.LinkedList.removeLast (LinkedList.java:281)
> >>  at org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.endElement
> >> (PrettyPrintXMLWriter.java:297)
> >>  at
> >>
> org.apache.maven.tools.plugin.generator.PluginDescriptorGenerator.writeDescriptor
> >>
> >> (PluginDescriptorGenerator.java:175)
> >>
> >> -
> >> 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
>
>

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Gabriel Belingueres]

Hi Robert:

I'm testing it and getting *consistently* the same exception with this
config:

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T15:41:47-03:00)
Maven home: C:\productos\apache-maven-3.6.0\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.7.0_80\jre
Default locale: es_AR, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

(actually it is a win 10 but it fails to recognze it).

It works OK when remote debugging with mvnDebug.

Don't know why throws a NoSuchElementException when trying to remove an
element on a non empty LinkedList...my best guess is that it is some sort
of bug in the hotspot optimization of the JVM.

Which Java 7 specific update is running on Jenkins?

Gabriel

El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte (
rfscho...@apache.org) escribió:

> Hi,
>
> sometimes the maven-plugin-plugin fails to write the plugin descriptor
> and
> exits with the exception below.
> I see the same unreliable behavior on our Jenkins servers too, re-running
> often fixes the issue.
> I have seen the issue several times locally when running with mvn.cmd, so
> far never with mvnDebug.cmd and always running with default #threads.
> I can't find a reason why elementStack[1] gets out of sync.
>
> If there are others experiencing the same or similar issues, please share
> your analysis.
> Hopefully we can solve this instability issue soon.
>
> thanks,
> Robert
>
> [1]
>
> http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L40
>
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor
> (default-descriptor) on project maven-javadoc-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed.
> NoSuchElementException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor
> (default-descriptor) on project maven-javadoc-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed
>
>
>
> Caused by: java.util.NoSuchElementException
>  at java.util.LinkedList.removeLast (LinkedList.java:281)
>  at org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.endElement
> (PrettyPrintXMLWriter.java:297)
>  at
> org.apache.maven.tools.plugin.generator.PluginDescriptorGenerator.writeDescriptor
>
> (PluginDescriptorGenerator.java:175)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: DefaultMavenReaderFilter API does not correctly interpolate collection variables

[Gabriel Belingueres]

Hi Simone:

Please check if you can safely upgrade your plexus-interpolation
dependency, as support to interpolate on arrays/lists/maps was deleted at
some point, but then added again in version 1.24.

Regards,
Gabriel

El mar., 16 de oct. de 2018 a la(s) 05:24, Simone Tripodi (
simonetrip...@apache.org) escribió:

> Thanks both for your kind reply, very appreciated!
>
> I was sure Plexus Interpolator supported that so I had the trouble I
> was doing something wrong at API level :)
>
> Keep up the good work, all the best!
> ~Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
> On Tue, Oct 16, 2018 at 10:12 AM Olivier Lamy  wrote:
> >
> > correct ATM we don't really have interpolation in such scripted way :(
> >
> >
> > On Tue, 16 Oct 2018 at 18:07, Robert Scholte 
> > wrote:
> >
> > > I recognize the issue,  but never paid attention to it since in
> general it
> > > doesn't make sense to access any listing entry in the pom by index. I
> have
> > > no solution here.
> > > Robert
> > > Verzonden vanaf mijn Samsung Galaxy-smartphone.
> > >  Oorspronkelijk bericht Van: Simone Tripodi <
> > > simonetrip...@apache.org> Datum: 15-10-18  12:12  (GMT+03:00) Aan:
> Maven
> > > Developers List  Onderwerp:
> > > DefaultMavenReaderFilter API does not correctly interpolate
> > >   collection variables
> > > Hi all mates,
> > >
> > > I am writing a plugin which needs to filter & then process resources,
> > > I am using the DefaultMavenReaderFilter API below:
> > >
> > >  DefaultMavenReaderFilter#filter( Reader, boolean, MavenProject,
> > > List, boolean, MavenSession )
> > >
> > > in my resource I declared few variables that have to be interpolated,
> > > everything works except:
> > >
> > >   "license": "${project.licenses[0].name}"
> > >
> > > which is not interpolated and keeps to be represented as the original
> > > string; if I try to replace it with
> > >
> > >   "license": "${project.licenses}",
> > >
> > > it is correctly interpolated as
> > >
> > >   "license":"[org.apache.maven.model.License@30135202]"
> > >
> > > Any idea what is wrong?
> > > Many thanks in advance!
> > > ~Simo
> > >
> > >  http://people.apache.org/~simonetripodi/
> > > http://twitter.com/simonetripodi
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.2

[Gabriel Belingueres]

+1

Thanks!!
Gabriel

2018-06-05 19:13 GMT-03:00 Hervé BOUTEMY :

> +1
>
> Regards,
>
> Hervé
>
> Le dimanche 3 juin 2018, 19:46:21 CEST Karl Heinz Marbaise a écrit :
> > Hi,
> >
> > We solved 2 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318121&ve
> > rsion=12343264
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MWAR%20AND%20reso
> > lution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%
> 20priority%20DESC%2C%
> > 20updated%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1432/
> >
> > https://repository.apache.org/content/repositories/maven-
> 1432/org/apache/mav
> > en/plugins/maven-war-plugin/3.2.2/maven-war-plugin-3.2.2-
> source-release.zip
> >
> > Source release checksum(s):
> > maven-war-plugin-3.2.2-source-release.zip sha1:
> > 707aa11b892eba1a45633dddf4f71d0394596787
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > 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
>
>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.1

[Gabriel Belingueres]

Great!!! Thank you

2018-05-13 5:16 GMT-03:00 Karl Heinz Marbaise :

> Hi Gabriel,
>
> I have added an issue for the upgrade of plexus-interpolation (MWAR-417)
> which is related to MWAR-303 and I will do a release of
> plexus-interpolation within the next daysafterwards I can make an other
> release of Maven WAR Plugin if this helps...
>
>
> Kind regards
> Karl Heinz Marbaise
> On 10/05/18 03:21, Gabriel Belingueres wrote:
>
>> any chance of adding MWAR-303 to the release? fix is already submitted.
>>
>> El mié., 9 de may. de 2018 20:14, Olivier Lamy 
>> escribió:
>>
>> +1
>>>
>>> On Thu, 10 May 2018 at 04:17, Karl Heinz Marbaise 
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> We solved 5 issues:
>>>>
>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12318121&version=12341729
>>>
>>>>
>>>> There are still a couple of issues left in JIRA:
>>>>
>>>>
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>> 20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>> 20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>>>
>>>>
>>>> Staging repo:
>>>> https://repository.apache.org/content/repositories/maven-1423/
>>>>
>>>>
>>>>
>>>> https://repository.apache.org/content/repositories/maven-142
>>> 3/org/apache/maven/plugins/maven-war-plugin/3.2.1/maven-war-
>>> plugin-3.2.1-source-release.zip
>>>
>>>>
>>>> Source release checksum(s):
>>>> maven-war-plugin-3.2.1-source-release.zip sha1:
>>>> 94317def832e4b767808dbed6b9463c75a99227c
>>>>
>>>> Staging site:
>>>> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>>>>
>>>> Guide to testing staged releases:
>>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>>>
>>>> Vote open for at least 72 hours.
>>>>
>>>> [ ] +1
>>>> [ ] +0
>>>> [ ] -1
>>>>
>>>>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.1

[Gabriel Belingueres]

any chance of adding MWAR-303 to the release? fix is already submitted.

El mié., 9 de may. de 2018 20:14, Olivier Lamy  escribió:

> +1
>
> On Thu, 10 May 2018 at 04:17, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > We solved 5 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12341729
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1423/
> >
> >
> >
> https://repository.apache.org/content/repositories/maven-1423/org/apache/maven/plugins/maven-war-plugin/3.2.1/maven-war-plugin-3.2.1-source-release.zip
> >
> > Source release checksum(s):
> > maven-war-plugin-3.2.1-source-release.zip sha1:
> > 94317def832e4b767808dbed6b9463c75a99227c
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.0

[Gabriel Belingueres]

Hi Karl:

The fix is on PR#5 which was committed after release 1.24, so a new release
is needed.
I tested the plugin with interpolation 1.25-SNAPSHOT and it solves MWAR-303,
but with the 1.24 release does not.

Gabriel

2017-10-02 5:33 GMT-03:00 Karl Heinz Marbaise :

> Hi,
>
>
> On 02/10/17 04:55, Gabriel Belingueres wrote:
>
>> Would it be possible to cut a release of plexus-interpolation and upgrade
>> this dependency to solve MWAR-303?
>>
>
> The plexus-interpolation version 1.24 is included which contains the PR#8
> ...so from my point of view this is already done (Need to close MWAR-303) ?
> Can you check that with that release?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>> 2017-09-30 13:16 GMT-03:00 Mikail Osipov :
>>
>> Am 2017-09-30 um 17:55 schrieb Karl Heinz Marbaise:
>>>
>>> Hi,
>>>>
>>>> We solved 3 issues:
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>>> ctId=12318121&version=12341372
>>>>
>>>> There are still a couple of issues left in JIRA:
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>>> 20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>>> 20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>>>>
>>>> Staging repo:
>>>> https://repository.apache.org/content/repositories/maven-1371
>>>> https://repository.apache.org/content/repositories/maven-137
>>>> 1/org/apache/maven/plugins/maven-war-plugin/3.2.0/maven-war-
>>>> plugin-3.2.0-source-release.zip
>>>>
>>>> Source release checksum(s):
>>>> maven-war-plugin-3.2.0-source-release.zip sha1:
>>>> 5c661f4554616147491036dfac689ba9db90cec2
>>>>
>>>>
>>>> Staging site:
>>>> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>>>>
>>>> Guide to testing staged releases:
>>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>>>
>>>> Vote open for at least 72 hours.
>>>>
>>>>
>>> +1
>>>
>>>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.0

[Gabriel Belingueres]

Would it be possible to cut a release of plexus-interpolation and upgrade
this dependency to solve MWAR-303?

2017-09-30 13:16 GMT-03:00 Mikail Osipov :

> Am 2017-09-30 um 17:55 schrieb Karl Heinz Marbaise:
>
>> Hi,
>>
>> We solved 3 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12318121&version=12341372
>>
>> There are still a couple of issues left in JIRA:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1371
>> https://repository.apache.org/content/repositories/maven-137
>> 1/org/apache/maven/plugins/maven-war-plugin/3.2.0/maven-war-
>> plugin-3.2.0-source-release.zip
>>
>> Source release checksum(s):
>> maven-war-plugin-3.2.0-source-release.zip sha1:
>> 5c661f4554616147491036dfac689ba9db90cec2
>>
>>
>> Staging site:
>> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>>
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for at least 72 hours.
>>
>
> +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Questions about how to contribute to Plexus

[Gabriel Belingueres]

Thanks!!!
Gabriel

2016-09-01 5:03 GMT-03:00 Kristian Rosenvold :

> I will take a look at your interpolation pr's this weekend unless
> someone picks it up before.
>
> Kristian
>
>
> 2016-09-01 0:46 GMT+02:00 Gabriel Belingueres :
> > Hi Robert:
> >
> > Regarding Plexus components, I created a couple of pull requests on
> > plexus-interpolator (and some related maven-filtering patches).
> > I have a few free hours this week that I could use to merge those PR to
> > speed up a new release. Is it possible to assign me write permission to
> > that repo?
> > In addition, I saw that Plexus components are not configured in public
> > Sonarqube instance (https://sonarqube.com/), so I could request if they
> > could be included too.
> >
> > Gabriel
> >
> > 2016-08-30 12:20 GMT-03:00 Robert Scholte :
> >
> >> Hi,
> >>
> >> all development on Plexus and Modello is done at
> >> https://github.com/codehaus-plexus
> >> Since Maven is probably one of the few projects still using this, we
> >> haven't invested in all the infra related stuff like mailinglists, etc.
> >> So we have the sources and the documentation, that's about it.
> >> This project is maintained by a subset of the Apache Maven team, so we
> can
> >> fix our own issues.
> >> Best way is to create pull requests there and ping us if you're waiting
> >> too long for a response.
> >>
> >> thanks,
> >> Robert
> >>
> >>
> >> On Mon, 29 Aug 2016 19:57:19 +0200, Plamen Totev 
> >> wrote:
> >>
> >> Hi,
> >>>
> >>> Recently I was granted write access to the plexus-io and
> plexus-archiver
> >>> GitHub repositories. I'm not sure where I can found any guides for
> >>> contributors. Also I can't found the plexus project mail list - not
> sure
> >>> where to write if I have questions related to the project. I would
> love to
> >>> contribute to the project and help it with the maintenance but not sure
> >>> about what to do so I'll be very grateful if you could give me some
> >>> directions where I can get more info or help.
> >>>
> >>> Thanks,
> >>>
> >>> Plamen Totev
> >>>
> >>> -
> >>> 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
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Questions about how to contribute to Plexus

[Gabriel Belingueres]

Hi Robert:

Regarding Plexus components, I created a couple of pull requests on
plexus-interpolator (and some related maven-filtering patches).
I have a few free hours this week that I could use to merge those PR to
speed up a new release. Is it possible to assign me write permission to
that repo?
In addition, I saw that Plexus components are not configured in public
Sonarqube instance (https://sonarqube.com/), so I could request if they
could be included too.

Gabriel

2016-08-30 12:20 GMT-03:00 Robert Scholte :

> Hi,
>
> all development on Plexus and Modello is done at
> https://github.com/codehaus-plexus
> Since Maven is probably one of the few projects still using this, we
> haven't invested in all the infra related stuff like mailinglists, etc.
> So we have the sources and the documentation, that's about it.
> This project is maintained by a subset of the Apache Maven team, so we can
> fix our own issues.
> Best way is to create pull requests there and ping us if you're waiting
> too long for a response.
>
> thanks,
> Robert
>
>
> On Mon, 29 Aug 2016 19:57:19 +0200, Plamen Totev 
> wrote:
>
> Hi,
>>
>> Recently I was granted write access to the plexus-io and plexus-archiver
>> GitHub repositories. I'm not sure where I can found any guides for
>> contributors. Also I can't found the plexus project mail list - not sure
>> where to write if I have questions related to the project. I would love to
>> contribute to the project and help it with the maintenance but not sure
>> about what to do so I'll be very grateful if you could give me some
>> directions where I can get more info or help.
>>
>> Thanks,
>>
>> Plamen Totev
>>
>> -
>> 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
>
>