Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168565897
POM property, CLI property override, or we might want to start collecting
these provisional changes in a special maven plugin configuration section for
activating proposed
Good you agreed we don't need to add modulepath to MavenProject :-)
I see few ways forward with java 9 module system support in maven
* Convince jep authors to provide a mechanism to specify modulepath in a
way that does not require specific file/directory naming convention. I
only had very curso
The Apache Maven team is pleased to announce the release of the Apache
Maven JAR Utilities, version 1.2.
This module generates browsable HTML pages from Java source code.
https://maven.apache.org/shared/maven-shared-jar/
You should specify the version in your project's dependency configuration
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168543843
Perhaps a POM property with predefined name could activate this behaviour
in 3.x? In this way it can be set on a per-project basis as well as global
(with properties inject
Do you want to use modulepath for dependencies
-modulepath ../child2/target/classes, ../child3/target/classes
instead of aggregating -classpath in javac?
On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte wrote:
> Hi,
>
> I've been able to locally *package* a subset of the MavenModules enriched
> w
Ok, let me write out the complete story:
maven-settings-builder has the following module-info.java
module maven.settings.builder
{
exports org.apache.maven.settings.building;
exports org.apache.maven.settings.crypto;
exports org.apache.maven.settings.io;
exports org.apache.maven.settings
Hi,
The vote has passed with the following result:
+1: Michael Osipov, Karl Heinz Marbaise, Benson Margulies, Hervé Boutemy
PMC quorum: reached
I will promote the artifacts to the central repo, the source release ZIP
file and add this release the board report.
-
Not sure I understand. Are you talking about compiling, and more
specifically, invoking maven-compiler-plugin, on maven-settings-builder
and maven-settings projects or something else? If you are talking about
invoking maven-compiler-plugin on several interdependent projects, can
you explain how add
The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.19.1
The release contains 17 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!
http://maven.apache.org/plugins/
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168534190
General rule of thumb is that a change in resolution will definitely not go
in if it changes the default behaviour within a minor version. First smoke test
is making sure
I would really prefer a solution without changing Maven Project,
especially since we're talking about non-generic or language-specific
elements.
However, in my example where maven-settings-builder depends on
maven-settings, how would m-s-b know what the modulePath for m-s is? You
shouldn't
GitHub user nhojpatrick opened a pull request:
https://github.com/apache/maven-plugins/pull/76
Java 9 fixes
maven-jar-plugin and maven-javadoc-plugin require
org.codehaus.plexus:plexus-archiver:3.0.3-SNAPSHOT
plexus-archiver has had a critical change due to Java 9 changes t
Hi folks, especially Hervé,
we're discussing several important changes in how stuff is going to be
processed in Doxia. Some of them will introduce cleanups and necessary
compat breaks. Wouldn't it be wise to bump to a new major 2.0 which is
going to be the last supported for Maven 2.x? 3.0 wou
I agree that getCompileClasspathElements/getTestClasspathElements are
flawed, but I don't think adding
getCompileModulepathElements/getTestModulepathElements is a good idea.
MavenProject is supposed to be generic, and modulepath is something
very specific to java 9. At the same time, compile mojo
getCompileModulepathElements() and getTestModulepathElements()
Based on a modulePath you can (re)calculate the classPath, but not the
other way around.
Actually, I think there's a small design flaw when a MavenProject contains
getCompileClasspathElements() and getTestClasspathElements(). Th
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168519406
I've introduced DependencyManagementGraph object to store and compute
"distance" for dependencyManagement section - so there is no change to the
model itself. Signature of
Hi,
The vote has passed with the following result:
+1 (binding): Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY
The vote has passed with the following result:
+1 : Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY
0 : none
-1 : none.
PMC quorum: accomplished.
I will promote the artifacts t
What changes to MavenProject do you have in mind?
--
Regards,
Igor
On Sun, Jan 3, 2016, at 11:55 AM, Robert Scholte wrote:
> Hi,
>
> I've been able to locally *package* a subset of the MavenModules enriched
> with module-info.
>
> mvn package -pl :maven-settings-builder -am -Denforcer.s
The vote has passed with the following result:
+1 : Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY
0 : none
-1 : none.
PMC quorum: accomplished.
On Thu, Dec 31, 2015 at 3:14 PM, Tibor Digana
wrote:
> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
Hi,
I've been able to locally *package* a subset of the MavenModules enriched
with module-info.
mvn package -pl :maven-settings-builder -am -Denforcer.skip
resulting in:
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS
[57.217s]
[INFO
Am 2016-01-03 um 12:37 schrieb Hervé BOUTEMY:
the site uses old skin, because parent pom was not upgraded to 22: is this
intentional?
Yes, this is intentional. Parent 22 requires Java 1.6. I did not want to
introduce that and wanted to avoid the properties again. Version 2.0
will jump on it a
GitHub user CodingFabian opened a pull request:
https://github.com/apache/maven-wagon/pull/20
[WAGON-448] remove unnecessary dependency to commons-lang
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/CodingFabian/maven-wagon WAGO
+1
Regards,
Hervé
Le jeudi 31 décembre 2015 15:14:44 Tibor Digana a écrit :
> Hi,
>
> We solved 17 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&ve
> rsion=12333959
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/i#iss
the site uses old skin, because parent pom was not upgraded to 22: is this
intentional?
that does not cause any strong issue, just curiosity :)
so here is my +1
Regards,
Hervé
Le jeudi 31 décembre 2015 21:30:30 Michael Osipov a écrit :
> Hi,
>
> We solved 5 issues:
> https://issues.apache.or
Hi,
Tested without any issue.
so +1 from me...
Kind regards
Karl Heinz Marbaise
On 12/31/15 9:30 PM, Michael Osipov wrote:
Hi,
We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12334441
There are still a couple of issues left in JIRA:
htt
25 matches
Mail list logo