date:20180412

olamy closed pull request #69: [SCM-882] git checkout in binary mode when 
requested
URL: https://github.com/apache/maven-scm/pull/69
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.java
 
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.java
index 296e51b27..d2e8613c7 100644
--- 
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.java
+++ 
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.java
@@ -19,10 +19,15 @@
  * under the License.
  */
 
+import java.io.File;
+
+import org.apache.maven.scm.CommandParameter;
+import org.apache.maven.scm.CommandParameters;
 import org.apache.maven.scm.ScmBranch;
 import org.apache.maven.scm.ScmException;
 import org.apache.maven.scm.ScmFileSet;
 import org.apache.maven.scm.ScmFileStatus;
+import org.apache.maven.scm.ScmResult;
 import org.apache.maven.scm.ScmTag;
 import org.apache.maven.scm.ScmVersion;
 import org.apache.maven.scm.command.checkout.AbstractCheckOutCommand;
@@ -39,8 +44,6 @@
 import org.codehaus.plexus.util.cli.CommandLineUtils;
 import org.codehaus.plexus.util.cli.Commandline;
 
-import java.io.File;
-
 /**
  * @author mailto:strub...@yahoo.de;>Mark Struberg
  *
@@ -57,10 +60,15 @@
  * TODO We currently assume a '.git' directory, so this does not work for 
--bare repos
  * {@inheritDoc}
  */
