The command line is too long. in java project with maven - java

I have maven-gwt project. It has lots of dependencies which is usual by a large project. I think it is at the limit with creation of classpath. I found some information about the limitation. Allowed is 1023 Character. But I need the libraries.
I receive the following error when i want to package my project mit Maven.
The command line is too long.
How can I get around the problem.?
Here is the expanded error in Jenkins:
[INFO] --- maven-surefire-plugin:2.5:test (default-test) # MyProject ---
[INFO] Surefire report directory: C:\Documents and Settings\User\.jenkins\workspace\Myproject\target\surefire-reports
The command line is too long.
The command line is too long.
[ERROR] There are test failures.

I found another workaround here http://code.google.com/p/gwt-maven/issues/detail?id=88
(I have problem with changing pom to fit a specific OS)
In short: make path to local repository as short as possible.
"
Comment 40 by gaurav.a...#gmail.com, Mar 23, 2009
One of the fix to the problem of "GWT compilation fails due to- The input line is
too long." is as follows:
Change m2(maven) repository. You might have your maven
repository at:
C:\Documents and Settings\MahcineNameABC\.m2
Copy settings.xml file from folder
apache-maven-2.0.8\apache-maven-2.0.8\conf into C:\Documents and Settings\MahcineNameABC\.m2
In settings.xml:
change the tag as
<localRepository>M:</localRepository>. Now your m2 home is a virtual M drive.
Create a repository folder as D:\maven-2.0.8\repository
Cut/Copy all the files/folders from C:\Documents and Settings\MahcineNameABC\.m2\repository to D:\maven-2.0.8\repository
Map local drive: open command prompt and execute (to create the
virtual drive):
subst M: D:\maven-2.0.8\repository(help)
Now a virtual M drive will point to your repository.
Set environment variable M2_REPO with value M:
To enable long inputs, on command prompt execute:cmd /e:32768
This would fix the problem of long inputs due to very long entries in classpath
variables, at least in Win XP SP2. The inputs are combined and tested from comment#22
and #7.
Hope it helps!
This should help in most cases (and 'til the end of project - at least in my case)

This seems to be a known problem with gwt-maven. There is a discussion on the gwt-maven google groups: Workaround for windows command line length limit
The problem seems to be that the sources are included on the test classpath, hence you're getting problems when you're running surefire:
The workaround is to exclude the sources dependency, make it system scope (from the above thread):
<dependency>
<!-- non existant artifact ID required (-source) maven bug?? -->
<artifactId>myproject-rpc-source</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<classifier>sources</classifier>
<!-- hack below as maven only incudes provdied in test scope -->
<scope>system</scope>
<systemPath>${basedir}/../rpc/target/myproject-rpc-${project.version}-sources.jar</systemPath>
</dependency>
but I would fully read and understand the google groups thread before proceeding with this.

If you are using Intellij there is a setting in workspace.xml that takes care of this issue. There is an existing post about this.

From 2.5.0-rc1 the GWT Maven plugin has a new option: "genParam". Set this param to false to aviod this problem.

Related

Maven build failing due to unrecognized `--settings` option

In my Java projects building with maven, I have a a .mvn directory that contains a maven.config file. Content of that file is as follows:
--settings ./.mvn/local-settings.xml
The local-settings.xml holds authentication credentials for pulling from a private registry.
This setup worked fine up until yesterday. Now, the CI build (using maven:3-amazoncorretto-17) is failing with the following error message:
Unable to parse maven.config file options: Unrecognized option: --settings ./.mvn/local-settings.xml
Has there been a breaking change in the maven image I am using for building?
With the introduction of maven 3.9, there was a BREAKING CHANGE that affects the parsing of the maven.config file:
https://maven.apache.org/docs/3.9.0/release-notes.html#potentially-breaking-core-changes
Each line in .mvn/maven.config is now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see MNG-7684.
As pointed out by #khmarbaise in the comments, adding a newline in the maven.config works just fine and is even downwards compatible.
--settings
./.mvn/local-settings.xml

Unable to find out where reflections-maven plugin comes from

There executes a particular Maven plugin and I struggle to find out where it comes from to either remove or replace it as its compile dependency link is broken. I am talking about org.reflections:reflections-maven:0.9.8 that depends on org.jfrog.jade.plugins.common:jade-plugin-common:1.3.8 which Maven is not able to download from the central repository as the link redirects to OpenMind location and results in 404 (link).
Instead of including such JAR in the project structure, I would rather figure out where is reflections-maven plugin defined as this plugin is discontinued (GitHub) but somehow is executed during the build (mvn clean install).
[INFO] --- reflections-maven:0.9.5:reflections (default) # my-module ---
[INFO] Reflections took 240 ms to scan 1 urls, producing 35 keys and 128 values
[INFO] Reflections successfully saved in C:\Dev\my-project\my-parent\my-module\target\classes\META-INF\reflections\my-module-reflections.xml using XmlSerializer
I haven't found where is reflections-maven defined in any of the multi-module project structure or used. Note I use Maven 3.3.9. My attempts:
Skimming through all plugins and dependencies pom.xml of the failing module and all its parents (the module depends on other modules, however, they were all built successfully before the failing one).
mvn dependency:tree -Dverbose doesn't mention any of reflections-maven or jade-plugin-common at all. The command generates over 136k lines, so it was required to save the output into a file and perform the full-text-search. I am afras Maven 3 is the limit here as far as I understand from this comment.
Using depgraph-maven-plugin gave me the very same negative result.
mvn dependency:analyze -DignoreNonCompile gives only an information that the artifacts were resolved and that where it ends. it doesn't really show anything useful.
[INFO] --- reflections-maven:0.9.5:reflections (default) # my-module ---
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections-maven:pom:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections-maven\0.9.5\reflections-maven-0.9.5.pom-[IJ]-artifactCoord=org.reflections:reflections-maven:pom:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections-maven:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections-maven\0.9.5\reflections-maven-0.9.5.jar-[IJ]-artifactCoord=org.reflections:reflections-maven:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections\0.9.5\reflections-0.9.5.jar-[IJ]-artifactCoord=org.reflections:reflections:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=com.google.guava:guava:jar:r08-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\com\google\guava\guava\r08\guava-r08.jar-[IJ]-artifactCoord=com.google.guava:guava:jar:r08-[IJ]-error=
...
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.4.0-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\jfrog\maven\annomojo\maven-plugin-anno\1.4.0\maven-plugin-anno-1.4.0.jar-[IJ]-artifactCoord=org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.4.0-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.jfrog.jade.plugins.common:jade-plugin-common:jar:1.3.8-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\jfrog\jade\plugins\common\jade-plugin-common\1.3.8\jade-plugin-common-1.3.8.jar-[IJ]-artifactCoord=org.jfrog.jade.plugins.common:jade-plugin-common:jar:1.3.8-[IJ]-error=
...
Checking the artifacts using the reflections-maven from here, however, none of the artifacts mentioned appear in my project as well.
Question: If I don't have such JAR in the local repository, the build fails as the plugin is executed. In that case, how can I find a way any plugin (particularly reflections-maven in my case) is truly imported and executed in the project?
Feel free to ask for more info in the commens. I use IntelliJ Idea, Maven 3.3.9 and Java 7 if it matters.
Solution 1 (didn't work for me): I have tried to run mvn -Dverbose=true -Doutput=./effective-pom.xml help:effective-pom and both the normal and the verbose form of effective-pom displays the same output of reflections-maven plugin with no additional information about its origin. Since the file is rather big, I include a screenshot:
This might be an issue with my Maven 3.3.9 with a custom settings.xml and a specific IntelliJ Idea. I assume the verbose output would lead to the true origin.
Solution 2:
Upon installing Netbeans (I use IntelliJ Idea by default), the Effective tab of the POM editor finally led me to the true origin where the plugin is defined.
Sadly, IntelliJ Idea doesn't provide such navigation through its effective POM and navigating to the origin is virtually impossible without manual clicking through parent POMs.
With
Help:Effective-Pom:
mvn -Dverbose=true -Doutput=./effective-pom.xml help:effective-pom
We can analyze our "effective pom" (Pom#inheritance, Pom#super-Pom).
The verbose flag will also add the source pom (artifact) as a comment to each output line.
output sets an output file. (default: prints to console)
"inter alia" it allows us to locate/override any inherited plugin/dependency/"pom element".
Unfortunately the output generates:
for "trivial" projects "hundreds" lines of pom.
for "non-trivial" (spring-boot-starter), it gets easily into "ten-thousands" (lines of pom).
In intellij we have a "Show effective Pom" command, which basically invokes the mentioned goal and shows the output (in community edition unfortunately!?) without "verbose".
netbeans has a "Effective" tab in its "Pom Editor":
scrolling/cursoring is here also "cumbersome", but we have "full":
"Navigation" (window) support
Text search
Code hints, etc...
(, "Graph" view also very nice...(and unique feature among "maven IDES (that i know)", and it can be installed un-rooted;)!
Update:
So the mojo seems to work as documented:
<verbose> boolean (since:)3.2.0 Output POM input location as comments.
Default value is: false.
User property is: verbose.
For verbose to have an effect, we need to:
<project ...>
...
<build>
<plugins>
<artifactId>maven-help-plugin</artifactId>
<version>3.2.0</version> <!-- or higher! -->
</plugins>
</build>
...
</project>
... respectively can (without pom modification):
mvn -Dverbose=true -Doutput=./eff.pom.xml \
org.apache.maven.plugins:maven-help-plugin:3.2.0:effective-pom

Error during SonarScanner execution after executing SonarScanner.MSBuild.exe end command

Sonarqube Version -7.9.5
SonarQube Scanner - sonar-scanner-msbuild-5.0.4.24009-net46
Source code contains - C#, angular.js, html5, javascript.
Hi,
I executed the following commands and after executing the 3rd command I am getting execution failure error.
The command I executed in the CMD prompt are browsing to the path where solution is present are,
SonarScanner.MSBuild.exe begin /k:"Demo" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="TokenID_ABC"
MsBuild.exe /t:Rebuild
SonarScanner.MSBuild.exe end /d:sonar.login="TokenID_ABC"
ERROR: Error during SonarScanner execution
org.sonar.java.AnalysisException: Please provide compiled classes of your project with sonar.java.binaries property
I found one similar kind of issue reported where it is said that due to .java file present in the code the issue occurs, in our code as well .java files are present, not sure the use of them. How can I exclude those .java files while SonarQube analysis is performed and in which file do I need to add exclusion code?
Also, if there is some another solution to resolve this issue, then please let me know as I have very limited knowledge of Sonar.
Link of similar issue -
https://community.sonarsource.com/t/error-while-running-sonar-scanner-please-provide-compiled-classes-of-your-project-with-sonar-java-binaries-property/30027/2
You can exclude arbitrary files by going to your project settings in SonarQube -> Analysis Scope -> Source File Exclusions. Use regex to match your java files, i.e. *.java.

Changelog path resolving in Liquibase maven plugin

I've got one problem with liquibase-maven-plugin 4.2.2. If I specify the path to logs like it was before
changeLogFile= classpath:db/changelog/db.changelog-master.xml
I'm getting an error
Error Reading Changelog File: Found 2 files that match classpath:db/changelog/db.changelog-master.xml: jar:file:/Users/macbook/IdeaProjects/geek-study-eshop/shop-database/target/shop-database-1.0-SNAPSHOT.jar!/db/changelog/db.changelog-master.xml, file:/Users/macbook/IdeaProjects/geek-study-eshop/shop-database/target/classes/db/changelog/db.changelog-master.xml
I understand the reason for this error and it possible to resolve it by changing changeLogFile to target/db/changelog/db.changelog-master.xml. But in this case, I will have target\ prefix in filenames stored in DATABASECHANGELOG table. But I don't want that for some reasons. I want all file names there to be with prefix db/changelog/... or classpath:db/changelog/.... Is that possible to do that somehow without using logicFilePath attribute?
I found the solution! There is no way to change liquibase-maven-plugin behavior but it's possible to change maven phase on which we run liquibase:diff command. Simply use mvn clean compile liquibase:diff! We are doing diff after compilation and resource movement but before the jar packaging.

An ERROR occurred in archiving the artifacts

When I type "build*.jar" into Files to archive filed in Archive the artifacts, the warning red message "build*.jar' doesn't match anything: 'build' exists but not 'build*.jar" appears.
After I ignore it and build, the following ERROR occurred:
Archiving artifacts
ERROR: No artifacts found that match the file pattern "build\*.jar". Configuration error?
ERROR: 'build\*.jar' doesn't match anything: 'build' exists but not 'build\*.jar'
Build step 'Archive the artifacts' changed build result to FAILURE
Finished: FAILURE
If you want to totally ignore the artifact part, you can select the Do not fail build if archiving returns nothing option in Jenkins Post-build Actions > Archive the artifacts > Advanced settings.
Please check if build is a direct folder within your Jenkins Project workspace. For example if , target is a direct folder with your project workspace, target\*.jar will archive all the jars within the target folder. Also, please try clicking on the ? for more details
What's probably happening is that \ is escaping * and it's looking for literally the file named build*.jar.
I assume you are on Windows, hence you are using \ separator. However most Windows versions support /. Try that first:
build/*.jar
If that doesn't work, you can try escaping \ in the first place:
build\\*.jar

Categories

Resources