Fwd: Doxia Tools Converter Additional Usage Example (ant script)
For the archives
--Brian (mobile)
Begin forwarded message:
From: Adrien
Date: March 2, 2011 10:22:26 PM EST
To: bri...@apache.org
Subject: Doxia Tools Converter Additional Usage Example (ant script)
Hi,
i've found your project very useful. In my case, i neeeded to run with
dependencies included, but i had to inclue it in my existing tasks
processing, thus using ant.
Based on the following link :
http://maven.apache.org/doxia/doxia-tools/doxia-converter/usage.html
It could be also usefu for other people to have a dummy ant snippet to add
the conversion in their build. here is mine (apt to other formats), it'a
quite dummy and straightforward :
!--
http://maven.apache.org/doxia/doxia-tools/doxia-converter/usage.html
--
!--
#
#
# Generate Documentation
#
#
#
#
--
target name=doxia-convert
java
jar=./lib/doxia-converter-1.2-jar-with-dependencies.jar
dir=.
fork=true
failonerror=true
arg value=-in/
arg value=${tdi.apt}/
arg value=-out/
arg value=./doc/${tdi.apt}.${doxia.out.extension}/
arg value=-to/
arg value=${doxia.out.format}/
arg value=-from/
arg value=apt/
arg value=-f/
/java
/target
target name=doc.xhtml
antcall target=doxia-convert
param name = doxia.out.format value = xhtml/
param name = doxia.out.extension value = html/
/antcall
/target
target name=doc.docbook
antcall target=doxia-convert
param name = doxia.out.format value = docbook/
param name = doxia.out.extension value = xml/
/antcall
/target
target name=doc.rtf
antcall target=doxia-convert
param name = doxia.out.format value = rtf/
param name = doxia.out.extension value = rtf/
/antcall
/target
target name=doc.latex
antcall target=doxia-convert
param name = doxia.out.format value = latex/
param name = doxia.out.extension value = tex/
/antcall
/target
target name=doc
antcall target=doc.xhtml /
antcall target=doc.docbook /
antcall target=doc.rtf /
antcall target=doc.latex /
/target
Hopefully will it be useful to someone else.
Thank you for your work.
Kind Regards,
Adrien
Re: Multi-module source release assembly, using Common Apache POM version 7 not using moduleSets?
This descriptor assumes that all modules ate children of the execution root...or a tree. If that's not the case in your project then you would need to create a custom bundle descriptor. --Brian (mobile) On May 17, 2010, at 3:20 PM, Marshall Schor m...@schor.com wrote: The current common apache parent POM (version 7) [1], when you specify the apache-release profile, activates a part: plugins !-- Create a source-release artifact that contains the fully buildable project directory source structure. This is the artifact which is the official subject of any release vote. -- plugin artifactIdmaven-assembly-plugin/artifactId . . . executions execution idsource-release-assembly/id . . . configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot . . . /configuration When used on a multi-module aggregate project, this only creates the source-release-assembly at the aggregate project level. It seems to me, since this artifact is the official subject of any release vote, that this source assembly should include the sources from this aggregate project, plus all of the sub-modules . (Currently it only has the the source from this aggregate project; none of the submodules are included.) I think the assembly plugin attempts to support this use case, via its moduleSets elements. Are multi-module projects in Apache supposed to override the common Apache Parent and specify the moduleSets form of assembly? Or is there another preferred way to do this? -Marshall Schor [1] http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom - 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: Dependency:unpack version problem
Fwiw the depmgt is checked in the unpack/copy goals... But Stephen is right, unpack-dependencies is the right goal here. --Brian (mobile) On May 6, 2010, at 11:16 AM, Jörg Schaible joerg.schai...@gmx.de wrote: subir.sasiku...@wipro.com wrote: Use a property for the version + you can also use dependencyManagement. But I doubt whether dependencyManagement version will flow to dependency:unpack configurations. So property is best solution. Maybe you should read Stephen's answer also ... ;-) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugins and their versions
Take a look at the enforcer requirepluginversions rule. It will do what you have asked. --Brian (mobile) On Dec 30, 2009, at 10:26 AM, Roland Asmann roland.asm...@adesso.at wrote: Hi all! I was wondering if there is a plugin that can report all configured plugins in a POM. Important to me would be the configured version of the plugin, so if no such version is given, it should either not give the version or give it as 'latest'. Does anybody know of a plugin that can do this? Roland Asmann - 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: Links to artifacts in a snapshot repository
The nexus FAQ shows the link syntax: http://nexus.sonatype.org/nexus-faq.html#25 --Brian (mobile) On Dec 22, 2009, at 12:37 PM, Johannes Schneider maili...@cedarsoft.com wrote: Hi, at the moment I am creating a page for a project of mine. And because not everybody out there uses maven (don't understand why), I want to provide a link to the latest artifact for manual download. Of course that is not possible since every snapshot artifact has the build date prepended. How could that be solved? Sincerly, Johannes Sample repository: http://nexus.cedarsoft.com/content/groups/public-snapshots/com/cedarsoft/serialization/1.0.0-beta2-SNAPSHOT/ - 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: Difference between repo1.maven.org/maven2 and repo2.maven.org/maven2?
They are the same. Internally the nginx config for central is repo2 but how that came to be I don't know. --Brian (mobile) On Dec 6, 2009, at 3:23 PM, Brett Porter br...@apache.org wrote: To my knowledge, they are exactly the same thing at this point. - Brett On 07/12/2009, at 6:18 AM, Glen Mazza wrote: Hello, I had asked this question on a much older thread not immediately visible from Nabble, so I wanted to ask again in a new email in hopes of getting a response: What is the difference between Super POM[1]'s default repository http://repo1.maven.org/maven2 and http://repo2.maven.org/maven2/ ? Do they point to the same repository via URL redirection or to different but mirrored repositories or are they indeed different repositories with different artifacts in them? Thanks, Glen [1] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Super_POM -- View this message in context: http://old.nabble.com/Difference-between-repo1.maven.org-maven2-and-repo2.maven.org-maven2--tp26667984p26667984.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 -- Brett Porter br...@apache.org http://brettporter.wordpress.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: Plugin version in SUPER POM simply ignored, with trivial pom.xml
Go by help effective pom not describe, it looks hokey to me. Is 2.4.1 the latest? Maybe that's what is being reported. --Brian (mobile) On Dec 5, 2009, at 10:07 PM, kdwinkler keithdwink...@gmail.com wrote: Help even reports version 2.4.1 for the below pom: project ... build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version2.3/version /plugin /plugins /pluginManagement /build reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version2.3/version /plugin /plugins /reporting /project -- View this message in context: http://old.nabble.com/Plugin-version-in-SUPER-POM-simply-ignored%2C-with-trivial-pom.xml-tp26661071p26662106.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: [WARNING] POM is invalid. error messages in Maven 2.2.1 but not in 2.0.10
Maybe 2.2.2 will fix it. =)
Not likely. The pom is plain wrong an it was a bug in 2.x which
allowed it to go unnoticed.
On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall javabr...@gmail.com
wrote:
http://jira.codehaus.org/browse/MNG-4379 ... or did your team log
that :).
On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia
elle...@gmail.com wrote:
Hi Brett,
Thanks for the suggestion. I may have found the issue. Would it be
this:
Validation Errors:
[DEBUG] For dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped
dependency
must specify an absolute path systemPath.
[DEBUG] For managed dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped
dependency
must specify an absolute path systemPath.
[DEBUG]
[DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for
compile)
[DEBUG] Skipping disabled repository central
[DEBUG] myartifact: using locally installed snapshot
[WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
invalid.
Its dependencies (if any) will NOT be available to the current
build.
[DEBUG] Reason: Failed to validate POM for project
mypackage:myartifact at Artifact
[mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
[DEBUG]
Validation Errors:
[DEBUG] For dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped
dependency
must specify an absolute path systemPath.
[DEBUG] For dependency Dependency {groupId=weblogic,
artifactId=webservices, version=10.0, type=jar}: system-scoped
dependency must specify an absolute path systemPath.
[DEBUG] For managed dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped
dependency
must specify an absolute path systemPath.
[DEBUG] For managed dependency Dependency {groupId=weblogic,
artifactId=webservices, version=10.0, type=jar}: system-scoped
dependency must specify an absolute path systemPath.
[DEBUG]
Now in this project, we are inheriting from a parent POM
(standardised
for our department) with entries like this:
(WL_HOME is Weblogic install directory)
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.5.0.11/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
/dependency
dependency
groupIdcom.sun/groupId
artifactIdrt/artifactId
version1.5.0.11/version
scopesystem/scope
systemPath${java.home}/lib/rt.jar/systemPath
/dependency
dependency
groupIdweblogic/groupId
artifactIdweblogic/artifactId
version10.0/version
scopesystem/scope
systemPath${env.WL_HOME}/server/lib/weblogic.jar/
systemPath
/dependency
dependency
groupIdweblogic/groupId
artifactIdwebservices/artifactId
version10.0/version
scopesystem/scope
systemPath${env.WL_HOME}/server/lib/webservices.jar/
systemPath
/dependency
Now it only fails on the Weblogic related entries. With the Java
system dependencies it seems to do fine.
Has the handling of this changed from 2.0.* to 2.2.*?
If so, what should we replace it with?
And will these settings also work for people still using maven
2.0.10?
Ellecer
On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall javabr...@gmail.com
wrote:
Hi Ellecer
What is the output of mvn -e -X ...
Brett
On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia elle...@gmail.com
wrote:
Hi,
How come when I try a build using Maven 2.2.1 I get multiple
messages
like
this:
[WARNING] POM for 'mypackage.artifact:pom:1.0.2-
SNAPSHOT:compile' is
invalid.
Its dependencies (if any) will NOT be available to the current
build.
These errors weren't displaying when I was using Maven 2.0.10
I'm trying to use the newer version of Maven but I can't proceed
with
these error messages.
How can I find out what are the actual errors it's referring to? I
didn't come across any mention of relevant POM format changes
going
from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on
this it
would be a great help! Is there a way to validate the pom and get
format error details from Maven?
thanks,
Ellecer
---
--
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---
--
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For
Re: Frustration with snapshot updates
Then change your snapshot repo update policy to never. However since Maven keeps looking for something, there is cleary some other problem with your build setup. It's not normal for it to keep looking like that... That's what I was trying to help figure out. --Brian (mobile) On Oct 2, 2009, at 10:23 PM, Quintin Beukes quin...@skywalk.co.za wrote: It succeeds. There is nothing missing. I build the project from svn trunk, it get's installed in the repo, and now maven keeps trying to download it by iterating all my repositories. It's part of the snapshot updates. It happens with ALL snapshot dependencies. As soon as I add another snapshot dependency, it gets added to the list. Everything is fine. I can temporarily bypass it by updating the modification dates on the files, but that's only effective for 2 minutes, and I don't want to update them everytime I build. All I need is to disable snapshot updates for all repos, completely. I don't need it on this development. When I need it one day I'll re-enable it, and by then the dependancy will be released and won't be a snapshot anymore. Quintin Beukes On Sat, Oct 3, 2009 at 3:43 AM, Brian Fox bri...@infinity.nu wrote: On Fri, Oct 2, 2009 at 11:55 AM, Quintin Beukes quin...@skywalk.co.za wrote: Firstly, -o won't work, because I have to re-enable it everytime a build fails for a legitimate dependency. Secondly, it's snapshots built from dev source code - I update via SVN and build them to get the latest versions. So they're not available in the remote repositories yet. And it's definitely required dependencies. It's getting bad, because as the project grows, they get more, and I wait about 40 seconds now just for the downloads to fail, so my build can complete. Can complete with build failed or success? I feel like there's still something fundamentally missing here. Quintin Beukes On Fri, Oct 2, 2009 at 8:43 PM, Brian Fox bri...@infinity.nu wrote: On Fri, Oct 2, 2009 at 3:54 AM, Quintin Beukes quin...@last.za.net wrote: Hey, Whenever a project depends on a snapshot versioned library, then it tries to update this snapshot. If the snapshot isn't found in any of the repositories, then it obviously doesn't update. But now it tries again with the next build. And over, and over, and over. I'll ask the obvious question first: Why do you have a dependency that doesn't exist? And if your build succeeds without this dependency, is it even a defacto dependency? --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - 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: Assembly plugin Question
Make a new module that builds your assembly and place a dependency on the war so that it will run last. --Brian (mobile) On Jul 17, 2009, at 9:10 AM, Jim Collings jlistn...@gmail.com wrote: So I have a project which builds several submodules but culminates in the construction of a war file out of those submodules. In the end, all I need is the war file. How can I run an assembly AFTER and ONLY AFTER everything else is done and exclusive of the submodules? Jim C. - 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: dependency:tree in XML format
I'll try to push a release then this week. --Brian (mobile) On Jul 18, 2009, at 2:29 PM, lukewpatterson lukewpatter...@gmail.com wrote: Is there a build plugin that can generate the dependency list/tree in XML format? I found this open issue http://jira.codehaus.org/browse/MDEP-145 but it hasn't been released yet. Thanks, Luke -- View this message in context: http://www.nabble.com/dependency%3Atree-in-XML-format-tp24550574p24550574.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: Dependency missing on Windows
Not all the internal lists were linkedlists until 2.0.10. That means the jdk 1.5 vs 1.6 could be causing subtle differences in the resolution order. Upgrade both to 2.0.10 and you should have repeatable results that you can use to adjust your pom accordingly. --Brian (mobile) On Jul 17, 2009, at 9:46 AM, robert.kl...@innovations.de wrote: Hi, I have a strange experience with a missing dependency. The problem occurred when upgrading spring-ws-core to version 1.5.7. In that version they changed a dependency from stax:stax-api to javax.xml.stream:stax-api. This change worked fine on my machine (yeah, I know) but broke the build on our ci server, as the new dependency resolved to stax-api-1.0-2.jar which is built with Java 1.5 and not 1.4 (which we unfortunately must support). The interesting thing: when calling mvn dependency:tree on the server showed the dependency but it did not appear on my machine This of course would explain, why the build worked locally. Can anybody explain this difference in dependency resolution? Some details - The server is running Linux with Maven 2.0.9 and Java 1.5 - I'm using Windows XP with Maven 2.1.0 (but also tried 2.0.9 with same result) and Java 1.6 - Same Repositories - Server and Windows should use Java 1.4 for building - It is mulit-module project - In the project is a transitive dependency to stax:stax-api in version 1.0.1 (this version was used by spring-ws-core before the upgrade) Cheers, Robert Klaus Business Rules Management -- Innovations Software Technology GmbH Bosch Group Ziegelei 7, 88090 Immenstaad/GERMANY Tel. +49 7545 202-339 Fax +49 7545 202-301 robert.kl...@innovations.de www.innovations.de Executives: Achim Berger, Thomas Cotic, Walter Pitz, Thomas Schmid Register Court Ulm HRB 631888 This message may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please inform us immediately and destroy this message including all copies thereof. - 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: mirrors, oh mirrors
Yes, Nexus 1.3 supports true mirrors. http://www.sonatype.com/people/2009/03/new-feature-in-nexus-13-mirror-su pport/ -Original Message- From: CemKoc [mailto:cem.koc.fwd+nbl...@gmail.com] Sent: Wednesday, April 08, 2009 7:05 AM To: users@maven.apache.org Subject: Re: mirrors, oh mirrors Is there any solution about this problem? I'd like mirrors to provide multiple alternate locations. I put the improvement request here: http://jira.codehaus.org/browse/MNG-3772 Cheers, Szczepan -- View this message in context: http://n2.nabble.com/mirrors%2C-oh-mirrors-tp1125603p2604561.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: m2eclipse and crashing on any access to pom.xml
The m2eclipse user list is more appropriate for this, but Igor found these links: http://www.mail-archive.com/ubuntu-b...@lists.ubuntu.com/msg728168.html http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg21845.html so it doesn't seem specific to M2e. -Original Message- From: seand...@gmail.com [mailto:seand...@gmail.com] On Behalf Of Sean Davis Sent: Wednesday, April 08, 2009 3:09 PM To: users@maven.apache.org Subject: m2eclipse and crashing on any access to pom.xml I am running eclipse under: java -version java version 1.6.0_04 Java(TM) SE Runtime Environment (build 1.6.0_04-b12) Java HotSpot(TM) 64-Bit Server VM (build 10.0-b19, mixed mode) When I do anything to add a dependency, I get a crash of the VM: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2adcdb63522a, pid=18211, tid=1085491536 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x1f122a] # # An error report file with more information is saved as: # /home/sdavis/eclipse/hs_err_pid18211.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Any suggestions as to how to alleviate the problem? Do I really need to back up to java 1.5 to use m2eclipse as some sites suggest? Thanks, Sean
RE: Additional dependecy scope
You want to potentially use profiles to manage your dependencies. There isn't the ability to add new scopes. -Original Message- From: Uldis Karlovs-Karlovskis [mailto:uldis.karlovs-karlovs...@ctco.lv] Sent: Monday, April 06, 2009 2:53 AM To: 'Maven Users List' Subject: RE: Additional dependecy scope Hello again. Is anybody going to anser me? :( Regards, Uldis, C. T. Co uldis.karlovs-karlovs...@ctco.lv -Original Message- From: Uldis Karlovs-Karlovskis [mailto:uldis.karlovs-karlovs...@ctco.lv] Sent: piektdiena, 2009. gada 3. aprīlī 12:43 To: users@maven.apache.org Subject: Additional dependecy scope Hello! From documentation I see there are scopes for managing dependency artifacts. However, I need more of them. These are only to manage packaging and control one tests package, but I have different tests per project (unit, integration, selenium etc) and every of them should have some different jars in classpath. Also I`m deploying the same project to tomcat, jboss and websphere (there may be even different versions of them) so the EAR or WAR package libraries may differ for any of them. From documentation I found that Maven offers only a way to specify different libraries for WAR and EAR. What are recommendations? I don`t want to split everything into smaller projects just to get this functionality. Uldis Karlovs - Karlovskis Lead SCM Engineer System Configuration Management C.T.Co Mobile: +371 29 345 210 - 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 Clean Plugin exclude target folder
Agree. Everything in the target folder should be considered temporal and wiped on a clean build. -Original Message- From: Johan Lindquist [mailto:jo...@kawoo.co.uk] Sent: Monday, April 06, 2009 3:48 AM To: Maven Users List Subject: Re: Maven Clean Plugin exclude target folder -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Not sure what you are generating the sources from, but for generated SOAP client code, we usually build this as a separate module (jar) and have our code depend on it - saves us generating code all the time. For other generated code (from the source tree for example) we have taken the approach that a clean command should remove them *all* to ensure consistency in the final artifact. If some code lived through a clean cycle, we argued that it could potentially cause unwanted side-effects. Just my two cents, Cheers, Johan Bogdan Minciu wrote: Hello, As I read from http://maven.apache.org/plugins/maven-clean-plugin/examples/delete_addit ional_files.html, The Maven Clean Plugin will delete the target directory by default. But I was wondering, is there any possibility to exclude some folders under the /target folder from the deleted directories? For example I would like to delete anything under /target besides the /target/src folder. I tried using the excludes with no success. I have some useful .java files in there. I know this isn't the best architecture, but I am using some code generators that could not be configured otherwise. Many thanks in advance, - -- you too? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ2bPMpHYnED7evioRAqH7AJ92CT5bNRLLtSsV9UBTA+v3QadJxgCeOeNE BS1twPO7tXYZIVQlQkU8xr4= =B+KC -END PGP SIGNATURE- - 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: The Definitive Guide in French
We have had a couple of volunteers requests for the French version. Ping Tim @ b...@sonatype.com for details. -Original Message- From: Emmanuel Hugonnet [mailto:ehsavoi...@gmail.com] Sent: Monday, April 06, 2009 5:27 AM To: Maven Users List Subject: Maven: The Definitive Guide in French Hi, I was wondering if there is a French translation or some work in progress, as the French community is expanding. If none is available I would like to volunteer to produce it. Emmanuel
RE: LATEST and RELEASE release version management
Having the release plugin translate these values at release time _before_ the validation build and tag is the only sane way to use them. I currently have never use them because they aren't repeatable. From: Hayes, Peter [mailto:peter.ha...@fmr.com] Sent: Monday, April 06, 2009 12:12 PM To: Maven Users List Subject: RE: LATEST and RELEASE release version management Graham Leggett wrote: Having said that, it makes no sense to have the release plugin care about LATEST, because by definition, building against LATEST isn't repeatable, and in order for there to be a release, you need the build to be repeatable. I think this does impact the release plugin as it could offer the ability to resolve the LATEST version at release time. These builds would be reproducible because the release plugin tags the poms during the release process. I think what you're saying is that the build prior to the release build is not guaranteed to have the same dependent artifacts as the release build. I care about the release build being reproducible. Pete
RE: Trouble finding correct repositories
If you go to http://repository.sonatype.org and click on advanced search, you can find that you can do a checksum search. This will calculate the hash in your browser and then attempt to find the matching hash from the index of central -Original Message- From: daniel.green [mailto:october...@gmail.com] Sent: Sunday, April 05, 2009 7:31 PM To: users@maven.apache.org Subject: Trouble finding correct repositories Currently at work we're using maven2 for a project. Unfortunately, they're hosting /all/ of the dependencies in our source repository. I would like to help change that. I've started by going through and removing all the scopesystemPath stuff so maven looks in the repositories for a remote copy. I've gone through and eliminated /some/ of the unresolved dependencies, but am having trouble with the remaining. The thing that's bothering me is some of the results look like they should be included in the repositories I'm pulling from. You people would now best. from the specified remote repositories: Maven Plugin Repository (http://struts2plugin-maven-repo.googlecode.com/svn/trunk/), jboss (http://repository.jboss.com/maven2), central (http://repo1.maven.org/maven2) ... 1) com.sun:tools:jar:1.5.0_15 2) org.aspectj.tools:aspectjrt:jar:1.5.4 3) org.apache.activemq:activeio-core:jar:3.1-SNAPSHOT 4) org.apache.activemq:activeio-core:test-jar:tests:3.1-SNAPSHOT 5) javax.servlet:servlet-api:jar:2.0 6) common-binaries:junit:jar:1 7) common-binaries:junitee:jar:1 8) common-binaries:hibernate-annotations:jar:1 9) common-binaries:hibernate3:jar:1 10) common-binaries:ejb3-persistence:jar:1 11) common-binaries:hibernate-entitymanager:jar:1 12) common-binaries:javassist:jar:1 13) common-binaries:hibernate-search:jar:1 14) common-binaries:lucene-core:jar:1 15) common-binaries:hibernate-validator:jar:1 16) common-binaries:ws-commons-util:jar:1 17) common-binaries:xmlrpc-client:jar:1 18) common-binaries:xmlrpc-common:jar:1 19) common-binaries:velocity:jar:1.5 20) common-binaries:freemarker:jar:1 21) common-binaries:struts2-dojo-plugin:jar:2.1.2 22) common-binaries:struts2-portlet-plugin:jar:2.1.2 23) common-binaries:struts2-spring-plugin:jar:1 24) common-binaries:struts2-tabletags:jar:2.1.2 25) common-binaries:aspectjrt:jar:1 26) common-binaries:aspectweaver:jar:1 27) common-binaries:sojo:jar:1 28) common-binaries:org-json:jar:1 29) common-binaries:jsontools-core:jar:1 30) common-binaries:ifxjdbc:jar:1 31) common-binaries:commons-lang:jar:1 32) common-binaries:commons-fileupload:jar:1 33) common-binaries:commons-configuration:jar:1 34) common-binaries:commons-collections:jar:1 35) common-binaries:commons-beanutils:jar:1 36) common-binaries:commons-dbcp:jar:1 37) common-binaries:commons-pool:jar:1 38) common-binaries:log4j:jar:1 39) common-binaries:activemq-core:jar:1 40) org.apache.commons:logging:jar:1.1.0 41) org.apache.commons:codec:jar:1.3 42) org.jboss:jboss-cache-jdk50:jar:1.4.1 43) org.jboss:jboss-jmx:jar:4.2.2 44) org.jboss:jboss-mail:jar:1.4 45) org.jboss:jboss-jmx-adaptor-plugin:jar:4.2.2 46) org.jboss:jboss-system:jar:4.2.2 47) org.jboss:commons-httpclient:jar:3.0.1 48) org.jboss:antlr:jar:4.2.2 49) common-binaries:doxia-converter:jar:1.1 50) common-binaries:doxia-core:jar:1.1 51) common-binaries:doxia-logging-api:jar:1.1 52) common-binaries:doxia-module-apt:jar:1.1 53) common-binaries:doxia-module-xhtml:jar:1.1 54) common-binaries:doxia-sink-api:jar:1.1 55) common-binaries:plexus-classworlds:jar:1.5.7 56) common-binaries:plexus-container-default:jar:1.5.7 57) common-binaries:plexus-utils:jar:1.5.7 Any pointers in the right direction would be fantastic. Some of the versions of the dependencies are kinda old, but at this stage of the game there's nothing I can do about it. Any help will be appreciated! I am primarily worried about the ones that seem like they should be in the repositories listed. For example the jboss stuff. With foremost thanks, Daniel. -- View this message in context: http://www.nabble.com/Trouble-finding-correct-repositories-tp22900078p22 900078.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: Maven Archetype Plugin is Hosed --- and nobody cares
Howard, You have an interesting way of motivation and over generalization: Once again, Maven is screwed up beyond belief and the developer community response is pitifully absent http://twitter.com/hlship; First of all, one plugin does not represent the entire Maven project. Second, the assumption that we are all here to jump at your beck and call is offensive. Perhaps your approach is what earns you pitifully absent response. Third, it's open source and patches are welcome. -Original Message- From: Howard Lewis Ship [mailto:hls...@gmail.com] Sent: Friday, April 03, 2009 8:31 PM To: Maven Users List Subject: Re: Maven Archetype Plugin is Hosed --- and nobody cares Yes, that's the bug I added and mentioned in my posting to this mailing list. On Fri, Apr 3, 2009 at 5:22 PM, Martin Gainty mgai...@hotmail.com wrote: http://jira.codehaus.org/browse/ARCHETYPE-236 Martin __ Disclaimer and confidentiality note This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Date: Fri, 3 Apr 2009 16:31:54 -0700 Subject: Maven Archetype Plugin is Hosed --- and nobody cares From: hls...@gmail.com To: users@maven.apache.org Recently, the Maven archetype plugin has broken in an incompatible way. Documented here http://jira.codehaus.org/browse/ARCHETYPE-236. New archetypes (generated from the same source as previously working ones) no longer work. The problem is wide spread: http://www.google.com/search?q=The%20META-INF%2Fmaven%2Farchetype.xml%20descriptor%20cannot%20be%20found this appears to be a backwards-incompatible change to the plugin. So far, the Maven development community has been unresponsive (i.e., 5+ days since I added the bug, no comments). Does anyone out in Maven-land have a workaround? -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009 -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - 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 2.0 project versions, dependency versions, and perpetual releasing
Also have a look at versions-maven-plugin That's what I meant earlier, not dependency-maven-plugin. I haven't personally used it yet, but I've shown it to several clients / trainees and it's worked well for them in this case. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven Archetype Plugin is Hosed --- and nobody cares
You are hearing my frustration with the entire Maven infrastructure and the fact the default response of the community is always that's not Maven's problem; your build/plugin/approach is broken. Again with the stereotyping and generalization. I haven't seen anyone say anything like that yet...and if there really is a problem with the approach, people are generally helpful in showing the preferred approach. You've identified what appears to be a regression and if you followed along recently, regressions are something we will give preference to fixing. Alas, just the oppopsite. It seems necessary to throw a temper tantrum to get any attention at all. Hey if that works for you, great. My 5 year old doesn't get too far with that approach though. The many other people who have posted on mailing lists and blogs about the same problem have been ignored. I checked the archives and didn't see any emails from you on a maven list related to this problem. In fact, according to Nabble, your last message was in Jan/2008. I know I have alerts for blogs out there and try to respond when appropriate, but certainly I don't have the omnipresence required to solve every problem raised on every obscure list and blog on the internet. So your claims of requiring a temper tantrum to get attention seem a bit unfounded imo, when it doesn't seem like it's been raised here recently, and certainly not from you. Third, it's open source and patches are welcome. Patching Maven is a bit difficult, since often, it is not possible to: a) Determine which plugin is the problem If you're running the archetype plugin, that seems obvious. b) Match a class name in a stack trace to a plugin c) Locate the plugin's home page d) Locate the source for the plugin The pattern on apache is pretty obvious as well, but hey we control everyone else's plugins and source out there so I guess that's our fault too. f) Understand the code, since the Maven standard is to NOT comment code (and, on top of that, much code is generated mechanically from XML) Again unproductive generalizations. I don't think this is true of my own code and certainly wouldn't bash anyone else's code that they donated to the project. If I don't like it, I'm free to not use it or patch it as needed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Central index redirect
I find it amazing that there were 224 million downloads of a single file in Central last month! That sounds more like the total usage of Central, astounding. (Curious is you have those numbers available too...) You're right, I had the wrong number in my head. 224m was the central hit, 4m is the index hit. Are there misconfigured tools out there in the world that are causing this file to be downloaded every single time a build executes, or something along those lines?? Lots of users of the index
RE: Is IBIBLIO down?
But is Central really down? Working for me. Central is not. Ibiblio was last I checked (last night). Central != Ibiblio and hasn't been for several years now. Ibiblio is just one of the mirrors. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Help with patching a release?
Easiest thing is to roll the poms to a snapshot and then do a traditional release. This assumes that the project you are patching is your own and the scm info is correct. -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Friday, April 03, 2009 12:32 PM To: Maven Users Subject: Help with patching a release? Hi gang, I need to apply a small patch to a project that has already been released. In general, I understand that I need to branch the tag under which the code was released, make the change, then create a new release. I'm running into a problem, I guess with the release plugin, though. (I'm sure it's *my* problem, not the plugin's.) When I try to run a release:prepare, I get an error indicating that I don't have a SNAPSHOT project. OK, that makes sense, because I branched from a release tag. So, my question is, what would be the proper procedure for this exercise? I mean, from the point of view of Maven and maven-release-plugin, how should I go about the steps of applying a change to a released version? This is the first time I've had to do this. So, it's a learning opportunity. Thanks, Dave - 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: Help with patching a release?
Yep, it's similar to what is described here: http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with -3rd-party-snapshot-dependencies/ -Original Message- From: Todd Thiessen [mailto:thies...@nortel.com] Sent: Friday, April 03, 2009 1:31 PM To: Maven Users List Subject: RE: Help with patching a release? If you don't own the project, it is a bit more involved. In that case you would have to export the project and then import it to your svn repo and then update the scm and distribution management sections accordingly. Also remember to change the version of the project to distinguish it from the next proper release of the actual project. So, for example, if the current version is: 2.1-SNAPSHOT Give it a version like: 2.1-dave-1-SNAPSHOT sSo that you don't collide with the next official release. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Friday, April 03, 2009 1:16 PM To: Maven Users List Subject: RE: Help with patching a release? Easiest thing is to roll the poms to a snapshot and then do a traditional release. This assumes that the project you are patching is your own and the scm info is correct. -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Friday, April 03, 2009 12:32 PM To: Maven Users Subject: Help with patching a release? Hi gang, I need to apply a small patch to a project that has already been released. In general, I understand that I need to branch the tag under which the code was released, make the change, then create a new release. I'm running into a problem, I guess with the release plugin, though. (I'm sure it's *my* problem, not the plugin's.) When I try to run a release:prepare, I get an error indicating that I don't have a SNAPSHOT project. OK, that makes sense, because I branched from a release tag. So, my question is, what would be the proper procedure for this exercise? I mean, from the point of view of Maven and maven-release-plugin, how should I go about the steps of applying a change to a released version? This is the first time I've had to do this. So, it's a learning opportunity. Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven 2.0 project versions, dependency versions, and perpetual releasing
Use snapshots during your dev cycle and publish your non-developer-desktop builds as official releases. There is the dependency-maven-plugin that can ease the updates of cross dependencies, but if you structure your build tree effectively, this will be minimal. You're on the right track, but don't throw out the notion of snapshots just to avoid ever changing the poms. -Original Message- From: Zac Thompson [mailto:zac.thomp...@gmail.com] Sent: Friday, April 03, 2009 4:16 PM To: users@maven.apache.org Subject: Maven 2.0 project versions, dependency versions, and perpetual releasing I also posted this question on stackoverflow, but I wanted to go to the source, as it were. How should we manage the project and dependency versions in our POM hierarchy? I apologize for the length of the message. The first paragraph is probably all that's needed, but I'm not good at self-editing and I wanted to give as much context as possible. Scenario: The system has number of components, each with its own POM. There are some long dependency chains (A depends on B depends on C, etc.). I want each non-developer-desktop build to be a potential release candidate -- if it passes QA, we will deploy it without rebuilding. In other words, I never want to build SNAPSHOT versions as part of my regularly scheduled builds, only versions like 1.3.0.5, 1.3.0.6, etc. I also want to enable the developers to work on multiple components at once. To forestall some expected suggestions: the Maven Release Plugin doesn't help me ... unless there's some magic way I can have my dependency versions not be SNAPSHOTs in the POMs but still let the developers work on more than one component at once? How should we manage the project and dependency versions in all of our POMs? Right now it's just SNAPSHOTs everywhere, which makes things simple for the developers (they started with SNAPSHOTs and never concerned themselves with anything else). But it's worrying at deployment time (builds with SNAPSHOT dependencies are not well-defined, and not reproducible). I'd like to avoid excessive version juggling at build time, but right now I don't see any way around it. Let's say I have components util, libj, libk, APP, and UI, with dependencies as follows: libj - util (libj depends on util) libk - util APP - libj UI - libj, libk I have development teams working on APP and UI, and they will sometimes need to make changes/additions to some of the dependencies (even util) in order to enable their current work. How should the checked-in POM and dependency versions for each component look? I'm prepared to hear that I may be taking the wrong approach to this problem. All suggestions welcome. - 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 2.0 project versions, dependency versions, and perpetual releasing
Forget about LATEST and RELEASE, these are not reproducible down the road. The way I like to manage my dependencies is that they stay using the release version until a change to it that I need occurs. Then that dependency is changed to use the new snapshot. Hopefully you are using properties or dependencyManagement to reduce the number of places this needs to be changed to 1 per product group of modules. Then when it's time to release you know all the other things you must release because they are set as snapshots. -Original Message- From: Zac Thompson [mailto:zac.thomp...@gmail.com] Sent: Friday, April 03, 2009 8:43 PM To: Maven Users List Subject: Re: Maven 2.0 project versions, dependency versions, and perpetual releasing I am willing to continue using snapshots during the dev cycle. I don't seek to eliminate them completely, but they are getting in my way. It's not SNAPSHOT versions of the projects themselves that is the obstacle, but SNAPSHOT dependencies. My challenge is that the dev cycle for a slice of the system could be extremely short (say, two hours), at which time I might need to update the versions and the dependencies for a few poms as I build them in sequence, and then update the dependency versions in many other POMs (perhaps 20, even though they may not be modified yet) in order to facilitate future development. As an example, let's say a developer changes a component, but also updates a shared utility library as part of the work. There's no problem with the checked-in component and library poms being SNAPSHOTs, but I have only four options for the dependency version: 1) component depends on SNAPSHOT dependency. Easy for the developer to work with and test, impossible for me to manage. This is where we are now. 2) component depends on specific release version of library: Feels the most authentic and proper, but then Dev has to wait for a release build of the library and an update to the component POM for the new dependency version in order to use it for the component work. Also, I have to update all the other POMs that depend on the library. 3) component depends on virtual RELEASE version of library (or version range if supported and more appropriate). This is a lot like #1, but I won't have to update the component POMs when I build a new library. But it worsens build reproducibility, and the Dev still has to wait for an official library build in order to try out their changes to the component. This is a troublesome bottleneck for both #2 and #3 -- our split is just not that perfect that we can modify each piece in isolation. They need a way to use the new library they just built on their desktop while developing the component. They could update the component pom to depend on the snapshot of the library (temporarily back to #1), but then we risk them checking in that snapshot dependency, which will mess up any other devs on the same component. I'd like them to be able to avoid updating POMs unless there's a meaningful change to our dependency tree. 4) component depends on LATEST library. This allows the developer to work with the latest release until they start development, and then they'll find their self-built SNAPSHOTs. I also don't have to update lots of poms with every library build. This is close to #1, but at least I can be fairly sure that there will be no SNAPSHOT versions found by my scheduled builds. I can dimly see risks surrounding timing issues if they build a SNAPSHOT from an old checkout after my release build, but I can't fix everything. Any thoughts? #4 looks the best to me at the moment, but I haven't tried it yet. Still trying to wrap my head around it. Zac On Fri, Apr 3, 2009 at 3:49 PM, Brian E. Fox bri...@reply.infinity.nu wrote: Use snapshots during your dev cycle and publish your non-developer-desktop builds as official releases. There is the dependency-maven-plugin that can ease the updates of cross dependencies, but if you structure your build tree effectively, this will be minimal. You're on the right track, but don't throw out the notion of snapshots just to avoid ever changing the poms. -Original Message- From: Zac Thompson [mailto:zac.thomp...@gmail.com] Sent: Friday, April 03, 2009 4:16 PM To: users@maven.apache.org Subject: Maven 2.0 project versions, dependency versions, and perpetual releasing I also posted this question on stackoverflow, but I wanted to go to the source, as it were. How should we manage the project and dependency versions in our POM hierarchy? I apologize for the length of the message. The first paragraph is probably all that's needed, but I'm not good at self-editing and I wanted to give as much context as possible. Scenario: The system has number of components, each with its own POM. There are some long dependency chains (A depends on B depends on C, etc.). I want each non-developer-desktop build to be a potential release candidate -- if it passes QA, we
RE: [ANN] Maven 2.1.0 Released
The @phase will automatically cause a plugin to run at that phase, but the plugin must still be mentioned in the pom. -Original Message- From: Pankaj Tandon [mailto:pankajtan...@gmail.com] Sent: Thursday, April 02, 2009 10:40 AM To: users@maven.apache.org Subject: Re: [ANN] Maven 2.1.0 Released Hello Rob, I wanted to ask you about your comment below where you state that even if you have an annotation in a mojo for the execution phase, you still have to declare an executions element for the very same phase in the project that invkes this plugin. That, kind of defeats the purpose of having a default phase specified in the Mojo, does it not? And it certainly doesn't work that way for other plugins (the war plugin for instance that is bound to the package phase). So am I missing something here or is this a bug introduced with 2.0.10? Thanks Pankaj Okay, my mistake - although it was indeed the 2.1.0 mvn which was in my path, I had forgotten to change the value of my M2_HOME environment variable. Therefore, it was actually 2.0.10 which was being executed, which was why my goal was being ignored. And anyway, I had wrongly assumed that adding the '@phase prepare-package' annotation to the mojo was enough to trigger the goal's execution - you still have to add a pluginexecutions...goal to the pom, and I can confirm that this works fine. Many thanks to Brett for asistance. Rob 2009/3/25 Rob Dickens arctic@googlemail.com As in a pluginspluginexecutionsexecution block in the pom.xml of the jar-packaged project? There isn't one, since the plugin's mojo has a '@phase prepare-package'. 2009/3/25 Brett Porter br...@apache.org On 25/03/2009, at 10:07 PM, Rob Dickens wrote: Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. All packaging types will if you properly bind to the phase, but there is no default binding in any of the mojos yet. How have you constructed your execution block? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575576.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: Why are projects deploying to repo1.maven.org not allowed to use plugins from other repositories?
This isn't a hard and fast rule, but we generally like to see that the entire enclosure is available on Central. You would need to introduce not just the pluginRepo, but probably a regular repo and that's where problems start. That repo then pollutes the downstream resolution for other artifact lookups and this is what causes people problems. -Original Message- From: Peter Niederwieser [mailto:pnied...@gmail.com] Sent: Thursday, April 02, 2009 8:55 AM To: users@maven.apache.org Subject: Why are projects deploying to repo1.maven.org not allowed to use plugins from other repositories? Say I need a plugin for my release process that's not available from repo1.maven.org. How would the inclusion of a plugin repository affect the users of my artifact? Or why else is it not allowed to add a plugin repository? Cheers, Peter -- View this message in context: http://www.nabble.com/Why-are-projects-deploying-to-repo1.maven.org-not- allowed-to-use-plugins-from-other-repositories--tp22847197p22847197.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: [ANN] Maven 2.1.0 Released
The war plugin is introduced by the lifecycle. The mappings are dependent on the packaging type. More info is available here: http://www.sonatype.com/books/maven-book/reference/simple-project-sect-l ifecycle.html -Original Message- From: Pankaj Tandon [mailto:pankajtan...@gmail.com] Sent: Thursday, April 02, 2009 11:17 AM To: users@maven.apache.org Subject: Re: [ANN] Maven 2.1.0 Released Rob and Brian, Thanks for the response. However, how then does the maven-war-plugin run. I do NOT specify an execution section for that plugin, and it runs in the package phase. So I am not sure why is it necessary to mention the execution element at all (with or without a phase). Just the plugin with a generic configuration node should do. Still confused, Pankaj you still have to declare an executions element for the very same phase in the project that invkes this plugin. That's right, except you don't have to specify the phase - the one declared by the mojo will be assumed. 2009/4/2 Pankaj Tandon pankajtan...@gmail.com Hello Rob, I wanted to ask you about your comment below where you state that even if you have an annotation in a mojo for the execution phase, you still have to declare an executions element for the very same phase in the project that invkes this plugin. That, kind of defeats the purpose of having a default phase specified in the Mojo, does it not? And it certainly doesn't work that way for other plugins (the war plugin for instance that is bound to the package phase). So am I missing something here or is this a bug introduced with 2.0.10? Thanks Pankaj Okay, my mistake - although it was indeed the 2.1.0 mvn which was in my path, I had forgotten to change the value of my M2_HOME environment variable. Therefore, it was actually 2.0.10 which was being executed, which was why my goal was being ignored. And anyway, I had wrongly assumed that adding the '@phase prepare-package' annotation to the mojo was enough to trigger the goal's execution - you still have to add a pluginexecutions...goal to the pom, and I can confirm that this works fine. Many thanks to Brett for asistance. Rob 2009/3/25 Rob Dickens arctic@googlemail.com As in a pluginspluginexecutionsexecution block in the pom.xml of the jar-packaged project? There isn't one, since the plugin's mojo has a '@phase prepare-package'. 2009/3/25 Brett Porter br...@apache.org On 25/03/2009, at 10:07 PM, Rob Dickens wrote: Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. All packaging types will if you properly bind to the phase, but there is no default binding in any of the mojos yet. How have you constructed your execution block? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575576.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 -- Rob, Lafros.com -- View this message in context: http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575805.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: How to use maven-dependency-plugin to unpack-dependencies for 2 artifacts?
You should use the includeArtifactId to filter exactly the ones you want for
each folder. It looks like it¹s picking up both of your files in both
executions so you just need to be more specific which artifacts to unpack.
On 4/1/09 11:42 PM, David Hoffer dhoff...@gmail.com wrote:
I'm having problems figuring out how to configure the
maven-dependency-plugin to unpack 2 separate dependencies. I have 3
executions, the first uses the copy-dependencies goal to copy a swf
artifact, this seems to work.
Then I have two executions each using unpack-dependencies goal; the
first unpacks some flex config files and the second unpacks a spring
configuration file. Here is my pom:
executions
execution
idcopy-swf/id
phaseprocess-classes/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/output
Directory
includeArtifacIdscdf-as-client-testapp/includeArtifacIds
includeTypesswf/includeTypes
overWritetrue/overWrite
/configuration
/execution
execution
idunpack-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/WEB-INF
/flex
/outputDirectory
includeArtifacIdscdf-blaze-svcs-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
execution
idunpack-spring-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/WEB-INF
/spring
/outputDirectory
includeArtifacIdscdf-spring-directbroker-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
/executions
The problem is that the output folders /WEB-INF/flex /WEB-INF/spring
BOTH contain the same contents, i.e. they BOTH contain what is
supposed to be only in flex and only in spring. Furthermore BOTH
contain some content not from either artifact!?! This unexpected
content seems to be some flex content which I have no idea why it is
adding.
How can I use maven-dependency-plugin to just unpack one artifact and
put it in a separate folder?
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven2 ignoring environment variables
In general, try to avoid using env vars as it makes your build more fragile
as you¹ve noticed. Somehow it seems these env aren¹t getting through to
maven, but there¹s not enough info below to tell you why.
On 4/2/09 6:46 AM, amys amy.t.sav...@gmail.com wrote:
I use an environment variable like ${env.FLORENCE_HOME} in my pom.xml files.
Sometimes this resolves correctly, sometimes it doesn't, and then Maven
generates files into a directory literally called ${env.FLORENCE_HOME} in
my build environment.
Specifically, I define a variable ${florence.server} based on
${env.FLORENCE_HOME} in one pom.xml, then reference ${florence.server} in
another pom.xml.
This generally works, and I cannot tell what triggers the problem, Moreover,
even where the bug occurs, the base pom is being correctly referenced, as
the variable ${florence.server} does resolve, even when the env variable it
references does not.
Using
- Maven 2.1
- Eclipse Maven Plugin 0.9.7 of 20081130
--
View this message in context:
http://www.nabble.com/Maven2-ignoring-environment-variables-tp22845174p2284517
4.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
RE: How to use maven-dependency-plugin to unpack-dependencies for 2 artifacts?
It's things like this that give maven a bad rep. Folks spend hours
trying to get it to work and never do. Fixing it is in order, but why
on earth can't the keepers of the plugin document this in an obvious
place?
Because that assumption below isn't true. The unpack and copy goals allow you
very fine grained control over which artifacts go where since you can name them
one at a time. The xxx-dependencies goals are intended for operation en-mass of
your dependencies and you filter them down using many different filters. It is
possible to specify a single artifactId in the filter. This case though would
require multiple executions since it wasn't designed like the copy/unpack to
run in a single execution and cherry pick artifacts.
On Thu, Apr 2, 2009 at 11:41 AM, Bryan Loofbourrow
bryan.loofbour...@amdocs.com wrote:
I've run into this too. I inferred that the dependency plugin's
unpack-dependencies goal was simply not written in a way that allows it
to be executed twice in the same project. I can see how that could
happen, if one were not pretty careful in the execute() method about
making the scratchpad controlling the scratchpad. I resorted to
splitting up Maven projects so that there's no more than one
unpack-dependencies per pom. But I too would love a better solution.
Actually, the situation could be a bit worse than I portray it above, if
Maven itself does not handle multiple executions by making separate
calls to execute, with a different set of instantiated parameters each
time. But I hope it does.
-- Bryan
-Original Message-
From: David Hoffer [mailto:dhoff...@gmail.com]
Sent: Wednesday, April 01, 2009 8:42 PM
To: users@maven.apache.org
Subject: How to use maven-dependency-plugin to unpack-dependencies for 2
artifacts?
I'm having problems figuring out how to configure the
maven-dependency-plugin to unpack 2 separate dependencies. I have 3
executions, the first uses the copy-dependencies goal to copy a swf
artifact, this seems to work.
Then I have two executions each using unpack-dependencies goal; the
first unpacks some flex config files and the second unpacks a spring
configuration file. Here is my pom:
executions
execution
idcopy-swf/id
phaseprocess-classes/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/
outputDirectory
includeArtifacIdscdf-as-client-testapp/includeArtifacIds
includeTypesswf/includeTypes
overWritetrue/overWrite
/configuration
/execution
execution
idunpack-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/W
EB-INF/flex
/outputDirectory
includeArtifacIdscdf-blaze-svcs-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
execution
idunpack-spring-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/W
EB-INF/spring
/outputDirectory
includeArtifacIdscdf-spring-directbroker-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
/executions
The problem is that the output folders /WEB-INF/flex /WEB-INF/spring
BOTH contain the same contents, i.e. they BOTH contain what is
supposed to be only in flex and only in spring. Furthermore BOTH
contain some content not from either artifact!?! This unexpected
content seems to be some flex content which I have no idea why it is
adding.
How can I use maven-dependency-plugin to just unpack one artifact and
put it in a separate folder?
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For
RE: Central index redirect
We moved the index to S3 back in November to reduce the load on Central and improve access time for other artifacts. (224m downloads and 24TB last month alone for the index) The index is not accessible from repo1.maven.org anymore and it redirects to S3. (the s3 url is pseudo dynamic so to get the files you must still hit central for the redirected url). If you can't use s3, then you'll have to change to ibiblio or another mirror that is hosting the index files directly. If you use Nexus, then the mirror support[1] will allow you to use ibiblio and repo1 transparently at the same time and the index would come from ibiblio. [1] http://www.sonatype.com/people/2009/03/new-feature-in-nexus-13-mirror-su pport/ -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, April 02, 2009 4:30 PM To: Maven Users List Subject: Re: Central index redirect setup nexus and pull off a mirror of repo1 2009/4/2 Hayes, Peter peter.ha...@fmr.com The company that I work for has blocked all access to the Amazon S3 hosting site due to security / threat concerns. Due to this, I am no longer able to download the central index. Has anyone else had this issue and if so were they able to work around it? Peter Hayes Architecture Shared Technology Services | Fidelity Investments Management Technology - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Is IBIBLIO down?
Yes it seems to be down. Using a repository manager would isolate you from these issues. -Original Message- From: logachandru.x.rajamanic...@jpmchase.com [mailto:logachandru.x.rajamanic...@jpmchase.com] Sent: Thursday, April 02, 2009 8:01 PM To: Maven Users List Subject: Is IBIBLIO down? Importance: High Hi, I get the following error when I try a maven build. Please let me know whether this issue could be 'coz of the IBIBLIO site being down. I could not hit the IBIBLIO site as well. Can anybody advise. Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/plugins/m aven-plugins/12/maven-plugins-12.pom.sha1 Thanks Regards, Logu Rajamanickam This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Sharing Maven-based project
We have some tools to help convert a local repo into a remote repo format: https://docs.sonatype.com/display/NX/Nexus+Command+Line+Tools -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Tuesday, March 31, 2009 10:57 AM To: users@maven.apache.org Subject: Re: Sharing Maven-based project Please correct me if I'm wrong: 1. I have to install Nexus (my choice) on the dev machine (shared server). 2. I will use Nexus to copy my local MVN repository to the dev machine. Thanks for help , I'm so newbie with Maven. Cedros GmbH wrote: Yes, create a repository for your unit/company. You don't want to let your colleagues download artifacs manually from eg. SVN. We use Artifactoy as a repository and central mirror for every maven installation in the company. Its running on Tomcat, easy to install and integrated with the company LDAP. Regards Am 29.03.2009 um 16:08 schrieb HHB: Hey, I use Maven as the build tool for our project. Now my team mates want to checkout the project from the SVN and I want to add the project to out continuous integration server (Hudson). I'm not sure but should I create a central repository in our unit? or let each mate (and CI server) download the dependency himself? What repository manager do you suggest? Thanks. -- View this message in context: http://www.nabble.com/Sharing-Maven-based-project-tp22767986p22767986.ht ml 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 -- View this message in context: http://www.nabble.com/Sharing-Maven-based-project-tp22767986p22804979.ht ml 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: Update maven-metadata.xml
Maven does yes, but if things get messed up via manual intervention or bugs in the deploy-file goal, then there's no way to systematically clean the metadata. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, April 01, 2009 9:51 AM To: 'Maven Users List' Subject: RE: Update maven-metadata.xml Not really. I have deploy-file automated, so not sure how a UI would help me with that. Am I way off base here? Is Maven not designed to manage these repositories? I know the repository managers provide slick UI's to make a bunch of repositories look like one on site, and I have a repository (not managed by a repository manager) here to prevent users going off over the internet (ie hitting repo1 infrequently). But shouldn't Maven just handle these things? -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Tuesday, March 31, 2009 10:35 PM To: Maven Users List Subject: RE: Update maven-metadata.xml Using a repo manager would solve both problems. You could upload via a ui instead of deploy-file and the metadata would be correctly generated. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Tuesday, March 31, 2009 9:17 PM To: 'users@maven.apache.org' Subject: Update maven-metadata.xml Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: http://maven.apache.org/plugins/maven-deploy-plugin/index.html I did some googling around and found some comments regarding this but nothing definitive. FWIW, I am using Maven 2.1.0 for all of this, on Windows. Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [ANN] Maven Release Plugin 2.0-beta-9 Released
I agree completely, but until/unless the svn team fixes this major defect,
there's not much we can do. (besides switch everyone to git ;-) )
-Original Message-
From: Todd Thiessen [mailto:thies...@nortel.com]
Sent: Wednesday, April 01, 2009 10:18 AM
To: Maven Users List
Subject: RE: [ANN] Maven Release Plugin 2.0-beta-9 Released
I was pleased when I heard that there was a fix for the tags not working with
svn in 1.5.1 bug [1]. I didn't look into the solution in great detail at first
and I apologize for that. It is little difficult to look at everything all the
time as I am sure you all are familiar with. I did take a little time this
morning to understand the solution however. I never did understand what
remoteTagging meant for an option in the release plugin (which needs to be
documented, btw, on the release plugin site).
So if I understand remote tagging correctly, this means that a tag is taken off
the trunk, not the working copy.
Doesn't this break backwards compatibility? For instance if there are users out
there who do rely on making a tag of the working copy to ensure that you don't
tag something committed during a build, once they upgrade to release 9 of the
release plugin, this won't work for them anymore.
I view the remoteTaggins option as a work around. It is fundamentally a bug in
svn (it did work in pre 1.5.1, and doing an svn copy of a working copy is
documented to work [2]). If svn ever fixes it, then the remoteTagging option
wouldn't be needed anymore and should be defaulted to false.
I understand the comments in [3] which indicate that the likelihood of a commit
occurring during a build isn't the common case, but how can you tell? This
could happen more than we might think and there are tags of releases out there
which do not match the built artifacts. There is no way to know without doing a
detailed analysis of the artifacts and the tagged source. I feel it is pretty
safe to say that such an analysis hasn't been done ;-). Even if someone did
happen to stumble upon such a case where they were stepping through the source
in there debugger and noticed that lines didn't match up. It may be dismissed
if the lines were close enough to follow or simply upgrading to a more recent
version of the artifact all of a sudden fixes it.
Ultimately I feel we still need an svn solution to this. Remote tagging is only
a work around.
My 2 cents anyway.
[1] http://jira.codehaus.org/browse/SCM-406
[2] http://svnbook.red-bean.com/en/1.0/re07.html
[3] http://jira.codehaus.org/browse/SCM-262
---
Todd Thiessen
-Original Message-
From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On
Behalf Of Olivier Lamy
Sent: Wednesday, April 01, 2009 6:54 AM
To: Maven Users List
Subject: Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
2009/4/1 Jorg Heymans jorg.heym...@gmail.com:
(taking this back to the users list)
On Wed, Apr 1, 2009 at 10:01 AM, Olivier Lamy
ol...@apache.org wrote:
2009/4/1 Jorg Heymans jorg.heym...@gmail.com:
On Wed, Apr 1, 2009 at 9:33 AM, Olivier Lamy
ol...@apache.org wrote:
Try mvn help:effective-pom I'm not sure the scm
information is correct.
I don't know what to make from the scm info, in any case
it points
to a non-existing tag:
scm
connectionscm:svn:http://server/svn/project/tags/myparent-4/myproj
ect/connection
developerConnectionscm:svn:http://server/svn/project/tags/myparent
-4/myproject/developerConnection
/scm
The myproject at the end seems bad. In any case somehow
beta-8 was
able to cope with this, wierd.
:-) (in this case IMHO your project is bad : publishing site will
publish bad source info etc.. changelog plugin can not work etc..)
The released parent pom contains this scm element :
scm
connectionscm:svn:http://server/svn/project/tags/myparent-4/connect
ion
developerConnectionscm:svn:http://server/svn/project/tags/myparent-4
/developerConnection
/scm
Do you mean this is wrong ?
No the release parent has correct information but not your child(s)
pom(s) because if the child doesn't have any scm information
they are inherited from the parent ! + your current project's
artifactId
in your case effective pom will be :
scm
connectionscm:svn:http://server/svn/project/tags/myparent-4/
${artifactId}/connection
developerConnectionscm:svn:http://server/svn/project/tags/my
parent-4/${artifactId}/developerConnection
/scm
And IMHO this is not correct for your current project !
SIte informations won't be correct.
Your child poms must contains their own scm informations
(something like) :
scm
connectionscm:svn:http://server/svn/project/myparent/trunk/$
{artifactId}/connection
developerConnectionscm:svn:http://server/svn/project/myparen
t/trunk/${artifactId}/developerConnection
/scm
Sure it's a side effect of using remote tagging to have a
workaround on the svn 1.5.0
RE: java.lang.OutOfMemoryError: PermGen space problem
Use the MAVEN_OPTS env to bump up the memory. The contents of this variable are passed directly to your jdk. I forget the exact syntax for increasing the permgen, but I'm sure google knows. -Original Message- From: SRINIVASA RAO [mailto:srinivasv_amb...@yahoo.com] Sent: Wednesday, April 01, 2009 10:51 AM To: users@maven.apache.org Subject: java.lang.OutOfMemoryError: PermGen space problem Hi all, When i run the mvn clean install -e command , it is getting the following error: java.lang.OutOfMemoryError: PermGen space maven Could anybody please guide to solve this problem . Regards, Sam - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist
That plugin doesn't exist on apache, so the error is correct. -Original Message- From: Azazel Se [mailto:azazel...@hotmail.com] Sent: Monday, March 30, 2009 10:37 PM To: users@maven.apache.org Subject: The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist Hi. I cannot get the service archiver plugin to work (AAR). mvn aar:aar gives this result: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'aar'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist or no valid version could be found and with mvn -U aar:aar it says it is checking for updates from central but fails also. I've tried mvn org.aparche.axis2-aar-maven-plugin:aar as well but with same result. When I tried changing the version number in the pom.xml file and tried the command again it seemed to start downloading but failed again. Any suggestions as to what is wrong? -Az. _ Dobbelt så moro - del bilder med andre mens du chatter på Windows Live Messenger. http://www.microsoft.com/windows/windowslive/products/messenger.aspx - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Duplicate Module/Project Names in m2eclipse
When you import, you can select a naming template and one of them includes the group. This is also handy if you happen to have multiple branches imported at the same time, since one of the other options includes the version. -Original Message- From: Andrew Hughes [mailto:ahhug...@gmail.com] Sent: Tuesday, March 31, 2009 12:26 AM To: Maven Users List Subject: Duplicate Module/Project Names in m2eclipse Hi, Eclipse can't seem to handle two modules in the same workspace that have the same artifactId. For example if I have a multi-module project (groupId:artifact) as below: - carworld:carworld - carworld:ferrari - carworld.ferrari:car - carworld:porsche - carworld.porsche:car There are two modules that have artifactIdcar/artifactId (but different groupId's). m2Eclipse+Eclipse appears to use the artifactId as the project identifier and when the two car projects are imported only one is actually imported. Is this a known issue? are there any workarounds? Cheers. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Sharing Maven-based project
Yes, although if all your project dependencies are in the Maven central repository, there may be some value in waiting on Nexus (or one of the other repo managers, although I like Nexus) 'til you're ready. If you've already got several dependencies in your local repo that can't be found on central, then it's probably simpler to set up Nexus than it is to move dependencies around between developers, yes. Don't forget about the improved build performance that will come with the proxies you get with a repo manager. I wouldn't say that you don't need one until you actually need to share artifacts (which would happen as soon as you actually start building and releasing anyway). I would say that as soon as you have more than one developer in a given location, you should consider a repo manager if only to proxy builds and protect yourself from transient network outages. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Update maven-metadata.xml
Using a repo manager would solve both problems. You could upload via a ui instead of deploy-file and the metadata would be correctly generated. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Tuesday, March 31, 2009 9:17 PM To: 'users@maven.apache.org' Subject: Update maven-metadata.xml Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: http://maven.apache.org/plugins/maven-deploy-plugin/index.html I did some googling around and found some comments regarding this but nothing definitive. FWIW, I am using Maven 2.1.0 for all of this, on Windows. Thanks! -Jim - 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: dependency:unpack-dependencies not updating releases
It's because the same modello model is used for both, but that value is ignored. Trust me, if you try to start changing releases, you will have endless problems. -Original Message- From: Richard Chamberlain [mailto:richard.chamberl...@caplin.com] Sent: Monday, March 30, 2009 4:39 AM To: Maven Users List Subject: RE: dependency:unpack-dependencies not updating releases Hi Brian, I'm confused. What is the meaning of an updatePolicy for releases? repositories repository releases updatePolicyalways/updatePolicy /releases snapshots updatePolicyalways/updatePolicy /snapshots idcaplin/id urlfile:/maven/maven-repo/url /repository Richard -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: 27 March 2009 18:44 To: Maven Users List Subject: RE: dependency:unpack-dependencies not updating releases By changing a release artifact you are violating Maven Commandment #1: Release artifacts are immutable. Maven will never recheck for updated release artifacts, so it will just hand back what's in the local repository to the plugin every time. -Original Message- From: Richard Chamberlain [mailto:richard.chamberl...@caplin.com] Sent: Friday, March 27, 2009 12:28 PM To: Maven Users List Subject: dependency:unpack-dependencies not updating releases Hi, I'm using dependency:unpack-dependencies to get some zips of artefacts from our company repository. However if I update a released artefact without changing the version (i.e. documentation change), our company repository is never checked by my script. The only way to get the latest version is to delete the artefact from my cache so it re-resolves it. When a dependency is a snapshot it is always updated. The command i'm using is: mvn dependency:unpack-dependencies -DoutputDirectory=mvn -DmarkersDirectory=mvn And the output from mvn help:effective-pom shows that my updatePolicy is set to always: ... repositories repository releases updatePolicyalways/updatePolicy /releases snapshots updatePolicyalways/updatePolicy /snapshots idcaplin/id urlfile:/maven/maven-repo/url /repository repository snapshots enabledfalse/enabled /snapshots idcentral/id nameMaven Repository Switchboard/name urlhttp://repo1.maven.org/maven2/url /repository /repositories ... My project pom file is: ?xml version=1.0? project modelVersion4.0.0/modelVersion groupIdcaplin/groupId artifactIdtestproject/artifactId version1.4.1/version dependencies dependency groupIdtest.richardc/groupId artifactIdtest/artifactId version1.0/version typezip/type /dependency /dependencies /project And the debug output is: D:\Development\Sandbox\testmvn -X dependency:unpack-dependencies -DoutputDirect ory=mvn -DmarkersDirectory=mvn + Error stacktraces are turned on. Maven version: 2.0.10-RC7 Java version: 1.5.0_08 OS name: windows xp version: 5.1 arch: x86 Family: windows [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\richardc\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'D:\buildTools\apache- maven-2.0.10-RC7\bin\..\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [DEBUG] Loading plugin prefixes from group: com.octo.mtg [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:10 for project: org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: org.apache.m aven:maven-parent:pom:7 from the repository. [DEBUG] Wagons could not be registered as the extension container was never crea ted [INFO] [INFO] Building Unnamed - caplin:testproject:jar:1.4.1 [INFO]task-segment: [dependency:unpack-dependencies] [INFO] [DEBUG] caplin:testproject:jar:1.4.1 (selected for null) [DEBUG] test.richardc:test:zip:1.0:compile (selected for compile) [DEBUG] Plugin dependencies for: org.apache.maven.plugins:maven-dependency-plugin:2.0 are: org.apache.maven:maven-artifact:jar:2.0.8:runtime org.apache.maven:maven-plugin-api:jar:2.0.8:runtime
RE: Despite trusted CA, unable to find valid certification path to requested target
The CA may be trusted, but the site needs to expose the full signature trail from the server cert up to the CA. Not doing this will often cause the site to appear ok in a browser, but not to java. Most SSL signing authorities provide a bundle that you can set on the server side. -Original Message- From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Sunday, March 29, 2009 1:14 PM To: users@maven.apache.org Subject: Despite trusted CA, unable to find valid certification path to requested target Hi all, I am having trouble getting mvn site:deploy to work with mvn v2.1.0 (also v2.0.6), as follows: Embedded error: Failed to create destination WebDAV collection (directory): /docs/stencil/0.0.1-SNAPSHOT/./apidocs unable to find valid certification path to requested target The machine is a MacOSX machine, and a search turns up three different copies of the cacerts database (one for v1.4.2, one for 1.5.0 and one for 1.6.0). The CA cert for the DAV webserver is present in all three cacert databases, and to be sure I physically removed and re-added the CA cert to all three databases, with no luck. From the symptoms I am seeing, it looks like none of these three cacert databases are being used at all, and the JDK is using a mystery or missing database of its own. Can anyone confirm whether maven does any weird or special handling of cacert databases on MacOSX, or does it just revert to the JDK default on the platform? Is there a way to see what CA cert database is being used by maven when it runs? (It's obviously not using any of the cacert databases I've added the CA cert to, or it would work). Anyone ever solved a problem like this before? Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Despite trusted CA, unable to find valid certification path to requested target
Give this tool a try then and see http://repository.apache.org/ssl/ if it helps. -Original Message- From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Sunday, March 29, 2009 3:04 PM To: Maven Users List Subject: Re: Despite trusted CA, unable to find valid certification path to requested target Brian E. Fox wrote: The CA may be trusted, but the site needs to expose the full signature trail from the server cert up to the CA. Not doing this will often cause the site to appear ok in a browser, but not to java. Most SSL signing authorities provide a bundle that you can set on the server side. In this case, the cert is signed by the CA directly, the full chain is just two certs long. Trying the same config under Linux works fine, with the same certs, project and site. Regards, Graham -- -Original Message- From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Sunday, March 29, 2009 1:14 PM To: users@maven.apache.org Subject: Despite trusted CA, unable to find valid certification path to requested target Hi all, I am having trouble getting mvn site:deploy to work with mvn v2.1.0 (also v2.0.6), as follows: Embedded error: Failed to create destination WebDAV collection (directory): /docs/stencil/0.0.1-SNAPSHOT/./apidocs unable to find valid certification path to requested target The machine is a MacOSX machine, and a search turns up three different copies of the cacerts database (one for v1.4.2, one for 1.5.0 and one for 1.6.0). The CA cert for the DAV webserver is present in all three cacert databases, and to be sure I physically removed and re-added the CA cert to all three databases, with no luck. From the symptoms I am seeing, it looks like none of these three cacert databases are being used at all, and the JDK is using a mystery or missing database of its own. Can anyone confirm whether maven does any weird or special handling of cacert databases on MacOSX, or does it just revert to the JDK default on the platform? Is there a way to see what CA cert database is being used by maven when it runs? (It's obviously not using any of the cacert databases I've added the CA cert to, or it would work). Anyone ever solved a problem like this before? Regards, Graham -- - 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 to bulk load the jars in my local repo into a new (empty) corporate remote repo?
We have some tools to help with this. They will sort out snapshots from releases and cleanup the metadata that is specific to a local repo. They are designed to leave the repos in a state to put into Nexus and let Nexus rebuild all the missing metadata. If your repository manager is Nexus, you're in luck. If not, you can install Nexus locally and let it rebuild the files for you, then take the data (stored in a plain m2 repo layout) and ship it over to the repository. Ideally you would send it to an admin, but otherwise you're gonna have to find another way. Even if it's not a complete solution, it will get you a few steps closer. https://docs.sonatype.com/display/NX/Nexus+Command+Line+Tools http://nexus.sonatype.org -Original Message- From: Jeff Walker [mailto:webservices.archit...@gmail.com] Sent: Saturday, March 28, 2009 1:05 PM To: users@maven.apache.org Subject: How to bulk load the jars in my local repo into a new (empty) corporate remote repo? Hi, I'm a relative newbie to Maven2. My problem is, I have a local repository full of about 400 jars. All is well and good, my projects build and I am happy. My happiness level is now in jeopardy! Another team has created a remote repository in our domain. I have to switch to use it. I located it and updated my pom files. Great, just one problem, it's of course empty! How do I bulk load the jars in my local repo into this new remote repo, without doing the mvn:deploy:deploy-file thing for each jar (400 times). I can get no help from the person who created the remote repo. (Company politics, you understand). Thanks, -jeff - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: dependency:unpack-dependencies not updating releases
Overwriting is different than re-resolving. He wants to re-resolve a release that has changed. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Friday, March 27, 2009 2:10 PM To: Maven Users List Subject: Re: dependency:unpack-dependencies not updating releases Have a look at the plugin mojo... you'll see there's a config option to control whether snapshots are overwritten and whether releases are overwritten. 2009/3/27 Richard Chamberlain richard.chamberl...@caplin.com Hi, I'm using dependency:unpack-dependencies to get some zips of artefacts from our company repository. However if I update a released artefact without changing the version (i.e. documentation change), our company repository is never checked by my script. The only way to get the latest version is to delete the artefact from my cache so it re-resolves it. When a dependency is a snapshot it is always updated. The command i'm using is: mvn dependency:unpack-dependencies -DoutputDirectory=mvn -DmarkersDirectory=mvn And the output from mvn help:effective-pom shows that my updatePolicy is set to always: ... repositories repository releases updatePolicyalways/updatePolicy /releases snapshots updatePolicyalways/updatePolicy /snapshots idcaplin/id urlfile:/maven/maven-repo/url /repository repository snapshots enabledfalse/enabled /snapshots idcentral/id nameMaven Repository Switchboard/name urlhttp://repo1.maven.org/maven2/url /repository /repositories ... My project pom file is: ?xml version=1.0? project modelVersion4.0.0/modelVersion groupIdcaplin/groupId artifactIdtestproject/artifactId version1.4.1/version dependencies dependency groupIdtest.richardc/groupId artifactIdtest/artifactId version1.0/version typezip/type /dependency /dependencies /project And the debug output is: D:\Development\Sandbox\testmvn -X dependency:unpack-dependencies -DoutputDirect ory=mvn -DmarkersDirectory=mvn + Error stacktraces are turned on. Maven version: 2.0.10-RC7 Java version: 1.5.0_08 OS name: windows xp version: 5.1 arch: x86 Family: windows [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\richardc\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'D:\buildTools\apache- maven-2.0.10-RC7\bin\..\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [DEBUG] Loading plugin prefixes from group: com.octo.mtg [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:10 for project: org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: org.apache.m aven:maven-parent:pom:7 from the repository. [DEBUG] Wagons could not be registered as the extension container was never crea ted [INFO] [INFO] Building Unnamed - caplin:testproject:jar:1.4.1 [INFO]task-segment: [dependency:unpack-dependencies] [INFO] [DEBUG] caplin:testproject:jar:1.4.1 (selected for null) [DEBUG] test.richardc:test:zip:1.0:compile (selected for compile) [DEBUG] Plugin dependencies for: org.apache.maven.plugins:maven-dependency-plugin:2.0 are: org.apache.maven:maven-artifact:jar:2.0.8:runtime org.apache.maven:maven-plugin-api:jar:2.0.8:runtime org.apache.maven:maven-project:jar:2.0.8:runtime org.apache.maven:maven-model:jar:2.0.8:runtime org.apache.maven:maven-core:jar:2.0.8:runtime org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-9:runtime org.codehaus.plexus:plexus-utils:jar:1.4.6:runtime org.apache.maven.shared:file-management:jar:1.1:runtime org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:ru ntime org.apache.maven.shared:maven-dependency-analyzer:jar:1.0:runtime org.apache.maven.shared:maven-dependency-tree:jar:1.1:runtime org.apache.maven.shared:maven-common-artifact-filters:jar:1.0:runtime org.codehaus.plexus:plexus-io:jar:1.0-alpha-1:runtime org.apache.maven.reporting:maven-reporting-api:jar:2.0.6:runtime org.apache.maven.reporting:maven-reporting-impl:jar:2.0.4:runtime
RE: dependency:unpack-dependencies not updating releases
By changing a release artifact you are violating Maven Commandment #1: Release artifacts are immutable. Maven will never recheck for updated release artifacts, so it will just hand back what's in the local repository to the plugin every time. -Original Message- From: Richard Chamberlain [mailto:richard.chamberl...@caplin.com] Sent: Friday, March 27, 2009 12:28 PM To: Maven Users List Subject: dependency:unpack-dependencies not updating releases Hi, I'm using dependency:unpack-dependencies to get some zips of artefacts from our company repository. However if I update a released artefact without changing the version (i.e. documentation change), our company repository is never checked by my script. The only way to get the latest version is to delete the artefact from my cache so it re-resolves it. When a dependency is a snapshot it is always updated. The command i'm using is: mvn dependency:unpack-dependencies -DoutputDirectory=mvn -DmarkersDirectory=mvn And the output from mvn help:effective-pom shows that my updatePolicy is set to always: ... repositories repository releases updatePolicyalways/updatePolicy /releases snapshots updatePolicyalways/updatePolicy /snapshots idcaplin/id urlfile:/maven/maven-repo/url /repository repository snapshots enabledfalse/enabled /snapshots idcentral/id nameMaven Repository Switchboard/name urlhttp://repo1.maven.org/maven2/url /repository /repositories ... My project pom file is: ?xml version=1.0? project modelVersion4.0.0/modelVersion groupIdcaplin/groupId artifactIdtestproject/artifactId version1.4.1/version dependencies dependency groupIdtest.richardc/groupId artifactIdtest/artifactId version1.0/version typezip/type /dependency /dependencies /project And the debug output is: D:\Development\Sandbox\testmvn -X dependency:unpack-dependencies -DoutputDirect ory=mvn -DmarkersDirectory=mvn + Error stacktraces are turned on. Maven version: 2.0.10-RC7 Java version: 1.5.0_08 OS name: windows xp version: 5.1 arch: x86 Family: windows [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\richardc\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'D:\buildTools\apache- maven-2.0.10-RC7\bin\..\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [DEBUG] Loading plugin prefixes from group: com.octo.mtg [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:10 for project: org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: org.apache.m aven:maven-parent:pom:7 from the repository. [DEBUG] Wagons could not be registered as the extension container was never crea ted [INFO] [INFO] Building Unnamed - caplin:testproject:jar:1.4.1 [INFO]task-segment: [dependency:unpack-dependencies] [INFO] [DEBUG] caplin:testproject:jar:1.4.1 (selected for null) [DEBUG] test.richardc:test:zip:1.0:compile (selected for compile) [DEBUG] Plugin dependencies for: org.apache.maven.plugins:maven-dependency-plugin:2.0 are: org.apache.maven:maven-artifact:jar:2.0.8:runtime org.apache.maven:maven-plugin-api:jar:2.0.8:runtime org.apache.maven:maven-project:jar:2.0.8:runtime org.apache.maven:maven-model:jar:2.0.8:runtime org.apache.maven:maven-core:jar:2.0.8:runtime org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-9:runtime org.codehaus.plexus:plexus-utils:jar:1.4.6:runtime org.apache.maven.shared:file-management:jar:1.1:runtime org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:ru ntime org.apache.maven.shared:maven-dependency-analyzer:jar:1.0:runtime org.apache.maven.shared:maven-dependency-tree:jar:1.1:runtime org.apache.maven.shared:maven-common-artifact-filters:jar:1.0:runtime org.codehaus.plexus:plexus-io:jar:1.0-alpha-1:runtime org.apache.maven.reporting:maven-reporting-api:jar:2.0.6:runtime org.apache.maven.reporting:maven-reporting-impl:jar:2.0.4:runtime org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-8:runtime org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:runtime
RE: Apache maven snapshots repository root links are invalid
Thanks for pointing this out. It's actually a misconfig in the proxy rewrite rules. The /snapshots is actually a proxy of http://repository.apache.org/content/groups/snapshots and it looks like the reverse proxy rules are bunging up the url. I'll have to polish my rewrite-fu to get them worked out. -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Thursday, March 26, 2009 6:59 AM To: Maven Users List Subject: Apache maven snapshots repository root links are invalid Hello maven users, Links on http://repository.apache.org/snapshots are invalid, they are missing snapshots part. This is error only in the root of the repository, once in some directory e.g. http://repository.apache.org/snapshots/org;, links work well. It seems to be some sort of (nexus) configuration issue. Regards, Stevo.
RE: How to perform a deploy only
Running the full lifecycle is a fundamental of Maven, so this type of feature request is unlikely to gain traction. You should rather look at your build configuration to solve the problem, or as mentioned use a repo man that can help you out. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 11:26 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - 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: Find updates to versioned dependencies and plugins
Google for the versions-maven-plugin -Original Message- From: Marcin Wiśnicki [mailto:mwisni...@gmail.com] Sent: Wednesday, March 25, 2009 9:27 AM To: users@maven.apache.org Subject: Find updates to versioned dependencies and plugins Hi, this might be a silly question but I did a lot of googling and failed to find the answer: How can I get a list of all outdated dependencies of my project, that is, dependencies and plugins for which there are newer versions in remote repositories than specified in my pom.xml ? Thanks. PS. Please CC me when responding as I'm not subscribed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. Do we assume that bob is unable to see that the version he currently works on and compiles, tests, installs and maybe deploys has 2.2-snapshot written all over it? Maybe bob shouldn't be writing code ;-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org
The jar is now on central and is being pushed again to all 1st level mirrors. -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Wednesday, March 25, 2009 9:48 PM To: Maven Users List Subject: Re: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org We're trying to recover the release artifact that seems to have been lost in transit. To work around this, you should add maven-install-plugin to your POM with the previous version (2.2). This is a good practice for reproducibility regardless, and in place by default in Maven 2.0.9+. Cheers, Brett On 26/03/2009, at 11:01 AM, Ellecer Valencia wrote: Hi, We've just had a problem with a build that was looking for the latest maven-install-plugin, which is 2.3. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3 I've looked at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plu gin/2.3/ and the jar file isn't there. The sources and javadoc jar files are present. Are these files being uploaded manually or automatically? Was it just mistakenly deleted? Thanks for your help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 to perform a deploy only
This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: Show maven plug-in configuration options?
Lookup mvn help:describe on the maven-help-plugin page, that will get you the info that normally shows on a plugin's website. -Original Message- From: Will Hoover [mailto:java.whoo...@gmail.com] Sent: Tuesday, March 24, 2009 2:50 PM To: 'Maven Users List' Subject: Show maven plug-in configuration options? Does anyone know of a way to show a maven plugin configuration options from the mvn command? - 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: Does a plugin with no executions need to be marked inherited?
Inherited is true by default. Prior to 2.0.9, only executions could be marked to not inherit, not the entire config. -Original Message- From: Trevor Harmon [mailto:tre...@vocaro.com] Sent: Tuesday, March 24, 2009 3:04 PM To: Maven Users List Subject: Does a plugin with no executions need to be marked inherited? Hi, I have a parent POM that configures the Compiler plugin for Java 1.4. It modifies the plugin's configuration and does not define any goals or executions. In such a situation, does setting the plugin's inherited element to true have any effect? For example: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration inheritedtrue/inherited /plugin My tests (using help:effective-pom) indicate that inherited has no effect on whether this configuration get passed on to children, but does anyone know for sure? Thanks, Trevor - 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 2.1.0 + SHITTY plugin = Whose issue, Mine, Yours, Theirs?
Already been filed: http://jira.codehaus.org/browse/MSHITTY-10 -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Monday, March 23, 2009 8:58 AM To: Maven Users List Subject: Re: Maven 2.1.0 + SHITTY plugin = Whose issue, Mine, Yours, Theirs? I think the integration testing plugin will need to be updated for compat with Maven 2.1.0 - the version it installs it with (testing) is inconsistent with the internal metadata of the plugin that says it is X.Y.Z-SNAPSHOT. This might be a cumbersome change - we can look at alternatives but for now please file it with the plugin issue tracker. - Brett On 23/03/2009, at 11:48 PM, Josh Suereth wrote: All, I just upgraded to Maven 2.1.0 and Im getting the following error in the integration test logs when running my Super Helpful Integration Testing ThingY (SHITTY) integration tests - OUT: org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager getting plugin 'org.scala-tools:maven-scala- plugin': Plugin 'org.scala-tools:maven-scala-plugin:testing' has an invalid descriptor: OUT: 1) Plugin's descriptor contains the wrong version: 2.10.1 OUT:at org .apache .maven .lifecycle .DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java: 1521) I'm guessing maven 2.1.0 is performing some new check that the shitty plugin hasn't been updated for? As a temporary work-around I can just develop in maven 2.0.10 for now, however I was wondering if 1) This is actually an issue with the shitty plugin, or I've failed to configure things correctly 2) I should be using some other form of integration testing for maven 2.1.0 3) if anyone else has seen this issue? Thanks for the help! Maven 2.1.0 is working great for all my other projects that use the maven-scala-plugin, just not the plugin itself. Great work Maven Team -Josh -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: Is there a mavenized library for copying files?
Look at the maven-dependency-plugin -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Friday, March 13, 2009 3:06 PM To: 'Maven Users List' Subject: Is there a mavenized library for copying files? I am writing a plugin which needs to copy files. Since the File.rename() command can fail if source and target are on different drives, and since I don't want to write my own byte mover loop, I wonder whether there is an out-of-the-box file copy / file move library that I can just call? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Is there a mavenized library for copying files?
Sorry I misunderstood the question. Plexus-utils has a fileUtils.move (or something similar, don't have the source in front of me) -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Friday, March 13, 2009 4:05 PM To: Maven Users List Subject: RE: Is there a mavenized library for copying files? Look at the maven-dependency-plugin -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Friday, March 13, 2009 3:06 PM To: 'Maven Users List' Subject: Is there a mavenized library for copying files? I am writing a plugin which needs to copy files. Since the File.rename() command can fail if source and target are on different drives, and since I don't want to write my own byte mover loop, I wonder whether there is an out-of-the-box file copy / file move library that I can just call? - 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: dependency lookup url
You want a settings like this: http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-gro up.html On 3/11/09 1:25 PM, mcystems mcyst...@googlemail.com wrote: I tried every possible combination on settings.xml: without mirrors, with mirrors defining snapshot a release repositories remove them. Nothing. It seems that the build-in central repository configuration cannot be override in settings.xml. While I debugged maven I find that the central repository policy is always disabled no matter what. However! If I put my snapshot repository url into the projects pom.xml it works. Csaba On Tue, 2009-03-10 at 16:29 -0700, Wayne Fay wrote: I'm mirroring everything to my artifactory instance (maybe that is misconfigured/bugy but since I don't know the lookup url I can't figure out). You still need to declare a snapshot-enabled repo somewhere in your settings.xml. 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: Which phase does a plugin's goal execute ?
Check the site for the plugin. The plugin author can tell maven to execute up to a certain phase in the annotations - and this will be reflected on the plugin's goal page for that goal. On 3/11/09 6:21 PM, Balasubramanian, Ravi Shankar rbala...@informatica.com wrote: Hi all, I am executing a plugin's goal directly through the maven command. It is executed as follows: mvn clover2:setup ( which executes the setup goal of the clover2 plugin) However, I want another plugin's goal to be executed before the clover2:setup goal is executed which I have to mention in the pom.xml. Is there a way to find out which phase does the plugin's goal actually executes when we call it directly ? Tx, Ravi
RE: Maven Meetup @ Sonatype on March 19th 20th
As an addendum to the meetup, we're also going to conduct a keysigning party. For more information about a key signing party, take a look at these excellent documents for how the ApacheCon party runs: http://wiki.apache.org/apachecon/PgpKeySigning Note, that this requires a tiny bit of preparation, and that is simply to send me your public key ahead of time. This way we can print out the list for all attendees. You can export your key like this: gpg --armor --export KEY_ID mykey.asc and then send that file to me via email (bri...@infinity.nu or bri...@sonatype.com) -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Wednesday, March 11, 2009 10:03 PM To: Maven Users List Subject: Maven Meetup @ Sonatype on March 19th 20th Hi, For those interested in knowing what Sonatype is working on in the Maven community, we're having a Maven Meetup the week before EclipseCon in Mountain View. It's a full day of presentations on Maven and related technologies like m2eclipse, Nexus, Tycho, Hudson, NMaven, NAR, FlexMojos and more. That will be followed up by a full day hackathon. You can see the full description here: http://www.sonatype.com/people/2009/03/sonatype-maven-meetup-on-march-19 th-20th/ And you can signup to attend here: https://docs.sonatype.org/display/COMM/Maven+Meetup+on+March+19th+and+20 th+at+Sonatype We are syncing up with the Hippo folks who are putting on the Maven Meetup in Amsterdam (unfortunately the conference organizers didn't notice that EclipseCon and ApacheCon are in the same week) as none of the Sonatype folks can attend ApacheCon. We are planning to record all the sessions on the 19th and so they should be available for everyone at ApacheCon. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency question
The dependency:tree goal does show test dependencies by default. -Original Message- From: stanlick [mailto:stanl...@gmail.com] Sent: Wednesday, March 04, 2009 7:16 AM To: users@maven.apache.org Subject: Re: Dependency question I hear you pal, but the lawyers are concentrating on the fact that the archives are on our machine following a download of the full zip. So do you think Maven might be able to report on them for the lawyers even though they are not dependencies? Peace, Scott Stephen Connolly-2 wrote: Those dependencies are required to *test* struts they are not required by your project as struts has already been tested. -Stephen 2009/3/3 stanlick stanl...@gmail.com Thanks guys -- If you look at the POM for Struts 2.1.6 there are many more dependencies than what show up running dependency:resolve. I verifies the default for scope because several of the dependencies are test. It appears the default is all scopes, so I am wondering why I don't see them all when I run dependency:resolve. Peace, Scott - Show quoted text - -- View this message in context: http://www.nabble.com/Dependency-question-tp22315314p22328900.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: Use mirror in parent snapshot inheritance
Sounds like you have no snapshot repositories enabled in the settings. In our sample settings, we show overloading central to enabled snapshots. The mirror then directs this to nexus which will find it. If maven sees no snapshot repo enabled, it doesn't even try to find it externally. See here: http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-gro up.html -Original Message- From: Vincent Beretti [mailto:vbere...@gmail.com] Sent: Tuesday, March 03, 2009 3:19 AM To: Maven Users List Subject: Re: Use mirror in parent snapshot inheritance Thanks for the answer. I look at the blog article. In fact, we use mirror definition in settings.xml. This is the only way for B to grab A from our Nexus repository. The problem is that when A is not in our local repository, B is not able to grab A in nexus if A is a snapshot version. The mirror is defined for everything (mirrorOf*/mirrorOf) but it seems that it only search for release version and not for snapshots. Is it a wanted restriction or a bug ? I don't really understand Brett Porter's answer in http://jira.codehaus.org/browse/MNG-943, because if the a single POM for the company that is the root that all projects inherit from is a snapshot version, sub modules won't be able to find it. Thanks, Vincent. On Mon, Mar 2, 2009 at 7:57 PM, Brian E. Fox bri...@reply.infinity.nuwrote: You might want to take a look at this: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your- poms-is-a-bad-idea/http://www.sonatype.com/people/2009/02/why-putting-r epositories-in-your-%0Apoms-is-a-bad-idea/ -Original Message- From: Vincent Beretti [mailto:vbere...@gmail.com] Sent: Monday, March 02, 2009 11:37 AM To: users@maven.apache.org Subject: Use mirror in parent snapshot inheritance Hi all, let's consider the following project : A | B | C A is the parent pom of B. In A, I define the repository location of our entreprise repository. A is a currently in a snapshot version so in B's pom.xml I have : parent groupIdcom.xxx/groupId artifactIdA/artifactId version1.0-SNAPSHOT/version parent So when I checkout A and build it from A or B, the build is successfull. But let's consider I only want to checkout B, because I don't want to checkout all C project sources. When I run an install on B project (A is not available through filesystem in the upper directory or in my local repository as a 1.0-SNAPSHOT version), the build fails saying that it can not find the artifact A with version 1.0-SNAPSHOT. This should be normal because it can not find the location of our entreprise repository because it is defined in project A. So I defined a mirror, that for all requests (mirror-of*mirror-of) forward to our entreprise repository for all artifacts (releases and snapshots). It is still not working. I saw this issue : http://jira.codehaus.org/browse/MNG-943 It seems to be the reason why I can't retrieve the snapshots version of my artifact A. It is really blocking for big projects. How can I bypass this limitation ? Can we correct this limitation and allow retrieval of snapshots artifacts ? Thanks, Vincent Beretti. - 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: Dependency question
If every jar present in dependency:resolve is shown in the tree, then that's all folks. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Tuesday, March 03, 2009 2:52 PM To: Maven Users List Subject: Re: Dependency question I am running mvn dependency:tree and expecting a large dependency tree, when in fact all I get is what you see below. I *know* there are more dependencies than this! Can someone help me out with this flags and switches please? How do you *know* there are more dependencies? Have you tried with a sample pom of your own creation that has very well defined first, second, and third-level dependencies, to verify they all appear as you expect? That would be my test -- not a random Struts2 artifact. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: sign refuses to sign jar artifact of project with custom packaging type
Seems like the plugin itself needs to be changed to allow for this. It should look at the type of the file, not the packaging. -Original Message- From: Rob Dickens [mailto:arctic@googlemail.com] Sent: Monday, March 02, 2009 12:50 PM To: users@maven.apache.org Subject: jar:sign refuses to sign jar artifact of project with custom packaging type I get the following message when mvn is run with the -X option: [DEBUG] Not executing jar:sign as the project is not a Java module (Am using a custom packaging type in order to use a custom lifecycle, that invokes a custom goal before the jar:jar one.) If I change the packaging type back to jar, jar:sign does sign the artifact. Could anyone please help. Thanks. -- Rob, Lafros.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Use mirror in parent snapshot inheritance
You might want to take a look at this: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your- poms-is-a-bad-idea/ -Original Message- From: Vincent Beretti [mailto:vbere...@gmail.com] Sent: Monday, March 02, 2009 11:37 AM To: users@maven.apache.org Subject: Use mirror in parent snapshot inheritance Hi all, let's consider the following project : A | B | C A is the parent pom of B. In A, I define the repository location of our entreprise repository. A is a currently in a snapshot version so in B's pom.xml I have : parent groupIdcom.xxx/groupId artifactIdA/artifactId version1.0-SNAPSHOT/version parent So when I checkout A and build it from A or B, the build is successfull. But let's consider I only want to checkout B, because I don't want to checkout all C project sources. When I run an install on B project (A is not available through filesystem in the upper directory or in my local repository as a 1.0-SNAPSHOT version), the build fails saying that it can not find the artifact A with version 1.0-SNAPSHOT. This should be normal because it can not find the location of our entreprise repository because it is defined in project A. So I defined a mirror, that for all requests (mirror-of*mirror-of) forward to our entreprise repository for all artifacts (releases and snapshots). It is still not working. I saw this issue : http://jira.codehaus.org/browse/MNG-943 It seems to be the reason why I can't retrieve the snapshots version of my artifact A. It is really blocking for big projects. How can I bypass this limitation ? Can we correct this limitation and allow retrieval of snapshots artifacts ? Thanks, Vincent Beretti. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Profiles Filters - sharing common config
It's pretty much not the maven way to expect that they will _never_ be in the
local repo. However, dependencies are resolved in the reactor if it is built
in the same mvn execution. The dependency:copy/unpack won't find things there,
but copy-dependencies/unpack-dependencies will.
-Original Message-
From: les.hazlew...@anjinllc.com [mailto:les.hazlew...@anjinllc.com] On Behalf
Of Les Hazlewood
Sent: Saturday, February 28, 2009 7:48 PM
To: Maven Users List
Subject: Re: Profiles Filters - sharing common config
Does the remote-resources and dependency plugins require the artifact
they're depending on to be in a repository (even the local one)?
My 'producer' module is a peer to my 'consumer' module. The consumer
requires the resources .jar from the producer.
I want to run 'mvn package' and have my build work, but things are failing.
Is it absolutely mandatory that an 'install' be executed in order to use the
remote-resources and dependency plugins? Is there a way to get them to
point to the .jar files that already exist on disk in the peer modules? Or
is that not the Maven Way?
My desire is to not install to any repo (even my local $HOME/.m2 one) unless
I can guarantee that all modules in a project package correctly. It just
doesn't seem right to put anything in a repo as consumable unless the
project as a whole can package in its entirety...
Thanks,
Les
On Fri, Feb 27, 2009 at 11:16 AM, Les Hazlewood l...@hazlewood.com wrote:
Ahh - I see your approach Jason - using a .vm template. Nice - I'll work
with that.
Thanks again!
Best,
Les
On Fri, Feb 27, 2009 at 11:03 AM, Les Hazlewood lhazlew...@apache.orgwrote:
Before trying the .tgz file, I wanted to see if I could make it work as
suggested. However, placing the template web.xml file in
src/main/resources didn't work - the consumer's
target\maven-shared-archive-resources directory is empty. Here is my
relevant config:
producer module
plugin
artifactIdmaven-remote-resources-plugin/artifactId
executions
execution
goals
goalbundle/goal
/goals
configuration
includes
param**/*.xml/param
/includes
/configuration
/execution
/executions
/plugin
The web.xml file *is* listed in the
target\classes\META-INF\maven\remote-resources.xml file:
?xml version=1.0 encoding=UTF-8?remoteResourcesBundle
remoteResources
remoteResourceweb.xml/remoteResource
/remoteResources
/remoteResourcesBundle
Here is how I was trying to consume it from another module:
consumer module
plugin
artifactIdmaven-remote-resources-plugin/artifactId
executions
execution
goals
goalprocess/goal
/goals
configuration
resourceBundles
resourceBundle${project.groupId}:producerModuleName:${project.version}/resourceBundle
/resourceBundles
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-war-plugin/artifactId
configuration
webXml${basedir}/target/maven-shared-archive-resources/web.xml/webXml
/configuration
/plugin
Any ideas? Now I'm going to try the tarball...
- Les
On Thu, Feb 26, 2009 at 11:54 PM, Jason van Zyl jvan...@sonatype.comwrote:
There is a bug in the remote-resources-plugin it seems. So I adjusted
slightly and here's a version that works:
http://people.apache.org/~jvanzyl/les2.tgzhttp://people.apache.org/%7Ejvanzyl/les2.tgz
I put the resources in the standard src/main/resources, and then
specified the web.xml in the WAR plugin. Not a hard bug to fix but this will
let you use the released version of the remote resources plugin.
On 26-Feb-09, at 4:35 PM, Les Hazlewood wrote:
Hi all,
I'm having a hell of a time getting this to work with web.xml files. Is
there an example I can look at that produces a bundle and then consumes
one? If there are any uses of this where the template file is an XML
file,
that'd be really useful.
I'm trying to do this using a web.xml file as the 'template' to be
exported
to other modules. Here is what I have so far:
=== Creating the bundle (source module) ===
plugin
artifactIdmaven-remote-resources-plugin/artifactId
executions
execution
goals
goalbundle/goal
/goals
configuration
resourcesDirectory${basedir}/src/main/webapp/resourcesDirectory
includes
param**/*.xml/param
/includes
/configuration
/execution
/executions
/plugin
== Consuming the bundle (dependent module) ==
plugin
artifactIdmaven-remote-resources-plugin/artifactId
executions
execution
goals
goalprocess/goal
/goals
configuration
resourceBundles
resourceBundle${project.groupId}:moduleName:${project.version}/resourceBundle
/resourceBundles
/configuration
/execution
/executions
/plugin
When I look in the dependent module's
target\maven-shared-archive-resources\WEB-INF directory,
RE: Profiles Filters - sharing common config
But the reference
is created to the ${sibling_project}/target/classes directory not to
the artifact produced. So whatever you were going to put into the JAR
will be in the ${sibling_project}/target/classes directory
It's actually a little more screwy than that. It depends on the phase
that you have run. In phases compile, you get nothing. Compile -
Package gets you the classes folder. Package + gets you the jar in
/target/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom: This is due to the old eclipses not supporting nested modules. With M2e this is no longer a problem, so you should maintain a traditional tree structure instead. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Nothing immediate pops into my head, but what if you could hook your CI system to monitor these external xsds and use that to trigger the build? The only way to stop the build currently is via the enforcer plugin, you could make a custom rule...but it would be seen to the CI as a build failure. -Original Message- From: les.hazlew...@anjinllc.com [mailto:les.hazlew...@anjinllc.com] On Behalf Of Les Hazlewood Sent: Wednesday, February 25, 2009 5:56 PM To: users@maven.apache.org Subject: Conditional plugin execution based on build time behavior - Maven profiles not sufficient? Hi folks, Here's what I'm trying to achieve: I have a build that must run every 5 minutes or so in a Continuous Integration server. It must do this because it downloads information that exists outside of a Maven artifact repository or any build environment and must regularly check to see if information has changed. If the information source has changed in any way, my Maven build must create a new SNAPSHOT .jar to reflect the change. If the information doesn't change, a new .jar should never be created or deployed to the repository. This is to avoid uploading a new snapshot .jar every 5 minutes to the repository, and consequently having developers all download this snapshot as a dependency every time they build (yuck). Is there a way to pre-emptively stop a build in order to prevent the .jar from being created/installed/deployed? I don't want to fail the build, because this case is not a failure - the build would have correctly stopped short the lifecycle specifically because the .jar should not be created. This behavior would exclude standard Maven profiles as a solution as I understand them because they're only activated based on some condition when the build starts. The knowledge of if a build should be 'short circuited' would only be available after this plugin finished executing. -- Now, here's my very specific use case of why I'd like to do this (but should probably work generically as described above), in case you're curious: My plugin downloads .xsd files from well-known locations (not maven repositories), auto-generates .java (and then .class) files representing these .xsd files, creates a .jar file and deploys this .jar to a maven repository. Other applications consume this 'Java XSD stubs' .jar to call web services and are quite happy, but they should automatically be updated if the .XSD contracts change, so they can eagerly adapt to these points of change, in true Continuous Integration fashion. But I only want the .jar to be created and deployed to the maven repository if one or more of the downloaded .xsd files are different compared to the last time the build was executed. If the files don't change between 5-minute cycles (verified by downloading them and comparing to the previously retrieved files), nothing should happen Everything is working except for the part where I pre-emptively exit the build, but without Failing the build. Anyone have any ideas? Thanks SO much for feedback! Cheers, Les
RE: Mavenizing Existing Project Part Deux
Dependency:copy and/or dependency:copy-dependencies -Original Message- From: Ketan Khairnar [mailto:ketan.khair...@gmail.com] Sent: Thursday, February 26, 2009 5:42 AM To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Based on this discussion, I have a question here regarding uncommon requirement. Once my build is finished I need to copy all the generated artifacts as well as portal components and some shell scripts/batch files from resources. Copying is done to custom directory which acts as TestBed of the application. i.e. it can start jetty..with portal and all application jars. I couldnt do that using maven-assembly plugin. Only otions I had 1) jar with dependencies - doesnt work as I need it in directory format or rather I can first gather all things and then build executable jarbut it takes longer too considering frequent change install cycle 2) assembly descriptor --- How can I copy generated artifacts i.e. jars modulesets? ..but then with unpack=false option it also copies all dependencies too which I don't need Can anybody suggest me better solution? TIA Ketan On Thu, Feb 26, 2009 at 4:03 PM, Dominic Mitchell d...@semantico.com wrote: On 25 Feb 2009, at 14:40, Steve Cohen wrote: I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. I did this the other day, using the maven-ant-tasks to manage dependencies of an ant based project. I've written a POM and a minimal ant script, which collaborate to download all dependencies from our internal repo. It works like a charm, given that this project can't be converted to maven wholesale yet (it's cocoon 2.1, and would need to be migrated to 2.2). -Dom
RE: New repository for Maven snapshots
Hi Wes, see here for information about using the new repo: https://issues.apache.org/jira/browse/INFRA-1896 and here for a little background: https://issues.apache.org/jira/browse/INFRA-1885 -Original Message- From: Wes Wannemacher [mailto:w...@wantii.com] Sent: Saturday, February 21, 2009 8:52 PM To: Maven Users List Subject: Re: New repository for Maven snapshots On Saturday 21 February 2009 20:10:49 Brian E. Fox wrote: The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. Brian, right now, the struts project pushes its snapshots over to people.a.o when the apache hudson builds them (as often as daily, but usually not quite that often). Is this a new host? If you want to send me the details off-list, I'll need to reconfigure our hudson builds to push to the new host. -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - 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
New repository for Maven snapshots
The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: Error building CAS with Maven 2.0.10
Something is horribly wrong with your setup or the CAS poms. The war plugin here: http://repo1.maven.org/maven2/maven/maven-war-plugin/20030413.023708/mav en-war-plugin-20030413.023708.pom Is not the right one. It should be in org/apache/maven/plugins not /maven. I'm guessing somehow you got a Maven1 plugin in the pom? -Original Message- From: Vinicius Borges [mailto:vinicius...@gmail.com] Sent: Friday, February 20, 2009 12:57 PM To: users@maven.apache.org Subject: Error building CAS with Maven 2.0.10 Hello everybody, I want to build CAS project... but something is gonna wrong... I builded CAS server 3.3.1 with Maven 2.0.10... [INFO] [INFO] Building JA-SIG CAS Web Application [INFO]task-segment: [package, install] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-war-plugin/ 2.1-alpha-2/maven-war-plugin-2.1-alpha-2.pom 7K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-war-plugin/ 2.1-alpha-2/maven-war-plugin-2.1-alpha-2.jar 72K downloaded Downloading: http://repo1.maven.org/maven2/maven/maven-war-plugin/20030413.023708/mav en-war-plugin-20030413.023708.pom 165b downloaded Downloading: http://repo1.maven.org/maven2/maven/maven-war-plugin/20030413.023708/mav en-war-plugin-20030413.023708.jar 4K downloaded [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [maven:maven-war-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [maven:maven-war-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginMana ger.java:327) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(Defau ltPluginManager.java:212) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM anager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycl e(DefaultLifecycleExecutor.java:1239) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa ppings(DefaultLifecycleExecutor.java:1005) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 10 minutes 18 seconds [INFO] Finished at: Fri Feb 20 13:20:56 BRST 2009 [INFO] Final Memory: 25M/51M [INFO] What should be this? Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency/Version Issue with maven
When building the directed graph of how to order the modules at build time, Maven doesn't consider (that I'm aware of) the existence of a dependency in the local repo. Are you using versions to describe the dependency between these modules? That's about the only thing that comes to mind? (even though they are the same version, it may influence it somehow) You can try reordering the modules in your pom, this would possibly cause this problem to go away, but tf you can make a sample project for this, I'd be interested in taking a look. --Brian -Original Message- From: Eric Swenson [mailto:eswen...@intertrust.com] Sent: Wednesday, February 18, 2009 1:39 PM To: users@maven.apache.org Cc: e...@swenson.org; Eric Swenson Subject: Dependency/Version Issue with maven We're running into an issue that causes our automated builds to fail quite frequently now and wonder what it is about our use of maven that is causing this. The builds are failing because the order in which maven (2.0.9) is choosing to build the components of a large, multi-component project is wrong. The question we are trying to answer is how to get maven to build in the right order. Here is the failing scenario. Say there are two modules, Module1 and Module2 where Module1 depends on Module2. A developer makes an incompatible change to Module2 and makes a corresponding change to Module1 so that it becomes compatible with the updated Module2. The version number in neither pom is updated since we are using snapshots, and this change is but one of many in a lifecycle of changes for these versions of the two components. If the build machine completely wipes the local maven repository, pulls afresh from source controls, and does a mvn clean install, of course, everything works just fine. However, our build machine doesn't wipe the local repository, does an svn update, and a mvn install. In this case, maven must do something along the lines of: * Realizes that Module1 needs to be rebuilt because of changes of source files for that module * Realizes that Module2 needs to be rebuilt because of changes of sources files for that module * Looks at the dependency lists of all modules and decides to build Module1 first, followed by Module2. It noted that Module1 was dependent on Module2, but it looked at the version number of the dependency and noted that the local maven repository already has an (old) version of the Module2 artifact - same version number, but an old (incompatible) snapshot). So it concluded, since there was already the correct version in the maven local repo, that it didn't need to build Module2 first. * It compiles Module1, which fails because Module2 is required to be rebuilt first (and the local maven repo updated with the changes). What are we doing wrong in our use of maven here that makes this not work? We don't want to have to clean out the local repo before each build. Changing the build to use mvn clean install doesn't help. The exact same problem occurs for the exact same reason. Note, although we are using snapshot versions for all our components, we are NOT deploying to a shared repository (or even the build machine's local repository). Any help or suggestions on changes to our use of maven? n Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: eclipse ide not picking up settings.xml
The settings isn't refreshed except at startup or if you force it via the preferences-maven page. (assuming this is m2e) -Original Message- From: Mick Knutson [mailto:mknut...@baselogic.com] Sent: Monday, February 16, 2009 10:19 PM To: maven Subject: Re: eclipse ide not picking up settings.xml I am still looking into this, and it appears that the embedded eclipse maven, is not picking up my /Users/mick/.m2/settings.xml When I add the properties into the run configuration, the build finds that missing property. But I have many Can anyone help? --- Thank You... Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://baselogic.com Linked IN: http://linkedin.com/in/mickknutson Twitter: http://twitter.com/mickknutson Vacation Rental: http://tahoe.baselogic.com --- On Sun, Feb 15, 2009 at 5:37 AM, Mick Knutson mknut...@baselogic.comwrote: When I run my build on the command line, the profiles.xml is picked up fine, but when I run this through eclipse 3.4.1, the properties in my profiles.xml are not present. Any ideas? --- Thank You... Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://baselogic.com Linked IN: http://linkedin.com/in/mickknutson Twitter: http://twitter.com/mickknutson Vacation Rental: http://tahoe.baselogic.com --- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Removing: jar from forked lifecycle, to prevent recursive invocation
This means the plugin that caused the fork to occur is removed from that forked lifecycle so it doesn't fork again. -Original Message- From: Romain Gilles [mailto:romain.gil...@thomsonreuters.com] Sent: Tuesday, February 17, 2009 5:08 AM To: Maven Users List Subject: Removing: jar from forked lifecycle, to prevent recursive invocation Hi all, I have this message during my build process but I don't understand it: Removing: jar from forked lifecycle, to prevent recursive invocation It does not provide the name of the Jar, is there anybody that can help me, please? Romain. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. - 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: Anyone? Snapshots repositories, how should they work?
Nexus only stores what Maven sends it. So if you have defined things as legacy (m1) in maven and told Nexus it's m2, you're going to have some trouble. Make everything M2, non-legacy (the default) and it should just work. -Original Message- From: Kent Närling [mailto:kent.narl...@seamless.se] Sent: Monday, February 16, 2009 12:46 PM To: Maven Users List Subject: Re: Anyone? Snapshots repositories, how should they work? Ok, funny enough, I have set the format in nexus to maven2, but it still insists on storing it in legacy format... strange... Could this be a bug in nexus? we are using an older beta version ... The meta data file very correctly says the incorrect build number and timestamp: versioning - snapshot timestamp20090213.090140/timestamp buildNumber303/buildNumber /snapshot - versions version1.1-SNAPSHOT/version version4.2.2-SNAPSHOT/version It seems this timestamp buildnumber refers to another artifact in the same directory?!? I can see why the legacy format is messed up... :-( 2009/2/16 Nick Stolwijk nick.stolw...@gmail.com Legacy layout is the maven 1 layout. If you only use maven 2, don't use the legacy layout. I guess something goes wrong with your metadata. If you use a maven 2 layout like maven[1] there will be a metadata file, to construct the final url. What does your metadata file say about your snapshots? [1] http://repository.sonatype.org/content/repositories/apache-snapshots/org/apache/maven/maven/2.0.10-SNAPSHOT/maven-metadata.xml With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Feb 16, 2009 at 6:03 PM, Kent Närling kent.narl...@seamless.se wrote: I thought legacy layout was standard for snapshot repositories? Is it even possible to use non-legacy layout for snapshots? And it does try to use the correct path, it is just the timestamp/buildnumber that mismatch...? 2009/2/16 Nick Stolwijk nick.stolw...@gmail.com http://nexus:8081/nexus/content/groups/public-snapshots/com.my.common/poms/my-artifact-0.11-20090211.000348-293.pom Seeing you have a special directory for poms it looks like you have a legacy repository defined. Maybe that goes wrong? Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Feb 16, 2009 at 5:44 PM, Kent Närling kent.narl...@seamless.se wrote: Anyone give me a pointer regarding this? please? Is it a very stupid question... ? :-( -- Forwarded message -- From: Kent Närling kent.narl...@seamless.se Date: 2009/2/11 Subject: Snapshots repositories, how should they work? To: Maven Users List users@maven.apache.org This might be a newbie question, bit I have tried to find documentation explaining how snapshot repositories should work... can anyone give me a pointer? We have an internal repository (nexus) and a build server (continuum) which works fine with released artifacts etc However I cannot get automatic download of snapshot dependencies to work successfully...? I have added a snapshot-enabled repository to my settings and it does try to download it, but it seems it gets the timestamp/build number incorrect all the time! For instance, I can see that maven is trying to download: Downloading: http://nexus:8081/nexus/content/groups/public-snapshots/com.my.common/poms/my-artifact-0.11-20090211.000500-295.pom But when I check the repo manually, the latest snapshot was actually named: http://nexus:8081/nexus/content/groups/public-snapshots/com.my.common/poms/my-artifact-0.11-20090211.000348-293.pom What am I doing wrong? -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: kent.narl...@seamless.se www.seamless.se - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: kent.narl...@seamless.se www.seamless.se - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: kent.narl...@seamless.se www.seamless.se - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
RE: recurrent exception
Haha, I think that's Brett's form of: http://lmgtfy.com/?q=DashboardUtils+getDocument()+SAXException -Original Message- From: Brett Randall [mailto:javabr...@gmail.com] Sent: Monday, February 16, 2009 4:37 PM To: Maven Users List Subject: Re: recurrent exception Top hit on Google for: DashboardUtils getDocument() SAXException Premature end of file is: https://jira.codehaus.org/browse/MOJO-1292 May be relevant to your issue. Brett On Mon, Feb 16, 2009 at 10:02 PM, Giovanni Azua brave...@swissonline.chwrote: Hi, I have lately seen this exception below recurrently popping out in my build. Any clues? TIA, Regards, Giovanni [ERROR] DashboardUtils getDocument() SAXException: org.xml.sax.SAXParseException: Premature end of file. at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.jav a:23 9) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Docume ntBu ilderImpl.java:283) at org.codehaus.mojo.dashboard.report.plugin.DashBoardUtils.getDocument(Das hBoa rdUtils.java:886) at org.codehaus.mojo.dashboard.report.plugin.DashBoardUtils.getTaglistRepor t(Da shBoardUtils.java:834) at org.codehaus.mojo.dashboard.report.plugin.DashBoardUtils.getDashBoardMav enPr oject(DashBoardUtils.java:308) at org.codehaus.mojo.dashboard.report.plugin.DashBoardReportMojo.executeRep ort( DashBoardReportMojo.java:280) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenRep ort. java:98) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(Repo rtDo cumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(Def ault SiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSi teRe nderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nage r.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default Life cycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle (DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifec ycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Fail ures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( Defa ultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycle Executor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) - 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: New Maven Respository Search Application
Hopefully they are using the indexes and not scraping the entire contents of the repos. -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Thursday, February 12, 2009 9:57 AM To: Maven Users List Subject: RE: New Maven Respository Search Application Does this only index Central? -Original Message- From: Deron Eriksson [mailto:jonde...@codestrategies.com] Sent: Thursday, February 12, 2009 6:07 AM To: users@maven.apache.org Subject: New Maven Respository Search Application I'd like to announce our new Maven repository search application called Jarvana that features searching for classes, artifacts, and content. In addition to project dependency information, class search results include links to relevant source code and javadocs when available. Class and artifact search results include links to a 'POM inspector' and the relevant archive file, which can be drilled into online. Plugin information is displayed when available. Content searches can be broken down into different areas (html, java, xml, etc) and include a 'Highlighter' feature similar to Google's 'Cached' results highlighting. The main page is available at: http://www.jarvana.com The application features a repository browser that has shortcut links and allows for sorting based on a variety of characteristics such as the number of folders, directories, and archives within folders. http://www.jarvana.com/jarvana/browse The browser 'Archive Details' view sums up statistics about all of the files in all of the archives. These results are also sortable. http://www.jarvana.com/jarvana/browse?d=ypath=by=order= We also just added a 'Digest Generator and Checker' tool that generates MD5 and SHA1 digests for an uploaded file and checks to see if those digests exist in the repository. This tool can be found here: http://www.jarvana.com/jarvana/more Jarvana is still a work in progress so UI and functionality changes are quite likely to occur in the near future. Questions, comments, and constructive criticism are always welcome! Deron Eriksson Code Strategies -- View this message in context: http://www.nabble.com/New-Maven-Respository-Search-Application-tp2197396 1p21973961.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Does maven not use VERSION while detecting circular dependencies?
- Geoffrey This is too limiting IMO. Sahoo Why? You can't have multiple versions of the same jar on the classpath, so allowing these circular dependencies to take version into consideration just pushes the problem futher down the stack. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Resolved Version Weirdness
Sounds to me like a classic case of not specifying your direct dependencies. Some other pom changed and introduced a transitive change breaking something you actually depend on. Run mvn dependency:analyze on your projects, if it says you are missing direct dependencies, you should fix them. Yes, dependency-plugin and jar-plugin use the same resolution -- that is core hands the artifact list over to the plugins when they start. The dependency-plugin get the test scope to start which includes everything, perhaps some test dependency you have slightly changed and is influencing the dependency tree as seen by it. -Original Message- From: Reinhard Nägele [mailto:reinhard.naeg...@mgm-tp.com] Sent: Monday, February 09, 2009 2:41 AM To: users@maven.apache.org Subject: Resolved Version Weirdness Hello, We have a multi-module project which transitively uses Commons Logging. We do not use it directly ourselves and so did not explicitly declare it as a dependency. So far, this has not been a problem. But for some reason, something must have changed over the weekend. I started our application and got a NoClassDefFoundError because org.apache.commons.logging.LogFactory was missing. I then checked the following: - Maven dependencies in Eclipse (using m2eclipse) showed commons-logging-1.1 - The dependency hierarchy and dependency:tree showed commons-logging-1.1 as the winner (amongst 1.0, 1.0.3, 1.0.4, 1.1, 1.1.1) . dependency:copy copied commons-logging-1.1.jar - The Jar plugin wrote commons-logging-1.1.1 into the manifest. So, the problem is that either the Jar plugin or the Dependency plugin is wrong. Don't they use the same mechanism in order to determine the classpath? Naturally, I would expect the latest version to win. I don't understand why this happened all of a sudden. Nothing has changed here, and all our plugin versions are locked. For now, I fixed the problem by explicitly adding commons-logging-1.1.1 as a dependency, but I don't really like this. I'd appreciate any insight into what's going on here. Thanks, Reinhard - 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 2.0.9 - Upgrade Hints/Conflicts with other tools?
There were changes between 2.0.5 and 2.0.6 that related to the handling of transitive dependencies and dependencyManagment. There is a goal in the dependency plugin to help you prepare your build before you migrate. You definitely want to look at this: http://maven.apache.org/plugins/maven-dependency-plugin/examples/prepari ng-dependencies.html Anything else should be documented in the release notes for each release which is still on the site. Also note that 2.0.10 is staged and being voted on. Assuming it will pass, it's 2 days away from a release. -Original Message- From: David Bruley [mailto:david.bru...@bcbsnd.com] Sent: Tuesday, February 10, 2009 9:52 AM To: users@maven.apache.org Subject: Maven 2.0.9 - Upgrade Hints/Conflicts with other tools? Hello, I work for a company that is fairly new to Maven and open source in general. We are currently using Maven 2.0.5 with Continuum for our continuous build server and Artifactory for our internal artifact repository. We need to upgrade to Maven 2.0.9, but this is the first time we have upgraded and I have a few questions/concerns. I tried to search for related info on Google but did not find much. I also tried to search the last few months worth of posts on the mailing list. I did come across an older post on issues with Continuum and Maven 2.0.7 http://jira.codehaus.org/browse/MNG-3084 and while it is obviously not an issue for 2.0.9, it's an example of some of the concerns I have of potential issues to watch out for. Essentially, my question is, are there any best practices to follow when upgrading versions of Maven? Are there easy ways to upgrade all the latest versions of various plug-ins for example? Does one necessarily need to upgrade to the latest versions of plug-ins or is it more of a case by case basis? Are there any issues to be aware of with Continuum? Perhaps that's a post for the Continuum mailing list. I apologize if this is too basic a question, as I mentioned we are fairly new to the environment and I would like to make this initial upgrade as seamless as possible. It's not the actual upgrade of Maven, that's simple enough, more any related steps in the process that we may not be aware of. Thanks in advance for any assistance. Dave Bruley Technical Analyst CoreLink Administrative Solutions Confidentiality Notice: This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient(s), please contact the sender by replying to this e-mail and destroy/delete all copies of this e-mail message. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Problems with maven-kogo-plugin
This was my project and since it got blocked by maven 2.0.2 bugs at the time... I never went back to fixing it. Now that you can fairly easily wrap ant tasks into plugins, I would suggest that approach. The kodo plugin in the sandbox required too much hacking of the ant task code to make it work reliably. It did work ok for enhancing at the time but I would be surprised if it worked with later versions of their tools. -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Tuesday, February 10, 2009 11:06 AM To: Maven Users List Subject: Re: Problems with maven-kogo-plugin I see a Sourceforge project [1] which haven't been updated for quite a while (2005) and a codehaus project [2], which also seems a bit dead. (Correct me if I'm wrong) It seems the Sourceforge project is still a maven 1 plugin and the codehaus project didn't got any further than an alpha version. I think you're out of luck. [1] http://maven-plugins.sourceforge.net/maven-kodo-plugin/ [2] http://mojo.codehaus.org/kodo-maven-plugin/index.html Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Tue, Feb 10, 2009 at 4:57 PM, Sean Hennessy shenne...@astutenetworks.com wrote: transcription error perhaps? maven-kodo vs maven-kogo -Original Message- From: maven_noob [mailto:kristianfra...@gmail.com] Sent: Tuesday, February 10, 2009 7:33 AM To: users@maven.apache.org Subject: Problems with maven-kogo-plugin I'Hi there - I'm trying to get this plug in to work when installing one of my projects. This is the message I am getting when trying to do an mvn install: [INFO]task-segment: [install] [INFO] [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for updates from central [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [maven-plugins:maven-kodo-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [maven-plugins:maven-kodo-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:325) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:212) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1238) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1004) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue Feb 10 09:25:37 CST 2009 The pom for my project contains the following: plugin groupIdmaven-plugins/groupId artifactIdmaven-kodo-plugin/artifactId version3.1.2/version executions execution phasecompile/phase goals goalenhance/goal /goals /execution /executions /plugin Any suggestions? Thanks! -- View this message in context:
ApacheCon Europe 2009: Early Bird Deadline Extended
Subject: ApacheCon Europe 2009: Early Bird Deadline Extended until 13th of February Here's some great news for everyone who's thinking of traveling to Amsterdam for this year's ApacheCon Europe. The Early Bird deadline has been extended to Friday, February 13th - and remember, there is a discount of 150 Euro on registration for anyone staying at the Mövenpick Hotel. Register at http://www.eu.apachecon.com. ApacheCon is a week of open source goodness straight from the source of The Apache Software Foundation: - More than 60 1-Hour Sessions on System Administration, Development, Data Mining and Search Technologies, Enterprise Web Services, SOA, and Cloud Technologies, Open Source Business and Community, and more - Over a dozen Training Workshops from industry experts (see below) - World-class Keynotes and vendor Expo - Lightning Talks and Birds-of-a-Feather sessions - New this year: Geeks for Geeks Track, BarCampApache, and Hackathon! ApacheCon Europe 2009 features 2-day, 1-day, and half-day Training Workshops on the following topics: Data Mining and Search Technologies --- - Lucene Boot Camp (Grant Ingersoll) - Solr Boot Camp (Erik Hatcher) The Next Generation of Web Data Storage --- - Building Standalone CouchDB Applications (J. Chris Anderson) - High Performance CouchDB (J. Chris Anderson) Cloud and Distributed Computing Technologies - Hadoop Tools and Tricks for Data Processing Pipelines (Christophe Bisciglia and Aaron Kimball) System Administration - - Apache HTTP Server - Nuts to Bolts (Jim Jagielski) - Everything Tomcat - Administering, Tuning, Troubleshooting and Developing (Mark Thomas) Developing State-of-the-Art Web Applications - A Day of REST (J Aaron Farr) - Apache CXF - Developing and Deploying Open Source SOA Endpoints (Adrian Trenaman) - Ajax on Struts 2: How a Second Generation Web Application Framework Meets the Demands of RIA (Chad Michael Davis) - Behavior-Driving Your Apache Wicket Application: Making the Most of Webdriver and JDave-Wicket (Timo Rantalaiho) Building and Managing Java-based Projects - - Maven Workshop (Zeger Hendrikse) Professional Media Trainings - Media Analyst Training (Sally Khudairi) - Intermediate Media Analyst Training (Sally Khudairi) We hope to see you on the 23-27 March at the Mövenpick Hotel in Amsterdam! Visit http://www.eu.apachecon.com for further information and registration details. Interested in sponsoring the ApacheCon conferences? Please contact Delia Frees at de...@apachecon.com for further information. -- ApacheCon Europe 2009 Team planners-2009-eu at apachecon.com http://www.eu.apachecon.com
RE: Checkstyle report failing
You need to put it in the reportingPlugins section of you pom. -Original Message- From: bwonch [mailto:bill.wo...@gmail.com] Sent: Thursday, February 05, 2009 10:30 PM To: users@maven.apache.org Subject: Checkstyle report failing Hi everyone - I'm not sure if this is the appropriate place for this posting or not. We have a Maven build, using Hudson as the CI server. We're running the Checkstyle maven plugin. When I call checkstyle, it runs as expected and I see the resulting output in Hudson through the Checkstyle plugin, but when I run mvn site, it's not showing any results. Here's the checkstyle call, if that helps: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId /plugin Any ideas what I'm doing wrong here? Thanks! Bill -- View this message in context: http://www.nabble.com/Checkstyle-report-failing-tp21865980p21865980.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: Got blocked?
Noone has been blocked recently. Note that wget is blocked automatically so if you use that, it won't work. Use your browser to test connectivity. -Original Message- From: Johannes Schneider [mailto:maili...@cedarsoft.com] Sent: Thursday, February 05, 2009 4:17 PM To: users@maven.apache.org Subject: Got blocked? Hi, I get a lot of 443s when trying to connect to Maven Central Repository. The IP of my build server is 78.47.151.147. How can I get unblocked? I just tried to install Nexus - maybe something went wrong? Regards, Johannes Schneider - 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
[Please Test] 2.0.10-RC8
The previous regressions have been fixed. Here's the list of issues fixed in 2.0.10: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName =HtmlprojectId=10500Create=Create Staged at (self-signed cert for now) https://repository.zones.apache.org/content/groups/staging/org/apache/ma ven/apache-maven/2.0.10-RC8/ Please try it out and see if we have any remaining regressions over 2.0.9. Thanks, Brian -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: RE: nexus can't find maven-archetype-plugin?
You will have trouble getting snapshots with your settings because you are only mirroring central which is not enabled for snapshots. You want to use something like this: settings mirrors mirror mirror !--This sends everything to /public -- idnexus/id mirrorOf*/mirrorOf urlhttp://localhost:8081/nexus/content/groups/public/url /mirror /mirrors profiles profile iddevelopment/id repositories repository idcentral/id urlhttp://central/url releasesenabledtrue/enabled/releases snapshotsenabledtrue/enabled/snapshots /repository /repositories pluginRepositories pluginRepository idcentral/id urlhttp://central/url releasesenabledtrue/enabled/releases snapshotsenabledtrue/enabled/snapshots /pluginRepository /pluginRepositories /profile /profiles activeProfiles activeProfiledevelopment/activeProfile /activeProfiles /settings -Original Message- From: Jens Rapp [mailto:tec_la...@gmx.de] Sent: Monday, February 02, 2009 1:32 AM To: Maven Users List Subject: Re: RE: nexus can't find maven-archetype-plugin? well, here's my settings.xml- couldn't send it earlier. I'm just using the standard repositories which are configured in nexus. Original-Nachricht Datum: Thu, 29 Jan 2009 15:16:04 -0500 Von: Brian E. Fox bri...@reply.infinity.nu An: Maven Users List users@maven.apache.org Betreff: RE: nexus can\'t find maven-archetype-plugin? Little hard to diagnose with that info. How is your settings.xml setup? What repos are in your group? What exactly is maven saying (log)? We have a nexus user list where your questions will be noticed quicker: http://nexus.sonatype.org/dev/mailing-lists.html -Original Message- From: Jens Rapp [mailto:tec_la...@gmx.de] Sent: Wednesday, January 28, 2009 4:17 AM To: users@maven.apache.org Subject: nexus can't find maven-archetype-plugin? hi, i'm playing around with nexus as repository manager and now have a little problem: the maven-archetype-plugin can't be found. most of the other plugins work maven uses the standard public repository group in nexus. what do i have to do for being able to use em all??? -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - 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 -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven deploy project on a server different from remote repo server
You could use the assembly plugin to produce a bundle with the dependencies. Or you could patch something together with dependency:copy-dependencies and dependency:build-classpath -Original Message- From: Qureshi,Shahzad [Ontario] [mailto:shahzad.qure...@ec.gc.ca] Sent: Monday, February 02, 2009 11:26 AM To: users@maven.apache.org Subject: Maven deploy project on a server different from remote repo server Hi all, Here is the situation. Our internal remote repository is on server1 and my application that will require some of the jars sitting on the remote repo is on server2. Now my application is in jar format (created using maven) and is used by a web coldfusion based application. Now, do I simply figure out which dependencies my app requires and manually put them somewhere on server2 and use the classpath way of doing things to run this app or is there a better way to do this using Maven? I have been using Maven for a few months now and I understand how it works but I am not sure what to do in this deployment scenario that I mentioned above Any insights will be appreciated. Thank you Shahzad Qureshi Systems Analyst/Programmer Applications Directorate, CIOB Environment Canada shahzad.qure...@ec.gc.ca - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven for the internet afraid
I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach. -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin dependencies We have some list of approved plugins we somehow decide we need. For each, we want to populate our repo with any artifacts those plugins might require in use. During the approval process we create dummy projects to exercise each plugin, then we build those projects against a proxy repo and declare whatever landed in the proxy kosher. That step rubs me wrong because I feel like Maven is resolving plugin dependencies based on the plugin's configuration for a particular project, and we'll easily miss some use cases, ending up with an incomplete repository. Wendy, apparently has a better way that uses the assembly plugin, but I don't quite understand it. Could you illustrate? 2. Different dependency configurations Say we like artifact A, so we create a project, P that depends on A. Declared dependencies are like so: P -- A A -- B, C B -- D-v1 C -- D-v2 So we bundle P's dependencies in remote repo configuration and upload to the approved repository, which now includes A, B, C and D-v1. Some time later, a developer depends on only C, and the project refuses to build. How do you all handle this? In any case, thank you all for the encouragement that we might not be as crazy as I think. - 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: POM element orders
The order should follow the pom, with children always coming before the parent definitions. User bound executions always come after the default ones for any given phase. -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Sunday, February 01, 2009 12:12 PM To: Maven Users List Subject: RE: POM element orders AFAIK, the execution of plugin goals within a phase is not configurable, at least in Maven 2.0.x. In order to make dependency:unpack happen before assembly:attached, just execute dependency:unpack in an earlier lifecycle phase. HTH, Justin From: Éric Daigneault [mailto:dai...@gmail.com] Sent: Sun 2/1/2009 12:08 PM To: users@maven.apache.org Subject: POM element orders Hello, I'm having a bit of a problem here ! I have a project that while not very big, does span a dependency tree a few level deep and has many leaves of final deployed packages. I use maven not only to build and all but to generate zip files that contain everything (doc, runtime environment, libraries, config files etc). This makes the job of people that have to deploy the modules a lot easier. So.. Parent POM contains all that is necessary to build the base package, most of which are set to not be inherited by the children as they will simply use the parent Zip file package as a baseline and will complete or override the necessary files to create the final packages. My problem is this, in the parent I define some build tasks that will be inherited by the children, namely : build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration inheritedtrue/inherited /plugin ... snip ... plugin inheritedtrue/inherited artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc/main/assembly/package.xml /descriptor /descriptors /configuration /plugin /plugins /build I clipped out the extra fluff leaving the interesting bits. In the child project I have this build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin /artifactId executions execution idunpackProcessor/id phasepackage/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdcom.purkinje/groupId artifactIdProcessorService/artifactId classifierpackage/classifier typezip/type overWritetrue/overWrite outputDirectorytarget/processorPack /outputDirectory /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin /plugins The goal is to be able to use the definition of the parent to create a package based on the assembly rules (package.xml) that all child must have. My problem is that the assembly is executed BEFORE the unpacking and thus will not include the parent`s file as intended. The only workaround I found to this is to redefine the assembly section in each children thereby nullifying the inheritance benefit... Questions : 1 - can I control the order in which the build tasks are executed ? 2 - can I create dependencies amongst them so that the order of execution, while not controlled in absolute, would still be respected and do the intended work. 3 - is there a better way to achieve this knowing the children may very well have some code inside along with documentation and configuration ? Many thanks in advance Éric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: POM element orders
Take a look at: http://www.sonatype.com/book and http://www.maven.apache.org/plugins/ -Original Message- From: Éric Daigneault [mailto:dai...@gmail.com] Sent: Sunday, February 01, 2009 8:35 PM To: Maven Users List Subject: Re: POM element orders Thanks Justin, sounds reasonable... there are so many phases to choose from I guess the expanding of the package could very well be in the pre-package phase. @Brian.. That`s just it, when I put the assembly bits in the parent POM it is systematically executed before anything in the children`s POM. I would`ve expected the opposite thereby giving children the opportunity to complete and add to the parent`s actions. Unless I did not get it right. The only way I found (without resorting to other phases) was to copy the assembly part in the children at the end of their POM. I'll give the prior phase definition a try, no reason for it not to work, though I am still puzzled by this behavior, could be a bug but I think the most likely cause is something I do not get in the maven build pattern. when you say userbound and default, in the example above which is considered default ? and which is considered user bound ? also where on the net can I find a bit of help regarding all this ? I find maven really helpfull in many ways, but there is one thing I still find very hard is to reach easy to read and usefull documentation on the plugins, and on the many capabilities of Maven. It is easy inough to find trivial examples but I grew out of these quite fast. Is there anything akin to the Javadoc system that maven plungins be documented in ? Is there a repository of documenatation for plugins ? again, thanks Éric
RE: Maven for the internet afraid
That's one reason why I run Nexus locally when I travel, because the offline mode breaks lots of plugins. -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, January 30, 2009 10:28 PM To: users@maven.apache.org Subject: RE: Maven for the internet afraid you're going to have to reconfig ALL your plugins to use a localRepository this is a massive PITA and documentation is thin maven expects a clear path to ALL scp or sftp or https servers Martin Gainty __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: RE: Maven for the internet afraid Date: Fri, 30 Jan 2009 22:04:36 -0500 From: bri...@reply.infinity.nu To: users@maven.apache.org This use case was exactly what the Procurement in Nexus was designed to support. It allows you to definitively control the artifacts used by your builds. The only alternative is to manage it my hand, which is labor intensive and error prone. http://www.sonatype.com/products/nexus -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Thursday, January 29, 2009 11:28 PM To: users@maven.apache.org Subject: Maven for the internet afraid Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - 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 _ Windows Live(tm): E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_ 012009 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Automatically Synchronizing with Central Repo
Where's the request? It's usually not too bad. The repository-maintain...@apache.org list is where you need to get the attention. -Original Message- From: Lincoln Baxter, III [mailto:lincolnbax...@gmail.com] Sent: Saturday, January 31, 2009 11:30 AM To: Maven Users List Subject: Automatically Synchronizing with Central Repo Just curious, how long did it take people to get projects added to the central repo? I've put in a request, but it's been sitting there for about 3 weeks now. I'm trying to use the automatic sync via ssh_rsync, not the manual upload (which is supposed to take longer.) Thanks, just wondering what I should expect. --Lincoln - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven for the internet afraid
This use case was exactly what the Procurement in Nexus was designed to support. It allows you to definitively control the artifacts used by your builds. The only alternative is to manage it my hand, which is labor intensive and error prone. http://www.sonatype.com/products/nexus -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Thursday, January 29, 2009 11:28 PM To: users@maven.apache.org Subject: Maven for the internet afraid Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - 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: nexus can't find maven-archetype-plugin?
Little hard to diagnose with that info. How is your settings.xml setup? What repos are in your group? What exactly is maven saying (log)? We have a nexus user list where your questions will be noticed quicker: http://nexus.sonatype.org/dev/mailing-lists.html -Original Message- From: Jens Rapp [mailto:tec_la...@gmx.de] Sent: Wednesday, January 28, 2009 4:17 AM To: users@maven.apache.org Subject: nexus can't find maven-archetype-plugin? hi, i'm playing around with nexus as repository manager and now have a little problem: the maven-archetype-plugin can't be found. most of the other plugins work maven uses the standard public repository group in nexus. what do i have to do for being able to use em all??? -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - 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