-protected CheckOutScmResult executeCheckOutCommand( ScmProviderRepository 
repo, ScmFileSet fileSet,
-   ScmVersion version, 
boolean recursive, boolean shallow )
+@Override
+public ScmResult executeCommand( ScmProviderRepository repo, ScmFileSet 
fileSet,
+ CommandParameters parameters )
 throws ScmException
 {
+ScmVersion version = parameters.getScmVersion( 
CommandParameter.SCM_VERSION, null );
+boolean binary = parameters.getBoolean( CommandParameter.BINARY, false 
);
+boolean shallow = parameters.getBoolean( CommandParameter.SHALLOW, 
false );
+
 GitScmProviderRepository repository = (GitScmProviderRepository) repo;
 
 if ( GitScmProviderRepository.PROTOCOL_FILE.equals( 
repository.getFetchInfo().getProtocol() )
@@ -85,7 +93,7 @@ protected CheckOutScmResult executeCheckOutCommand( 
ScmProviderRepository repo,
 }
 
 // no git repo seems to exist, let's clone the original repo
-Commandline clClone = createCloneCommand( repository, 
fileSet.getBasedir(), version, shallow );
+Commandline clClone = createCloneCommand( repository, 
fileSet.getBasedir(), version, binary, shallow );
 
 exitCode = GitCommandLineUtils.execute( clClone, stdout, stderr, 
getLogger() );
 if ( exitCode != 0 )
@@ -163,10 +171,12 @@ public static Commandline createCommandLine( 
GitScmProviderRepository repository
  * create a git-clone repository command
  */
 private Commandline createCloneCommand( GitScmProviderRepository 
repository, File workingDirectory,
-ScmVersion version, boolean 
shallow )
+ScmVersion version, boolean 
binary, boolean shallow )
 {
 Commandline cl = GitCommandLineUtils.getBaseGitCommandLine( 
workingDirectory.getParentFile(), "clone" );
 
+forceBinary( cl, binary );
+
 if ( shallow )
 {
 cl.createArg().setValue( "--depth" );
@@ -189,6 +199,15 @@ private Commandline createCloneCommand( 
GitScmProviderRepository repository, Fil
 return cl;
 }
 
+private void forceBinary( Commandline cl, boolean binary )
+{
+if ( binary )
+{
+cl.createArg().setValue( "-c" );
+cl.createArg().setValue( "core.autocrlf=false" );
+}
+}
+
 /**
  * create a git-pull repository command
  */
@@ -228,4 +247,17 @@ private Commandline createPullCommand( 
GitScmProviderRepository repository, File
 }
 return cl;
 }
+
+/**
+ * The overriden {@link #executeCommand(ScmProviderRepository, ScmFileSet, 
CommandParameters)} in this class will
+ * not call this method!
+ * 
+ * {@inheritDoc}
+ */
+protected CheckOutScmResult executeCheckOutCommand( ScmProviderRepository

[jira] [Closed] (SCM-881) ScmWagon has no way to work with SVN in binary mode

2018-04-12 Thread *$^¨%`£


 [ 
https://issues.apache.org/jira/browse/SCM-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) closed SCM-881.
--
Resolution: Fixed

> ScmWagon has no way to work with SVN in binary mode
> ---
>
> Key: SCM-881
> URL: https://issues.apache.org/jira/browse/SCM-881
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> In some configurations svn will automatically add the svn:eol-style property 
> to newly added text files. ScmWagon needs to perform the add command without 
> adding automatic properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-881) ScmWagon has no way to work with SVN in binary mode

2018-04-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SCM-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436737#comment-16436737
 ] 

ASF GitHub Bot commented on SCM-881:


olamy closed pull request #68: [SCM-881] svn add in binary mode when requested
URL: https://github.com/apache/maven-scm/pull/68
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
 
b/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
index 9d5f1d0e1..eb8ced780 100644
--- 
a/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
+++ 
b/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
@@ -49,12 +49,6 @@ protected ScmResult executeAddCommand( ScmProviderRepository 
repository, ScmFile
boolean binary )
 throws ScmException
 {
-// TODO: could do this with propset?
-if ( binary )
-{
-throw new ScmException( "This provider does not yet support binary 
files" );
-}
-
 if ( fileSet.getFileList().isEmpty() )
 {
 throw new ScmException( "You must provide at least one 
file/directory to add" );
@@ -62,6 +56,12 @@ protected ScmResult executeAddCommand( ScmProviderRepository 
repository, ScmFile
 
 Commandline cl = createCommandLine( fileSet.getBasedir(), 
fileSet.getFileList() );
 
+if ( binary )
+{
+cl.createArg().setValue( "--config-option" );
+cl.createArg().setValue( "config:miscellany:enable-auto-props=no" 
);
+}
+
 SvnAddConsumer consumer = new SvnAddConsumer( getLogger() );
 
 CommandLineUtils.StringStreamConsumer stderr = new 
CommandLineUtils.StringStreamConsumer();


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> ScmWagon has no way to work with SVN in binary mode
> ---
>
> Key: SCM-881
> URL: https://issues.apache.org/jira/browse/SCM-881
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> In some configurations svn will automatically add the svn:eol-style property 
> to newly added text files. ScmWagon needs to perform the add command without 
> adding automatic properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] olamy closed pull request #68: [SCM-881] svn add in binary mode when requested

olamy closed pull request #68: [SCM-881] svn add in binary mode when requested
URL: https://github.com/apache/maven-scm/pull/68
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
 
b/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
index 9d5f1d0e1..eb8ced780 100644
--- 
a/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
+++ 
b/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/add/SvnAddCommand.java
@@ -49,12 +49,6 @@ protected ScmResult executeAddCommand( ScmProviderRepository 
repository, ScmFile
boolean binary )
 throws ScmException
 {
-// TODO: could do this with propset?
-if ( binary )
-{
-throw new ScmException( "This provider does not yet support binary 
files" );
-}
-
 if ( fileSet.getFileList().isEmpty() )
 {
 throw new ScmException( "You must provide at least one 
file/directory to add" );
@@ -62,6 +56,12 @@ protected ScmResult executeAddCommand( ScmProviderRepository 
repository, ScmFile
 
 Commandline cl = createCommandLine( fileSet.getBasedir(), 
fileSet.getFileList() );
 
+if ( binary )
+{
+cl.createArg().setValue( "--config-option" );
+cl.createArg().setValue( "config:miscellany:enable-auto-props=no" 
);
+}
+
 SvnAddConsumer consumer = new SvnAddConsumer( getLogger() );
 
 CommandLineUtils.StringStreamConsumer stderr = new 
CommandLineUtils.StringStreamConsumer();


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


With regards,
Apache Git Services

[jira] [Commented] (MNGSITE-333) Broken link in "Project maven is retired. See maven's attic page."

2018-04-12 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MNGSITE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436311#comment-16436311
 ] 

Hervé Boutemy commented on MNGSITE-333:
---

it looks that it was a transient issue caused by attic work:
see 
https://lists.apache.org/thread.html/a4fee8c2386f5c6550d960a734c36c56c788d9a32959c6c7a98f5cac@%3Cgeneral.attic.apache.org%3E
should not happen again...

> Broken link in "Project maven is retired. See maven's attic page."
> --
>
> Key: MNGSITE-333
> URL: https://issues.apache.org/jira/browse/MNGSITE-333
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Maria Jurcovicova
>Priority: Major
>
> The [https://maven.apache.org/] page currently shows red banner on top. The 
> banner says: "Project _maven_ is retired. See maven's [attic page 
> |https://attic.apache.org/projects/maven.html]." 
> If maven was really retired, then the link in "attic page" is broken. There 
> does not seem to be any mention of maven in apache attic. If the project is 
> not retired, the banner should not be there.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-336) Dependency that should be on modulepath sometime put on classpath


[ 
https://issues.apache.org/jira/browse/MCOMPILER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436114#comment-16436114
 ] 

Colbert Philippe commented on MCOMPILER-336:


No XML entry 'useIncrementalCompilation' in my POM, even when I view Effective 
POM using Eclipse!   Since it's not there, there is nothing to delete.   Can 
you advise on what to do to find a good workaround?

> Dependency that should be on modulepath sometime put on classpath
> -
>
> Key: MCOMPILER-336
> URL: https://issues.apache.org/jira/browse/MCOMPILER-336
> Project: Maven Compiler Plugin
>  Issue Type: Task
>Affects Versions: 3.7.0
>Reporter: Martin Desruisseaux
>Assignee: Robert Scholte
>Priority: Major
> Attachments: module-vs-classpath.zip
>
>
> {{maven-compiler-plugin}} sometime puts modularized dependencies on the 
> {{javac}} {{-classpath}} option instead than {{-modulepath}}, which cause 
> compilation failure. A test case is attached. Step to reproduce:
> {noformat}
> cd module-vs-classpath
> cd a
> mvn install
> cd ../b
> mvn clean install
> mvn install
> {noformat}
> The last command fail with the following error message:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project b: Compilation failure
> [ERROR] module not found: test.a
> {noformat}
> Execution with the {{-X}} option shows that the {{test.a}} dependency is 
> correctly declared in {{-modulepath}} when executing {{mvn clean install}}, 
> but is wrongly declared in {{-classpath}} when executing {{mvn install}}.
> A workaround is to remove the 
> {{false}} option in 
> the {{pom.xml}} files, or to execute {{touch src/main/java/module-info.java}} 
> before {{mvn install}}. However the same error message occurs when attempting 
> to execute {{mvn site}}, for which case I have found no workaround yet (note: 
> the {{mvn site}} problem is not reproduced by the attached 
> {{module-vs-classpath.zip}} file).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!


[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436100#comment-16436100
 ] 

Colbert Philippe commented on MCOMPILER-337:


Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
2018-02-24T14:49:05-05:00)
Maven home: C:\Users\Colbert Philippe\workspace\montreal\quebec.lachine\EMBEDDED
Java version: 9, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[DEBUG] Created new class realm maven.api
[DEBUG] Importing foreign packages into class realm maven.api
[DEBUG]   Imported: javax.annotation.* < plexus.core
[DEBUG]   Imported: javax.annotation.security.* < plexus.core
[DEBUG]   Imported: javax.enterprise.inject.* < plexus.core
[DEBUG]   Imported: javax.enterprise.util.* < plexus.core
[DEBUG]   Imported: javax.inject.* < plexus.core
[DEBUG]   Imported: org.apache.maven.* < plexus.core
[DEBUG]   Imported: org.apache.maven.artifact < plexus.core
[DEBUG]   Imported: org.apache.maven.classrealm < plexus.core
[DEBUG]   Imported: org.apache.maven.cli < plexus.core
[DEBUG]   Imported: org.apache.maven.configuration < plexus.core
[DEBUG]   Imported: org.apache.maven.exception < plexus.core
[DEBUG]   Imported: org.apache.maven.execution < plexus.core
[DEBUG]   Imported: org.apache.maven.execution.scope < plexus.core
[DEBUG]   Imported: org.apache.maven.lifecycle < plexus.core
[DEBUG]   Imported: org.apache.maven.model < plexus.core
[DEBUG]   Imported: org.apache.maven.monitor < plexus.core
[DEBUG]   Imported: org.apache.maven.plugin < plexus.core
[DEBUG]   Imported: org.apache.maven.profiles < plexus.core
[DEBUG]   Imported: org.apache.maven.project < plexus.core
[DEBUG]   Imported: org.apache.maven.reporting < plexus.core
[DEBUG]   Imported: org.apache.maven.repository < plexus.core
[DEBUG]   Imported: org.apache.maven.rtinfo < plexus.core
[DEBUG]   Imported: org.apache.maven.settings < plexus.core
[DEBUG]   Imported: org.apache.maven.toolchain < plexus.core
[DEBUG]   Imported: org.apache.maven.usability < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.* < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.authentication < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.authorization < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.events < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.observers < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.proxy < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.repository < plexus.core
[DEBUG]   Imported: org.apache.maven.wagon.resource < plexus.core
[DEBUG]   Imported: org.codehaus.classworlds < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.* < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.classworlds < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.component < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.configuration < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.container < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.context < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.lifecycle < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.logging < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.personality < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.util.xml.Xpp3Dom < plexus.core
[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlPullParser < 
plexus.core
[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlPullParserException < 
plexus.core
[DEBUG]   Imported: org.codehaus.plexus.util.xml.pull.XmlSerializer < 
plexus.core
[DEBUG]   Imported: org.eclipse.aether.* < plexus.core
[DEBUG]   Imported: org.eclipse.aether.artifact < plexus.core
[DEBUG]   Imported: org.eclipse.aether.collection < plexus.core
[DEBUG]   Imported: org.eclipse.aether.deployment < plexus.core
[DEBUG]   Imported: org.eclipse.aether.graph < plexus.core
[DEBUG]   Imported: org.eclipse.aether.impl < plexus.core
[DEBUG]   Imported: org.eclipse.aether.installation < plexus.core
[DEBUG]   Imported: org.eclipse.aether.internal.impl < plexus.core
[DEBUG]   Imported: org.eclipse.aether.metadata < plexus.core
[DEBUG]   Imported: org.eclipse.aether.repository < plexus.core
[DEBUG]   Imported: org.eclipse.aether.resolution < plexus.core
[DEBUG]   Imported: org.eclipse.aether.spi < plexus.core
[DEBUG]   Imported: org.eclipse.aether.transfer < plexus.core
[DEBUG]   Imported: org.eclipse.aether.version < plexus.core
[DEBUG]   Imported: org.fusesource.jansi.* < plexus.core
[DEBUG]   Imported: org.slf4j.* < plexus.core
[DEBUG]   Imported: org.slf4j.helpers.* < plexus.core
[DEBUG]   Imported: org.slf4j.spi.* < plexus.core
[DEBUG] Populating class realm maven.api
[INFO] Error stacktraces are turned on.
[DEBUG] Message scheme: plain
[DEBUG] Reading global settings from settings.xml
[DEBUG] Reading user settings from C:\Users\Colbert

[jira] [Comment Edited] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!


[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436083#comment-16436083
 ] 

Colbert Philippe edited comment on MCOMPILER-337 at 4/12/18 6:19 PM:
-

 

Hi Robert!   Robert, I used Eclipse to create the entire project structure.   I 
didn't hand-code it!   It takes too long by hand.   I prefer to do it through 
Eclipse.   My version of Eclipse is the most recent one for Java9.    It's 
Eclipse 4.8M.   There is another version: Eclipse  4.8M a for Java10.   I think 
both are very similar.

 

Here is how I created the project under Eclipse using Maven.

I create a new simple Java project using Maven.   I make sure that it's package 
is POM.   That's my parent project. Within my parent project (right-click on 
parent), go down the menu to Maven->Create New Maven Module, which creates a 
new child-project for a module. The module-info is not in the child-project (it 
should since I selected 'Create new Maven Module').   Eclipse should be doing 
this automatically.    I am forced to create my own module-info.java.   I do 
this using Eclipse menu option.     Right-click 
child-project->Configure->Create module-info I am also forced to create the 
module package myself.   Eclipse should be doing this. I populate the 
module-info.java as show my original letter.

 

 

If you wish, we can do a Skype conference and do a screen-share.   This might 
save time narrowing down the problem.

 

The bottom-line is that Maven + maven-compiler-plugin is mixing-up Classpath 
and module-path.   That's WRONG!   Only module-path should be used!

 


was (Author: cp1):
Hi Robert!   Robert, I used Eclipse to create the entire project structure.   I 
didn't hand-code it!   It takes too long by hand.   I prefer to do it through 
Eclipse.   My version of Eclipse is the most recent one for Java9.    It's 
Eclipse 4.8M.   There is another version: Eclipse  4.8M a for Java10.   I think 
both are very similar.

Here is how I created the project under Eclipse using Maven.
 * I create a new simple Java project using Maven.   I make sure that it's 
package is POM.   That's my parent project.
 * Within my parent project (right-click on parent), go down the menu to 
Maven->Create New Maven Module, which creates a new child-project for a module.
 * The module-info is not in the child-project (it should since I selected 
'Create new Maven Module').   Eclipse should be doing this automatically.   
 * I am forced to create my own module-info.java.   I do this using Eclipse 
menu option.     Right-click child-project->Configure->Create module-info
 * I am also forced to create the module package myself.   Eclipse should be 
doing this.
 * I populate the module-info.java as show my original letter.

 

If you wish, we can do a Skype conference and do a screen-share.   This might 
save time narrowing down the problem.

The bottom-line is that Maven + maven-compiler-plugin is mixing-up Classpath 
and module-path.   That's WRONG!   Only module-path should be used!

 

 

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
>

[jira] [Comment Edited] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!


[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436083#comment-16436083
 ] 

Colbert Philippe edited comment on MCOMPILER-337 at 4/12/18 6:15 PM:
-

Hi Robert!   Robert, I used Eclipse to create the entire project structure.   I 
didn't hand-code it!   It takes too long by hand.   I prefer to do it through 
Eclipse.   My version of Eclipse is the most recent one for Java9.    It's 
Eclipse 4.8M.   There is another version: Eclipse  4.8M a for Java10.   I think 
both are very similar.

Here is how I created the project under Eclipse using Maven.
 * I create a new simple Java project using Maven.   I make sure that it's 
package is POM.   That's my parent project.
 * Within my parent project (right-click on parent), go down the menu to 
Maven->Create New Maven Module, which creates a new child-project for a module.
 * The module-info is not in the child-project (it should since I selected 
'Create new Maven Module').   Eclipse should be doing this automatically.   
 * I am forced to create my own module-info.java.   I do this using Eclipse 
menu option.     Right-click child-project->Configure->Create module-info
 * I am also forced to create the module package myself.   Eclipse should be 
doing this.
 * I populate the module-info.java as show my original letter.

 

If you wish, we can do a Skype conference and do a screen-share.   This might 
save time narrowing down the problem.

The bottom-line is that Maven + maven-compiler-plugin is mixing-up Classpath 
and module-path.   That's WRONG!   Only module-path should be used!

 

 


was (Author: cp1):
Hi Robert!   Robert, I used Eclipse to create the entire project structure.   I 
didn't hand-code it!   It take too long my hand.   I prefer to do it through 
Eclipse.   My version of Eclipse is the most recent one for Java9.    It's 
Eclipse 4.8M.   There is another version: Eclipse  4.8M a for Java10.   I think 
both are very similar.

Here is how I created the project under Eclipse using Maven.
 * I create a new simple Java project using Maven.   I make sure that it's 
package is POM.   That's my parent project.
 * Within my parent project (right-click on parent), go down the menu to 
Maven->Create New Maven Module, which creates a new child-project for a module.
 * The module-info is not in the child-project (it should since I selected 
'Create new Maven Module').   Eclipse should be doing this automatically.   
 * I am forced to create my own module-info.java.   I do this using Eclipse 
menu option.     Right-click child-project->Configure->Create module-info
 * I am also forced to create the module package myself.   Eclipse should be 
doing this.
 * I populate the module-info.java as show my original letter.

 

If you wish, we can do a Skype conference and do a screen-share.   This might 
save time narrowing down the problem.

The bottom-line is that Maven + maven-compiler-plugin is mixing-up Classpath 
and module-path.   That's WRONG!   Only module-path should be used!

 

 

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
>

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!


[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436083#comment-16436083
 ] 

Colbert Philippe commented on MCOMPILER-337:


Hi Robert!   Robert, I used Eclipse to create the entire project structure.   I 
didn't hand-code it!   It take too long my hand.   I prefer to do it through 
Eclipse.   My version of Eclipse is the most recent one for Java9.    It's 
Eclipse 4.8M.   There is another version: Eclipse  4.8M a for Java10.   I think 
both are very similar.

Here is how I created the project under Eclipse using Maven.
 * I create a new simple Java project using Maven.   I make sure that it's 
package is POM.   That's my parent project.
 * Within my parent project (right-click on parent), go down the menu to 
Maven->Create New Maven Module, which creates a new child-project for a module.
 * The module-info is not in the child-project (it should since I selected 
'Create new Maven Module').   Eclipse should be doing this automatically.   
 * I am forced to create my own module-info.java.   I do this using Eclipse 
menu option.     Right-click child-project->Configure->Create module-info
 * I am also forced to create the module package myself.   Eclipse should be 
doing this.
 * I populate the module-info.java as show my original letter.

 

If you wish, we can do a Skype conference and do a screen-share.   This might 
save time narrowing down the problem.

The bottom-line is that Maven + maven-compiler-plugin is mixing-up Classpath 
and module-path.   That's WRONG!   Only module-path should be used!

 

 

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to

[jira] [Commented] (MNG-6392) Add Project Settings .mvn/settings.xml

2018-04-12 Thread James Z.M. Gao (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435984#comment-16435984
 ] 

James Z.M. Gao commented on MNG-6392:
-

[~rfscholte] yeah, settings.xml includes not only , also includes 
,  and .

> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6392) Add Project Settings .mvn/settings.xml

2018-04-12 Thread James Z.M. Gao (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435965#comment-16435965
 ] 

James Z.M. Gao commented on MNG-6392:
-

In my organizations, we share some common .mvn dirs, and synced via git 
sub\{module/tree/repo} commands. I agree the credentials should be always keep 
away from project source. So the .mvn/settings.xml should only contains the 
public or internal shared information, such as repo/mirror url for bootstrap 
the core extensions and parent poms, the http configurations of the server, 
such as timeout. In my cases, the _download_ action do not need auth in a 
internal network (out of this network, the project even can't be checked out), 
and we set .mvn/wrapper/maven-wrapper.properties to download Maven from a 
internal cache server. The important user/password/key for publish artifacts 
only exists on the CI/CD servers by releasing ops teams.

If the bootstrap repo/mirror also need auth, we indeed have to distribute 
credentials before first run `mvn verify`. But setup an identity is more light 
than merge a bunch of profiles/mirrors into .m2/settings.xml. Another pros is 
that the server credentials is composable from many different environments, 
they don't conflict; whereas if two project required different central mirrors, 
they can't be easily merged to fit both projects.

Here is an example for a developer who maintain three projects: private-app, 
company-app and open-source-lib, then

 
{code:java}
~/.m2/settings.xml -- holds the passwords for a company central mirror and a 
personal repo

/open-source-lib -- .mvn dir only contains the wrapper configuration

/company-app/.mvn/settings.xml -- contains a default activated profile with a 
central mirror only works in conpany

/private-app/.mvn/settings.xml -- contains a default activated profile with a 
private repository and a central mirror at home

{code}
 

 

In .mvn dir, the organization and the project ownner can define what maven 
features project needs and how maven integrates with the organization 
infrastructures;

In .m2 dir, the developer define who he is and how the maven cooperates with 
his local environment.

> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MCOMPILER-336) Dependency that should be on modulepath sometime put on classpath


 [ 
https://issues.apache.org/jira/browse/MCOMPILER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte reassigned MCOMPILER-336:


Assignee: Robert Scholte

> Dependency that should be on modulepath sometime put on classpath
> -
>
> Key: MCOMPILER-336
> URL: https://issues.apache.org/jira/browse/MCOMPILER-336
> Project: Maven Compiler Plugin
>  Issue Type: Task
>Affects Versions: 3.7.0
>Reporter: Martin Desruisseaux
>Assignee: Robert Scholte
>Priority: Major
> Attachments: module-vs-classpath.zip
>
>
> {{maven-compiler-plugin}} sometime puts modularized dependencies on the 
> {{javac}} {{-classpath}} option instead than {{-modulepath}}, which cause 
> compilation failure. A test case is attached. Step to reproduce:
> {noformat}
> cd module-vs-classpath
> cd a
> mvn install
> cd ../b
> mvn clean install
> mvn install
> {noformat}
> The last command fail with the following error message:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project b: Compilation failure
> [ERROR] module not found: test.a
> {noformat}
> Execution with the {{-X}} option shows that the {{test.a}} dependency is 
> correctly declared in {{-modulepath}} when executing {{mvn clean install}}, 
> but is wrongly declared in {{-classpath}} when executing {{mvn install}}.
> A workaround is to remove the 
> {{false}} option in 
> the {{pom.xml}} files, or to execute {{touch src/main/java/module-info.java}} 
> before {{mvn install}}. However the same error message occurs when attempting 
> to execute {{mvn site}}, for which case I have found no workaround yet (note: 
> the {{mvn site}} problem is not reproduced by the attached 
> {{module-vs-classpath.zip}} file).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6392) Add Project Settings .mvn/settings.xml


[ 
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435912#comment-16435912
 ] 

Robert Scholte commented on MNG-6392:
-

Sounds like you want the {{profiles.xml}} back which were removed with MNG-4060.

> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte updated MCOMPILER-337:
-
Description:
I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.

I already contacted Maven to ask what version of Maven to use with Java 9
module feature. They recommended the latest version: Maven 3.5.0 (latest) with
the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. I'm
also using Java JDK 9.

I want to report a problem with Maven when working with Java 9 module feature.
It's not a big problem but it's big enough to prevent the use of Maven with
Java 9 modules. The problem is with Maven, when used under Eclipse. I create
Maven projects under Eclipse for speed.

I created two identical projects with Java 9 module. The two projects make use
of a few old-style Jar files by importing them as default module (as prescribed
by the makers of Java 9). The jar files are: ant.jar,
commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar,
commons-lang3-3.7.jar.
* The first project is a small project built from the command-line with a
text-editor. It's a Java 9 module project (has a module-info.java) and makes
use of these 4 libray jar files in the manner prescribed by the Java 9
documentation. This project compiles and works. All Jar files are put the the
module-path of the project and their respective 'requires' statement is in the
module-info.java file. (see below)

{code:java}
module canada.ontario {
exports canada.ontario;
requires org.apache.commons.lang3;
requires commons.collections4;
requires commons.beanutils;
}
{code}
*
** The second project is identical to the first one but is built using Maven
(versions specified above) created under Eclipse. The project as created as
intended based on Maven guidelines. First a parent project was created with
packaging set with pom. The a child-project was created for the module.

After the child-project was created, in the child-project POM file, I entered
the full plug-in entries to use the new 'maven-compiler-plugin' version 3.7.0.
This works because we can see its use on the compiling log display messages.

On Eclipse Workspace view, I selected the parent project root (previously
created), right clicking on the parent project, then selecting 'Maven', then
selecting 'New Maven Module Project'. This creates a Maven child project for
the new module.
- I created a 'module-info.java' with the name of the module (canada.ontario)
in the src directory.
- I also created a package with the same name as the module (canada.ontario).
- I entered the same 'exports' and 'requires' statements as displayed above.
- I also entered all the Maven dependencies to each of the four (4) libraries
stated above. I got these dependencies from the Maven repository.
- I also enabled full compile-time log-message diplay, in order to get maximum
information.

HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT!

When compiling the second child-project for the module, there is an error. I
have narrowed down the reason for the error.

For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar
dependencies under the module-path. It splits the list of dependencies between
the classpath and the module-path, WHICH IS WRONG! (see below)
{noformat}
[INFO] Changes detected - recompiling the module!
[DEBUG] Classpath: <- There should be no jar under this Classpath list ***
[DEBUG] C:\Users\Colbert
Philippe\workspace\montreal\quebec.lachine\target\classes
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
[DEBUG] Modulepath: <- All jar file dependencies should be under this
ModulePath list ***
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\org\apache\commons\commons-lang3\3.7\commons-lang3-3.7.jar
[DEBUG] Source roots:
{noformat}
This is the source of the error!

Since putting all the jar files under module-path works in my first
hand-created project works fine. I am certain that this is the cause of the
error.

was:
I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.

I want to report a problem with Maven when working with Java 9 module feature.

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!


[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435901#comment-16435901
 ] 

Robert Scholte commented on MCOMPILER-337:
--

bq. I created a 'module-info.java' with the name of the module (canada.ontario) 
in the src directory. 

This line worries me a bit, it seems that the project structure doesn't follow 
the [Maven standard directory 
layout|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html],
 but more the Eclipse Java layout.
Assuming you're not bound to the project structure, I'd suggest to Mavens 
default. If you import this in Eclipse, it'll recognize the correct structure.

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
>

[jira] [Commented] (MINSTALL-115) Setting installAtEnd causes no installs to occur when a multimodule project has multiple class realms

2018-04-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MINSTALL-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435807#comment-16435807
 ] 

ASF GitHub Bot commented on MINSTALL-115:
-

chonton commented on issue #1: MINSTALL-115: installAtEnd fails with multiple 
class realms
URL: 
https://github.com/apache/maven-install-plugin/pull/1#issuecomment-380851533
 
 
   Unfortunately, this technique interferes with surefire/failsafe.  The user 
properties must contain String properties.  I could make the pojos into json 
encoding.  
   
   Or, what other places can a plugin save information across invocations?  It 
appears that plugin context is also tied to the ClassLoader.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Setting installAtEnd causes no installs to occur when a multimodule project 
> has multiple class realms
> -
>
> Key: MINSTALL-115
> URL: https://issues.apache.org/jira/browse/MINSTALL-115
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install
>Affects Versions: 2.5.2
>Reporter: Philip Pearson
>Priority: Major
> Attachments: InstallConfiguration.java, mojo.patch
>
>
> When the {{installAtEnd}} configuration parameter is set to {{true}} on a 
> multimodule project with multiple class realms then because a different class 
> loaders creates instances of the {{InstallMojo}} class there will be muliple 
> instances of {{readyProjectsCounter}} and {{installRequests}}.
> However, because the end is determined by {{projectsReady = 
> readyProjectsCounter.incrementAndGet() == reactorProjects.size()}} it will 
> never complete as {{readyProjectsCounter}} will never equal the size 
> {{reactorProjects}} if even one project is executed in another class realm.
> {{maven-deploy-plugin}} partially solved this in MDEPLOY-193 by using 
> {{project.equals(reactorProjects.get(reactorProjects.size() - 1))}} instead.  
> However, the installation is a little more complex than the deploy as we need 
> to read the used the {{createChecksum}} and {{updateReleaseInfo}} 
> configuration parameters from each installed project - we can't store them 
> ahead of time because of the issue with the class realms, so we need to read 
> the plugin configurations before we can call 
> {{installProject(instalRequest)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] chonton commented on issue #1: fix DeployAtEnd failures

chonton commented on issue #1: fix DeployAtEnd failures
URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-380851681
 
 
   Unfortunately, this technique interferes with surefire/failsafe.  The user 
properties must contain String properties.  I could make the pojos into json 
encoding.  
   
   Or, what other places can a plugin save information across invocations?  It 
appears that plugin context is also tied to the ClassLoader.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


With regards,
Apache Git Services

[GitHub] chonton commented on issue #1: MINSTALL-115: installAtEnd fails with multiple class realms

chonton commented on issue #1: MINSTALL-115: installAtEnd fails with multiple 
class realms
URL: 
https://github.com/apache/maven-install-plugin/pull/1#issuecomment-380851533
 
 
   Unfortunately, this technique interferes with surefire/failsafe.  The user 
properties must contain String properties.  I could make the pojos into json 
encoding.  
   
   Or, what other places can a plugin save information across invocations?  It 
appears that plugin context is also tied to the ClassLoader.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


With regards,
Apache Git Services

[jira] [Updated] (MCLEAN-86) Unable to delete files because of umlauts

2018-04-12 Thread Phillip Wirth (JIRA)


 [ 
https://issues.apache.org/jira/browse/MCLEAN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phillip Wirth updated MCLEAN-86:

Description: 
I am not able to delete some files with mvn clean

The LOCALE vairable is set to \{{C}}

Project properties:
{code:java}
UTF-8
 UTF-8
 utf-8

{code}
 

I am able to build the project (same locale setting) and deep inside the target 
folder I can see why it fails
{code:java}
zarathustra@wotan ..oesung/oms/xxx/xxx/coupons/domain/meta (git)-[master] % ll 
total 24 
-rw-rw-r--. 1 zarathustra zarathustra 1139 Apr 12 16:37 
'MetaAdvertisementOutletCity$D'$'\303\274''sseldorfLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1115 Apr 12 16:37 
'MetaAdvertisementOutletCity$K'$'\303\266''lnLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nchenLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nsterLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1131 Apr 12 16:37 
'MetaAdvertisementOutletCity$N'$'\303\274''rnbergLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1143 Apr 12 16:37 
'MetaAdvertisementOutletCity$Saarbr'$'\303\274''ckenLiteral.class'

{code}
 

Running {{mvn -X clean}} results in the following error:
{code:java}
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
 
 at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) 
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) 
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) 
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) 
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) 
 at sun.reflect.NativeMethodAxxxssorImpl.invoke0(Native Method) 
 at 
sun.reflect.NativeMethodAxxxssorImpl.invoke(NativeMethodAxxxssorImpl.java:62) 
 at 
sun.reflect.DelegatingMethodAxxxssorImpl.invoke(DelegatingMethodAxxxssorImpl.java:43)
 
 at java.lang.reflect.Method.invoke(Method.java:498) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) 
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to clean 
project: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:212) 
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) 
 ... 20 more 
Caused by: java.io.IOException: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:251) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:193) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:118) 
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:191) 
 ... 22 more

{code}

  was:
I am not able to delete some files with mvn clean

The LOCALE vairable is set to \{C}

Project properties:
{code:java}
UTF-8
 UTF-8
 utf-8

{code}
 

I am able to build the project (same locale setting) and deep inside the target 
folder I can see why it fails
{code:java}

[jira] [Created] (MCLEAN-86) Unable to delete files because of umlauts

2018-04-12 Thread Phillip Wirth (JIRA)

Phillip Wirth created MCLEAN-86:
---

 Summary: Unable to delete files because of umlauts
 Key: MCLEAN-86
 URL: https://issues.apache.org/jira/browse/MCLEAN-86
 Project: Maven Clean Plugin
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: fedora with maven and LOCALE=C
Reporter: Phillip Wirth


I am not able to delete some files with mvn clean

The LOCALE vairable is set to \{C}

Project properties:

{code}

UTF-8
 UTF-8
 utf-8

{code}

 

I am able to build the project (same locale setting) and deep inside the target 
folder I can see why it fails

{code}

zarathustra@wotan ..oesung/oms/cce/xxx/coupons/domain/meta (git)-[master] % ll 
total 24 
-rw-rw-r--. 1 zarathustra zarathustra 1139 Apr 12 16:37 
'MetaAdvertisementOutletCity$D'$'\303\274''sseldorfLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1115 Apr 12 16:37 
'MetaAdvertisementOutletCity$K'$'\303\266''lnLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nchenLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nsterLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1131 Apr 12 16:37 
'MetaAdvertisementOutletCity$N'$'\303\274''rnbergLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1143 Apr 12 16:37 
'MetaAdvertisementOutletCity$Saarbr'$'\303\274''ckenLiteral.class'

{code}

 

Running \{{mvn -X clean}} results in the following error:

{code}

at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
 
 at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) 
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) 
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) 
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) 
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) 
 at sun.reflect.NativeMethodAxxxssorImpl.invoke0(Native Method) 
 at 
sun.reflect.NativeMethodAxxxssorImpl.invoke(NativeMethodAxxxssorImpl.java:62) 
 at 
sun.reflect.DelegatingMethodAxxxssorImpl.invoke(DelegatingMethodAxxxssorImpl.java:43)
 
 at java.lang.reflect.Method.invoke(Method.java:498) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) 
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to clean 
project: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:212) 
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) 
 ... 20 more 
Caused by: java.io.IOException: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:251) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:193) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:118) 
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:191) 
 ... 22 more

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MCLEAN-86) Unable to delete files because of umlauts

2018-04-12 Thread Phillip Wirth (JIRA)


 [ 
https://issues.apache.org/jira/browse/MCLEAN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phillip Wirth updated MCLEAN-86:

Description: 
I am not able to delete some files with mvn clean

The LOCALE vairable is set to \{C}

Project properties:
{code:java}
UTF-8
 UTF-8
 utf-8

{code}
 

I am able to build the project (same locale setting) and deep inside the target 
folder I can see why it fails
{code:java}
zarathustra@wotan ..oesung/oms/xxx/xxx/coupons/domain/meta (git)-[master] % ll 
total 24 
-rw-rw-r--. 1 zarathustra zarathustra 1139 Apr 12 16:37 
'MetaAdvertisementOutletCity$D'$'\303\274''sseldorfLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1115 Apr 12 16:37 
'MetaAdvertisementOutletCity$K'$'\303\266''lnLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nchenLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37 
'MetaAdvertisementOutletCity$M'$'\303\274''nsterLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1131 Apr 12 16:37 
'MetaAdvertisementOutletCity$N'$'\303\274''rnbergLiteral.class' 
-rw-rw-r--. 1 zarathustra zarathustra 1143 Apr 12 16:37 
'MetaAdvertisementOutletCity$Saarbr'$'\303\274''ckenLiteral.class'

{code}
 

Running {{mvn -X clean}} results in the following error:
{code:java}
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
 
 at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) 
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) 
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) 
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) 
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) 
 at sun.reflect.NativeMethodAxxxssorImpl.invoke0(Native Method) 
 at 
sun.reflect.NativeMethodAxxxssorImpl.invoke(NativeMethodAxxxssorImpl.java:62) 
 at 
sun.reflect.DelegatingMethodAxxxssorImpl.invoke(DelegatingMethodAxxxssorImpl.java:43)
 
 at java.lang.reflect.Method.invoke(Method.java:498) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) 
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) 
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to clean 
project: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:212) 
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
 
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) 
 ... 20 more 
Caused by: java.io.IOException: Failed to delete 
/home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:251) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:193) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160) 
 at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:118) 
 at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:191) 
 ... 22 more

{code}

  was:
I am not able to delete some files with mvn clean

The LOCALE vairable is set to \{C}

Project properties:

{code}

UTF-8
 UTF-8
 utf-8

{code}

 

I am able to build the project (same locale setting) and deep inside the target 
folder I can see why it fails

{code}

[jira] [Created] (MSOURCES-115) aggregate-sources yields different results based on reactor

2018-04-12 Thread Raymond DeCampo (JIRA)

Raymond DeCampo created MSOURCES-115:


 Summary: aggregate-sources yields different results based on 
reactor
 Key: MSOURCES-115
 URL: https://issues.apache.org/jira/browse/MSOURCES-115
 Project: Maven Source Plugin
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Raymond DeCampo


The main idea here is that depending on whether a particular project is built 
from the parent project or on its own, the sources jar generated by 
aggregate-sources may be different.  IMO this attacks the repeat-ability of the 
build.  The root cause is that aggregate-sources pulls in all the sources in 
the reactor.

 

Consider a three layer structure.  One parent project at the top level, say 
foo-parent.  Then two child modules at the next level, say foo-client and 
foo-server.  Then some number of children of foo-client and foo-server where 
the actual Java code lives.

 

The poms for foo-server and foo-client have aggregate-sources set up.  If a 
build is executed directly on foo-client for example, then the resulting source 
foo-client-sources-*.jar will have the source from the children of foo-client.

 

If a build is executed from foo-parent, both foo-client and foo-server are 
included in the reactor.  Now the resulting foo-client-sources-*.jar includes 
the source code from foo-server's children as well as its own.

 

I would expect that the aggregate-sources target would only include the source 
of the children of the current project instead of the source from any project 
in the reactor.  I would also expect that the build should result identical 
artifacts whether or not it is invoked from the parent project or not.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Colbert Philippe updated MCOMPILER-337:
---
Description:
I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.

HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT!

When compiling the second child-project for the module, there is an error. I
have narrowed down the reason for the error.

[INFO] Changes detected - recompiling the module!
[DEBUG] Classpath: <- There should be no jar under this Classpath list ***
[DEBUG] C:\Users\Colbert
Philippe\workspace\montreal\quebec.lachine\target\classes
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
[DEBUG] Modulepath: <- All jar file dependencies should be under this
ModulePath list ***
[DEBUG] C:\Users\Colbert
Philippe\.m2\repository\org\apache\commons\commons-lang3\3.7\commons-lang3-3.7.jar
[DEBUG] Source roots:

This is the source of the error!

Since putting all the jar files under module-path works in my first
hand-created project works fine. I am certain that this is the cause of the
error.

was:
I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.

I want to report a problem with Eclipse when working with Java 9 module
feature. It's not a big

[jira] [Created] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

Colbert Philippe created MCOMPILER-337:
--

Summary: Using old-style Jar files with Java9 Module project,
Classpath and Module-path are mixed up!
Key: MCOMPILER-337
URL: https://issues.apache.org/jira/browse/MCOMPILER-337
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.7.0
Reporter: Colbert Philippe

I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.

I want to report a problem with Eclipse when working with Java 9 module
feature. It's not a big problem but it's big enough to prevent the use of
Eclipse with Java 9 modules. The problem is with Eclipse, not Maven. The Maven
version that I'm using works fine! I tested it!

* The first project is a small project built from the command-line with a
text-editor. It's a Java 9 module project (has a module-info.java) and makes
use of these 4 libray jar files in the matter prescribed by the Java 9
documentation. This project compile and works. All Jar files are put the the
module-path of the project and their respective 'requires' statement is in the
module-info.java file. (see below)

module canada.ontario {
exports canada.ontario;
requires org.apache.commons.lang3;
requires commons.collections4;
requires commons.beanutils;
}

** The second project is identical to the first one but is built using Eclipse
& Maven (versions specified above). The project as created as intended with
Maven. First a parent project was created with packaging set with pom. The a
child-project was created for the module.

- I created a 'module-info.java' with the name of the module (canada.ontario)
in the src directory.
- I also created a package with the same name as the module (canada.ontario).
- I entered the same 'exports' and 'requires' statements as displayed above.
- I also entered all the Maven dependencies to each of the four (4) libraries
stated above. I got these dependencies from the Maven repository.
- I also enabled full compile-time log-message diplay, in order to get maximum
information.

### HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! ###

When compiling the second child-project for the module, there is an error. I
have narrowed down the reason for the errror.

This is the source of the error!

Since putting all the jar files under module-path works in my first
hand-created project works fine. I am certain that this is the cause of the
error.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6392) Add Project Settings .mvn/settings.xml


[ 
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435530#comment-16435530
 ] 

Karl Heinz Marbaise commented on MNG-6392:
--

Can you give a use case example for this? I think going a way to put a 
{{settings.xml}} into {{.mvn/settings.xml}} would run into the need to have a 
setup in every project which I don't like and based on the large organisations 
I have worked at it is bad cause you can't sync that correctly. Having a two 
possible location in particular {{$HOME/.m2/settings.xml}} in particular things 
like passwords/keys for access to repository managers etc. which I would like 
**NOT** to have inside the project (nor is this allowed in corporate 
environments)...
Based on your suggestions via `./mvnw verify` after the code has been checked 
out can cause issues as well cause how should be downloaded the initial Maven 
for this? From where and by using which credentials for access to repositories 
which is very often limited by using credentials ? 

> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6392) Add Project Settings .mvn/settings.xml


 [ 
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6392:
-
Remaining Estimate: (was: 168h)
 Original Estimate: (was: 168h)

> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNGSITE-333) Broken link in "Project maven is retired. See maven's attic page."


 [ 
https://issues.apache.org/jira/browse/MNGSITE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MNGSITE-333.
---
Resolution: Not A Problem

I have checked on the pages too and I don't see any hint about that...nor I can 
see it in the source of the page? So I will close this issue..nevertheless 
thanks for reporting this...and trying to help.

> Broken link in "Project maven is retired. See maven's attic page."
> --
>
> Key: MNGSITE-333
> URL: https://issues.apache.org/jira/browse/MNGSITE-333
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Maria Jurcovicova
>Priority: Major
>
> The [https://maven.apache.org/] page currently shows red banner on top. The 
> banner says: "Project _maven_ is retired. See maven's [attic page 
> |https://attic.apache.org/projects/maven.html]." 
> If maven was really retired, then the link in "attic page" is broken. There 
> does not seem to be any mention of maven in apache attic. If the project is 
> not retired, the banner should not be there.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Moved] (MNGSITE-333) Broken link in "Project maven is retired. See maven's attic page."