Re: Snapshots of core Maven plugins
Il dom 21 apr 2019, 18:01 Hervé BOUTEMY ha scritto: > is someone working on it? > the code is here: https://github.com/apache/maven-jenkins-lib > PRs welcome > > The deploy has to happen only from master branch, once the build and ITs > run > on every platform and JDK is ok > Then the strategy to choose which build (platform and JDK) has to be > deployed > will have to be chosen: I advise to start with whichever implementation > makes > the implementor happy before we start the discussion on choosing the > definitive strategy we'll choose as a whole... > Currently I would build and deploy with jdk11 (assuming that it is producing better bytecode then older versions). OS should not be a problem (but I would stay on linux). The only risk is that as we are not using 'release' flag for javac we could produce code not 100% compatible with every supported version. Just my 2 cents Enrico > Regards, > > Hervé > > Le lundi 15 avril 2019, 12:58:23 CEST Marc Philipp a écrit : > > Hi all, > > > > based on a discussion with Enrico Olivelli on Slack [1], I’d like to > bring > > up the topic of automated publishing of snapshots of core Maven plugins. > > > > Currently, some plugins have snapshots in the ASF’s snapshot repo [2] and > > others (such as the maven-checkstyle-plugin) don’t have any. The ones > that > > are published are often outdated and do not contain the latest changes. > > > > I work for Gradle and we’re developing a Maven extension that we’d like > to > > test against the latest snapshots of Maven and all supported plugins. I > > think having snapshots published automatically with every commit to the > > development branch would be generally useful for developers who would > like > > to try out the latest version to provide feedback etc. > > > > So, first of all, I’d like to discuss with you if you think publishing > > snapshots automatically would be useful. If so, I’d be happy to > contribute > > although I expect the changes would mostly have to be made in Jenkins. > > > > Cheers, > > > > Marc > > > > [1] https://the-asf.slack.com/archives/C7Q9JB404/p1555263260044100 > > [2] > https://repository.apache.org/content/repositories/snapshots/org/apache/ > > maven/plugins/ > > > > > > Marc Philipp > > Senior Software Engineer > > Gradle > > W. gradle.com > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Bumping Checkstyle plugin version to 3.1.0-SNAPSHOT (from 3.0.1-SNAPSHOT)
Committed. Can any JIRA admin rename version 3.0.1 to 3.1.0 please ? Thanks Enrico Il dom 21 apr 2019, 21:07 Stephen Connolly ha scritto: > On Sun 21 Apr 2019 at 16:24, Enrico Olivelli wrote: > > > Hi, > > I want to commit this breaking change [1] in checkstyle plugin, > > that is the upgrade [2] to latest checkstyle (8.x) and thus the making > > Java 8 the minimum version for the plugin. > > > > Currently I have 3.0.1-SNAPSHOT on master, > > I think I need to move to 3.1.0-SNAPSHOT. > > > +1 > > > > > > Is is better to bump the version to 3.1.0-SNAPSHOT and then commit the > > breaking change or commit the change and then commit the new version ? > > > > I feel it is better to change the version to 3.1.0-SNAPSHOT and then > > commit the breaking change. > > > > Any review on the PR is well appreciated as well > > > > Best regards and Happy Easter ! > > Enrico > > > > [1] https://github.com/apache/maven-checkstyle-plugin/pull/13 > > [2] https://issues.apache.org/jira/browse/MCHECKSTYLE-366 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > Sent from my phone >
Re: MRELEASE-985(again)
Hi Petar, can you confirm that only dependency versions are picked up from commandline, and not any other property? And if you do a release, please make it a M1 (milestone 1), because there are quite some changes that should be part of the final 3.0.0 thanks, Robert On Mon, 22 Apr 2019 08:37:02 +0200, Petar Tahchiev wrote: Hello, if somebody would confirm my changes are OK, I'd like to perform a release of the maven-release-plugin - the last release is almost 4 years old. На нд, 21.04.2019 г. в 13:29 ч. Petar Tahchiev написа: Hi Robert, and thank you for your response. I have pushed a test which fails if I revert my changes. The test passes with my changes. Please could someone have a look at what I have changed and if it is OK. Thank you. На нд, 21.04.2019 г. в 12:27 ч. Robert Scholte написа: Hi Petar, IIRC the idea behind the original setup was to keep the original builder immutable and to keep a clear separation between what was configured by descriptor and what by commandline. And IIRC there's a set of properties that should NEVER be overridden via commandline. Also, if this is that critical for you, remember to add a test. You've seen that the codebased has changed a lot, verifying changes with tests is the only way to ensure the refactoring was done properly. thanks, Robert On 21-4-2019 08:38:37, Petar Tahchiev wrote: Hey guys, a while ago I raised this issue https://issues.apache.org/jira/browse/MRELEASE-985 and also I made a pull-request: https://github.com/apache/maven-release/pull/18 but it was closed, because I believe after a few years the code was very much out of sync with the master. However, I checked the master and seems like there is a way to override the SNAPSHOT dependencies from the command with a command like this: mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-SNAPSHOT:prepare -DdryRun=true -Ddependency.com.nemesis:bom.release=2.0.1.RELEASE -Ddependency.com.nemesis:bom.development=2.1.3-BUILD-SNAPSHOT -e -B However, when I tried it I got the same error: Caused by: org.apache.maven.shared.release.ReleaseFailureException: Can't release project due to non released dependencies : com.nemesis:bom:pom:2.1.0.BUILD-SNAPSHOT in project 'Nemesis Platform' (com.nemesis:platform:pom:2.1.0.BUILD-SNAPSHOT) Then I started digging and saw that in the DefaultReleaseManager the command-line properties are copied to a new ReleaseBuilder using ReleaseUtils.copyPropertiesToReleaseDescriptor and then this new release builder is ignored. Furthermore the CheckDependenciesSnapshotsPhase was not interested if the dependency was resolved from the command-line and was simply checking if it is a SNAPSHOT dependency. With those two small changes my build works fine. Can someone of you have a look at my PR: https://github.com/apache/maven-release/pull/28 and confirm that the change in DefaultReleaseManager doesn't break anything. All the tests pass. If you confirm that it is OK I can add a test Thank you. -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Help Plugin 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Help Plugin, version 3.2.0 The Maven Help Plugin is used to get relative information about a project or the system. It can be used to get a description of a particular plugin, including the plugin's goals with their parameters and component requirements, the effective POM and effective settings of the current build, and the profiles applied to the current project being built. https://maven.apache.org/plugins/maven-help-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-help-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-help-plugin/download.cgi Release Notes - Maven Help Plugin - Version 3.2.0 ** New Feature * [MPH-160] - help:effective-pom -Dverbose: add source location as comments in effective pom.xml ** Improvement * [MPH-161] - add color to goal or plugin description Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven PMD Plugin 3.12.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven PMD Plugin, version 3.12.0 A Maven plugin for the PMD toolkit, that produces a report on both code rule violations and detected copy and paste fragments, as well as being able to fail the build based on these metrics. https://maven.apache.org/plugins/maven-pmd-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-pmd-plugin 3.12.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-pmd-plugin/download.cgi Release Notes - Maven PMD Plugin - Version 3.12.0 ** Bug * [MPMD-277] - Plugin tries to download local submodules from repo ** New Feature * [MPMD-280] - Support targetJdk 12 * [MPMD-281] - Display found violations grouped by priority ** Improvement * [MPMD-279] - Improve documentation of maxAllowedViolations * [MPMD-282] - Add rule name to HTML report ** Dependency upgrade * [MPMD-275] - Upgrade to PMD 6.13.0 * [MPMD-284] - Upgrade parent to 33 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Accessing a maven repository programatically (in 2019)
This repo: https://github.com/airlift/resolver should have all you need. The Presto engine uses it to discover and load plugins if necessary from the local or remote repo. It uses the sonatype version of Aether, not the current Apache Maven Artifact Resolver but my guess is that this is straightforward to refactor. -h On Sat, Apr 20, 2019 at 10:16 PM Michael Lipp wrote: > On 2019/04/08 11:21:19, Paul Hammant wrote: > > There's shades of https://en.wikipedia.org/wiki/XY_problem to what you> > > posting. I, for one, an interested in what your trying to make after > you've> > > solved this problem :)> > > It's not trivial. There is a tool called "bnd" that supports the > development and deployment of OSGi bundles. The tool works "natively" > with OSGi Repositories > ( > https://osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/repository/Repository.html > ). > There are various bnd plugins that provide "OSGi repository views" on a > selection of artifacts from one or more maven repositories. In order to > do this, bnd provides its own library for accessing maven repositories, > including classes for parsing and evaluating POMs. > > When I started to write my own bnd plugin > ( > https://github.com/mnlipp/de.mnl.osgi/tree/master/de.mnl.osgi.bnd.repository > ) > I found that bnd's POM evaluation lacks some features. My first idea was > to replace all of bnd's maven library with the "standard" maven library. > This led to my initial question in this list. Sorry to say, but none of > the answers really helped. I dug further through the maven API and the > sources. Much too late I found > > https://lairdnelson.wordpress.com/2017/03/06/maven-and-the-project-formerly-known-as-aether/ > , > I wish I had found it earlier, would have saved me a lot of "digging". > It is obviously impossible to use the "standard" maven library (or > better "components") without a ridiculous number of (partially > redundant) CDI libraries. (That gave me quite a different perspective on > bnd's sleek implementation.) > > Having understood this, I thought about fixing the problems I had > identified with bnd's POM handling. But somehow, it seemed ridiculous to > maintain this non-trivial functionality twice. So what I have ended up > with is this: > > https://github.com/mnlipp/de.mnl.osgi/blob/2e9246a3a1fe416c50ec3667676a95b92babe232/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/CompositeMavenRepository.java#L134 > . I use the "components" from the maven library and assemble them myself > to avoid pulling in all those CDI libraries. Assembling the components, > I found that eventually the only "repository functionality" required to > evaluate a POM into a "Model" (using the standard maven components) is > an implementation of "ModelResolver". I therefore provide such an > implementation based on bnd's repository (access) classes > ( > https://github.com/mnlipp/de.mnl.osgi/blob/bnd.repository-2.0.0/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/BndModelResolver.java > ). > Maybe I'll some day try to assemble a "standard" repository access from > the (former) aether components. But actually, this part of bnd's maven > library seems to work flawlessly, so my motivation is quite low. (And I > still don't understand the aether API. It seems to duplicate a lot of > the functionality provided by the org.apache.maven.* classes.) > > Is this an X/Y problem? Maybe. The question was "How can I use the maven > libraries for (easily) accessing a maven repository?". Maybe I should > have asked first "Is the collection of maven APIs in the various > libraries intended to support easy access to the content of a maven > repository?" > > - Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[RESULT] [VOTE] Release Apache Maven PMD Plugin version 3.12.0
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Robert Scholte, Hervé BOUTEMY +1 (non-binding): Andreas Dangel PMC quorum: reached I will promote the artifacts to the central repo. Regards, Andreas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
