Re: How do i layout subversion with a project made of multiple modules ?
That's the way I do it, and then I use externals to checkout the branch combination I want (this is actually done automatically for me bythe Subversive Eclipse plugin). I like this approach because it allows me to control which subprojects to branch and when. On the other hand the Maven release plugin can't cope with this setup. Cheers, Nicola Musatti Celinio Fernandes wrote: Hi, I was looking for some information on how to layout subversion with a maven project made of multi modules and found this interesting discussion : http://getsatisfaction.com/sonatype/topics/how_do_i_layout_subversion_with_multi_module_builds I'd like to know if anyone in this mailing list can also share his experience regarding this matter. Currently I have set things in SVN such that each module has its own trunk/tags/branches. What do you think ? Thanks for helping. Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non gli sia pervenuto per errore. In tal caso e' pregato di avvisare immediatamente il mittente e, tenuto conto delle responsabilita' connesse all'indebito utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso contenute, voglia cancellare l'originale e distruggere le varie copie o stampe. The receiver of this message is required to check if he/she has received it erroneously. If so, the receiver is requested to immediately inform the sender and - in consideration of the responsibilities arising from undue use and/or disclosure of the message and/or the information contained therein - destroy the original message and any copy or printout thereof. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
release process and SNAPSHOT upgrade
Hi, My project has dependencies on various common components, that have their own release lifecycle To get quicker bug-fixes and features we used to get them as SNAPSHOT, and when we plan a release we release first the commons, then the project. To do this, I need to upgrade my POM to switch snapshots to recent released version, here is the workflow : * release common * upgrade POM to released commom * release the project I would like to automate the latest steps using versions:use-releaseshttp://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html BUT using this one as a preparationGoal in release plugin fails, as the Don't use SNAPSHOT rule is checked by release plugin before the preparationGoal is executed. Do you have any suggestion on the way to do this ? Maybe I should create a Jira to change the release proces task order, so that the SNAPSHOT check occurs AFTER preparationGoal (makes sense to me, but maybe this has some side-effects) Cheers, Nicolas
shade plugin and aggregated javadocs
Hello folks, I have a multi-module project which includes a pom-only module to create a binaries uber-jar plus a corresponding sources jar using the shade plugin. Now I want to add a jar of corresponding javadocs. Unfortunately the shade plugin doesn't have a createJavadocsJar parameter analogous to its createSourcesJar, so I've been trying to work out how to do it. After reading the javadoc plugin docs I added the following section to my uber-jar project pom: plugin artifactIdmaven-javadoc-plugin/artifactId version2.7/version executions execution phasepackage/phase goals goaljar/goal /goals configuration includeDependencySourcestrue/includeDependencySources dependencySourceIncludes dependencySourceIncludecom.googlecode.jaitools:*/dependencySourceInclude /dependencySourceIncludes excludePackageNamesjaitools.demo.*/excludePackageNames /configuration /execution /executions /plugin This seems to work well if I run from the uber-jar module's directory. When the build is run from the parent (top) directory no javadocs are generated for the uber-jar project. There is a javadoc section in the parent pom to build javadocs within each standard module. Perhaps this is overriding the javadoc section in the uber-jar's pom ? I'm sure this must be a standard task. I'd be very grateful for any tips. The full parent pom is here: http://jai-tools.googlecode.com/svn/trunk/pom.xml The uber-jar project pom is here: http://jai-tools.googlecode.com/svn/trunk/jt-all/pom.xml Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to release a single module in a Mercurial repository?
Hello, Perso, I have tested MRELEASE-457 with git and svn. So it look to need some hack to work with the hg scm provider. Can you load a jira issue I will have a look ? Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/3 Andreas Ebbert-Karroum andreas.ebbert-karr...@codecentric.de: Hi, I still stand by my claim that the story of releasing a single module in a hg multi-module repository is currently not possible. Now you might say, that this is against conventions, and you should always release the whole repository, but usage of of maven and mercurial differs, and after all it's convention over configuration and not convention or not at all. In this E-Mail I will prove to you that this is not possible, if you will follow me through the following steps. If at any point I missed an option I would like you to raise your voice :) *Step 1* So, I started with a very simple multi-module project (/pom.xml and /multi/pom.xml) and tried to release just a single module (multi). It turned out that this is not possible, because during the release:perform phase, the whole hg repository is checked out, and the build is started in the root of that repository. = Use the latest maven-release-plugin:2.2-SNAPSHOT in which MRELEASE-457http://jira.codehaus.org/browse/MRELEASE-457is fixed. *Step 2* The new dependencies with the snapshot release plugin also updates to a newer hg scm provider. The new hg scm provider has the interesting new habit to throw an exception, when you want to tag something, which does not concern the whole repository. Caused by: org.apache.maven.scm.ScmException: This provider doesn't support tagging subsets of a directory at org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77) at org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) ... 29 more = Update the dependencies of maven-release-plugin:2.2-SNAPSHOT to use maven-scm-provider-hg:1.4 *Step 3 * The next step was to move the parent pom out of the root of the hg repository. We have a standardized layout in our hg repositories (to take into account various tradeoffs between maven, m2eclipse, hudson, etc.) that we have all projects in directories under the root directory. So I tried to have / root / pom.xml (having a module ../multi) and / multi / pom.xml (having a parent ../root) The release plugin did not like that at all: [INFO] EXECUTING: cmd.exe /X /C hg commit --message [maven-release-plugin] prepare release root-1.6 C:\Temp\releasetest\parent\pom.xml C:\Temp\releasetest\multi\pom.xml [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp/releasetestrepo* [INFO] Tagging release with the label root-1.6... [INFO] EXECUTING: cmd.exe /X /C hg tag --message [maven-release-plugin] copy for tag root-1.6 root-1.6 [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp* [ERROR] EXECUTION FAILED Execution of cmd : push failed with exit code: -1. Working directory was: c:\temp\releasetest Your Hg installation seems to be valid and complete. Hg version: 1.6.2 (OK) This is probably a bug, but I have no idea if this is in the scm provider, release plugin, shared components, ... I'm glad to create a jira issue for it, but would like to do so for the right project. = Having no pom.xml in the root of the repository is apparently a bad idea. But we need to have our parent in a folder under the root directly. So I created a thin dummy pom, which just has the real parent as module. *Step 4* So we now have: / pom.xml / parent / pom.xml / multi / pom.xml While I created the root pom.xml, I tried to optimize a bit and included localCheckout=true to the plugin configuration, so that the tag checkout does not happen from the remote repository, but from the local one. Bad idea: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2-SNAPSHOT:perform (default-cli) on project root: The scm url is invalid. [ERROR] - An hg 'file' url must be on the form 'file:///' or 'file://localhost/'. My scm url is: scm:hg:file:///C:/Temp/releasetestrepo So also the remote hg repository is on the local filesystem, but when the local checkout occurs, the url is apparently not constructed correctly. = Ok, no localCheckout. Not a big deal, moving on. *Step 5* If possible, I don't want the /parent/pom.xml to inherit from /pom.xml, because it may well be, that it needs to inherit from something completely different. I only wanted to use the /pom.xml as a forwarder to /parent/pom.xml. So I tried that, and tried to release the multi-module. I did this by running from working directory /parent the command mvn --batch-mode -pl multi release:prepare. But I could not find a working scm configuration in
Re: release process and SNAPSHOT upgrade
This is probably obvious but I think even if you were able to run the version updates the release plugin will complain about having local modifications. The updated pom would also need to be committed before the m-release-p will be happy. On Mar 4, 2011 5:33 AM, nicolas de loof nicolas.del...@gmail.com wrote: Hi, My project has dependencies on various common components, that have their own release lifecycle To get quicker bug-fixes and features we used to get them as SNAPSHOT, and when we plan a release we release first the commons, then the project. To do this, I need to upgrade my POM to switch snapshots to recent released version, here is the workflow : * release common * upgrade POM to released commom * release the project I would like to automate the latest steps using versions:use-releases http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html BUT using this one as a preparationGoal in release plugin fails, as the Don't use SNAPSHOT rule is checked by release plugin before the preparationGoal is executed. Do you have any suggestion on the way to do this ? Maybe I should create a Jira to change the release proces task order, so that the SNAPSHOT check occurs AFTER preparationGoal (makes sense to me, but maybe this has some side-effects) Cheers, Nicolas
Re: Upgrading maven-embedder from 2.0.4 to 3.0.2
On Mar 4, 2011, at 2:40 AM, Anders Hammar wrote: Easier in that post isn't referring to easier to code as in fewer lines of code, but rather making it possible to embed in an extensible way. Maven 2.x was a command line tool, where Maven 3.0 has a modular design so that it can be embedded in tools like m2eclipse, for example. This was simply just not possible (in a good way) with Maven 2.x. As I understand it, maven-embedder stopped at 2.0.4 for Maven 2 because they ran into too many issues trying to get it to work with the old Maven 2 code base. Correct. /Anders On Fri, Mar 4, 2011 at 06:13, mraible m...@raibledesigns.com wrote: This seems somewhat complicated - isn't there an easier way? Of the top 10 reasons to use Maven, #4 is it's easier to embed. http://www.sonatype.com/people/2011/02/top-ten-reasons-to-move-to-maven-3/ -- View this message in context: http://maven.40175.n5.nabble.com/Upgrading-maven-embedder-from-2-0-4-to-3-0-2-tp3379984p3408943.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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
How to include site into war file?
Hi,
I've got a project, which is distributed as a web application. I'd
like to include the site into the webapp. As you possibly know, the
assembly plugin does support this, so it shouldn't be all too
impossible.
I tried the following snippet in my POM. Unfortunately, this seems to
trigger an endless loop between the site and the javadoc plugin.
Any other ideas how I might achieve my goal?
Thanks,
Jochen
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
phasegenerate-resources/phase
goals
goalsite/goal
/goals
configuration
outputDirectory${webappDirectory}/docs/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
--
I Am What I Am And That's All What I Yam (Popeye)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: release process and SNAPSHOT upgrade
Ryan, Actually, you can modify the pom during preparationGoals as that is precisely the stage where the pom can be modified because thee release plugin has just modified it and is building with the modified pom to validate that the modifications work. Nicolas, Perhaps what is needed is another place to insert goals... I've already added completionGoals to help with CI (though I have still to spin a version of the release plugin with that parameter exposed) The idea being that you could, in the preparationGoals, specify a goal that would resolve the dependency ranges into concrete versions and then use the completionGoals to open up the ranges again. Your use-case is somewhat similar so maybe we need another hook-point... though the more hook points we add, the more complex things get. It would be nice if you could just use the existing hook points, but here goes... if we had an initiationGoals so that it would look a little something like: 1. Call initiationGoals 2. Validate for release 3. Modify pom to proposed release 4. Call preparationGoals 5. Commit release poms 6. Tag release 7. Modify pom to dev of next version 8. Call completionGoals 9. Commit next dev poms That would give you scope to do some of what you want to do... though you'd have to specify the initiationGoals as something like versions:use-releases scm:commit so that the validation would work. And yes, I'd be wary of doing one set of validation checks and then calling some postScmChecksInitiationGoals followed by the scmChecks... whatever about adding an initiationGoals (which smells a bit hacky), splitting the validation step in to two and adding another fork point in-between is a no-go to me. ARGH there is one issue there. Pom modification does not result in a re-read of the pom itself. So even if you did modify the pom in an initiationGoals you'd be scuppered anyway. Perhaps the best think to do is to use the invoker plugin, use a profile called makeRelease which has the defaultGoal of validate and bind your invoker plugin to that phase... in that case releasing for you would just be mvn -PmakeRelease that would run invoker which would run on the current pom using src/release/invoker.properties (or whatever you choose to call it) which would then specify in sequence the series of mvn invokations to fire) H longer response than I had planned -Stephen On 4 March 2011 10:50, Ryan Connolly ryn...@gmail.com wrote: This is probably obvious but I think even if you were able to run the version updates the release plugin will complain about having local modifications. The updated pom would also need to be committed before the m-release-p will be happy. On Mar 4, 2011 5:33 AM, nicolas de loof nicolas.del...@gmail.com wrote: Hi, My project has dependencies on various common components, that have their own release lifecycle To get quicker bug-fixes and features we used to get them as SNAPSHOT, and when we plan a release we release first the commons, then the project. To do this, I need to upgrade my POM to switch snapshots to recent released version, here is the workflow : * release common * upgrade POM to released commom * release the project I would like to automate the latest steps using versions:use-releases http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html BUT using this one as a preparationGoal in release plugin fails, as the Don't use SNAPSHOT rule is checked by release plugin before the preparationGoal is executed. Do you have any suggestion on the way to do this ? Maybe I should create a Jira to change the release proces task order, so that the SNAPSHOT check occurs AFTER preparationGoal (makes sense to me, but maybe this has some side-effects) Cheers, Nicolas
How can I specify jetty version or use maven3 with latest jetty ?
Hi all I used to have a project run well with maven2 and jetty 6. Today I updated to maven3 today. There were an exception when I run my project with mvn jetty:run, says that: there's no plugin in found with name jetty. So I add pluginGrouporg.mortbay.jetty/pluginGroup to settins.xml . And it reported an other error: [INFO] jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest [INFO] [INFO] --- jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest --- [WARNING] The POM for javax.servlet.jsp.jstl:jstl-api:jar:1.2 is missing, no dependency information available [WARNING] The POM for org.glassfish.web:jstl-impl:jar:1.2 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.156s [INFO] Finished at: Fri Mar 04 14:25:01 GMT 2011 [INFO] Final Memory: 4M/8M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run (default-cli) on project learntest: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run failed: Plugin org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2 or one of its dependencies could not be resolved: The following artifacts could not be resolved: javax.servlet.jsp.jstl:jstl-api:jar:1.2, org.glassfish.web:jstl-impl:jar:1.2: Failure to find javax.servlet.jsp.jstl:jstl-api:jar:1.2 in http://localhost/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. I have added java.net/glassfish to nexus repositories, but it seems doesn't work. How can I specify jetty version or solve the problem ?
Re: Maven 3 deploy jar name appending numbers
Is there any way of limiting the number of deployed snapshot jars? We deploy these every night, Is the only solution to set up a job that to ensures the # of deployed snapshot jars is kept constant? Thanks for the info -Dave --- On Thu, 3/3/11, Wayne Fay wayne...@gmail.com wrote: From: Wayne Fay wayne...@gmail.com Subject: Re: Maven 3 deploy jar name appending numbers To: Maven Users List users@maven.apache.org Date: Thursday, March 3, 2011, 4:59 PM I tried changing this flag uniqueVersion to false, but still the same effect. This did not occur with maven 2. any ideas on how to make the output of deploy be jarname-8.5.3-SNAPSHOT.jar? This is how Maven3 works, read the compatibility notes for M3. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments Wayne - 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: Maven 3 deploy jar name appending numbers
That's how you would do it with Nexus - schedule the Remove Snapshots from Repository task. You can configure it different ways (minimum count, retention days, remove if released). /Anders On Fri, Mar 4, 2011 at 15:48, hall baseball hallbaseb...@yahoo.com wrote: Is there any way of limiting the number of deployed snapshot jars? We deploy these every night, Is the only solution to set up a job that to ensures the # of deployed snapshot jars is kept constant? Thanks for the info -Dave --- On Thu, 3/3/11, Wayne Fay wayne...@gmail.com wrote: From: Wayne Fay wayne...@gmail.com Subject: Re: Maven 3 deploy jar name appending numbers To: Maven Users List users@maven.apache.org Date: Thursday, March 3, 2011, 4:59 PM I tried changing this flag uniqueVersion to false, but still the same effect. This did not occur with maven 2. any ideas on how to make the output of deploy be jarname-8.5.3-SNAPSHOT.jar? This is how Maven3 works, read the compatibility notes for M3. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can I specify jetty version or use maven3 with latest jetty ?
The problem is likely that you don't have all required repositories for the dependencies of the plugin defined as plugin repositories. Someone else had the exact same problem (different plugin though) earlier this week. In Maven 3, dependencies for plugins are only retrieved from pluginRepositories. This was not the case in Maven 2. /Anders On Fri, Mar 4, 2011 at 15:42, clt phoenix@gmail.com wrote: Hi all I used to have a project run well with maven2 and jetty 6. Today I updated to maven3 today. There were an exception when I run my project with mvn jetty:run, says that: there's no plugin in found with name jetty. So I add pluginGrouporg.mortbay.jetty/pluginGroup to settins.xml . And it reported an other error: [INFO] jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest [INFO] [INFO] --- jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest --- [WARNING] The POM for javax.servlet.jsp.jstl:jstl-api:jar:1.2 is missing, no dependency information available [WARNING] The POM for org.glassfish.web:jstl-impl:jar:1.2 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.156s [INFO] Finished at: Fri Mar 04 14:25:01 GMT 2011 [INFO] Final Memory: 4M/8M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run (default-cli) on project learntest: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run failed: Plugin org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2 or one of its dependencies could not be resolved: The following artifacts could not be resolved: javax.servlet.jsp.jstl:jstl-api:jar:1.2, org.glassfish.web:jstl-impl:jar:1.2: Failure to find javax.servlet.jsp.jstl:jstl-api:jar:1.2 in http://localhost/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. I have added java.net/glassfish to nexus repositories, but it seems doesn't work. How can I specify jetty version or solve the problem ?
java.lang.SecurityException: signer information does not match signer information of other classes in the same package
Hello everyone
I'm trying to get the maven-processor-plugin execute the EclipseLink's
CanonicalModelProcessor to generate metamodels for JPA. I'm following
the blog entry
http://blog.gueck.com/2009/12/generating-jpa-20-criteria-canonical.html
that describes how to set up this with Maven.
When executing mvn generate-sources, I get the following exception:
[INFO] diagnostic error: java.lang.SecurityException: class
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProperties's
signer information does n
ot match signer information of other classes in the same package
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.RuntimeException: java.lang.SecurityException: class
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProperties's
signer information doe
s not match signer information of other classes in the same package
at
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor.process(CanonicalModelProcessor.java:407)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:625)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:554)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:699)
at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:981)
at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
at com.sun.tools.javac.main.Main.compile(Main.java:353)
...
I think that this is caused by two concurring versions of eclipselink.
My project depends on the OSGI version, but the maven-processor-plugin
on the normal eclipselink version. The OSGI version is signed, the
normal version not. The plugin has to use the normal version, because
the CanonicalModelProcessor only is contained in this jar.
dependencies
...
dependency
!-- signed OSGI version --
groupIdorg.eclipse.persistence/groupId
artifactIdorg.eclipse.persistence.jpa/artifactId
scopecompile/scope
/dependency
...
/dependencies
plugin
groupIdorg.bsc.maven/groupId
artifactIdmaven-processor-plugin/artifactId
dependencies
dependency
!-- unsigned OSGI version --
groupIdorg.eclipse.persistence/groupId
artifactIdeclipselink/artifactId
version${eclipselink.version}/version
/dependency
/dependencies
/plugin
Do you have any ideas how I can get around this security exception?
Thanks in advance,
James
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How can I specify jetty version or use maven3 with latest jetty ?
I think I'm running afoul of this but am not sure what the right solution is (I'm the SysAdmin for some deva switching to maven3). A plugin that builds fine under maven2 can't find a dependency under maven3, yet I see it deployed/cached under repo1-cache where it's always been. It only appears to look in: plugins-release plugins-snapshot plugins-release-local plugins-snapshot-local Are you saying that I have to define repo1-cache as a plugin repository? Am I likely going to wind up listing all the caches as plugin repositories? My apologies for being clueless - I never had to use Artifactory (2.3.2) or Maven (3.0.2) before about four days ago. :-) -ste On Mar 4, 2011, at 10:13 AM, Anders Hammar and...@hammar.net wrote: The problem is likely that you don't have all required repositories for the dependencies of the plugin defined as plugin repositories. Someone else had the exact same problem (different plugin though) earlier this week. In Maven 3, dependencies for plugins are only retrieved from pluginRepositories. This was not the case in Maven 2. /Anders On Fri, Mar 4, 2011 at 15:42, clt phoenix@gmail.com wrote: Hi all I used to have a project run well with maven2 and jetty 6. Today I updated to maven3 today. There were an exception when I run my project with mvn jetty:run, says that: there's no plugin in found with name jetty. So I add pluginGrouporg.mortbay.jetty/pluginGroup to settins.xml . And it reported an other error: [INFO] jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest [INFO] [INFO] --- jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest --- [WARNING] The POM for javax.servlet.jsp.jstl:jstl-api:jar:1.2 is missing, no dependency information available [WARNING] The POM for org.glassfish.web:jstl-impl:jar:1.2 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.156s [INFO] Finished at: Fri Mar 04 14:25:01 GMT 2011 [INFO] Final Memory: 4M/8M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run (default-cli) on project learntest: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run failed: Plugin org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2 or one of its dependencies could not be resolved: The following artifacts could not be resolved: javax.servlet.jsp.jstl:jstl-api:jar:1.2, org.glassfish.web:jstl-impl:jar:1.2: Failure to find javax.servlet.jsp.jstl:jstl-api:jar:1.2 in http://localhost/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. I have added java.net/glassfish to nexus repositories, but it seems doesn't work. How can I specify jetty version or solve the problem ? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to release a single module in a Mercurial repository?
Please use hg scm provider component Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/4 Andreas Ebbert-Karroum andreas.ebbert-karr...@codecentric.de: Hi Olivier, I can gladly do so. Do you want me to report that for the maven-release-plugin, or is that an issue with the hg scm provider? Andreas 2011/3/4 Olivier Lamy ol...@apache.org Hello, Perso, I have tested MRELEASE-457 with git and svn. So it look to need some hack to work with the hg scm provider. Can you load a jira issue I will have a look ? Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/3 Andreas Ebbert-Karroum andreas.ebbert-karr...@codecentric.de: Hi, I still stand by my claim that the story of releasing a single module in a hg multi-module repository is currently not possible. Now you might say, that this is against conventions, and you should always release the whole repository, but usage of of maven and mercurial differs, and after all it's convention over configuration and not convention or not at all. In this E-Mail I will prove to you that this is not possible, if you will follow me through the following steps. If at any point I missed an option I would like you to raise your voice :) *Step 1* So, I started with a very simple multi-module project (/pom.xml and /multi/pom.xml) and tried to release just a single module (multi). It turned out that this is not possible, because during the release:perform phase, the whole hg repository is checked out, and the build is started in the root of that repository. = Use the latest maven-release-plugin:2.2-SNAPSHOT in which MRELEASE-457http://jira.codehaus.org/browse/MRELEASE-457is fixed. *Step 2* The new dependencies with the snapshot release plugin also updates to a newer hg scm provider. The new hg scm provider has the interesting new habit to throw an exception, when you want to tag something, which does not concern the whole repository. Caused by: org.apache.maven.scm.ScmException: This provider doesn't support tagging subsets of a directory at org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77) at org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) ... 29 more = Update the dependencies of maven-release-plugin:2.2-SNAPSHOT to use maven-scm-provider-hg:1.4 *Step 3 * The next step was to move the parent pom out of the root of the hg repository. We have a standardized layout in our hg repositories (to take into account various tradeoffs between maven, m2eclipse, hudson, etc.) that we have all projects in directories under the root directory. So I tried to have / root / pom.xml (having a module ../multi) and / multi / pom.xml (having a parent ../root) The release plugin did not like that at all: [INFO] EXECUTING: cmd.exe /X /C hg commit --message [maven-release-plugin] prepare release root-1.6 C:\Temp\releasetest\parent\pom.xml C:\Temp\releasetest\multi\pom.xml [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp/releasetestrepo* [INFO] Tagging release with the label root-1.6... [INFO] EXECUTING: cmd.exe /X /C hg tag --message [maven-release-plugin] copy for tag root-1.6 root-1.6 [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp* [ERROR] EXECUTION FAILED Execution of cmd : push failed with exit code: -1. Working directory was: c:\temp\releasetest Your Hg installation seems to be valid and complete. Hg version: 1.6.2 (OK) This is probably a bug, but I have no idea if this is in the scm provider, release plugin, shared components, ... I'm glad to create a jira issue for it, but would like to do so for the right project. = Having no pom.xml in the root of the repository is apparently a bad idea. But we need to have our parent in a folder under the root directly. So I created a thin dummy pom, which just has the real parent as module. *Step 4* So we now have: / pom.xml / parent / pom.xml / multi / pom.xml While I created the root pom.xml, I tried to optimize a bit and included localCheckout=true to the plugin configuration, so that the tag checkout does not happen from the remote repository, but from the local one. Bad idea: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2-SNAPSHOT:perform (default-cli) on project root: The scm url is invalid. [ERROR] - An hg 'file' url must be on the form 'file:///' or 'file://localhost/'. My scm url is: scm:hg:file:///C:/Temp/releasetestrepo So also the remote hg repository is on the local filesystem, but when the local checkout occurs, the url is apparently not
Re: How to release a single module in a Mercurial repository?
Ok, it's http://jira.codehaus.org/browse/SCM-612 I'm glad (even eager!) to try out any patch :) Thanks, Andreas 2011/3/4 Olivier Lamy ol...@apache.org Please use hg scm provider component Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/4 Andreas Ebbert-Karroum andreas.ebbert-karr...@codecentric.de: Hi Olivier, I can gladly do so. Do you want me to report that for the maven-release-plugin, or is that an issue with the hg scm provider? Andreas 2011/3/4 Olivier Lamy ol...@apache.org Hello, Perso, I have tested MRELEASE-457 with git and svn. So it look to need some hack to work with the hg scm provider. Can you load a jira issue I will have a look ? Thanks ! -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy 2011/3/3 Andreas Ebbert-Karroum andreas.ebbert-karr...@codecentric.de : Hi, I still stand by my claim that the story of releasing a single module in a hg multi-module repository is currently not possible. Now you might say, that this is against conventions, and you should always release the whole repository, but usage of of maven and mercurial differs, and after all it's convention over configuration and not convention or not at all. In this E-Mail I will prove to you that this is not possible, if you will follow me through the following steps. If at any point I missed an option I would like you to raise your voice :) *Step 1* So, I started with a very simple multi-module project (/pom.xml and /multi/pom.xml) and tried to release just a single module (multi). It turned out that this is not possible, because during the release:perform phase, the whole hg repository is checked out, and the build is started in the root of that repository. = Use the latest maven-release-plugin:2.2-SNAPSHOT in which MRELEASE-457http://jira.codehaus.org/browse/MRELEASE-457is fixed. *Step 2* The new dependencies with the snapshot release plugin also updates to a newer hg scm provider. The new hg scm provider has the interesting new habit to throw an exception, when you want to tag something, which does not concern the whole repository. Caused by: org.apache.maven.scm.ScmException: This provider doesn't support tagging subsets of a directory at org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77) at org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) ... 29 more = Update the dependencies of maven-release-plugin:2.2-SNAPSHOT to use maven-scm-provider-hg:1.4 *Step 3 * The next step was to move the parent pom out of the root of the hg repository. We have a standardized layout in our hg repositories (to take into account various tradeoffs between maven, m2eclipse, hudson, etc.) that we have all projects in directories under the root directory. So I tried to have / root / pom.xml (having a module ../multi) and / multi / pom.xml (having a parent ../root) The release plugin did not like that at all: [INFO] EXECUTING: cmd.exe /X /C hg commit --message [maven-release-plugin] prepare release root-1.6 C:\Temp\releasetest\parent\pom.xml C:\Temp\releasetest\multi\pom.xml [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp/releasetestrepo* [INFO] Tagging release with the label root-1.6... [INFO] EXECUTING: cmd.exe /X /C hg tag --message [maven-release-plugin] copy for tag root-1.6 root-1.6 [INFO] EXECUTING: cmd.exe /X /C *hg push file:///C:/Temp* [ERROR] EXECUTION FAILED Execution of cmd : push failed with exit code: -1. Working directory was: c:\temp\releasetest Your Hg installation seems to be valid and complete. Hg version: 1.6.2 (OK) This is probably a bug, but I have no idea if this is in the scm provider, release plugin, shared components, ... I'm glad to create a jira issue for it, but would like to do so for the right project. = Having no pom.xml in the root of the repository is apparently a bad idea. But we need to have our parent in a folder under the root directly. So I created a thin dummy pom, which just has the real parent as module. *Step 4* So we now have: / pom.xml / parent / pom.xml / multi / pom.xml While I created the root pom.xml, I tried to optimize a bit and included localCheckout=true to the plugin configuration, so that the tag checkout does not happen from the remote repository, but from the local one. Bad idea: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2-SNAPSHOT:perform (default-cli) on
AUTO: Andreas Schlosser is out of the office. (returning 03/08/2011)
I am out of the office until 03/08/2011. This message is not forwarded. I will respond to your message when I return. In urgent cases please contact mcommerce-supp...@sybase.com Regards Andreas Schlosser Note: This is an automated response to your message Re: Upgrading maven-embedder from 2.0.4 to 3.0.2 sent on 3/4/2011 1:21:26 PM. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can I specify jetty version or use maven3 with latest jetty ?
You would simplify things by grouping the repos (in the repo manager, Artifactory) instead of handling them one by one. I think it's called virtual repos in Artifactory terms. If you ask on the Artifactory users list, they could probably help you. /Anders On Fri, Mar 4, 2011 at 17:05, shaun.t.erick...@accenture.com wrote: I think I'm running afoul of this but am not sure what the right solution is (I'm the SysAdmin for some deva switching to maven3). A plugin that builds fine under maven2 can't find a dependency under maven3, yet I see it deployed/cached under repo1-cache where it's always been. It only appears to look in: plugins-release plugins-snapshot plugins-release-local plugins-snapshot-local Are you saying that I have to define repo1-cache as a plugin repository? Am I likely going to wind up listing all the caches as plugin repositories? My apologies for being clueless - I never had to use Artifactory (2.3.2) or Maven (3.0.2) before about four days ago. :-) -ste On Mar 4, 2011, at 10:13 AM, Anders Hammar and...@hammar.net wrote: The problem is likely that you don't have all required repositories for the dependencies of the plugin defined as plugin repositories. Someone else had the exact same problem (different plugin though) earlier this week. In Maven 3, dependencies for plugins are only retrieved from pluginRepositories. This was not the case in Maven 2. /Anders On Fri, Mar 4, 2011 at 15:42, clt phoenix@gmail.com wrote: Hi all I used to have a project run well with maven2 and jetty 6. Today I updated to maven3 today. There were an exception when I run my project with mvn jetty:run, says that: there's no plugin in found with name jetty. So I add pluginGrouporg.mortbay.jetty/pluginGroup to settins.xml . And it reported an other error: [INFO] jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest [INFO] [INFO] --- jetty-maven-plugin:8.0.0.M2:run (default-cli) @ learntest --- [WARNING] The POM for javax.servlet.jsp.jstl:jstl-api:jar:1.2 is missing, no dependency information available [WARNING] The POM for org.glassfish.web:jstl-impl:jar:1.2 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.156s [INFO] Finished at: Fri Mar 04 14:25:01 GMT 2011 [INFO] Final Memory: 4M/8M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run (default-cli) on project learntest: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2:run failed: Plugin org.mortbay.jetty:jetty-maven-plugin:8.0.0.M2 or one of its dependencies could not be resolved: The following artifacts could not be resolved: javax.servlet.jsp.jstl:jstl-api:jar:1.2, org.glassfish.web:jstl-impl:jar:1.2: Failure to find javax.servlet.jsp.jstl:jstl-api:jar:1.2 in http://localhost/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. I have added java.net/glassfish to nexus repositories, but it seems doesn't work. How can I specify jetty version or solve the problem ? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
freshest, most stable, version
Hello, I am interested in upgrading from Nexus 1.4.1 and while I weigh the various feature sets, I thought to poll the community as to what new versions are proving the most stable. Any pointers to issues-sites will be appreciated. Take care, Chris [cid:image001.png@01CBDA73.C87312F0] Christopher Hahn The Dude Software Production Engineering RD Services, Hewlett-Packard Phone: 858-655-4096 Cell: 619-630-9791 ch...@hp.commailto:christopher.h...@hp.com Visit our SPE Portalhttp://teams5.sharepoint.hp.com/teams/SPE/default.aspx
Re: freshest, most stable, version
I am interested in upgrading from Nexus 1.4.1 and while I weigh the various feature sets, I thought to poll the community as to what new versions are proving the most stable. The Nexus project maintains its own lists for questions like this: http://nexus.sonatype.org/project-information.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
