Re: Multi-Module Library Best Practices (configuration & deployment)
Hi Nikki, have a look at the maven-flatten-plugin at https://www.mojohaus.org/flatten-maven-plugin/ This essentially allows you to use your parent POMs during builds but deletes the reference to them when your artifact gets deployed, integrating the information from the parents at the appropriate places (flattening), reducing the information "leaked" to the consumer of your artifact to the bare minimum. Cheers, Wolf On 19.12.18 08:53, Nikki Novak wrote: https://github.com/BattlePlugins/BattleArena Got a report on Discord that one of the users could not build one of our open source projects: BattleArena. Examples of his error reproduced by me (with an empty local-repo): [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 02:03 min [INFO] Finished at: 2018-12-18T20:38:53-06:00 [INFO] Final Memory: 14M/390M [INFO] [ERROR] Failed to execute goal on project BattleArena: Could not resolve dependencies for project mc.alk:BattleArena:jar:3.9.10.21: Failed to collect dependencies at mc.euro:BukkitInterface:jar:4.0.1: Failed to read artifact descriptor for mc.euro:BukkitInterface:jar:4.0.1: Could not find artifact mc.euro:BukkitInterface-Parent:pom:parent in rainbowcraft-repo (http://rainbowcraft.sytes.net/maven/repository/) -> [Help 1] [ERROR] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 02:06 min [INFO] Finished at: 2018-12-18T20:35:57-06:00 [INFO] Final Memory: 12M/392M [INFO] [ERROR] Failed to execute goal on project BattleArena: Could not resolve dependencies for project mc.alk:BattleArena:jar:3.9.10.22: Failed to collect dependencies at mc.alk:BattleBukkitLib:jar:4.0.2: Failed to read artifact descriptor for mc.alk:BattleBukkitLib:jar:4.0.2: Could not find artifact mc.alk:BattleBukkitLib-parent:pom:parent in rainbowcraft-repo (http://rainbowcraft.sytes.net/maven/repository/) -> [Help 1] [ERROR] Maven is looking for the Parent POM of multi-module projects. BattleArena has THREE of these multi-module projects as dependencies: https://github.com/Europia79/BukkitInterface https://github.com/BattlePlugins/BattleBukkitLib https://github.com/BattlePlugins/WorldEditUtil And our Maven repository: http://rainbowcraft.sytes.net/maven/repository/ So, I am thinking that these multi-module projects are mis-configured ? Because when I deploy them, I am only deploying the final JAR of the main module (for example): mvn deploy -pl modules/BukkitInterface Hack#1: Obviously, I can just deploy ALL modules & call it a day... But these other modules don't have life-cycles... Meaning that they're not used at all... except to create the final JAR. Hack#2: For these multi-module projects, I have since learned that the modules must be set to optional. And I've discovered that deleting the Parent block from the main-module's pom.xml fixes the issue. And Maven will no longer look for the Parent-POM. But this really seems like a hach-ish solution: Not best practices. Because as I understand it: The Parent-block just denotes inheritance. I would really like to figure this out & understand it. What is Maven best practices here ? How does one configure these libraries (multi-modules) in such a way that dependent projects aren't un-necessarily looking for the Parent-POMs ? (When they should be happy with just the libraries JAR file). -- "Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher." - Antoine de Saint-Exupéry, Terre des Hommes - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy:deploy-file with same groupId artifactId but different classifiers
Hi Francois, in my experience you will need to deploy from a single machine in a single call to deploy:deploy-file, attaching all the artifacts you need to deploy with qualifiers, e.g.: Use a single free form jenkins job to - synchronously trigger a multiconfiguration job in jenkins to build the native libraries (mvn install there, not mvn deploy!), - and then collect the artifacts generated from the multiconfiguration job and deploy them to your repository: mvn deploy:deploy-file \ -Durl=http://centos-dev:8090/repository/internal/ \ -DrepositoryId=archiva.internal \ -DgroupId=com.myCompany -DartifactId=myLib \ -Dversion=1.0.0 \ -Dtypes=zip,zip \ -Dclassifiers=x64-natives-linux,x64-natives-win \ -Dfiles=myLib-x64-natives-linux.zip,jre-x64-natives-win.zip \ -Dfile=some_file You will need to make up a main artifact (some_file) to deploy (cant' remember whether you could use the pom file) - I usually use a file created by combining all the machine dependent stuff into one big archive which also allows me to use a single artifact as dependency in further builds. Doing it this way avoids at least two pitfalls: - mvn deploy is not atomic (have a look at the output of mvn deploy to see what it does) and deploying the same artifact from two machines to the same repo is asking for trouble (like: losing one or the other from time to time) - Even if the repository manager you are using does not enforce a deploy once strategy (e.g. for -SNAPSHOT releases) you will end up with *multiple* versions instead of one, which can lead to really obscure behaviour when the repository manager cleans up stuff it consideres no longer necessary. Hth Cheers, Wolf On 29.06.2015 09:53, Francois MAROT wrote: Hello all, I'm in the process of converting an existing build to Maven. I have 2 Jenkins jobs building the same native library on 2 different systems (win / lin). At the end of each one, I want to deploy them on my Archiva repo. So I execute the following commands : On a Linux computer: mvn deploy:deploy-file -Dfile=myLib-x64-natives-linux.zip -Dclassifier=natives-linux -DgroupId=com.myCompany -DartifactId=myLib -Dversion=1.0.0 -DrepositoryId=archiva.internal -Durl=http://centos-dev:8090/repository/internal/ On a Windows computer: mvn deploy:deploy-file -Dfile=jre-x64-natives-win.zip -Dclassifier=natives-win -DgroupId=com.myCompany -DartifactId=myLib -Dversion=1.0.0 -DrepositoryId=archiva.internal -Durl=http://centos-dev:8090/repository/internal/ Problem is the second command leads to a build failed because the pom of the project in version 1.0.0 is already deployed... BUT, I am lucky because the artifact with classifier natives-win has already been uploaded so both artifact end up on the server correctly. So builds depending on them can retreive them correctly and everything is fine... ... except that I don't want to base my build on luck and would like to know what is the correct way to deploy 2 artifacts with everything being the same except the qualifier. How do you pepole deploy a same artifact but built by different computers, architectures ? I'm using Maven 3.3.1 Apache Archiva 2.1.1 -- View this message in context: http://maven.40175.n5.nabble.com/mvn-deploy-deploy-file-with-same-groupId-artifactId-but-different-classifiers-tp5838931.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: Codehaus Mojo repository
... and for those in search of the documentation formerly hosted at codehaus: some/most of it can be found at http://www.mojohaus.org Cheers, Wolf On 03.06.2015 09:01, Olivier Lamy wrote: Hi Have a look here https://github.com/mojohaus/ Olivier On 3 June 2015 at 16:57, Curtis Rueden wrote: Hi everyone, It looks like Codehaus SVN is finally kaput: $ svn checkout http://svn.codehaus.org/mojo svn: E175011: Unable to connect to a repository at URL ' http://svn.codehaus.org/mojo' svn: E175011: Repository moved temporarily to 'http://www.codehaus.org '; please relocate But the mojo repository is not yet populated on GitHub: https://github.com/codehaus/mojo Is it planned to populate that repository? Where does the code live in the meantime? Thanks, Curtis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: use separate mirrors for project dendencies and plugin dependencies ??
On 06.05.2014 09:07, Dan Tran wrote: Ofcourse, I do have Maven repo manager ̣ nexus at this time), however still struggle on how to get only plugin's artifact goto one proxy and others goto to another proxy using mirror settings. Are you able to do so? -Dan I'm none to sure that this would even help at all: Presumably you are trying to separate artifacts used by plugins during your build (where you might use e.g. GPL licensed modules) from artifacts used as dependencies in your project proper (where using that same GPL licensed modules would make your legal department scream) by separating the repositories used to provide them. As far as I know/understand all artifacts are downloaded to the same local cache repository (~/.m2/repository), regardless of whether they were required by some plugin or as a dependency of your project. This makes them available for both purposes and thus obliterates all your efforts of keeping them separate. Maven Masters: Please correct me if I'm wrong. Cheers, Wolf On Mon, May 5, 2014 at 11:59 PM, Christian Domsch m...@landrus.de wrote: Hi Dan, Did you consider using nexus? There you can setup any kind of strange repo setup your mind can come up with ;-) For your case, create one repo for your project stuff and one repo for your plugin stuff. Create a group for both for easy access and control access by authorization... Christian On 06.05.2014 06:29, Dan Tran wrote: Thanks Barrie, Will see what I can can do. On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar baerr...@gmail.com wrote: On 6 May 2014 09:21, Dan Tran dant...@gmail.com wrote: for legal purpose ( btw, please dont drill me here), I would like to use one mirror as a gate way for all of of my project dependencies,and another mirror as a gate way for all of my plugins and their dependencies is it possible? Posting a settings.xml config here is very much appreciated Having not done this, here is some more insane advice. I'd use three. One proxy to proxy the other two proxies. All developers point to the master proxy. You can then configure the master proxy to refer to the project dependencies proxy and another for plugins dependencies proxy. You might need a more sophisticated maven repository manager that you can restrict what is allowed in the proxies (i.e. it just doesn't go and grab stuff for you). You're going to have to do a lot of fiddling to get this to work. I'm not convinced it is going to give you what legal thinks it will... If you could write up what you tried and whether it worked it would be helpful for anyone else attempting the same thing... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.5 - Strange Interaction/Regression: maven-enforcer-plugin vs. maven-assembly-plugin
Hi list.
I just got hit by a weird interaction between two plugins, namely the
maven-enforcer-plugin and the maven-assembly-plugin:
I recently updated the versions for the plugins used in my build and
suddenly the creation of an assembly broke with an NPE:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble)
on project extjars: Execution assemble of goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
NullPointerException - [Help 1]
Now the strange part is, that the m-a-p version had not been updated and
the assembly descriptor had not been changed.
Further investigation revealed the update of m-e-p to be the cause of
the error, as reverting to 1.2 (down from 1.3) magically made the build
work again.
I think this is a bug/regression that should be fixed, but: which of the
plugins should I file the Jira against? Is the m-e-p destroying data
that it should not touch or did the changed behaviour of m-e-p uncover a
bug in m-a-p?
If nothing else here's more proof of the necessity of nailing down all
the versions to get a reproducible build...
If you feel up to reproducing/analyzing the error here are the two
(merged and stripped down) files required:
pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
properties
plugins.maven-enforcer-plugin.version1.3/plugins.maven-enforcer-plugin.version
/properties
groupIdch.pecunifex.maven/groupId
artifactIdextjars/artifactId
version2014.0.0-SNAPSHOT/version
packagingpom/packaging
name3rd-party Jars Assembly/name
description
Collect all 3rd-party dependencies and assemble them for
redistribution.
/description
prerequisites
maven3.0/maven
/prerequisites
dependencies
dependency
groupIdasm/groupId
artifactIdasm-commons/artifactId
version3.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm/artifactId
version3.1/version
/dependency
!-- ... --
/dependencies
build
defaultGoalpackage/defaultGoal
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clean-plugin/artifactId
version2.4.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.7/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.4/version
executions
execution
idassemble/id
phasepackage/phase
goalsgoalsingle/goal/goals
configuration
appendAssemblyIdfalse/appendAssemblyId
descriptors
descriptor
extjars.xml
/descriptor
/descriptors
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version${plugins.maven-enforcer-plugin.version}/version
executions
execution
idenforce-plugin-versions/id
goals
goalenforce/goal
/goals
configuration
rules
requirePluginVersions
messageBest Practice is to
always define plugin versions!/message
/requirePluginVersions
/rules
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
extjars.xml:
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idextjars/id
formats
formatzip/format
/formats
Re: Maven 3.0.5 - Strange Interaction/Regression: maven-enforcer-plugin vs. maven-assembly-plugin
Done: http://jira.codehaus.org/browse/MENFORCER-156
On 03.07.2013 15:27, Stephen Connolly wrote:
File the bug request against enforcer and let that move it *if* necessary
as initial evidence points to enforcer's issue
On 3 July 2013 13:40, Wolf Geldmacher wrote:
Hi list.
I just got hit by a weird interaction between two plugins, namely the
maven-enforcer-plugin and the maven-assembly-plugin:
I recently updated the versions for the plugins used in my build and
suddenly the creation of an assembly broke with an NPE:
[ERROR] Failed to execute goal org.apache.maven.plugins:**
maven-assembly-plugin:2.4:**single (assemble) on project extjars:
Execution assemble of goal org.apache.maven.plugins:**
maven-assembly-plugin:2.4:**single failed. NullPointerException - [Help
1]
Now the strange part is, that the m-a-p version had not been updated and
the assembly descriptor had not been changed.
Further investigation revealed the update of m-e-p to be the cause of the
error, as reverting to 1.2 (down from 1.3) magically made the build work
again.
I think this is a bug/regression that should be fixed, but: which of the
plugins should I file the Jira against? Is the m-e-p destroying data that
it should not touch or did the changed behaviour of m-e-p uncover a bug in
m-a-p?
If nothing else here's more proof of the necessity of nailing down all the
versions to get a reproducible build...
If you feel up to reproducing/analyzing the error here are the two (merged
and stripped down) files required:
pom.xml:
project
xmlns=http://maven.apache.**org/POM/4.0.0http://maven.apache.org/POM/4.0.0
xmlns:xsi=http://www.w3.org/**2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=http://**maven.apache.org/POM/4.0.0http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/**maven-4.0.0.xsdhttp://maven.apache.org/xsd/maven-4.0.0.xsd
modelVersion4.0.0/**modelVersion
properties
plugins.maven-enforcer-**plugin.version1.3/plugins.**
maven-enforcer-plugin.version
/properties
groupIdch.pecunifex.maven/**groupId
artifactIdextjars/**artifactId
version2014.0.0-SNAPSHOT/**version
packagingpom/packaging
name3rd-party Jars Assembly/name
description
Collect all 3rd-party dependencies and assemble them for
redistribution.
/description
prerequisites
maven3.0/maven
/prerequisites
dependencies
dependency
groupIdasm/groupId
artifactIdasm-commons/**artifactId
version3.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm/artifactId
version3.1/version
/dependency
!-- ... --
/dependencies
build
defaultGoalpackage/**defaultGoal
plugins
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-clean-**plugin/artifactId
version2.4.1/version
/plugin
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-deploy-**plugin/artifactId
version2.7/version
/plugin
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
version2.3.1/version
/plugin
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-site-plugin**/artifactId
version3.0/version
/plugin
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-assembly-**plugin/artifactId
version2.4/version
executions
execution
idassemble/id
phasepackage/phase
goalsgoalsingle/goal/**goals
configuration
appendAssemblyIdfalse/**appendAssemblyId
descriptors
descriptor
extjars.xml
/descriptor
/descriptors
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-enforcer-**plugin/artifactId
version${plugins.maven-**enforcer-plugin.version}/**version
executions
execution
idenforce-plugin-versions/**id
goals
goalenforce/goal
/goals
configuration
rules
requirePluginVersions
messageBest Practice is to always
define plugin versions!/message
/requirePluginVersions
Re: maven-exec-plugin
On 06.06.2013 11:48, virg g wrote: Hi, I am having a problem in using maven-exec-plugin. I have requirement that i need to use SVN MOVE command to rename labels. Since SCM does not support MOVE svn tags/labels i am using maven-exec-plugin to rename svn tags with required arguments including svn username and password. The problem i am facing is, this exec plugin is able to rename the labels, but in the build log, it shows the entire exec plugin command in plain text what i have set, since i am passing even password also, it also displays password in plain text. Is there any way i can mask some parameters which i want to aovid being displayed in plain text. Not that I know of. Wrap the call in a procedure (shell/cmd batch) on your platform of choice and call that instead. That way the username/passwd can be hidden inside the procedure. Distribute this wrapper as part of a toolset package to the machines you run the build on or as part of the project. Use of the maven-exec plugin is usually non-portable between platforms anyway, so you're not losing too much more. Or is there any bettern plugin i can use to meet my requirement? Any pointers for this? None that I know of. THanks Virg Cheers, Wolf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.5: site plugin or documentation broken?
Hi Hervé, On 10.04.2013 02:41, Hervé BOUTEMY wrote: 1. warning if you don't define plugin version you can believe Maven 3 doc, version is taken from pluginManagement: coded here [1] But I must confess I never tried with CLI, since we use to continue defining plugin version directly to keep Maven 2.x compatibility I just tried and confirm this warning happens, but it is wrong: please open a Jira issue Done. Jira MSITE-685 2. report inheritence I just tried the corresponding inheritedReports IT from m-site-p, which I had to skip with Maven 3 in MSITE-595 [2] /r1148517 [3] and you're right: now, m-site-p with Maven 3 seems to behave like Maven 2, then the doc is now wrong I don't know when/how it has changed: m-site-p or Maven? Please open another Jira issue Done. Jira MSITE-686 I'd like to see the Jira as a report against the code and not against the documentation, because IMHO the documented behaviour is what I would expect it to be (otherwise there is no way to ever shrink the list in derived POMs), although it would then be incompatible to the behaviour in Maven 2. BTW, thanks for these precise reports: this really helps us keep Maven as good as possible Thank *you* for the support! Regards, Hervé [1] http://maven.apache.org/shared/maven-reporting- exec/apidocs/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#getPluginVersion(org.apache.maven.reporting.exec.ReportPlugin, org.apache.maven.artifact.repository.RepositoryRequest, org.apache.maven.reporting.exec.MavenReportExecutorRequest) [2] http://jira.codehaus.org/browse/MSITE-595 [3] http://svn.apache.org/viewvc?view=revisionrevision=r1148517 Cheers, Wolf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.5: site plugin or documentation broken?
I'm trying to get the maven site plugin to do my bidding but have gotten
lost...
Given the following simple POM's
pom.xml:
project
modelVersion4.0.0/modelVersion
groupIdch.pecunifex/groupId
artifactIdparent/artifactId
version1.0-SNAPSHOT/version
packagingpom/packaging
urlhttp://localhost/parent/url
modules
modulechild/module
/modules
properties
version.site.plugin3.2/version.site.plugin
version.info.plugin2.6/version.info.plugin
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version${version.site.plugin}/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
version${version.info.plugin}/version
/plugin
/plugins
/pluginManagement
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
reportSets
reportSet
reports
reportindex/report
reportsummary/report
reportproject-team/report
reportmodules/report
reportplugins/report
reportplugin-management/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
/project
and child/pom.xml:
project
modelVersion4.0.0/modelVersion
parent
groupIdch.pecunifex/groupId
artifactIdparent/artifactId
version1.0-SNAPSHOT/version
/parent
groupIdch.pecunifex/groupId
artifactIdchild/artifactId
urlhttp://localhost/child/url
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
reportSets
reportSet
reports
reportindex/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
/project
and the documentation on:
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html
I get the following when I call mvn site:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
ch.pecunifex:child:jar:1.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @ line
16, column 21
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
ch.pecunifex:parent:pom:1.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @ line
38, column 21
[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]
while the documentation clearly states that:
When used with Maven 3, a report plugin version can be empty (like build
plugins).
The following order/strategy will be used to find/resolve a version:
- search the same groupId/artifactId in the build.plugins section
- search the same groupId/artifactId in the build.pluginManagement.plugins
section
- resolve with current repositories (can include automatic SNAPSHOT
resolution)
Why do I get the warning? And on the wrong line to boot?
And, worse yet, a little later I get:
...
[INFO]
[INFO] Building parent 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-site-plugin:3.2:site (default-site) @ parent ---
[INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:2.6
[INFO] Relativizing decoration links with respect to project URL:
http://localhost/parent
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[INFO] Generating About report--- maven-project-info-reports-plugin:2.6
[INFO] Generating Project Summary report---
maven-project-info-reports-plugin:2.6
[INFO] Generating Project Team report---
maven-project-info-reports-plugin:2.6
[INFO] Generating Project Modules report---
maven-project-info-reports-plugin:2.6
[INFO] Generating Project Plugins
Re: Maven life cycle dependencies
On 13.03.2013 16:58, Wayne Fay wrote: dependencies dependency groupIdmaven.issue/groupId artifactIddependency/artifactId version1.0/version ... modules moduledependency/module /modules This seems like a bad idea right up front. You shouldn't have a dependency as a module in the same pom. You have constructed essentially a circular reference. The strange setup is only due to my effort to reduce the example code to the minimum. I wanted to provide working POMs that all the scenarios I'm describing can be reproduced with. Cheers, Wolf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven life cycle dependencies
Hail all ye maven gurus! I've (again) hit some issues with the-maven-way(tm) that I'd appreciate your thoughts on: Using Maven 3.0.5/Java 1.7.0_10/Linux on an (abstracted) aggregation project with two POMs: maven/pom.xml: project modelVersion4.0.0/modelVersion groupIdmaven.issue/groupId artifactIdaggregation/artifactId version2014.0.0-SNAPSHOT/version packagingpom/packaging urlhttp://localhost/documentation/maven/url dependencies dependency groupIdmaven.issue/groupId artifactIddependency/artifactId version1.0/version /dependency /dependencies properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties modules moduledependency/module /modules build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId version1.2.1/version configuration executableecho/executable /configuration executions !-- Binding to the clean phase will make the clean fail when any dependencies are specified and we try run clean for a fresh project! -- execution idclean/id phaseclean/phase goals goalexec/goal /goals configuration arguments argumentExecuting mvn clean/argument /arguments /configuration /execution /executions /plugin /plugins /build reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.2/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.6/version configuration dependencyLocationsEnabledfalse/dependencyLocationsEnabled /configuration /plugin /plugins /reporting /project maven/dependency/pom.xml: project modelVersion4.0.0/modelVersion groupIdmaven.issue/groupId artifactIddependency/artifactId version1.0/version urlhttp://localhost/documentation/maven/dependency/url reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.2/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.6/version /plugin /plugins /reporting /project (1) When I run mvn clean on the top level *for the first time* I get this error: [ERROR] Failed to execute goal on project aggregation: Could not resolve dependencies \ for project maven.issue:aggregation:pom:2014.0.0-SNAPSHOT: \ Failure to find maven.issue:dependency:jar:1.0 in URL of our MRM Obviously it cannot be in the MRM yet, as I'm building (this version) for the first time, but: - Why does maven even try to resolve this dependency when cleaning? - And (just out of curiosity) why does it try to resolve that dependency outside of the reactor? (2) Once the maven build cycle has been run beyond the install phase for this project the dependency will be satisfied either from the local cache or from the MRM - but: This makes a first time clean for each new version behave differently from all later invocations and breaks the mvn clean install mantra used by CI systems. The scenario cannot be that exotic and we all want stable and reproducible builds - so: How do you solve it? (3) If you comment out the binding of exec-maven-plugin:exec to the clean phase, a first time clean will succeed. Shouldn't adding a plugin to some phase be transparent w/r/t the prerequisites of the phase? Who's to blame for the unexpected change in behaviour? Is this a problem in the Maven core? Is this an issue with the exec-maven-plugin? (4) Running mvn site on this same project shows a very similar problem: The first time a site is generated (i.e. without having run the maven build cycle to, or beyond, the install phase), site generation will fail with the same message as above, even without any additional plugins bound to the site phase. Is it considered best practice that the site life cycle implicitly depends on the build life cylce, at least as far as dependencies are concerned? If so: Why is it a different
Re: The Maven Way
Thank you all for the ideas hints the fruitful discussion and special thanks to Eric for summing it up! I very much appreciate your time and efforts. Regards, Wolf Am 19.04.2012 17:15, schrieb Eric Kolotyluk: After reading this thread and the embedded references I believe much of this information should be captured and added to http://maven.apache.org - in particular under Learning About Maven the very first topic should be The Maven Way. As well, if you go to http://maven.apache.org/what-is-maven.html then one of the first things you should see is a link to The Maven Way. Newbies in particular should be guided as soon as possible to this philosophical discussion about Maven, and how to best learn and master Maven, before anything else. People need to be clear about Convention over Configuration - they may not agree with the pattern, but it should be made clear to them that by embracing this pattern they will likely find Maven a much more satisfying experience. The surrounding text should catch the newbie's attention right away and guide them to this philosophical discussion with phrases like If you are new to Maven please read 'The Maven Way' to get the most satisfying Maven experience. Maybe some humor is also appropriate I fought Maven, and Maven won - maybe we can revise the original Clash lyrics Pulling hair cause my build's not done I fought Maven and Maven won [x2] I need a break cause my build's not done I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and Swear'n like a son of a gun I fought Maven and Maven won [x2] I miss my Ant and I miss my fun I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and I fought Maven and Maven won [x7] I fought Maven and Chad's article http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html has some really valuable insight, especially about patterns. Too few people understand the importance of patterns - myself included - and we need to be reminded of this. Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal on how to ask questions is also valuable - to both the person trying to learn Maven, but more importantly to the people trying to document and explain Maven. In my own job we struggle with documenting our products because users often complain that our documentation is only a reference that is useful if you mostly know how to do something, but terrible at identifying common goals and the processes to achieve them. Many kudos to Barrie for taking the pragmatic step to open a JIRA issue on this. My own pet peeve with Maven is that when something goes wrong - the diagnostics you get can be exceedingly hard to fathom (especially for newbies) - and often very misleading to what the actual cause of the problem is. In many cases when I quoted the diagnostic messages on users@maven.apache.org I got back all kinds of bizarre answers and suggestions because other people also were mislead by the diagnostics. If someone is looking for an idea for a PhD or postdoc project - please build an Intelligent System to figure out why my Maven build is hosed and explain it to me with some meaningful diagnostics - even better - suggest possible fixes the way m2e does (but just better). This has been great discussion - thanks to all who participated :-) Special thanks to Wolf who got this discussion started. Cheers, Eric - 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
The Maven Way
Hi list, a simple question with (hopefully) a simple answer: Is there some coherent documentation of the Maven way? I'm *not* looking for: * documentation of the Maven syntax * documentation of Maven plugins * Maven reference documentation * Use the Source, Luke! style of advice What I'm looking for is: * a collection of patterns / anti-patterns in the use of Maven, * documentation on the Do's and Dont's when using Maven, * documentation of the best practices implemented by Maven, * documentation of basic assumptions in Maven. I'm being bitten by gotcha's that spring up at inconvenient times and *then* being told that I've strayed from The Way; I'd rather follow some road signs upfront than find myself confronted with scathing dogs in some lonely backyard that I happen to stumble into. Something along the lines of Chapter 3.6 of Maven: The Complete Reference, which sets out to ... distill some of this knowledge to help you adopt best practices from the start without having to wade through years of discussions ... but then, unfortunately, only covers two (Dependency Grouping and Multi-module vs. Inheritance). Similar to this, just much more complete and with some background/rationale thrown in, if possible. Pointers anyone? Pretty please? Regards, Wolf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Inheritance of properties
Hello List.
I'm aiming at introducing maven (mvn 3.0.3 to be precise) in our
company.
In preparation for the task I've set up a company wide POM (c-p-p) and a
project specific POM (c-p-p-p) plus a sample project for the developers
here to use as a template (sample-project) - all included below.
The SCM used is Subversion and the structure of the repositories is
historically grown, which requires me to define a scm-loc property
which needs to be reset for every project.
The problem I'm encountering:
After mvn install for the company and project wide parent POMs I run
mvn help:effective-pom from within the sample-project with unexpected
results:
...
groupIdcom.company/groupId
artifactIdsample-project/artifactId
version2012.0.0-SNAPSHOT/version
nameA sample project/name
descriptionA very simple example project./description
urlhttps://doc.company.com/build/trunk/maven/sample-project/url
scm
connectionscm:svn:https://svn.company.com/repos/build/trunk/maven/sample-project/c-p-p-p/sample-project/connection
developerConnectionscm:svn:https://svn.company.com/repos/build/trunk/maven/sample-project/c-p-p-p/sample-project/developerConnection
urlscm:svn:https://svn.company.com/repos/build/trunk/maven/sample-project/c-p-p-p/sample-project/url
/scm
...
- The project URL that I explicitly (re-)defined in the
sample-project's POM is expanded as I would expect.
- All URLs in the SCM section of the effective POM have a trailing
c-p-p-p/sample-project (as does the project URL if it is inherited
and not explicitly set it in the sample-project's POM).
I understand that maven does inheritance before interpolation, so as
the scm-loc property is set in the sample-project's POM I would expect
all expansions of the property to have the value defined in the POM.
What am I missing?
Where does the additional suffixing come from?
Is this a bug?
Is there a way to achieve my goal without having to make it explicit in
every single derived POM?
As side remarks: The effective POM fpr c-p-p-p looks ok - no unexpected
tailing traces of the parent POM there; and mvn 2.2.1 behaves exactly
the same way.
Cheers,
Wolf
POMs used
c-p-p/pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
!-- Artifact coordinates --
groupIdcom.company/groupId
artifactIdc-p-p/artifactId
version2012.0.0-SNAPSHOT/version
packagingpom/packaging
!-- Artifact description --
nameCompany Parent POM/name
descriptionCentral POM for all of Company. Defines central
locations, central repositories and central properties./description
urlhttps://${doc-host}/${svn-loc}/url
!-- Globally defined properties --
properties
!-- Documentation host --
doc-hostdoc.company.com/doc-host
!-- Subversion repository host --
svn-hostsvn.company.com/svn-host
!-- readonly access to SVN --
svn-roscm:svn:https://${svn-host}/repos/svn-ro
!-- read/write access to SVN --
svn-rwscm:svn:https://${svn-host}/repos/svn-rw
!-- Current branch in SVN --
svn-branchtrunk/svn-branch
!-- location of artifact in SVN --
svn-locbuild/${svn-branch}/maven/c-p-p/svn-loc
!-- Default encoding used for source files --
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
!-- Repositories (SVN integration) --
scm
connection${svn-ro}/${svn-loc}/connection
developerConnection${svn-rw}/${svn-loc}/developerConnection
url${svn-ro}/${svn-loc}/url
/scm
/project
c-p-p-p/pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
properties
!-- location of artifact in SVN --
svn-locbuild/${svn-branch}/maven/svn-loc
/properties
!-- Import Company-wide Settings --
parent
groupIdcom.company/groupId
artifactIdc-p-p/artifactId
version2012.0.0-SNAPSHOT/version
/parent
!-- This defines generic project settings --
groupIdcom.company/groupId
artifactIdc-p-p-p/artifactId
version2012.0.0-SNAPSHOT/version
packagingpom/packaging
nameCompany Project Parent POM/name
descriptionCentral POM for Company Projects. Defines generic project
properties./description
/project
sample-project/pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
!-- Import Company Project Wide Settings --
parent
groupIdcom.company/groupId
artifactIdc-p-p-p/artifactId
version2012.0.0-SNAPSHOT/version
/parent
properties
!-- location of artifact in SVN --
Re: Inheritance of properties
Hi Jörg, Thanks for the answer. Can you point me to a place where this behaviour is documented? It seems to hold for most, but not all URLs, i.e. scm, project URL and documentation site URL (except for the webAccessUrl of the maven-project-info-reports-plugin which remains untouched!) seem to be affected, repository URLs seem to be not affected. ... and it's not always the current artifactId either - frequently it's the parent-POMs artifactId followed by the current artifactId, but again this does not seem to be the case always. Thanks again, Wolf On Thu, 2011-04-07 at 14:35 +0200, Jörg Schaible wrote: Hi Wolf, Wolf Geldmacher wrote: Hello List. I'm aiming at introducing maven (mvn 3.0.3 to be precise) in our company. In preparation for the task I've set up a company wide POM (c-p-p) and a project specific POM (c-p-p-p) plus a sample project for the developers here to use as a template (sample-project) - all included below. The SCM used is Subversion and the structure of the repositories is historically grown, which requires me to define a scm-loc property which needs to be reset for every project. The problem I'm encountering: After mvn install for the company and project wide parent POMs I run mvn help:effective-pom from within the sample-project with unexpected results: ... groupIdcom.company/groupId artifactIdsample-project/artifactId version2012.0.0-SNAPSHOT/version nameA sample project/name descriptionA very simple example project./description urlhttps://doc.company.com/build/trunk/maven/sample-project/url scm connectionscm:svn:https://svn.company.com/repos/build/trunk/maven/sample- project/c-p-p-p/sample-project/connection developerConnectionscm:svn:https://svn.company.com/repos/build/trunk/maven/sample- project/c-p-p-p/sample-project/developerConnection urlscm:svn:https://svn.company.com/repos/build/trunk/maven/sample- project/c-p-p-p/sample-project/url /scm ... - The project URL that I explicitly (re-)defined in the sample-project's POM is expanded as I would expect. - All URLs in the SCM section of the effective POM have a trailing c-p-p-p/sample-project (as does the project URL if it is inherited and not explicitly set it in the sample-project's POM). I understand that maven does inheritance before interpolation, so as the scm-loc property is set in the sample-project's POM I would expect all expansions of the property to have the value defined in the POM. What am I missing? Where does the additional suffixing come from? The artifactId is automatically appended as suffix when URLs are inherited. Is this a bug? No. Is there a way to achieve my goal without having to make it explicit in every single derived POM? No. As side remarks: The effective POM fpr c-p-p-p looks ok - no unexpected tailing traces of the parent POM there; and mvn 2.2.1 behaves exactly the same way. BTW: The behavior *is* annoying. It's not only that it prevents interpolation, it also silently implies that the artifactId matches the folder structure in the SCM. - Jörg - 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: Inheritance of properties
Hi Anders, On Thu, 2011-04-07 at 14:26 +0200, Anders Hammar wrote: First of all, I think that you're addressing the (what I call) developer way by adding properties for many tings. Even if this would work, it makes the poms difficult to read and understand. What I'm trying to do is to make the *developers' POMs* as easy to read and understand as possible - a single property that defines the location of the scm, documentation, a.s.o. is all that would have to be defined. I don't care as much for the company and project parent POMs as most developers will never touch or even look at them, if things work out ok for them. I believe future tooling support (like m2eclipse) will solve some of this, but I still regard this as the developer's approach. Unfortunately I cannot wait for the tooling support to happen - and yes, I'm approaching this as a developer who wants to have maximal (configuration) re-use. I'm trying to swing with the Convention over Configuration approach, but there are some boundaries here that I just cannot ignore without loosing acceptance for Maven - one of them being that I cannot disrupt development for reorganizing the structure of the SCM: A lot of (somewhat brittle) scaffolding has been built around the SCM structure that I intend to get rid of, but I can only do it bottom-up, one project one library at a time, while the whole rest of the system still behaves and builds as before. For example, I would leave the generic scm section out of the corporate pom. Or more correctly, the corporate pom will have a scm section specifying (without the usa of properties) the path to the scm where the corporate pom is located. Then for each product, the parent pom would override this by declaring the correct scm path for it. ... and the correct site path, and the correct documentation URL, ... leading to larger POMs and configuration information spreading throughout all POMs? There must be a better way! Have a look at how the corporate pom at Apache, Codehaus, etc is made up. Best-practice that works. It will give you some hints of configuration that you corp parent do lack. I did have a look at the ASF POM and I cut out a lot of the stuff that is in my top-level POM for brevity on the list. Cheers, Wolf Cut for brevity. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
