Re: Additional Maturity Metadata in artifacts (especially in the pom)?
Indeed. I'm willing to work as liaison for Gradle :-) Let's make it work! Cheers, Andres --- Java Champion; Groovy Enthusiast JCP EC Associate Seat http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Mon, May 6, 2019 at 8:03 PM Robert Scholte wrote: > Some already know about my plan/wish to bring experts representing the > different buildtools, IDEs and artifact repositories together and work an > a new specification. > I am aware of the Gradle papers, haven't compared them yet with our first > proposals yet. > I'm sure we have the same goal, but this will only work if all related > parties join. > > thanks, > Robert > > > On Mon, 06 May 2019 19:53:58 +0200, Andres Almiray > wrote: > > > Hello everyone, > > > > FWIW Gradle has come up with its own metadata format (announced at > > https://blog.gradle.org/gradle-metadata-1.0, explained at > > > https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md > > ) > > > > Perhaps here's an opportunity to collaborate and decide on a common > > format > > and/or features that benefit all of us, what do you think? > > > > Cheers, > > Andres > > > > --- > > Java Champion; Groovy Enthusiast > > JCP EC Associate Seat > > http://andresalmiray.com > > http://www.linkedin.com/in/aalmiray > > -- > > What goes up, must come down. Ask any system administrator. > > There are 10 types of people in the world: Those who understand binary, > > and > > those who don't. > > To understand recursion, we must first understand recursion. > > > > > > On Mon, May 6, 2019 at 7:15 PM Robert Scholte > > wrote: > > > >> 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)?
Some already know about my plan/wish to bring experts representing the different buildtools, IDEs and artifact repositories together and work an a new specification. I am aware of the Gradle papers, haven't compared them yet with our first proposals yet. I'm sure we have the same goal, but this will only work if all related parties join. thanks, Robert On Mon, 06 May 2019 19:53:58 +0200, Andres Almiray wrote: Hello everyone, FWIW Gradle has come up with its own metadata format (announced at https://blog.gradle.org/gradle-metadata-1.0, explained at https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md ) Perhaps here's an opportunity to collaborate and decide on a common format and/or features that benefit all of us, what do you think? Cheers, Andres --- Java Champion; Groovy Enthusiast JCP EC Associate Seat http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Mon, May 6, 2019 at 7:15 PM Robert Scholte wrote: 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)?
Hello everyone, FWIW Gradle has come up with its own metadata format (announced at https://blog.gradle.org/gradle-metadata-1.0, explained at https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md ) Perhaps here's an opportunity to collaborate and decide on a common format and/or features that benefit all of us, what do you think? Cheers, Andres --- Java Champion; Groovy Enthusiast JCP EC Associate Seat http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Mon, May 6, 2019 at 7:15 PM Robert Scholte wrote: > 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 > >
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
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
Re: New release of ant-maven-plugin
Il lun 6 mag 2019, 14:47 Tibor Digana ha scritto: > I also would prefer using Java 8 in plugins but we have made an agreement > to use Java 7 and migrate plugins to API 3.0. > This means the ant-maven-plugin should be released with version 3.0.0. > > Enrico, do we loose some rules of Checkstyle if using the old version of > the plugin at Java 7 here in Maven? > Sorry, I don't know But checkstyle 8 needs java8 Enrico > Cheers > Tibor > > On Sat, May 4, 2019 at 9:01 PM Eric Lilja wrote: > > > I would not mind at all seeing latest 1.10.x of Ant being used instead (I > > believe 1.10.6 is being voted on at the moment), and the plugin requiring > > Java 8. I am also happy to hear that the checkstyle plugin didn't get > stuck > > on some older, Java 7-compatible release of Checkstyle, but is able to > > follow the latest versions! I think that's good! > > > > - Eric L > > > > On Sat, May 4, 2019 at 8:57 PM Enrico Olivelli > > wrote: > > > > > Il sab 4 mag 2019, 19:46 Eric Lilja ha scritto: > > > > > > > That's great news, Sylwester! Since it will be version 3.0 (as you > > say), > > > > I'm assuming the plugin will be changed to require Maven 3.x and > Java 7 > > > > (and update to latest Maven parents), as that is a target for > official > > > > Maven plugins versioned 3 and higher? And why can't we use ant > version > > > > 1.10.x, does it require Java 8? > > > > > > > > > > FYI we are doing the same for checkstyle plugin. Checkstyle now > requires > > > java8 and so the new version of the plugin will adapt to its core > > > dependency > > > > > > > > > Enrico > > > > > > > > > > > > > Looking forward to the release! > > > > > > > > - Eric L > > > > > > > > On Fri, May 3, 2019 at 9:48 PM Sylwester Lachiewicz < > > > slachiew...@gmail.com > > > > > > > > > wrote: > > > > > > > > > I have also updated Ant to 1.9.14 and I think we can already > prepare > > a > > > > vote > > > > > for the 3.0 release. > > > > > Sylwester > > > > > > > > > > niedz., 14 kwi 2019 o 22:35 Sebastian Laskawiec < > slask...@redhat.com > > > > > > > > napisał(a): > > > > > > > > > > > Hey Robert, > > > > > > > > > > > > Thank you for the heads up! > > > > > > > > > > > > I'm talking about this one: > > > > > > org.apache.maven.plugins > > > > > > maven-antrun-plugin > > > > > > 1.8 > > > > > > > > > > > > The one, that can run Ant scripts within a Maven project. > > > > > > > > > > > > Thanks, > > > > > > Sebastian > > > > > > > > > > > > On Sat, Apr 13, 2019 at 11:50 AM Robert Scholte < > > > rfscho...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Hi Sebastian, > > > > > > > > > > > > > > be careful with your naming, because my first response would > have > > > > been > > > > > > > 'no'. > > > > > > > > > > > > > > You're talking about ant-maven-plugin, whereas we maintain 2 > > > related > > > > > > > plugins: maven-ant-plugin and maven-antrun-plugin. > > > > > > > > > > > > > > The first one can generate Ant scripts based on a Maven > project. > > > This > > > > > > > project hasn't been touched for quite some time and it probably > > > > doesn't > > > > > > > make sense to maintain this plugin any longer. > > > > > > > > > > > > > > The latter on the other hand does make sense, however in > general > > it > > > > is > > > > > a > > > > > > > sign that you're doing a task that should be transformed to a > > > > dedicated > > > > > > > Maven plugin. > > > > > > > > > > > > > > So all we need is somebody to step up as the release manager. > > > > > > > Might be a good project for a Maven committer who has never > done > > a > > > > > > > release > > > > > > > before. > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > On Thu, 11 Apr 2019 09:28:02 +0200, Sebastian Laskawiec > > > > > > > wrote: > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > My name is Sebastian Łaskawiec and I'm a part of Keycloak > > > > Engineering > > > > > > > > Team > > > > > > > > [1]. > > > > > > > > > > > > > > > > Recently I hit a problem with resolving user properties that > > > seems > > > > to > > > > > > be > > > > > > > > fixed in Maven. I would love to give it a go but it seems we > > > didn't > > > > > > have > > > > > > > > any release for a very long time [2]. Could you please tell > me, > > > do > > > > > you > > > > > > > > plan > > > > > > > > to release a new version any time soon? > > > > > > > > > > > > > > > > On a side note, I already reached Hervé Boutemy, who asked me > > to > > > > > write > > > > > > to > > > > > > > > this email list and ask for release. Thank you for the hint, > > > Hervé! > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Sebastian Łaskawiec > > > > > > > > Senior Software Engineer @ Red Hat > > > > > > > > Keycloak Engineering Team > > > > > > > > > > > > > > > > [1] https://www.keycloak.org/ > > > > > > > > [2] https://github.com/apache/maven-antrun-plugin/releases > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: looking for some volunteer
Hello Dejan, I am glad that you are back again. yes, feel free. Github is yours. T On Mon, May 6, 2019 at 2:29 PM Dejan Stojadinovic wrote: > This one slipped slipped though the cracks (I was few weeks off the grid > due to traveling). Let me try to push something soon (if it is not too > late). > > On 2019/04/07 01:19:13, Tibor Digana wrote: > > Hi Dejan, > > > > I almost forgot your email. > > Pls create a PR on GitHub with a little work even if still incomplete but > > at least we would not forget it. > > As you can see in [1] we should create release branches and for your PR > as > > well. > > [1]: https://github.com/apache/maven-surefire/pull/227 > > > > Cheers > > Tibor > > > > > > On Tue, Mar 26, 2019 at 9:24 AM Dejan Stojadinovic > > wrote: > > > > > Thanx Tibor, I left short comments on JIRA issues (just to mark them). > > > I hope I will squeeze first github PR in a few days. > > > > > > Regards, > > > Dejan > > > > > > On 2019/03/24 23:19:08, Tibor Digana wrote: > > > > Hi Dejan, > > > > > > > > Good to hear. In our Jira are two issues related to my original > email: > > > > https://issues.apache.org/jira/browse/SUREFIRE-1654 > > > > https://issues.apache.org/jira/browse/SUREFIRE-1494 > > > > If you have any questions, feel free to ask here. > > > > Pls run the build locally (mvn -P run-its install) until our TravisCI > > > build > > > > would be ready for you. The build takes cca 1 hour to complete. > > > > We should solve these two issue in two separate pull requests. > > > > I guess these tasks require very good preparation and analysis of ITs > > > > before making any changes. > > > > > > > > @Enrico can you pls investigate TravisCI, why it still behaves so > much > > > > differently from Jenkins CI and fails? > > > > Is it really due to the deployed SNAPSHOT versions at ASF Nexus? > > > > > > > > Thx > > > > > > > > Cheers > > > > Tibor > > > > > > > > > > > > On Sun, Mar 24, 2019 at 3:23 PM Dejan Stojadinovic < > dejan2...@gmail.com> > > > > wrote: > > > > > > > > > Hi Tibor, > > > > > > > > > > I volunteer for this. I have a solid experience with maven usage > and > > > also > > > > > contributed few (easy) maven commits: > > > > > https://github.com/apache/maven/commits?author=dejan2609 > > > > > > > > > > Regards, > > > > > Dejan Stojadinović > > > > > > > > > > On 2019/03/23 21:47:04, Tibor Digana > wrote: > > > > > > It's going to be very pedant work for someone who want to help > us in > > > > > > Surefire. > > > > > > > > > > > > I am looking for some volunteer who will remove the deprecated > config > > > > > param > > > > > > `forkMode` in favor of `forkCount`. All our ITs should use > > > `forkCount` > > > > > > since then. > > > > > > > > > > > > Additionally, the volunteer should deprecate `surefire-junit4` > > > provider. > > > > > > Instead `surefire-junit47` provider should be selected as default > > > > > provider > > > > > > for JUnit4 tests. Again the ITs should be changed and plugin > > > dependencies > > > > > > should use `surefire-junit4` provider in place where it was not > > > > > specified. > > > > > > > > > > > > It's easy to do. When you see the usages of `.forkMode()` method > - > > > only > > > > > 20 > > > > > > in `surefire-its` and 43 usages of `` in > > > > > > `surefire-its/src/test/resources`. > > > > > > > > > > > > Successful build must prove that the changes have been applied > > > correctly. > > > > > > The changes should be in a pull request on GitHub. > > > > > > > > > > > > Cheers > > > > > > Tibor > > > > > > > > > > > > > > > > > - > > > > > 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: New release of ant-maven-plugin
I also would prefer using Java 8 in plugins but we have made an agreement to use Java 7 and migrate plugins to API 3.0. This means the ant-maven-plugin should be released with version 3.0.0. Enrico, do we loose some rules of Checkstyle if using the old version of the plugin at Java 7 here in Maven? Cheers Tibor On Sat, May 4, 2019 at 9:01 PM Eric Lilja wrote: > I would not mind at all seeing latest 1.10.x of Ant being used instead (I > believe 1.10.6 is being voted on at the moment), and the plugin requiring > Java 8. I am also happy to hear that the checkstyle plugin didn't get stuck > on some older, Java 7-compatible release of Checkstyle, but is able to > follow the latest versions! I think that's good! > > - Eric L > > On Sat, May 4, 2019 at 8:57 PM Enrico Olivelli > wrote: > > > Il sab 4 mag 2019, 19:46 Eric Lilja ha scritto: > > > > > That's great news, Sylwester! Since it will be version 3.0 (as you > say), > > > I'm assuming the plugin will be changed to require Maven 3.x and Java 7 > > > (and update to latest Maven parents), as that is a target for official > > > Maven plugins versioned 3 and higher? And why can't we use ant version > > > 1.10.x, does it require Java 8? > > > > > > > FYI we are doing the same for checkstyle plugin. Checkstyle now requires > > java8 and so the new version of the plugin will adapt to its core > > dependency > > > > > > Enrico > > > > > > > > > Looking forward to the release! > > > > > > - Eric L > > > > > > On Fri, May 3, 2019 at 9:48 PM Sylwester Lachiewicz < > > slachiew...@gmail.com > > > > > > > wrote: > > > > > > > I have also updated Ant to 1.9.14 and I think we can already prepare > a > > > vote > > > > for the 3.0 release. > > > > Sylwester > > > > > > > > niedz., 14 kwi 2019 o 22:35 Sebastian Laskawiec > > > > > napisał(a): > > > > > > > > > Hey Robert, > > > > > > > > > > Thank you for the heads up! > > > > > > > > > > I'm talking about this one: > > > > > org.apache.maven.plugins > > > > > maven-antrun-plugin > > > > > 1.8 > > > > > > > > > > The one, that can run Ant scripts within a Maven project. > > > > > > > > > > Thanks, > > > > > Sebastian > > > > > > > > > > On Sat, Apr 13, 2019 at 11:50 AM Robert Scholte < > > rfscho...@apache.org> > > > > > wrote: > > > > > > > > > > > Hi Sebastian, > > > > > > > > > > > > be careful with your naming, because my first response would have > > > been > > > > > > 'no'. > > > > > > > > > > > > You're talking about ant-maven-plugin, whereas we maintain 2 > > related > > > > > > plugins: maven-ant-plugin and maven-antrun-plugin. > > > > > > > > > > > > The first one can generate Ant scripts based on a Maven project. > > This > > > > > > project hasn't been touched for quite some time and it probably > > > doesn't > > > > > > make sense to maintain this plugin any longer. > > > > > > > > > > > > The latter on the other hand does make sense, however in general > it > > > is > > > > a > > > > > > sign that you're doing a task that should be transformed to a > > > dedicated > > > > > > Maven plugin. > > > > > > > > > > > > So all we need is somebody to step up as the release manager. > > > > > > Might be a good project for a Maven committer who has never done > a > > > > > > release > > > > > > before. > > > > > > > > > > > > Robert > > > > > > > > > > > > On Thu, 11 Apr 2019 09:28:02 +0200, Sebastian Laskawiec > > > > > > wrote: > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > My name is Sebastian Łaskawiec and I'm a part of Keycloak > > > Engineering > > > > > > > Team > > > > > > > [1]. > > > > > > > > > > > > > > Recently I hit a problem with resolving user properties that > > seems > > > to > > > > > be > > > > > > > fixed in Maven. I would love to give it a go but it seems we > > didn't > > > > > have > > > > > > > any release for a very long time [2]. Could you please tell me, > > do > > > > you > > > > > > > plan > > > > > > > to release a new version any time soon? > > > > > > > > > > > > > > On a side note, I already reached Hervé Boutemy, who asked me > to > > > > write > > > > > to > > > > > > > this email list and ask for release. Thank you for the hint, > > Hervé! > > > > > > > > > > > > > > Thanks, > > > > > > > Sebastian Łaskawiec > > > > > > > Senior Software Engineer @ Red Hat > > > > > > > Keycloak Engineering Team > > > > > > > > > > > > > > [1] https://www.keycloak.org/ > > > > > > > [2] https://github.com/apache/maven-antrun-plugin/releases > > > > > > > > > > > > > > > > > > > > >
Re: looking for some volunteer
This one slipped slipped though the cracks (I was few weeks off the grid due to traveling). Let me try to push something soon (if it is not too late). On 2019/04/07 01:19:13, Tibor Digana wrote: > Hi Dejan, > > I almost forgot your email. > Pls create a PR on GitHub with a little work even if still incomplete but > at least we would not forget it. > As you can see in [1] we should create release branches and for your PR as > well. > [1]: https://github.com/apache/maven-surefire/pull/227 > > Cheers > Tibor > > > On Tue, Mar 26, 2019 at 9:24 AM Dejan Stojadinovic > wrote: > > > Thanx Tibor, I left short comments on JIRA issues (just to mark them). > > I hope I will squeeze first github PR in a few days. > > > > Regards, > > Dejan > > > > On 2019/03/24 23:19:08, Tibor Digana wrote: > > > Hi Dejan, > > > > > > Good to hear. In our Jira are two issues related to my original email: > > > https://issues.apache.org/jira/browse/SUREFIRE-1654 > > > https://issues.apache.org/jira/browse/SUREFIRE-1494 > > > If you have any questions, feel free to ask here. > > > Pls run the build locally (mvn -P run-its install) until our TravisCI > > build > > > would be ready for you. The build takes cca 1 hour to complete. > > > We should solve these two issue in two separate pull requests. > > > I guess these tasks require very good preparation and analysis of ITs > > > before making any changes. > > > > > > @Enrico can you pls investigate TravisCI, why it still behaves so much > > > differently from Jenkins CI and fails? > > > Is it really due to the deployed SNAPSHOT versions at ASF Nexus? > > > > > > Thx > > > > > > Cheers > > > Tibor > > > > > > > > > On Sun, Mar 24, 2019 at 3:23 PM Dejan Stojadinovic > > > wrote: > > > > > > > Hi Tibor, > > > > > > > > I volunteer for this. I have a solid experience with maven usage and > > also > > > > contributed few (easy) maven commits: > > > > https://github.com/apache/maven/commits?author=dejan2609 > > > > > > > > Regards, > > > > Dejan Stojadinović > > > > > > > > On 2019/03/23 21:47:04, Tibor Digana wrote: > > > > > It's going to be very pedant work for someone who want to help us in > > > > > Surefire. > > > > > > > > > > I am looking for some volunteer who will remove the deprecated config > > > > param > > > > > `forkMode` in favor of `forkCount`. All our ITs should use > > `forkCount` > > > > > since then. > > > > > > > > > > Additionally, the volunteer should deprecate `surefire-junit4` > > provider. > > > > > Instead `surefire-junit47` provider should be selected as default > > > > provider > > > > > for JUnit4 tests. Again the ITs should be changed and plugin > > dependencies > > > > > should use `surefire-junit4` provider in place where it was not > > > > specified. > > > > > > > > > > It's easy to do. When you see the usages of `.forkMode()` method - > > only > > > > 20 > > > > > in `surefire-its` and 43 usages of `` in > > > > > `surefire-its/src/test/resources`. > > > > > > > > > > Successful build must prove that the changes have been applied > > correctly. > > > > > The changes should be in a pull request on GitHub. > > > > > > > > > > Cheers > > > > > Tibor > > > > > > > > > > > > > - > > > > 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
Deprecating HTTP access to Central
Last year, we deprecated old and insecure TLS protocols on Central to make access more secure. This year, we're moving things forward again by deprecating and later removing access to insecure by default HTTP access. Right now this affects less than 20% of the traffic hitting Central. To find out more about the timelines and details, see here: https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/ Thanks, Brian CTO, Sonatype Apache Maven PMC Member - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Additional Maturity Metadata in artifacts (especially in the pom)?
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
