Re: [MJLINK] Move from 3.0.1 to 3.1.0
Le mardi 15 décembre 2020, 22:53:47 CET Andres Almiray a écrit : > Hello, > > Not that I want to hijack this thread but considering that the move is from > a fix release to a minor release I wonder about the use of > jlink. > > For a multi-module project having this packaging option is not much of a > problem, as if the project produces more than one artifact (such as a > shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra > module can perform the jlink packaging. > > However for single project builds the jlink would > prevent other packaging options, wouldn't it? sure, there is only one packaging in a pom.xml > Say I want to have single JAR, shaded JAR, and jlink image on the same > single project build. Is it possible to do so? yes, it's by definition of POM's packaging always possible to do (for this packaging or any other): it's just not automatic but has to be configured as explicit plugins calls Here is for example the reference of default packaging and their associated automatic plugin goals bindings: https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html Defining a packaging is just a way to ease such goals bindings: but nothing prevents you to always use pom packaging (which binds only install:install and deploy:deploy) and define by hand every plugin goals bindings you want that would correspond to war for example (which would mean defining 6 additional plugingoals bindings to be defined in your pom.xml) > > If it is, then I missed it in the docs. given it's not specific to this plugin and its provided packaging, I suppose it is implicit: don't hesitate to provide a PR to make this more explicit if you think this is useful given the nature of this plugin > It it's not allowed then I'd suggest if JAR packaging is also enabled when > jlink is defined, so keep them both active. Then > remove jlink in 4.0.0. perhaps a page describing the jlink packaging the same way default packagings are described in Maven core could help to understand the mechanism behind it > > As reference the Helidon maven plugin supports creating jlink and Graal > native images while keeping jar > > https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plug > in > > All this being said, this comment is to weight in a possible change that > would merit a minor release instead of a fix release. > > Cheers, > Andres > > --- > Java Champion; Groovy Enthusiast > 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 Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell > > wrote: > > Hello everyone, > > > > looking at the issues already solved and soon-be-solved, the next release > > feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. > > > > If you agree, I would like to update the git repository to 3.1.0 and > > create > > a 3.0.x branch from the last release, if needed. > > > > I would also like to request some help with the documentation [2]. > > Currently it says that an extra 'dist' project is needed, but with the > > introduction of classifiers (or moving the main jar away using a > > classifier), this does not hold true anymore. > > > > Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even > > "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even > > documented anymore – only 'jlink --plugin-list' shows its usage. > > > > Summary: > > 4 issues left, of which are: > > 1 with PR to be merged (update plexus-utils) > > 1 with PR half-way done (--add-options for launcher script) > > 1 documentation to be done > > 1 to be moved away or "wont’t fix". > > > > Thanks in advance, > > Ben > > > > [1] > > > > https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK > > %20AND%20fixVersion%20%3D%203.0.1 [2] > > https://issues.apache.org/jira/browse/MJLINK-49 > > [3] https://issues.apache.org/jira/browse/MJLINK-39 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Merci! Yes, I cannot change releases, so highly appreciated! I might ping you again about the release, as I created a ECDSA OpenPGP key, which nexus does not yet recognize. Thanks! Ben On 16.12.20 08:06, Hervé BOUTEMY wrote: given the number of new features, yes, switching to 3.1.0 makes sense I just renamed the next release to 3.1.0 in Jira (I fear you don't have permissions) No need to create 3.0.x Git branch for now, unless you really have a specific reason to do so: we generally don't try to maintain multiple versions in parallel Don't hesitate to ping if there are tasks you don't have permissions Regards, Hervé Le mardi 15 décembre 2020, 22:37:21 CET Benjamin Marwell a écrit : Hello everyone, looking at the issues already solved and soon-be-solved, the next release feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. If you agree, I would like to update the git repository to 3.1.0 and create a 3.0.x branch from the last release, if needed. I would also like to request some help with the documentation [2]. Currently it says that an extra 'dist' project is needed, but with the introduction of classifiers (or moving the main jar away using a classifier), this does not hold true anymore. Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even documented anymore – only 'jlink --plugin-list' shows its usage. Summary: 4 issues left, of which are: 1 with PR to be merged (update plexus-utils) 1 with PR half-way done (--add-options for launcher script) 1 documentation to be done 1 to be moved away or "wont’t fix". Thanks in advance, Ben [1] https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%2 0AND%20fixVersion%20%3D%203.0.1 [2] https://issues.apache.org/jira/browse/MJLINK-49 [3] https://issues.apache.org/jira/browse/MJLINK-39 - 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: [MJLINK] Move from 3.0.1 to 3.1.0
Not that I want to hijack this thread No worries! It is always good to have an extra pair of eyes look at the work of a new committer. ;-) However for single project builds the jlink would prevent other packaging options, wouldn't it? I created ITs, but this set-up is not an the list: https://github.com/apache/maven-jlink-plugin/tree/master/src/it/projects (Especially MJLINK-52_*). I would not know why this would prevent other packaging options. I will create another IT which will be packaging=jlink and add a jar execution. Note that you will need to define the execution manually. Say I want to have single JAR, shaded JAR, and jlink image on the same single project build. Is it possible to do so? This is why MJLINK-52 adds classifiers. The check of existing artifacts was broken before then. Most ITs from the link above already show a single jar project with an extra jlink execution. Add as many shaded jars as you like… Does that help? Thanks, Ben On 15.12.20 22:53, Andres Almiray wrote: Hello, Not that I want to hijack this thread but considering that the move is from a fix release to a minor release I wonder about the use of jlink. For a multi-module project having this packaging option is not much of a problem, as if the project produces more than one artifact (such as a shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra module can perform the jlink packaging. However for single project builds the jlink would prevent other packaging options, wouldn't it? Say I want to have single JAR, shaded JAR, and jlink image on the same single project build. Is it possible to do so? If it is, then I missed it in the docs. It it's not allowed then I'd suggest if JAR packaging is also enabled when jlink is defined, so keep them both active. Then remove jlink in 4.0.0. As reference the Helidon maven plugin supports creating jlink and Graal native images while keeping jar https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin All this being said, this comment is to weight in a possible change that would merit a minor release instead of a fix release. Cheers, Andres --- Java Champion; Groovy Enthusiast 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 Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell wrote: Hello everyone, looking at the issues already solved and soon-be-solved, the next release feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. If you agree, I would like to update the git repository to 3.1.0 and create a 3.0.x branch from the last release, if needed. I would also like to request some help with the documentation [2]. Currently it says that an extra 'dist' project is needed, but with the introduction of classifiers (or moving the main jar away using a classifier), this does not hold true anymore. Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even documented anymore – only 'jlink --plugin-list' shows its usage. Summary: 4 issues left, of which are: 1 with PR to be merged (update plexus-utils) 1 with PR half-way done (--add-options for launcher script) 1 documentation to be done 1 to be moved away or "wont’t fix". Thanks in advance, Ben [1] https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1 [2] https://issues.apache.org/jira/browse/MJLINK-49 [3] https://issues.apache.org/jira/browse/MJLINK-39 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
given the number of new features, yes, switching to 3.1.0 makes sense I just renamed the next release to 3.1.0 in Jira (I fear you don't have permissions) No need to create 3.0.x Git branch for now, unless you really have a specific reason to do so: we generally don't try to maintain multiple versions in parallel Don't hesitate to ping if there are tasks you don't have permissions Regards, Hervé Le mardi 15 décembre 2020, 22:37:21 CET Benjamin Marwell a écrit : > Hello everyone, > > looking at the issues already solved and soon-be-solved, the next release > feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. > > If you agree, I would like to update the git repository to 3.1.0 and create > a 3.0.x branch from the last release, if needed. > > I would also like to request some help with the documentation [2]. > Currently it says that an extra 'dist' project is needed, but with the > introduction of classifiers (or moving the main jar away using a > classifier), this does not hold true anymore. > > Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even > "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even > documented anymore – only 'jlink --plugin-list' shows its usage. > > Summary: > 4 issues left, of which are: > 1 with PR to be merged (update plexus-utils) > 1 with PR half-way done (--add-options for launcher script) > 1 documentation to be done > 1 to be moved away or "wont’t fix". > > Thanks in advance, > Ben > > [1] > https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%2 > 0AND%20fixVersion%20%3D%203.0.1 [2] > https://issues.apache.org/jira/browse/MJLINK-49 > [3] https://issues.apache.org/jira/browse/MJLINK-39 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Fwd: [maven-compiler-plugin] Issue with compiling test source using modules using a multi-version maven project.
Oops sent this to the wrong emailSent from my iPhoneBegin forwarded message:From: Claudio Corsi Date: December 15, 2020 at 20:38:30 ESTTo: dev-h...@maven.apache.orgSubject: [maven-compiler-plugin] Issue with compiling test source using modules using a multi-version maven project.Hi All,I am using maven to develop a java agent that uses a multi-version jar file. This is being developed within a single project module instead of using multiple modules. The issue is that my initial jar file will default compilation target is jdk 7 and it includes classes for jdk 9. The issue is that I am creating a test that is using modules and when I try to build the module specific test code. I get the UnsupportedOperationException that includes the message:Can't compile test sources when main sources are missing a module descriptorThis is generated within the TestCompilerMojo#preparePaths method. I tried to get around this issue by adding compiler specific attributes in the pom file but alas I was not able to get around this issue. I then forked the maven-compiler-plugin code and updated the code. I was able to get around this issue by adding the following code to the mentioned method. // It is possible that we are building a multi-version jar file in which the main classes are not module based. if ( ! mainModuleDescriptorClassFile.exists() && release != null ) { // @todo does it really matter that we check the version? int version = Integer.valueOf( release ); if ( version >= 9 ) { String releaseOutputDirectory = String.format( "%s%sMETA-INF%sversions%s%d", getProject().getBuild().getOutputDirectory(), File.separator, File.separator, File.separator, version ); // @todo how to add the releaseOutputDirectory automatically? // testPath.add( releaseOutputDirectory ); mainModuleDescriptorClassFile = new File ( releaseOutputDirectory, "module-info.class" ); if ( getLog().isDebugEnabled() ) { getLog().debug( "Updated main module " + mainModuleDescriptorClassFile ); } } }This was add after the initial for loop for the master branch (3.9.0-SNAPSHOT). I was able to get around the initial exception but alas I was still having issues building the test source. I then was able to get around the issue by adding the following compilerArgs to my pom file: --module-path ${project.basedir}/target/classes/META-INF/versions/9 This allowed me to build the test source for that specific test module.I then was wondering if there is a better solution to this issue and I noticed that if I added the releaseOutputDirectory to the testPath collection then the above compilerArgs would not be required to be able to build the test sources. My question then is, "Is their a better way then adding the directory to the testPath?". I worry that the above solution will not work in all cases and can be a maintenance nightmare. It seems that being forced to include the compileArgs to the test source build is a better overall solution. Any opinions or comments on the above proposal?I've attach the test pom and patched TestCompilerMojo files.Thanks,--Claudio
TestCompilerMojo.java
Description: Binary data
pom.xml
Description: XML document
Re: [MJLINK] Move from 3.0.1 to 3.1.0
+1 for 3.1.0 release wt., 15 gru 2020 o 22:38 Benjamin Marwell napisał(a): > > Hello everyone, > > looking at the issues already solved and soon-be-solved, the next release > feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. > > If you agree, I would like to update the git repository to 3.1.0 and create > a 3.0.x branch from the last release, if needed. > > I would also like to request some help with the documentation [2]. > Currently it says that an extra 'dist' project is needed, but with the > introduction of classifiers (or moving the main jar away using a > classifier), this does not hold true anymore. > > Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even > "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even > documented anymore – only 'jlink --plugin-list' shows its usage. > > Summary: > 4 issues left, of which are: > 1 with PR to be merged (update plexus-utils) > 1 with PR half-way done (--add-options for launcher script) > 1 documentation to be done > 1 to be moved away or "wont’t fix". > > Thanks in advance, > Ben > > [1] > https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1 > [2] https://issues.apache.org/jira/browse/MJLINK-49 > [3] https://issues.apache.org/jira/browse/MJLINK-39 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Hello, Not that I want to hijack this thread but considering that the move is from a fix release to a minor release I wonder about the use of jlink. For a multi-module project having this packaging option is not much of a problem, as if the project produces more than one artifact (such as a shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra module can perform the jlink packaging. However for single project builds the jlink would prevent other packaging options, wouldn't it? Say I want to have single JAR, shaded JAR, and jlink image on the same single project build. Is it possible to do so? If it is, then I missed it in the docs. It it's not allowed then I'd suggest if JAR packaging is also enabled when jlink is defined, so keep them both active. Then remove jlink in 4.0.0. As reference the Helidon maven plugin supports creating jlink and Graal native images while keeping jar https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin All this being said, this comment is to weight in a possible change that would merit a minor release instead of a fix release. Cheers, Andres --- Java Champion; Groovy Enthusiast 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 Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell wrote: > Hello everyone, > > looking at the issues already solved and soon-be-solved, the next release > feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. > > If you agree, I would like to update the git repository to 3.1.0 and create > a 3.0.x branch from the last release, if needed. > > I would also like to request some help with the documentation [2]. > Currently it says that an extra 'dist' project is needed, but with the > introduction of classifiers (or moving the main jar away using a > classifier), this does not hold true anymore. > > Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even > "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even > documented anymore – only 'jlink --plugin-list' shows its usage. > > Summary: > 4 issues left, of which are: > 1 with PR to be merged (update plexus-utils) > 1 with PR half-way done (--add-options for launcher script) > 1 documentation to be done > 1 to be moved away or "wont’t fix". > > Thanks in advance, > Ben > > [1] > > https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1 > [2] https://issues.apache.org/jira/browse/MJLINK-49 > [3] https://issues.apache.org/jira/browse/MJLINK-39 >
[MJLINK] Move from 3.0.1 to 3.1.0
Hello everyone, looking at the issues already solved and soon-be-solved, the next release feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1]. If you agree, I would like to update the git repository to 3.1.0 and create a 3.0.x branch from the last release, if needed. I would also like to request some help with the documentation [2]. Currently it says that an extra 'dist' project is needed, but with the introduction of classifiers (or moving the main jar away using a classifier), this does not hold true anymore. Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even documented anymore – only 'jlink --plugin-list' shows its usage. Summary: 4 issues left, of which are: 1 with PR to be merged (update plexus-utils) 1 with PR half-way done (--add-options for launcher script) 1 documentation to be done 1 to be moved away or "wont’t fix". Thanks in advance, Ben [1] https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1 [2] https://issues.apache.org/jira/browse/MJLINK-49 [3] https://issues.apache.org/jira/browse/MJLINK-39
[GitHub] [maven-site] michael-o commented on pull request #219: Add 'What's New in Maven 4' blog
michael-o commented on pull request #219: URL: https://github.com/apache/maven-site/pull/219#issuecomment-745272863 If you go through articles and resources you'll notice that some of them are dead. I'd prefer when the first alpha goes online that your content would be part of the Maven site and not external. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] mthmulders opened a new pull request #219: Add 'What's New in Maven 4' blog
mthmulders opened a new pull request #219: URL: https://github.com/apache/maven-site/pull/219 Add a reference to the blog post 'What's New in Maven 4' by @MartinKanters and myself. The reason I'm creating a merge request is two-fold: 1. I'm not sure if this place on the site is the right place for this kind of content. 1. I'm also the co-author of the blog post so I'd appreciate if somebody else could confirm it's a useful resource to list on the Maven website. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
