Re: MRELEASE-985(again)
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 > -- 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
Avoiding to shade aether classes in shared/artifact-transfer
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 Archetype Plugin version 3.1.0
+1 Sylwester niedz., 21 kwi 2019 o 09:08 Petar Tahchiev napisał(a): > I tested with our project. Seems good. +1 from me > > На сб, 20.04.2019 г. в 21:01 ч. Robert Scholte > написа: > > > Hi, > > > > We solved 13 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122&version=12340346&styleName=Text > > > > There are still a couple of issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317122%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1499/ [ > > https://repository.apache.org/content/repositories/maven-1499/] > > > > > https://repository.apache.org/content/repositories/maven-1499/org/apache/maven/archetype/maven-archetype/3.1.0/maven-archetype-3.1.0-source-release.zip > > > > Source release checksum(s): > > > > maven-archetype-3.1.0-source-release.zip sha512: > 6dc9b9ac60d945bca4818cb259d07fe5b6bb71ea4befd16490093cccd445def3de02aa3f03d88a2b9c80ceea3f114485f119afed8101adbf27895ca659a199a1 > > > > Staging site: > > https://maven.apache.org/archetype-archives\archetype-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 > > > > -- > 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 >
Re: Bumping Checkstyle plugin version to 3.1.0-SNAPSHOT (from 3.0.1-SNAPSHOT)
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: Snapshots of core Maven plugins
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... 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: [maven-scm-publish-plugin] branch master updated: exclude Windows from ITs: require svn and svnadmin executables
I must confess disabling the IT on Windows is just lazyness to avoid a stupid failure on CI don't hesitate to revert if you really prefer to find and fix the root cause: I don't have any problem with job well done by others ;) Regards, Hervé Le dimanche 21 avril 2019, 12:45:12 CEST Robert Scholte a écrit : > The issue on Jenkins has to do with the @ in the path of the workspace. SCM > parses this as a username/password separator. Based on the SCM > Implementation for subversion[1] that's a bug: scm:svn:file:// doesn't > support username+password > > Robert > > [1] https://maven.apache.org/scm/subversion.html > [https://maven.apache.org/scm/subversion.html] > > On 14-4-2019 16:12:13, Robert Scholte wrote: > Hi Hervé, > > IIRC most of these tests run fine on my Windows machine. Only the one with > symbolic links has issues, probably because just me running in > administrator mode to be able to create symlinks. If svn is missing on the > Windows nodes at builds.a.o, we should ask INFRA to add it, like I did for > gpg support[1]. > > best, > Robert > > [1] https://issues.apache.org/jira/browse/INFRA-18014 > [https://issues.apache.org/jira/browse/INFRA-18014] > > On 14-4-2019 11:07:53, hbout...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > hboutemy pushed a commit to branch master > in repository > https://gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git > > > The following commit(s) were added to refs/heads/master by this push: > new 471c7de exclude Windows from ITs: require svn and svnadmin executables > 471c7de is described below > > commit 471c7de83b67b50e0fb6f92448eb8f76ccd7f44c > Author: Hervé Boutemy > AuthorDate: Sun Apr 14 11:07:43 2019 +0200 > > exclude Windows from ITs: require svn and svnadmin executables > --- > src/it/publish-scm-staged/invoker.properties | 3 +++ > src/it/publish-scm/invoker.properties | 3 +++ > src/it/site-deploy/invoker.properties | 3 +++ > 3 files changed, 9 insertions(+) > > diff --git a/src/it/publish-scm-staged/invoker.properties > b/src/it/publish-scm-staged/invoker.properties index d5572ef..6af860f > 100644 > --- a/src/it/publish-scm-staged/invoker.properties > +++ b/src/it/publish-scm-staged/invoker.properties > @@ -16,3 +16,6 @@ > # under the License. > > invoker.goals = site site:stage scm-publish:publish-scm > + > +# Windows doesn't have svn and svnadmin executables > +invoker.os.family = !windows > diff --git a/src/it/publish-scm/invoker.properties > b/src/it/publish-scm/invoker.properties index bf59692..eaa8afa 100644 > --- a/src/it/publish-scm/invoker.properties > +++ b/src/it/publish-scm/invoker.properties > @@ -16,3 +16,6 @@ > # under the License. > > invoker.goals = site scm-publish:publish-scm > + > +# Windows doesn't have svn and svnadmin executables > +invoker.os.family = !windows > diff --git a/src/it/site-deploy/invoker.properties > b/src/it/site-deploy/invoker.properties index 270bcc7..e9b4e5f 100644 > --- a/src/it/site-deploy/invoker.properties > +++ b/src/it/site-deploy/invoker.properties > @@ -16,3 +16,6 @@ > # under the License. > > invoker.goals = site-deploy > + > +# Windows doesn't have svn and svnadmin executables > +invoker.os.family = !windows - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Bumping Checkstyle plugin version to 3.1.0-SNAPSHOT (from 3.0.1-SNAPSHOT)
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. 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
Re: [VOTE] Release Apache Maven PMD Plugin version 3.12.0
+1 I was able to check the binary with a build I did with Open JDK 7 latest from my Linux box (while it had been built with old Oracle JDK 7u80 on Windows). I opened and fixed MPMD-285 since there was a non-reproducible bit where we have a solution. Regards, Hervé Le jeudi 11 avril 2019, 20:35:38 CEST Andreas Dangel a écrit : > Hi, > > We solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344380&styl > eName=Text&projectId=12317621 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20stat > us%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > Staging repo: > https://repository.apache.org/content/repositories/maven-1497/ > https://repository.apache.org/content/repositories/maven-1497/org/apache/mav > en/plugins/maven-pmd-plugin/3.12.0/maven-pmd-plugin-3.12.0-source-release.zi > p > Source release checksum(s): > maven-pmd-plugin-3.12.0-source-release.zip sha512: > 97d4570792151a17d04ccc8f7414a5218a42a97ac0a547b252b00e280ac792d9af703fd33c37 > f757df308e78345a7277f05d27a94f2536f34f99bcc44925aaf5 > Staging site: > https://maven.apache.org/plugins-archives/maven-pmd-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 > > > Regards, > Andreas > > > > - > 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: [maven-scm-publish-plugin] branch master updated: exclude Windows from ITs: require svn and svnadmin executables
The issue on Jenkins has to do with the @ in the path of the workspace. SCM parses this as a username/password separator. Based on the SCM Implementation for subversion[1] that's a bug: scm:svn:file:// doesn't support username+password Robert [1] https://maven.apache.org/scm/subversion.html [https://maven.apache.org/scm/subversion.html] On 14-4-2019 16:12:13, Robert Scholte wrote: Hi Hervé, IIRC most of these tests run fine on my Windows machine. Only the one with symbolic links has issues, probably because just me running in administrator mode to be able to create symlinks. If svn is missing on the Windows nodes at builds.a.o, we should ask INFRA to add it, like I did for gpg support[1]. best, Robert [1] https://issues.apache.org/jira/browse/INFRA-18014 [https://issues.apache.org/jira/browse/INFRA-18014] On 14-4-2019 11:07:53, hbout...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. hboutemy pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git The following commit(s) were added to refs/heads/master by this push: new 471c7de exclude Windows from ITs: require svn and svnadmin executables 471c7de is described below commit 471c7de83b67b50e0fb6f92448eb8f76ccd7f44c Author: Hervé Boutemy AuthorDate: Sun Apr 14 11:07:43 2019 +0200 exclude Windows from ITs: require svn and svnadmin executables --- src/it/publish-scm-staged/invoker.properties | 3 +++ src/it/publish-scm/invoker.properties | 3 +++ src/it/site-deploy/invoker.properties | 3 +++ 3 files changed, 9 insertions(+) diff --git a/src/it/publish-scm-staged/invoker.properties b/src/it/publish-scm-staged/invoker.properties index d5572ef..6af860f 100644 --- a/src/it/publish-scm-staged/invoker.properties +++ b/src/it/publish-scm-staged/invoker.properties @@ -16,3 +16,6 @@ # under the License. invoker.goals = site site:stage scm-publish:publish-scm + +# Windows doesn't have svn and svnadmin executables +invoker.os.family = !windows diff --git a/src/it/publish-scm/invoker.properties b/src/it/publish-scm/invoker.properties index bf59692..eaa8afa 100644 --- a/src/it/publish-scm/invoker.properties +++ b/src/it/publish-scm/invoker.properties @@ -16,3 +16,6 @@ # under the License. invoker.goals = site scm-publish:publish-scm + +# Windows doesn't have svn and svnadmin executables +invoker.os.family = !windows diff --git a/src/it/site-deploy/invoker.properties b/src/it/site-deploy/invoker.properties index 270bcc7..e9b4e5f 100644 --- a/src/it/site-deploy/invoker.properties +++ b/src/it/site-deploy/invoker.properties @@ -16,3 +16,6 @@ # under the License. invoker.goals = site-deploy + +# Windows doesn't have svn and svnadmin executables +invoker.os.family = !windows
Re: MRELEASE-985(again)
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
Re: MRELEASE-985(again)
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
Re: Accessing a maven repository programatically (in 2019)
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
Re: [VOTE] Release Apache Maven Archetype Plugin version 3.1.0
I tested with our project. Seems good. +1 from me На сб, 20.04.2019 г. в 21:01 ч. Robert Scholte написа: > Hi, > > We solved 13 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122&version=12340346&styleName=Text > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317122%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1499/ [ > https://repository.apache.org/content/repositories/maven-1499/] > > https://repository.apache.org/content/repositories/maven-1499/org/apache/maven/archetype/maven-archetype/3.1.0/maven-archetype-3.1.0-source-release.zip > > Source release checksum(s): > > maven-archetype-3.1.0-source-release.zip sha512: > 6dc9b9ac60d945bca4818cb259d07fe5b6bb71ea4befd16490093cccd445def3de02aa3f03d88a2b9c80ceea3f114485f119afed8101adbf27895ca659a199a1 > > Staging site: > https://maven.apache.org/archetype-archives\archetype-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 -- 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
