Re: maven-jar-plugin out of heap space
Hi, the VOTE for a fixed version maven-jar-plugin will be finished within a few days which includes this fix.. so only a few days to live with this remporary solution. Kind regards Karl Heinz Marbaise On 6/8/16 11:48 PM, Csaba Kozák wrote: Hey Karl, Updating plexus-archiver seems to do the trick. On 29 May 2016 at 15:21, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, I have checked a setup with -Xmx32m ...which will not work...but if you increase to -Xmx40m it will work... Kind regards Karl Heinz Marbaise On 5/29/16 3:11 PM, Karl Heinz Marbaise wrote: Hi, On 5/26/16 9:13 PM, WonderCsabo wrote: Hey, After i updated the maven-jar-plugin to version 3.0.0, i started to see these problems on my CI build: https://travis-ci.org/WonderCsabo/androidannotations/jobs/132201434#L2473 I can verify that this only happens with 3.0.0. Could you please try to configuration the maven-jar-plugin 3.0.0 like this in your build and check if this helps: org.apache.maven.plugins maven-jar-plugin 3.0.0 org.codehaus.plexus plexus-archiver 3.3 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Resources Plugin Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Resources Plugin Version 3.0.1. https://maven.apache.org/plugins/maven-resources-plugin/ Important Note: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-resources-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-resources-plugin/download.cgi Release Notes Maven Resources Plugin 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317827=12335752 Bug: * [MRESOURCES-225] - Hyperlink error on character encoding example page Improvements: * [MRESOURCES-226] - Too much logging in normal mode * [MRESOURCES-227] - Upgrade maven-plugins to version 30 * [MRESOURCES-229] - Upgrade plexus-interpolation to 1.22 Enjos, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.1.0. https://maven.apache.org/shared/maven-archiver/ The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. Important Notes since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-archiver 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-archiver/download.cgi Release Notes Maven Archiver 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12335563 Bugs: * [MSHARED-494] - Impossible to generate a reproducible build due to timestamp in pom.properties * [MSHARED-544] - Remove maven-fluido-skin from site descriptor Improvements: * [MSHARED-515] - Addition of xz compression support. * [MSHARED-522] - Upgrade maven-shared-components parent to version 30 * [MSHARED-539] - Upgrade plexus-utils to 3.0.24 * [MSHARED-540] - Upgrade plexus-interpolation to 1.22 * [MSHARED-541] - Upgrade maven-shared-utils to 3.0.1 * [MSHARED-542] - Upgrade plexus-archiver to 3.3 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Packaging doxygen output across modules?
Hi, so you need to have the packaging in the doxygen-maven-plugin as well which is currently not done...? Best would be to add a feature request ... Kind regards Karl Heinz Marbaise On 6/4/16 4:28 PM, org.apache.maven.u...@io7m.com wrote: Hello. I have a multi-module project: module-A module-B module-C module-documentation The module-documentation module contains documentation written in a DocBook-like system. The build for the module aggregates the javadocs of module-[A,B,C], generates XHTML documentation, and packages the whole lot up into an archive file. This is all working fine, however I now need to add a module-D that contains source code written in a language that can only currently be documented via Doxygen. I see Karl Heinz Marbaise is maintaining a nice doxyen-maven-plugin, so I've attached that as a report and it works correctly. However, how do I now package up the resulting doxygen HTML such that it can be added to the archive file produced by module-documentation? What's the Maven way to handle this? M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Status on namespace support for POM Elements ?
Hi, On 6/5/16 7:22 AM, Roland Huss wrote: Hi Karl Heinz, Really bad idea to hijack an existing jira issue.. Please open a new one or if you have problems creating an issue please ask here on the users list first... Agreed, but I really couldn't create a new ticket at that time (only service desk ticket were enabled) so that what my last ressort. Sorry, very likely my fault, since I could open a ticket today --> https://issues.apache.org/jira/browse/MNG-6036 So if you couldn't open a new ticket than you should have asked first and waited untill someone has ansered and helped you which you didn't...and changed things without a need...I have removed the comment in MNG-2716.. Do you really think introducing XML namespaces would make the handling of the pom better ? In particular if you have a separate namespace for every plugin? (At apache maven project we have 49 plugins ? This would mean in consequence 49 namespaces? And at mojohaus there are about another 50 plugins? So this means having to use the configuration parameters for all the plugins and on top you need to do namespace configuration in your pom file? I'm the opinion this would make things worse than better...(There are some things which are better)... In general pom changes in any way could only become part of pom model 5 (Maven 4/5 in line) cause it would break to many things...You can take a deep look into the jira for Maven 4.. https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12330198 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Filtering Version 3.1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Filtering Version 3.1.1. https://maven.apache.org/shared/maven-filtering/ This component has been built from the filtering process/code in Maven Resources Plugin. Important Notes since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-filtering 3.1.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-filtering/download.cgi Release Notes Maven Archiver 3.1.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12335751 Improvements: * [MSHARED-516] - Change info logging output to debug (ignoreDelta) * [MSHARED-517] - Refactor Code to remove usage of deprecated marked code. * [MSHARED-528] - Upgrade maven-shared-components parent to version 30 * [MSHARED-532] - Upgrade plexus-utils to 3.0.24 * [MSHARED-533] - Upgrade plexus-interpolation to 1.22 * [MSHARED-543] - Change info logging output to debug Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Shared Utils Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Shared Utils Version 3.0.1. https://maven.apache.org/shared/maven-shared-utils/ This project aims to be a functional replacement for plexus-utils in Maven. Important Notes since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-shared-utils 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-shared-utils/download.cgi Release Notes Maven Shared Utils 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12335471 Bug: * [MSHARED-475] - Not able to compile a module named as "RCS" and "SCCS" Improvements: * [MSHARED-503] - Upgrade maven-shared-components parent to version 22 * [MSHARED-504] - Remove System.gc() call * [MSHARED-534] - Upgrade com.google.code.findbugs:jsr305 to 3.0.0 * [MSHARED-535] - Upgrade maven-shared-components parent to version 30 * [MSHARED-536] - Removed unused plugin declaration for maven-assembly-plugin * [MSHARED-537] - Removing plugin declaration which is handled by the parent * [MSHARED-538] - Upgrade maven-fluido-skin to 1.5 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Status on namespace support for POM Elements ?
Hi, On 6/1/16 9:57 PM, Roland Huss wrote: Hi, I tried to use a namespace different than the default one for POM elements and failed. After some research through various JIRA tickets its seems that this is a quite old topic, but I couldn't find a statement whether namespace it is now planned or not. It's not that I would expect any special namespace related feature, but merely to be able to use specify a namespace like in http://www.w3.org/2001/XMLSchema-instance; xmlns="http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/POM/4.0.0;> http://maven.apache.org/POM/4.0.0; xmlns="http://fabric8.io/fabric8-maven-plugin;> . This also my use case, namely to introduce an XSD for a plugin configuration. Thus works with IDEA autocompletion and doc support, but only when not switching the default namespace. I don't know why, but I was unable to create a new issue on JIRA. Therefore I 'hijacked' an old one because I think this is ticket is still valid--> https://issues.apache.org/jira/browse/MNG-2715?focusedCommentId=15307347=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15307347 Really bad idea to hijack an existing jira issue.. Please open a new one or if you have problems creating an issue please ask here on the users list first... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin out of heap space
Hi, I have checked a setup with -Xmx32m ...which will not work...but if you increase to -Xmx40m it will work... Kind regards Karl Heinz Marbaise On 5/29/16 3:11 PM, Karl Heinz Marbaise wrote: Hi, On 5/26/16 9:13 PM, WonderCsabo wrote: Hey, After i updated the maven-jar-plugin to version 3.0.0, i started to see these problems on my CI build: https://travis-ci.org/WonderCsabo/androidannotations/jobs/132201434#L2473 I can verify that this only happens with 3.0.0. Could you please try to configuration the maven-jar-plugin 3.0.0 like this in your build and check if this helps: org.apache.maven.plugins maven-jar-plugin 3.0.0 org.codehaus.plexus plexus-archiver 3.3 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin out of heap space
Hi, On 5/26/16 9:13 PM, WonderCsabo wrote: Hey, After i updated the maven-jar-plugin to version 3.0.0, i started to see these problems on my CI build: https://travis-ci.org/WonderCsabo/androidannotations/jobs/132201434#L2473 I can verify that this only happens with 3.0.0. Could you please try to configuration the maven-jar-plugin 3.0.0 like this in your build and check if this helps: org.apache.maven.plugins maven-jar-plugin 3.0.0 org.codehaus.plexus plexus-archiver 3.3 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions regarding License Maven Plugin
Hi Mark, On 5/27/16 3:27 PM, Mark H. Wood wrote: On Thu, May 26, 2016 at 10:34:28AM +0100, Stian Soiland-Reyes wrote: license-maven-plugin is not maintained by Apache, and have its own mailing list which should be able to help you further: This page http://www.mojohaus.org/mail-lists.html shows the users mailing list of the Apache Maven Project as Mailing list for the mojohaus .which is not correct...;-( Use the dev mailing list... More generally: a plugin with a name like FOO-maven-plugin is not maintained by the Maven project, and it would be good to see if it has its own mailing list. A plugin with a name like maven-FOO-plugin probably *is* maintained by the Maven project. We should make it more clear. The name of the plugin alone maven-FOO-plugin is not enough..the groupId tells you the rest: org.apache.maven.plugins is the group of the maven-plugins which are maintained here at the Apache Maven Project: The list of plugins: https://maven.apache.org/plugins/ We have also a number of shared artifacts (usually used by plugins also outside of Apache). https://maven.apache.org/shared/ The other groupId is: org.codehaus.mojo which is maintained at the MojoHaus (formerly CodeHaus): http://www.mojohaus.org/ The list of plugins: http://www.mojohaus.org/plugins.html (Which is honestly not uptodate)... Better take a look at https://github.com/mojohaus/ So if you have the groupId: org.apache.maven.plugins plus artifactId: maven-compiler-plugin this plugin is mainained here at Apache Maven Project... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions regarding License Maven Plugin
Hi, On 5/26/16 1:30 PM, Karl Heinz Marbaise wrote: Hi Maxim, not a big issue many of the MojoHaus developers are also on this list ... Yeah the page of the license-maven-plugin has not been updated for a longer time (last time with the release of the license-maven-plugin)... I completely missed there has been a release a few days ago..this should have been changed.. So you can use this: https://groups.google.com/forum/#!forum/mojohaus-dev Kind regards Karl Heinz Marbaise On 5/26/16 12:13 PM, Maxim Solodovnik wrote: Hm, According to [1], this is the only user list available So I hope to get some answers to my questions here [1] http://www.mojohaus.org/license-maven-plugin/mail-lists.html On Thu, May 26, 2016 at 3:53 PM, Maxim Solodovnik <solomax...@gmail.com> wrote: sorry for posting to the wrong list The plugin was announced here, this is why I wrote here :( Will write to the correct list On Thu, May 26, 2016 at 3:34 PM, Stian Soiland-Reyes <st...@apache.org> wrote: Hi, license-maven-plugin is not maintained by Apache, and have its own mailing list which should be able to help you further: http://www.mojohaus.org/license-maven-plugin/mail-lists.html Some documentation for each goal: http://www.mojohaus.org/license-maven-plugin/plugin-info.html On 26 May 2016 5:19 a.m., "Maxim Solodovnik" <solomax...@gmail.com> wrote: Hello All, I'm trying to integrate license-maven-plugin and have couple of questions: 1) it seems like "aggregate-add-third-party" goal with "useMissingFile" option is not generating "src/license/THIRD-PARTY.properties" files, is this by design? 2) it seems "groupByLicense" option is not available for "aggregate-add-third-party" goal, maybe it can be added? 3) Is it possible to generate LICENSE file like [1] using this plugin? so there will be blocks like: license name affected libraries license text Thanks in advance for the answers :) [1] https://git-wip-us.apache.org/repos/asf?p=tomee.git;a=blob_plain;f=LICENSE;hb=HEAD - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions regarding License Maven Plugin
Hi Maxim, not a big issue many of the MojoHaus developers are also on this list ... Yeah the page of the license-maven-plugin has not been updated for a longer time (last time with the release of the license-maven-plugin)... So you can use this: https://groups.google.com/forum/#!forum/mojohaus-dev Kind regards Karl Heinz Marbaise On 5/26/16 12:13 PM, Maxim Solodovnik wrote: Hm, According to [1], this is the only user list available So I hope to get some answers to my questions here [1] http://www.mojohaus.org/license-maven-plugin/mail-lists.html On Thu, May 26, 2016 at 3:53 PM, Maxim Solodovnik <solomax...@gmail.com> wrote: sorry for posting to the wrong list The plugin was announced here, this is why I wrote here :( Will write to the correct list On Thu, May 26, 2016 at 3:34 PM, Stian Soiland-Reyes <st...@apache.org> wrote: Hi, license-maven-plugin is not maintained by Apache, and have its own mailing list which should be able to help you further: http://www.mojohaus.org/license-maven-plugin/mail-lists.html Some documentation for each goal: http://www.mojohaus.org/license-maven-plugin/plugin-info.html On 26 May 2016 5:19 a.m., "Maxim Solodovnik" <solomax...@gmail.com> wrote: Hello All, I'm trying to integrate license-maven-plugin and have couple of questions: 1) it seems like "aggregate-add-third-party" goal with "useMissingFile" option is not generating "src/license/THIRD-PARTY.properties" files, is this by design? 2) it seems "groupByLicense" option is not available for "aggregate-add-third-party" goal, maybe it can be added? 3) Is it possible to generate LICENSE file like [1] using this plugin? so there will be blocks like: license name affected libraries license text Thanks in advance for the answers :) [1] https://git-wip-us.apache.org/repos/asf?p=tomee.git;a=blob_plain;f=LICENSE;hb=HEAD -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive dependencies starting from WAR files
Hi Steve, Why not running maven-dependency-plugin it within the war package module than you get all dependencies which have been packaged into the war file ? Kind regards Karl Heinz Marbaise On 5/24/16 2:07 PM, Hostettler, Steve wrote: Hi, Our solutions is composed of different war files. I would like, starting from the released artifacts that we deliver to our customer, to generate a dependency list. The goal is to be able to present an exhaustive list of dependencies we are relying on along with their licenses. The org.apache.maven.plugins:maven-dependency-plugin does not help for it does not display War dependencies. I would prefer reusing an existing plugin but in the worst case I can also write my own plugin for that. Have you any suggestion on how to tackle this problem? Many thanks in advance for your help. Steve - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin-3.0.0 compatiblity/regression?
Hi Maxim, I've already created an issue for m2e: https://github.com/tesla/m2eclipse-mavenarchiver/issues/8 Kind regards Karl Heinz Marbaise On 5/23/16 5:54 AM, Maxim Solodovnik wrote: Hello Karl, do I need to create JIRA issue? or maybe you can point me to the correct tracker I can file issue against m2e? On Sat, May 21, 2016 at 1:11 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, On 5/20/16 7:20 AM, Maxim Solodovnik wrote: I got following errors in eclipse: org.apache.maven.archiver.MavenArchiver.getManifest(org.apache.maven.project.MavenProject, org.apache.maven.archiver.MavenArchiveConfiguration) pom.xml /openmeetings-core line 1 Maven Configuration Problem command line build works as expected This is a problem in M2E ... Kind regards Karl Heinz Marbaise On Fri, May 20, 2016 at 11:16 AM, Dan Tran <dant...@gmail.com> wrote: Hi My jar project can also create RPM via rpm-maven-plugin:attach-rpm now throws this error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (project-jar-for-docker) on project xxx: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1] This is a valid use case where I can have mutiple artifact extensions without the need to use classifiers The release notes of jar plugin 3.0.0 also not mentioned about this I hope this is not intentional My appology, i should have tested the during its voting period Thanks -Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Resources Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the
Apache Maven Resources Plugin Version 3.0.0.
https://maven.apache.org/plugins/maven-resources-plugin/
Important Note:
* Maven 3.X only
* JDK 6 minimum requirement
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-resources-plugin
3.0.0
You can download the appropriate sources etc. from the download page:
https://maven.apache.org/plugins/maven-resources-plugin/download.cgi
Release Notes Maven Resources Plugin 3.0.0
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317827=12331252
Bugs:
* [MRESOURCES-190] - Regression: The plugin is now silently ignoring
.gitignore files.
* [MRESOURCES-191] - Updated plexus-interpolation to fix possible concurrency
issues
* [MRESOURCES-218] - List of examples not complete on first page
* [MRESOURCES-219] - Link to wiki page should be removed now that Codehaus is
shut down
* [MRESOURCES-221] - Additional practices for Filtering example page
Improvements:
* [MRESOURCES-99] - ${project.baseUri} and ${maven.build.timestamp} are not
expanded by resource filtering
* [MRESOURCES-185] - Update version of plexus-utils to 3.0.18
* [MRESOURCES-186] - Improve error handling based on Mark invalid
* [MRESOURCES-187] - New parameter in the plugin to be able to use filename
filtering.
* [MRESOURCES-188] - Upgrade to Maven 3.0 compatiblity + JDK 1.6
* [MRESOURCES-192] - Upgrade maven-filtering to 1.3
* [MRESOURCES-194] - Upgrade to maven-plugins parent version 26
* [MRESOURCES-195] - Upgrade maven-plugin-testing-harness to 1.3
* [MRESOURCES-197] - Upgrade to maven-plugins parent version 27
* [MRESOURCES-201] - Add Parameter for not ignore directories with a leading
dot.
* [MRESOURCES-202] - Upgrade plexus-utils to 3.0.22
* [MRESOURCES-207] - Change package to org.apache.maven.plugins to prevent
conflict with Maven Core
* [MRESOURCES-208] - Remove @Deprecated marked code
* [MRESOURCES-213] - Moved code into maven-filtering
* [MRESOURCES-214] - Added requireProjects to resources/testResources mojo
* [MRESOURCES-216] - Upgrade maven-filtering to 3.1.0
* [MRESOURCES-217] - Updated plexus-utils to 3.0.23
* [MRESOURCES-220] - Encoding example should mention recommended default
project.build.sourceEncoding property
* [MRESOURCES-222] - Remove param properties that doesn't make sense for CLI
usage
* [MRESOURCES-223] - Define the escapeString by default with "\"
New Feature:
* [MRESOURCES-203] - Add a skip option to skip the execution of resources goal
Reporters of this Release:
* Laurent TOURREAU [MRESOURCES-203]
* Felix Köhler [MRESOURCES-201]
* Josue Abarca [MRESOURCES-190]
* Thomas Champagne [MRESOURCES-99]
Many thanks to all reporters/contributors/testers of this release.
Enjos,
-The Apache Maven team
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: gpg bad signature
Hi, On 5/21/16 5:12 PM, Vejcik, Steve wrote: Hi Folks – just starting down the path of using Maven and am unable to verify the signature for the binary tar.gz archive: gpg --verify apache-maven-3.3.9-bin.tar.gz.asc apache-maven-3.3.9-bin.tar.gz.asc You have to use: gpg --verify apache-maven-3.3.9-bin.tar.gz.asc apache-maven-3.3.9-bin.tar.gz instead ... Kind regards Karl Heinz Marbaise gpg: Signature made Tue 10 Nov 2015 10:44:20 AM CST using DSA key ID BB617866 gpg: BAD signature from "Sarel Jason van Zyl <ja...@maven.org>" (after having imported the KEYS file cited on the main page). I assume all is well, but want to confirm and/or find a way to verify signature. Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin-3.0.0 compatiblity/regression?
Hi Dan, On 5/20/16 10:26 PM, Dan Tran wrote: I meant appassemble-maven-plugin. Ah sorry could have imagined that myself... very likely the error is from the fix of https://issues.apache.org/jira/browse/MJAR-198 For now, I will need to use antrun to copy the local primary jar to the place I need. Maybe, appassemble should do this for me btw, if have RPM module but does invocation of 2 jar goals. Would that cause an issue? If you run the jar goals without defining a classifier than yes...I assume you used the jar goal ? That's not a issue it prevents bad things which means simply replacing primary artifact without knowing it... -D On Fri, May 20, 2016 at 1:11 PM, Karl Heinz Marbaise <khmarba...@gmx.de <mailto:khmarba...@gmx.de>> wrote: Hi Dan, On 5/20/16 10:04 PM, Dan Tran wrote: Hi Robert, According to the jar plugin source outputDirectory is not read only. that is why I can change the default value. here is my use case - Start out of jar module with a profile to create the RPM - In the profile, use assembler-maven-plugin to create staging distribution assembly-maven-plugin? Do you mean maven-assembly-plugin ? - since the primary jar file is not in my staging, I need to invoke jar plugin explicitly to create another jar. This makes jar plugin thinks it has 2 primary artifacts and bails out - Use RPM to package the staging As there has been already a call which sets the main artifact (primary artiact) of the project and maven-jar-plugin regrets to set the main artifact if it is already been set That sounds like you build needs to be cleaned up...to prevent setting the main artifact twice ? Can we see that build somewhere ? Or can you send me a log file of it? (privately?) This is a valid use case right? Hm..we will see Kind regards Karl Heinz Thanks -Dan On Fri, May 20, 2016 at 12:15 PM, Robert Scholte <rfscho...@apache.org <mailto:rfscho...@apache.org>> wrote: Dan, outputDirectory has become a readonly parameter. The reason is that you can set it with . Does that work for you? thanks, Robert On Fri, 20 May 2016 21:09:55 +0200, Karl Heinz Marbaise <khmarba...@gmx.de <mailto:khmarba...@gmx.de>> wrote: Hi Dan, On 5/20/16 7:16 AM, Dan Tran wrote: Hi My jar project can also create RPM via rpm-maven-plugin:attach-rpm now throws this error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (project-jar-for-docker) on project xxx: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1] This is a valid use case where I can have mutiple artifact extensions without the need to use classifiers Can you create an example project for this? So i can create an JIRA for that or you can create the jira with that...sounds like an edge case which i didn't thought of ?... So you are replacing the main artifact but with different extensions ? Hm.. ? > The release notes of jar plugin 3.0.0 also not mentioned about this https://issues.apache.org/jira/browse/MJAR-198 I hope this is not intentional - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin-3.0.0 compatiblity/regression?
Hi Dan, On 5/20/16 10:04 PM, Dan Tran wrote: Hi Robert, According to the jar plugin source outputDirectory is not read only. that is why I can change the default value. here is my use case - Start out of jar module with a profile to create the RPM - In the profile, use assembler-maven-plugin to create staging distribution assembly-maven-plugin? Do you mean maven-assembly-plugin ? - since the primary jar file is not in my staging, I need to invoke jar plugin explicitly to create another jar. This makes jar plugin thinks it has 2 primary artifacts and bails out - Use RPM to package the staging As there has been already a call which sets the main artifact (primary artiact) of the project and maven-jar-plugin regrets to set the main artifact if it is already been set That sounds like you build needs to be cleaned up...to prevent setting the main artifact twice ? Can we see that build somewhere ? Or can you send me a log file of it? (privately?) This is a valid use case right? Hm..we will see Kind regards Karl Heinz Thanks -Dan On Fri, May 20, 2016 at 12:15 PM, Robert Scholte <rfscho...@apache.org> wrote: Dan, outputDirectory has become a readonly parameter. The reason is that you can set it with . Does that work for you? thanks, Robert On Fri, 20 May 2016 21:09:55 +0200, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi Dan, On 5/20/16 7:16 AM, Dan Tran wrote: Hi My jar project can also create RPM via rpm-maven-plugin:attach-rpm now throws this error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (project-jar-for-docker) on project xxx: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1] This is a valid use case where I can have mutiple artifact extensions without the need to use classifiers Can you create an example project for this? So i can create an JIRA for that or you can create the jira with that...sounds like an edge case which i didn't thought of ?... So you are replacing the main artifact but with different extensions ? Hm.. ? The release notes of jar plugin 3.0.0 also not mentioned about this https://issues.apache.org/jira/browse/MJAR-198 I hope this is not intentional Kind regards Karl Heinz Marbaise - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin-3.0.0 compatiblity/regression?
Hi, On 5/20/16 7:20 AM, Maxim Solodovnik wrote: I got following errors in eclipse: org.apache.maven.archiver.MavenArchiver.getManifest(org.apache.maven.project.MavenProject, org.apache.maven.archiver.MavenArchiveConfiguration) pom.xml /openmeetings-core line 1 Maven Configuration Problem command line build works as expected This is a problem in M2E ... Kind regards Karl Heinz Marbaise On Fri, May 20, 2016 at 11:16 AM, Dan Tran <dant...@gmail.com> wrote: Hi My jar project can also create RPM via rpm-maven-plugin:attach-rpm now throws this error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (project-jar-for-docker) on project xxx: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1] This is a valid use case where I can have mutiple artifact extensions without the need to use classifiers The release notes of jar plugin 3.0.0 also not mentioned about this I hope this is not intentional My appology, i should have tested the during its voting period Thanks -Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jar-plugin-3.0.0 compatiblity/regression?
Hi Dan, On 5/20/16 7:16 AM, Dan Tran wrote: Hi My jar project can also create RPM via rpm-maven-plugin:attach-rpm now throws this error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.0:jar (project-jar-for-docker) on project xxx: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1] This is a valid use case where I can have mutiple artifact extensions without the need to use classifiers Can you create an example project for this? So i can create an JIRA for that or you can create the jira with that...sounds like an edge case which i didn't thought of ?... So you are replacing the main artifact but with different extensions ? Hm.. ? The release notes of jar plugin 3.0.0 also not mentioned about this https://issues.apache.org/jira/browse/MJAR-198 I hope this is not intentional Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven JAR Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JAR Plugin Version 3.0.0. https://maven.apache.org/plugins/maven-jar-plugin/ Important Note: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jar-plugin 3.0.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jar-plugin/download.cgi Release Notes Maven JAR Plugin 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12334171 Bugs: * [MJAR-177] - Empty string should be treated as default classifier * [MJAR-198] - jar:jar without classifier replaces default jar * [MJAR-204] - Adding plexus-utils version 3.0.22 * [MJAR-205] - Compatibility with JDK9 requires an update of plexus-archiver * [MJAR-216] - Documentation for skip param in test-jar goal is wrong Documentation: * [MJAR-197] - Typo in site navigation Improvements: * [MJAR-183] - Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin * [MJAR-194] - Upgrade plexus-archiver to 2.10 * [MJAR-199] - Option "classifier" to goal test-jar * [MJAR-201] - Upgrade Maven 3.X Only JDK 1.6 * [MJAR-202] - Bump version to 3.0.0-SNAPSHOT * [MJAR-203] - Change package to org.apache.maven.plugins to prevent conflict with Maven Core * [MJAR-207] - Upgrade plexus-archiver from 3.0.3 to 3.1 * [MJAR-208] - Make naming of properties consistent * [MJAR-209] - Remove param properties that doesn't make sense for CLI usage * [MJAR-210] - Remove useDefaultManifestFile parameter * [MJAR-214] - Replace @pom.version@ with @project.version@ in Integration Tests * [MJAR-215] - Upgrade plexus-archiver from 3.1 to 3.1.1 in synch with maven-archiver 3.0.1 * [MJAR-217] - Make finalName readonly parameter Tasks: * [MJAR-213] - Upgrade to maven-archiver 3.0.1 * [MJAR-218] - Upgrade to maven-archiver 3.0.2 to fix regression Reporters of this Release: * Sanne Grinovero [MJAR-205] * Leo Breuss [MJAR-199] * Elias Elmqvist Wulcan [MJAR-198] * Andreas Kohn [MJAR-197] * Stefan Fussenegger [MJAR-177] Tester of this Release: * Stian Soiland-Reyes Many thanks to all reporters/contributors/testers of this release. Enjos, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn site [ERROR] Unable to determine if resource
Hi, can you show exactly what you have tried and show the error messages you get? Best would be an example project which causes the problems... And how your settings.xml looks like? Kind regards Karl Heinz Marbaise On 5/13/16 6:31 PM, sekaijin wrote: I'm runnig mvn 3.3.9 i'm using a nexus repository as a miror (not internet acces) I've somes erros on mvn site command I've added each repositories in mirror settings but mvn continue to try to connect on internet A+JYT - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple local repositories
On 5/7/16 10:08 PM, Karagkiaouris Diamantis wrote:
Yes. Exactly but is it possible to pass a variable from
tag during the build in order to have different
local caches?
No..the localRepository can not be part of a profile.
But you can use the following:
mvn -Dmaven.repo.local=$HOME/.my/other/repository
Kind regards
Karl Heinz Marbaise
Thank you
Am 07.05.2016 um 22:57 schrieb Karl Heinz Marbaise:
Hi,
On 5/7/16 9:49 PM, Karagkiaouris Diamantis wrote:
Hello,
I would like to ask if it is possible to have multiple local maven
repositories and if it can be set as a parameter in a maven profile.
Can you explain what you exactly mean.
Do you mean having a different local caches for different purposes ?
Runinng one build with cache at $HOME/.m2/repository and running a
second build with cache at $HOME/.m2/repository-run-two
The location of the local cache can be configured via the
[settings.xml][1] file like this:
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd;>
${user.home}/.m2/repository
This snippet above shows the default...to change it for your own
purposes you need to change localRepositoy entry...
But usually i can't recommend that, only if you exactyl what you are
doing...
[1]: https://maven.apache.org/settings.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple local repositories
Hi,
On 5/7/16 9:49 PM, Karagkiaouris Diamantis wrote:
Hello,
I would like to ask if it is possible to have multiple local maven
repositories and if it can be set as a parameter in a maven profile.
Can you explain what you exactly mean.
Do you mean having a different local caches for different purposes ?
Runinng one build with cache at $HOME/.m2/repository and running a
second build with cache at $HOME/.m2/repository-run-two
The location of the local cache can be configured via the
[settings.xml][1] file like this:
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd;>
${user.home}/.m2/repository
This snippet above shows the default...to change it for your own
purposes you need to change localRepositoy entry...
But usually i can't recommend that, only if you exactyl what you are
doing...
[1]: https://maven.apache.org/settings.html
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.0.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.0.2. https://maven.apache.org/shared/maven-archiver/ The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. Important Notes since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-archiver 3.0.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-archiver/download.cgi Release Notes Maven Archiver 3.0.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12335563 Bugs: * [MSHARED-513] - Regression: Created-By row in manifest does not include Maven version Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Filtering Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Filtering Version 3.1.0. https://maven.apache.org/shared/maven-filtering/ This component has been built from the filtering process/code in Maven Resources Plugin. The goal is to provide a shared component for all plugins that needs to filter resources. Important Note since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's pom as follows: org.apache.maven.shared maven-filtering 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-filtering/download.cgi Release Notes Maven Filtering 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334170 Improvements: * [MSHARED-495] - Add convenience method to move code into Maven Filtering * [MSHARED-496] - Change version from 3.0.1 to 3.1.0-SNAPSHOT to follow semver. * [MSHARED-497] - Allow copying of defaultExcluded files like .gitignore etc. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.0.1 Released
Hi to all, unfortunately the previous email about Maven Archiver 3.0.1 announcement contained the wrong content. Now the following content is the correct one (hopefully ;-). Sorry for the confusion. Kind regards Karl Heinz Marbaise The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.0.1. https://maven.apache.org/shared/maven-archiver/ The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. Important Note since Version 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's pom as follows: org.apache.maven.shared maven-archiver 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-archiver/download.cgi Release Notes Maven Archiver 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334036 Bugs: * [MSHARED-154] - pomPropertiesFile does not actually permit override * [MSHARED-191] - Specification-Version must not contain "-SNAPSHOT" * [MSHARED-298] - Errors in manifest example on site Improvements: * [MSHARED-296] - Improve header of pom.properties * [MSHARED-465] - Remove @Deprecated marked code * [MSHARED-506] - Upgrade plexus-archiver from 2.9.1 to 3.1.1 * [MSHARED-511] - Using structures to keep insertion order for MANIFEST.MF * [MSHARED-512] - Remove @Deprecated marked code which has been missed. Tasks: * [MSHARED-492] - Upgrade parent to version 22 * [MSHARED-493] - Clean up warnings emitted by Javadoc 8 (doclint) and Checkstyle Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Source Plugin Version 3.0.0. https://maven.apache.org/plugins/maven-source-plugin/ The Source Plugin creates a jar archive of the source files of the current project. The jar file is, by default, created in the project's target directory. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-source-plugin 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-source-plugin/download.html Release Note Apache Maven Source Plugin Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12331545 Bug: * [MSOURCES-81] - allow sources jar to contain Maven descriptor Improvements: * [MSOURCES-75] - Update version of plexus-archiver to 2.7 * [MSOURCES-76] - Upgrade from maven-plugins version 25 to 26 * [MSOURCES-77] - Upgrade maven-archiver from 2.5 to 2.6 * [MSOURCES-78] - Upgrade plexus-archiver 2.7 to 2.8.4 * [MSOURCES-79] - Upgrade to maven-plugins parent version 27 * [MSOURCES-80] - Upgrade plexus-archiver to 2.10.2 * [MSOURCES-82] - Make naming of properties consistent to the plugin name. * [MSOURCES-83] - Make Plugin only Maven 3.0 minimum * [MSOURCES-84] - Change package name from org.apache.maven.plugin to org.apache.maven.plugins * [MSOURCES-85] - Upgrade plexus-archiver to 3.0.1 * [MSOURCES-86] - Upgrade maven-archiver to 3.0.0 * [MSOURCES-88] - Upgrade plexus-utils to 3.0.22 * [MSOURCES-89] - Using plugin parent version 28 * [MSOURCES-90] - Upgrade junit to 4.11 * [MSOURCES-91] - Added several properties for parameters * [MSOURCES-92] - Generate Maven Descriptor by default * [MSOURCES-93] - Upgrade plexus-archiver from 3.0.1 to 3.0.3 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maybe a lack of specification ?
Hi,
On 4/14/16 5:37 PM, Raffaele Esposito wrote:
Hi,
Thank you for your mails.
I still think maven plugin documentations are poorly designed,
what I highlighted could indeed be considered defect in the documentation.
So i would suggest to make appropriate issue in JIRA either with patches
attached or related pull request (via githup) or at least write in the
issues what and how to improve this...
Apache Maven is an open source project ...any help is appreciated...
Kind regards
Karl Heinz Marbaise
Kind regards,
Raffaele
On Thu, Apr 14, 2016 at 12:21 AM, Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:
Hi,
On 4/13/16 11:26 PM, Raffaele Esposito wrote:
Hi all,
In the Maven super-pom.xml definition (4.0.0)
in the build section are defined some configuration parameters,
such as:
${project.basedir}/target
${project.build.directory}/classes
${project.basedir}/target
${project.build.directory}/classes
${project.artifactId}-${project.version}
${project.build.directory}/test-classes
${project.basedir}/src/main/java
...
Now let's take for example :
${project.build.directory}/classes
*resources:resources* plugin goal uses it, as described in the
documentation:
Name Type Since Description outputDirectory File - The output
directory into which to copy the resources. Default value is:
${project.build.outputDirectory}.
Yes the maven-resources-plugin defines it and it means you can
change it via the pom configuration for the goal: resources
*compiler:compile* plugin goal uses it as well (I guess),
but it is nowhere defined in the documentation of that plugin.
In the documentation you mean that you can use it as a configuration
entry in the pom ? And yes this it is correct, cause it wouldn't
make sense to change it...(which is also true for the
maven-resources-plugin) but at the moment it is as it is...This
might change for 3.0.0 of maven-resources-plugin...
And the other thing it is defined for the compiler-plugin as you can
see here:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java?revision=1517906=markup#l65
>
Why is that
? is it a lack in the specification or what ?
am I missing something ?
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maybe a lack of specification ?
Hi,
On 4/13/16 11:26 PM, Raffaele Esposito wrote:
Hi all,
In the Maven super-pom.xml definition (4.0.0)
in the build section are defined some configuration parameters,
such as:
${project.basedir}/target
${project.build.directory}/classes
${project.basedir}/target
${project.build.directory}/classes
${project.artifactId}-${project.version}
${project.build.directory}/test-classes
${project.basedir}/src/main/java
...
Now let's take for example :
${project.build.directory}/classes
*resources:resources* plugin goal uses it, as described in the
documentation:
Name Type Since Description outputDirectory File - The output
directory into which to copy the resources. Default value is:
${project.build.outputDirectory}.
Yes the maven-resources-plugin defines it and it means you can change it
via the pom configuration for the goal: resources
*compiler:compile* plugin goal uses it as well (I guess),
but it is nowhere defined in the documentation of that plugin.
In the documentation you mean that you can use it as a configuration
entry in the pom ? And yes this it is correct, cause it wouldn't make
sense to change it...(which is also true for the maven-resources-plugin)
but at the moment it is as it is...This might change for 3.0.0 of
maven-resources-plugin...
And the other thing it is defined for the compiler-plugin as you can see
here:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java?revision=1517906=markup#l65
>
Why is that
? is it a lack in the specification or what ?
am I missing something ?
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: "Perhaps you are running on a JRE rather than a JDK?" error building with maven.
Hi,
i would recommend you to use Maven 3.X at least..and don't use Maven 2.X
anymore..(cause it's End Of Life)...
Where does JAVA_HOME point to? to /home/user/ProgramFiles/jdk1.8.0_71/
or /home/user/ProgramFiles/jdk1.8.0_71/jre ?
Kind regards
Karl Heinz Marbaise
On 2/26/16 3:24 PM, Gintare Ragaisiene wrote:
Hello
I want to use swagger-codegen on Ubuntu 14.04 LTS (OS type 64-bit). So I
downloaded the source code from
https://github.com/swagger-api/swagger-codegen/tree/v2.1.5 , unzipped it
and build with maven.
$ sudo mvn -e package
The error appears:
...
[INFO] Copying 438 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 66 source files to
/home/user/ProgramFiles/swagger-codegen-2.1.5/modules/swagger-codegen/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] No compiler is provided in this environment. Perhaps you are
running on a JRE rather than a JDK?
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
No compiler is provided in this environment. Perhaps you are running on a
JRE rather than a JDK?
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
No compiler is provided in this environment. Perhaps you are running on a
JRE rather than a JDK?
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException:
Compilation failure
No compiler is provided in this environment. Perhaps you are running on a
JRE rather than a JDK?
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:745)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:118)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
--
"mvn -v" output is:
Apache Maven 2.2.1 (rdebian-14)
Java version: 1.8.0_71
Java home: /home/user/ProgramFiles/jdk1.8.0_71/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "3.19.0-49-generic" arch: "amd64" Family: "unix"
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Source Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Source Plugin Version 3.0.0. https://maven.apache.org/plugins/maven-source-plugin/ The Source Plugin creates a jar archive of the source files of the current project. The jar file is, by default, created in the project's target directory. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-source-plugin 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-source-plugin/download.html Release Note Apache Maven Source Plugin Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12331545 Bug: * [MSOURCES-81] - allow sources jar to contain Maven descriptor Improvements: * [MSOURCES-75] - Update version of plexus-archiver to 2.7 * [MSOURCES-76] - Upgrade from maven-plugins version 25 to 26 * [MSOURCES-77] - Upgrade maven-archiver from 2.5 to 2.6 * [MSOURCES-78] - Upgrade plexus-archiver 2.7 to 2.8.4 * [MSOURCES-79] - Upgrade to maven-plugins parent version 27 * [MSOURCES-80] - Upgrade plexus-archiver to 2.10.2 * [MSOURCES-82] - Make naming of properties consistent to the plugin name. * [MSOURCES-83] - Make Plugin only Maven 3.0 minimum * [MSOURCES-84] - Change package name from org.apache.maven.plugin to org.apache.maven.plugins * [MSOURCES-85] - Upgrade plexus-archiver to 3.0.1 * [MSOURCES-86] - Upgrade maven-archiver to 3.0.0 * [MSOURCES-88] - Upgrade plexus-utils to 3.0.22 * [MSOURCES-89] - Using plugin parent version 28 * [MSOURCES-90] - Upgrade junit to 4.11 * [MSOURCES-91] - Added several properties for parameters * [MSOURCES-92] - Generate Maven Descriptor by default * [MSOURCES-93] - Upgrade plexus-archiver from 3.0.1 to 3.0.3 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: debugging maven-deploy-plugin:deploy-file
Hi, On 2/8/16 6:43 AM, Mehul Sanghvi wrote: I have a project with multiple modules and sub-modules. Two of the modules, use the same maven-deploy-plugin:deploy-file logic, just the artefacts they are working Can you show an example of your deploy-file logic? Cause if you are really using deploy-file goal within your pom file and in your life cycle there is something wrong... Kind regards Karl Heinz Marbaise with are different. One module uploads designated JARs to Nexus. The other is meant for uploading ZIP files. Both are activated only if their respective profiles are activated, -Pupload-jars and -Pupload-zips respectively. Both modules share the same settings.xml information regarding repositories and servers. Upload-jars is able to successfully upload the JARs using deploy-file. Upload-zips always fails with: Return code is: 401, ReasonPhrase:Unauthorized How do I figure out the credentials that are being used ? When I use mvn -X I do not see anything that would indicate what user/passwd combination is being used. Any thoughts or suggestions ? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Avoid change folder permission when using maven site deploy plugin
On 2/3/16 8:13 PM, Tim Wu T wrote: Hi All, When we deploy the site to our Linux server, I found maven will execute "chmod -Rf g+w,a+rX " in the log folder every time, and this will takes very long time (Maybe 5-6 minutes) Can show a little bit more of your log output and in particular which Maven version, which plugin do you use? How do you deploy the site ? How is Maven called in this case? Kind regards Karl Heinz Marbaise Is there any way to avoid this? Thanks very much. Br, Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven ACR Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven ACR Plugin Version 3.0.0. https://maven.apache.org/plugins/maven-acr-plugin/ This plugin generates J2EE Application Client file. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-acr-plugin 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-acr-plugin/download.html Release Note Apache Maven ACR Plugin Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317020=12330202 Improvements: * [MACR-12] - Update version of plexus-archiver to 2.5 * [MACR-13] - Update version of plexus-archiver to 2.7.1 * [MACR-14] - Upgrade plexus-interpolation to 1.21 * [MACR-15] - Upgrade maven-filtering to 1.3 * [MACR-16] - Upgrade maven-archiver to 2.6 * [MACR-17] - Upgrade plexus-archiver 2.7.1 to 2.8.2 * [MACR-18] - Upgrade to maven-plugins version 25 to 26 * [MACR-19] - Upgrade to maven-plugins parent version 27 * [MACR-20] - Upgrade maven-plugin-testing-harness to 1.3 * [MACR-21] - Upgrade from plexus-archiver 2.4.4 to 2.9 * [MACR-22] - Remove unnecessary exclusions of org.codehaus.plexus:plexus-component-api * [MACR-23] - Upgrade Maven 3.X Only JDK 1.6 * [MACR-24] - Change package to org.apache.maven.plugins to prevent conflict with Maven Core * [MACR-25] - Rename properties according to the plugin name * [MACR-26] - Update lifecycle mapping to newest plugin version. * [MACR-27] - Bump version to 3.0.0-SNAPSHOT Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: CD versioning
Hi Jason,
sounds interessting.. ;-)..
Kind regards
Karl Heinz
On 1/22/16 3:17 AM, Jason van Zyl wrote:
I have something that I wouldn’t make public but you’re free to hack it up and
do what you like with it.
On Jan 21, 2016, at 11:47 AM, Benson Margulies <bimargul...@gmail.com> wrote:
On Thu, Jan 21, 2016 at 2:42 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
Hi Benson,
you know that you can define the following properties since Maven 3.2.1[1]
${revision}, ${changelist} and ${sha1} which can be set outside from Maven
via:
mvn -Drevision=1.2.3-SNAPSHOT ...
and you can use it:
...
...
${revision}
..
in case of a multi module build you can also use it in the parent definition
of the children...
but there does not exist some kind of jar which generates the version...as
far as i know...
that's the disconnect; i thought that JvZ or someone described a
drop-in Jar that could cause a property to come into existence (which
could then be referenced). Of course, I can wrap a script around mvn
if there is no such beast.
Kind regards
Karl Heinz Marbaise
[1]: http://maven.apache.org/docs/3.2.1/release-notes.html
On 1/20/16 1:11 PM, Benson Margulies wrote:
Some time ago, I recall some email about dynamic versioning; the idea
being that all the elements in all the POMs of the project
would look like ${version}, and a jar dropped into
the maven extensions directory would provide a component that would
generate the version, perhaps from a git hash or something like that.
Is there any doc around on how to set this up? Is it functional in
3.2.5?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Combination of deployAtEnd and installAtEnd does not seem to work
Hi, can you test if a simple mvn deploy will work correctly or is it only related during the release ? Has release plugin somehow configured (preparationGoals something llike this? )? Kind regards Karl Heinz Marbaise On 1/22/16 2:11 PM, Alexander Kriegisch wrote: Yesterday I rolled another release and again the artifacts were not uploaded. I cannot share my build log because it contains internal information, but what I can say is that for each single module I see in the log: Deploying at end Then at the end of the successful mvn release:perform build, nothing gets uploaded despite the advance notice. As for your question: I do not use any Tycho/OSGi and no plugins with their own lifecycle that I would be aware of. Do you have any idea what I could have done wrong in order to trigger such a (non-)deployment behaviour during release:perform? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: CD versioning
Hi Benson,
you know that you can define the following properties since Maven 3.2.1[1]
${revision}, ${changelist} and ${sha1} which can be set outside from
Maven via:
mvn -Drevision=1.2.3-SNAPSHOT ...
and you can use it:
...
...
${revision}
..
in case of a multi module build you can also use it in the parent
definition of the children...
but there does not exist some kind of jar which generates the
version...as far as i know...
Kind regards
Karl Heinz Marbaise
[1]: http://maven.apache.org/docs/3.2.1/release-notes.html
On 1/20/16 1:11 PM, Benson Margulies wrote:
Some time ago, I recall some email about dynamic versioning; the idea
being that all the elements in all the POMs of the project
would look like ${version}, and a jar dropped into
the maven extensions directory would provide a component that would
generate the version, perhaps from a git hash or something like that.
Is there any doc around on how to set this up? Is it functional in
3.2.5?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: RuntimeInfo.init() not found
Hi, I assume you are building with Maven 3.2.X or newer ? Kind regards Karl Heinz Marbaise On 1/10/16 6:54 PM, Nulik Nol wrote: Hi, I am compiling a beta distribution of liferay7.0 and I have a problem with maven-ant-tasks.jar the method RuntimeInfo.init() does not exist in the jar but is required by the build process. The error I get when I build is this: BUILD FAILED /home/niko/lrdev/master/portal/build.xml:69: The following error occurred while executing this line: /home/niko/lrdev/master/portal/build.xml:329: The following error occurred while executing this line: /home/niko/lrdev/master/portal/build.xml:545: The following error occurred while executing this line: /home/niko/lrdev/master/portal/build-common.xml:900: java.lang.NoSuchMethodError: org.apache.maven.settings.RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V at org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:328) at org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278) at org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223) at org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212) at org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700) at org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110) at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272) at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570) ... There is also one error complaining about non-existent antlib.xml that is shown few lines above, but I think it manages to pass over it: log begins --- install-portal-snapshots: [antlib:org.apache.maven.artifact.ant] Could not load definitions from resource org/apache/maven/artifact/ant/antlib.xml. It could not be found. Class java.util.ArrayList loaded from parent loader (parentFirst) Class java.io.File loaded from parent loader (parentFirst) Finding class org.apache.maven.artifact.ant.AttachedArtifact Loaded from /home/niko/lrdev/master/portal/lib/development/maven-ant-tasks-2.1.3.jar org/apache/maven/artifact/ant/AttachedArtifact.class Class org.apache.maven.artifact.ant.AttachedArtifact loaded from ant loader (parentFirst) Finding class org.apache.maven.artifact.Artifact Loaded from /home/niko/lrdev/master/portal/lib/development/maven-ant-tasks-2.1.3.jar org/apache/maven/artifact/Artifact.class Class java.lang.Comparable loaded from parent loader (parentFirst) Class org.apache.maven.artifact.Artifact loaded from ant loader (parentFirst) Class org.apache.maven.model.Contributor loaded from parent loader (parentFirst) Class org.apache.maven.model.Dependency loaded from parent loader (parentFirst) Class org.apache.maven.model.DependencyManagement loaded from parent loader (parentFirst) Class org.apache.maven.model.Developer loaded from parent loader (parentFirst) Class org.apache.maven.model.IssueManagement loaded from parent loader (parentFirst) Class org.apache.maven.model.License loaded from parent loader (parentFirst) Class org.apache.maven.model.MailingList loaded from parent loader (parentFirst) Class org.apache.maven.model.Organization loaded from parent loader (parentFirst) Class org.apache.maven.model.Scm loaded from parent loader (parentFirst) Class org.apache.maven.model.DistributionManagement loaded from parent loader (parentFirst) Class org.apache.maven.model.Model loaded from parent loader (parentFirst) Finding class org.apache.maven.artifact.ant.Profile Loaded from /home/niko/lrdev/master/portal/lib/development/maven-ant-tasks-2.1.3.jar org/apache/maven/artifact/ant/Profile.class Class org.apache.maven.artifact.ant.Profile loaded from ant loader (parentFirst) Finding class org.apache.maven.project.MavenProjectBuilder Loaded from /home/niko/lrdev/master/portal/lib/development/maven-ant-tasks-2.1.3.jar org/apache/maven/project/MavenProjectBuilder.class Class org.apache.maven.project.MavenProjectBuilder loaded from ant loader (parentFirst) Finding class org.apache.maven.project.MavenProject Loaded from /home/niko/lrdev/master/portal/lib/development/maven-ant-tasks-2.1.3.jar org/apache/maven/project/MavenProject.class Class java.lang.Cloneable loaded from parent loader (parentFirst) Class org.apache.maven.project.MavenProject loaded from ant loader (parentFirst) Class org.apache.maven.model.Build loaded from parent loader (parentFirst) Class java.util.Properties loaded from parent loader (parentFirst) Class org.apache.maven.model.Parent loaded from parent loader (parentFirst) Class org.apache.maven.model.CiManagement loaded from parent loader (parentFirst) Class org.apache.maven.model.Reporting loaded from parent loader (parentFirst) Finding class
Re: AW: AW: AW: How to manage dependency "includes"?
HI, On 1/9/16 10:59 AM, Christofer Dutz wrote: Everyone that has worked for a Bank knows you can't > just go there and tell them what the standard is, > cause they'll tell you what their standard is ;-) Unfortunately true... So in the end we prohibited (by maven plugin) providing the version of third party libraries, > enforced the usage of a company-wide dependencyManagement pom > that is used in every project. Sounds like a good idea... > Additionally we enforced the rules of the dependency plugin to > declare used dependencies and not to rely on transitive dependencies. That is what i don't understand...where is the relationship to maven-dependency-plugin.May be i missed things here > With this a lot of our problems were solved. Which kind of problems...may be i missed things here... Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things, >and would it be ok to fix up a Pull request implementing that functionality? Hm...so you can do things like this (exclusion) single parts... group-a artifact-a 1.0 group-c excluded-artifact and since Maven 3.2.1 you exclude all transitive dependencies via: group-a artifact-a 1.0 * * ... Apart from that...an include does not make sense from my point of view cause this could lead to the impression that you you could add dependencies transitively..which makes no sense.. Furthermore changing the pom structure here would break all things This kind of changed could only be made (may be ...) in Maven 4??? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Combination of deployAtEnd and installAtEnd does not seem to work
Hi Alexander, On 1/9/16 2:13 PM, Alexander Kriegisch wrote: Hi community. This inquiry relates to [1] https://issues.apache.org/jira/browse/MRELEASE-664 [2] https://issues.apache.org/jira/browse/MDEPLOY-157 [3] https://issues.apache.org/jira/browse/MINSTALL-93 [4] https://issues.apache.org/jira/browse/MDEPLOY-168 where [2] and [3] are kinda spawned from [1] and [4] has not been implemented yet because it seems to be non-trivial at least, maybe complicated or even complex. Anyway, a combination of [2] and [3] should, as I understand the tickets, permit me to upload (deploy) my build artifacts to a repository manager only at the end of a successful multi-module build. Thus, I added this to my parent POM's pluginManagement section: org.apache.maven.plugins maven-install-plugin 2.5.2 true org.apache.maven.plugins maven-deploy-plugin 2.8.2 true I see artifacts being uploaded to the repository manager per module anyway. Am I doing anything wrong? If you have defined in pluginManagement be carefull no one overwrites that in the child pom or changes the plugin configuration and regrets the inherited part by using inherited false ...Furthermore use the correct versions... I'm using this for more than 2 years without any problems BUT are you using plain Maven or some kind of OSGi parts (like tycho) or other plugins which define their own lifecycle ? Can you show an log output of the build ? Or do you have an example project which shows that behaviour ? P.S.: Sorry to Karl Heinz for having asked this question in ticket [2], but I thought I had discovered an implementation bug. No problem... we will see if you have found an other bug or not... And general rule is to create a separate JIRA ticket and don't reopen closed tickets...if it's needed we will link to other tickets... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to use 5 digit version numbers with Maven ?
Hi, On 1/7/16 1:08 PM, Mehul Sanghvi wrote: We need to use 5 digit version numbers going forward. Maven only handles 3 digit version numbers where is this documented ? which is simply not true. https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning Since Maven 3 you can use as many version numbers as you like... using the versions-maven-plugin. Is there a way to use 5 digits for project.version ? What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and 1.2.3.4.5 vs 1.2.3 after the release. You should simply use itcause it works... Furthermore if you use Maven 3.2.5+ you can check the behaviour on command line via: (You have to change the maven-artifact-VERSION.jar accordingly to your Maven installation) this small CLI app which is included in your maven distribution: ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5-SNAPSHOT 1.0.2.6-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5-SNAPSHOT == 1.0.2.5-snapshot 1.0.2.5-SNAPSHOT < 1.0.2.6-SNAPSHOT 2. 1.0.2.6-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.0.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.0.0-SNAPSHOT == 1.0.2.5-snapshot 1.0.2.5.0.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.10.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.10.0-SNAPSHOT == 1.0.2.5.10-snapshot 1.0.2.5.10.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.100.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.100.0-SNAPSHOT == 1.0.2.5.100-snapshot 1.0.2.5.100.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: File Management Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: File Management Version 3.0.0. https://maven.apache.org/shared/file-management/ The Maven File Management API provides an API to collect files from a given directory using several include/exclude rules. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared file-management 3.0.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/file-management/download.cgi Release Notes File Management 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331511 Bugs: * [MSHARED-92] - Cannot retreive FileNameMapper with MapperUtil * [MSHARED-96] - Sample code is not working Improvements: * [MSHARED-265] - add fileset XML descriptor documentation generated from model * [MSHARED-399] - Upgrade to Maven 2.2.1 compatiblity * [MSHARED-400] - Upgrade maven-shared-utils to 0.7 * [MSHARED-401] - Remove dependency plexus-container-default:1.0-alpha-9-stable-1 * [MSHARED-462] - Upgrade JUnit Test Cases to new style (JUnit 4.11) * [MSHARED-467] - Upgrade Maven 3.X Only JDK 1.6 * [MSHARED-474] - Upgrade maven-shared-io to 3.0.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven Application Skin, Maven Classic Skin, Maven Stylus Skin
Hi Michael, here my +1.. Kind regards Karl Heinz Marbaise On 12/24/15 11:34 PM, Michael Osipov wrote: Hi, as previously suggested, it makes sense to retire those skins because they haven't been updated for a long time and we don't have the resources to maintain them properly [1]. Last releases: Maven Application Skin: 2012-01-18 Maven Classic Skin: 2012-01-18 Maven Stylus Skin: 2012-07-30 I therefore propose that we retire these skins. If this vote is successful I will make one final release of the skin, making it clear on the skin site that it has been retired. After that the source code will be moved into the "retired" area in our Subversion repository. The process for retiring a skin is described here: http://maven.apache.org/developers/retirement-plan-plugins.html (Though these aren't plugins, the process is universal) The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... I would ask kindly those who have already cast their vote to revote to make it "official". [1] http://mail-archives.apache.org/mod_mbox/maven-dev/201512.mbox/%3Ctrinity-8ab6577c-ab69-4f9f-86e6-533e0b309a94-1450902628141%403capp-gmx-bs54%3E - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Shared IO Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Shared IO Version 3.0.0. http://maven.apache.org/shared/maven-shared-io/ API for I/O support like logging, download or file scanning. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-shared-io 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/shared/maven-io/download.cgi Release Notes Maven Shared IO 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334278 Improvements: * [MSHARED-471] - Upgrade maven-shared-components parent to version 22 * [MSHARED-472] - Upgrade maven-shared-utils to 3.0.0 * [MSHARED-473] - Upgrade Maven 3.X Only JDK 1.6 * [MSHARED-476] - Removed the empty interface MultiChannelMessageHolder * [MSHARED-479] - Bump version to 3.0.0-SNAPSHOT Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] XML Maven Plugin 1.0.1
The MojoHaus team is pleased to announce the release of the XML Maven Plugin Version 1.0.1 http://www.mojohaus.org/xml-maven-plugin/. This Plugin is a collection of several XML related tasks. To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo xml-maven-plugin 1.0.1 Release Notes: https://github.com/mojohaus/xml-maven-plugin/issues?q=milestone%3A%22Release+1.0.1%22 Enjoy, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How Maven solves the problem of long builds on large projects?
Hi, On 12/21/15 1:53 PM, Sergey Saraev wrote: Hello! I am developing a project with 67 modules. I use Apache Maven 3.0.4. Reassembly of the project take 1 hour and 50 minutes although usually commit change only one module. You should use only: mvn clean install ... any other things like pmd, checkstyle etc. don't make sense in a usual build.. Furthermore have you taken a look how long the build time of the different modules is? What is the module with the longest time? How many tests do you run? How long do the tests take? I can give an impression of a large build (420 module) about 6500 tests, can be built in ca. 35 minutes ca. 580,000 lines of code...running (mvn clean deploy)... BTW: Why are you using such old plugin versions? (http://maven.apache.org/plugins/)... And of course on what kind of machine do you do the build? dedicated build machine? Kind regards Karl Heinz Marbaise The project is very large. It contains 5948 java classes (Basically, time spent on their compilation.). Build command: mvn clean install pmd:pmd checkstyle:checkstyle cobertura:cobertura Plugins versions: maven-compiler-plugin:2.3.2 maven-antrun-plugin:1.6 (use wlappc task: http://docs.oracle.com/cd/E21764_01/web./e13706/splitbuild.htm#WLPRG224) maven-surefire-plugin:2.10 maven-jar-plugin:2.3.2 maven-install-plugin:2.3.1 maven-pmd-plugin:2.7.1 maven-checkstyle-plugin:2.6 cobertura-maven-plugin:2.7 How to speed up the assembly? (Maybe skip modules, which sources have not changed or something else) Regards, Sergey Saraev | Research & Development | Office: +7 (846) 270-7800 ext. 2662 | Mobile: +7 (917) 813-5604 | --www.NetCracker.com-- Proven Partner to Communications Service Providers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Hijack mvn clean:clean to do file cleanup?
Hi Ben, you can define an execution with the id `default-cli` where you can configure the special filesSet for your purpose ...which you can execute from command line only via clean:clean... If you are in Maven 3.3.X+ you define several of them like this: org.apache.maven.plugins maven-clean-plugin default-cli ... second-cli ... now you can use: mvn clean:clean@default-cli mvn clean:clean@second-cli Kind regards Karl Heinz Marbaise On 12/17/15 7:36 PM, Ben Podgursky wrote: We have a problem where our build servers fill up with jar artifacts post-build (we have a lot of java builds). I was hoping to attach an execution of clean:clean with a custom after the deploy phase. However, I don't want to sweep the whole target/ directory, just the filesets I define, since we want to hold onto test results Is there any way to disable the automatic detection of project.build.directory, etc, and only delete custom filesets? Or is there another plugin/goal which would let me do this? I can write a mojo if I need to, but was hoping something was already out there. Thanks, Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [rpm-maven-plugin] how to control the name under which rpm is stored in m2 repository?
Hi Steve,
simply answer to this: It is not possible...
Long answer: Maven repositories dependending on an appropriate naming
schema to find artifacts / versions etc. If you change that the whole
system will not work at all..
So the name which is stored within a maven repository can't be changed.
Kind regards
Karl Heinz Marbaise
On 12/7/15 7:44 PM, Steve Cohen wrote:
Our organization has a convention for naming rpms. Typically, the rpm
will have a shorter base name than the Maven project. There is also a
convention around how releases are named. So we want a name
like|${shortname}-${project.version}-${release}.noarch.rpm|.
I want to build such rpms using the rpm-maven-plugin rather than older
nmake technology.
And this is easily accomplished using the plugin's parameters. The rpm
generated in the target directory has the desired name.
However, when|mvn install|installs this rpm into the maven repository,
it insists on storing it the "maven
way":|${project.artifactId}-${project.version}.rpm|
I want the rpm stored in the standard maven repository directory using
the name that is initially created on package.
I also tried using the maven-install-plugin (install-file goal) and did
not get the results I was after.
How may I accomplish this?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: how do i specify additional wagon plugins in the project pom to build deps when they don't yet exist in built form?
Hi, On 12/7/15 8:15 PM, james northrup wrote: I would like to intercepts maven repo requests and builds the ones that fit a certain pattern of buildable SCM repos, specifically using git[hub] repositories. Maven is based on binary artifacts and NOT on source artifacts... what pom options exist to control wagon so that a similar solution can be added to a parent pom to utilize plugin to build or exec when built dependencies are not yet installed in specified repositories. By default there does not exist such an machanism...for good reasons... Why you might can do use a EventSpy to intercept the repository request so you might can create an Maven extension which could handle that But you might take a look to this: https://github.com/l2x6/srcdeps-maven-plugin but from my point of view it will break all the advantages Maven has...which means you don't need to rebuild everything everytime... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] MojoHaus Templating Maven Plugin Version 1.0.0 Released
The MojoHaus team is pleased to announce the release of the Templating Maven Plugin Version 1.0.0 http://www.mojohaus.org/templating-maven-plugin/. The Templating Maven Plugin handles copying files from a source to a given output directory, while filtering them. This plugin is useful to filter Java Source Code if you need for example to have things in that code replaced with some properties values. To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo templating-maven-plugin 1.0.0 Release Notes: http://www.mojohaus.org/templating-maven-plugin/github-report.html Enjoy, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Running tests using failsafe from a shaded jar?
Hi Mirko,
The class DefaultClassRealmManager is contained in maven-core module..
@Named
@Singleton
public class DefaultClassRealmManager
implements ClassRealmManager
{
public static final String API_REALMID = "maven.api";
/**
* During normal command line build, ClassWorld is loaded by jvm
system classloader, which only includes
* plexus-classworlds jar and possibly javaagent classes, see
https://issues.apache.org/jira/browse/MNG-4747.
*
* Using ClassWorld to determine plugin/extensions realm parent
classloaders gives m2e and integration test harness
* flexibility to load multiple version of maven into dedicated
classloaders without assuming state of jvm system
* classloader.
*/
private static final ClassLoade
...
http://maven.apache.org/ref/3.0.5/maven-core/apidocs/org/apache/maven/classrealm/DefaultClassRealmManager.html
Kind regards
Karl Heinz Marbaise
On 11/21/15 10:20 PM, Mirko Friedenhagen wrote:
Hello,
I want to use to run tests on machine, where Maven is not installed
and access to a repository is not allowed.
However I want to (ab-)use the failsafe plugin so I may use the fine
machinery which allows to specify tests and get XML reports.
Using maven-embedded I created an App class which just runs
failsafe:integration tests, all dependencies are found in a shaded
jar.
I already used
org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
so a complete looking META-INF/plexus/components.xml is created.
When I start the jar with java -jar MY_SHADED_JAR.jar I always get the
following error:
22:09:57.365 [main] WARN Sisu - Error injecting:
org.apache.maven.project.DefaultProjectBuildingHelper
com.google.inject.ProvisionException: Unable to provision, see the
following errors:
1) No implementation for org.apache.maven.classrealm.ClassRealmManager
was bound.
while locating org.apache.maven.project.DefaultProjectBuildingHelper
Looking into components.xml DefaultClassRealmManager is not there but
is referenced twice.
Grepping through the components.xml files in a Maven installation, I
do not see where the DefaultClassRealmManager is instantiated.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Mapping Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Mapping Version 3.0.0. http://maven.apache.org/shared/maven-mapping/ The goal is to provide a shared component for all plugins that need to do mapping. Note: This component uses only Maven 3 dependencies and needs JDK 1.6 You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-mapping 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/shared/maven-mapping/download.cgi Release Notes Maven Mapping 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333967 Bug: * [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential thread safety issues Improvement * [MSHARED-356] - Upgrade to Maven 2.2.1 compatiblity * [MSHARED-357] - Update version of plexus-interpolation to 1.19 * [MSHARED-449] - Upgrade to Maven 3.X only + JDK 6 * [MSHARED-452] - Removed calling to accessor * [MSHARED-453] - Bump version to 3.0.0-SNAPSHOT * [MSHARED-457] - Upgrade maven-shared-components parent to version 22 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Version 3.3.9 Released
The Apache Maven team is pleased to announce the release of Apache Maven 3.3.9. http://maven.apache.org/ You can download the appropriate sources etc. from the download page http://maven.apache.org/download.cgi Release Notes - Apache Maven Version 3.3.9 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074 Code Contributors of this release: * Martin Schäf * Stuart McCulloch * sugartxy * Robert Stern * Florencia Tarditti * tssp * Dave Syer * Joseph Walton * Stephen Kitt * Anton Tanasenko * Tang Xinye * Ben Caradoc-Davies Issue Reporters of this release: * Brandon Enochs * Martin Schäf * Stephan Schroevers * Christian Schlichtherle * Brandon Enochs * Anders Forsell * Shubham Chaurasia * Keith Turner * Jonathan Radon * Ben Caradoc-Davies Many thanks to contributors and reporters for the support and time. Participants to VOTE of the Maven 3.3.4 till the Maven 3.3.9 Release: * Francisco Collao Gárate * Anton Tanasenko * Mark Derricut * Eric Barboni * Jieren * Jörg Schaible * Gary Gregory * Mark Derricut Many thanks to those who tested the Maven releases and thanks for their support as well. Bugs: * [MNG-5297] - Mark as deprecated for compile-time enforcement. (Contributor: Joseph Walton) * [MNG-5649] - Use Commons Lang's Validate to intercept invalid input * [MNG-5681] - Properties on command line with leading or trailing quotes are stripped * [MNG-5721] - Possible NullPointerException in org.apache.maven.repository.MetadataResolutionResult (reporter/contributor Martin Schäf ). * [MNG-5786] - Variable maven.multiModuleProjectDirectory may be set incorrectly (reporter Stephan Schroevers). * [MNG-5787] - Moving from Maven 3.0.5 to 3.3.3 breaks plugins with some dependencies on the class path (reporter Christian Schlichtherle). * [MNG-5796] - mvn fails when the current directory is a root drive on Windows (reporter Brandon Enochs). * [MNG-5812] - Project base dir not fully working in Cygwin (contributor tssp). * [MNG-5813] - Make MAVEN_OPTS env variable with mvnDebug correctly * [MNG-5816] - Empty maven.config cause Maven to exit with failure (contributor tssp) * [MNG-5840] - is used if the groupId and artifactId match irrespective of the version * [MNG-5858] - mvn script fails to locate .mvn in current directory (contributor Dave Syer). * [MNG-5877] - maven-aether-provider/maven-compat does not always generate snapshot versions using Gregorian calendar year (contributor Joseph Walton; reporter Anders Forsell). * [MNG-5882] - Nonportable shell constructs cause bin/mvn errors on Debian (contributor Ben Caradoc-Davies) * [MNG-5884] - mvn script doesn't handle directories containing spaces (contributor Stephen Kitt). * [MNG-5886] - Broken link of 'Building Maven' in README.md on Github (reporter Shubham Chaurasia). * [MNG-5891] - Log file command line option description contains an extra word (reporter Keith Turner). * [MNG-5898] - Multi-module build with ear fails to resolve war in 3.3.3 (reporter Jonathan Radon). * [MNG-5907] - org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight Improvements: * [MNG-5780] - upgrade Java minimum version prerequisite from Java 6 to Java 7 * [MNG-5805] - Custom packaging types: configuring DefaultLifecycleMapping mojo executions (contributor Anton Tanasenko). * [MNG-5818] - Disallow the programmatic injection of project dependencies * [MNG-5844] - Close IO Streams in finally or try-with-resource statement (contributor Tang Xinye) * [MNG-5871] - make url inheritance algorithm more visible * [MNG-5888] - Update used modello version from 1.8.1 to 1.8.3 * [MNG-5892] - Removing par lifecycle from default life cycle bindings * [MNG-5893] - Make used plugin version for maven-resources-plugin in default-bindings.xml consistent * [MNG-5894] - Removed binding for maven-ejb3-plugin from default binding * [MNG-5905] - Maven build does not work with Maven 2.2.1 * [MNG-5906] - Use canonical name for UTC timezone * [MNG-5911] - Upgrade maven-parent to version 27 * [MNG-5915] - Upgrade Wagon version to 2.10 * [MNG-5921] - Upgraded to plexus-components 1.6 that uses asm 5.x * [MNG-5922] - Upgrade plexus-utils to 3.0.22 to support combine.id as configuration attribute for Map merging * [MNG-5923] - Switch to official Guice 4.0 (reporter/contributor: Stuart McCulloch) * [MNG-5924] - Upgrade to Eclipse/Sisu 0.3.2 (reporter/contributor: Stuart McCulloch). * [MNG-5925] - Update animal-sniffer-maven-plugin to 1.14. MANIMALSNIFFER-49 required when building with JDK9 Task: * [MNG-5887] - update Modello site url Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Please reopen MNG-4533 Add an always active profile activator
Hi, On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote: Hi, could issue MNG-4533 "Add an always active profile activator" please be reopened? https://issues.apache.org/jira/browse/MNG-4533 The issues was automatically closed in 2014. I find the current workarounds to create an always active profile (check for non existing property, check for always existing file) quite ugly. The question is why do you need a profile which is always active ? In consequence i would ask why do you need a profile at all in such case? If it is always active you don't need a profile May be you can elaborate more what you like to achieve and what the use case is? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Please reopen MNG-4533 Add an always active profile activator
Hi,
On 11/14/15 10:06 PM, Arend v. Reinersdorff wrote:
Hi Karl Heinz,
good point. I'll try to elaborate more:
The idea is to have a profile which is always active, unless explicitly
deactivated. One can nearly achieve this with
true, but not quite because an
activeByDefault profile is deactivated if another profile from the same
pom.xml is activated.
So this is needed when:
- one profile should always be active, but can be turned off explicitly
- another profile can be activated, and activating it should not
deactivate the always active profile
Here's a concrete example. Solution taken from this answer on
Stackoverflow
http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945
- a multi module project
- normally all modules are included in a build
- in some cases certain modules (data-foo and data-bar) should be
excluded from the build (in the Stackoverflow question because the tests
took a long time,
Ok...starting with Maven 3.2.1[1] you can use things like this:
mvn -pl !moduleYouDontLikeToBuild package
So no need for a profile...I'm just quoting the answers which already
given on SO...
Apart from that if you have tests which run long you should think if
those tests are really unit- or integration tests...which means
different life cycle phases etc. and never activate/deactivate modules
via profiles[2]
[1]: http://maven.apache.org/docs/3.2.1/release-notes.html
[2]:
http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>
I was researching it to exclude modules from Javadoc
generation) The modules are excluded with "mvn -!Pfull-build"
The above can also be applied to exclude from JavaDoc ...I'm asking
myself why you like to exclude a module from JavaDoc generation but this
is a different story
- also, there's another profile to change the target directory.
Activating this should not interfere with module exclusion. "mvn
-PtargetInTemp clean install" should still build all modules.
common
foo
bar
full-build
pom.xml
data-foo
data-bar
targetInTemp
${env.TEMP}/${project.groupId}/${project.artifactId}
I don't understand why you need such thing (like different directory?)
and what is the reason for creating this kind of profile ? What is the
real problem behind this?
Kind regards
Karl Heinz Marbaise
Best regards,
Arend
On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:
Hi,
On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:
Hi,
could issue MNG-4533 "Add an always active profile activator"
please be
reopened?
https://issues.apache.org/jira/browse/MNG-4533
The issues was automatically closed in 2014.
I find the current workarounds to create an always active
profile (check
for non existing property, check for always existing file) quite
ugly.
The question is why do you need a profile which is always active ?
In consequence i would ask why do you need a profile at all in such
case? If it is always active you don't need a profile
May be you can elaborate more what you like to achieve and what the
use case is?
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
<mailto:users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
<mailto:users-h...@maven.apache.org>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] MojoHaus Properties Maven Plugin Version 1.0.0 Released
The MojoHaus Team is pleased to announce of the Properties Maven Plugin Version 1.0.0 http://www.mojohaus.org/properties-maven-plugin/ The Properties Maven Plugin is here to make life a little easier when dealing with properties. It provides goals to read properties from files and URLs and write properties to files, and also to set system properties. You should specify the version in your projects dependencies: org.codehaus.mojo properties-maven-plugin 1.0.0 Release Notes for the Properties Maven Plugin Version 1.0.0 http://www.mojohaus.org/properties-maven-plugin/github-report.html We have two contributors for this release. Reporter: * puntogil: Issue #2 properties-maven-plugin does not include the license file. Reporter and contributor: * kreyssel: Issue #15 add m2e lifecycle mapping for 'write-project-properties' Many thanks for the reporters and contributors. Enjoy, - The MojoHaus Team Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-plugin-testing-harness: NoClassDefFoundError: org/apache/maven/execution/MavenExecutionRequest
Hi, On 11/13/15 2:23 PM, org.apache.maven.u...@io7m.com wrote: On 2015-11-13T10:03:54 + <org.apache.maven.u...@io7m.com> wrote: Hello. I'm attempting to add a Maven plugin to a small compiler project: Here's a tiny repro case. https://github.com/io7m/mvn-bug-20151113 Why are you using this: org.apache.maven maven-plugin-api 2.0 Better use at least version 3.0 of this... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Locking down dependency versions...
Hi Kevin, On 11/12/15 10:22 PM, Kevin Burton wrote: Is there a maven module that can lock down dependency versions? Are you talking about SNAPSHOT's or something different? I have a custom / in house script we wrote that writes a .dependencies file with the jar dependencies. If we commit without updating it, CI will fail with an error because you didn't manually approve the change by regenerating the .dependencies file. This way we don't have to worry about a radical dependency change due to a new dependency breaking our tree. The problem is I'm starting to break off our code into sub-projects and I'd like to use this everywhere. Kevin Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Locking down dependency versions...
Hi Kevin,
On 11/12/15 11:00 PM, Kevin Burton wrote:
Just regular dependency versions.
So if we're using 1.0.1 of library A I don't want adding adding library
B to transitively change our dependency on library A...
If you have a direct dependency to library A in version 1.0.1 than
adding an other lib B which has a dependency to library A in version
2.0.0 your project will use 1.0.1...(the shorter the distance the more
important such an dependency is)...
So i don't see the point or do i misunderstand a thing?
Kind regards
Karl Heinz Marbaise
This has happened to us before and caused problems.
On Thu, Nov 12, 2015 at 1:40 PM, Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:
Hi Kevin,
On 11/12/15 10:22 PM, Kevin Burton wrote:
Is there a maven module that can lock down dependency versions?
Are you talking about SNAPSHOT's or something different?
I have a custom / in house script we wrote that writes a
.dependencies file
with the jar dependencies.
If we commit without updating it, CI will fail with an error
because you
didn't manually approve the change by regenerating the
.dependencies file.
This way we don't have to worry about a radical dependency
change due to a
new dependency breaking our tree.
The problem is I'm starting to break off our code into
sub-projects and I'd
like to use this everywhere.
Kevin
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
<mailto:users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
<mailto:users-h...@maven.apache.org>
--
We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!
Founder/CEO Spinn3r.com <http://Spinn3r.com>
Location: *San Francisco, CA*
blog:**http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Filtering Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Filtering Version 3.0.0. http://maven.apache.org/shared/maven-filtering/ The goal is to provide a shared component for all plugins that needs to filter resources. Important Notes: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your projects dependencies: org.apache.maven.shared maven-filtering 3.0.0 You can download the appropriate sources etc. from the download page: http://maven.apache.org/shared/maven-filtering/download.cgi Release Notes Maven Shared Filtering component Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331472 Bug: * [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential thread safety issues Improvements: * [MSHARED-367] - Fixed Checkstyle reported errors / warnings * [MSHARED-370] - Text on the main page should be changed * [MSHARED-371] - Increase chance of java8 compliance by updating to plexus-component-* 1.6 * [MSHARED-378] - Upgrade maven-shared-utils to 0.7 * [MSHARED-441] - Upgrade maven-shared-utils to 3.0.0 * [MSHARED-451] - Upgrade Maven 3.0 + JDK 6 * [MSHARED-454] - Removed hard code version for maven-changes-plugin * [MSHARED-455] - Update to new maven-shared-components parent pom version 22 * [MSHARED-463] - Upgrade to annotation based usage instead of XDoclet * [MSHARED-464] - Upgrade user documentation Task: * [MSHARED-456] - Removed @Deprecated marked code Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven stops building class files after Enum file added to project.
Error messages ? Log output ? Kind regards Karl Heinz Marbaise On 11/9/15 7:59 PM, Jarl wrote: The build succeeds but the target/classes directory is empty of any class files. -Jarl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven stops building class files after Enum file added to project.
Hi, those lines: [INFO] Assembling webapp [myProject] in [C:\myProject\target\myProject-2.1.0] [INFO] Processing war project [INFO] Copying webapp resources [C:\myProject\src\main\webapp] [INFO] Webapp assembled in [661 msecs] [INFO] Building war: C:\apache-tomcat-7.0.64\webapps\myProject-2.1.0.war [INFO] look strange cause building the war is a different folder than building the rest of the project... Have you tested to do a mvn clean ... before doing mvn package ? Kind regards Karl Heinz Marbaise On 11/9/15 8:13 PM, Jarl wrote: No error messages. [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ myProject--- [INFO] Changes detected - recompiling the module! [INFO] Compiling 295 source files to C:\myProject\target\classes [INFO] [INFO] --- maven-war-plugin:2.3:war (default-war) @ myProject--- [INFO] Packaging webapp [INFO] Assembling webapp [myProject] in [C:\myProject\target\myProject-2.1.0] [INFO] Processing war project [INFO] Copying webapp resources [C:\myProject\src\main\webapp] [INFO] Webapp assembled in [661 msecs] [INFO] Building war: C:\apache-tomcat-7.0.64\webapps\myProject-2.1.0.war [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ myProject--- [INFO] Installing C:\apache-tomcat-7.0.64\webapps\myProject-2.1.0.war to C:\Users\admin\.m2\repository\com\nsb\myProject\myProject\2.1.0\myProject-2.1.0.war [INFO] Installing C:\myProject\pom.xml to C:\Users\admin\.m2\repository\com\nsb\myProject\myProject\2.1.0\myProject-2.1.0.pom [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 8.935 s [INFO] Finished at: 2015-11-09T19:47:32+01:00 [INFO] Final Memory: 23M/224M On 11/9/2015 8:04 PM, Karl Heinz Marbaise wrote: Error messages ? Log output ? Kind regards Karl Heinz Marbaise On 11/9/15 7:59 PM, Jarl wrote: The build succeeds but the target/classes directory is empty of any class files. -Jarl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Components POM Version 22 Released
The Apache Maven team is pleased to announce the release of Apache Maven Shared Components POM Version 22. http://maven.apache.org/pom/maven-shared-components/ Release Notes - Maven POMs - Version MAVEN-SHARED-22 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12328931 Bug: * [MPOM-88] - yyy-LATEST deployment URL breaks site parent reference menu Improvement: * [MPOM-91] - Use fluido skin Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Solaris
Hi, Maven 3.3.X needs Java 1.7 ... will not help... You need to stuck with Maven 3.2.5 ...or you need to install Java 7 and may be you need to configure toolchain... Kind regards Karl Heinz Marbaise On 11/4/15 8:12 PM, james pruett wrote: This is all I can figure out as to what pieces of java my box has... Thanks for helping! $/usr/bin/javac -version javac 1.6.0_91 $ /usr/bin/java -version java version "1.6.0_91" Java(TM) SE Runtime Environment (build 1.6.0_91-b13) Java HotSpot(TM) Server VM (build 20.91-b07, mixed mode) $ ls -las java* 1 lrwxrwxrwx 1 root other 16 Mar 12 2015 java -> ../java/bin/java 1 lrwxrwxrwx 1 root other 17 Mar 12 2015 javac -> ../java/bin/javac 1 lrwxrwxrwx 1 root other 19 Mar 12 2015 javadoc -> ../java/bin/javadoc 1 lrwxrwxrwx 1 root other 17 Mar 12 2015 javah -> ../java/bin/javah 1 lrwxrwxrwx 1 root other 17 Mar 12 2015 javap -> ../java/bin/javap 1 lrwxrwxrwx 1 root other 18 Mar 12 2015 javaws -> ../java/bin/javaws $ pwd /usr/java/jre/bin $ ls ControlPanel java_vm jcontrol orbd policytool rmiregistry sparcv9 unpack200 java javawskeytool pack200 rmid servertooltnameserv - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Solaris
Hi James, point JAVA_HOME to ...whatever/jdk1.7.0_79/ Kind regards Karl Heinz Marbaise On 11/4/15 8:27 PM, james pruett wrote: I downloaded jdk1.7 binaries for Sparc 64bit. $ find . -name bin ./jdk1.7.0_79/bin ./jdk1.7.0_79/jre/bin Q: Do I just point JAVA_HOME to one of those? Thanks again! jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Solaris
Hi,
On 11/4/15 7:55 PM, james pruett wrote:
Hi again,
I am trying to use maven from Solaris and get this error.
Thanks for helping.
-jim
$ ../../maven/apache-maven-3.3.3/bin/mvn clearn install -f pom.xml -N
Exception in thread "main" java.lang.UnsupportedClassVersionError:
org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0
That looks you are using not Java 1.7+ JDK
Kind regards
Karl Heinz Marbaise
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at
org.codehaus.plexus.classworlds.launcher.Launcher.getMainClass(Launcher.java:144)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:266)
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)
On Wed, Nov 4, 2015 at 11:00 AM, Andrew Todd <andrew.todd...@gmail.com>
wrote:
See https://issues.apache.org/jira/browse/MNG-5852
This has happened in several releases -- Maven developers need to switch
their hashbang to #!/usr/bin/env bash or otherwise actually test against a
Bourne shell.
On Wed, Nov 4, 2015 at 11:29 AM, Dan Tran <dant...@gmail.com> wrote:
you may want to link your /bin/sh to bash
-D
On Wed, Nov 4, 2015 at 8:20 AM, james pruett <gpscru...@gmail.com>
wrote:
Hi,
I am compiling maven on Solaris. apache-maven-3.3-3.bin.tar.gz
My environment is:
echo $0
tcsh
I get this error
/apache-maven-3.3.3/bin % ./mvn
./mvn: syntax error at line 200: `(' unexpected
line 200 says: local basedir=($pwd)
Any help appreciated!
Jim
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jdeps-plugin RFEs
Hi, JIRA will do a restart on 6.11.2015 afterwards the new project is available...(Yes for this plugin)...http://status.apache.org/ (Upcoming maintenance link)... On 11/3/15 7:31 PM, jieryn wrote: Since there isn't yet a project to report issues, I was informed to report issues here. Would be nice to have a skip option so we can configure the plugin to run in a high level POM, and then case by case skip it where we need. Also, there seems to be quite a lot of output. It would be nice if we could just have the errors reported without all the extra package/class output. Finally, that output itself is not grepable, so it's kind of spammy and then won't play nice with tools for processing a lot of data. Maybe a report mojo? Looks cool, love this stuff, thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jdeps-plugin:3.0.0 site
Hi, On 10/30/15 6:14 PM, jieryn wrote: I'm sorry, it looks like I double pasted the URLs. No problem.. http://maven.apache.org/plugins/maven-jdeps-plugin/issue-tracking.html links to https://issues.apache.org/jira/browse/MJDEPS which says the project does not exist. I want to file a couple of issues for this plugin. I can not find where to file the issues. Thanks! Yeah that's unfortunately true... I have filed in a issue[1] for infrastructure team to create the appropriate jira project ... In the meantime you can report the issues you have simply here on the user list Kind regards Karl Heinz Marbaise [1]: https://issues.apache.org/jira/browse/INFRA-10694 On Fri, Oct 30, 2015 at 12:31 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, On 10/30/15 3:14 PM, jieryn wrote: The site for the m-jdeps-p ( https://issues.apache.org/jira/browse/MJDEPS ) is broken for the Issues page. It links to https://issues.apache.org/jira/browse/MJDEPS which doesn't exist. Can you be a little bit more specific what does not work?.. I have checked here from germany no problem...just fine... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jdeps-plugin:3.0.0 site
Hi, On 10/30/15 3:14 PM, jieryn wrote: The site for the m-jdeps-p ( https://issues.apache.org/jira/browse/MJDEPS ) is broken for the Issues page. It links to https://issues.apache.org/jira/browse/MJDEPS which doesn't exist. Can you be a little bit more specific what does not work?.. I have checked here from germany no problem...just fine... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin Version 2.4.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 2.4.2. This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. https://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 2.4.2 You can download the [appropriate sources etc. from the download page](http://maven.apache.org/plugins/maven-shade-plugin/download.cgi). Release Notes - Apache Maven Shade Plugin Version 2.4.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008 Bugs: * [MSHADE-172] - "java.lang.ArithmeticException: / by zero" in MinijarFilter * [MSHADE-190] - Shade does not relocate the contents of META-INF/services files * [MSHADE-209] - [REGRESSION] "java.lang.ArithmeticException: / by zero" in MinijarFilter (reporter Jon McLean). Improvements: * [MSHADE-205] - Better use of ClazzpathUnit for improved jar minimization (contribution of Benoit Perrot). * [MSHADE-207] - Replace wrong link to codehaus with correct location * [MSHADE-210] - Upgrade maven-plugins parent to version 28. * [MSHADE-211] - Keep Java 1.5 Enjoy, The Apache Maven team Thanks to contributors and reporters. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Clean Plugin Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Clean Plugin Version 3.0.0. The Clean Plugin is used when you want to remove files generated at build-time in a project's directory. Important Notes: * Maven 3.X only * JDK 6 minimum requirement https://maven.apache.org/plugins/maven-clean-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-clean-plugin 3.0.0 Release Notes - Apache Maven Clean Plugin Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12330417 Improvements: * [MCLEAN-56] - Make Plugin only 3.X compatible - get rid of Maven 2. * [MCLEAN-62] - Upgrade to maven-plugins parent version 27 * [MCLEAN-63] - Make naming of properties consistent * [MCLEAN-65] - Bump version to 3.0.0 * [MCLEAN-66] - Upgrade maven-shared-utils to 0.9 * [MCLEAN-67] - Change package name to org.apache.maven.plugins * [MCLEAN-69] - Upgrade maven-shared-utils to 3.0.0 Enjoy, The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.0.0. The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. Important Notes: * Maven 3.X only * JDK 6 minimum requirement http://maven.apache.org/shared/maven-shared-utils/ You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-archiver 3.0.0 Release Notes - Apache Maven Shared Utils - Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333673 Improvements: * [MSHARED-380] - Fix Checkstyle reported errors/warnings * [MSHARED-387] - Upgrade plexus-archiver from 2.8.1 to 2.9 * [MSHARED-438] - Use Maven 3.0 Dependencies * [MSHARED-445] - Upgrade maven-shared-utils 3.0.0 * [MSHARED-446] - Upgrade version to 3.0.0-SNAPSHOT * [MSHARED-447] - Use fluido skin 1.4 Enjoy, The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cannot seem to install Maven on Windows 7 64-bit
Hi, first dont use "maven --version" as command cause maven will be called by: "mvn --version" instead... Furthermore you should not use MAVEN_HOME environment variable...only add the bin folder of the distribution (apache-maven-3.3.3/bin) to the PATH of your windows system Don't forget to close and reopen the console...and then check it... Kind regards Karl Heinz Marbaise On 10/15/15 9:45 PM, Cai Black wrote: [RESOLVED] OK, so, apparently this is an issue with Maven 3.3.3, and when I downgraded to Maven 3.2.5, everything worked as expected. Christopher (Cai) Black Mgr. Software Development RigNet 1880 S. Dairy Ashford, Suite 300 | Houston, TX 77077- 4760 | USA Tel: +1.281.674.0717 | Mobile: +1.832.439.8134 | Fax: +1.281.674.0101 Email: christopher.bl...@rig.net<mailto:christopher.bl...@rig.net> www.rig.net<http://www.rig.net/> From: Cai Black Sent: Thursday, 15 October 2015 14:22 To: 'users@maven.apache.org' Subject: Cannot seem to install Maven on Windows 7 64-bit Hi, all. I did the following: * installed jdk-8u60-windows-x64 "java -version" output: C:\>java -version java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) * extracted the ZIP into C:\maven * added the following environment variable: MAVEN_HOME = C:\maven * appended the following to the PATH: %MAVEN_HOME%\bin "maven -version" outputs the same thing as "java -help" instead of the expected "Apache Maven 3." stuff. Any thoughts here? Christopher (Cai) Black Mgr. Software Development RigNet 1880 S. Dairy Ashford, Suite 300 | Houston, TX 77077- 4760 | USA Tel: +1.281.674.0717 | Mobile: +1.832.439.8134 | Fax: +1.281.674.0101 Email: christopher.bl...@rig.net<mailto:christopher.bl...@rig.net> www.rig.net<http://www.rig.net/> *** Important Notice * This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with RigNet. RigNet reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Shared Utils Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Shared Utils Version 3.0.0. This project aims to be a functional replacement for plexus-utils in Maven. It is not a 100% API compatible replacement though but a replacement with improvements: lots of methods got cleaned up, generics got added and we dropped a lot of unused code. Important Notes: * Maven 3.X only * JDK 6 minimum requirement http://maven.apache.org/shared/maven-shared-utils/ You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-shared-utils 3.0.0 Release Notes - Apache Maven Shared Utils - Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333677 Bug: * [MSHARED-444] - Make the optional dependency (commons-io) to a usual dependency Improvements: * [MSHARED-439] - Upgrade to Maven 3.0 dependencies and JDK6 * [MSHARED-440] - Bump version number to 3.0.0 * [MSHARED-442] - Remove shading of artifact instead of using simple jar * [MSHARED-443] - Use fluido skin for site. Enjoy, The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven site plugin, turn off copyright notice
Hi, On 10/13/15 9:45 PM, Alex O'Ree wrote: Is there a way to turn off the copyright notice on the bottom of generated maven sites? Which of them do you mean exactly ? Can you show an example and mark which you mean? Which skin do you use? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven site plugin, turn off copyright notice
Hi, On 10/13/15 9:57 PM, Alex O'Ree wrote: I think I figured it out. It was being injected into the footer. Overriding the footer in the site descriptor appears to have suppressed it. Took me a few minutes to find the solution in the source, but did see it referenced anywhere on the maven site plugin's website Hm... http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Custom_footer might need an improvement? ... Kind regards Karl Heinz Marbaise On Tue, Oct 13, 2015 at 3:55 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, On 10/13/15 9:45 PM, Alex O'Ree wrote: Is there a way to turn off the copyright notice on the bottom of generated maven sites? Which of them do you mean exactly ? Can you show an example and mark which you mean? Which skin do you use? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy-dependencies goal error
Hi Michael, > With all due respect I insulted no one. Am I frustrated? Yes, but I did not insult anyone. Now I was perfectly fine with letting this go until I received your comment. > So let me use this opportunity to make a few more comments. Thank you for suggesting That I go somewhere else for help. > However, this is the Maven mailing list set up for the express > purpose of getting help with this software. it is absolutely intended to ask here and I'm your opinion, cause this is User Mailing list... Where else do you suggest I go? Very good question...Unfortunately i haven't got a idea to suggest... As for the volunteer service you provide, I thank you for that service. > But when I am dissatisfied with the service I am getting, > please don't throw in my face that you are a volunteer. > You made that choice. > And as a result, putting up with frustrated customers > is something you are going to have to deal with. > It's part of the deal you signed on to when you volunteered. > If you are not willing to do that, > then maybe you should consider not volunteering. Yes exactly the point. If those who ansered here and don't like to answer or if they are the opinion to waste their time..than really keep quiet..and let others do the job... Now I was told by a responder on this thread that I > am not a customer because I did not pay for this software. > Nothing could be further from the truth. There is no one paying for Maven it self... > In my career I had many "customers" that did not pay for > the software I was supporting. > It was my job to provide them the best support that I could. > I suggest that responders to requests for help on this > mailing list adopt the same approach, volunteer or not. Yes...true... Another responder to this thread brought up that > he was volunteering and I was wasting his time. If the original poster is wasting his/here time than just simply don't do it anymore... > How about the time of mine he wasted when he suggested > I try something that made no difference in the outcome, > and had nothing to do with the problem? > And this has happened to me before with other > responders on this mailing list. >I was in fact told by another responder that the reply of a specific person > was off topic and is often the case for that person. Maybe you should spend some time pointing that out to those individuals > rather than chastising someone who is simply trying to get help. Regards, Mike I'm really sorry Michael to read such things in the user mailing list which is intended for people using Maven and searching for help and usage of Maven. To be honest if someone on the user list is the opinion to waste here/his time just simple keep quiet...or better unsubscribe from the list... Maven is an open source project which lives from its community...and unfortunately i have to say that is not a good attitude of a "community" against a user....who searches for help... I never thought i need to write something like this Kind regards Karl Heinz Marbaise Apache Maven PMC Member - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy-dependencies goal error
Hi Michael, I'm replying to Jörg... Kind regards Karl Heinz Marbaise On 10/6/15 12:14 AM, michael.ctr.taru...@faa.gov wrote: Karl, Could you clarify this. I don't understand your reply. In fact I'm not sure if you are replying to me or Jorg. It appears to be the latter. Could you please confirm? Thank you. Michael Tarullo Contractor (Engility Corp) Enterprise Architect NSRR System Administrator FAA WJH Technical Center (609)485-5294 -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Monday, October 05, 2015 6:10 PM To: Maven Users List Subject: Re: Copy-dependencies goal error Hi, On 10/5/15 7:51 PM, Jörg Schaible wrote: Hi Michael, michael.ctr.taru...@faa.gov wrote: My apology about part of this reply. I did not understand part of your suggestion. I thought you were saying 3.0.5 is the latest release. That said, I don't see how using the latest release or an older release makes any difference. I have a requirement to use 3.1.1 from a COTS product vendor, so that is probably not an option. And "bogus" is just not a good enough explanation for me. What specifically is wrong with what I am doing that does not work in this release? I just cite my original mail: IIRC you have problems with 3.1.x when using dependencies with import scope, because it ignores then your settings then for transitive deps declaring their own repository in the POM. AFAICS, you are using dependencyManagement with dependencies declared with scope "import"". The given pom does not contain any dependencyManagement...so it does simply plays not a role here...Apart from that import scope means only to use the dependencyManagement part and nothing else as described in the documentation...so it does not ignore it nor is it wrong... See the original documentation https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html. so this is NOT a problem in contrary it is exactly working as it should be...Apart from using repository definition in a pom is a bad practice...But this is a different story... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy-dependencies goal error
Hi, On 10/5/15 7:51 PM, Jörg Schaible wrote: Hi Michael, michael.ctr.taru...@faa.gov wrote: My apology about part of this reply. I did not understand part of your suggestion. I thought you were saying 3.0.5 is the latest release. That said, I don't see how using the latest release or an older release makes any difference. I have a requirement to use 3.1.1 from a COTS product vendor, so that is probably not an option. And "bogus" is just not a good enough explanation for me. What specifically is wrong with what I am doing that does not work in this release? I just cite my original mail: IIRC you have problems with 3.1.x when using dependencies with import scope, because it ignores then your settings then for transitive deps declaring their own repository in the POM. AFAICS, you are using dependencyManagement with dependencies declared with scope "import"". The given pom does not contain any dependencyManagement...so it does simply plays not a role here...Apart from that import scope means only to use the dependencyManagement part and nothing else as described in the documentation...so it does not ignore it nor is it wrong... See the original documentation https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html. so this is NOT a problem in contrary it is exactly working as it should be...Apart from using repository definition in a pom is a bad practice...But this is a different story... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 deploy snapshot and multi module
Hi, On 10/5/15 6:24 PM, Bob Hpv wrote: Dear all, I was using maven 2 and the unique version for SNAPSHOT deployment. Which version of Maven 2 have you used ? 2.2.1 ? In this configuration if I deploy a multi-module project, I had a single timestamp for all the modules which was very useful when we wanted to use one fixed SNAPSHOT. Sounds like you don't use a repository manager ? I upgraded recently to maven 3. Which version of Maven 3 ? 3.0.5, 3.1.1, 3.2.5, 3.3.3 ? With maven 3, we see that the timestamps are different for each module and it is now more complicated to use a fixed snapshot. How can I fallback to the maven2 behavior with maven3 ? Regards Bob - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy-dependencies goal error
Hi, On 10/5/15 6:07 PM, Jörg Schaible wrote: latest Maven version or 3.0.5, > because 3.1.1. is bogus. Can you tell me in which way 3.1.1 is bogus ? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: errors when using release:update-versions
Hi, On 10/5/15 6:19 PM, Mehul Sanghvi wrote: I am trying to use the following: mvn -V -B release:update-versions -DdevelopmentVersion=1.2.3.4-SNAPSHOT and it keeps coming back with the following: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:update-versions First you are using an ancient version of the maven-release-plugin[2]you should define the version by using a pluginManagement in a corporate pom file... (default-cli) on project FUBAR: Missing required setting: scm connection or developerConnection must be specified. We do not use the maven scm plugin. The POMs are all checked out locally on my system, and ready for editing. So why is it complaining about the scm connection and developerConnection ? I tried to google and read the documents, but I am most likely missing someting in my interpretation of things. You have to define the scm connection[1] information into your pom's: for example like this: scm:svn:http://127.0.0.1/svn/my-project scm:svn:https://127.0.0.1/svn/my-project If you like to use maven-release-plugin you have to define those informations in the pom file. [1]: https://maven.apache.org/pom.html#SCM [2]: http://maven.apache.org/maven-release/maven-release-plugin/ Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a cache of version range resolutions?
Hi, On 10/2/15 11:06 PM, Benson Margulies wrote: I've just tried version ranges for the first time, and I hit a pothole. Step 1: set version in dependency to: 7.14.0.c52.2. Run a build. Step 2: change version in pom to [7.13.500.c52.2,7.13.600.c52.2). Now, mvn dependency:whatever shows the correct resolution, but an actual build stubbornly uses the 7.14.0.c52.2 version in the karaf-maven-plugin. Which Maven version do you use? Kind regards Karl Heinz Marbaise Completely wiping ~/.m2/repository fixed this. Can anyone give me higher-precision coordinates for what data I need to nuke when this happens? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor projects and ${project.version}
Hi,
On 9/16/15 1:50 AM, Jordan Zimmerman wrote:
Is there any way (using plugins, whatever) to get a stable reference to the
root project version? Here is what I’m trying to do. I have a reactor project:
pom.xml
module1/pom.xml
module2/pom.xml
The wrinkle is that the root pom.xml has a parent (for example foo:bar:1.2).
> foo.bar has several of its own modules that I want to use.
> So, in the root pom.xml I want to have a dependency from foo,
> in module1’s pom I want to have a dependency from foo etc.
If you are making a multi module build you can always use
${project.version} ...? Can you make an example project of what you have
tried and put it on github or something similar that we have something
concrete where we can talk about...
Kind regards
Karl Heinz Marbaise
>
There seems to be no way to create a Maven property that matches foo’s
version. If in the root pom I have:
${project.parent.version}
This won’t work in module1/2’s pom as it will reference the root pom’s version,
not foo. The only thing that works is to hard code:
1.2
But this means that I’m specifying foo’s version twice. Once in the parent tag
and once as a property. Is there no way around this?
-Jordan
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Upgrading to 3.3.3
Hi, if you call via Ant script? Why? Special requirement ? Are you on Windows or Linux ? Do you call the "mvn.bat" or "mvn.cmd" file ? Do you call the file from the distribution ? Apart from that the property is intended to find the root folder of a multi module build where the ".mvn" folder can be located... See Release notes for more details on it... http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/ Maven-Ant-Task has not been updated for Maven 3.3.X as far as i know... Kind regards Karl Heinz Marbaise On 9/14/15 5:14 PM, David Hoffer wrote: We are attempting to upgrade our CI builds to use Maven 3.3.3 but are getting new errors with that version (3.2.5 worked). The error is: -Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME environment variable and mvn script match. This only seems to be an issue with some of our builds, specifically the ones where the top level build is an Ant script that calls Maven via maven-ant-tasks. What is this new property multiModuleProjectDirectory, why was it added and how do I fix this? The online links on this issue seem vague and point to updates needed in Eclipse and IntelliJ but in my case there is no IDE just a CI build. Any help is greatly appreciated. -Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Upgrading to 3.3.3
Hi David, On 9/14/15 5:57 PM, David Hoffer wrote: The reason for the Ant script is historical. It's a very large project that back in the day was 100% Ant. Over time portions were migrated to Maven, the only way to integrate with the larger Ant script is with Maven-Ant-Task. Today all the developer builds are pure maven but most of the CI builds have to do more than that...build installers, build ISO images, etc. Unfortunately those other tasks are still Ant. I would say it's time to migrate...and leave Ant for Maven related thingsCan you tell me what kind of installers ? ISO image ? As far as i remember there is a maven plugin which creates iso images (Stephen Connolly has written something like that if my memory does not mistaken me)... We don't have any '.mvn' folders. Shouldn't multiModuleProjectDirectory just default to the same folder that has the top level pom? Yes in this case it is exactly that way...you should add property set in your ant task to define the property...that should fix the problem...but i'm not sure if this will fix it completely...why don't you call "mvn.cmd" or "mvn" from the ant task... So wait a moment...you are using Maven Ant Tasks to call maven? Sounds strange ...why not directly calling Maven... >Not clear why pure maven build works w/o setting multiModuleProjectDirectory but not when using Maven-Ant-Task. The difference is that pure Maven the property is set by the calling scripts ( mvn / mvn.cmd)...which will identify the root folder of a multi module build...and the Maven Ant Task does not know anything about that property... We don't call "mvn.bat" or "mvn.cmd" directly as that must be handled by Maven-Ant-Task. Yes that's your issue, cause Maven Ant Task hasn't been updated/releases for a long time...and especially for Maven 3.3.X not...if you like to provide a patch ;-) ..? > I wondered if the change from bat to cmd was the cause of the problem, still not sure. Not the change from .bat to .cmd...The change from bat to cmd was only to leave Win95 support... The point is the usage for the root folder to find ".mvn" folder...which is needed cause the configuration (maven.config) is located there and jvm configuration (jvm.config) and extensions (extensions.xml) are being loaded from there... > I did see that Maven-Ant-Task has not been updated in quite some time, it's unfortunate if it needs to be updated for Maven 3.3.3 and not just work the same as prior versions. The problem is that sometimes things needed to be changed...yes it is unfortunate... To be honest there had been several discussions to resign the Maven-Ant-Tasks and the maven-antrun-plugin Are you aware of the need of Java 7 for Maven 3.3.X ? Are you saying that 3.3.3 isn't going to work with Maven-Ant-Task? At the moment no one is working ont Maven Ant Task...which means in other words at the moment Yes. > If so we will have to stay with 3.2.5 until that's updated or we can replace our remaining Ant builds...but that isn't likely to happen soon. The questions is what exactly prevents you from updating..which tasks do you use ? I assume you use it within CI (Jenkins presumably?)... Kind regards Karl Heinz Marbaise -Dave On Mon, Sep 14, 2015 at 9:31 AM, Karl Heinz Marbaise <khmarba...@gmx.de <mailto:khmarba...@gmx.de>> wrote: Hi, if you call via Ant script? Why? Special requirement ? Are you on Windows or Linux ? Do you call the "mvn.bat" or "mvn.cmd" file ? Do you call the file from the distribution ? Apart from that the property is intended to find the root folder of a multi module build where the ".mvn" folder can be located... See Release notes for more details on it... http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/ Maven-Ant-Task has not been updated for Maven 3.3.X as far as i know... Kind regards Karl Heinz Marbaise On 9/14/15 5:14 PM, David Hoffer wrote: We are attempting to upgrade our CI builds to use Maven 3.3.3 but are getting new errors with that version (3.2.5 worked). The error is: -Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME environment variable and mvn script match. This only seems to be an issue with some of our builds, specifically the ones where the top level build is an Ant script that calls Maven via maven-ant-tasks. What is this new property multiModuleProjectDirectory, why was it added and how do I fix this? The online links on this issue seem vague and point to updates needed in Eclipse and IntelliJ but in my case there is no IDE just a CI build. Any help is greatly appreciated. -Dave
Re: Upgrading to 3.3.3
Hi David, On 9/14/15 7:20 PM, David Hoffer wrote: Thanks for the info...that really clears up the issues. Let me try to answer your questions. Yes we use 'maven-ant-tasks-2.1.3.jar' to call maven from an Ant script. Based on my point of view there is no advantage to call Maven from Ant ? just call it directly..also in TeamCity you can call mvn directly.. I didn't create any of the Ant stuff so can't say why things are the way they are but we use this a lot to download artifacts from Nexus so probably used it to run Maven builds too because all the configuration was already setup. The downloads are done by Maven automaticially... Currently the Ant scripts create InstallAnywhere (IA) installers Means as far as i know create some folder structures with particular files in it ? (i know IZPack a bit..)would sound like a job for maven-assembly-plugin may be some parts can be done by maven-resources-plugin ... > and generate ISO images. There are no native Maven plugins for these tasks but we have created wrappers for use with Maven in other projects but they are not compatible with this particular build so we would need to refactor the build to make the full switch to Maven. https://github.com/stephenc/java-iso-tools Yes I'm aware Maven 3.3.3 needs JDK7, that's okay as we build all new stuff with JDK8. We use TeamCity for CI. Ok..so no problem... I didn't realize that Maven-Ant-Tasks cared what version of Maven it was used with. Do you know what's the latest Maven version it officially supports? As as i know it should work till 3.2.5 as you already realized... (but officially Hm..whatever this means..)... > Perhaps I can use this as the reason to bite the bullet and convert the remaining Ant portions to Maven. If you have questions converning that please don't hesitate to ask here on the list...so we can support you Kind regards Karl Heinz Marbaise -Dave On Mon, Sep 14, 2015 at 10:36 AM, Karl Heinz Marbaise <khmarba...@gmx.de <mailto:khmarba...@gmx.de>> wrote: Hi David, On 9/14/15 5:57 PM, David Hoffer wrote: The reason for the Ant script is historical. It's a very large project that back in the day was 100% Ant. Over time portions were migrated to Maven, the only way to integrate with the larger Ant script is with Maven-Ant-Task. Today all the developer builds are pure maven but most of the CI builds have to do more than that...build installers, build ISO images, etc. Unfortunately those other tasks are still Ant. I would say it's time to migrate...and leave Ant for Maven related thingsCan you tell me what kind of installers ? ISO image ? As far as i remember there is a maven plugin which creates iso images (Stephen Connolly has written something like that if my memory does not mistaken me)... We don't have any '.mvn' folders. Shouldn't multiModuleProjectDirectory just default to the same folder that has the top level pom? Yes in this case it is exactly that way...you should add property set in your ant task to define the property...that should fix the problem...but i'm not sure if this will fix it completely...why don't you call "mvn.cmd" or "mvn" from the ant task... So wait a moment...you are using Maven Ant Tasks to call maven? Sounds strange ...why not directly calling Maven... >Not clear why pure maven build works w/o setting multiModuleProjectDirectory but not when using Maven-Ant-Task. The difference is that pure Maven the property is set by the calling scripts ( mvn / mvn.cmd)...which will identify the root folder of a multi module build...and the Maven Ant Task does not know anything about that property... We don't call "mvn.bat" or "mvn.cmd" directly as that must be handled by Maven-Ant-Task. Yes that's your issue, cause Maven Ant Task hasn't been updated/releases for a long time...and especially for Maven 3.3.X not...if you like to provide a patch ;-) ..? > I wondered if the change from bat to cmd was the cause of the problem, still not sure. Not the change from .bat to .cmd...The change from bat to cmd was only to leave Win95 support... The point is the usage for the root folder to find ".mvn" folder...which is needed cause the configuration (maven.config) is located there and jvm configuration (jvm.config) and extensions (extensions.xml) are being loaded from there... > I did see that Maven-Ant-Task has not been updated in quite some time, it's unfortunate if it needs to be updated for Maven 3.3.3 and not just work the same as prior versions. The problem is that sometimes things needed to be changed...yes
Re: Where has the list of maven project properties gone?
Hi, I have added a wiki page... https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide On 9/5/15 11:00 AM, Hervé BOUTEMY wrote: here is the core reference: http://maven.apache.org/ref/3-LATEST/maven-model-builder/ it does not explain everyting that can be found in POM or in settings, since there are so much info available but it points to POM and settings descriptors and explains everything that is not POM or settings Regards, Hervé Le vendredi 4 septembre 2015 15:23:19 Steve Cohen a écrit : What with the Codehaus "termination of Maven services" and other recent developments, what has happened to the handy list of predefined project properties and other properties that was once but no longer is available from http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide ? I need to look up one stinking property that I know I've used before and can't find any listings of these. I can't believe how difficult this information has become to find. Can someone provide a link to such a list? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can not build with Junit4.18
Hi, On 8/30/15 3:40 PM, 建文 wrote: I add junit4.8 in my project, and the test java classes are in src/main/java not src/test/java(i know it's not best practice), You should change that and put the tests into src/test/java... I assume you have given the scope for junit ? If yes than junit is not available for src/main/java... Apart from that a scope of a test dependency to runtime does not make sense...for tests it should be test scope... Furthermore your test should be named likt Junit4Test.java insteadto follow the naming conventions... and i set junit dependency scope to runtime. but when i run mvn clean install -DskipTests=ture,got error, [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project HigoPlatform: Compilation failure: Compilation failure: [ERROR] /mydata/project/HigoPlatform/src/main/java/com/higo/test/TestJunit4.java:[3,24] package org.junit does not exist [ERROR] /mydata/project/HigoPlatform/src/main/java/com/higo/test/TestJunit4.java:[5,17] package org.junit does not exist [ERROR] /mydata/project/HigoPlatform/src/main/java/com/higo/test/TestJunit4.java:[14,4] cannot find symbol [ERROR] symbol: class Test [ERROR] location: class com.higo.test.TestJunit4 [ERROR] /mydata/project/HigoPlatform/src/main/java/com/higo/test/TestJunit4.java:[16,5] cannot find symbol from error,i try to override the junit version in maven-compiler-plugin with: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.3/version configuration encodingUTF-8/encoding source1.7/source target1.7/target /configuration dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.12/version /dependency /dependencies /plugin but not work.any suggest or resolution tip? thanks Junit ist not a plugin dependency it's a usual dependency...which means to add it as this: dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.12/version /dependency /dependencies which is also a contradiction to the subject of the thread... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Enforcer Version 1.4.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Enforcer Version 1.4.1 http://maven.apache.org/enforcer/ Enforcer is a build rule execution framework. If you need to force things within your build please use the maven-enforcer-plugin. http://maven.apache.org/enforcer/maven-enforcer-plugin/ plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.4.1/version /plugin You can download the appropriate sources etc. from the download page: http://maven.apache.org/enforcer/download.cgi Release Notes - Maven Enforcer - Version 1.4.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520version=12330766 Bugs: * [MENFORCER-222] - RequireSameVersion rule regression between 1.3 and 1.4 * [MENFORCER-224] - Regression from 1.3.1 to 1.4 with bannedDependencies rule * [MENFORCER-229] - Ban Distribution Management documentation example doesn't work * [MENFORCER-237] - Resources Link to codehaus is wrong Improvements: * [MENFORCER-223] - Upgrade mrm-maven-plugin to 1.0-beta-2 * [MENFORCER-227] - Document nullability with @Nonnull on EnforcerRule API * [MENFORCER-233] - Upgrade maven-invoker-plugin to 2.0.0 * [MENFORCER-235] - Use maven-fluido-skin 1.4 * [MENFORCER-236] - Upgrade maven-assembly-plugin version from 2.4 to 2.5.5 in integration test * [MENFORCER-238] - Upgrade plexus-utils to 3.0.22 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Facing problem whith Maven for Portals-pom 1.4
Hi, are you behind a corporate firewall / proxy ? Furthermore have you correctly configured your nexus? Have you tried to get the pom via browser / curl ? https://repo.maven.apache.org/maven2/org/apache/portals/portals-pom/1.4/portals-pom-1.4.pom Have you tried the following url as central URL: https://repo1.maven.org/maven2/ Kind regards Karl Heinz Marbaise PS.: Please use the users list for such questionsand not dev list... On 8/7/15 8:11 PM, Lalitha Bourishetty wrote: Hi Team, When I tried to build Jetspeed 2.3 source code with maven 3.3.1 , got below error: Downloading: https://repo.maven.apache.org/maven2/org/apache/portals/portals-pom/1.4/portals-pom-1.4.pom [ERROR] [ERROR] Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.apache.portals.jetspeed-2:jetspeed-2:2.3.0: Could not transfer artifact org.apache.portals:portals-pom:pom:1.4 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/23.235.40.215] failed: Connection timed out: connec t and 'parent.relativePath' points at wrong local POM @ line 28, column 11 @ [ERROR] The build could not read 1 project - [Help 1] org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.apache.portals.jetspeed-2:jetspeed-2:2.3.0: Could not transfer artifact org.apache.portals:portals-pom:pom:1.4 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/23.235.40.215] failed: Connection timed out: connec t and 'parent.relativePath' points at wrong local POM @ line 28, column 11 I thought it might be problem with proxy and made all required settings in settings.xml (settings like proxy etc.) Even after configuring proxy got same error. I tried to do using Maven repository server I went with Nexus. When Tried with nexus got below exception: When I tried with Nexus, I am facing below error: org.apache.http.conn.ConnectTimeoutException: Connect to repo1.maven.org:443 [repo1.maven.org/23.235.44.209] failed: connect timed out jvm 1| at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:134) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.sonatype.nexus.plugins.rrb.MavenRepositoryReader.getContent(MavenRepositoryReader.java:231) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.plugins.rrb.MavenRepositoryReader.extract(MavenRepositoryReader.java:101) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.plugins.rrb.RemoteBrowserResource.get(RemoteBrowserResource.java:138) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.plexus.rest.resource.RestletResource.represent(RestletResource.java:233) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.rest.NexusRestletResource.represent(NexusRestletResource.java:39) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.resource.Resource.getRepresentation(Resource.java:302) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.resource.Resource.handleGet(Resource.java:464) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.Finder.handle(Finder.java:353) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.Filter.doHandle(Filter.java:150) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1
Re: Automatically appended artifactId in inherited SCM element
-mojo.html
I have seen also that you define the maven-sources-plugin in your core
module like this:
!-- Create source jar --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-source-plugin/artifactId
version2.4/version
executions
execution
phasepackage/phase
goals
goaljar/goal
goaltest-jar/goal
/goals
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-Title
Specification-Version${project.version}/Specification-Version
Specification-Vendorio7m.com/Specification-Vendor
Implementation-Title${project.name}/Implementation-Title
Implementation-Version${project.version}/Implementation-Version
Implementation-Vendorio7m.com/Implementation-Vendor
Implementation-Vendor-Id${project.groupId}/Implementation-Vendor-Id
Built-Byio7m/Built-By
/manifestEntries
/archive
/configuration
/execution
/executions
/plugin
Apart from the manifest part as mentioned for the maven-jar-plugin you
have defined explicit executions with binding to life cycle which is not
neccessary cause maven-sources-plugin is already bound to the life
cycleAnd you should prevent using the goal 'jar' cause it will fork
the life cycle...Are you sure making source packages of your test code ?
Also i have found a thing in your parent pom:
prerequisites
maven2.2.1/maven
/prerequisites
So i can give you a hint to read this:
http://blog.soebes.de/blog/2015/04/04/maven-prerequisites/
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Automating the build of a JNI based application
Hi, I would suggest to use Maven 3.X and not Maven 2.X anymore...but apart from that the site shows Maven minimum 2.0.9[2]...which looks like a bug... Furthermore please be aware of EoL for Maven 2 [1]. [1] http://maven.apache.org/maven-2.x-eol.html [2] http://maven-nar.github.io/plugin-info.html On 8/3/15 9:01 AM, Dušan Rychnovský wrote: Hi, Thanks for your suggestions. I tried the nar-maven-plugin as described on the usage page ( http://maven-nar.github.io/usage.html). I have the following pom: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcz/groupId artifactId.../artifactId version1.0-SNAPSHOT/version packagingnar/packaging build plugins plugin artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.7/source target1.7/target /configuration /plugin plugin groupIdcom.github.maven-nar/groupId artifactIdnar-maven-plugin/artifactId version3.2.3/version extensionstrue/extensions configuration libraries library typejni/type narSystemPackagecz/narSystemPackage /library /libraries /configuration /plugin /plugins /build /project And the following maven version: *Apache Maven 2.2.1 (rdebian-4)* And when I run *mvn clean package* I get the following error *Internal error in the plugin manager executing goal 'com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate': Unable to load the mojo 'com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate' in the plugin 'com.github.maven-nar:nar-maven-plugin'. A required class is missing: org/sonatype/aether/resolution /ArtifactResolutionException org.sonatype.aether.resolution.ArtifactResolutionException* What's wrong? Thanks, Dusan 2015-08-01 21:05 GMT+02:00 Benson Margulies bimargul...@gmail.com: Look for the modern nar plugin on github. On Fri, Jul 31, 2015 at 12:59 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 7/31/15 6:51 PM, Dušan Rychnovský wrote: Hi, I'm creating a JNI wrapper on top of a C++ library. I'd like to have a one-click Maven build for the whole application. When building it manually, I need to do the following: javac ... (compile the Java source files) javah ... (generate JNI header files from Java class files) g++ ... (compile the JNI source files + link them with the static library) I'm looking for a way to have these commands executed by Maven. I looked at the native-maven-plugin ( http://maven.apache.org/archives/maven-1.x/plugins/native/index.html) and I'm afraid it will not work for me. Nor should it cause Maven 1 is simply dead.. * The documentation is extremely insufficient (there is literally no official documentation on the plugin site and nor is there any information elsewhere on the Internet). which is not really astonishing... * I cannot even look at the source-code as it isn't there in the SVN repository linked from the plugin site. * I tried to make it work based on the two SO posts I discovered but I couldn't. I'm thinking about the following project layout: /src /src/main /src/main/java... the Java interfaces with native methods /src/main/native ... the C++ implementation of the generated header files The static library itself is a product of a different project and will be installed on my system in a standard location (i.e. outside of this project). What I need is essentially to call the javah and g++ commands after the Java .class files have been generated. The g++ command is non-trivial, there are quite a few compiler and linker options that need to be applied. The generated library file should not be a part of the generated JAR file, it should be a separate artifact. I was thinking maybe I'll need to use the exec-maven-plugin ( http://www.mojohaus.org/exec-maven-plugin/index.html) and run the commands manually? Or is there a better way to do this? Also, once the library is generated, I'd like to have Maven run some test cases using the generated JNI wrapper to make sure it works correctly. Thanks very much for your help. Kind regards, Dusan I woudl suggest to take a look into the nar-maven-plugin: http://maven-nar.github.io/ which might be better fit your needs.. Kind Regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional
Re: maven release plugin: help page is showing a deprecated version 2.5
Hi Brice, On 7/31/15 3:56 PM, Brice Vandeputte wrote: Hi all, not sure to be on the good ML but I would like to ask to one of the maven-release-plugin leader/owner to update some help page about the plugin version to use. It is very good to get in contact with us to show there is something wrong/could be made better...and yes use the mailing list for this... Those pages are independent documentation from the maven-release-plugin...but for example, this help page is up-to-date and refers to the latest plugin vrersion : 2.5.2 http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html (others overviews pages are ok) Those pages are generated during the release of a version of the plugin...so shouldn't be a problem..but this should not mean to check if see issues etc. please report them... but this one is not (refers to : 2.5) https://maven.apache.org/guides/mini/guide-releasing.html maybe this is the only one but that page was my starting point I have fixed the page content to use the most uptodate version. Thanks for reporting this issue.. Kind regards Karl Heinz Marbaise I m trying to check but I have an issue when releasing with 2.5 version : on release:perform target, maven release plugin is deploying on snapshot repo instead of release one. this issue has been discussed here: http://stackoverflow.com/questions/7332580/maven-deploys-to-snapshot-instead-of-release and rely on this bug: http://jira.codehaus.org/browse/MRELEASE-875 Is it possible to update the maven site to show only to the latest version on each page to avoid confusing (unlucky) end-users like me ;) Regards Thanks Brice Vandeputte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Automating the build of a JNI based application
Hi, On 7/31/15 6:51 PM, Dušan Rychnovský wrote: Hi, I'm creating a JNI wrapper on top of a C++ library. I'd like to have a one-click Maven build for the whole application. When building it manually, I need to do the following: javac ... (compile the Java source files) javah ... (generate JNI header files from Java class files) g++ ... (compile the JNI source files + link them with the static library) I'm looking for a way to have these commands executed by Maven. I looked at the native-maven-plugin ( http://maven.apache.org/archives/maven-1.x/plugins/native/index.html) and I'm afraid it will not work for me. Nor should it cause Maven 1 is simply dead.. * The documentation is extremely insufficient (there is literally no official documentation on the plugin site and nor is there any information elsewhere on the Internet). which is not really astonishing... * I cannot even look at the source-code as it isn't there in the SVN repository linked from the plugin site. * I tried to make it work based on the two SO posts I discovered but I couldn't. I'm thinking about the following project layout: /src /src/main /src/main/java... the Java interfaces with native methods /src/main/native ... the C++ implementation of the generated header files The static library itself is a product of a different project and will be installed on my system in a standard location (i.e. outside of this project). What I need is essentially to call the javah and g++ commands after the Java .class files have been generated. The g++ command is non-trivial, there are quite a few compiler and linker options that need to be applied. The generated library file should not be a part of the generated JAR file, it should be a separate artifact. I was thinking maybe I'll need to use the exec-maven-plugin ( http://www.mojohaus.org/exec-maven-plugin/index.html) and run the commands manually? Or is there a better way to do this? Also, once the library is generated, I'd like to have Maven run some test cases using the generated JNI wrapper to make sure it works correctly. Thanks very much for your help. Kind regards, Dusan I woudl suggest to take a look into the nar-maven-plugin: http://maven-nar.github.io/ which might be better fit your needs.. Kind Regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unsupported protocol: ‘http’” during maven threaded build.
Hi Kevin, On 7/21/15 6:59 PM, Kevin Burton wrote: We’re using maven 3.2.5 and recently migrated to a threaded build and I now get this error: [ERROR] Unsupported protocol: 'http' [ERROR] Unsupported protocol: 'https' [ERROR] Unsupported protocol: 'http' [ERROR] Unsupported protocol: 'http' [ERROR] Unsupported protocol: 'https' [ERROR] Unsupported protocol: 'http' [ERROR] Unsupported protocol: 'http' I get about 40 of those and the build fails. It only happens intermittently so I think on of the plugins isn’t thread safe. Any recommendation of a fix and how to resolve this? First it would be helpful to have full log output. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to delete certain snapshots from Nexus
Hi David, On 7/21/15 6:03 PM, David Hoffer wrote: We use Nexus as our corporate Maven repository and would like to periodically delete certain SNAPSHOT artifacts. We need to be able to filter/select by groupId and by version...so delete all where groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT. You can only delete all kind of SNAPSHOT's in Nexus based on a time frame for example delete all SNAPSHOT's which are older than 30 days etc.. Our use case is that when we refactor part of the build to use new groupIds the old ones are not valid anymore however sometimes there is a lingering reference to the old groupId, if we can delete all the old SNAPSHOTS we could find those errors now instead of when we release. Any ideas on how to do this are much appreciated. -Dave Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin Version 2.4.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 2.4.1 http://maven.apache.org/plugins/maven-shade-plugin/ This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.4.1/version /plugin You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-shade-plugin/download.cgi Release Notes - Maven Shade Plugin - Version 2.4.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12332978 Bugs: * [MSHADE-148] - Shade Plugin gets stuck in infinite loop building dependency reduced POM * [MSHADE-194] - Reporting uses maven-invoker-plugin version 1.9 instead of 1.10 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
