Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)
+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...
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
Remote repositories should always provide a model 4.0.0 pom, otherwise tools including all currently known Maven versions will not work. The first check is if the modelVersion is 4.0.0, otherwise Maven will simply stop working. Since the pom on the system is copied/uploaded as-is, there's no way to do real improvements on the pom right now. This is quite hardened is Maven Core. So one of the things we are working on is implementing a way where the build-pom can be adjusted to a valid 4.0.0 before being published. Maven 3.6.x already contains a couple of preparations. Once there's a separation, real improvements can be done. And then it makes sense to keep the the pom for builds, upload it as 4.0.0 and some new + improved format. Robert On Wed, 08 May 2019 22:48:38 +0200, Christofer Dutz wrote: Ok ... And what's the: 4.0.0 And the: xmlns="http://maven.apache.org/POM/4.0.0"; About? One should think that a system like Nexus should be able to be extended to support multiple POM Versions ... So as this metadata adds new features, wouldn't this simply be a modelVersion=4.1.0? Chris Am 08.05.19, 20:38 schrieb "Robert Scholte" : On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz wrote: > Well depending on how much metadata should be added ... > > Guess we already have a lot of stuff in the pom.xml which is considered > metadata ... having some additional optional elements shouldn't break > anything (I think) This part is actually very tricky. We've done it recently in order to control SCM path resolution, but it did break at several places, e.g. uploads to Centrals didn't work, because poms are validated against the 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the same version, not that elegant. If there is a place in the current version (e.g. existing String element with new value) we could consider it, otherwise I would like to push it forward. thanks, Robert [1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with child.scm) > But adding some additional files exclusively used for metadata might > also be an option ... would this be alongside the pom and artifacts or > inside the artifacts as static resources? > Cause having additional files alongside the pom and jar artifacts for > example could require changing the tooling ... jar-embedded or > pom-embedded resources should work out of the box. > > Chris > > Am 06.05.19, 19:15 schrieb "Robert Scholte" : > > Assuming we need a new metadatafile in the future to extend/enrich > the > current pom file, do you think it would fit in something like a PDT > file[1]? >If so, please at a comment so we can take it into account when > working on > new specifications. >Robert >[1] > https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema >On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz > wrote: >> Hi all, > > > > I am currently working hard on adding support for other languages > in the > > PLC4X maven build. While working on the python I noticed that they > have > > some sort of maturity self-assessment metadata in their artifacts > and I > > think that actually quite a good thing. > > > > Doing some research I couldn’t find any means to provide similar > data > > for maven. > > > > In PLC4X we have a lot of modules. Some are older and mature, but > others > > we’d like to mark as experimental. > > It would be great if we could also provide enforcer rules to for > example > > allow only mature modules or modules with a maturity scoring of at > least > > X … > > > > I thing we could achieve something like this manually, by providing > > metadata in form of resources in the jars and custom enforcer > modules, > > but that would be an island solution only working in our domain. I > think > > this could be beneficial to the entire Maven ecosystem to have > something > > more generic in the system itself. > > > > Any thoughts & suggestions on this? > > > > Chris > - > 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: Additional Maturity Metadata in artifacts (especially in the pom)?
Ok ... And what's the: 4.0.0 And the: xmlns="http://maven.apache.org/POM/4.0.0"; About? One should think that a system like Nexus should be able to be extended to support multiple POM Versions ... So as this metadata adds new features, wouldn't this simply be a modelVersion=4.1.0? Chris Am 08.05.19, 20:38 schrieb "Robert Scholte" : On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz wrote: > Well depending on how much metadata should be added ... > > Guess we already have a lot of stuff in the pom.xml which is considered > metadata ... having some additional optional elements shouldn't break > anything (I think) This part is actually very tricky. We've done it recently in order to control SCM path resolution, but it did break at several places, e.g. uploads to Centrals didn't work, because poms are validated against the 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the same version, not that elegant. If there is a place in the current version (e.g. existing String element with new value) we could consider it, otherwise I would like to push it forward. thanks, Robert [1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with child.scm) > But adding some additional files exclusively used for metadata might > also be an option ... would this be alongside the pom and artifacts or > inside the artifacts as static resources? > Cause having additional files alongside the pom and jar artifacts for > example could require changing the tooling ... jar-embedded or > pom-embedded resources should work out of the box. > > Chris > > Am 06.05.19, 19:15 schrieb "Robert Scholte" : > > Assuming we need a new metadatafile in the future to extend/enrich > the > current pom file, do you think it would fit in something like a PDT > file[1]? >If so, please at a comment so we can take it into account when > working on > new specifications. >Robert >[1] > https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema >On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz > wrote: >> Hi all, > > > > I am currently working hard on adding support for other languages > in the > > PLC4X maven build. While working on the python I noticed that they > have > > some sort of maturity self-assessment metadata in their artifacts > and I > > think that actually quite a good thing. > > > > Doing some research I couldn’t find any means to provide similar > data > > for maven. > > > > In PLC4X we have a lot of modules. Some are older and mature, but > others > > we’d like to mark as experimental. > > It would be great if we could also provide enforcer rules to for > example > > allow only mature modules or modules with a maturity scoring of at > least > > X … > > > > I thing we could achieve something like this manually, by providing > > metadata in form of resources in the jars and custom enforcer > modules, > > but that would be an island solution only working in our domain. I > think > > this could be beneficial to the entire Maven ecosystem to have > something > > more generic in the system itself. > > > > Any thoughts & suggestions on this? > > > > Chris >- > 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
[VOTE] Release Apache Maven JAR Plugin version 3.1.2
Hi, We solved 2 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526&version=12344629 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1502/ https://repository.apache.org/content/repositories/maven-1502/org/apache/maven/plugins/maven-jar-plugin/3.1.2/maven-jar-plugin-3.1.2-source-release.zip Source release checksum(s): maven-jar-plugin-3.1.2-source-release.zip sha1: cb3abae243455afbca49cc1b9f156235411223e2 maven-jar-plugin-3.1.2-source-release.zip sha512: aff5baf3c218ab79e1f15b59f3c7e6c0c0b5344b13cf62d1aef03be34a8f90b75ceb51c7d8a28f1916becdcc48ec869b426bcb71365de364a93b981050d1fd70 Staging site: https://maven.apache.org/plugins-archives/maven-jar-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)
+1 T
Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)
+1 regards, Hervé Le mercredi 8 mai 2019, 20:25:14 CEST Robert Scholte a écrit : > 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... - 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)
+1 /Anders (mobile) Den ons 8 maj 2019 20:25Robert Scholte skrev: > 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...
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz wrote: Well depending on how much metadata should be added ... Guess we already have a lot of stuff in the pom.xml which is considered metadata ... having some additional optional elements shouldn't break anything (I think) This part is actually very tricky. We've done it recently in order to control SCM path resolution, but it did break at several places, e.g. uploads to Centrals didn't work, because poms are validated against the 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the same version, not that elegant. If there is a place in the current version (e.g. existing String element with new value) we could consider it, otherwise I would like to push it forward. thanks, Robert [1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with child.scm) But adding some additional files exclusively used for metadata might also be an option ... would this be alongside the pom and artifacts or inside the artifacts as static resources? Cause having additional files alongside the pom and jar artifacts for example could require changing the tooling ... jar-embedded or pom-embedded resources should work out of the box. Chris Am 06.05.19, 19:15 schrieb "Robert Scholte" : Assuming we need a new metadatafile in the future to extend/enrich the current pom file, do you think it would fit in something like a PDT file[1]? If so, please at a comment so we can take it into account when working on new specifications. Robert [1] https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz wrote: > Hi all, > > I am currently working hard on adding support for other languages in the > PLC4X maven build. While working on the python I noticed that they have > some sort of maturity self-assessment metadata in their artifacts and I > think that actually quite a good thing. > > Doing some research I couldn’t find any means to provide similar data > for maven. > > In PLC4X we have a lot of modules. Some are older and mature, but others > we’d like to mark as experimental. > It would be great if we could also provide enforcer rules to for example > allow only mature modules or modules with a maturity scoring of at least > X … > > I thing we could achieve something like this manually, by providing > metadata in form of resources in the jars and custom enforcer modules, > but that would be an island solution only working in our domain. I think > this could be beneficial to the entire Maven ecosystem to have something > more generic in the system itself. > > Any thoughts & suggestions on this? > > Chris - 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: [VOTE] Retired Maven Artifact Resolution API (Maven2)
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 08.05.19 20:25, Robert Scholte wrote: 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... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Retired Maven Artifact Resolution API (Maven2)
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...
Re: Regarding MJAR-259 and MSOURCES-119
It's dependency:resolve-plugins that's wrong. What you can do is run a Maven build with the -X flag and look at the beginning of the maven-jar-plugin execution. There you should see the resolved tree of the plugin's dependencies. /Anders On Wed, May 8, 2019 at 11:18 AM Eric Lilja wrote: > Hi, and thanks for the answers! We (and many others I'm sure) are happy to > see new releases as soon as possible, of course :-) > > Anders: Thanks for the workaround, I implemented it in our corporate pom > for maven-jar-plugin and maven-source-plugin, plus maven-javadoc-plugin. > Then I wiped out .m2/repository and built the corporate parent and then one > of our smaller projects (which had been changed to use the new parent > version). I could see it downloaded version 4.1.0 of plexus-archiver, along > with 3.3, 3.4, 3.5, 3.6.0, and 3.7.0 (it was simple mvn clean install, > which also builds a source-jar and javadocs). > > However, when I do: dependency:resolve-plugins, I get: > [INFO] > org.apache.maven.plugins:maven-jar-plugin:maven-plugin:3.1.1:runtime > [INFO] org.apache.maven.plugins:maven-jar-plugin:jar:3.1.1 > [INFO] org.apache.maven:maven-plugin-api:jar:3.0 > [INFO] org.apache.maven:maven-model:jar:3.0 > [INFO] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 > [INFO] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2 > [INFO] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7 > [INFO] org.apache.maven:maven-core:jar:3.0 > [INFO] org.apache.maven:maven-settings:jar:3.0 > [INFO] org.apache.maven:maven-settings-builder:jar:3.0 > [INFO] org.apache.maven:maven-repository-metadata:jar:3.0 > [INFO] org.apache.maven:maven-model-builder:jar:3.0 > [INFO] org.apache.maven:maven-aether-provider:jar:3.0 > [INFO] org.sonatype.aether:aether-impl:jar:1.7 > [INFO] org.sonatype.aether:aether-spi:jar:1.7 > [INFO] org.sonatype.aether:aether-api:jar:1.7 > [INFO] org.sonatype.aether:aether-util:jar:1.7 > [INFO] org.codehaus.plexus:plexus-interpolation:jar:1.14 > [INFO] org.codehaus.plexus:plexus-classworlds:jar:2.2.3 > [INFO] org.codehaus.plexus:plexus-component-annotations:jar:1.7.1 > [INFO] org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3 > [INFO] org.sonatype.plexus:plexus-cipher:jar:1.4 > [INFO] org.apache.maven:maven-artifact:jar:3.0 > [INFO] org.apache.maven:maven-archiver:jar:3.3.0 > [INFO] org.apache.maven.shared:maven-shared-utils:jar:3.2.1 > [INFO] commons-io:commons-io:jar:2.5 > [INFO] org.codehaus.plexus:plexus-archiver:jar:3.7.0 <-- > [INFO] org.codehaus.plexus:plexus-io:jar:3.1.0 > [INFO] org.apache.commons:commons-compress:jar:1.18 > [INFO] org.iq80.snappy:snappy:jar:0.4 > [INFO] org.tukaani:xz:jar:1.8 > [INFO] org.codehaus.plexus:plexus-utils:jar:3.1.0 > > Here's it still listing 3.7.0 of plexus-archiver, did it not work or does > dependency:resolve-plugins fail to pick up version overrides? Same behavior > for maven-source-plugin and maven-javadoc-plugin, both list their original > dependencies in dependency:resolve-plugins > > (Unrelated question: Is the order of dependencies random in the above list > or is it classpath order? If it's random, it would be better if it was > sorted, so it's easy for the human eye to scan for a particular dependency) > > - Eric L > > On Tue, May 7, 2019 at 9:16 PM Anders Hammar wrote: > > > Checking m-jar-p, what is needed is an upgrade of plexus-archiver to > > version 4.0.0+ as it includes an upgraded dependency to plexus-io v3.1.1. > > See [1]. > > If you include m-jar-p in the pluginManagement section of your corporate > > parent-POM, you could bump this on the existing maven-jar-plugin v3.1.1 > > like this: > > > > org.apache.maven.plugins > > maven-jar-plugin > > 3.1.1 > > > > > > org.codehaus.plexus > > plexus-archiver > > 4.1.0 > > > > > > > > > > [1] > > > > > https://github.com/codehaus-plexus/plexus-archiver/blob/master/ReleaseNotes.md#plexus-archiver-400 > > > > /Anders > > > > On Tue, May 7, 2019 at 8:07 PM Eric Lilja wrote: > > > > > Hi, in my organization we're seeing big increases in build time using > > newer > > > versions of maven-jar-plugin and maven-sources-plugin, because those > > > plugins are affected by a bug in plexus-io. > > > > > > The issue in plexus-io has been fixed since some time: [1] and I > > believe a > > > release has been made of relevant plexus components containing the fix > > (but > > > I might be wrong about that). > > > > > > However, both MJAR-259 [2] and MSOURCES-119 [3] are still open. When > can > > we > > > expect new releases of these two plugins (and other plugins/components > > > affec
Re: Regarding MJAR-259 and MSOURCES-119
Hi, and thanks for the answers! We (and many others I'm sure) are happy to see new releases as soon as possible, of course :-) Anders: Thanks for the workaround, I implemented it in our corporate pom for maven-jar-plugin and maven-source-plugin, plus maven-javadoc-plugin. Then I wiped out .m2/repository and built the corporate parent and then one of our smaller projects (which had been changed to use the new parent version). I could see it downloaded version 4.1.0 of plexus-archiver, along with 3.3, 3.4, 3.5, 3.6.0, and 3.7.0 (it was simple mvn clean install, which also builds a source-jar and javadocs). However, when I do: dependency:resolve-plugins, I get: [INFO] org.apache.maven.plugins:maven-jar-plugin:maven-plugin:3.1.1:runtime [INFO] org.apache.maven.plugins:maven-jar-plugin:jar:3.1.1 [INFO] org.apache.maven:maven-plugin-api:jar:3.0 [INFO] org.apache.maven:maven-model:jar:3.0 [INFO] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 [INFO] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2 [INFO] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7 [INFO] org.apache.maven:maven-core:jar:3.0 [INFO] org.apache.maven:maven-settings:jar:3.0 [INFO] org.apache.maven:maven-settings-builder:jar:3.0 [INFO] org.apache.maven:maven-repository-metadata:jar:3.0 [INFO] org.apache.maven:maven-model-builder:jar:3.0 [INFO] org.apache.maven:maven-aether-provider:jar:3.0 [INFO] org.sonatype.aether:aether-impl:jar:1.7 [INFO] org.sonatype.aether:aether-spi:jar:1.7 [INFO] org.sonatype.aether:aether-api:jar:1.7 [INFO] org.sonatype.aether:aether-util:jar:1.7 [INFO] org.codehaus.plexus:plexus-interpolation:jar:1.14 [INFO] org.codehaus.plexus:plexus-classworlds:jar:2.2.3 [INFO] org.codehaus.plexus:plexus-component-annotations:jar:1.7.1 [INFO] org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3 [INFO] org.sonatype.plexus:plexus-cipher:jar:1.4 [INFO] org.apache.maven:maven-artifact:jar:3.0 [INFO] org.apache.maven:maven-archiver:jar:3.3.0 [INFO] org.apache.maven.shared:maven-shared-utils:jar:3.2.1 [INFO] commons-io:commons-io:jar:2.5 [INFO] org.codehaus.plexus:plexus-archiver:jar:3.7.0 <-- [INFO] org.codehaus.plexus:plexus-io:jar:3.1.0 [INFO] org.apache.commons:commons-compress:jar:1.18 [INFO] org.iq80.snappy:snappy:jar:0.4 [INFO] org.tukaani:xz:jar:1.8 [INFO] org.codehaus.plexus:plexus-utils:jar:3.1.0 Here's it still listing 3.7.0 of plexus-archiver, did it not work or does dependency:resolve-plugins fail to pick up version overrides? Same behavior for maven-source-plugin and maven-javadoc-plugin, both list their original dependencies in dependency:resolve-plugins (Unrelated question: Is the order of dependencies random in the above list or is it classpath order? If it's random, it would be better if it was sorted, so it's easy for the human eye to scan for a particular dependency) - Eric L On Tue, May 7, 2019 at 9:16 PM Anders Hammar wrote: > Checking m-jar-p, what is needed is an upgrade of plexus-archiver to > version 4.0.0+ as it includes an upgraded dependency to plexus-io v3.1.1. > See [1]. > If you include m-jar-p in the pluginManagement section of your corporate > parent-POM, you could bump this on the existing maven-jar-plugin v3.1.1 > like this: > > org.apache.maven.plugins > maven-jar-plugin > 3.1.1 > > > org.codehaus.plexus > plexus-archiver > 4.1.0 > > > > > [1] > > https://github.com/codehaus-plexus/plexus-archiver/blob/master/ReleaseNotes.md#plexus-archiver-400 > > /Anders > > On Tue, May 7, 2019 at 8:07 PM Eric Lilja wrote: > > > Hi, in my organization we're seeing big increases in build time using > newer > > versions of maven-jar-plugin and maven-sources-plugin, because those > > plugins are affected by a bug in plexus-io. > > > > The issue in plexus-io has been fixed since some time: [1] and I > believe a > > release has been made of relevant plexus components containing the fix > (but > > I might be wrong about that). > > > > However, both MJAR-259 [2] and MSOURCES-119 [3] are still open. When can > we > > expect new releases of these two plugins (and other plugins/components > > affected by the same issue)? Is something block the release or no one > > simply got around to it yet? > > > > We're trying to stay current and modern in our little eco-system at work, > > but this issue is holding us back on older versions of aforementioned > > plugins. > > > > Thanks for your time! > > > > - Eric L > > > > [1] https://github.com/codehaus-plexus/plexus-io/pull/17 > > [2] https://issues.apache.org/jira/browse/MJAR-259 > > [3] https://issues.apache.org/jira/browse/MSOURCES-11
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
Well depending on how much metadata should be added ... Guess we already have a lot of stuff in the pom.xml which is considered metadata ... having some additional optional elements shouldn't break anything (I think) But adding some additional files exclusively used for metadata might also be an option ... would this be alongside the pom and artifacts or inside the artifacts as static resources? Cause having additional files alongside the pom and jar artifacts for example could require changing the tooling ... jar-embedded or pom-embedded resources should work out of the box. Chris Am 06.05.19, 19:15 schrieb "Robert Scholte" : Assuming we need a new metadatafile in the future to extend/enrich the current pom file, do you think it would fit in something like a PDT file[1]? If so, please at a comment so we can take it into account when working on new specifications. Robert [1] https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz wrote: > Hi all, > > I am currently working hard on adding support for other languages in the > PLC4X maven build. While working on the python I noticed that they have > some sort of maturity self-assessment metadata in their artifacts and I > think that actually quite a good thing. > > Doing some research I couldn’t find any means to provide similar data > for maven. > > In PLC4X we have a lot of modules. Some are older and mature, but others > we’d like to mark as experimental. > It would be great if we could also provide enforcer rules to for example > allow only mature modules or modules with a maturity scoring of at least > X … > > I thing we could achieve something like this manually, by providing > metadata in form of resources in the jars and custom enforcer modules, > but that would be an island solution only working in our domain. I think > this could be beneficial to the entire Maven ecosystem to have something > more generic in the system itself. > > Any thoughts & suggestions on this? > > Chris - 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
