Re: How to rewrite POMs retaining the XML structure
Hi Robert, took me some days, but today I can finally come up with an update on this: I moved the relevant sources (and all Your regarding commits) to a new project/repository and extended them for our needs. My idea on this is to provide it as a helper library that can be used for more than only the release plugin. Please have a look at https://github.com/CoreMedia/maven-jdom-parser and let me know what you think about it. I'd like to know it You think it could be worth it continuing it as (sort of) central library for POM modifications. May be could/should have some further (on- or off-list) conversation about it. Best regards Marc On Mon, 3 Dec 2018 at 16:50, Robert Scholte wrote: > On Mon, 03 Dec 2018 11:47:58 +0100, Marc Rohlfs > wrote: > > > Hi all, > > > > many thanks for Your suggestions. I already check the different plugin > > implementations (except tidy-maven-plugin) before writing my post - > > should > > have probably mentioned them in my post, I'm sorry. Unfortunately none of > > them really seems to help me with what I like/need to achieve, expect of > > the JDom parser approach that was implemented by Robert Scholte for the > > maven-release-plugin version 3.0 - which hasn't been continued nor > > released for 2 1/2 years now. > > > > @Robert: I'd really like to pick up Your approach. Looks very useful to > > me, > > not only for the maven-release-plugin. If You don't mind, I'd invest a > > little time to transfer it to a new library and extend it for my use > > cases. > > That would be great. I guess I was working on it before I had to switch > to > JPMS/Project Jigsaw support. > Since then focus was on keeping all our ~100 subprojects running on more > Java versions. > The maven-release-plugin is not dead. There are more things that should > be > improved for 3.0.0, but based on business value I need to focus on other > topics. Will definitely work on it again in the future! > > Robert > > > > > @Anton: DecentXML is an interesting library, too. I'll surely remember > > this > > one. > > > > @Matthieu: Besides some other use cases, we basically need this for a > > migration of a very huge/complex project setup into a new project layout. > > For this, (re)calculate our projects (including dependencies, properties > > etc) and we need to continuously transfer changes between old and new > > project layout for a transition period. > > > > Best regards > > Marc > > > > > > On Thu, 29 Nov 2018 at 17:11, Marc Rohlfs > > wrote: > > > >> Hi all, > >> > >> is there a way to rewrite pom.xml files without loosing formatting, > >> ordering and comments? > >> > >> We need to (programmatically) do several changes on Maven POMs, e.g. > >> adding and removing dependencies and properties. Currently we're using > >> the MavenXpp3Reader and MavenXpp3Writer classes to read and write the > >> pom.xml files, but in the output files, all comments are removed, the > >> XML > >> nodes are reordered and formatting (indentations, empty lines) is lost. > >> Does anybody know a way how to read and write POM files without loosing > >> formatting ordering and comments? > >> > >> Best regards > >> Marc > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How to rewrite POMs retaining the XML structure
Hi all, many thanks for Your suggestions. I already check the different plugin implementations (except tidy-maven-plugin) before writing my post - should have probably mentioned them in my post, I'm sorry. Unfortunately none of them really seems to help me with what I like/need to achieve, expect of the JDom parser approach that was implemented by Robert Scholte for the maven-release-plugin version 3.0 - which hasn't been continued nor released for 2 1/2 years now. @Robert: I'd really like to pick up Your approach. Looks very useful to me, not only for the maven-release-plugin. If You don't mind, I'd invest a little time to transfer it to a new library and extend it for my use cases. @Anton: DecentXML is an interesting library, too. I'll surely remember this one. @Matthieu: Besides some other use cases, we basically need this for a migration of a very huge/complex project setup into a new project layout. For this, (re)calculate our projects (including dependencies, properties etc) and we need to continuously transfer changes between old and new project layout for a transition period. Best regards Marc On Thu, 29 Nov 2018 at 17:11, Marc Rohlfs wrote: > Hi all, > > is there a way to rewrite pom.xml files without loosing formatting, > ordering and comments? > > We need to (programmatically) do several changes on Maven POMs, e.g. > adding and removing dependencies and properties. Currently we're using > the MavenXpp3Reader and MavenXpp3Writer classes to read and write the > pom.xml files, but in the output files, all comments are removed, the XML > nodes are reordered and formatting (indentations, empty lines) is lost. > Does anybody know a way how to read and write POM files without loosing > formatting ordering and comments? > > Best regards > Marc >
How to rewrite POMs retaining the XML structure
Hi all, is there a way to rewrite pom.xml files without loosing formatting, ordering and comments? We need to (programmatically) do several changes on Maven POMs, e.g. adding and removing dependencies and properties. Currently we're using the MavenXpp3Reader and MavenXpp3Writer classes to read and write the pom.xml files, but in the output files, all comments are removed, the XML nodes are reordered and formatting (indentations, empty lines) is lost. Does anybody know a way how to read and write POM files without loosing formatting ordering and comments? Best regards Marc
Re: Reactor:resume goal
Hi Todd, with the 'resume' goal You can define a module in Your build reactor (meaning the complete hierarchy with all sub modules), from where the build should be resumed. You use this e.g. when the build failed in a module, You fixed the problem in that module and then You don't like to run the hole build again. Since Maven 2.1.0 there are command line options for that. Call: mvn clean install --resume-from [groupId:artifactId] or mvn clean install --resume-from path/to/module If I understood Your Your question right, You just want to build all sub modules of 'level2Project', right? Then You might just call: mvn clean install -f level2Project/pom.xml Kind regards Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Execution of plugin in child poms and not in current pom
Hi Conny, what about this idea: 1. Create a properties file 'something.properties' in Your parent POM module directory and set the 'skip' property for the enforcer plugin in there: enforcer.skip=true 2. Configure the Properties Plugin in the build section of Your parent POM: plugin groupIdorg.codehaus.mojo/groupId artifactIdproperties-maven-plugin/artifactId version1.0-alpha-2/version executions execution goals goalread-project-properties/goal /goals !-- Bind the execution to the validate phase so that it is executed BEFORE the enforcer plugin -- phasevalidate/phase configuration !-- The execution should not fail if the properties file cannot be found -- quiettrue/quiet files filesomething.properties/file /files /configuration /execution /executions /plugin With this, the execution of the Enforcer plugin should be skipped only in modules that contain the 'something.properties' with the property 'enforcer.skip=true'. I only tested it briefly, but it seems to work. Hope that helps Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Release Plugin - Putting Release Version into scmCommentPrefix
I don't think it's possible (yet). I'd suggest to file a feature request at http://jira.codehaus.org/browse/MRELEASE. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Relative path to parent directory at multi module maven project
I normally define a property called something like
'multiproject.basedir' in every POM - or at least in every POM that
needs to reference a path in the parent project dir.
Some examples:
- in 'parent/pom.xml' it's:
multiproject.basedir${basedir}multiproject.basedir
- in 'parent/sub1/pom.xml' it's:
multiproject.basedir${basedir}/..multiproject.basedir
- in 'parent/sub1/sub2/pom.xml' it's:
multiproject.basedir${basedir}/../..multiproject.basedir
With this, You have a common property to locate Your configuration in
the parent project dir.
Another approach would be similar to Sharing Assembly Descriptors [1].
It's just little more complicated:
1. Create module that contains the all the configuration files. It
should use the Assembly plugin to package the file into a ZIP (or TAR or
whatever) archive and install it to the local repo.
2. Use the dependency:unpack goal to extract the contents of the ZIP
archive, that was created by the new module, and bind it to the
'pre-site' phase. You can do this configuration once in the parent POM
and inherit it to all modules.
2.a. If You like/need, You could use the resources:copy-resources goal
to overwrite the extracted configuration files with custom files that
are placed in the modules. Also bind it to the 'pre-site' phase. This
configuration can also be inherited from the parent to all module POMs.
3. Configure the site plugins to use the unpacked configuration files in
each module. Even this can be done in the parent POM and inherited to
the modules.
Kind regards, Marc
[1]
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Setting pom properties from Maven Plugin for resource filtering
Hi Ronen, take a look at the Properties Maven Plugin [1]. I don't have any experience with that plugin, because I haven't used it yet. But it looks like it should do exactly what You want to achieve with Your custom Maven plugin. However, if it doesn't work out for You, You could at least take a look at the source code to see how it adds the properties to the project model. The Build Helper Maven Plugin [2] also sets some properties, You could check its sources, too. One more point: I assume You checked that Your configuration of the Resources plugin works properly ... Kind regards Marc [1] http://mojo.codehaus.org/properties-maven-plugin [2] http://mojo.codehaus.org/build-helper-maven-plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Missing artifact javax.transaction:jta:jar:1.0.1B
Hi, the artifact does not exists in Central, right. But there's no need to download and install it manually. The artifact is available in the repository http://download.java.net/maven/2, You just only need to add it to Your Nexus and/or Maven settings. Regards, Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Assembly Advice
On 18/05/11 18:49, Eric Kolotyluk wrote: My current structure is +-- pom.xml ! +--- mod1 +--- mod2 needs an assembly and depends on mod1 mod3 +--- mod3 +--- mod4 needs an assembly and depends on mod1 mod3 Executing the assembly plugin in mod2 and mod4 should work. I did this in many builds and never experienced any problems. There're just some things to care about: The assembly plugin has to be bound to the package phase. This means, that tere'll be 2 executions in that phase: jar:jar (or war:war or whatever Your packaging implies) and assembly:single. Unfortunately there's no defined behaviour for the execution sequence of 2 goal being bound to the same phase. But I noticed that the plugins are executed in the same order like they're defined in the POM. This means that you'll (only) have to care for the order of the plugin declarations in Your POM. And if there's not declaration for You POM's packaing plugin, You could simply add an empty declaration: plugins plugin artifactIdmaven-jar-plugin/artifactId /plugin plugin artifactIdmaven-assembly-plugin/artifactId executions execution idassemble/id goalsgoalsingle/goal/goals phasepackage/phase configuration appendAssemblyIdtrue/appendAssemblyId ... /configuration /execution /executions /plugin /plugins As the build now produces 2 artifacts, You should never omit the classifier in the assembly archive's final name. Once again: AFAIK this is *not a supported behaviour* - but it always worked for me. Are you saying I need to define something like +-- pom.xml ! +--- mod1 +--- mod2 +--- mod3 +--- mod4 +--- mod-ass2 +--- pom.xml (dependencies to mod1, mod2 and mod3) +--- mod-ass4 +--- pom.xml (dependencies to mod1, mod3 and mod4) How will that ensure that mod1, mod2, mod3, mod4 will pass through the install phase, before mod-ass2 and mod-ass4 pass through the package phase.? The Maven reactor should do that automatically, if the required modules for each assembly are declared as (compile or runtime) dependencies in the POM. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: help - how to reduce the build time using mvn and cargo
Java memory settings are not defined like system properties - You shouldn't use '-D'. Try this: set MAVEN_OPTS=-Xms=1024M -Xmx=1024M This might not solve Your problem, but it should fix the memory reservation/allocation. BTW: I wouldn't modify the mvn.bat. Just set the MAVEN_OPTS as an environment var. On 12/05/11 18:53, javadaisy wrote: I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat. It didn't work - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release plugin question
developerConnectionscm:svn:https://dev.envieta.com:8443/svn/dlm}/developerConnection ^ Could it be this closing curly bracket? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Only partial filtering of .bat with assembly
Which version of the plugin do You use? I filed a bug report for this problem and it was solved with the plugin version 2.2.1. See: http://jira.codehaus.org/browse/MASSEMBLY-528 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Only partial filtering of .bat with assembly
I just checked it once more. With the plugin version 2.2, filtering didn't work when there was an '@' character somewhere in the document. My problem was solved with version 2.2.1, but in my case there wasn't an '@' character in the same line. BTW: Your workaround is not bad! Another idea would be adding a foo property to the statement: -Dfix=@. Filtering works, if there's an even number of '@' characters. Formally (e.g. with Maven 1) filter tokens looked like this: @propname@. I think the problem is sort of a relic ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Subversion.
I was just thinking a bit about this. You're facing different problems You won't be able all at once: 1. You could create the releases of the sub modules independently (first You'd have to create a release of the parent, using 'mvn release:prepare release:perform -N'). Problem: the dependencies in the other sub modules wouldn't be updated to the new SNAPSHOT version of the released module. 2. You could release all modules together. Problems: You can only have tags for the whole multi project, but You can't have separate tags for each sub module (I think, but I can't verify this right now). Furthermore You'd always have to release all the sub modules together, but I'd assume that You'd rather like to release just one (or some) of the sub modules at the same time. BTW: You'd face the same (or similar) problems with other SCMs, too. What about requesting a new feature/parameter for the maven-release-plugin, e.g. 'releaseModule'. It could be configured the same way like the command line option '--projects'. If the parameter is not set, the plugin would create the release as it already does right now, and otherwise it would only tag and release the specified module(s). What do You (list members) think about this approach? Kind regards, Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Subversion.
Didn't notice that parameter before. Sounds interesting - if it would really create a separate release tag for every module. But it wouldn't solve the problem of releasing just one (or some) of the modules in the reactor. On 20/04/11 14:01, Stephen Connolly wrote: I've never set up a test project to see exactly what it does, but I thoughthttp://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#commitByProject might do something nice... or not! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Subversion.
On 20/04/11 13:55, Wendy Smoak wrote: On Wed, Apr 20, 2011 at 6:59 AM, Marc Rohlfspomar...@googlemail.com wrote: I was just thinking a bit about this. You're facing different problems You won't be able all at once: 1. You could create the releases of the sub modules independently (first You'd have to create a release of the parent, using 'mvn release:prepare release:perform -N'). Not necessarily. If that parent (in the directory with the svn externals) is only there as an aggregator for convenience, it never needs to be released. I didn't involve the svn:externals idea into my thoughts, because it would only work if the modules don't inherit from the parent. In most multi-module projects (I've seen), modules do inherit parent configurations. I You want to release a sub module, the release plugin requests the parent to be released first - which might be achieved using 'mvn release:prepare release:perform -N'. The projects themselves could have some other parent, like a corporate level parent pom that controls versions, etc. A project can only declare oneparent but it's not 1:1. You're right, but Maven discourages this: [WARNING] [WARNING] Some problems were encountered while building the effective model for test:my-sub-module:jar:1.0-SNAPSHOT [WARNING] 'parent.relativePath' points at test:my-parent instead of test:another-parent, please verify your project structure @ line 11, column 11 [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] - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Subversion.
On 20/04/11 14:41, Marc Rohlfs wrote: On 20/04/11 13:55, Wendy Smoak wrote: On Wed, Apr 20, 2011 at 6:59 AM, Marc Rohlfspomar...@googlemail.com wrote: I was just thinking a bit about this. You're facing different problems You won't be able all at once: 1. You could create the releases of the sub modules independently (first You'd have to create a release of the parent, using 'mvn release:prepare release:perform -N'). Not necessarily. If that parent (in the directory with the svn externals) is only there as an aggregator for convenience, it never needs to be released. I didn't involve the svn:externals idea into my thoughts, because it would only work if the modules don't inherit from the parent. In most multi-module projects (I've seen), modules do inherit parent configurations. I You want to release a sub module, the release plugin requests the parent to be released first - which might be achieved using 'mvn release:prepare release:perform -N'. The projects themselves could have some other parent, like a corporate level parent pom that controls versions, etc. A project can only declare oneparent but it's not 1:1. You're right, but Maven discourages this: [WARNING] [WARNING] Some problems were encountered while building the effective model for test:my-sub-module:jar:1.0-SNAPSHOT [WARNING] 'parent.relativePath' points at test:my-parent instead of test:another-parent, please verify your project structure @ line 11, column 11 [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] P.S.: Maybe the maven-invoker-plugin could solve this in another way ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Tim, I hope You don't mind the question, but did You add the the wagon jar to the MAVEN_HOME/lib directory on Your Hudson server, too? Anyway, I'd rather not add any libraries to the MAVEN_HOME/lib directory, because this needs to be done on each and every server and workstation where the Maven build has to be executed and would most likely be forgotten when setting up new environments. Furthermore, You won't be able to use Hudsons automatic installation support for Maven any more. I thought that adding the wagon JAR as a build extension as well as adding adding it as a plugin dependency would work with both M2 and M3. But if You really need different configurations for M2 and M3, You could use different profiles that are automatically activated when the build is executed with M2 or M3. [1] shows how this could be achieved. One last question: How is the Your Maven repository realised? Reading Your posts, I assume that You might use an Apache server and copy the artifacts to the docroot (using the scp wagon). I'd suggest to use a repository manager, it provides You with several advantages over a simple docroot and normally work fine with the HTTP(S) protocols. See [2], it provides a list of the commonly used repository mangers along with some general information. Especially take a look at the feature matrix [3], it will help You to select the right one for Your needs - I'd suggest to take a closer look at Nexus ;) Kind regards Marc [1] https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.x [2] http://maven.apache.org/repository-management.html [3] http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Hi Tim, On 06/04/11 12:34, Tim Pizey wrote: I cannot see in what sense ssh is an extension ... In the sense that it is not incuded in the Maven core anymore ... ;) ... But if You really need different configurations for M2 and M3, You could use different profiles that are automatically activated when the build is executed with M2 or M3. Thanks, yes, different profiles occurred to me, but really I want a single pom which will build under m2 and m3. Currently scp does not work under M2 or M3. It is a single POM. Both profiles (I think You only need one for M3) are defined inside the POM. Return to the original version of Your POM an define the scp build extension in a profile, that is automatically activated when the build is executed with M3. I'd suggest to use a repository manager, it provides You with several advantages over a simple docroot and normally work fine with the HTTP(S) protocols. I guess I am forced to, but I have used this simple, elegant mechanism since maven1 ! I do not see the use case for repository managers, and am in disagreement with the decision not to support per-dependency repositories. (My take on the success of the internet is decentralization). I'd say repository managers provide even more elegant features. They allow (amongst others) proxying public repos (to reduce traffic and download/build times), Legacy (M1) to default (M2/M3) repo layout transformation, automatic snapshot clean-up and finding dependencies by contained Java classes. Define Your repo manager as a mirror in Your settings.xml ... What should I do about older M2 repositories? eg http://webmacro.sourceforge.net/maven2/ Proxy them in the repo manager ... See [2], it provides a list of the commonly used repository mangers along with some general information. Especially take a look at the feature matrix [3], it will help You to select the right one for Your needs - I'd suggest to take a closer look at Nexus ;) So scp support has been removed to drive people to Nexus ?? I don't know why it was removed - maybe someone else can answer this. I'd suggest that one of the reasons was to get a lighter (and faster) Maven core. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: mvn deploy and site in one go
And you don't have to deploy the first time, install is enough (mvn install site site:deploy) and deploy later on skipping the tests if the first run was successful. Right, forgot to mention that, many thanks!!! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Antwort: Re: mvn deploy and site in one go
If now only every other plugin (checkstyle/findbugs) would support such a 'two-phase' model as well. If these were just setting a property (like the corresponding ant-targets) that could be evaluated in the 'verify' phase... The Findbugs and Checkstyle plugins provide different goals, for reports and for default builds. Check the available goals in the plugin documentations ([1] and [2]). Use the plugin executions to configure the goals to any phase of any Maven life cycle, You can even have separate configurations (per execution) - [3] is a good reference to get started with this. Cheers Marc [1] http://mojo.codehaus.org/findbugs-maven-plugin/plugin-info.html [2] http://maven.apache.org/plugins/maven-checkstyle-plugin/plugin-info.html [3] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: mvn deploy and site in one go
another idea could be to call Maven with the --fail-at-end (-fae) option. But this doesn't seem to work with Maven 3 anymore. Even if 'fail-at-end' was working: wouldn't the artifacts still be deployed, when running 'mvn deploy' ? Yes, You're right - didn't think about that. It could be solved if You add another build configuration (mvn deploy -Dmaven.test.skip=true) that is only triggered when the main build finishes successfully. Our buildtimes vary from 30min to 3hour (yeah - big heavy integration tests). How are the integration tests executed in Your build? You should use the maven-failsave-plugin instead of the maven-surefire-plugin. The maven-failsave-plugin doesn't fail the build, but the test failures will be in Your reports. Another (last) idea, that just occurred to me: You could try to avoid build configurations for multi module projects and have a separate build configuration for every single module (per POM). This should decrease the number of tests per build execution so that it might be affordable if tests are executed twice. Build configurations would be triggered by VCS changes and snapshot dependencies. (Maybe not suitable for You but at least another idea) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy and site in one go
Hi Stefan, another idea could be to call Maven with the --fail-at-end (-fae) option. But this doesn't seem to work with Maven 3 anymore. Maybe it could be worth it for You filing a regression report for Maven 3 at [1]. #3 ... sound interesting! The most complicated thing here is to share data between two builds. But this might be possible with TeamCity artifact dependencies. I think this should work fine. I did something similar for a customer with TeamCity: A main build created the deployable archives using Maven and another build was tiggered when the main build finished (successfully) and used Ant to deploy the archives. I remember that I configured die 'Artifact Paths' in 'General Settings' to (sort of) published the relevant files, so that they can be accessed by the subsequent build (using the 'artifact dependencies' configuration?) Also developers would be informed that a build is broken, but need to wait until the 'report' build gets scheduled. I'd say they wouldn't need to wait much more time than they had/have to when using Your Ant builds. The 'report' build would be triggered immediately after the other one has finished (using the 'Finish Build trigger'). [1] http://jira.codehaus.org/browse/MNG - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-enforcer-plugin and Maven 3
There's already a bug report about this (You could vote for it): http://jira.codehaus.org/browse/MENFORCER-98 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy and site in one go
Hi Stefan, I don't understand why You're so anxious the run the tests only once on Your CI environment. You're dealing with two different purposes (build and reporting), that are often handled independently from each other. And normally the CI environment isn't too busy, so that it can easily afford executing the tests twice. Insisting on Maven to run the test only once, generate the test result report AND fail the build on errors won't work, You'll need to accept some limitations or tweak on of the Surefire plugin or Team City. I see the following possibilities: 1. Just accept having to independent build configurations - my favorite, too ;) 2. Change the invocation sequence: 'mvn site-deploy deploy'. Problem: the site generation doesn't fail, but the build won't fail either (because it won't execute the tests a second time). 3. Creating a second build configuration for 'mvn site-deploy', and trigger it when the 'mvn deploy' build is finished - it can be triggered even if the build 'mvn deploy' build failed. You could try to use the same working directory for both build configurations or at least the same report output directory and configure the 'maven-surefire-report-plugin' with the report set 'report-only'. A shared report output directory could e.g. be defined using a Team City environment variable. Use a profile, that is automatically activated when Maven is invoked by Team City, to configure the Surefire plugins with the shared report output directory. (I didn't verify all this) I could imagine some more possibilities, but they would be evil and I won't describe them here ... Kind regards Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Defining common localRepository that will work on both Windows and linux
As Windows und Unix have a different file system structures, I'd say
you'll need to work with properties. Call 'mvn help:system' on both
systems and try to find a common property (either system property or
environment variable) You could use. The Maven Properties Guide [1]
gives some further information about available properties. You could
either define a custom environment variable on each workstation and use
that one.
Some examples how You could define the local repositories using a property:
localRepository${user.home}/.m2/repository/localRepository
localRepository${env.HOME}/.m2/repository/localRepository
localRepository${env.CUSTOM_REPO_ENV_VAR}/localRepository
[1] http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: JMeter in Maven
Not too nice but at least something You could start with: http://wiki.apache.org/jakarta-jmeter/JMeterMavenPlugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Debugging maven-dependency-plugin
If can't find useful information in the debug output, it's getting somewhat hard to analyse. In the last instance You could try to debug it using the IDE: 1. Download the sources of the dependency plugin version Your're using from the SVN and integrate/import it in Your IDE. 2. Set a debug break point at the begining of the execute() method in the CopyDependenciesMojo class. 3. Start Your build using the command 'mvnDebug' (instead of 'mvn'). Maven now waits for a remote debugger to connect until it starts the build. 4. In Your IDE, start the remote debugger for the maven-dependency-plugin project (using port 8000). The execution of the Maven build should stop at the break point and You can start debugging ... BTW: I think I have an idea why the servlet-api-2.3.jar isn't excluded when copying the dependencies. Try using a dot instead of a dash: excludeGroupIdsjavax.servlet/excludeGroupIds - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: help:effective-settings
Add the '-X' option to Your command line statement and check the output - with Maven 3.0.3, the interesting output is somewhere within the first 15 lines. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using the new maven assembly goals
Hi Rui, I guess You were formally using the 'assembly:assembly' (or 'assembly:directory') goal, right? Those goals where not inherited by default in multi-project builds [1], but they forced Maven to build all included POMs up to the package phase before the assembly is processed [1]. This is discouraged now, You should assemble Your release artifacts using an additional submodule instead - like discribed in [2]. About Your POM and command invocation: In contrast to using 'assembly:assembly', the 'assembly:single' goal is inherited to the sub modules. The results are: - With inherited=false, the 'assembly:single' execution is missing the assembly descriptor configuration. - With inherited=true, the 'assembly:single' execution cannot find Your assembly descriptor, because it expects a 'release.xml' file in the base directory of each sub module. - You could call 'mvn help:effective-pom -N' to not recurse into the sub modules, but how would You get their artifacts then? One last point: With all my questions I wanted to tell You that You should tend to provide all the information that might be needed to answer Your question. Even in Your last mail I didn't find enough information so that I had to guess what You really want to achieve and how Your assembly descriptor might look like. (And I guess that this lack of information is the main reason why no one else took care of Your question so far) Kind regards Marc [1] http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html [2] http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using the new maven assembly goals
Hi Rui, normally inheritedfalse/inherited should work for You. It is a Maven core parameter and it doesn't depend on the plugin goal You are using. I can only guess about possible problems, maybe You should provide some more code and/or information like: - Where is this Your plugin configuration located (in the main build section, in the pluginManagement section or even in a profile) - Are there any other occurrences of maven-assembly-plugin configuration in this POM? - Does Your POM inherit configuration from another parent POM? - Which Maven version do You use? - Which plugin version is actually used? - How do You run (invoke) Maven? To analyse the problem, You could add the '-X' when You run maven. Calling 'mvn help:effective-pom' could help, too. Have a nice weekend Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 site: how to add report configured in module to parent's report config?
I would guess that this is the expected behavior, as otherwise it would not be possible to remove reports defined in the parent. You will have to add all the reports again if you want them to run in this module. No, it's a bug. Inheritance of report plugin configuration worked with Maven 2 and should also work with Maven 3. Pls take a look at http://jira.codehaus.org/browse/MSITE-484. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mirrors
Partially true. For my own repositories, this will work. However, Maven also checks the repositories defined in all dependencies and those I have no influence over. I normally define a mirror that also covers those repositories (using a wild card and/or a thirdparty mirror definition like the one I stated in the other post), because it's very annoying when Maven attempts to fetch dependencies from each and very repository that is defined somewhere - sometimes those builds can take really long. Of course, You're right that You can't differentiate between release and snapshot repositories. I didn't take that in account, because I don't rely on thirdparty snapshots ... Would've been great if Maven had an option to mirror types of repositories (release/snapshot) as well as id's. I think that would be a good idea. Could be worth it filing a feature request in the Maven Jira. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mirrors
Did You try something like this: mirrors mirror idshapshot-mirrors/id nameSnapshot Mirros/name urlhttp://snapshots.mycompany.com/repo/url mirrorOf*-snapshots/mirrorOf /mirror mirror idrelease-mirrors/id nameRelease Mirros/name urlhttp://releases.mycompany.com/repo/url mirrorOf*-releases/mirrorOf !-- Or maybe: mirrorOf!*-snapshots/mirrorOf -- /mirror mirror !-- OPTIONAL!!! -- idthirdparty-mirrors/id nameThirdparty Mirros/name urlhttp://proxy.mycompany.com/repo/url mirrorOf!*-releases,!*-snapshots/mirrorOf /mirror /mirrors I didn't double-check, but I'd say this should work ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mirrors
I haven't tried that, but what I read from the Maven-pages, it doesn't understand wildcards like that... But I can try though... I thought it would work, but I am not sure - I have to admit ... Then again, it would only work if the repositories are actually named like that, and I can't always influence that (3rd party!)... You use the repository IDs in the 'mirrorOf' configuration, and those IDs are defined in Your pom.xmls or Your settings.xml, where You define the remote repositories You want to use - this means that You should be able to influence that. Or did I misunderstand Your problem? Ah well, for now I'll take the Nexus-solution[1] and explicitly add a snapshot-repository that is always active. OK, if You have everything in one Nexus, creating a repository group for all of Your repositories (even including proxy repos) is the best way, of course. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War plugin (2.1-beta-1,*] problem
You really made my day. Thank you very very much. You're welcome! I dont know how to thank you. Just take a little time once in a while to answer a question in this list Yourself ... :) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment in Repository without version in file name?
Another idea might be:
1. In Your Maven project, create a text file with the following content:
http://your-nexus/your-nexus-repo/${project.artifactId}-${project.version}.${project.packaging}
2. Use the 'resources:copy-resources' with 'filtering=true' to copy the
file somewhere and get its tokens replaced (see
http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.html).
3. Use wget with the -i (--input-file=FILE) option and the '-O' option.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: War plugin (2.1-beta-1,*] problem
Hi Cem, that example helped a lot, before seening that, I could only guess ... The solution for Your problem is to set the 'useCache' parameter of the maven-war-plugin to 'true'. Seems like the default value for this parameter changed between the 2 plugin versions. plugin artifactIdmaven-war-plugin/artifactId version2.1.1/version !--version2.1-beta-1/version-- executions execution phaseprepare-package/phase goalsgoalexploded/goal/goals /execution /executions configuration useCachetrue/useCache /configuration /plugin If You execute Your build in debug mode (using the '-X' switch) - once with each plugin version - and pipe the output to different text files, You can simply use a diff editor to analyse the differences between the executions of the plugin versions ... In Your setup, You could even stick with the 'prepare-package' for the 'war:exploded' execution. If the maven-war-plugin is configured in the same 'build/plugin' configuration BEFORE the maven-replacer-plugin, You can rely on the wanted execution sequence. Normally it's better to use difference life cycle phases, because the execution sequence for plugins wired to the same phase isn't reliable in all cases. As an example, let's assume You'd like to to switch on the replacement only for special cases. To achieve that, You might configure the maven-replacer-plugin in a profile, and Maven wouldn't know which on to execute first, if both are bound to the same phase. Also I dont know how did you conclude that I have not enough knowledge about lifecycle... Anyway. You wrote that You changed Your custom plugin lifecycle to 'process-resources' instead of the 'war:exploded', which obviously seemed to be the wrong order - as far as I understood what You wanted to achieve. THAT gave me the impression that You weren't aware about the order of the life cycle phases. Didn't mean to sound rude, but sometimes it's useful to clarify things ... Kind regards Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War plugin (2.1-beta-1,*] problem
Hi Cem! But another question, why didnt my configuration work? For packagingpom/packaging, the 'war:war' goal is already bound to the package phase (with the execution ID 'default-war'). With 'test2', You added an additional execution with its own configuration. Please take a look at the build output. You'll see 2 'war:war' executions: 1. The first one is the 'default-war' execution. It works with 'useCache=false' and overwrites the 'new-token' text file with 'old-token' file. 2. The second one is the 'test2' execution. It works with 'useCache=true', but the text file has already been reset by the 'default-war' execution. Try to rename 'test2' to 'default-war' and You'll see that it works like You assumed: now there's only one 'war:war' execution left, and it works with 'useCache=true'. Maybe I'm wrong, but I'd suggest not to be too confident that the default execution ID will always be 'default-war'. What I did is just globally setting 'useCache=true' for all executions (including Your custom war:exploded). One last point: I'd suggest not to modify the resources in the same directory where the maven-war-plugin assembles them. This might sometimes lead to unwanted effects, e.g. when You want to do a simple build without executing the 'clean' life cycle. What about this: 1.a) Copy the resources to be modified to another (custom) subfolder of the target directory (e.g. using the resources:copy-resources goal; see http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.html) and use Your plugin to modify the resources in there. 1.b) Configure Your custom plugin (or the maven-replacer-plugin) with input directory 'src/main/webapp' and set its output directory to a (custom) subfolder of the target directory. 2. Use the 'webResources' parameter of the maven-war-plugin to add the modified resources to Your webapp (see http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html). Kind regards Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War plugin (2.1-beta-1,*] problem
Just for curiosity: what happens if You configure the 'prepare-war' execution of Your test configuration for the 'process-resources' phase? As Your custom plugin goal and the 'war:exploded' goal are both configured for the same phase, are You sure that they're really executed in the estimated order? Regarding Your command line statement: I'd not rely my build on additional goals that have to be added to the command line statement. It's predestined to cause problems, because other project members might forget to add that argument. I'd always tend to configure it using a plugin execution. On 14/02/11 13:41, Cem Koc wrote: Also tried such configuration to test. It is still changing that processed files with unprocessed files. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1.1/version executions execution idprepare-war/id phaseprepare-package/phase goals goalexploded/goal /goals /execution /executions /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: War plugin (2.1-beta-1,*] problem
1) Create an exploded directory of project 2) Make necessary processing at prepare package phase 3) Create a war which has processed files I am not sure that I understood everything very good but I changed my custom plugin lifecycle to 'process-resources'. It did not help me as I expected. It's the other way round! If I understood You right, You use Your custom goal to modify the contents of the exploded directory and add it to the WAR afterwards. 1) Bind the 'war:exploded' goal to the phase 'process-resources' 2) Bind Your custom goal to the phase 'prepare-package'. 3) Configure the 'war:war' goal to include the contents of the exploded directory in the WAR file. 3.1) If this still doesn't work, You might additionally configure the 'war:war' goal to exclude original files from 'src/main/webapp' using the 'warSourceExcludes' parameter. I have to impression that You're not familiar with the build lifecycle, might that be? See http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference. Furthermore, You should present a little more of You configuration (or an example that behaves similarly). It's hard to help if I have to guess what You're really doing there ... (If providing an example, You might e.g. configure the antrun plugin instead of Your custom plugin) On 14/02/11 14:43, Cem Koc wrote: Hi, I am not sure that I understood everything very good but I changed my custom plugin lifecycle to 'process-resources'. It did not help me as I expected. (Cmd: mvn clean war:exploded package) At the logs I could see successfully processed files. My custom plugin is processing sources without any problem. War goal of the war plugin is changing files I am sure about this. I tested with (*,2.1-beta-1] and I have not encountered any problem. Just newer version of the 2.1-beta-1 has this problem. By the way, It might be helpful mvn clean war:exploded prepare-package is working great too as a flat directory. thanks Marc Rohlfs wrote: Just for curiosity: what happens if You configure the 'prepare-war' execution of Your test configuration for the 'process-resources' phase? As Your custom plugin goal and the 'war:exploded' goal are both configured for the same phase, are You sure that they're really executed in the estimated order? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 support for org.apache.maven.user-settings
On 09/02/11 16:16, Wayne Fay wrote: started working with an alias: alias mvn='mvn -s .../settings.xml' But this wouldn't work on Windows machines ... I've done something similar with mvnclienta and mvnclientb. You simply copy the mvn.bat file, rename it, and insert the -s .../settings-clienta.xml into the call to mvn directly. This seems like a reasonable approach to me on any OS. I'm starting the terminal with some additional, client-specific environment variables. This allows me to use different Maven, Java, etc. versions, depending on each client's specifications. With Your approach, I see 2 problems: 1. I wouldn't like to create new mvnclient* scripts on every version upgrade. And when I simply copy them from another Maven version, I'd first have to check if there aren't any changes in the original scripts. 2. Hudson offers automatic installation of Maven distributions. This is a very nice feature, because (especially in bigger organisations) admins often don't like to provide developers with access to the server hosts. But don't see a (reasonable) way the replicate the mvnclient* scripts in an automatically installed distribution. Marc - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 support for org.apache.maven.user-settings
Hi there, the command line argument works (for me). But in Hudson (V 1.394), You need to add the '-s .../settings.xml' arguments to each project's build configuration. A global settings configuration for all Maven builds could only be set using the 'MAVEN_OPTS' with the 'org.apache.maven.user-settings' (or 'org.apache.maven.global-settings') property. In Hudson's project build configuration there's another field called 'Alternate settings file'. Help item says that it's equivalent to using the '-s' option, but it doesn't seem to work with Maven 3 - guess that configuration feature is also implemented using 'MAVEN_OPTS'. (OK, this might be worth filing a bug report in the Hudson Jira) Personally, I also used to use the 'MAVEN_OPTS' on my development environment, too. Doing development consultancy for different customers, I prefer to have separate Maven settings for each customer workspace, and it would really be annoying having to add the '-s' option (with maybe a long file path argument) to each and every command line statement. After noticing that I can't set them any more using the 'MAVEN_OPTS', I started working with an alias: alias mvn='mvn -s .../settings.xml' But this wouldn't work on Windows machines ... All in all I'd prefer if the support for both of the system properties, 'org.apache.maven.user-settings' and 'org.apache.maven.global-settings' could be restored, because it would provide much more flexibility to all imaginable build environment setup variants. Kind regards Marc On 08/02/11 21:50, Vincent Latombe wrote: Use -s command-line argument? Vincent 2011/2/8 radairadai.rosenbl...@gmail.com Benjamin Bentmann wrote: There is no alternative but support for the system property can be restored if there's a valid use case for it. Benjamin we have a hudson CI server running builds for multiple (maven) projects, each with its own repositories. it would be nice to seperate the settings.xml between builds, and not lump them all together - for that i'd need to override the location of the settings file. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-tp3261146p3375624.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: WARNINGS in Maven Build: maven-compiler-plugins missing
An explanation can be found in the Maven 3.x Compatibility Notes: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution BTW: The version numbers can either be defined in the 'pluginManagement' and/or in the 'plugins' section - depends on Your project. On 04/02/11 06:47, Anders Hammar wrote: A very similar question was asked on the list some weeks ago. You need to lock down the (specify) the version of maven-compiler-plugin. You do that in the pluginManagement section. An example is here: http://maven.apache.org/pom.html#Plugin_Management (Note: You don't need to specify any executions though.) /Anders On Fri, Feb 4, 2011 at 06:16, Jonthan DeMaagdjondema...@gmail.com wrote: [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for org.sonatype.mavenbook.custom:simple-weather:jar:1.0 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 69, column 12 [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] .. .. Project builds and runs fine. But I really want to take care of these WARNINGS! Have not had much luck with tutorial, Maven by Example or online resources. Went to this as last resource! Thanks much! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: adding a jar as resource to a webapp
I'd suggest it could be a JAR containing an Applet. The maven-dependency-plugin might help You out. Use on of the following approaches: http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html On 02/02/11 17:06, Antonio Petrelli wrote: The jar should not be added to the classpath at build, runtime! And it should not be included in WEB-INF/lib. Not at build, not at runtime and not in WEB-INF/lib? What do you need it for? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Attach sources/javadoc to system-scoped dependency
What do You need the sources and the download JARs for? Guess You like to be attached to the library in You IDE project, right? For Eclipse I see 2 workarounds: 1. This is evil, but it worked for me in a little test project: Deploy the JARs (main artifact, sources and javadoc) to the repository. Then declare the same dependency twice in Your POM, one with 'system' scope and one with 'provided' scope - the 'system' scoped dependency node should be declared first. 2. Create a user library for the JAR in Eclipse and configure the maven-eclipse-plugin: - use the 'classpathContainers' parameter to add the library to the project classpath. - use the 'excludes' parameter to remove the 'system' scoped library from the project classpath instead. On 01/02/11 14:34, Hauschild, Klaus (EXT) wrote: Is there no other solution? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?
I'll watch this issue as I'm really interested in how it might be handled.
Personally I don't have a clear position here.
Sometimes I'd like the property interpolation to be a little more
dynamic. It would e.g. be great if I could activate a profile by the
existence of a file whose path contains an interpolatable token (like
'src/main/filters/${target.environment}/something.properties'). But I
understand that something like this might lead to confusing
interpolation behaviour which sometimes could be hard to maintain. Like
Luke wrote, those build configurations would be less declarative.
What about introducing something like property scopes and/or types?
properties
my-prop scope=... type=...foo/my-prop
!-- 'scope' = 'global|pom' --
!-- 'type' = 'mutable|immutable' --
/properties
This was just a spontaneous idea, not really well-thought (yet).
On 28/01/11 18:11, Evgeny Goldin wrote:
Created an issue:http://jira.codehaus.org/browse/MNG-4998
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?
I'd say properties should be static - otherwise predefining them using
the command line switch '-D' wouldn't work properly. BTW: With this
Maven 3 show the same behaviour like Ant (I know, I shouldn't compare
them), where properties are always immutable.
I just checked it with the the Buildnumber Plugin
(http://mojo.codehaus.org/buildnumber-maven-plugin):
properties
buildNumberpredefined/buildNumber
/properties
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuildnumber-maven-plugin/artifactId
version1.0-beta-4/version
executions
execution
idinitialize/id
goals
goalcreate/goal
/goals
phaseinitialize/phase
configuration
revisionOnScmFailurescm-revision/revisionOnScmFailure
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.6/version
executions
execution
idecho/id
goals
goalrun/goal
/goals
phasegenerate-sources/phase
configuration
target
echo message=${buildNumber} /
/target
/configuration
/execution
/executions
/plugin
/plugins
/build
It shows exactly the same behaviour: with Maven 2 it prints
'scm-revision' and with Maven 3 it prints 'predefined'. Maybe it might
help You if You file an issue in the Jira for that component.
Maybe as a workaround You could introduce something like a
'defaultValue' for each property in Your plugin configuration(s).
Kind regards, Marc
On 27/01/11 20:55, Evgeny Goldin wrote:
But it can be perfectly changed in Maven 2 and I use it a lot. It's just that
in Maven 3 the expression doesn't reflect the change out of sudden.
-
Best regards,
Evgeny
http://evgeny-goldin.com/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to loose the /target/...
Looks a little strange to me, trying to do this kind of copy action
using the POMs build resources configuration. I'd suggest to use the
'resources:copy-resources' goal:
http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.html.
The 'outputDirectory' parameter should be configurable with any path,
even outside of the 'target' directory - You'd have to try it, I didn't
double-check ...
On 25/01/11 09:10, martin krüger wrote:
Hi everyone,
currently I try to copy some files with the maven-resources-plugin. Is
there any chance to get rid of the /target/ folder during the copy of
files? I'm using the following lines:
resource
filteringtrue/filtering
directory${basedir}/src/site/directory
targetPath${staging.dir}/bin/targetPath
/resource
and it results always in something like /target/myFolder/file.
Or even better. Is there a chance to loose the whole folder structure during
the copy action? If the source is something like
+src
+-main
+--a.file
+--b.file
+--c.file
--- result
+mytarget
+-a.file
+-b.file
+-c.file
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Generating web project with java, webapp, and resource folder from archtype goal
Did You check the doc of the archetype plugin? This should solve Your problem: http://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html On 19/01/11 10:30, Piotr Skawinski wrote: Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Assembly Plug-in - Creating custom root folder inside TAR file
Simply add 'includeBaseDirectoryfalse/includeBaseDirectory' to Your 'bin.xml'. (See http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_assembly) On 20/01/11 12:33, Tirumal Reddy Moolamalla wrote: I need something like this. Example.tar -MyFolder But I am getting like this. Example.tar ---Example MyFolder - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Assembly Plug-in - Creating custom root folder inside TAR file
yes!
On 20/01/11 12:56, Tirumal Reddy Moolamalla wrote:
I got solution to this. You just need to
putincludeBaseDirectoryfalse/includeBaseDirectory in your assembly
descriptor file.
Regards,
Tirumal Reddy M
-Original Message-
From: Tirumal Reddy Moolamalla [mailto:t.moolama...@zensar.com]
Sent: Thursday, January 20, 2011 5:04 PM
To: users@maven.apache.org
Subject: Maven Assembly Plug-in - Creating custom root folder inside TAR file
Hi,
I want to create a tar file using assembly plugin. I am able to do create a tar
file but unable to customize the root folder. It always is project/module name.
For example: My module name is Example and I want to create Example.tar file and it should directly
contain MyFolder. But when I create tar file the MyFolder is under the Example folder by
default.
I need something like this.
Example.tar
-MyFolder
But I am getting like this.
Example.tar
---Example
MyFolder
Below are my bin.xml and pom.xml.
pom.xml
-
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2/version
executions
execution
phaseprocess-resources/phase
goals
goalsingle/goal
/goals
/execution
/executions
configuration
descriptors
descriptor${project.basedir}/src/main/assembly/bin.xml/descriptor
/descriptors
/configuration
/plugin
bin.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;
idbin/id
formats
formattar/format
/formats
fileSets
fileSet
directory${project.basedir}/src/main/MyFolder/directory
outputDirectoryMyFolder/outputDirectory
/fileSet
/fileSets
/assembly
Regards,
Tirumal Reddy M
-
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: set up maven repository for all the mirrors
I should be possible, of course. I'd suggest to talk to Your company's network admin about Apache and DNS configuration. On 17/01/11 19:38, anemdhana wrote: Hello everyone, I found this is really useful to setup internal maven repository http://www.jfrog.org/products.php, which takes care of getting dependencies by looking into all repositories. A simple question, I want to setup this in an intranet environment; by allowing ldap authentication; Right now, I am able to access in my local box as, http://localhost:8080/artifactory with jetty-7 servelt container running on port 8080. is it possible to have customized url by having apache-webserver installed, like, http://repo.mycompany.com/artifactory - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problem when upgrading from maven2 to maven3
See the Maven 3 compatibility note on dependency resolution: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-DependencyResolution. It suggests to inspect the dependency tree that is printed when running Maven in debug mode. On 18/01/11 04:17, 刘勇坡 wrote: Can you tell me what I can do? and why a project work with maven2 well can't not be build with maven3? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
