Re: Structuring bigger Maven projects
Hi, On 30/11/16 19:18, Florian Schätz wrote: A library project to be shared between multiple applications each having its own release-cycle should not be part of a multi-module project used to build such an application and should be an independent project with its own release-cycle. While this is of course a good idea, especially when starting to create new applications, the library projects will grow with the applications and not independently of them. We cannot start by first investing months to create the perfect will-work-for-ten-years library and only then start coding the application that will, in the first months, only use 10% of all these features. So, realistically, during a development cycle, both the application and the library will grow... (which doesn't mean that we cannot separate them) Which leads me, for example, to the problem that I still want to automate as much as possible. I would like, for example, to click one button in my build server, perhaps enter some parameters and get a new release candidate of the libraries from the current release branch, update the dependency version of the application to this rc version, make the application an rc (from the application's release branch), install them both into the repository, tag the current status on git and deploy the rc application onto the server. Especially for bigger projects, I want to keep the amount of manual work needed as small as possible. As much building should be done automatically, if possible. And I would like not having to code a jenkins or maven plugin for that purpose (but of course, I would, if needed, no problem there). You can simply use maven-release-plugin (in Maven itself) which you can used to fully automatically create releases of your project...This will need only a plugin in Jenkins which handles all those stuff...correctly configured things like scm entries in your pom file tagging in Git will be done as well Sometimes you might need to improve that using the versions-maven-plugin in combination with some pipeline steps in Jenkins...which prevents some drawbacks of the maven-release-plugin May be you need to think about using the Maven integration in Jenkins or using freestyle projects or better start using pipelines ...(I often observed performance drawbacks in relationship with Maven integration in Jenkins)... https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin https://wiki.jenkins-ci.org/display/JENKINS/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: .asc.asc files
Hi Jochen, On 04/12/16 15:14, Jochen Wiedmann wrote: Hi, trying to deploy a release to Nexus, I end up with files commons-fileupload-1.3.3-bin.tar.gz.asc.asc.asc.asc. What I did: cd target/checkout (Directory created by mvn release:perform) mvn -Prealease -Papache-release clean site install deploy a simple: mvn -Prelease -Papache-release clean site deploy is sufficient... by using the deploy phase all life cycle phases including install will run a second time... Furthermore during a release:prepare release:perform the "deploy" should already been done...cause usually a release:perform will run things like "deploy"... Kind regards Karl Heinz Marbaise Any ideas, what's wrong? And (so I can file a bug report): Which plugin is the culprit? Thanks, - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slightly more advanced resource filtering (templating)?
Hi, have you taken a look at the build-helper-maven-plugin which has a goal parse-version which will result in appropriate properties which than can be used to achieve what you like. Kind regards Karl Heinz Marbaise http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html On 03/01/17 19:25, org.apache.maven.u...@io7m.com wrote: Hello. I have a small project that contains a plugin for Blender[0]. Plugins in Blender are Python files that must contain a hash value at the top of the file containing version information. The version information has to be numeric constants as Blender actually parses this data rather than evaluating it in an interpreter. https://github.com/io7m/smf/blob/develop/io7m-smfj-blender/src/main/resources/__init__.py Right now, I'm having to remember to manually insert the right version number each time I increment the Maven version. I'd much rather filter the Python source file as a resource instead, but unfortunately I'd need to transform the Maven version string: 2.3.1 → (2, 3, 1) Is there an existing plugin that can do this? I assume that it'd be some sort of templating engine. Unfortunately, all of the search results for that seem to be in regards to the site plugin. M [0] http://blender.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: buildnumber plugin - last revision vs revision
Hi Jan, On 30/03/17 22:01, Jan Tosovsky wrote: Dear All, I'd like to implement versioning of my builds based on actual SVN revisions. However, when using buildnumber plugin, it returns the revision of top level folder (repository root), not my subfolder. When running the following command in console, which seems to be executed via plugin during the build process: svn --non-interactive info C:\trunk\liferay\test-portlet I am getting the following outcome: Path: C:\trunk\liferay\test-portlet Working Copy Root Path: C:\trunk URL: https://svn.doctribute.org/svn/dev/trunk/liferay/test-portlet Relative URL: ^/trunk/liferay/test-portlet Repository Root: https://svn.doctribute.org/svn/dev Repository UUID: d2212073-805c-254b-a7b3-a8ceac86dd9a Revision: 44044 Node Kind: directory Schedule: normal Last Changed Author: j.tosovsky Last Changed Rev: 43992 Last Changed Date: 2017-03-24 16:44:15 +0100 (Fri, 24 Mar 2017) For my use I'd prefer using 'Last Changed Rev' and 'Last Changed Date' for the final buildNumber and timestamp respectively. Currently I am getting 44044, which is not the revision of my code, but the revision of other (sister) project. I've tried to modify this option (with both true/false values), but the result is same: false (I am not sure I understand the meaning of this feature) Is there any chance to utilize 'Last Changed XXX' entries? which version of the buildnumber-maven-plugin 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: buildnumber plugin - last revision vs revision
Hi Jan, On 31/03/17 00:18, Jan Tosovsky wrote: On 2017-03-30 Karl Heinz Marbaise wrote: On 30/03/17 22:01, Jan Tosovsky wrote: I'd like to implement versioning of my builds based on actual SVN revisions. However, when using buildnumber plugin, it returns the revision of top level folder (repository root), not my subfolder. When running the following command in console, which seems to be executed via plugin during the build process: svn --non-interactive info C:\trunk\liferay\test-portlet I am getting the following outcome: Path: C:\trunk\liferay\test-portlet Working Copy Root Path: C:\trunk URL: https://svn.doctribute.org/svn/dev/trunk/liferay/test-portlet Relative URL: ^/trunk/liferay/test-portlet Repository Root: https://svn.doctribute.org/svn/dev Repository UUID: d2212073-805c-254b-a7b3-a8ceac86dd9a Revision: 44044 Node Kind: directory Schedule: normal Last Changed Author: j.tosovsky Last Changed Rev: 43992 Last Changed Date: 2017-03-24 16:44:15 +0100 (Fri, 24 Mar 2017) For my use I'd prefer using 'Last Changed Rev' and 'Last Changed Date' for the final buildNumber and timestamp respectively. Currently I am getting 44044, which is not the revision of my code, but the revision of other (sister) project. I've tried to modify this option (with both true/false values), but the result is same: false (I am not sure I understand the meaning of this feature) Is there any chance to utilize 'Last Changed XXX' entries? which version of the buildnumber-maven-plugin do you use? oops, it is 1.4. Just fine that is the latest release of it... In meantime I found GitHub Pages and my issue resembles https://github.com/mojohaus/buildnumber-maven-plugin/issues/36 and also (fixed, but not released yet) https://github.com/mojohaus/buildnumber-maven-plugin/issues/38 But there is also a pull request mentioning the support for the Last Changed Date (what I need as well): https://github.com/mojohaus/buildnumber-maven-plugin/pull/16 So I most likely need to integrate that pull request and to build the custom version from sources to get correct behavior. Or is there planned any new build (the last one was in 2015)? Thanks, Jan At the moment I'm working on such issues...and trying to fix some of them...cause the 3.0.0 milestone has a large number of fixes in the meantime...I'm thinking of making a release of it within the next few weeks... 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 password encryption by project
Hi, I would never put passwords etc. into a pom file. encrypted or not... I would suggest to put them into the settings.xml file outside your pom file, cause the pom file will be checked in into version control system.. On 17/03/17 14:38, Alix Lourme wrote: Dear community, I'm searching the best practice for password encryption in a maven POM file *by project*, could by used by properties (like in ANT or WAGON). Sample : --- maven-antrun-plugin 1.8 --- In this case, my *docker.password* could be a properties (pom or settings.xml) but must not be in clear text. The problem with Maven encryption <https://maven.apache.org/guides/mini/guide-encryption.html>: - I have a master password defined in *settings-security.xml* (locally) for my user need (like proxy password encryption in MY *settings.xml*) - The CI tools contains the same mechanism (own *settings-security.xml*) for global needs, like server encryption used in *settings.xml* for jar publication in repository ; and I can't retrieve this file => I can't use this mechanism for password encryption who works locally and on the CI server. *Is there a way to have a encryption mechanism for the project's perimeter ?* (and not for user's perimeter, current Maven encryption works perfectly for that). --- Using -s and -gs Maven options (=> user/global settings override) could be a workaround but : - Server item definition or properties defining password must be in clear text - Using this Maven settings for each build depending the project workspace is a little boring You can use the user settings.xml file this where you can also encrypt the passwords/etc. https://maven.apache.org/guides/mini/guide-encryption.html Kind regards Karl Heinz Marbaise Perhaps is there a best way like a "private key by project" ... but I didn't found entry point about that. Thanks in advance. Best regards *NB*: This question was firstly on stackoverflow <https://stackoverflow.com/questions/33784790/maven-password-encryption-by-project>, but no really interest ^^. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting maven to create a bundle manifest incrementally in eclipse
Hi Bill,
On 21/03/17 16:01, Bill Mair wrote:
Hi,
I'm attempting to switch to maven to create my packages but I have hit a
snag that I can't find a solution for.
Up until now, I have been controlling the dependencies of my ant build
process with the contents of "META-INF/MANIFEST.MF". Maven works the
other way around and generates that based on what I have actually used,
which I think is fantastic.
You can use Maven Tycho which gives you back the switch of requirement.
In Tycho you can either work MANIFEST first or POM first setup...
https://eclipse.org/tycho/
And of course if your working on OSGi it makes sense to control the
dependencies via MANIFEST via Eclipse which can handle that very good
(dependencies, tree etc., target platforms etc.).
I already have the git hash being included by buildnumber-maven-plugin
(which required the additional pluginManagement section to work
correctly in eclipse).
Than you are using an old version cause 3.0.0 already includes this
mapping for m2e...
My problem is that this is only generated when I build the bundle and
not during incremental saves.
The reason is simply cause you changed the side which means pom
first..which I would say is not a good idea in OSGi and Eclipse...
Kind regards
Karl Heinz Marbaise
What do I have to change in this pom.xml to make eclipse, m2e, maven and
the maven-bundle-plugin play nicely together?
--
Bill Mair
pom.xml
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;>
test.iface
test.iface
UTF-8
/MM/dd HH:mm:ss
z
4.0.0
test
test.iface
1.0.1
scm:git:file://.
scm:git:file://.
scm:git:file://.
HEAD
org.osgi
org.osgi.core
5.0.0
provided
true
org.osgi
org.osgi.compendium
4.3.0
provided
true
javax.jws
jsr181-api
1.0-MR1
junit
junit
4.12
compile
true
bundle
org.apache.felix
maven-bundle-plugin
3.0.1
true
META-INF
${bundle.symbolicName}
${project.version}
${project.organization.name}
Copyright (C)
${project.organization.name}
${maven.build.timestamp}
${buildNumber}
!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${project.version}"
org.codehaus.mojo
buildnumber-maven-plugin
1.4
validate
create
false
false
org.apache.maven.plugins
maven-javadoc-plugin
2.10.4
attach-javadocs
jar
org.apache.maven.plugins
maven-source-plugin
3.0.1
attach-sources
jar
org.apache.maven.plugins
maven-compiler-plugin
3.6.1
1.7
1.7
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
org.eclipse.m2e
lifecycle-mapping
1.0.0
org.codehaus.mojo
buildnumber-maven-plugin
Re: [EXTERNAL] Re: Getting maven to create a bundle manifest incrementally in eclipse
Hi, as far as i know you can generate the MANIFEST file from that...?? Not 100%sure about this [1] cause I never used it myself.. Furthermore if you create an appropriate target platform and create a p2 repo from it (using tycho, upload to Nexus for example) this can be used to be integrated in your build in Eclipse (using tycho) which than will solve it also inside Eclipse... Kind regards Karl Heinz [1]: https://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts On 21/03/17 22:42, Justin Georgeson wrote: POM-first dependencies in Tycho is just for resolution of plugin jars from Maven repo (when they're not available in a P2 software site). It doesn't handle writing your MANIFEST file to reflect those POM-first dependencies, so you have to declare them in both files in that case. -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Tuesday, March 21, 2017 3:34 PM To: Maven Users List <users@maven.apache.org> Subject: [EXTERNAL] Re: Getting maven to create a bundle manifest incrementally in eclipse External Sender: Use caution with links/attachments. Hi Bill, On 21/03/17 16:01, Bill Mair wrote: Hi, I'm attempting to switch to maven to create my packages but I have hit a snag that I can't find a solution for. Up until now, I have been controlling the dependencies of my ant build process with the contents of "META-INF/MANIFEST.MF". Maven works the other way around and generates that based on what I have actually used, which I think is fantastic. You can use Maven Tycho which gives you back the switch of requirement. In Tycho you can either work MANIFEST first or POM first setup... https://urldefense.proofpoint.com/v2/url?u=https-3A__eclipse.org_tycho_=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=bGPk9-NRTEIkBgx-D3uOAMwB-b2itE0bf0pzjbKlZs0= And of course if your working on OSGi it makes sense to control the dependencies via MANIFEST via Eclipse which can handle that very good (dependencies, tree etc., target platforms etc.). I already have the git hash being included by buildnumber-maven-plugin (which required the additional pluginManagement section to work correctly in eclipse). Than you are using an old version cause 3.0.0 already includes this mapping for m2e... My problem is that this is only generated when I build the bundle and not during incremental saves. The reason is simply cause you changed the side which means pom first..which I would say is not a good idea in OSGi and Eclipse... Kind regards Karl Heinz Marbaise What do I have to change in this pom.xml to make eclipse, m2e, maven and the maven-bundle-plugin play nicely together? -- Bill Mair pom.xml https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_POM_4.0.0=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=Kd-TDhLw1iVBaAqGOI6edW5kxuY1JW2ncBCQDTakR0Y= " xmlns:xsi="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2001_XMLSchema-2Dinstance=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=UiQcEFOTpLzlDZ2bGKUP0roZmZ-lekq-ckzXz77Yxhk= " xsi:schemaLocation="https://urldefense.proofpoint.com/v2/url?u=http-3A __maven.apache.org_POM_4.0.0=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbr MXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD 7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=Kd-TDhLw1iVBaAqGOI6edW5kxuY1JW2n cBCQDTakR0Y= https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_x sd_maven-2D4.0.0.xsd=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF 0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrT DV4FppklgbeyRakFBIPqJoSP43Y=w_BXwgMpPrHERwc7gqdgadG__EXBDlY4TbMX5iap Kqw= "> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bundle.symbolicName=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=TaSov7e93VtOFSW-wbSkimpcFZzq0fn2hX35RitVOPU= >test.iface <https://urldefense.proofpoint.com/v2/url?u=http-3A__bundle.namespace=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=HMZ22MdATe7QYvAwINbNz14S1EiFEDYPPTUuMKtgw5M= >test.iface <https://urldefense.proofpoint.com/v2/url?u=http-3A__project.build.sourceEncoding=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=Afq0-NWD7K5pqCrTDV4FppklgbeyRakFBIPqJoSP43Y=vDUOZN2NLvmaNvEKU56117LjFqTzysiSg8ADE9Upe5s= >UTF-8 <https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.build.timestamp.format=DwICaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
Re: maven-artifact-transfer not able to resolve SNAPSHOT artifact
Hi Dan, On 03/04/17 07:54, Dan Tran wrote: Hi, I am very sure maven-artifact-transfer is not the issue. The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories, needed by maven-artifact-transfer, has snapshot resolution disable For my case, I am using maven setting's mirror to route all pom's repositories to my internal maven repository. This also means I have only one remoteRepository with this content from my debugger id: xxx url: http://my.internal.repo/public layout: default snapshots: [enabled => false, update => daily] I'm not sure but maybe this is the problem ? not enabled to allow having snapshots ? Kind regards Karl Heinz releases: [enabled => true, update => daily] What could have caused this? I am seeing this issue on all maven 3.1+ Thanks -Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency question
Hi, On 11/04/17 23:38, Stephen Connolly wrote: On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote: Hi Stephen, There is a special version keyword LATEST which means the very newest version, snapshot or otherwise. And RELEASE means the newest release (non-SNAPSHOT) version. Support for those were dropped in Maven 3 By "support" do you mean "social support" as opposed to technical functionality? They were supposed to be removed. If they are working now, that's a bug Unfortunately they are working ;-(.. https://issues.apache.org/jira/browse/MNG-6206 Kind regards Karl Heinz Marbaise Because they are still present in the codebase, and they still work technically: https://github.com/apache/maven/blob/master/maven- resolver-provider/src/main/java/org/apache/maven/repository/internal/ DefaultVersionResolver.java#L188-L197 Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote: Hi Hector, This is fine as long as the dependency is always set to x.y.z-Snapshot and the dependency is always overwritten this way. What if the producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want the dependent build to always get the latest in this case, x.y.z.3-Snapshot ? There is a special version keyword LATEST which means the very newest version, snapshot or otherwise. And RELEASE means the newest release (non-SNAPSHOT) version. Support for those were dropped in Maven 3 *and* anyway they were only for *plugin* versions because the plugin version does not support ranges. For dependency versions, define a range Similar to version ranges, Maven will have to ask the remote repository about the latest known version in these cases, and will then use that. I want to emphasize, as others have mentioned, that using any of these strategies will result in _irreproducible builds_. That is, your code might build today, and then the same code will fail to build in the future, because the versions will resolve differently. The only way (I know of) to achieve reproducible builds is to use fixed release versions, always. Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector < hector.magna...@sap.com wrote: This is fine as long as the dependency is always set to x.y.z-Snapshot and the dependency is always overwritten this way. What if the producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want the dependent build to always get the latest in this case, x.y.z.3-Snapshot ? The difference with this scenario is that the producer will always have a new build number. As for your solution of using the range, do I always have to change the pom file in the dependent build whenever a new build is produced by the producer ? -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, April 10, 2017 10:39 AM To: Maven Users List <users@maven.apache.org> Subject: Re: dependency question On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector <hector.magna...@sap.com> wrote: I'm still a little confused about the answers I'm getting. So, if build A is being updated with a new build number(even for a snapshot), and build B has it as a dependency in it's pom.file, how does the pom file in Build B need to look like in the dependency section so that it does get the latest snapshot build of build A ? This conversation seems to keep mixing up SNAPSHOT version processing with various conventions for using version ranges. If the producer produces x.y.z-SNAPSHOT, and the consumer declares a dependency on x.y.z-SNAPSHOT, every build of the consumer will go out to the repositories to look for the latest snapshot build. Snapshots have risks and do not provide a repeatable build. Then again, neither do ranges. If you don't want to use snapshots, then you write the dependency in the consumer with a range (1.0-2.0] or whatever makes sense. This will cause builds of the consumer to go out to repositories and try to find the newest version within the range. it's up to you to bump the version in the producer, manually or with the maven-release-plugin. Scenario: Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot and they are all being uploaded to a repository. What will the pom file in build B look like so that the next time build B is executed, 3-snapshot for build A will be picked up ? -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Frida
Re: Any way to change the color scheme in Maven 3.5.0?
Hi, On 10/04/17 08:45, Francesco Chicchiriccò wrote: Thanks Hervé, appending -Dstyle.success=green to my MAVEN_OPTS did the trick. Is there any place where defaults for all styles (debug, info, warning, error, success, warning, failure, strong, mojo and project) are reported? Thanks! Yes if you do a mvn -X clean: ... [DEBUG] Imported: org.slf4j.helpers.* < plexus.core [DEBUG] Imported: org.slf4j.spi.* < plexus.core [DEBUG] Populating class realm maven.api [INFO] Error stacktraces are turned on. [DEBUG] Message scheme: color [DEBUG] Message styles: debug info warning error success failure strong mojo project [DEBUG] Reading global settings from /usr/local/maven/conf/settings.xml [DEBUG] Reading user settings from /Users/kama/.m2/settings.xml [DEBUG] Reading global toolchains from /usr/local/maven/conf/toolchains.xml [DEBUG] Reading user toolchains from /Users/kama/.m2/toolchains.xml Kind regards Karl Heinz Marbaise Regards. On 2017-04-08 08:33 (+0200), Hervé BOUTEMY <herve.bout...@free.fr> wrote: Hi, Yes, you can customize colors (thanks to some help I got during a Paris HackerGarten Meetup [1]). Here is the link in th ereference documentation: http://maven.apache.org/ref/3.5.0/maven-embedder/ While reading now what I wrote, it should probably be enhanced to be more explicit that styled message API details are particularly useful for color customization => I'll improve immediately this doc for the next minor release :) Regards, Hervé [1] https://www.meetup.com/Paris-Hackergarten/ Le vendredi 7 avril 2017, 12:47:35 CEST Francesco Chicchiriccò a écrit : Hi all, I am using since quite some time Maven 3.5.0-beta-1 and I am very satisfied, thanks for the good work! I was wondering if there is any mean to change the predefined color scheme: could you please provide any pointer WRT this? Thanks. Regards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any way to change the color scheme in Maven 3.5.0?
Hi, On 10/04/17 09:11, Francesco Chicchiriccò wrote: On 2017-04-10 08:58 (+0200), Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, On 10/04/17 08:45, Francesco Chicchiriccò wrote: Thanks Hervé, appending -Dstyle.success=green to my MAVEN_OPTS did the trick. Is there any place where defaults for all styles (debug, info, warning, error, success, warning, failure, strong, mojo and project) are reported? Thanks! Yes if you do a mvn -X clean: ... [DEBUG] Imported: org.slf4j.helpers.* < plexus.core [DEBUG] Imported: org.slf4j.spi.* < plexus.core [DEBUG] Populating class realm maven.api [INFO] Error stacktraces are turned on. [DEBUG] Message scheme: color [DEBUG] Message styles: debug info warning error success failure strong mojo project [DEBUG] Reading global settings from /usr/local/maven/conf/settings.xml [DEBUG] Reading user settings from /Users/kama/.m2/settings.xml [DEBUG] Reading global toolchains from /usr/local/maven/conf/toolchains.xml [DEBUG] Reading user toolchains from /Users/kama/.m2/toolchains.xml Sorry, I don't get it: where do I see, i.e., that style.info is blue by default? The following line is colored by the appropriate colors which are used...you should not do a redirect into a pipe via less/more etc.. [DEBUG] Message styles: debug info warning error success failure strong 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 3.5.0 and the versions plugin
Hi Mark, for the versions-maven-plugin there is already an issue for that: https://github.com/mojohaus/versions-maven-plugin/issues/56 Currently I'm working on a large number of the issues in the versions-maven-plugin ... https://github.com/mojohaus/versions-maven-plugin/milestone/2?closed=1 It will take some time... Kind regards Karl Heinz Marbaise On 13/04/17 23:00, Mark Eggers wrote: Folks, I'm working on upgrading an environment to maven 3.5.0. With prerequisites in pom.xml, I get the expected message: [WARNING] The project org.mdeggers:CSEquity:war:1.0-SNAPSHOT uses prerequisites which is only intended for maven-plugin projects but not for non maven-plugin projects. For such purposes you should use the maven-enforcer-plugin. See https://maven.apache.org/enforcer/enforcer- rules/requireMavenVersion.html I then remove the prerequisites tag and replace it with the appropriately configured enforcer plugin. The project builds cleanly. However, one of the things that we do in Jenkins is run a series of mvn versions:display--updates (plugins, dependencies) and mail the results to developers. When I run mvn versions:display-plugin-updates, I get the expected output as well as the following: [WARNING] Project does not define minimum Maven version, default is: 2.0 [ERROR] Project does not define required minimum version of Maven. [ERROR] Update the pom.xml to contain [ERROR] [ERROR] 3.0 [ERROR] Is there a way to resolve this? Should I file an issue with the maven versions plugin? . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin assembly: Howto use 'single' goal as an agregator ?
Hi, If you like to produce a package (zip/tar/whatever kind of archive/bundle) which contains some modules/artifacts etc. from your multi module build it is the best thing to create a separate module in your build with packaging pom and only put the maven-assembly-plugin in it and bind it to the life cycle. This project contains all the needed dependencies in your assembly project pom...which should be packaged into your resulting archive (zip/tar/whatever). The assembly descriptor contains the appropriate dependencySets/moduleSets/sources etc. entries as needed. This makes it absolutely sure that using a simple: mvn clean package or mvn install everything is correctly packaged into the resulting bundle you would like to build. This is simply a good way of following single responsibility principle. This produces each time a correct and the same result in contradiction to your supplemental goal calling from command line (you just simply miss it?). Apart from that using fileSets is usually not the correct way cause it relies on the content which is on the file system which might sometimes not what you really like if you don't do: mvn clean before. If you do things like this: mvn install ...Doing something here... mvn install assembly:attached The resulting bundle which has been produced by using assembly:attached could contain artifacts which are not part of the build.. This is also an problem in reproducibility of builds. From my point of view a single command like this: mvn clean package is easier and more in the paradigm of Maven. Use conventions... Adding a supplemental call to a plugin goal does not make it easier.. I will rely on just the build as it...without using supplemental goals or using some properties needed to be defined on the command line which I often see in other projects where you need to call some goals of plugins before or after things. I will alway try to get it as simple as possible which will result in just: mvn clean package. What I don't understand is your reference to maven-release-plugin and maven-invoker-plugin ? Kind regards Karl Heinz Marbaise On 11/03/17 15:56, Alix Lourme wrote: Hello, Since maven-assembly-plugin v3.3.0, the *attached* goal has been removed ( MASSEMBLY-704 <https://issues.apache.org/jira/browse/MASSEMBLY-704>). This *attached* goal was an aggregator (v2.6 source <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.6/src/main/java/org/apache/maven/plugin/assembly/mojos/AttachedAssemblyMojo.java>) but not the *single* goal (v3.0.0 source <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-3.0.0/src/main/java/org/apache/maven/plugins/assembly/mojos/SingleAssemblyMojo.java> ). Even *attached* goal "*leads to non-standard builds*", it was very useful on a multi modules project to generate a bundle with some modules items (artifacts, anything produced on *package* phase, ...) when the descriptor contains only *fileSets* definitions, using only one Maven command (e.g.: "*mvn install assembly:attached*") ; because assembly executed after package/install/deploy phase in each modules. With module binaries <https://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries> configuration, this job could be done ; but forces reviewing all assembly descriptors (usage of *moduleSet* in addition of *fileSet*), or using two steps Maven command. If you consider that using one command is a prerequisite ( *maven-release-plugin* plugin usage or some jobs with *maven-invoker*), the v2.x -> v3.x *maven-assembly-plugin* migration could be a little tricky. => Is there a way to execute single goal as an aggregator, via pom configuration (inheritable from a super/company parent pom) ? With that the *migration *could be just to replace *attached* by *single*. Many thanks in advance for tips or idea Best regards - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency question
Hi Russlel, On 07/04/17 17:29, Russell Gold wrote: That’s the way it works: when you specify a snapshot, it takes the latest. This is not 100% true, cause it depends on the update policy you have defined in your settings either explicit or by default the updates will be checked every 24 hours... If you like to force this you can use mvn -U ...or define a different updatePolicy in your settings.xml for the appropriate repository. By using mvn -U you make sure for running this build Maven will check if there are newer SNAPSHOT version available for dependencies which have defined a SNAPSHOT version This is working for a single module project...but if you have a multi module build (Project C: A1 build before A2) which takes for example 5 minutes to build ...this is no longer 100% true... Now let us assume you have another project B which dependends on two different artifacts (A1, A2) of Project C ...this means in consequence those artifacts are build at two different times... This means it could happen that your build of Project B consumes A2 from build #10 but A1 from build #9 ... In practical it usually works without any issue using the mvn -U ...but you should be aware of this issue... The only solution which I have found to make 100% sure is to use the output during the build of the project A and use those parsed informations about the SNAPSHOT versions and inject them into my current build ...(https://github.com/khmarbaise/deployment-recorder-extension not ready yet)... Kind regards Karl Heinz Marbaise There are some corner cases where it won’t. I think it only checks for a new snapshot every few hours or so, so if you are putting out a lot you might conceivably miss one. You can reset that if you need to . On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> wrote: If the builds for A are always getting a unique build number as a snapshot build, how am I sure that B will always get the latest snapshot of A ? Is there a way to name the A snapshot builds with a unique build number each time for this scenario. -Original Message- From: Russell Gold [mailto:russell.g...@oracle.com] Sent: Thursday, April 6, 2017 2:27 PM To: Maven Users List <users@maven.apache.org> Subject: Re: dependency question The simplest way is simply to use a snapshot version of A. That way B will always use the latest snapshot. When you finally release A, you can have B point to the released version instead of the snapshot. On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote: I have to 2 java projects a and b in maven. The B project uses the A build as a dependency. How do I ensure the whenever the A project has a new build, the B project will always use that latest build in A. A is being built with a unique build number each time it gets built. So is A has build # 10 as the newest build, the B project has to use build #10 of A. Hector Magnanao Jr. SCM Analyst SAP Fieldglass Skype: (331) 702-6142 Mobile: (847) 857-8401 Email: hector.magna...@sap.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven return code 502, ReasonPhrase:notresolvable
Hi, first recommendation I can give is upgrade the plugin versions cause 1.3 from 2008 ...is really old... furthermore error code 502 is "Bad Gateway"...do you have an Apache http server between you and the Nexus ? Or do you use Nexus plain...? Sounds like an issue on network level...Or bad configuration of Nexus etc.. How does your settings.xml look like? Kind regards Karl Heinz Marbaise On 13/08/17 18:29, Mehul Sanghvi wrote: I upgraded my Nexus OSS server to version 2.14.5-02, and I still see the same issue. All new builds that I have get affected by this, unless I manually copy the artefacts from an existing local maven repository. I have rebuilt the metadata, re-built the indexes, etc. as well. Still the same result. Anyone have any thoughts/suggestions/pointers ? cheers, mehul On Wed, Jul 26, 2017 at 9:21 AM, Mehul Sanghvi <mehul.sang...@gmail.com> wrote: Maven version: 3.3.3 Nexus version: OSS 2.14.o-1 Starting this past Monday, I have been seeing the following: build 25-Jul-2017 20:27:16 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (default) on project xml2jsonMigration: Execution default of goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run failed: Plugin org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.apache.maven:maven-plugin-api:jar:2.0.4, org.apache.maven:maven-project:jar:2.0.4, org.apache.maven:maven-settings:jar:2.0.4, org.apache.maven:maven-profile:jar:2.0.4, org.apache.maven:maven-model:jar:2.0.4, org.apache.maven:maven-artifact-manager:jar:2.0.4, org.apache.maven:maven-repository-metadata:jar:2.0.4, org.apache.maven:maven-artifact:jar:2.0.4, org.codehaus.plexus:plexus-utils:jar:1.5.6: Could not transfer artifact org.apache.maven:maven-plugin-api:jar:2.0.4 from/to releases (http://nexus.myorg.com:8081/nexus/content/groups/releases/): Failed to transfer file: http://nexus.myorg.com:8081/nexus/content/groups/releases/ org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar. Return code is: 502 , ReasonPhrase:notresolvable. At first it was for an artefact that was located in an internal corporate Artifactory repository, which I was able to get past by modifying the proxy settings in the settings.xml file. It used to be: *.myorg.com and I changed it to *.myorg.com|*.mycorp.com The error above that I am getting though, is for something that was working. And the artefacts are accessible via the web browser. From a network standpoint, the Nexus server is one hop away (based on traceroute information). This used to work. There have been no network changes, not VM changes, no updates to Maven. We did change the version number of our product by removing the -SNAPSHOT, but that should not cause this error that we are seeing. I have tried using the -U command line option, as well as just pointing maven.repo.local to a new location and avoiding any cacheing issues. Any pointers/suggestions/thoughts ? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: apache-maven-3.3.9 silently doesn't compile with jdk7 (it does with jdk8)
Hi, can you give a full working example of that... cause it sounds like there is something wrong with your configuration... What does: "mvn --version" says? Are you trying to run in console or running from inside of Eclipse? Kind regards Karl Heinz Marbaise On 08/08/17 16:38, bamboomy wrote: Hey All, this is my first message on the list :) I was wondering... When I compile with jdk8 (or eclipse that runs under jdk8) my (java 7) code compiles just fine, however it silently doesn't with jdk7 as jdk... [INFO] Changes detected - recompiling the module! [INFO] Compiling 37 source files to C:\Project\wss\maven\Sysper2\Reporting_maven\target\classes (but the target/classes/ folder is just empty) with jdk8: [INFO] Changes detected - recompiling the module! [INFO] Compiling 37 source files to C:\Project\wss\maven\Sysper2\Reporting_maven\target\classes [INFO] /C:/Project/wss/maven/Sysper2/Reporting_maven/src/main/java/eu/cec/admin/sysper2/document/model/Document.java: C:\Project\wss\maven\Sysper2\Reporting_maven\src\main\java\eu\cec\admin\sysper2\document\model\Document.java uses or overrides a deprecated API. [INFO] /C:/Project/wss/maven/Sysper2/Reporting_maven/src/main/java/eu/cec/admin/sysper2/document/model/Document.java: Recompile with -Xlint:deprecation for details. [INFO] /C:/Project/wss/maven/Sysper2/Reporting_maven/src/main/java/eu/cec/admin/sysper2/report/web/BirtConfiguration.java: Some input files use unchecked or unsafe operations. [INFO] /C:/Project/wss/maven/Sysper2/Reporting_maven/src/main/java/eu/cec/admin/sysper2/report/web/BirtConfiguration.java: Recompile with -Xlint:unchecked for details. and a well filled target/classes/ folder... Is this normal or should I file a bug? Br, S. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: apache-maven-3.3.9 silently doesn't compile with jdk7 (it does with jdk8)
Hi, On 10/08/17 02:10, Guang Chao wrote: On Tue, Aug 8, 2017 at 10:38 PM, bamboomy <bambo...@gmail.com> wrote: Hey All, this is my first message on the list :) I was wondering... When I compile with jdk8 (or eclipse that runs under jdk8) my (java 7) code compiles just fine, however it silently doesn't with jdk7 as jdk... Is it OpenJDK? Which build? [INFO] Changes detected - recompiling the module! [INFO] Compiling 37 source files to C:\Project\wss\maven\Sysper2\Reporting_maven\target\classes (but the target/classes/ folder is just empty) It looks weird, but intuition tells me it is not maven problem but config issue in your box. We haved dived into that more and it is not a config issue...I can reproduce the problem...(We have not yet the root cause)... But you can see the description here: https://issues.apache.org/jira/browse/MCOMPILER-302 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.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.2.0 https://maven.apache.org/shared/maven-archiver/ You should specify the version in your project: org.apache.maven.shared maven-archiver 3.2.0 Important Note: * Maven 3.X minimum * JDK 7 minimum requirement. 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.2.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12336743 Bug: * [MSHARED-601] - Update examples with "Archiver-Version" manifest entry Improvements: * [MSHARED-578] - Upgrade maven-shared-utils to 3.1.0 * [MSHARED-579] - Upgrade to plexus-archiver 3.4 * [MSHARED-643] - Upgrade to maven-shared-utils 3.2.0 * [MSHARED-644] - Removed prerequisites for none maven-plugin project * [MSHARED-653] - Upgrade to plexus-archiver 3.5 Enjos, -The Apache Maven team 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
Hi, On 26/07/17 20:13, Karl Heinz Marbaise wrote: Hi, On 26/07/17 11:49, ahardy42 wrote: Is there life is in this testing harness still? I'm looking at https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/ The link to JIRA returns 503 - http://jira.codehaus.org/browse/MPLUGINTESTING Outch that are the old links which means there hasn't been a release for a longer time ;-( This is the new location: https://issues.apache.org/jira/projects/MPLUGINTESTING/ and the link to git repo is 404 https://github.com/apache/maven-plugin-testing but it's out of date correct... I have created an appropriate INFRA ticket to fix this[1]. [1]: https://issues.apache.org/jira/browse/INFRA-14716 Thanks to INFRA..already fixed the problem. Kind regards Karl Heinz Marbaise I can imagine there is a big population of maven users out there who look at it and give up, which is a shame because you can't beat a good test harness. Yes this is unfortunately true... I have managed to put some code together to make my tests run nicely in IntelliJ and I was wondering if you wanted any documentation or example code? Both is appreciated...sure .. I've still got issues and I've got a live question on StackOverflow: https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness Regards Adam - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-plugin-testing-harness
Hi, On 26/07/17 11:49, ahardy42 wrote: Is there life is in this testing harness still? I'm looking at https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/ The link to JIRA returns 503 - http://jira.codehaus.org/browse/MPLUGINTESTING Outch that are the old links which means there hasn't been a release for a longer time ;-( This is the new location: https://issues.apache.org/jira/projects/MPLUGINTESTING/ and the link to git repo is 404 https://github.com/apache/maven-plugin-testing but it's out of date correct... I have created an appropriate INFRA ticket to fix this[1]. [1]: https://issues.apache.org/jira/browse/INFRA-14716 I can imagine there is a big population of maven users out there who look at it and give up, which is a shame because you can't beat a good test harness. Yes this is unfortunately true... I have managed to put some code together to make my tests run nicely in IntelliJ and I was wondering if you wanted any documentation or example code? Both is appreciated...sure .. I've still got issues and I've got a live question on StackOverflow: https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness Regards Adam 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: Excessive "checking for updates" on Travis CI
HI, first you are using version ranges...that's the reason for that... Simple recommendation I can give is: Don't use version ranges... Kind regards Karl Heinz Marbaise On 29/06/17 19:13, Mark Raynsford wrote: Hello. I use the free Travis CI service to build my various projects on each commit. I have a project that has a rather large number of modules (~90) and upon building each module, I see lots of this in the log: [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.jequality:com.io7m.jequality.core: checking for updates from sonatype [INFO] artifact com.io7m.jequality:com.io7m.jequality.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.jtensors:com.io7m.jtensors.core: checking for updates from sonatype [INFO] artifact com.io7m.jtensors:com.io7m.jtensors.core: checking for updates from sonatype-apache [INFO] artifact it.unimi.dsi:fastutil: checking for updates from sonatype [INFO] artifact it.unimi.dsi:fastutil: checking for updates from sonatype-apache [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: checking for updates from sonatype [INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.jtensors:com.io7m.jtensors.storage.bytebuffered: checking for updates from sonatype [INFO] artifact com.io7m.jtensors:com.io7m.jtensors.storage.bytebuffered: checking for updates from sonatype-apache [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: checking for updates from sonatype [INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype [INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype [INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for updates from sonatype-apache [INFO] artifact com.io7m.ieee754b16:com.io7m.ieee754b16.core: checking for updates from sonatype [INFO] artifact com.io7m.ieee754b16:com.io7m.ieee754b16.core: checking for updates from sonatype-apache Note that not only are these artifacts being checked redundantly (because an artifact may be checked at least once per module), they're also being checked multiple times in the same plugin execution! You can see an example of a build log here: https://api.travis-ci.org/jobs/248453940/log.txt I'm actually starting to hit the 4mb log file size limit on Travis due to the sheer amount of output produced. The project's source code, for the curious, is here: https://github.com/io7m/r2 Is there some way to get these redundant checks to stop? Failing that, is there a way to get Maven to shut up about it? M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excessive "checking for updates" on Travis CI
Hi Mark, On 29/06/17 19:50, Mark Raynsford wrote: On 2017-06-29T19:38:40 +0200 Karl Heinz Marbaise <khmarba...@gmx.de> wrote: HI, first you are using version ranges...that's the reason for that... Simple recommendation I can give is: Don't use version ranges... Hello. I maintain ~70 projects with complex interdependencies (this graph shows a subset of them): https://raw.githubusercontent.com/io7m/universe/master/io7m.png If I don't use version ranges, then when I update one dependency, I get to update a ton of other packages too. I make frequent releases. Without version ranges, my day would quickly be consumed by version-number-incrementing busy work across a large number of packages instead of getting actual development work done. I make strong guarantees about API compatibility with my own packages, including using japicmp to analyze the bytecode to ensure that I follow semantic versioning correctly. Therefore, I use version ranges, and have been for years. Is there something else I could be doing? Maybe you can do this by using versions-maven-plugin to update deps etc. via CI solution so you don't use versions ranges and prevent the request against your repository manager and have the job done via the computer instead of doing it manually and waisting your time with updating 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: Excessive "checking for updates" on Travis CI
Hi Mark, On 30/06/17 11:44, Mark Raynsford wrote: Apologies if that came off as rude, it wasn't intended to be. Upon re-reading it, I think it came off as a bit harsh. No problem. It's a real good behaviour of yours that you appologize for that...which I didn't take as rude etc. 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 resources plugin issue?
Hi, On 03/07/17 18:55, Laird Nelson wrote: I'm running into a strange situation with the maven-resources-plugin. I have my test resources set up normally, like this: src/test/resources …so basically the defaults made explicit. Why? Maven is about Convention over Configuration...so just remove it cause it's default... Today I suddenly noticed that—Maven 3.5.0, Maven Resources Plugin 3.0.2—although the plugin is reporting that (a) filtering is off and (b) there are 26 files to copy, none of them is actually copied. The above snippet does not turn on filtering. Do I mistaken something? What do you mean by it's not copied? Can you please create a complete example project which shows the problem?...best would be on github so we can take a look... Before we dig into details I would like to have the start situation define... Kind regards Karl Heinz Marbaise I dug in further and found that (ultimately) the culprit is here: https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/FileUtils.java#L1960 Briefly, each of the files that the plugin has decided to copy has a lastModified() of 0L, which means that in the absence of an overwrite being specified none of them is copied. Hmm, that's odd. It turns out the files in question that I'm working with happen to have been extracted from a tar archive, and have modification times of, for example, December 31, 1969. (They aren't that old; that's obviously something wonky about how they were wrapped up in the tar archive.) Obviously that's before the 1970 epoch, so I'm guessing that java.io.File#lastModified() probably returns something like Math.max(0L, realModificationTime) (the documentation says it returns 0L in the case of an error, but I don't think this is an error case). Is this expected behavior of the FileUtils class? There is documentation that indicates the lastModified() check was chosen explicitly ( https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/FileUtils.java#L1908-L1909). I can work around the issue, I guess, by touching all the files in an extra automated step or moving this to an explicit maven-resources-plugin:resources invocation with overwrite specified, but it seems to me this should Just Work™. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Please officially support RELEASE and LATEST (was: Re: dependency question)
ally valid. But so do SNAPSHOTs, and so do version ranges. And those have not been deprecated. So why are RELEASE and LATEST eschewed so heavily? I agree fully to that, cause I've learned that using version ranges has the same problem as you already mentioned. I would like to deprecate the version ranges as well The SNAPSHOT's a very usefull but you can run in problems too...yes... Orthogonally: I think it would be awesome to warn about irreproducible builds, be they from SNAPSHOTs, version ranges, or these special keywords. People need to know when their builds are vulnerable. But there should probably also be a property to disable this warning, for the cases when the developer intentionally wants/needs to use them, and knows what they are doing. My experience is that they simply don't understand the consequence using LATEST/RELEASE nor the usage of version ranges...and often astonished of build failures later and having problems reproducing builds... Kind regards Karl Heinz Marbaise If the issue is just that no ones has time to work on e.g. MNG-6206, I could try to make some time for it—I feel strongly enough about this issue. Thanks for any insight, workarounds, counterarguments, agreement. (Especially if you agree: please speak up, so the core Maven devs know I'm not just an outlier here!) Regards, Curtis [1] https://github.com/ctrueden/jrun -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven WAR Plugin Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven WAR Plugin, version 3.1.0. The WAR Plugin is responsible for collecting all artifact dependencies, classes and resources of the web application and packaging them into a web application archive. http://maven.apache.org/plugins/maven-war-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-war-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-war-plugin/download.cgi Important Note: * Maven 3.X only * JDK 6 minimum requirement Release Notes - Maven WAR Plugin - Version 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12338167 Bugs: * [MWAR-257] - Restore dependentWarExcludes/Includes since there is no alternative on global level * [MWAR-398] - Upgrade of plexus-interpolation to 1.24 to correct escaping issue. * [MWAR-400] - Upgrade the WAR lifecycle to use the maven-resources-plugin 3.0.2 * [MWAR-404] - true is not honored * [MWAR-405] - Workaround XStream incompatibility with Java9 New Feature: * [MWAR-396] - Check the existence of the web.xml based on the existence of particular classes 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: How is the best way to get an effective POM outside of a Maven Plugin?
Hi Sandra,
first question: Do you need the full resolved pom (effective pom) or
would it be enough just to simply to parse the pom file which can simply
being done using MavenXpp3Reader this would deliver the XML as a Maven
Model class which can simply being used to extract information from the
maven model...
Kind regards
Karl Heinz Marbaise
On 09/08/17 13:00, spars...@web.de wrote:
Hello,
currently, I'm working on a small tool, that needs some information of a POM
and its parent POM. I didn't want to parse them with a XML reader, so I found
that the DefaultModelBuilder can build a complete effective POM for me. Based
on a stackoverflow answer
(https://stackoverflow.com/questions/27383357/how-do-i-instantiate-mavenresolver-for-modelbuilder-usage)
I build following example:
DefaultModelBuilderFactory factory = new DefaultModelBuilderFactory();
final DefaultModelBuilder defaultModelBuilder = factory.newInstance();
ModelBuildingRequest buildRequest = new DefaultModelBuildingRequest();
buildRequest.setPomFile(Paths.get("/path/to/a/pom.xml").toFile())
.setProcessPlugins(false)
.setValidationLevel(ModelBuildingRequest.VALIDATION_LEVEL_MINIMAL);
final ModelBuildingResult modelBuildingResult =
defaultModelBuilder.build(buildRequest);
It works fine for simple POM (simple means a POM without a parent reference). But if I set a POM with a parent reference in buildRequest.setPomFile, I get following exception:
Exception in thread "main" java.lang.IllegalArgumentException: no model
resolver provided, cannot resolve parent POM groupId:artifactId:1 for POM
groupId:artifactId:version (/path/to/a/pom.xml)
at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:890)
at
org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:750)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:309)
at
com.github.sparsick.maven.effecitve.pom.maven.model.builder.ApacheMavenModelBuilder.main(ApacheMavenModelBuilder.java:17)
Another example on Stackoverflow
(https://stackoverflow.com/questions/4838591/is-there-a-library-for-reading-maven2-3-pom-xml-files)
mentions to use RepositoryModelResolver from Apache Archiva as an
implementation ModelResolver. But I don't want to introduce a dependency to
Apache Archiva in my tool.
So my questions are, is the usage of DefaultModelBuilder the best way to get an
effective POM of my project outside of a Maven Plugin? If so which
implementation I should use for the ModelResolver? If not what is the best way
to get the effective POM outside of a Maven Plugin.
Thank you and best regards,
Sandra Parsick
-
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
[ANN] Apache Maven Assembly Plugin Version 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin Version 3.1.0 The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. https://maven.apache.org/plugins/maven-assembly-plugin/ Important Note since 3.1.0: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-assembly-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-assembly-plugin/download.cgi Release Notes Maven Assembly Plugin 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12338667 Bugs: * [MASSEMBLY-643] - descriptorSourceDirectory: parameter isn't used * [MASSEMBLY-841] - Maven Assembly Plugin throws IllegalStateException when looking for project modules * [MASSEMBLY-842] - Incorrect entries created in MANIFEST/maven * [MASSEMBLY-855] - Remote repositories ignored in a multi-module project Dependency upgrades: * [MASSEMBLY-854] - Upgrade to Plexus Archiver 3.5 * [MASSEMBLY-859] - Upgrade to Plexus IO 3.0.0 * [MASSEMBLY-867] - Upgrade maven-archiver to 3.2.0 * [MASSEMBLY-868] - Upgrade plexus-utils to version 3.1.0 Improvements: * [MASSEMBLY-711] - Add support for generating XZ compressed tarballs (.tar.xz) * [MASSEMBLY-858] - don't read assembly descriptor from thread classloader but plugin classloader * [MASSEMBLY-860] - Upgrade to Java 7 Thanks to the volunteer(s) who helped to check this release. o Grzegorz Grzybek 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 Assembly EJB Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EJB Plugin Version 3.0.0 This plugin generates J2EE Enterprise Javabean (EJB) file as well as the associated client jar. https://maven.apache.org/plugins/maven-ejb-plugin/ Important Note since 3.0.0: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ejb-plugin 3.0.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ejb-plugin/download.cgi Release Notes Maven EJB Plugin 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317421=12330676 Bugs: * [MEJB-109] - JDK 9 - EA compatibility Issue Improvements: * [MEJB-72] - Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin * [MEJB-81] - Upgrade to Maven 3.X only compatiblity * [MEJB-86] - Make naming of properties consistent * [MEJB-87] - Upgrade EJB Version default to 3.1 in accordance with Java EE 6 * [MEJB-88] - Change package to org.apache.maven.plugins to prevent conflict with Maven Core * [MEJB-92] - Make separate classifier for client and main aritfact * [MEJB-93] - Prevent re-adding of main artifact twice * [MEJB-94] - Make integration tests more reliable * [MEJB-97] - Remove param properties that doesn't make sense for CLI usage * [MEJB-101] - Upgrade maven-shared-components parent to version 30 * [MEJB-108] - Upgrade bound plugins to life cycle * [MEJB-113] - Move component.xml to correct location. Dependency Upgrades: * [MEJB-114] - Upgrade plexus-utils to version 3.1.0 * [MEJB-111] - Upgrade plexus-archiver to 3.5. * [MEJB-110] - Updated maven-archiver to 3.2.0 * [MEJB-107] - Upgrade of plexus-interpolation to 1.24. * [MEJB-106] - Upgrade of maven-archiver to 3.1.1. * [MEJB-105] - Upgrade of maven-archiver to 3.1.0. * [MEJB-104] - Upgrade of maven-filtering to 3.1.1. * [MEJB-103] - Upgrade of plexus-interpolation to 1.22. * [MEJB-102] - Upgrade of plexus-archiver to 3.4. * [MEJB-100] - Upgrade plexus-archiver from 3.2 to 3.3 * [MEJB-99] - Upgrade maven-filtering to 3.1.0 * [MEJB-98] - Upgrade maven-archiver to 3.0.2 * [MEJB-96] - Upgrade plexus-archiver to 3.1.1 * [MEJB-95] - Upgrade plexus-archiver from 3.0.1 to 3.0.3 * [MEJB-91] - Upgrade plexus-archiver from 2.10.2 to 3.0.1 * [MEJB-90] - Upgrade commons-io to 2.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
[ANN] Apache Maven Shared Component: Maven Dependency Analyzer Version 1.7 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Dependency Analyzer Version 1.7 https://maven.apache.org/shared/maven-dependency-analyzer/ Analyzes the dependencies of a project for undeclared or unused artifacts. You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-analyzer 1.7 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi Release Notes Maven Archiver 1.7: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334271 Bugs: * [MSHARED-428] - maven-dependency-analyzer does not detect method references * [MSHARED-545] - maven-dependency-analyzer fails on classes containing constant long or double Improvements: * [MSHARED-412] - Change the visibility of DefaultProjectDependencyAnalyzer's buildArtifactClassMap() from private to protected * [MSHARED-470] - Upgrade maven-shared-components parent to version 22 * [MSHARED-525] - Upgrade maven-shared-components parent to version 30 Tasks: * [MSHARED-633] - Upgrade plexus-component-metadata / plexus-component-annotation to 1.7.1 * [MSHARED-634] - Using maven-inovker 2.2 to ensure it works with all Maven versions on Windows 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: Continuous Delivery with Maven now possible?
Hi Dan, I'm trying to do something in this direction starting next week... Apart from that already tested it with Eclipse Neon without any issue...(at the moment only test projects with 10-15 modules)... But it works at the moment.. In the meantime I have found one issue which is related to maven-enforcer-plugin where I already opened an issue for it [1].. Kind regards Karl Heinz [1]: https://issues.apache.org/jira/browse/MENFORCER-268 On 03/05/17 20:39, Dan Tran wrote: Hi I have been experimenting with suggestion from Karl [1] with small multi module maven project. Is there any one actually bring this to production for large scale project yet? Love to learn from your experience integration specially with Jenkins, IDE ( eclipse, intellij, Netbean) this allows us to stop using maven-release-plugin Thanks -Dan [1] http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/ - 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 Artifact Transfer Version 0.9.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Artifact Transfer Version 0.9.1. https://maven.apache.org/shared/maven-artifact-transfer/ An API to install, deploy and resolving artifacts with Maven3 You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-artifact-transfer 0.9.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-artifact-transfer/download.cgi Release Notes Maven Artifact Transfer 0.9.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12340502 Bug: * [MSHARED-602] - NoSuchMethodException using DependencyCollector with Maven 3.0 Improvements: * [MSHARED-635] - Upgrade to plexus-component-metadata/plexus-component-annotation to 1.7.1 * [MSHARED-636] - Upgrade maven-common-artifact-filters to 3.0.1 * [MSHARED-637] - Remove IOException from ProjectDeployer cause it's not thrown by the 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
[ANN] Apache Maven Shared Component: Maven Dependency Tree Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Dependency Tree 3.0.1. https://maven.apache.org/shared/maven-dependency-tree/ A tree-based API for resolution of Maven project dependencies. You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-dependency-tree 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-tree/download.cgi Release Notes Maven Dependency Tree 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333851 Bug: * [MSHARED-437] - maven-dependency-tree removes optional flag from managed dependencies Improvements: * [MSHARED-526] - Upgrade maven-shared-components parent to version 30 * [MSHARED-615] - Change characters used to diplay trees to make relationships clearer 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: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Dan,
On 10/05/17 00:59, Dan Tran wrote:
Hi
I am in the process of switching our 250+ modules to version-less poms.
There are 2 phases
1. Activated flatten poms. Every thing seems ok,
Good to hear that...
> except those external
modules which depends on a full pom.xml at maven repo. This is fixable
Can you give more details about that? What that means?
2. Switched versionless using ${revision} at a dev branch. Looking good,
except final maven memory report increases significantly by 2G for both min
and max
you mean the output of Maven at BUILD SUCCESS ?
Do you have the option to test with JConsole during the run of the build
and see how the evolution of the memory usage is going over the time?
Can you give the exact values for -Xmx, -Xms etc. and which JDK you are
using ?
Hm...Maven 3.5.0 contains a fix for larger reactors which caused a
bigger issues with large reactors (See
https://github.com/khmarbaise/maven-test-project-generator).
I'm really astonished cause Maven 3.3.9 used more memory than 3.5.0 did
(based on my tests)...Maybe the changes for the properties (revision,
changelist, sha1) might be the culprit...
No major hickup at IDEs eclipse, Intellij, and netbeans
No major means there are some? Do you have some more details...
Kind regards
Karl Heinz Marbaise
If you have any idea on the root cause of memory issue please advice
Thanks
-Dan
On Mon, May 8, 2017 at 10:27 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
Hi to all,
I think it is needed to explain that in more detail (means also to improve
the ci documentation).
Let me start with the following:
You can only use those three names "revision", "changelist" and "sha1" in
a version tag of the pom file cause they are handled special (the
foundation of its handling is given by the explanation of Bernd Eckenfeld
Thanks to Bernd).
This means in consequence the given part will not work as expected (at the
moment):
com.soebes.examples.j2ee parent
${revision}
pom
1.2.1-${buildNumber}
SNAPSHOT
If you like to make combinations you can do it like this for example:
(https://github.com/khmarbaise/javaee/tree/maven350-properties):
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
or to pickup the previous example which should look like this:
com.soebes.examples.j2ee parent
${revision}${changelist}
pom
1.2.1
-SNAPSHOT
So now your build will work as expected.
If you like to switch to release you simply do that by using the following:
mvn -Dchangelist= clean package (This will define changelist as empty).
Or if you like to give a buildNumber from commandline:
mvn -Dchangelist=-23-SNAPSHOT clean package
So to make it more convenient you can define the versions like this:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
So now I can build via (be carefull with the separator between version and
buildnumber "-"):
mvn -Dsha1=-123 clean package
By the above you can now define many combinatations on the command line:
mvn -Dchangelist= clean package
This means the command line overwrites the values of the properties which
are defined in the pom file (properties section).
You can of course remove the properties (properties section) from the pom
file at all and only define the information on command line (works in
Eclipse). But you can also define those things in ".mvn/maven.config" via
the appropriate "-D...".
So now lets come to the point about flatten-maven-plugin:
Assume you are using above proerties in kind of flavour...now you are
using my example( https://github.com/khmarbaise/
javaee/tree/maven350-properties) without the flatten-maven-plugin in the
build:
mvn install
The result of that would be having a folder in your local cache like etc.
where you find a jar file and of course a pom file: (I just picked up two
files as example):
$HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1-
SNAPSHOT/parent-1.3.1-SNAPSHOT.pom
$HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1-
SNAPSHOT/domain-1.3.1-SNAPSHOT.jar
Looks Ok so far? But let us take a look into the pom file:
The pom file will look like this:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
This looks ok so far (on the first glance)
But now I have given mvn -Drevision=2.0.0 install
There will produced also files like this:
$HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0-
SNAPSHOT/parent-2.0.0-SNAPSHOT.pom
The pom file will look like exactly the same:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
which is obviouly wrong(the same is if you omit the revision,
changelist and sha1 from prope
[ANN] Apache Maven Shared Component: Maven Reporting Impl Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Reporting Implementation 3.0.0 https://maven.apache.org/shared/maven-reporting-impl/ You should specify the version in your project: org.apache.maven.reporting maven-reporting-impl 3.0.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-reporting-impl/download.cgi Release Notes Maven Reporting Impl 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12332979 Bugs: * [MSHARED-392] - AbstractMavenReportRenderer#applyPattern(String) chokes on some specific input and produces useless segments * [MSHARED-489] - AbstractMavenReportRenderer#linkPatternedText ignores name if href is invalid * [MSHARED-608] - Remove index.html-adding block in AbstractMavenReportRenderer#getValidHref() Improvements: * [MSHARED-430] - Update JDK requirement to 1.6 / upgrade Maven Core dependencies to 3.0 * [MSHARED-582] - Upgrade maven-shared-components parent to version 30 * [MSHARED-583] - Make three digit version number * [MSHARED-642] - Upgrade to maven-shared-utils 3.2.0 Tasks: * [MSHARED-606] - Upgrade to Commons Validator 1.5.1 * [MSHARED-609] - Partially revert MSHARED-429 * [MSHARED-611] - Drop any href validation and pass as-is * [MSHARED-612] - Upgrade to Doxia 1.7 * [MSHARED-613] - Upgrade to Doxia Sitetools 1.7.4 * [MSHARED-614] - Upgrade to Maven Shared Utils 3.1.0 Wish: * [MSHARED-488] - Make input source file encoding default to platform encoding Enjos, -The Apache Maven team Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Customize the bundleFilename template used by the maven-ear-plugin?
Hi,
Have you checked the documentation about.. fileNameMapping
the following from the docs:
The file name mapping to use for all dependencies included in the EAR
file. The following values are valid standard, {code no-version}, full,
no-version-for-ejb. The standard means the filename is the artifactId
incl. the version of the artifact. The no-version means the files is
only the artifactId without the version. The full means the filename is
the groupId+artifactId+version of the artifact. The no-version-for-ejb
means the filename is the artifactId without the version in case of EJB
type.
Are you looking for something like that?
Kind regards
Karl Heinz Marbaise
On 20/06/17 19:21, Eric B wrote:
Is there a way to customize the filename used by the maven-ear-plugin for
the different modules but in a general template way?
At the moment, the bundleFilename by default seems to be:
${artifactId}-${version}.${packaging}
I would like to prepend it with a $[groupId} as well.
${groupId}-${artifactId}-${version}.${packaging}
where the groupId/artifactId/version/packaging belong to the module in
question.
However, I do not want to manually specify each module bundleFilename
manually.
Is there a way to configure this using parameterization?
ex:
maven-ear-plugin
${groupId}-${artifactId}-${version}.${packaging}
??
Anything remotely similar exist, or anyway to achieve a similar
functionality? If I use ${groupId}/etc in the module definition, it
actually uses the ${project.groupId} instead of the webmodule.groupId.
Thanks,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Jenkins builds
Hi Greg, On 19/05/17 19:12, Greg Parker wrote: I’m looking for a way to isolate builds from one another on our Jenkins server. > What I would like to do is have a common .m2 folder > for external dependencies. > For my own artifacts I’d like to install/retrieve > them to/from a separate local repository. > I suspect that this capability does not exist, but I thought I would check. The first thing what you need to understand is that the $HOME/.m2/repository is a cache location where the artifacts which are downloaded only cached to prevent repeated downloads from remote repositories.. The first step is to separate build jobs in Jenkins means that each job has it's own local cache directory which means having the local cache in the workspace ($WORKSPACE/.repository)... The second step is having a repository manager (like Nexus, Artifactory or Archiva) which handles the separation between the artifacts which are created by your own and the ones you are consuming from outside (for example from Maven Central).. There I would suggest to make this difference for your own artifacts and the artifacts which you call "external"... 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 Dependency Plugin Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.0.1. https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 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.plugins maven-dependency-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12338874 Bugs: * [MDEP-409] - dependency:tree fails for a multi-module project where one module depends on another and "mvn install" has not been run yet * [MDEP-419] - dependency:list, dependency:build-classpath and dependency:tree result with the different dependencies order * [MDEP-428] - Unpack goal does not fail build when destination could not be created and unpacks to current working directory instead * [MDEP-471] - Java 8 Method references are not detected * [MDEP-548] - The get Mojo doesn't resolve the artifact when setting transitive to false * [MDEP-565] - Upgrade maven-artifact-transfer to version 0.9.1 Documentation: * [MDEP-534] - Document format of mojo parameter 'artifact' Improvements: * [MDEP-482] - Can't use both outputProperty and outputFile in build-classpath mojo * [MDEP-563] - Print dependency:resolve-plugins output just like other goal output * [MDEP-566] - Upgrade maven-common-artifact-filter to version 3.0.1 * [MDEP-567] - Upgrade to maven-dependency-tree to 3.0.1 New Feature: * [MDEP-500] - Print GAV information in console output during dependency:resolve-plugins execution Task: * [MDEP-547] - Remove some old (404) links from site Reporters of this Release: * Elias Elmqvist Wulcan [MDEP-534] * Andrew Wright [MDEP-500] * Dagan Sandler [MDEP-482] * Ben Hardy [MDEP-471] * Dave Moten [MDEP-428] * Julien Boulay [MDEP-419] * Eric Pabst [MDEP-409] 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: Inject xml into the POM for build specific elements.
Hi, On 30/05/17 16:44, George Kopf wrote: I apologize if this topic has already been discussed. I searched all over the web and the archives and didn't find anything, but I can't believe that I'm the only person with this request. No need to apologize for asking... I'm running the CI/CD pipeline for several java projects. We're using Git, Maven, Jenkins, Sonar, and Nexus. I would like to to have the developers create and own their own POM.XML that will be used for Snapshots and Release Candidates. and in consequence also for releases ? I want to add my build specific POM elements to the effective POM for the CI process but I don't want their POM to have to include all the extra elements for Jacoco and Sonar (and whatever else we add in the future > I can do this with profiles but then their POM will have everything in it. I can do this with a parent POM but they already have a parent POM (springboot) so that they can run locally. If you have springboot as parent it might be a good choice to use spring as bom instead of as a parent...than you can control things different and better... Does it not work ? So where is the difference for a CI pom and usual pom file ? > I would have to insert my parent pom in between and that seems fragile since mine is only for CI builds. What exactly is fragile here? I can't do this with the settings.xml, on the build server, because it doesn't have all the required elements. Sure the settings.xml has a different purpose... I hope that there is something obvious that I've missed (like a Jenkins plugin) but I'm about to give up and just require the developers to live with an excessively complicated POM file. Maybe it's worth to take al look at the tiles-maven-plugin[1] which might help here... Maybe you can give an example what becomes so long or complicated ? Kind regards Karl Heinz Marbaise [1]: https://github.com/repaint-io/maven-tiles - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Work-around for antrun AttachArtifact not working in external Ant build file
Hi, if i correctly understand you have a property file for each environment and maybe some other files and a base artifact (jar/war?) now it sounds you have to build for each environment a different jar/war ? Maybe something like this could help here: https://github.com/khmarbaise/multienv-maven-plugin/ or: https://github.com/khmarbaise/iterator-maven-plugin/ Kind regards Karl Heinz Marbaise On 31/05/17 11:42, Jürgen Weber wrote: Hi Jörg, problem is, I have to build message driven beans, some 20, only difference is the queue name in the deployment descriptor. Queue names are listed in a property file. I know that Maven wants no environment specific properties in artifacts, but Sun defined the activation spec for MDBs. And the activation spec is in code or in ejb-jar.xml, both in the mdb jar. So I have to build a different MDB for each queue. And I have to iterate over the queues (which is possible in ant + JavaScript. Yuck). So I'd need to attach n artefacts, wherea in a Maven pom I have to list each artefact individually. Greetings, Jürgen Am 30.05.2017 08:45 schrieb "Jörg Schaible" <joerg.schai...@bpm-inspire.com : Hi Jürgen, Jürgen Weber wrote: What is the recommended work-around for attaching artifacts created by antrun? * forward target directory as variable to ant ? That helps if the created files should be removed in a normal "clean" phase. * build-helper-maven-plugin attach-artifact ? Definitely the proper action. http://technotes.khitrenovich.com/attach-maven-artifact- external-build-xml-file/ https://issues.apache.org/jira/browse/MANTRUN-181 Thx, Juergen Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Inject xml into the POM for build specific elements.
Hi George,
based on the comments in your example...
Are you really using Maven 2 ? Please remove it...cause it's long end of
life...
Furthermore the repositories should be defined in users settings.xml and
not inside the pom file...The distributionManagement should be done in a
corporate pom only once...
Kind regards
Karl Heinz Marbaise
On 05/06/17 14:42, George Kopf wrote:
Thank you for your help. I figured it out using the tiles-maven-plugin.
After fighting through the documentation I put together a simple tile
and pulled it into my pom.
To clarify what the docs are saying:
1. The tile will be called tile.xml, will be installed in your maven
repository along with a pom.xml that has uses the tiles-maven-plugin.
2. The project pom also uses the tiles-maven-plugin but it has the
configuration element to reference your tile.
Here is a concrete example of a tile for the jacoco plugin and then
inject the tile into your project pom.
tile.xml
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;>
org.jacoco
jacoco-maven-plugin
0.7.9
default-prepare-agent
prepare-agent
default-report
prepare-package
report
default-check
check
implementation="org.jacoco.maven.RuleConfiguration">
BUNDLE
implementation="org.jacoco.report.check.Limit">
COMPLEXITY
COVEREDRATIO
0.0
pom.xml that accompanies the tile.xml in your maven repository
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;>
4.0.0
edu.school
cdp_build_tile
1.0-SNAPSHOT
tile
snapshots
Nexus Repository
default
http://server.school.edu:8081/nexus/content/repositories/snapshots
nexus
Nexus Repository
default
http://server.school.edu:8081/nexus
true
io.repaint.maven
tiles-maven-plugin
2.10
true
build section of your project's pom
io.repaint.maven
tiles-maven-plugin
2.10
true
false
edu.school:cdp_build_tile:1.0-SNAPSHOT
On Tue, May 30, 2017 at 1:25 PM, Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:
Hi,
On 30/05/17 16:44, George Kopf wrote:
I apologize if this topic has already been discussed. I
searched all over
the web and the archives and didn't find anything, but I can't
believe that
I'm the only person with this request.
No need to apologize for asking...
I'm running the CI/CD pipeline for several java projects.
We're using Git, Maven, Jenkins, Sonar, and Nexus.
I would like to to have the developers create and own their own
POM.XML
that will be used for Snapshots and Release Candidates.
and in consequence also for releases ?
I want to add my build specific POM elements to the effective
POM for the
CI process but I don't want their POM to have to include all the
extra
elements for Jacoco and Sonar (and whatever else we add in the
future >
I can do this with profiles but then their POM will have
everything in it.
I can do this with a parent POM but they already have a parent POM
(springboot) so that they can run locally.
If you have springboot as parent it might be a good ch
Re: maven-3.2.4 location
Hi Martin, unfortunately there does not exist a distro for Maven 3.2.4 cause this has never been made it to the public... Only 3.2.5... Apart from that it looks this test in Apache Rat Plugin does not work correctly... Are you trying to fix it ? Kind regards Karl Heinz Marbaise On 06/06/17 23:14, Martin Gainty wrote: All- mvn -version Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T07:57:3 7-04:00) Maven home: /maven/maven333 Java version: 1.8.0_40, vendor: Oracle Corporation Java home: /Java/jdk1.8/jre produces this failure: Running org.apache.rat.mp.RatCheckMojoTest Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.2 sec <<< FAILURE! - in org.apache.rat.mp.RatCheckMojoTest testIt1(org.apache.rat.mp.RatCheckMojoTest) Time elapsed: 0.03 sec <<< FAILURE! junit.framework.AssertionFailedError: Maven 3.2.4 or better is required the test says current-maven-version 3.3.3 is not > Maven 3.2.4 any idea where i can locate a distro for maven 3.2.4 to make this test succeed? Thanks, Martin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Follow up: Building projects for multiple platforms
Hi,
On 17/06/17 16:23, Christofer Dutz wrote:
I Karl Heinz,
I think that’s a really good idea … unfortunately I can’t seem to be able to
run the retrolambda plugin on jars, so I might setup little projects, that use
the dependency-plugin to unpack the jars and test-jars first and run the
retrolambda on them and then package them back. Eventually this might also help
running the testsuite a second time, but with Java7. Is there a way to have
maven execute tests with a different java version (Run maven with Java 8 and
execute the tests with Java 7)? Right now I’m relying on the animalsniffer
plugin to verify my java8 and java7 jars, but the others would feel more
comfortable if we really ran the tests with a different java version.
That's example for using toolchains...
Running Maven with Java 8 and running Tests with Java 7 ...which should
be a separate module (otherwise the configuration would be a nightmare)...
If I correctly understand that scenario you have a jar build with Java 8
in a module call it "xyz-jdk8" also having tests for that ...
Now you need another module (defining toolchains using JDK 7) running
your tests with surefire (I can remember there is an option to scan
existing jars which contain tests found it: dependenciesToScan )...and
run the tests and repackage after retolambda...But you have to be sure
that the tests don't use JDK 8 specific parts cause they will run on JDK
7 ...
Should working I didn't even test it...
Kidn regards
Karl Heinz Marbaise
Chris
Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:
Hi,
I would make a separate module for java8 and run there the retrolambda-
maven-plugin and another separate module for java7 and run there the
retrolambda-
maven-plugin as well...than you can make a separate jar file for each ...
No need for different executions of the compiler plugins etc. and
separte output folders configurations etc.
This needs to use toolchains and then you can run with a single
run...all of them...
Just coming into my mind...
If i correctly understand you are developing in JDK 8 and than you would
like to offer a package which supports JDK 7 ..
So making a module with JDK 8 code in it pluse unit tests...
A separate module which uses the JDK 8 code as dependency and using the
retrolambda plugin and maybe some supplemental tests on it...using JDK 7
which can be handled with Toolchain...
Kind regards
Karl Heinz Marbaise
On 16/06/17 14:25, Justin Georgeson wrote:
> Instead of tweaking the version, I would configure an executions of the
compiler plugins compile and testcompile goals to a separate output folders, like
${build.directory}${file.separator}classes-java7 and
${build.directory}${file.separator}test-classes-java7 and then an execution of the
jar plugin to create/attach a jar with classifier set to 'java7'.
>
>
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
>
> That way you can have both versions build/deploy together in one
pipeline with the same version.
>
> You can use properties in the version if you use Maven 3.5 with some
other tricks, there was a recent thread on the list about it
>
> http://www.mail-archive.com/users@maven.apache.org/msg139475.html
>
>
>> -Original Message-
>> From: Christofer Dutz [mailto:christofer.d...@c-ware.de]
>> Sent: Friday, June 16, 2017 3:54 AM
>> To: Maven List <users@maven.apache.org>
>> Subject: [EXTERNAL] Follow up: Building projects for multiple platforms
>>
>> External Sender: Use caution with links/attachments.
>>
>>
>>
>> Hi,
>>
>> A short follow up question regarding my last one.
>> In the Edgent maven build, which I am working on, we need to produce
java8,
>> java7 and android versions of jars. This is done by running the
retrolambda-
>> maven-plugin on the classes when building the java7 version. To make the
>> dependency resolution work correctly with all variants we decided to
use the
>> normal version number for the java8 output and add a suffix of “–java7”
to the
>> version in case of a java7 build (for SNAPSHOT versions the “-java7” is
included
>> between the version and the “SNAPSHOT”). In order to be able to switch
the
>> versions by selecting profiles, I used variables for the artifact
versions.
>> As I know variables for versions of parent poms is a really bad idea
(Don’t even
>> know if it works), I setup the project to have constant versions in the
parent
[ANN] Apache Maven Shared Component: Maven Shared Utils Version 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Shared Utils Version 3.2.0 https://maven.apache.org/shared/maven-shared-utils/ You should specify the version in your project: org.apache.maven.shared maven-shared-utils 3.2.0 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.2.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12338026 Bugs: * [MSHARED-574] - UT failure on Windows: utils.io.Java7SupportTest createAndReadSymlink * [MSHARED-610] - PrettyPrintXMLWriter internally uses java.io.PrintWriter without checking for any errors. * [MSHARED-617] - StreamFeeder should flush OutputStream * [MSHARED-618] - CommandLineCallable does not always call the 'runAfterProcessTermination' runnable. * [MSHARED-619] - StreamFeeder silently ignores exceptions. * [MSHARED-622] - CommandLineCallable silently ignores exceptions thrown from the stdin processor (StreemFeeder). * [MSHARED-630] - Javadoc of several classes still references Maven 3.4.0 for color support Improvements: * [MSHARED-587] - remove logger level API from MessageBuilder * [MSHARED-620] - CommandLineCallable should defer starting threads until called. * [MSHARED-621] - CommandLineCallable should calculate process timeouts using 'System.nanoTime' instead of 'System.currentTimeMillis'. * [MSHARED-639] - Removed prerequisites cause it is not a plugin Task: * [MSHARED-623] - Deprecation of methods 'close' and 'flush' of class 'StreamPumper'. Enjos, -The Apache Maven team Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Follow up: Building projects for multiple platforms
Hi,
I would make a separate module for java8 and run there the retrolambda-
maven-plugin and another separate module for java7 and run there the
retrolambda-
maven-plugin as well...than you can make a separate jar file for each ...
No need for different executions of the compiler plugins etc. and
separte output folders configurations etc.
This needs to use toolchains and then you can run with a single
run...all of them...
Just coming into my mind...
If i correctly understand you are developing in JDK 8 and than you would
like to offer a package which supports JDK 7 ..
So making a module with JDK 8 code in it pluse unit tests...
A separate module which uses the JDK 8 code as dependency and using the
retrolambda plugin and maybe some supplemental tests on it...using JDK 7
which can be handled with Toolchain...
Kind regards
Karl Heinz Marbaise
On 16/06/17 14:25, Justin Georgeson wrote:
Instead of tweaking the version, I would configure an executions of the
compiler plugins compile and testcompile goals to a separate output folders,
like ${build.directory}${file.separator}classes-java7 and
${build.directory}${file.separator}test-classes-java7 and then an execution of
the jar plugin to create/attach a jar with classifier set to 'java7'.
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
That way you can have both versions build/deploy together in one pipeline with
the same version.
You can use properties in the version if you use Maven 3.5 with some other
tricks, there was a recent thread on the list about it
http://www.mail-archive.com/users@maven.apache.org/msg139475.html
-Original Message-
From: Christofer Dutz [mailto:christofer.d...@c-ware.de]
Sent: Friday, June 16, 2017 3:54 AM
To: Maven List <users@maven.apache.org>
Subject: [EXTERNAL] Follow up: Building projects for multiple platforms
External Sender: Use caution with links/attachments.
Hi,
A short follow up question regarding my last one.
In the Edgent maven build, which I am working on, we need to produce java8,
java7 and android versions of jars. This is done by running the retrolambda-
maven-plugin on the classes when building the java7 version. To make the
dependency resolution work correctly with all variants we decided to use the
normal version number for the java8 output and add a suffix of “–java7” to the
version in case of a java7 build (for SNAPSHOT versions the “-java7” is included
between the version and the “SNAPSHOT”). In order to be able to switch the
versions by selecting profiles, I used variables for the artifact versions.
As I know variables for versions of parent poms is a really bad idea (Don’t even
know if it works), I setup the project to have constant versions in the parent
poms and only use these for configuring the reactor and the plugins – no
dependencies are handled here. The build is working nicey, unfortunately the
build is outputting hundreds of warnings like this:
[WARNING] Some problems were encountered while building the effective model
for org.apache.edgent.analytics:edgent-analytics-sensors:jar:1.2.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
org.apache.edgent.analytics:edgent-analytics-sensors:${edgent.version},
/Users/christoferdutz/Projects/Apache/Edgent/incubator-
edgent/analytics/sensors/pom.xml, line 31, column 12
Is there a “maven way” (TM) to achieve this sort of thing without the warnings?
Chris
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
-
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: Profiling Maven Compilation for a multi-module project
Hi, first I would suggest to check with: https://github.com/khmarbaise/maven-buildtime-profiler On 09/06/17 15:02, Debraj Manna wrote: Just cross-posting this from stack overflow <https://stackoverflow.com/questions/44458414/profiling-maven-compilation-for-a-multi-module-project> :- I have a multi module maven project which is taking a little too much time. What does "too much time" mean? About which time are we talking about... Can some one let me know if there is a way it is possible for me to see which step in maven is taking how much time. Also is it possible to see which steps are getting executed in parallel relative to which step? Maybe I misunderstand your question but what about comparing: mvn clean package against: mvn -T clean package ? Kind regards Karl Heinz Marbaise I am executing maven with -T 4. - Maven Version 3.5.0 Thanks, tuk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi to all,
I think it is needed to explain that in more detail (means also to
improve the ci documentation).
Let me start with the following:
You can only use those three names "revision", "changelist" and "sha1"
in a version tag of the pom file cause they are handled special (the
foundation of its handling is given by the explanation of Bernd
Eckenfeld Thanks to Bernd).
This means in consequence the given part will not work as expected (at
the moment):
com.soebes.examples.j2ee parent
${revision}
pom
1.2.1-${buildNumber}
SNAPSHOT
If you like to make combinations you can do it like this for example:
(https://github.com/khmarbaise/javaee/tree/maven350-properties):
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
or to pickup the previous example which should look like this:
com.soebes.examples.j2ee parent
${revision}${changelist}
pom
1.2.1
-SNAPSHOT
So now your build will work as expected.
If you like to switch to release you simply do that by using the following:
mvn -Dchangelist= clean package (This will define changelist as empty).
Or if you like to give a buildNumber from commandline:
mvn -Dchangelist=-23-SNAPSHOT clean package
So to make it more convenient you can define the versions like this:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
So now I can build via (be carefull with the separator between version
and buildnumber "-"):
mvn -Dsha1=-123 clean package
By the above you can now define many combinatations on the command line:
mvn -Dchangelist= clean package
This means the command line overwrites the values of the properties
which are defined in the pom file (properties section).
You can of course remove the properties (properties section) from the
pom file at all and only define the information on command line (works
in Eclipse). But you can also define those things in ".mvn/maven.config"
via the appropriate "-D...".
So now lets come to the point about flatten-maven-plugin:
Assume you are using above proerties in kind of flavour...now you are
using my example(
https://github.com/khmarbaise/javaee/tree/maven350-properties) without
the flatten-maven-plugin in the build:
mvn install
The result of that would be having a folder in your local cache like
etc. where you find a jar file and of course a pom file: (I just picked
up two files as example):
$HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1-SNAPSHOT/parent-1.3.1-SNAPSHOT.pom
$HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1-SNAPSHOT/domain-1.3.1-SNAPSHOT.jar
Looks Ok so far? But let us take a look into the pom file:
The pom file will look like this:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
This looks ok so far (on the first glance)
But now I have given mvn -Drevision=2.0.0 install
There will produced also files like this:
$HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0-SNAPSHOT/parent-2.0.0-SNAPSHOT.pom
The pom file will look like exactly the same:
com.soebes.examples.j2ee
parent
${revision}${sha1}${changelist}
pom
1.6
1.6
1.3.1
-SNAPSHOT
which is obviouly wrong(the same is if you omit the revision,
changelist and sha1 from properties part).
If you like to consume this pom file it will fail cause this can't be
correctly solve (where is the -Drevision=2.0.0 gone?)
That is the reason you need the flatten-maven-plugin cause it replace
the propreties in the version tag with it's current version (can do more
but that's a different story) and produce a correct pom file:
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns="http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
4.0.0
com.soebes.examples.j2ee
parent
2.0.0-SNAPSHOT
pom
Apache License 2.0
http://www.apache.org/licenses/LICENSE-2.0.txt
repo
which is now consumeable by any kind of tool etc. also Maven itself for
example as a dependency
I hope it makes this more clear...
If not please ask/suggest improvements about the docs or what you need
to know
Kind regards
Karl Heinz Marbaise
On 08/05/17 14:29, Stephen Connolly wrote:
On Mon 8 May 2017 at 03:58, Eric Benzacar <e...@benzacar.ca> wrote:
Hi,
Interesting. Would something like this be functional then? It seems to
work, but I don't know if it is working as expected, or by fluke:
com.soebes.examples.j2ee parent
${revision} pom ..
1.2.1-${buildNumber}
SNAPSHOT
Then at the command line, I can either set the buildNumber in the case of a
build:
mvn installl -DbuildNumber=12345
This works, but I don't know if I am
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Dan,
On 05/05/17 02:30, Dan Tran wrote:
is flatten-maven-plugin threadsafe? if not, we have a problem with large
project where multhreaded build is a must have
maven 3.5 displays a warning on flatten-maven-plugin not thread safe
I need to take a look...can you file in a ticket on flatten-maven-plugin..
Thanks.
Kind regards
Karl Heinz Marbaise
Thanks
-D
On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
Hi,
On 04/05/17 22:52, Justin Georgeson wrote:
Also I believe the partial reactor switches don't work for Tycho builds.
You mean -pl ..option I suppose?
As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things wrong
which results in not working things like this..
Kind regards
Karl Heinz Marbaise
-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
External Sender: Use caution with links/attachments.
Hard to train developers to break old habits but thanks... :-)
-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
Ah now I see the issue.
If you have a multi module build you should use
mvn -pl moduleToBuild clean install
but from root location and don't change into the module directory cause
this can't work like this.
Kind regards
Karl Heinz Marbaise
On 04/05/17 22:08, Robert Patrick wrote:
Hi Karl,
If I define the revision property in the top-level POM, I cannot refer
to it in the module POMs' elements *and* still retain the ability
to build from the module directory, right? I tried this and it failed
because it was unable to resolve the revision property variable.
C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
in
https://urldefense.proofpoint.com/v2/url?u=http-3A__a=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA= was cached in the local reposito ry, resolution will
not be reattempted until the update interval of repo1 has el apsed or
updates are forced and 'parent.relativePath' points at wrong local POM @
line 7, column 13 @ [ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project oracle.jcs.lifecycle:util:[unknown-version]
(C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unk
nown-ver
sion]: Failure to find
oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
local repo sitory, resolution will not be reattempted until the update
interval of repo1 ha s elapsed or updates are forced and
'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
[Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e swit ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please rea d the following articles:
[ERROR] [Help 1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
XoHWM-jV5GAbTtEvug-bc=
delException
Did I miss something?
Thanks,
Robert
-Original Message-----
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
On 04/05/17 21:55, Robert Patrick wrote:
With 3.
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Dan,
On 08/05/17 18:48, Dan Tran wrote:
Hi Karl
I think you already made changes to the the plugin, but will file ticket
to make it official
https://github.com/mojohaus/flatten-maven-plugin/issues/41
Already done by your ticket..
Kind regards
Karl Heinz
-D
On Thu, May 4, 2017 at 10:09 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
Hi Dan,
On 05/05/17 02:30, Dan Tran wrote:
is flatten-maven-plugin threadsafe? if not, we have a problem with large
project where multhreaded build is a must have
maven 3.5 displays a warning on flatten-maven-plugin not thread safe
I need to take a look...can you file in a ticket on flatten-maven-plugin..
Thanks.
Kind regards
Karl Heinz Marbaise
Thanks
-D
On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
Hi,
On 04/05/17 22:52, Justin Georgeson wrote:
Also I believe the partial reactor switches don't work for Tycho builds.
You mean -pl ..option I suppose?
As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things
wrong
which results in not working things like this..
Kind regards
Karl Heinz Marbaise
-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
External Sender: Use caution with links/attachments.
Hard to train developers to break old habits but thanks... :-)
-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
Ah now I see the issue.
If you have a multi module build you should use
mvn -pl moduleToBuild clean install
but from root location and don't change into the module directory cause
this can't work like this.
Kind regards
Karl Heinz Marbaise
On 04/05/17 22:08, Robert Patrick wrote:
Hi Karl,
If I define the revision property in the top-level POM, I cannot refer
to it in the module POMs' elements *and* still retain the
ability
to build from the module directory, right? I tried this and it failed
because it was unable to resolve the revision property variable.
C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the
POMs:
[FATAL] Non-resolvable parent POM for
oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
in
https://urldefense.proofpoint.com/v2/url?u=http-3A__a=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA= was cached in the local reposito ry, resolution will
not be reattempted until the update interval of repo1 has el apsed or
updates are forced and 'parent.relativePath' points at wrong local POM
@
line 7, column 13 @ [ERROR] The build could not read 1 project ->
[Help 1]
[ERROR]
[ERROR] The project oracle.jcs.lifecycle:util:[unknown-version]
(C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
oracle.jcs.lifecycle:util:[unk
nown-ver
sion]: Failure to find
oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
local repo sitory, resolution will not be reattempted until the update
interval of repo1 ha s elapsed or updates are forced and
'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
[Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e swit ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please rea d the following articles:
[ERROR] [Help 1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6
Re: Continuous Delivery with Maven now possible?
Hi Robert, On 04/05/17 21:55, Robert Patrick wrote: With 3.5, you can now use a variable *but* that variable > has to be accessible to the POM prior to finding its > parent so the only solution is to move the > version number outside the POM hierarchy and into a -D defined variable. Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...). > While this works, it seems to have some undesirable > aspects to it. In my opinion, it would be better if > Maven could find a way to resolve this issue > without resorting to -Ds to specify the > value of the variable. > I am not sure it is possible but I also worry > about moving the version number outside the POM... Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is: 1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy 2.) It is part of the project structure so that it can be managed in the project's source control system 3.) It cannot be overridden at build time with command-line arguments. 4.) Has a mechanism by which to reference it from all the necessary locations within the POMs Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it? -Original Message- From: Eric Benzacar [mailto:e...@benzacar.ca] Sent: Thursday, May 04, 2017 12:53 PM To: Maven Users List Subject: Re: Continuous Delivery with Maven now possible? I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk= 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me. I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file. From my perspective/view a pom file should be idempotent. That is every single build of a given NON-SNAPSHOT pom file should finish with the same build. But by moving a release number or version number outside of the pom, it eliminates this need. Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time. By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value. Consequently, I can still not be 100% confident that a pom delivered a particular version. I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches. In that way, my developers can fix the version number, but my build system can manipulate the revision property. Does anyone know if there is a plugin that will allow for that? Thanks, Eric On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote: How about everybody read their mail? (see below) On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote: Hi Dan, Karl & everyone, See Karl's Blog Link, please? […] On 03/05/17 20:39, Dan Tran wrote: Hi I have been experimenting with suggestion from Karl [1] with small multi module maven project. […] [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0i ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4 AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y& e= t-a-version-in-it/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi,
On 04/05/17 22:52, Justin Georgeson wrote:
Also I believe the partial reactor switches don't work for Tycho builds.
You mean -pl ..option I suppose?
As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things
wrong which results in not working things like this..
Kind regards
Karl Heinz Marbaise
-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
External Sender: Use caution with links/attachments.
Hard to train developers to break old habits but thanks... :-)
-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
Ah now I see the issue.
If you have a multi module build you should use
mvn -pl moduleToBuild clean install
but from root location and don't change into the module directory cause this
can't work like this.
Kind regards
Karl Heinz Marbaise
On 04/05/17 22:08, Robert Patrick wrote:
Hi Karl,
If I define the revision property in the top-level POM, I cannot refer to it in the
module POMs' elements *and* still retain the ability to build from the
module directory, right? I tried this and it failed because it was unable to resolve
the revision property variable.
C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
in
https://urldefense.proofpoint.com/v2/url?u=http-3A__a=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA= was cached in the local reposito ry, resolution will not be
reattempted until the update interval of repo1 has el apsed or updates are forced and
'parent.relativePath' points at wrong local POM @ line 7, column 13 @ [ERROR] The
build could not read 1 project -> [Help 1] [ERROR]
[ERROR] The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
sion]: Failure to find
oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
local repo sitory, resolution will not be reattempted until the update
interval of repo1 ha s elapsed or updates are forced and
'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
[Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e swit ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please rea d the following articles:
[ERROR] [Help 1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
XoHWM-jV5GAbTtEvug-bc=
delException
Did I miss something?
Thanks,
Robert
-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
On 04/05/17 21:55, Robert Patrick wrote:
With 3.5, you can now use a variable *but* that variable
> has to be accessible to the POM prior to finding its > parent so
the only solution is to move the > version number outside the POM
hierarchy and into a -D defined
variable.
Which is not true. You can define the property inside the pom file if you like
and can overwrite the version via command line (-Drevision=...).
> While this works, it seems to have some undesirable > a
Re: Continuous Delivery with Maven now possible?
Sorry was to fast with the send button... On 04/05/17 22:01, Karl Heinz Marbaise wrote: Hi Robert, On 04/05/17 21:55, Robert Patrick wrote: With 3.5, you can now use a variable *but* that variable has to be accessible to the POM prior to finding its parent so the only solution is to move the version number outside the POM hierarchy and into a -D defined variable. Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...). While this works, it seems to have some undesirable aspects to it. In my opinion, it would be better if Maven could find a way to resolve this issue without resorting to -Ds to specify the value of the variable. I am not sure it is possible but I also worry about moving the version number outside the POM... Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is: 1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy Can you explain what exactly you mean by this? 2.) It is part of the project structure so that it can be managed in the project's source control system You can simply use the .mvn/maven.config file for it... 3.) It cannot be overridden at build time with command-line arguments. Which contradicts the whole idea of making it simple to change the version... 4.) Has a mechanism by which to reference it from all the necessary locations within the POMs Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it? What is the advantage of having a complete different file here? The change on the other hand shouldn't be that hard ... Kind regards Karl Heinz Marbaise -Original Message- From: Eric Benzacar [mailto:e...@benzacar.ca] Sent: Thursday, May 04, 2017 12:53 PM To: Maven Users List Subject: Re: Continuous Delivery with Maven now possible? I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk= 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me. I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file. From my perspective/view a pom file should be idempotent. That is every single build of a given NON-SNAPSHOT pom file should finish with the same build. But by moving a release number or version number outside of the pom, it eliminates this need. Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time. By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value. Consequently, I can still not be 100% confident that a pom delivered a particular version. I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches. In that way, my developers can fix the version number, but my build system can manipulate the revision property. Does anyone know if there is a plugin that will allow for that? Thanks, Eric On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote: How about everybody read their mail? (see below) On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote: Hi Dan, Karl & everyone, See Karl's Blog Link, please? […] On 03/05/17 20:39, Dan Tran wrote: Hi I have been experimenting with suggestion from Karl [1] with small multi module maven project. […] [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0i ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4 AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y& e= t-a-version-in-it/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen
Re: Continuous Delivery with Maven now possible?
tly cause If the Maven project will go further this is a necessary step and to make other changes possible (Changing the pom model etc.) but this is complete different discussions. What you mentioned about have the versions-maven-plugin is correct and it needed to be improved to let the plugin only change the properties like revision,changelist,sha1 to be changed is something which I already thougt about which would mean only to change a single pom file (usually the project parent in a multi module build). After thinking about the "Idempotence" part I came to the conclusion that this is given, cause the process of building the pom file will result in the same artifact. The only difference I can see is that I might name it differently which means I just put a different "label" (Version) on it (or better we interpret that part of the filename as a version)... Kind regards Karl Heinz Marbaise Thanks, Eric On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote: How about everybody read their mail? (see below) On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote: Hi Dan, Karl & everyone, See Karl's Blog Link, please? […] On 03/05/17 20:39, Dan Tran wrote: Hi I have been experimenting with suggestion from Karl [1] with small multi module maven project. […] [1] http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou t-a-version-in-it/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Continuous Delivery with Maven now possible?
Hi Robert,
Ah now I see the issue.
If you have a multi module build you should use
mvn -pl moduleToBuild clean install
but from root location and don't change into the module directory cause
this can't work like this.
Kind regards
Karl Heinz Marbaise
On 04/05/17 22:08, Robert Patrick wrote:
Hi Karl,
If I define the revision property in the top-level POM, I cannot refer to it in the
module POMs' elements *and* still retain the ability to build from the
module directory, right? I tried this and it failed because it was unable to resolve
the revision property variable.
C:\rpatrick\work\projects\jcs-las\util>mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local reposito
ry, resolution will not be reattempted until the update interval of repo1 has el
apsed or updates are forced and 'parent.relativePath' points at wrong local POM
@ line 7, column 13
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
sion]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local repo
sitory, resolution will not be reattempted until the update interval of repo1 ha
s elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 7, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException
Did I miss something?
Thanks,
Robert
-Original Message-----
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
On 04/05/17 21:55, Robert Patrick wrote:
With 3.5, you can now use a variable *but* that variable
> has to be accessible to the POM prior to finding its > parent so the only
solution is to move the > version number outside the POM hierarchy and into a -D
defined
variable.
Which is not true. You can define the property inside the pom file if you like
and can overwrite the version via command line (-Drevision=...).
> While this works, it seems to have some undesirable
> aspects to it. In my opinion, it would be better if
> Maven could find a way to resolve this issue
> without resorting to -Ds to specify the
> value of the variable.
> I am not sure it is possible but I also worry
> about moving the version number outside the POM...
Maybe Maven should consider a mechanism by which the project version number can
be defined in a separate location that is:
1.) Well-known so that all resolution can happen directly by interacting with
this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the
project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations
within the POMs
Maybe something like an optional .mvn/project.version file and a variable that
cannot be overridden to refer to it?
-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca]
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?
I've read through Karl's blog
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand
the approach, there is still one critical issue that bothers me. I think this
actually reopens an old thread that circulated on this list a few months ago,
but it related to the Idempotence of a pom file.
>From my perspective/view a pom file should be idempotent. That is every
single build of a given NON-SNAPSHOT pom file should finish with the same build.
But by moving a release number or version number outside of the p
Re: Jenkins builds
Hi Greg, On 19/05/17 23:55, Greg Parker wrote: Thanks for the reply , > Although having a separate .m2 folder is quite possible and would address my issue, > it’s something I’m trying to avoid for performance reasons. > Pulling down all the external dependencies from Archiva, > or central repository, for each project takes too long > and takes up too much space. Archiva should proxy central repository and you should never directly pick dependencies from Maven Central only via a proxies repositores... The time is an issue but only for the first time ...you can use updates in version control so it's not necessary to download the deps for each build (I don't know how long your builds take? We have build about max 15 minutes release build and ci build takes 6 minutes) Disk space ? Is that really a question? disk space is cheap...currently each of our builds takes 15 GiB of disk space for CI and our release build take 54 GiB...currently having 5 branches in parallel having some other builds as well..in total we are talking about approx 1.5 TiB... It's important to check how long the downloads really take it might be a task to improve your infrastructure... > Our builds have a customer implementation > component which means we have many > builds for many customers. what does "many " builds mean? 10, 100, 1000 ? different builds? > What I would like to have is a common .m2 folder for external dependencies, > > and a build specific .m2 folder with just the build output. In Maven only a single location for the cache exists.. Apart from that I really don't understand your concerns having your own artifacts separated from those others? They are separated by groupId/artifactId/version etc. What kind of problem are you trying to solve? Furthermore in the minute you are using a single cache part for several build all those builds are coupled via this cache... Another thing is important here. This means you are coupling those builds to a particular build node if this cache does not exist your node can't run the build there...That's why the build cache in the workspace is the best option... Kind regards Karl Heinz Marbaise Something like: ~/.m2/repository /log4j /commons-io /… $WORKSPACE1/.m2/repository /customer1-lib /build-lib /... $WORKSPACE2/.m2/repository /customer2-lib /build-lib /... That way I don’t have to pull down all the common stuff into a fresh .m2 for each build. On May 19, 2017, at 5:36 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi Greg, On 19/05/17 19:12, Greg Parker wrote: I’m looking for a way to isolate builds from one another on our Jenkins server. What I would like to do is have a common .m2 folder for external dependencies. For my own artifacts I’d like to install/retrieve them to/from a separate local repository. I suspect that this capability does not exist, but I thought I would check. The first thing what you need to understand is that the $HOME/.m2/repository is a cache location where the artifacts which are downloaded only cached to prevent repeated downloads from remote repositories.. The first step is to separate build jobs in Jenkins means that each job has it's own local cache directory which means having the local cache in the workspace ($WORKSPACE/.repository)... The second step is having a repository manager (like Nexus, Artifactory or Archiva) which handles the separation between the artifacts which are created by your own and the ones you are consuming from outside (for example from Maven Central).. There I would suggest to make this difference for your own artifacts and the artifacts which you call "external"... 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: Project dependencies vs plugin dependencies for a mojo looking at the project
Hi Adam, On 12/09/17 18:05, Adam Hardy wrote: Hi, when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? The question which comes to my mind: Why do you need the dependencies of your own ? Aren't the defined in your plugin's pom ? Maybe I misunderstand a thing here? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Can you please explain what you are trying to accomplish ? Thanks Adam 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 JMod Plugin Version 3.0.0-alpha-1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JMod Plugin Version 3.0.0-alpha-1 release https://maven.apache.org/plugins/maven-jmod-plugin/ The JMod Plugin is used to create JMod Files http://openjdk.java.net/jeps/261 The plugin has got the major version 3 to make clear this plugin is only for Maven 3+. * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jmod-plugin 3.0.0-alpha-1 true You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jmod-plugin/download.cgi Release Notes Maven JMod Plugin 3.0.0-alpha-1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321433=12341363 Improvements: * [MJMOD-1] - Upgrade dependencies in component * [MJMOD-2] - Classpath / Modulepath using the dependencies of the current project. * [MJMOD-3] - Changed moduleName into outputFileName to prevent confusion * [MJMOD-5] - Usage of moduleName in describe/list goal / classpath usage in create goal 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: Project dependencies vs plugin dependencies for a mojo looking at the project
Hi, On 13/09/17 23:29, Adam Hardy wrote: On 12/09/17 18:05, Adam Hardy wrote: when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? The question which comes to my mind: Why do you need the dependencies of your own ? Aren't the defined in your plugin's pom ? Maybe I misunderstand a thing here? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Can you please explain what you are trying to accomplish ? The users of my plugin define a dependency which the mojo unpacks and extracts certain files from. You know that such a plugin already exists? maven-dependency-plugin:unpack / unpack-dependencies ? https://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html Furthermore the question is why do you need only certain files from it ? At the moment, I have coded the plugin to take the groupId and artifactId of this dependency via the mojo config. Sounds good so far...so counting one place... something like this. ... .. .. .. Group to be unpacked artifact of being upackage ... This strikes me as doppel gemoppelt I assume you mean duplicated ? ( I understand that; But only a few people here on the list have german background). for the user to put that info in twice. >I thought I could just enter it once as a plugin dependency in the user project pom - assuming it would be the only one. What do you think will the usage as plugin depenency change ? You can give this via the plugin configuration and which means your plugin must resolve it's dependencies and make a required download for it...which can be easily done by using a maven-artifact-transfer[3]. But I don't see the requirement to define it in two place ? Kind regards Karl Heinz Marbaise [1]: https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html [2]: https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html [3]: https://maven.apache.org/shared/maven-artifact-transfer/install-project.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Plugin Version 3.0.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.0.2. https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 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.plugins maven-dependency-plugin 3.0.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.0.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12338874 Bugs: * [MDEP-571] - JDK9: Issue with list goal fails with java.lang.NoSuchMethodException * [MDEP-573] - "purge-local-repository -Dinclude" does not work as described * [MDEP-577] - dependency:list doesn't show module name * [MDEP-583] - Failed to create release on JDK 8 based on JavaDoc issues Improvements: * [MDEP-578] - Add message in case module name cannot be extracted from jar. * [MDEP-580] - Recognize source of name for automatic modules Task: * [MDEP-581] - Downgrade maven-artifact-transfer to release version instead of SNAPSHOT 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
[ANN] Apache Maven JLink Plugin Version 3.0.0-alpha-1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JLink Plugin Version 3.0.0-alpha-1 release https://maven.apache.org/plugins/maven-jlink-plugin/ The plugin has got the major version 3 to make clear this plugin is only for Maven 3+. * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jlink-plugin 3.0.0-alpha-1 true You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jlink-plugin/download.cgi Release Notes Maven Jlink Plugin 3.0.0-alpha-1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12338874 Dependency upgrade: * [MJLINK-2] - Upgrade several plugins to get a working site generation 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 WAR Plugin Version 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven WAR Plugin, version 3.2.0. The WAR Plugin is responsible for collecting all artifact dependencies, classes and resources of the web application and packaging them into a web application archive. http://maven.apache.org/plugins/maven-war-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-war-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-war-plugin/download.cgi Important Note: * Maven 3.X only * JDK 7 minimum requirement Release Notes - Maven WAR Plugin - Version 3.2.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12341372 Bug: * [MWAR-407] - Binary files are modified during web.xml filtering; revert MWAR-404 Dependency upgrades: * [MWAR-409] - Upgrade maven-archiver to 3.2.0 / plexus-archiver 3.5 * [MWAR-410] - Upgrade plexus-utils to version 3.1.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: Release plugin: why are my releases tagged as snapshots?
Hi Chris,
If i correctly see in your pom file you have defined Git URL in the root
location of your project as well as in the sub module which is simply
wrong...
Cause you are trying to release a multi module build which means these
things should only be at the root of that...
Furthermore your child (skinny-wars-javaee5/pom.xml) duplicates many
things...Apart from that your child (which is not the case) based on the
things in Git repo:
UTF-8
1.8
1.8
${org.checkerframework:jdk8:jar}
github
io.github.pr0methean.betterrandom
BetterRandom
0.9.2.15-SNAPSHOT
BetterRandom
So in the end the parent is an aggregator...So my question if why are
you trying to release a single module ? Why not the whole in one go?
Furthermore you see the difference in the version ?
BTW: I'm not sure but there have been improvements made in more recent
versions of maven-release-plugin (but I'm not sure if really support
releases of childs at the moment?)...
Kind regards
Karl Heinz Marbaise
On 10/09/17 20:52, Chris wrote:
I've been informed at https://issues.sonatype.org/browse/OSSRH-34445 that:
"The logs show that the build is trying to checkout the release branch, but
whatever it checks out probably still has 0.9.2.7-SNAPSHOT as the version
instead of 0.9.2.8
Once the build things it's building a SNAPSHOT version, it has no choice
but to deploy to the Snapshots repo"
I've changed my release shell script a little bit since then to properly
integrate the Proguard step, but I'm still having the same issue. A more
up-to-date output log is here: https://pastebin.ca/3866418 The script I'm
running is at
https://github.com/Pr0methean/BetterRandom/blob/66901100812a4bca1243ac7639c34a837d6aecfa/release.sh
and
the pom.xml is at
https://github.com/Pr0methean/BetterRandom/blob/master/betterrandom/pom.xml
.
What do I need to do differently to generate a release with a non-snapshot
tag?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin: why are my releases tagged as snapshots?
Hi Chris,
based on the log output:
[INFO] Executing: /bin/sh -c cd
/home/ubuntu/workspace/betterrandom/target/checkout && git checkout
BetterRandom-0.9.2.14
[INFO] Working directory:
/home/ubuntu/workspace/betterrandom/target/checkout
[INFO] Executing: /bin/sh -c cd
/home/ubuntu/workspace/betterrandom/target/checkout && git ls-files
[INFO] Working directory:
/home/ubuntu/workspace/betterrandom/target/checkout
[INFO] Invoking perform goals in directory
/home/ubuntu/workspace/betterrandom/target/checkout/betterrandom
[INFO] Executing goals 'deploy'...
[INFO] Executing: /bin/sh -c cd
/home/ubuntu/workspace/betterrandom/target/checkout/betterrandom &&
/usr/share/maven/bin/mvn -s /tmp/release-settings4188024815796759751.xml
deploy --no-plugin-updates -DperformRelease=true -f pom.xml
[WARNING] Command line option -npu is deprecated and will be
removed in future Maven versions.
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the
effective model for
io.github.pr0methean.betterrandom:BetterRandom:jar:0.9.2.11-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
[WARNING]
[WARNING] It is highly recommended to fix these problems because
they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[WARNING]
[INFO]
[INFO]
There is being checkout a tag BetterRandom-0.9.2.14 which seemed to
contain the wrong version...Have you ever had such a tag ? May be done
via command line ?
Furthermore the output on Github shows something:
https://github.com/Pr0methean/BetterRandom/commit/0ce146b58ab0f18da93d665e8604dfa15eebdf09
Revert "Merge coverage and post-Proguard testing into same run."
This reverts commit a7f1da8.
instead of the usual messages like:
"[maven-release-plugin] prepare release ..."
Haven't you deleted this tag if something has failed with the release on
the remote ?
Kind regards
Karl Heinz Marbaise
On 10/09/17 21:52, Chris wrote:
Actually, the parent pom.xml can probably be deleted now. I was trying
to keep the child one together with a sibling pom.xml, which builds some
benchmarks (that I'm not going to push to Maven Central since they
wouldn't be useful as a library). I'll do that and see if it makes any
difference. You'll notice that release.sh descends into a subfolder to
do the build; so do my other build scripts.
On Sun, Sep 10, 2017 at 12:45 PM Karl Heinz Marbaise <khmarba...@gmx.de
<mailto:khmarba...@gmx.de>> wrote:
Hi Chris,
If i correctly see in your pom file you have defined Git URL in the root
location of your project as well as in the sub module which is simply
wrong...
Cause you are trying to release a multi module build which means these
things should only be at the root of that...
Furthermore your child (skinny-wars-javaee5/pom.xml) duplicates many
things...Apart from that your child (which is not the case) based on the
things in Git repo:
UTF-8
1.8
1.8
${org.checkerframework:jdk8:jar}
github
io.github.pr0methean.betterrandom
BetterRandom
0.9.2.15-SNAPSHOT
BetterRandom
So in the end the parent is an aggregator...So my question if why are
you trying to release a single module ? Why not the whole in one go?
Furthermore you see the difference in the version ?
BTW: I'm not sure but there have been improvements made in more recent
versions of maven-release-plugin (but I'm not sure if really support
releases of childs at the moment?)...
Kind regards
Karl Heinz Marbaise
On 10/09/17 20:52, Chris wrote:
> I've been informed at
https://issues.sonatype.org/browse/OSSRH-34445 that:
> "The logs show that the build is trying to checkout the release
branch, but
> whatever it checks out probably still has 0.9.2.7-SNAPSHOT as the
version
> instead of 0.9.2.8
>
> Once the build things it's building a SNAPSHOT version, it has no
choice
> but to deploy to the Snapshots repo"
>
> I've changed my release shell script a little bit since then to
properly
> integrate the Proguard step, but I'm still having the same issue.
A more
> up-to-date output log is here: https://pastebin.ca/3866418 The
script I'm
> running is at
>
https://github.com/Pr0methean/BetterRandom/blob/66901100812a4bca1243ac7639c34a837d6aecfa/release.sh
> and
> the pom.xml is at
>
https://github.com/Pr0methean/BetterRandom/blob/master/betterra
Re: Specifying version range for dependency causes resolver error; maven-metadata.xml on central looks wrong - how do I make ranges work?
Hi,
based on the feedback I got here:
https://issues.sonatype.org/browse/MVNCENTRAL-2721
It could be only a little time to be fixed in Maven Central..
Kind regards
Karl Heinz Marbaise
On 26/09/17 13:12, Karl Heinz Marbaise wrote:
Hi,
On 26/09/17 13:02, Christian Balzer wrote:
Hi all,
I have a pom.xml file of a legacy program that declares a dependency
on an Apache Commons' xml-resolver:xml-resolver via dependency
management and a property. The pom file looks essentially like this:
1.2
xml-resolver
xml-resolver
${xml-resolver.version}
xml-resolver
xml-resolver
${xml-resolver.version}
This works; version 1.2 does exist:
http://central.maven.org/maven2/xml-resolver/xml-resolver/1.2/
We now wanted to move to dependency ranges, to automatically pull in
the latest minor and patch releases:
https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
However, when I change the version range to [1.2,2.0) (i.e. all
release versions from 1.2 inclusive to 2.0 exclusive) I get the
following error message:
[ERROR] Failed to execute goal on project bar: Could not resolve
dependencies for project com.example.foo:bar:pom:1.0-SNAPSHOT:
Failed to collect dependencies at
xml-resolver:xml-resolver:jar:[1.2,2.0): No versions available for
xml-resolver:xml-resolver:jar:[1.2,2.0) within specified range ->
[Help 1]
I also tried version [1.2] (exact version range) with the same result.
After some googeling, I had a look at maven central's manifest for
that artifact, located at
http://central.maven.org/maven2/xml-resolver/xml-resolver/maven-metadata.xml
It turns out that the metadata only specifies version 1.1:
1.1
Is that the reason maven can't resolve the artifact with the
dependency range given?
Does that mean the metadata on maven central is corrupted?
That looks like that.
I have filed in a ticket for that problem.
https://issues.sonatype.org/browse/MVNCENTRAL-2721
Kind regards
Karl Heinz Marbaise
If so, where do I report the issue to get it fixed?
Is there another way to make this work (e.g. by asking our Nexus
mirror to do some magic)?
And last but not least: are there ever scenarios where previously
published versions are removed from the metadata file on central (but
not the jar files themselves)?
There are in extraordanary circumstances under which this can
happen...but it is extremely rare...(Only based on special license
issues...)...
I found 9 other artifacts so far that have the same issue...
Which artifacts ? With the above problem releated to the metadata ?
NB: When I run java -jar maven-artifact-3.1.0.jar [versions...] as
described on https://maven.apache.org/pom.html#Version_Order_Testing I
get an error message:
no main manifest attribute, in maven-artifact-3.1.0.jar
This works only from Maven 3.2.5+ not before...
See release notes for detail...
Kind regards
Karl Heinz Marbaise
I'm running Apache Maven 3.3.9 and that's the latest jar in my local
repo. (The docs specify version 3.3.9 for the actual jar.) Do I need
to pull the latest one, or is something else broken there?
Kind regards,
Christian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Hi, On 01/10/17 15:35, Alex O'Ree wrote: Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. based on the pom files there two definitions one for maven-surefire-plugin 2.4 and one for maven-surefire-plugin 2.15...which I would suggest clean up... Kind regards Karl Heinz Marbaise Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Hi, On 01/10/17 15:35, Alex O'Ree wrote: Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. Are you really using maven-surefire-plugin version 2.4 which is from 2008 ? Have you correctly defined to use maven-surefire-plugin 2.4 somewhere ? First I would suggest to keep Maven 3.3.9 and upgrade maven-surefire-plugin to newer versions and see if it does not break anything... Afterwards I would upgrade to Maven 3.5.0... Kind regards Karl Heinz Marbaise Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. Switching to maven 3.3.9 will work though - 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: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Hi Alex, I've also seen that the project inherits from apache parent version 13 which is 4 years old...in the meantime we are at version 18... Kind regards Karl Heinz Marbaise See: http://maven.apache.org/pom/asf/ On 02/10/17 00:57, Alex O'Ree wrote: after further investigation, it's probably not a maven issue. On Sun, Oct 1, 2017 at 11:15 AM, Alex O'Ree <alexo...@apache.org> wrote: I thought i had cleaned that up. One of those, if it's not broke don't fix it, kind of things. On Sun, Oct 1, 2017 at 10:24 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: Hi, On 01/10/17 15:35, Alex O'Ree wrote: Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. based on the pom files there two definitions one for maven-surefire-plugin 2.4 and one for maven-surefire-plugin 2.15...which I would suggest clean up... Kind regards Karl Heinz Marbaise Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Specifying version range for dependency causes resolver error; maven-metadata.xml on central looks wrong - how do I make ranges work?
Hi,
On 26/09/17 13:02, Christian Balzer wrote:
Hi all,
I have a pom.xml file of a legacy program that declares a dependency
on an Apache Commons' xml-resolver:xml-resolver via dependency
management and a property. The pom file looks essentially like this:
1.2
xml-resolver
xml-resolver
${xml-resolver.version}
xml-resolver
xml-resolver
${xml-resolver.version}
This works; version 1.2 does exist:
http://central.maven.org/maven2/xml-resolver/xml-resolver/1.2/
We now wanted to move to dependency ranges, to automatically pull in
the latest minor and patch releases:
https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
However, when I change the version range to [1.2,2.0) (i.e. all
release versions from 1.2 inclusive to 2.0 exclusive) I get the
following error message:
[ERROR] Failed to execute goal on project bar: Could not resolve dependencies for
project com.example.foo:bar:pom:1.0-SNAPSHOT: Failed to collect dependencies at
xml-resolver:xml-resolver:jar:[1.2,2.0): No versions available for
xml-resolver:xml-resolver:jar:[1.2,2.0) within specified range -> [Help 1]
I also tried version [1.2] (exact version range) with the same result.
After some googeling, I had a look at maven central's manifest for
that artifact, located at
http://central.maven.org/maven2/xml-resolver/xml-resolver/maven-metadata.xml
It turns out that the metadata only specifies version 1.1:
1.1
Is that the reason maven can't resolve the artifact with the
dependency range given?
Does that mean the metadata on maven central is corrupted?
That looks like that.
I have filed in a ticket for that problem.
https://issues.sonatype.org/browse/MVNCENTRAL-2721
Kind regards
Karl Heinz Marbaise
If so, where do I report the issue to get it fixed?
Is there another way to make this work (e.g. by asking our Nexus
mirror to do some magic)?
And last but not least: are there ever scenarios where previously
published versions are removed from the metadata file on central (but
not the jar files themselves)?
There are in extraordanary circumstances under which this can
happen...but it is extremely rare...(Only based on special license
issues...)...
I found 9 other artifacts so far that have the same issue...
Which artifacts ? With the above problem releated to the metadata ?
NB: When I run java -jar maven-artifact-3.1.0.jar [versions...] as
described on https://maven.apache.org/pom.html#Version_Order_Testing I
get an error message:
no main manifest attribute, in maven-artifact-3.1.0.jar
This works only from Maven 3.2.5+ not before...
See release notes for detail...
Kind regards
Karl Heinz Marbaise
I'm running Apache Maven 3.3.9 and that's the latest jar in my local
repo. (The docs specify version 3.3.9 for the actual jar.) Do I need
to pull the latest one, or is something else broken there?
Kind regards,
Christian
-
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: How does maven handle Java module dependencies?
Hi, On 27/08/17 14:38, Robert Scholte wrote: Hi Russ, this is how it works: in case there's a module descriptor, the module-path with be used. With the help of plexus-java it is possible to divide all jars over the module-path and classpath. This mechanism is implemented in the maven-compiler-plugin (will do an official release soon with the latest improvements), other plugins can/should use this too. This means that you actually don't need to change anything in your pom.xml. With the module descriptor and all the dependencies there's enough information to decide which jars belong on the modulepath and which on the classpath. So in the end there's no need for new scopes anymore, although that was my first thought as well. To create an installer, I think you're referring to JLink. Karl Heinz is preparing the maven-jlink-plugin. This is not an installer it is a Java Run-Time Image which uses JLink (maven-jlink-plugin, maven-jmod-plugin)... An example how it looks like at the moment can be seen[1] and in [2] how the most recent code works... The first alpha release of maven-jlink-plugin and maven-jmod-plugin is planned within a few weeks... Kind regards Karl Heinz Marbaise [1]: http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/ [2]: https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example thanks, Robert On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold <russell.g...@oracle.com> wrote: I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system? case 1) I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages. case 2) I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals case 3) I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info. So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned? Thanks, Russ - 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 Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to make a mojo run after "deploy" completion?
Hi, On 03/09/17 18:21, Steinar Bang wrote: I would like to run a mojo to run after deploy has completed successfully, to notify some OSGi bundles running in karaf, that they should update themselves with new deployed snapshots in a maven repository. The problem is that the deploy lifecycle phase is the last lifecycle phase of the default lifecycle http://maven.apache.org/ref/3.5.0/maven-core/lifecycles.html Ie. there is no "post-deploy" lifecycle phase to run my mojo in. We are thinking already of such things and which might be part of Maven 4+...[1] [1]:https://issues.apache.org/jira/browse/MNG-5666 Is there a way to order mojos bound to the same lifecycle, so that my mojo will only run after maven-deploy-plugin has done its thing? Usually if you bind a another plugin to the life cycle all plugins from the default life cycle will run firstif your plugin is bound to an life cycle like "deploy" (Preferrably only run my mojo if deployment has been successful, though I could live with running it every time) 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 both buildnumber-maven-plugin and maven-release-plugin
Hi, the question is what the real problem is? Can you have an example project which shows the problem? Or can you describe more in detail what exactly does not work or not work like you expect it.. 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: Special parameters - sha1
Hi,
I will give some more details cause I have created the docs /
implementation and you mentioned my blog ;-)..
On 14/11/17 03:12, Eric B wrote:
Following a long thread on this list, and a blog by khmarbaise (
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
I'm still a little confused as to exactly what is allowed in the special
version tags for a maven pom.
I know and realize that the 3 allowable tags are:
- ${revision}
- ${sha1}
- ${changelist}
However, from the thread and the blog, it seems that these properties
cannot be dependent on any other properties.
Correct.
For example, this is fine:
${revision}-${sha1}
where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
However, based on the further docs at
https://maven.apache.org/maven-ci-friendly.html, this design would fail:
which is not mentioned in the docs...
${revision}-${sha1}
${buildNumber}
and call it as -Drevision=1.2.3 -DbuildNumber=9
The problem is simply that buildNumber is not correctly overwritten from
command and not correctly handled duing the model reading /
interpolation at the correct time within Maven Core at the moment...
At the moment this is only implemented for those special three
properties...which already has performance impacts...which is also a
reason not making that possible for all kind of properties...at the
moment...
Is anyone able to shed some light as to why this would be the case? Why
can a property not be used to compute on of the 3 special vars?
My use case is that I want to supply the build number to all my builds, but
only append it to the version if a specific profile is enabled. In my
mind, it would be simple - make the sha1 property empty by default, and in
my specific profile, set it to the buildnumber. But based on my
understanding, this would fail.
Is my only option in that case to design it as:
${artifactVersion}
${revision}
buildNumber
${revision}-${sha1}
What is the reason for this limitation? Is there any chance that this
limitation will be removed in the future?
The question is why do you need a profile for this? You can define
defaults in .mvn/maven.config ...and during a CI build you can give
other information via command line ?
I don't see the need for a profile ? Maybe you can elaborate a little
bit more what the real problem 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: Problems Using ANTLR4 (Packaged Classes Not Found in Generated Code)
Hi, can make a test project on Github/gitlab etc. Kind regards Karl Heinz Marbaise On 29/10/17 05:13, R0b0t1 wrote: Is any more information needed? The files are generated properly by ANTLR, but I can not compile the generated files. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /C:/Users/R0b0t1/Documents/Code/grammar-mvn/target/generated-sources/antlr4/GrammarParser.java:[32,29] cannot find symbol symbol: class Vocabulary location: class LangParser And so on. I followed http://www.antlr.org/api/maven-plugin/latest/usage.html and http://www.antlr.org/api/maven-plugin/latest/dependency-info.html. I am not very smart. I have spent a few days trying to figure out the best way to compile a Java project. I have tried Ant, CMake, and now Maven. Maven seems like the easiest to use, but I can not solve this problem I am having. Respectfully, R0b0t1. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unrecognised tag: 'testResources'
Hi,
On 30/10/17 11:07, Ernst Reissner wrote:
Hi all,
When I run mvn resources:testResources i obtain
|Non-parseable POM
/home/ernst/Software/pom.xml:Unrecognisedtag:'testResources'|
Can you show the full pom file somewhere best would be on Github ...
The problem seems
|${resourceDir}trueoctave/octavercoctave/java.opts
${tstResourcesDir}true*.rml|
Just try a mvn clean
and see the output...
To be honest I don't see the need for such a complicated filtering/non
filtering setup in resources...can you elaborate in detail what the
problem is?
As long as I had only the tag resources, all was fine. Now that i added
testResources, i have the problem. The resources plugin is configured as
follows:
|org.apache.maven.pluginsmaven-resources-plugin3.0.2\|
I have the impression, that this problem is about maven itself not about
the resources plugin, right? I use maven 3.5.0.
Who can help?
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: [EXTERNAL] Re: how to use both buildnumber-maven-plugin and maven-release-plugin
Hi, On 24/10/17 15:59, Justin Georgeson wrote: I want to enforce in every build (not just release builds) > that the working copy is pristine > (ie doCheck=true for buildnumber plugin), On a CI server or locally ? but release:prepare dirties the working copy before running 'clean verify'. Of course it does cause it changes the pom files to represent the correct version...and commit this state of the change back to version control... So when I run release:prepare the buildnumber plugin fails. I can work around it by running 'mvn release:prepare > -Darguments="-Dmaven.buildNumber.doCheck=false"' but that just seems hacky, so I was curious if there's a better way. You know about the release:prepare goal what it is exactly doing ? http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html Maybe I misunderstand your question but it sounds like you are trying to resolve a thing which has been solved by maven-release-plugin already?... Kind regards Karl Heinz Marbaise Looks like if I configure a default property value for maven.buildNumber.doCheck to true, then I can have a profile activate when file release.properties exists to set the doCheck property to false, and that gets me through release:prepare. Any pitfalls I might be walking into with something like that? -Original Message----- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Tuesday, October 24, 2017 4:30 AM To: Maven Users List <users@maven.apache.org>; Justin Georgeson <justin.george...@halliburton.com> Subject: [EXTERNAL] Re: how to use both buildnumber-maven-plugin and maven-release-plugin External Sender: Use caution with links/attachments. Hi, the question is what the real problem is? Can you have an example project which shows the problem? Or can you describe more in detail what exactly does not work or not work like you expect it.. 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 both buildnumber-maven-plugin and maven-release-plugin
Hi,
On 25/10/17 08:50, Stephen Coy wrote:
Hi Pascal,
Unfortunately this method results in pom files being deployed with releases
that do not have corresponding versions in them.
In fact, the version is literally:
${revision}
This results in build warnings for consumers of the released artifact.
If you like to use a property for the version. First you have to use
Maven 3.5.0+ and furthermore flatten-maven-plugin as described in the
docs about that[1].
Kind regards
Karl Heinz Marbaise
[1]: http://maven.apache.org/maven-ci-friendly.html
Cheers,
Steve C
On 24 Oct 2017, at 8:27 pm, Pascal <pascal.gr...@gmail.com> wrote:
For me it's hard to understand the problem you are having, it might help to
specify the exact errors you are getting.
If you are willing to try something other than the release plugin, have a
look at https://axelfontaine.com/blog/dead-burried.html
Cheers,
Pascal
2017-10-23 18:40 GMT+02:00 Justin Georgeson <
justin.george...@halliburton.com>:
The 'clean verify' invoked by release:prepare fails in
buildnumber-maven-plugin because pom.xml is modified. I can pass arguments
to release:prepare have buildnumber-maven-plugin skip the check for
modifications, but that check is one of the main motivations for using it
in the first place. What are other people doing here?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Welcome Christian Stein to the Apache Maven Team
Hello Christian, welcome... Kind regards Karl Heinz Marbaise On 07/05/18 22:01, Robert Scholte wrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Christian Stein (sor) has been voted in as a new Apache Maven committer. Christian, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Assembly EJB Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EJB Plugin Version 3.0.1 This plugin generates J2EE Enterprise Javabean (EJB) file as well as the associated client jar. https://maven.apache.org/plugins/maven-ejb-plugin/ Important Note since 3.0.1: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ejb-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ejb-plugin/download.cgi Release Notes Maven EJB Plugin 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317421=12334440 Bug: * [MEJB-115] - Wrong default EJB version stated on Usage page Tasks: * [MEJB-116] - Clarify "properties removed" on intro page of site * [MEJB-117] - Remove reference to old wiki page on intro page * [MEJB-118] - Remove "J2EE" from plugin description and site Dependency upgrades: * [MEJB-119] - Upgrade parent to 31 * [MEJB-120] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MEJB-121] - Add documentation information for GitHub 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 WAR Plugin Version 3.2.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven WAR Plugin, version 3.2.1. The WAR Plugin is responsible for collecting all artifact dependencies, classes and resources of the web application and packaging them into a web application archive. http://maven.apache.org/plugins/maven-war-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-war-plugin 3.2.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-war-plugin/download.cgi Important Note: * Maven 3.X only * JDK 7 minimum requirement Release Notes - Maven WAR Plugin - Version 3.2.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12341729 Improvement: * [MWAR-412] - Upgrade parent to 31 Task: * [MWAR-401] - Upgrade the WAR lifecycle to use the maven-compiler-plugin 3.7.0 Dependency upgrades: * [MWAR-413] - Upgrade xstream to 1.4.10 * [MWAR-414] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MWAR-416] - Upgrade plexus-archiver to 3.6.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 EAR Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin Version 3.0.1 This plugin generates Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). https://maven.apache.org/plugins/maven-ear-plugin/ Important Note since 3.0.1: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ear-plugin/download.cgi Release Notes Maven EAR Plugin 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422=12342882 Improvements: * [MEAR-265] - Add documentation information for GitHub * [MEAR-266] - Upgrade mave-surefire/failsafe-plugin 2.21.0 Dependency upgrade: * [MEAR-268] - Upgrade plexus-archiver to 3.6.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: From where to download Maven?
Hi Martin,
just a small hint. Don't use M2_HOME anymore cause only the entry in
PATH for the bin directory is needed...
Furthermore the settings.xml should only being used or create in users
home directory...
Apart from that the given locations in the settings.xml with codehaus
in it are not valid cause codehaus is long time a go shutted down...
Kind regards
Karl Heinz Marbaise
On 13/05/18 17:23, Martin Gainty wrote:
follow anders recommendation of maven install (latest version of ) location:
https://maven.apache.org/download.cgi
Maven – Download Apache Maven<https://maven.apache.org/download.cgi>
maven.apache.org
Apache Maven 3.5.3 is the latest release and recommended version for all users.
Disk Approximately 10MB is required for the Maven installation itself. In
addition to that, additional disk space will be used for your local Maven
repository. The size of your local repository will vary depending on ...
tar xzvf apache-maven-3.5.3-bin.tar.gz
Alternatively use your preferred archive extraction tool.
* Add the bin directory of the created directory apache-maven-3.5.3 to the
PATH environment variable
Add M2_HOME environment variable to point to base location of maven
* Confirm with mvn -v in a new shell. The result should look similar to
$M2_HOME/conf/settings.xml will usually have repositories listed for snapshots,
plugins and dependencies if not you can use something like:
be aware that everyone who uses maven will have these settings
codehausSnapshots
Codehaus Snapshots
false
always
warn
true
never
fail
http://snapshots.maven.codehaus.org/maven2
default
if you want to specify repository locations for your OWN usage of maven try
updating repositories @
${user.home}/.m2/settings.xml
HTH
Martin
__
From: Andrew M <bluemind2...@yahoo.com.INVALID>
Sent: Sunday, May 13, 2018 11:04 AM
To: users@maven.apache.org
Subject: From where to download Maven?
Hi Guys,
I have started with Continuous Integration with Jenkins and there is a
precursor to Chapter 2/Module 2.
It states about refreshing knowledge about Maven Ant and war deployments, I
have a question in regards to Maven download and installation:
I went to the below url:
http://apache.mirror.amaze.com.au/maven/
From the above URL there is a list of so many directories, what exactly to
download and how to install?
http://maven.apache.org/download.cgi#Installation <-- Unfortunately doesn't
indicate installation steps.
Any guidance would be much appreciated.
Thank you
-
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 Dependency Analyzer Version 1.10 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Dependency Analyzer Version 1.10 https://maven.apache.org/shared/maven-dependency-analyzer/ Analyzes the dependencies of a project for undeclared or unused artifacts. You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-analyzer 1.10 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi Release Notes Maven Dependency Analyzer 1.10: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12343067 Dependency upgrade: * [MSHARED-718] - Upgrade asm to most recent version 6.1.1 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 Dependency Plugin Version 3.1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.1.1 https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 3.1.1: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.1.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.1.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12343248 Bug: * [MDEP-607] - maven-dependency-plugin:3.1.0:analyze failed.: NullPointerException Dependency upgrades: * [MDEP-611] - Upgrade plexus-archiver to 3.6.0 * [MDEP-612] - Upgrade maven-dependency-analyzer to 1.10 * [MDEP-614] - Upgrade file-management to 3.0.0 Many thanks to all reporters/contributors/testers of this release. Reporters: * MDEP-607: Filipe Sousa 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 WAR Plugin Version 3.2.2 Released
The Apache Maven team is pleased to announce the release of the
Apache Maven WAR Plugin, version 3.2.2.
The WAR Plugin is responsible for collecting all artifact dependencies, classes
and resources of the web application and packaging them into a web application
archive.
https://maven.apache.org/plugins/maven-war-plugin/
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-war-plugin
3.2.2
You can download the appropriate sources etc. from the download page:
https://maven.apache.org/plugins/maven-war-plugin/download.cgi
Important Note:
* Maven 3.X only
* JDK 7 minimum requirement
Release Notes - Maven WAR Plugin - Version 3.2.2
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12343264
Bug:
* [MWAR-303] - filtering of ${project.developers[0].id} does not work
Dependency upgrade:
* [MWAR-417] - Upgrade to plexus-interpolation to version 1.25
Many thanks to all reporters/contributors/testers of this release.
Voters:
* Gabriel Belingueres
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 Help Plugin Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Help Plugin Version 3.1.0 https://maven.apache.org/plugins/maven-help-plugin/ You should specify the version in your project's plugin configuration: Important Notes since Version 3.0.0 * Maven 3+ only * JDK 7 minimum requirement org.apache.maven.plugins maven-help-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-help-plugin/download.cgi Release Notes Maven Help Plugin 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522=12343004 New Feature: * [MPH-144] - Add ability to print mvn help:evaluate output to stdout in quiet mode Improvement: * [MPH-151] - Add documentation information for GitHub Tasks: * [MPH-145] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MPH-146] - JavaDoc Issues / Code cleanups Dependency upgrades: * [MPH-147] - plexus-interactivity-api to 1.0-alpha-6 * [MPH-148] - Upgrade xstream to 1.4.10 * [MPH-149] - Upgrade jdom-legacy to jdom2 2.0.6 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: ear without libraries
Hi, Are you using skinnyWars option? Do you have dependencies in your ear project? Can you show your pom file? On 08/06/18 19:58, Aitor Iturriondobeitia wrote: hello i am trying to use the maven ear for building my ear but into the ear the lib directory must be without libraries but i cannot make it how must y use the ear pluging for exclude all dependencies ? thanks 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: When does a Maven plugin uses the POM in the current directory?
Hi,
you can do that in different flavours..
by using an execution id like `default-cli` this will be used during the
execution on command line (using the current configuration) furthermore
since Maven 3.3.1 you can use things like[1]:
mvn version:set@Id
which means you can do a different configuration for command line in the
pom file:
Just by simply separating them by different id
org.codehaus.mojo
versions-maven-plugin
2.5.
default-cli
...
second-cli
[1]: https://maven.apache.org/docs/3.3.1/release-notes.html
On 13/06/18 08:08, Anders Hammar wrote:
If you put the configuration of the plugin within the pluginManagement
section of the pom, it will be used if you execute the plugin from command
line.
/Anders
On Tue, Jun 12, 2018 at 5:21 PM Oliver B. Fischer
wrote:
Dear all,
I use the Versions Maven Plugin to check for updates of my dependencies.
Therefore I added the following lines to my pom.xml:
org.codehaus.mojo
versions-maven-plugin
${versions-plugin.version}
classpath:///rules.xml
versionrules
versionrules
1-SNAPSHOT
But this configuration is not used if I run the Versions Maven Plugin in
the same directory as the pom.xml. The only way to my own configuration
is to put this plugin configuration in a profil and execute this profil
during the Maven run.
Is there a way to run the Versions plugin on the commandline and to
configure it via the pom.xml?
Bye,
Oliver
-
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: Notice: Java 6 and 7 users: SSL Protocol upgrades coming to Central
Hi Brian, I have posted the same here: https://blogs.apache.org/maven/entry/notice-java-6-and-7 Kind regards Karl Heinz Marbaise On 21/05/18 20:22, Brian Fox wrote: The march of standards continues unabated. Legacy TLS protocols 1.0 and 1.1 have varying weaknesses that could lead to a false sense of security. In June, in an effort to raise security and comply with modern standards, the insecure TLS 1.0 & 1.1 protocols will no longer be supported for SSL connections to Central. This should only affect users of Java 6 that are also using https to access central, which by our metrics is less than .2% of users. At the same time, this conversion will allow Central to support HTTP/2 with potential performance gains for modern http clients. The details about why, when and what you need to do are documented at the link below. As questions come up, we will continue to update this faq. If there is specific information required for non-maven build systems, please send it along and we will include that as well. https://central.sonatype.org/articles/2018/May/04/discontinue-support-for-tlsv11-and-below/ I've posted the same content as a blog to make it easier to disseminate here: https://blog.sonatype.com/enhancing-ssl-security-and-http/2-support-for-central - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Plexus Interpolation Version 1.25 Released
Hi to all, we appreciate to announce the new release of Plexus Interpolation Version 1.25. https://codehaus-plexus.github.io/plexus-interpolation/ The list of fixed issues can be seen via the following link: https://github.com/codehaus-plexus/plexus-interpolation/milestone/1?closed=1 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: Parent not deployed/
Hi, On 30/05/18 20:44, Naveen Swamy wrote: Hi, I am trying to refactor our maven packages, we were publishing way too many packages and I am fat jar which contains everything because that's how our users use. We are testing the package on the staging repo and running into issues where it is asking for the parent pom file. I wanted to know if we also have to publish the parent package or if there is a way around it ? this would also we have recursively release all parents packages? The package in question is here, i want to only release the platform specific packages. https://github.com/nswamy/incubator-mxnet/tree/v1.2.0/scala-package/assembly What is the problem with deploying / releasing the parent poms as well? What is the issue with them? 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: Release a snapshot version
Hi, On 27/06/18 12:25, Ravindranatha Panikar, Renjith wrote: I am planning to use maven release plugin for automating the release of our application. There can be two types of releases. Normal Release: Current code should be tagged. Pom.xml should get updated to 'next-version-SNAPSHOT'. Artifacts should be public to remote repository. SNAPSHOT Release: it can contain one or more hot fixes which we would like to release on an immediate basis. Tagging is not required here. Pom.xml should not be updated. Artifacts should be published to remote repository with name 'ProjectName- next-version-SNAPSHOT'.jar' I know maven-release-plugin can perform the 'Normal Release'. But is there any way I can handle the 'SNAPSHOT release'? A SNAPSHOT and a release is a contradiction in itself..cause a SNAPSHOT versions is not a release cause it can change etc. whereas a release is immutable can not change... Maybe I misunderstand your question but based on this it makes no sense to me... 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 ACR Plugin Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven ACR Plugin Version 3.1.0. This plugin generates J2EE Application Client file. https://maven.apache.org/plugins/maven-acr-plugin/ Important Note: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-acr-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-acr-plugin/download.cgi Release Notes Maven ACR Plugin 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317020=12334755 Bugs: * [MACR-41] - Upgrade of plexus-interpolation 1.24 to correct escaping issue. * [MACR-44] - Upgrade mave-surefire/failsafe-plugin 2.21.0 Improvement: * [MACR-30] - Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin Dependency upgrades: * [MACR-28] - Upgrade plexus-archiver from 3.0.1 to 3.0.3 * [MACR-29] - Upgrade plexus-archiver from 3.0.3 to 3.1 * [MACR-31] - Upgrade plexus-archiver from 3.1 to 3.1.1 / maven-archiver from 3.0.0 to 3.0.2 * [MACR-32] - Dependency updates. * [MACR-33] - Upgrade to maven-plugins version 30 * [MACR-34] - Upgrade of 'plexus-archiver' to version 3.3. * [MACR-35] - Upgrade maven-archiver to 3.1.0 * [MACR-36] - Upgrade maven-filtering to 3.1.1 * [MACR-37] - Upgrade plexus-interpolation to 1.22 * [MACR-38] - Upgrade maven-archiver to 3.1.0 * [MACR-39] - Upgrade of plexus-archiver to 3.4. * [MACR-40] - Upgrade of maven-archiver to 3.1.1. * [MACR-42] - Upgrade parent to 31 * [MACR-43] - Upgrade plexus-utils 3.1.0 / maven-archiver / plexus-achiver * [MACR-45] - Upgrade plexus-archiver to 3.6.0 * [MACR-46] - Upgrade plexus-interpolation to 1.25 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: No compiler is provided in this environment - how to stop this error ?
Hi, do you really want to work with SNAPSHOT versions? I would prefer to work with releases instead .. org.springframework.boot spring-boot-starter-parent 2.0.3.RELEASE which is available from Central... So you don't need any definition of repositories in your pom file...if you have just remove them... Furthermore I see in the screenshots that there are compilation errors...furthermore to drill down to the problem it would be more helpful to test on plain command line...and from within Eclipse etc.. Kind regards Karl Heinz Marbaise On 24/06/18 06:02, Karen Goh wrote: Thanks Jeff. It is working now. However, I'd like to know is it possible to change the version to 2.0.3 from 2.1.0 in maven pom.xml ? org.springframework.boot spring-boot-starter-parent 2.0.3.BUILD-SNAPSHOT I have tried to change on the advice of a forum member in Java Range. But, I keep receiving error message : Project build error: Non-resolvable parent POM for com.Superhi5:SpringBootHi5CRUD:0.0.1-SNAPSHOT: Could not transfer artifact org.springframework.boot:spring- boot-starter-parent:pom:2.0.3.BUILD-SNAPSHOT from/to spring-snapshots (https://repo.spring.io/snapshot): repo.spring.io and 'parent.relativePath' points at no local POM I tried various ways like doing mvn clean, mvn purge local repositories, update and then sue the below as per stackoverflow suggestion to change the version but to no avai. https://books.google.de/books?id=yEqrMNX3LAgC=PA124=IoIU0MYUp-=huettermann+automatic+releasing=de=PA123#v=onepage=huettermann%20automatic%20releasing=false Hope you could let me know how should I go about changing the version without all these errros. Tks & rgds, Karen On Fri, 6/22/18, Jeff MAURY wrote: Subject: Re: No compiler is provided in this environment - how to stop this error ? To: "Maven Users List" , "Karen Goh" Date: Friday, June 22, 2018, 7:24 PM Your JAVA_HOME must point a jdk not à jre Le ven. 22 juin 2018 à 13:16, Karen Goh a écrit : > Hi, > > I have been trying to tackle the below error without avail. > > In my due diligence, I have done the necessary checking like making sure > that the environment is run on 1.8JDK > > Please see screenshot > > https://ibb.co/eopTVT > > https://ibb.co/g2wE4o > > I got the below when I did the following: > > 1st, I did run maven clean > 2nd, I did maven install > > And the error appeared. > > > > --- maven-resources-plugin:3.0.1:resources (default-resources) @ > SpringBootHi5CRUD --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 1 resource > [INFO] Copying 0 resource > [INFO] > [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ > SpringBootHi5CRUD --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 6 source files to > C:\Users\Karen.Goh\eclipse-workspace\SpringBoothi5\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] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 16.031 s > [INFO] Finished at: 2018-06-22T18:53:34+08:00 > [INFO] Final Memory: 20M/182M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile > (default-compile) on project SpringBootHi5CRUD: Compilation failure > [ERROR] No compiler is provided in this environment. Perhaps you are > running on a JRE rather than a JDK? > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > > If I run using -X switch, I get the below error : > > [ERROR] Failed to execute goal > org.springframework.boot:spring-boot-maven-plugin:2.1.0.BUILD-SNAPSHOT:run > (default-cli) on project SpringBootHi5CRUD: An exception occurred while > running. null: InvocationTargetException: Error creating bean with name > 'ar
Re: after upgrade to maven 3.5.4 release plans fail when trying to upload source jar twice
Hi Jim, On 29/06/18 21:15, Jim Sellers wrote: Hi all. We have nexus reject over writing releases. After upgrading maven from 3.5.3 to 3.5.4, the release plan tries to upload the -sources jars twice, failing the build. This is for a multi module project. pom \- ear \- war Example error message [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project TestProjectWAR: Failed to deploy artifacts: Could not transfer artifact ca.gc.ic.test:TestProjectWAR:jar:sources:1.6.0 from/to internal-nexus ( https://my-nexus.example.com/maven-proxy/content/repositories/internal-released): Failed to transfer file: https://my-nexus.example.com/maven-proxy/content/repositories/internal-released/com/example/TestProjectWAR/1.6.0/TestProjectWAR-1.6.0-sources.jar. Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1] Revering maven to 3.5.3 fixes it. Anyone else seeing this behaviour? Do you have a sample project which reproduces the issue (github / bitbucket / gitlab) and very important the whole pom filesalso a log file would be helpful... 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.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Resources Plugin Version 3.1.0. https://maven.apache.org/plugins/maven-resources-plugin/ The Resources Plugin handles the copying of project resources to the output directory. There are two different kinds of resources: main resources and test resources. The difference is that the main resources are the resources associated to the main source code while the test resources are associated to the test source code. Thus, this allows the separation of resources for the main source code and its unit tests. Important Note: * Maven 3.X only * JDK 7 minimum requirement Reporters for this release: * Michel Barret [MRESOURCES-247] You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-resources-plugin 3.1.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.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317827=12338834 Bug: * [MRESOURCES-242] - Fix integration test include-git-ignore Improvement: * [MRESOURCES-247] - Improve WARNING message about encoding. Tasks: * [MRESOURCES-243] - Upgrade mave-surefire/failsafe-plugin 2.20.1 * [MRESOURCES-245] - Upgrade to JDK 7 minimum. Dependency upgrades: * [MRESOURCES-241] - Upgrade parent to 31 * [MRESOURCES-244] - Upgrade plexus-utils 3.1.0 * [MRESOURCES-248] - Add documentation information for GitHub 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: Auto-increment semantic version number for CD pipeline with git and docker
Hi,
On 26/10/17 19:31, ahardy42 wrote:
The projects I'm working on are migrating towards a micro-services
architecture and my aim is to find a way to implement:
- auto-increment the version number
see my comments later ...
- semantic versioning (3.1.99, 3.1.100, 3.1.101 etc)
Just a kind how you define the version in your pom file...and be aware
how to change minor/major/patch...
- using the maven pom version as the master or source version number
- running it in maven on the CI server builds
From what I read online, this is beginning to sound like alchemy. There seem
to be several blockers.
Can you mention some of those sources?
How can I tell maven to increment the version and commit the edited pom
without the CI platform seeing the commit and kicking off again in an
infinite loop? I can't see any way of doing it without branching and
merging/rebasing.
Maybe I misunderstand a thing here but what about the usual
maven-release-plugin ? This can be run on a CI server also on command
line directly for a developer if it's needed (But I would recommend to
do that only on CI)...BTW: Can you explain the part with the infinite
loop ? I don't get that point?
Just by using mvn -B release:prepare release:perform
BTW: Why should a change to the code being ignored by the CI platform?
[1]:
http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
My second main issue that I wonder about is: a developer commit may pass all
its tests and reach the maven deploy phase, at which point the automated CI
job wants to commit the updated pom with the incremented version - but it
might come after a second developer commits. This also points to branching
and then merging.
To make things clear here. The CI could do a release procedure on it's
own...(can be done by serveral pipeline steps)...But I would recommend
to use the maven-release-plugin at the first place...(If you really like
you can do it on your own)..
The default strategy of maven-release-plugin is for the prepare goal
like the following (from the docs):
* Check that there are no uncommitted changes in the sources
* Check that there are no SNAPSHOT dependencies
* Change the version in the POMs from x-SNAPSHOT to a new version (you
will be prompted for the versions to use)
* Transform the SCM information in the POM to include the final
destination of the tag
* Run the project tests against the modified POMs to confirm
everything is in working order
* Commit the modified POMs
* Tag the code in the SCM with a version name (this will
be prompted for)
* Bump the version in the POMs to a new value y-SNAPSHOT (these
values will also be prompted for)
* Commit the modified POMs
Afterwards the release:perform will do the following:
* Checkout from an SCM URL with optional tag
* Run the predefined Maven goals to release the project
(by default, deploy site-deploy)
And yes during the above prepare part (running tests against changed
pom's) there can be another commit which might fail the commit on
master/trunk for the changed pom's but it's very unlikely but of course
possible...after the tags has been created there is no issue on that,
cause the rest of the build will be done directly on the created tag
which is not influenced by commits on master/trunk...
I can sympathise with all the continuous delivery / microservices / devops
bloggers who have posted their articles about version numbers with
${code.branch}.${commit.date}.${build.number}.${sha1} but I can't help
seeing that solution as a work-around which makes it impossible to remember
what version you're on.
The question is if you really use different branches...in the meantime
many people have suggested to prevent use of branches cause it violates
the principle of integration cause the integration is done at the time
of merge which might be too lateIf you think about this you have
only a single version available...and no need for different versions...
Apart from that I don't see the need for a part ${build.number} and
${commit.date} ?...
Maybe this can help: http://maven.apache.org/maven-ci-friendly.html
Have I missed something when searching the net for the last couple of hours?
The question is what exactly is your problem?
I can suggest you a simple model. Just just use the master/trunk for
producing releases after each change (either via merge or via direct
commit; This is a different story to tell) on the master/trunk. This
means that you can simply prevent parallel build of master/trunk...so in
the end the master/trunk will always produce a single version.
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: Wrong version ids in doxia-modules
Hi Pete, On 03/07/18 22:43, Peter Nabbefeld wrote: Hello, I'm experimenting with a doxia module, using org.apache.maven.doxia/doxia-modules/1.8 as parent. When looking at the effective graph, I see every dependency with version 1.0-SNAPSHOT, though release version is 1.8, e.g.: org.apache.maven.doxia doxia-core 1.0-SNAPSHOT test-jar I've also noticed, only version 1.0-SNAPSHOT is available as a jar dependency, all the release version are sources only - why? maybe I misunderstand your question but based on the search in Central: http://search.maven.org/#search%7Cga%7C1%7Corg.apache.maven.doxia They are all available as JAR's as well as sources etc. ? 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: sorting versions for artifacts with hypen and / or dot in filename
Hi, On 09/01/18 00:44, hanas...@gmail.com wrote: How is the artifact name separated from the version number if the artifact has hypens and / or dots in it? Are they sorted as Strings? example: jar1 and the war are two submodules of a parent project G:A:V = org.myorg.project org.myorg.project.jar1 (and a org.myorg.project.war) 1.2.3 OR G:A:V = org.myproject.project org-myorg-project-jar1 (and a org-myorg-project-war) 1.2.3 * have also had the discussion of reversing to war-project-myorg.org * above of course would have -SNAPSHOT versions too The idea remove ambiguity between artifacts that would otherwise have ambiguity in their names. You might have seen many projects that have a core.jar or common.jar Of course this also is havoc if there are two core.jar files, from two different dependent projects, in the web lib directory of a WAR file. Need to be sure that maven and gradle will parse correctly and sort versions of x.y.z in the correct order and not revert to string ascii sort order. Can you give a little bit more of background information what you problem is or what kind of issue you have? Kind regards Karl Heinz Marbaise Thanks. - 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: Anything in pipeline to add functionality to read pom in different formats?
Hi, On 01/02/18 14:48, ahardy42 wrote: Hi All, as a loyal maven user I appreciate maven for all it does and give kudos to all the people who helped build it. Thought I'd say that before I ask my question in case you think I'm trolling. My main problem with maven is colleagues. I constantly hear complaints about maven being horrible. Instead of being bothered or dis-inhibiting themselves from seeing maven as it should be seen, they say "because it is XML". To be honest if people only say Maven is horrible based on the usage of XML they never understood they can use tools like Eclipse etc. nor have they understood Maven...nor used it in the right way...I learned that very often during my consultantancies.. They are often very astonished that Maven is very good usually they just didn't accept the basics... nevertheless.. Sometimes I think they'd rather use ant or shell script to do their builds, I see that a lot... or just go with gradle or ivy because someone cool mentioned them. To be honest Gradle yes cool tool but Ivy ? (Hm..I'm not sure).. Also I have hears stories about users going back to Maven cause you can do mostly everything in Gradle which will be done and in the end it is no more maintainable...in Maven that's not simple to script something etc.. ;-) This leads me naturally to ask, does anyone have any plans to write a maven pom reader that can read YAML or even JSON or any other potential non-XML format? If you like to use something different you can take a look at: https://github.com/takari/polyglot-maven Ruby, Yaml Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
