Re: Multi-module build/dependency behavior?
And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3-SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar, C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4.0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1.5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0\ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-api\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0.2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.jar, C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1.3.9\jsr305-1.3.9.jar, C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1.4.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0.3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanutils\1.6\commons-beanutils-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-codec\commons-codec\1.3\commons-codec-1.3.jar, C:\Users\steve.seagraves\.m2\repository\commons-configuration\commons-configuration\1.6\commons-configuration-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-lang\commons-lang\2.2\commons-lang-2.2.jar, C:\Users\steve.seagraves\.m2\repository\commons-digester\commons-digester\1.8\commons-digester-1.8.jar, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanutils-core\1.8.0\commons-beanutils-core-1.8.0.jar, C:\Users\steve.seagraves\.m2\repository\commons-dbcp\commons-dbcp\1.2.2\commons-dbcp-1.2.2.jar, C:\Users\steve.seagraves\.m2\repository\commons-pool\commons-pool\1.3\commons-pool-1.3.jar, C:\Users\steve.seagraves\.m2\repository\commons-dbutils\commons-dbutils\1.0\commons-dbutils-1.0.jar, C:\Users\steve.seagraves\.m2\repository\commons-httpclient\commons-httpclient\3.0.1\commons-httpclient-3.0.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-io\commons-io\1.2\commons-io-1.2.jar, C:\Users\steve.seagraves\.m2\repository\jakarta-regexp\jakarta-regexp\1.2\jakarta-regexp-1.2.jar, C:\Users\steve.seagraves\.m2\repository\jaxen\jaxen\1.1.1\jaxen-1.1.1.jar, C:\Users\steve.seagraves\.m2\repository\jdom\jdom\1.0\jdom-1.0.jar, C:\Users\steve.seagraves\.m2\repository\xerces\xercesImpl\2.8.1\xercesImpl-2.8.1.jar, C:\Users\steve.seagraves\.m2\repository\xom\xom\1.0\xom-1.0.jar, C:\Users\steve.seagraves\.m2\repository\xerces\xmlParserAPIs\2.6.2\xmlParserAPIs-2.6.2.jar, C:\Users\steve.seagraves\.m2\repository\xalan\xalan\2.6.0\xalan-2.6.0.jar, C:\Users\steve.seagraves\.m2\repository\lark\lark\19980115\lark-19980115.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-core\2.3.0\lucene-core-2.3.0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-highlighter\2.3.0\lucene-highlighter-2.3.0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-snowball\2.3.0\lucene-snowball-2.3.0.jar, C:\Users\steve.seagraves\.m2\repository\tsmConfig\tsmConfig\3.1.0\tsmConfig-3.1.0.jar, C:\Users\steve.seagraves\.m2\repository\webnfs\webnfs\19990414\webnfs-19990414.jar,
Re: Question about maven profiles activation
Hi, It is indeed exactly my issue. Does anyone of you knows more about this ? I think I will have to wait on this error report to see if such a trick is really possible or not. Cheers, Reynald On 09/25/2009 05:11 PM, Juven Xu wrote: I think this issue is related: https://issues.sonatype.org/browse/MVNDEF-261 On Fri, Sep 25, 2009 at 9:58 PM, Reynald Borerreynald.bo...@elca.chwrote: Dear all, I have been browsing the Maven Book online recently (available on http://www.sonatype.com/books/maven-book/reference/public-book.html), and I have found something interesting about the profiles used in Maven in one example: http://www.sonatype.com/books/maven-book/reference/profiles-sect-tips-tricks.html Basically, this example does the following: - in settings.xml, we define a profile, active by default, that set an environment variable; - in a module pom.xml, we activate another profile based on the presence of the previous environment variable. This is a functionality that looked very interesting at first, with the only drawback that I was not able to make it work. The only solution to activate the profile defined in the pom.xml file was to explicitly set the environment variable on the command-line, which is not what I want to do. I have tested this with versions 2.0.10 and 2.2.1, and both do not work. Does anyone know if what is presented in this example should work ? Or does anyone of you know a similar way of achieving such functionality ? Thanks in advance for your help, Reynald Borer - 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: Can not use the plexus component org.sonatype.plexus.components.sec.dispatcher.SecDispatcher since maven 2.2.0
Le Mon, 28 Sep 2009 09:35:00 +1000,
Brett Porter br...@apache.org a écrit :
It looks like when they were added, they were not properly hidden
from plugin classes. So you will need to ensure you use the exact
version of the library that is used in Maven.
On which artifact should I look on ? maven-core ?
Please report this at http://jira.codehaus.org/browse/MNG so it can be
corrected in future.
ok I will do this.
Thanks,
Brett
On 26/09/2009, at 3:19 AM, Tony Chemit wrote:
Le Fri, 25 Sep 2009 15:17:04 +0200,
Tony Chemit che...@codelutin.com a écrit :
Hi,
Since maven 2.1.0, I use in a mojo the
org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
from the artifact org.sonatype.plexus:plexus-sec-dispatcher:1.3.1
to decrypt password in my settings.xml
I recently change to maven 2.2.1, but my mojo does not anylonger
works fine
(same result with 2.2.0) :
Caused by:
org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field sec in object of type
org.nuiton.mail.plugin.SendEmailMojo because the requirement
ComponentRequirement
{role='org.sonatype.plexus.components.sec.dispatcher.SecDispatcher',
roleHint='default', fieldName='sec'} was missing at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField
(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent
(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent
(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent
(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute
(CompositionPhase.java:29) ...
26 more Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException
:
Unable to lookup component
'org.sonatype.plexus.components.sec.dispatcher.SecDispatcherdefault
', it
could not be started at
org.codehaus.plexus.DefaultPlexusContainer.lookup
(DefaultPlexusContainer.java:339)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField
(FieldComponentComposer.java:129) ...
30 more Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleException
:
Error starting component at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle
(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance
(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent
(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup
(DefaultPlexusContainer.java:331) ...
31 more Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException
:
Error composing component at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute
(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start
(AbstractLifecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle
(AbstractComponentManager.java:105) ...
34 more Caused by:
org.codehaus.plexus.component.composition.CompositionException:
Composition
failed for the field _cipher in object of type
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField
(FieldComponentComposer.java:144)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent
(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent
(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent
(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute
(CompositionPhase.java:29) ...
36 more Caused by: java.lang.IllegalArgumentException: Can not set
org.sonatype.plexus.components.cipher.PlexusCipher field
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
._cipher to
org.sonatype.plexus.components.cipher.DefaultPlexusCipher at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException
(UnsafeFieldAccessorImpl.java:146)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException
(UnsafeFieldAccessorImpl.java:150)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set
(UnsafeObjectFieldAccessorImpl.java:63)
at
Filtering test-resources
HI, I have implemented a filtering scheme for processing resources for different profiles in our project which works very nice - except for tests. 'process-test-resources' copies filtered resources into the classes directory (including the resource files only used for tests!), but also copies the same resources UNFILTERED into test-classes directory. And because this directory is used when running tests, the tests of course all fail when depending on the properties uncorrect defined in this directory. Can anyone suggest me a solution to this problem? Is there a way to enforce filtering on the test resources which are copied to the test-classes directory? Carlo __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: javadoc generation fails only during site generation
Hi, we get the same exception trace using Maven 2.2.1 and after upgrading to javadoc plugin 2.6. Now we use the aggregate goal in a report set instead of the aggregate config parameter. We hava a mulit-module build with two layers of aggregation: A-parent - A1 - A2 - B-parent - B1 - B2 In both parents the aggregate javadoc reportset is defined. When executing mvn install site in the top-level parent A-parent the exception occurs. (Removing the aggregate javadoc report set from B-parent does not help.) It seems to me that in this case the generated @options file does not contain the dependencies of the A1 and A2 modules, but only those of modules B1 and B2. Can somone confirm this behaviour? Is this the cause of the exception? Thanks, Holger Benoit DECHERF-3 wrote: Hi, In my project, when I execute mvn javadoc:javadoc, The javadoc generation works. But It fails when I execute mvn site, it fails: --- [INFO] Generating JavaDocs report. Loading source files for package com.x.euromarketplace.search.cleaner... Constructing Javadoc information... Standard Doclet version 1.6.0_16 Building tree for all the packages and classes... 34 warnings [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - /home/decherfb/tmp/searchCleaner/src/java/com//euromarketplace/search/cleaner/Configuration.java:13: package com..processframework.services does not exist import com..processframework.services.ServiceException; java.lang.NullPointerException at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) at com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) at com.sun.tools.javadoc.Main.main(Main.java:31) Command line was:/usr/java/jdk1.6.0_16/jre/../bin/javadoc @options @packages -- the @options doesn't have a correct classpath : the missing class is in an artifact A1.jar. In the pom, I have the dependency on A1.jar and A1-script.tgz (In this order). If I inverse the order of these dependencies, the site generation works! Do you have an idea on this bug ? Thanks, Benoit -- View this message in context: http://www.nabble.com/javadoc-generation-fails-only-during-site-generation-tp25508297p25641690.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: javadoc generation fails only during site generation
A small correction: The @options file does contain the dependencies of the first A module (A1), but misses those of all other A modules (for example A2). We use the following directory layout: A-parent/pom.xml A1/pom.xml A2/pom.xml B/B-parent/pom.xml B/B1/pom.xml B/B2/pom.xml Hope this helps, Holger Holger Brands wrote: Hi, we get the same exception trace using Maven 2.2.1 and after upgrading to javadoc plugin 2.6. Now we use the aggregate goal in a report set instead of the aggregate config parameter. We hava a mulit-module build with two layers of aggregation: A-parent - A1 - A2 - B-parent - B1 - B2 In both parents the aggregate javadoc reportset is defined. When executing mvn install site in the top-level parent A-parent the exception occurs. (Removing the aggregate javadoc report set from B-parent does not help.) It seems to me that in this case the generated @options file does not contain the dependencies of the A1 and A2 modules, but only those of modules B1 and B2. Can somone confirm this behaviour? Is this the cause of the exception? Thanks, Holger Benoit DECHERF-3 wrote: Hi, In my project, when I execute mvn javadoc:javadoc, The javadoc generation works. But It fails when I execute mvn site, it fails: --- [INFO] Generating JavaDocs report. Loading source files for package com.x.euromarketplace.search.cleaner... Constructing Javadoc information... Standard Doclet version 1.6.0_16 Building tree for all the packages and classes... 34 warnings [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - /home/decherfb/tmp/searchCleaner/src/java/com//euromarketplace/search/cleaner/Configuration.java:13: package com..processframework.services does not exist import com..processframework.services.ServiceException; java.lang.NullPointerException at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) at com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) at com.sun.tools.javadoc.Main.main(Main.java:31) Command line was:/usr/java/jdk1.6.0_16/jre/../bin/javadoc @options @packages -- the @options doesn't have a correct classpath : the missing class is in an artifact A1.jar. In the pom, I have the dependency on A1.jar and A1-script.tgz (In this order). If I inverse the order of these dependencies, the site generation works! Do you have an idea on this bug ? Thanks, Benoit -- View this message in context: http://www.nabble.com/javadoc-generation-fails-only-during-site-generation-tp25508297p25641699.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: Multi-module build/dependency behavior?
No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.atwrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3-SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar, C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4.0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1.5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0\ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-api\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0.2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.jar, C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1.3.9\jsr305-1.3.9.jar, C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1.4.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0.3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanutils\1.6\commons-beanutils-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-codec\commons-codec\1.3\commons-codec-1.3.jar, C:\Users\steve.seagraves\.m2\repository\commons-configuration\commons-configuration\1.6\commons-configuration-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-lang\commons-lang\2.2\commons-lang-2.2.jar, C:\Users\steve.seagraves\.m2\repository\commons-digester\commons-digester\1.8\commons-digester-1.8.jar, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanutils-core\1.8.0\commons-beanutils-core-1.8.0.jar, C:\Users\steve.seagraves\.m2\repository\commons-dbcp\commons-dbcp\1.2.2\commons-dbcp-1.2.2.jar, C:\Users\steve.seagraves\.m2\repository\commons-pool\commons-pool\1.3\commons-pool-1.3.jar,
Re: Building Multiple Eclipse with Maven
On Sun September 27 2009 5:37:24 pm Jason van Zyl wrote: On 2009-09-27, at 2:08 PM, Roland Asmann wrote: Again, the way we work DOES have real workspace resolution. The maven-eclipse-plugin makes the projects in the reactor reference each other PER DEFAULT, and any other projects in the workspace if you tell it to. I just ran it on a project and that's not what it did. I'm not talking only about multi-module projects but other projects you may refer to. I'm often working on several related projects where I need to work with them all at the same time. I'm not trying to tell anybody not to use M2Eclipse or anything, I just want to state that it is not correct to say that you can't use the plugin if you want workspace resolution. For inter-project resolution it is. For intra-project (i.e. multi- module) is does. The maven-eclipse-plugin does a great job of wiring inter-project things together. If someone files a bug report with a maven based test case, it's great cause I just need to do mvn eclipse:eclipse and it's all wired up to the projects I already have in my workspace so debugging is quick and easy. That said, you DO need to tell it where your workspace is.You can use the -D flag on the command line if you want. For me, I added a activeProfile to my settings.xml: activeProfiles activeProfileextra/activeProfile /activeProfiles profile idextra/id properties eclipse.workspace/home/dkulp/working/workspace/eclipse.workspace /properties /profile So that the workspace location is always set and eclipse:eclipse can always find it. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module build/dependency behavior?
The behavior on system 2 is somehow wrong... Maybe it has something to do with the combination of Vista/Cygwin/Maven? At least make sure you have the same version of maven running and are using the same (or at least a compatible) settings.xml file... Not sure what else it could be, but imo the correct behavior is that of system 1. On Monday 28 September 2009 15:21, David Hoffer wrote: No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.atwrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 -SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar , C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis -1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. 0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. 1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. 5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. 0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 \ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j ar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap i\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0 .2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.j ar, C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1 .3.9\jsr305-1.3.9.jar, C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1. 4.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0 .3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanuti ls\1.6\commons-beanutils-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-logging\commons-logging\1 .1.1\commons-logging-1.1.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-collections\commons-colle ctions\3.1\commons-collections-3.1.jar, C:\Users\steve.seagraves\.m2\repository\commons-codec\commons-codec\1.3\c ommons-codec-1.3.jar, C:\Users\steve.seagraves\.m2\repository\commons-configuration\commons-con figuration\1.6\commons-configuration-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-lang\commons-lang\2.2\com mons-lang-2.2.jar,
Re: Multi-module build/dependency behavior?
Yeah, that combination is all I can come up with too for the cause of this bug. I'm waiting to hear back from the developer what version of maven he is using (I think 2.1) and then I'll create a JIRA for this. -Dave On Mon, Sep 28, 2009 at 8:08 AM, Roland Asmann roland.asm...@cfc.at wrote: The behavior on system 2 is somehow wrong... Maybe it has something to do with the combination of Vista/Cygwin/Maven? At least make sure you have the same version of maven running and are using the same (or at least a compatible) settings.xml file... Not sure what else it could be, but imo the correct behavior is that of system 1. On Monday 28 September 2009 15:21, David Hoffer wrote: No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.at wrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 -SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar , C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis -1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. 0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. 1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. 5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. 0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 \ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j ar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap i\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0 .2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.j ar, C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1 .3.9\jsr305-1.3.9.jar, C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1. 4.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0 .3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes, C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanuti ls\1.6\commons-beanutils-1.6.jar, C:\Users\steve.seagraves\.m2\repository\commons-logging\commons-logging\1
Re: Multi-module build/dependency behavior?
And like I said: compare the settings.xml files on both systems, maybe there's something different in there! On Monday 28 September 2009 16:14, David Hoffer wrote: Yeah, that combination is all I can come up with too for the cause of this bug. I'm waiting to hear back from the developer what version of maven he is using (I think 2.1) and then I'll create a JIRA for this. -Dave On Mon, Sep 28, 2009 at 8:08 AM, Roland Asmann roland.asm...@cfc.at wrote: The behavior on system 2 is somehow wrong... Maybe it has something to do with the combination of Vista/Cygwin/Maven? At least make sure you have the same version of maven running and are using the same (or at least a compatible) settings.xml file... Not sure what else it could be, but imo the correct behavior is that of system 1. On Monday 28 September 2009 15:21, David Hoffer wrote: No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.at wrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes , it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 -SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar , C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis -1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. 0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. 1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. 5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. 0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 \ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j ar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap i\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0 .2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.j ar, C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1 .3.9\jsr305-1.3.9.jar, C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1. 4.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0 .3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes ,
Re: Maven Central Repository - Cleanup Efforts
Filtering is already used for another Maven feature. To avoid ambiguity, we should better call the one what I defined: repository-skinning or repository-certification. Do you think this new feature would hurt the repo or any Maven user? On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz albert.kur...@gmail.com wrote: It is not necessary to create a new repo and it is not necessary to modify anything on Central or the policies how it is managed. Mess could be cleaned up virtually if I could attach a filter. In the ~/.m2/settings.xml for example, I should be able to add a list of repository addresses and for each of this repositories (which list could include the Central repo) I should be able to setup a URL of the filter which I would wanna use. Filter format could be for example the nexus repository index format. One example is here: http://repository.codehaus.org/.index/ My Maven client software should effectively hide artifacts from repositories (not only from Central) which artifacts have no reference on my selected filter index. Maven users have different needs, so they would sign up to different filters. Users would never loose faith of Central repo for its content. Only the index providers could be blamed for the garbage or for the missing artifacts, but this is highly unlikely, because they will maintain their index files by automated processes. It would be courteous from the current Maven Central maintainers if they provide a filter, which reflects the requirements what was originally made to get into Central: http://maven.apache.org/guides/mini/guide-central-repository-upload.html (but lots of things got in, which do not comply to this). On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter br...@apache.org wrote: On 27/09/2009, at 5:15 AM, Jason van Zyl wrote: Not having a super high quality central repository actually makes our commercial efforts a lot harder. If I was devious I would have agreed with Brett and would make a completely clean central repository as our plans require intact repositories. But we don't have a clean repository and trying to make a separate one would be a disaster for general use. You have to live with what's there and Sonatype will actually invest in cleaning up the generally available repository. We already have with efforts like this: http://nexus.sonatype.org/oss-repository-hosting.html Given this comment, I think you might have misunderstood my post on d...@... I was of the opinion that clean going forward makes sense, past stuff is still available, but working on ways to make Maven understand metadata changes so that you can actually fix things that go wrong. Some related themes have come up in this thread over the weekend, but I'll try and follow up on dev@ later with something more concrete. - Brett - 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: Removing dependency elements using profiles
don't want this dependency to be included in the final WAR. How can I tell Maven to exclude the dependency element for the overlay? The answer must be You can't remove dependencies via profiles, but you can adjust the scope (eg to provided) which has the effect of removing it. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 2 TestNG skipping some tests
I'm finding the TestNG plugin to be a bit flaky. For example I have a few
tests defined in a couple of classes and I wanted to add a new test class so
I created a new class:
package com.pingmenow.services;
import org.testng.annotations.Test;
public class DummyTest {
@Test
public void dummyTest() {
assert 1 == 2;
}
}
I saved this under src/test/java/com/pingmenow/services/DummyTest.java
(alongside my other test classes) but when I execute mvn test it skips this
class:
[INFO] Scanning for projects...
[INFO]
[INFO] Building pingmenow Tapestry 5 Application
[INFO]task-segment: [test]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 10 resources
[INFO] [javarebel:generate {execution: generate-rebel-xml}]
[INFO] Processing com.pingmenow:pingmenow with packaging war
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/Users/toby/Documents/workspace/pingmenow/target/surefire-reports
---
T E S T S
---
Running TestSuite
...
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.463 sec
Results :
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
[INFO] support.GenericApplicationContext Closing
org.springframework.context.support.genericapplicationcont...@af7c57:
display name
[org.springframework.context.support.genericapplicationcont...@af7c57];
startup date [Mon Sep 28 16:03:29 BST 2009]; root of context hierarchy
[INFO] support.DefaultListableBeanFactory Destroying singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@cbc2d3:
defining beans
[org.springframework.context.annotation.internalPersistenceAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,sessionFactory,hibernateTemplate,dataSource,transactionManager,org.springframework.aop.config.internalAutoProxyCreator,org.springframework.transaction.annotation.AnnotationTransactionAttributeSource#0,org.springframework.transaction.interceptor.TransactionInterceptor#0,org.springframework.transaction.config.internalTransactionAdvisor,propertyPlaceholderConfigurer,serverService];
root of factory hierarchy
[INFO] hibernate3.LocalSessionFactoryBean Closing Hibernate SessionFactory
[INFO] impl.SessionFactoryImpl closing
[INFO] hbm2ddl.SchemaExport Running hbm2ddl schema export
[INFO] hbm2ddl.SchemaExport exporting generated schema to database
[INFO] hbm2ddl.SchemaExport schema export complete
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Mon Sep 28 16:03:31 BST 2009
[INFO] Final Memory: 12M/22M
[INFO]
I'm running maven 2.2.0:
Apache Maven 2.2.0 (r788681; 2009-06-26 14:04:01+0100)
Java version: 1.5.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.5.8 arch: i386 Family: unix
My pom.xml looks like this:
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=
http://maven.apache.org/POM/4.0.0;
modelVersion4.0.0/modelVersion
groupIdcom.pingmenow/groupId
artifactIdpingmenow/artifactId
version1.0-SNAPSHOT/version
packagingwar/packaging
namepingmenow Tapestry 5 Application/name
dependencies
!--
A dependency on either JUnit or TestNG is required, or the
surefire
plugin (which runs the tests) will fail, preventing Maven from
packaging the WAR. Tapestry includes a large number of testing
facilities designed for use with TestNG (http://testng.org/), so
it's
recommended.
--
dependency
groupIdorg.testng/groupId
artifactIdtestng/artifactId
version5.8/version
classifierjdk15/classifier
scopetest/scope
Re: Maven Central Repository - Cleanup Efforts
Yes it would hurt. A build then becomes dependent on the certlist in order for it to function. In such a way, a cert list becomes directly equivalent to a repository definition in a pom.xml file. We do not allow repository definitions in pom files for a good reason. certlists is just another name for the same thing. By all means I see repository managers being able to use certlists... but these would be applied at the repository manager level and not at the settings.xml or at the pom.xml level. If you need a specific certlist in order to build correctly, then I do not think we should allow your new artifacts into central... and now certlists are a dead duck Just my opinion, Stephen 2009/9/28 Albert Kurucz albert.kur...@gmail.com Filtering is already used for another Maven feature. To avoid ambiguity, we should better call the one what I defined: repository-skinning or repository-certification. Do you think this new feature would hurt the repo or any Maven user? On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz albert.kur...@gmail.com wrote: It is not necessary to create a new repo and it is not necessary to modify anything on Central or the policies how it is managed. Mess could be cleaned up virtually if I could attach a filter. In the ~/.m2/settings.xml for example, I should be able to add a list of repository addresses and for each of this repositories (which list could include the Central repo) I should be able to setup a URL of the filter which I would wanna use. Filter format could be for example the nexus repository index format. One example is here: http://repository.codehaus.org/.index/ My Maven client software should effectively hide artifacts from repositories (not only from Central) which artifacts have no reference on my selected filter index. Maven users have different needs, so they would sign up to different filters. Users would never loose faith of Central repo for its content. Only the index providers could be blamed for the garbage or for the missing artifacts, but this is highly unlikely, because they will maintain their index files by automated processes. It would be courteous from the current Maven Central maintainers if they provide a filter, which reflects the requirements what was originally made to get into Central: http://maven.apache.org/guides/mini/guide-central-repository-upload.html (but lots of things got in, which do not comply to this). On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter br...@apache.org wrote: On 27/09/2009, at 5:15 AM, Jason van Zyl wrote: Not having a super high quality central repository actually makes our commercial efforts a lot harder. If I was devious I would have agreed with Brett and would make a completely clean central repository as our plans require intact repositories. But we don't have a clean repository and trying to make a separate one would be a disaster for general use. You have to live with what's there and Sonatype will actually invest in cleaning up the generally available repository. We already have with efforts like this: http://nexus.sonatype.org/oss-repository-hosting.html Given this comment, I think you might have misunderstood my post on dev@ ... I was of the opinion that clean going forward makes sense, past stuff is still available, but working on ways to make Maven understand metadata changes so that you can actually fix things that go wrong. Some related themes have come up in this thread over the weekend, but I'll try and follow up on dev@ later with something more concrete. - Brett - 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: Building Multiple Eclipse with Maven
On 2009-09-28, at 6:28 AM, Daniel Kulp wrote: On Sun September 27 2009 5:37:24 pm Jason van Zyl wrote: On 2009-09-27, at 2:08 PM, Roland Asmann wrote: Again, the way we work DOES have real workspace resolution. The maven-eclipse-plugin makes the projects in the reactor reference each other PER DEFAULT, and any other projects in the workspace if you tell it to. I just ran it on a project and that's not what it did. I'm not talking only about multi-module projects but other projects you may refer to. I'm often working on several related projects where I need to work with them all at the same time. I'm not trying to tell anybody not to use M2Eclipse or anything, I just want to state that it is not correct to say that you can't use the plugin if you want workspace resolution. For inter-project resolution it is. For intra-project (i.e. multi- module) is does. The problem is the default configuration. When I just ran it by default it does not linking, so the chances that a new user is going to get this right the first time is highly unlikely. These are the problems we run into. That said, I'm not saying don't use the maven-eclipse-plugin, I'm saying we're not going support it working with M2Eclipse. The workspace linking is only one of the potential interoperability problems. The maven-eclipse-plugin may do all sorts of things but if they require additional configuration and don't work by default the likelihood of success is greatly reduced. The maven-eclipse-plugin does a great job of wiring inter-project things together. If someone files a bug report with a maven based test case, it's great cause I just need to do mvn eclipse:eclipse and it's all wired up to the projects I already have in my workspace so debugging is quick and easy. That said, you DO need to tell it where your workspace is.You can use the -D flag on the command line if you want. For me, I added a activeProfile to my settings.xml: activeProfiles activeProfileextra/activeProfile /activeProfiles profile idextra/id properties eclipse.workspace/home/dkulp/working/workspace/ eclipse.workspace /properties /profile So that the workspace location is always set and eclipse:eclipse can always find it. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Any other flaws? A build then becomes dependent on the certlist in order for it to function. The project's build will not become dependent of the certlist. If it was able to build with certlist feature turned on, it will certainly build without the certlist. We do not allow repository definitions in pom files for a good reason. Repository definitions and certlist select would go to settings file, not to the pom. By all means I see repository managers being able to use certlists... Managers of different repositories will not need to become managers of certlists. but these would be applied at the repository manager level and not at the settings.xml or at the pom.xml level. No, these two tasks (maintaining a repo vs maintaining a certlist) should be separated. If you need a specific certlist in order to build correctly, You may need a specific certlist in order to maintain certain qualities of your development process. But you don't need a certlist for performing any builds. I do not think we should allow your new artifacts into central.. No new artifacts needed on central. All what is needed, a Maven client which respects my filter settings. and now certlists are a dead duck Give me a good reason why! On Mon, Sep 28, 2009 at 10:34 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yes it would hurt. In such a way, a cert list becomes directly equivalent to a repository definition in a pom.xml file. We do not allow repository definitions in pom files for a good reason. certlists is just another name for the same thing. By all means I see repository managers being able to use certlists... but these would be applied at the repository manager level and not at the settings.xml or at the pom.xml level. If you need a specific certlist in order to build correctly, then I do not think we should allow your new artifacts into central... and now certlists are a dead duck Just my opinion, Stephen 2009/9/28 Albert Kurucz albert.kur...@gmail.com Filtering is already used for another Maven feature. To avoid ambiguity, we should better call the one what I defined: repository-skinning or repository-certification. Do you think this new feature would hurt the repo or any Maven user? On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz albert.kur...@gmail.com wrote: It is not necessary to create a new repo and it is not necessary to modify anything on Central or the policies how it is managed. Mess could be cleaned up virtually if I could attach a filter. In the ~/.m2/settings.xml for example, I should be able to add a list of repository addresses and for each of this repositories (which list could include the Central repo) I should be able to setup a URL of the filter which I would wanna use. Filter format could be for example the nexus repository index format. One example is here: http://repository.codehaus.org/.index/ My Maven client software should effectively hide artifacts from repositories (not only from Central) which artifacts have no reference on my selected filter index. Maven users have different needs, so they would sign up to different filters. Users would never loose faith of Central repo for its content. Only the index providers could be blamed for the garbage or for the missing artifacts, but this is highly unlikely, because they will maintain their index files by automated processes. It would be courteous from the current Maven Central maintainers if they provide a filter, which reflects the requirements what was originally made to get into Central: http://maven.apache.org/guides/mini/guide-central-repository-upload.html (but lots of things got in, which do not comply to this). On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter br...@apache.org wrote: On 27/09/2009, at 5:15 AM, Jason van Zyl wrote: Not having a super high quality central repository actually makes our commercial efforts a lot harder. If I was devious I would have agreed with Brett and would make a completely clean central repository as our plans require intact repositories. But we don't have a clean repository and trying to make a separate one would be a disaster for general use. You have to live with what's there and Sonatype will actually invest in cleaning up the generally available repository. We already have with efforts like this: http://nexus.sonatype.org/oss-repository-hosting.html Given this comment, I think you might have misunderstood my post on dev@ ... I was of the opinion that clean going forward makes sense, past stuff is still available, but working on ways to make Maven understand metadata changes so that you can actually fix things that go wrong. Some related themes have come up in this thread over the weekend, but I'll try and follow up on dev@ later with something more concrete. - Brett -
Buildable standalone source bundles with the assembly plugin
Hi there, I was wondering if any maven-assembly-plugin experts could say whether this scenario is possible, or how much work it'd be to implement it. I need an archive that contains a complete buildable standalone project bundle. More specifically, it needs to contain: 1) the full SCM checkout of the main project 2) full SCM checkouts of all dependencies that match a groupId:artifactId pattern (i.e. internal projects) 3) a local repository containing the binaries for the unmatched dependencies (i.e. third-party projects) Ideally, this would then be buildable with a single Maven command by pointing the reactor to the checked-out projects and configuring the local repository accordingly. The nearest issue I could find was MASSEMBLY-125, which looks like it aims to overlay the project's and dependencies' sources into a single source-tree. I need separate directories per dependency since resource naming conflicts could exist. Any first impressions appreciated. Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module build/dependency behavior?
It turns out this is a bug with maven version 2.0.10. It works fine if the developer switches to 2.1 or 2.2.1. -Dave On Mon, Sep 28, 2009 at 8:31 AM, Roland Asmann roland.asm...@cfc.at wrote: And like I said: compare the settings.xml files on both systems, maybe there's something different in there! On Monday 28 September 2009 16:14, David Hoffer wrote: Yeah, that combination is all I can come up with too for the cause of this bug. I'm waiting to hear back from the developer what version of maven he is using (I think 2.1) and then I'll create a JIRA for this. -Dave On Mon, Sep 28, 2009 at 8:08 AM, Roland Asmann roland.asm...@cfc.at wrote: The behavior on system 2 is somehow wrong... Maybe it has something to do with the combination of Vista/Cygwin/Maven? At least make sure you have the same version of maven running and are using the same (or at least a compatible) settings.xml file... Not sure what else it could be, but imo the correct behavior is that of system 1. On Monday 28 September 2009 15:21, David Hoffer wrote: No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.at wrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes , it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 -SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar , C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis -1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. 0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. 1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. 5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. 0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 \ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j ar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap i\0.2\slf-service-api-0.2.jar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0 .2\java-commons-0.2.jar, C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.j ar,
Re: Maven Central Repository - Cleanup Efforts
On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz albert.kur...@gmail.com wrote: Any other flaws? A build then becomes dependent on the certlist in order for it to function. The project's build will not become dependent of the certlist. If it was able to build with certlist feature turned on, it will certainly build without the certlist. If the build at all depends on the cert list for proper resolution, then yes it is a defacto dependency of the build. In other words, if the resolution is at all different without the certlist than it is with it, then the build is dependent on it for proper resolution. If the certlist isn't required, then what value does it provide? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Shared log4j configuration - best practice?
Can you share an example pom for such a dependent project? I.e., if A depends on B, I'm curious how A imports the dependencies from B. Currently we're accomplishing something similar to this via war overlays, but perhaps that isn't the optimal solution. Thanks, Damon -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Sunday, September 27, 2009 7:55 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? Why don't you just create a submodule only containing that logging configuration (and possible other shared classpath resources) and make it a dependency of all the other modules? That's what we do. Kalle On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict pbened...@apache.org wrote: Brian, it just sounds awfully complex. A simple matter such as sharing a log4j.property at the root of a nested project shouldn't create so much work. Any other avenue? I am glad you shared this information. Paul On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox bri...@infinity.nu wrote: Something like this approach should work: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-project s-in-maven/ On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote: I find myself replicating the same log4j configuration in my Maven projects. It's a typical setup I want my projects to always use. Is there any good way to specify one in a parent POM for all child projects? Would the maven-remote-resources-plugin be useful for this? Paul - 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 Central Repository - Cleanup Efforts
One unwritten? rule of Maven good practice is that you change the undefined dependency version definitions to fixed versions before release. If you have done that, resolution will not be effected by certlist on or off status. The value (benefit) what certlist would provide to a Maven user, is that the user will not need to evaluate many artifact, which are not worth to spend time on looking at. This could result to saving our valuable spare time which we spend on contributing to different open source projects. On Mon, Sep 28, 2009 at 11:32 AM, Brian Fox bri...@infinity.nu wrote: On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz albert.kur...@gmail.com wrote: Any other flaws? A build then becomes dependent on the certlist in order for it to function. The project's build will not become dependent of the certlist. If it was able to build with certlist feature turned on, it will certainly build without the certlist. If the build at all depends on the cert list for proper resolution, then yes it is a defacto dependency of the build. In other words, if the resolution is at all different without the certlist than it is with it, then the build is dependent on it for proper resolution. If the certlist isn't required, then what value does it provide? - 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: Shared log4j configuration - best practice?
That's just how Maven works. If A depends upon B and B depends upon C, A depends upon C transitively. It's, of course, not always this simple because there are different dependency scopes. See the matrix in http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html. WAR overlays are used specifically (or should be IMHO) for servlet context resources. For classpath resources, just stick the files in a JAR and add it as a dependency. Justin -Original Message- From: Damon Silver [mailto:damon.sil...@diio.net] Sent: Monday, September 28, 2009 12:40 PM To: 'Maven Users List' Subject: RE: Shared log4j configuration - best practice? Can you share an example pom for such a dependent project? I.e., if A depends on B, I'm curious how A imports the dependencies from B. Currently we're accomplishing something similar to this via war overlays, but perhaps that isn't the optimal solution. Thanks, Damon -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Sunday, September 27, 2009 7:55 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? Why don't you just create a submodule only containing that logging configuration (and possible other shared classpath resources) and make it a dependency of all the other modules? That's what we do. Kalle On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict pbened...@apache.org wrote: Brian, it just sounds awfully complex. A simple matter such as sharing a log4j.property at the root of a nested project shouldn't create so much work. Any other avenue? I am glad you shared this information. Paul On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox bri...@infinity.nu wrote: Something like this approach should work: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-pro ject s-in-maven/ On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote: I find myself replicating the same log4j configuration in my Maven projects. It's a typical setup I want my projects to always use. Is there any good way to specify one in a parent POM for all child projects? Would the maven-remote-resources-plugin be useful for this? Paul - 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 Central Repository - Cleanup Efforts
Sorry for thread hijack, but was not able to resist... Another thing to think about, since it's adoption: On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We do not allow repository definitions in pom files for a good reason. This seemed as a good idea, but think about it. Why would you _not_ put reposes in POMs? Because they will be _burned_ in to your POMs forever and your URLs may change down the road? Why is this better: * having repository defs in POMs, thus providing at least some usable info that a developer may use as starting point and google it up/search/look for it (where it went, what it was, etc) then: * providing _no_ useful information in POMs for future generations? Having no trace in your _build_ about needed reposes... Ah yes, _both_ cases are easily handled by MRMs + grouping + mirrorOf, but in 2nd case, the one building may only shoot in the dark, you did not provide _any_ information from what did you build your stuff. Think about it. ~t~
Re: Maven Central Repository - Cleanup Efforts
I did not propose point system to describe the quality of repository alone, I thought of it just to be able to compare two different repositories... (ie. you find same thing in two of them, decide which one will you want to use, etc). But now I understand that this would provide a lot less value that I thought initially. The other item in my list was the list of \problematic\ or simply \unusable\ or \less then qualifiable\ _parts/GAVs/trees_ of repo itself and this sounds more like the deprecation someone proposed... ~t~ On Sun, Sep 27, 2009 at 7:41 PM, Benson Margulies bimargul...@gmail.comwrote: I agree that a point system is pointless.
Re: Multi-module build/dependency behavior?
Very strange... I use 2.0.10 and I've NEVER had this problem... I still think it's a configuration issue. Either because of CygWin or the settings file. I'll keep an eye open though, in case this starts to happen to me too! Roland It turns out this is a bug with maven version 2.0.10. It works fine if the developer switches to 2.1 or 2.2.1. -Dave On Mon, Sep 28, 2009 at 8:31 AM, Roland Asmann roland.asm...@cfc.at wrote: And like I said: compare the settings.xml files on both systems, maybe there's something different in there! On Monday 28 September 2009 16:14, David Hoffer wrote: Yeah, that combination is all I can come up with too for the cause of this bug. I'm waiting to hear back from the developer what version of maven he is using (I think 2.1) and then I'll create a JIRA for this. -Dave On Mon, Sep 28, 2009 at 8:08 AM, Roland Asmann roland.asm...@cfc.at wrote: The behavior on system 2 is somehow wrong... Maybe it has something to do with the combination of Vista/Cygwin/Maven? At least make sure you have the same version of maven running and are using the same (or at least a compatible) settings.xml file... Not sure what else it could be, but imo the correct behavior is that of system 1. On Monday 28 September 2009 15:21, David Hoffer wrote: No, the problem is with the compiler. Here is more details on what is happening: I have a parent pom that has two modules, A B. B depends on A. A depends on P which is a 3rd party jar with provided scope. The task of module A is to combine the contents of A P, this sum is the output of A. Now when we build this (clean install) at the parent pom on two systems we get two different behaviors. System 1: (XP w/ maven 2.1) Everything works as expected. The build of B depends on the final output jar of A in its target folder. I.e. with -X turned on I see its depending on .../target/A.jar System 2: (Vista, w/ cygwin, maven 2.?) Build fails. The build of B does not depend on the final output jar of A, rather it depends on A's target/classes folder. I.e. with -X turned on I see its depending on .../target/classes (Note the build fails here because the classes folder is not enough, it would also need the P dependency which is not available because it's scope is provided. The desired behavior is as system 1, where dependent builds depend on the final output of A.) Whey are these builds different? System 1 is the assumed correct behavior, right? Is this somehow configurable?? -Dave On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann roland.asm...@cfc.at wrote: And for what plugin is this? In a normal scenario, this could be the output in the project 'cdf-webtas-overrides' for the test-plugin (surefire-plugin). There could be others as well. This is normal, because the tests need your classes when being run... It always uses the classes from the current project + any and all dependencies from the local repository. If you still think this is wrong, please post a little more from the Maven log, this small excerpt unfortunately is not quite clear without more info! Roland That's right maven is looking for a dependency in taget/classes, see below for the log. The one I'm referring to is C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes , it should be referencing the jar, right? How can this happen? So far I have only seen this on the one system I described. -Dave [DEBUG] (f) classpathElements = [ C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 -SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar , C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis -1.0.b2.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. 0\xmlbeans-2.4.0.jar, C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. 1.jar, C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. 5.4\groovy-all-1.5.4.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. 0.jar, C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 \ant-launcher-1.7.0.jar, C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j ar, C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap
Re : Maven Central Repository - Cleanup Efforts
- Message d'origine De : Albert Kurucz albert.kur...@gmail.com À : Maven Users List users@maven.apache.org Envoyé le : Lundi, 28 Septembre 2009, 19h39mn 00s Objet : Re: Maven Central Repository - Cleanup Efforts Tamas, could explain MRMs + grouping + mirrorOf or send a link? http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html 2009/9/28 Tamás Cservenák : Sorry for thread hijack, but was not able to resist... Another thing to think about, since it's adoption: On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We do not allow definitions in pom files for a good reason. This seemed as a good idea, but think about it. Why would you _not_ put reposes in POMs? Because they will be _burned_ in to your POMs forever and your URLs may change down the road? Why is this better: * having repository defs in POMs, thus providing at least some usable info that a developer may use as starting point and google it up/search/look for it (where it went, what it was, etc) then: * providing _no_ useful information in POMs for future generations? Having no trace in your _build_ about needed reposes... Ah yes, _both_ cases are easily handled by MRMs + grouping + mirrorOf, but in 2nd case, the one building may only shoot in the dark, you did not provide _any_ information from what did you build your stuff. Think about it. ~t~ - 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: Shared log4j configuration - best practice?
For common images, say, are you putting those in a shared jar or in a war? If the former, how do you reference them at runtime? - Damon -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Monday, September 28, 2009 9:51 AM To: Maven Users List Subject: RE: Shared log4j configuration - best practice? That's just how Maven works. If A depends upon B and B depends upon C, A depends upon C transitively. It's, of course, not always this simple because there are different dependency scopes. See the matrix in http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html. WAR overlays are used specifically (or should be IMHO) for servlet context resources. For classpath resources, just stick the files in a JAR and add it as a dependency. Justin -Original Message- From: Damon Silver [mailto:damon.sil...@diio.net] Sent: Monday, September 28, 2009 12:40 PM To: 'Maven Users List' Subject: RE: Shared log4j configuration - best practice? Can you share an example pom for such a dependent project? I.e., if A depends on B, I'm curious how A imports the dependencies from B. Currently we're accomplishing something similar to this via war overlays, but perhaps that isn't the optimal solution. Thanks, Damon -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Sunday, September 27, 2009 7:55 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? Why don't you just create a submodule only containing that logging configuration (and possible other shared classpath resources) and make it a dependency of all the other modules? That's what we do. Kalle On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict pbened...@apache.org wrote: Brian, it just sounds awfully complex. A simple matter such as sharing a log4j.property at the root of a nested project shouldn't create so much work. Any other avenue? I am glad you shared this information. Paul On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox bri...@infinity.nu wrote: Something like this approach should work: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-pro ject s-in-maven/ On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote: I find myself replicating the same log4j configuration in my Maven projects. It's a typical setup I want my projects to always use. Is there any good way to specify one in a parent POM for all child projects? Would the maven-remote-resources-plugin be useful for this? Paul - 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: Shared log4j configuration - best practice?
I've done both, depending on the use case. But in general, an image is going to be a servlet context resource and thus is a reasonable use for war overlay. That said, an image certainly could be on the classpath and accessed with ClassLoader.getResourceAsStream(). On Sep 28, 2009, at 7:07 PM, Damon Silver damon.sil...@diio.net wrote: For common images, say, are you putting those in a shared jar or in a war? If the former, how do you reference them at runtime? - Damon -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Monday, September 28, 2009 9:51 AM To: Maven Users List Subject: RE: Shared log4j configuration - best practice? That's just how Maven works. If A depends upon B and B depends upon C, A depends upon C transitively. It's, of course, not always this simple because there are different dependency scopes. See the matrix in http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html. WAR overlays are used specifically (or should be IMHO) for servlet context resources. For classpath resources, just stick the files in a JAR and add it as a dependency. Justin -Original Message- From: Damon Silver [mailto:damon.sil...@diio.net] Sent: Monday, September 28, 2009 12:40 PM To: 'Maven Users List' Subject: RE: Shared log4j configuration - best practice? Can you share an example pom for such a dependent project? I.e., if A depends on B, I'm curious how A imports the dependencies from B. Currently we're accomplishing something similar to this via war overlays, but perhaps that isn't the optimal solution. Thanks, Damon -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Sunday, September 27, 2009 7:55 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? Why don't you just create a submodule only containing that logging configuration (and possible other shared classpath resources) and make it a dependency of all the other modules? That's what we do. Kalle On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict pbened...@apache.org wrote: Brian, it just sounds awfully complex. A simple matter such as sharing a log4j.property at the root of a nested project shouldn't create so much work. Any other avenue? I am glad you shared this information. Paul On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox bri...@infinity.nu wrote: Something like this approach should work: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-pro ject s-in-maven/ On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote: I find myself replicating the same log4j configuration in my Maven projects. It's a typical setup I want my projects to always use. Is there any good way to specify one in a parent POM for all child projects? Would the maven-remote-resources-plugin be useful for this? Paul --- -- 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 TestNG skipping some tests
On Tue, Sep 29, 2009 at 1:14 AM, Toby Hobson toby.hob...@googlemail.comwrote:
I'm finding the TestNG plugin to be a bit flaky. For example I have a few
tests defined in a couple of classes and I wanted to add a new test class
so
I created a new class:
package com.pingmenow.services;
import org.testng.annotations.Test;
public class DummyTest {
@Test
public void dummyTest() {
assert 1 == 2;
}
}
Is the JVM being run without assertions being enabled? Typically, unless
you provide the JVM the -ea command-line option, assertions are not used.
I've always used the org.testng.Assert class in testNG classes instead of
java assert keywords. This way it doesn't matter how the JVM is started.
Can you try that to confirm that the test is executing?
Hope this helps,
Ed
Re: Building Multiple Eclipse with Maven
On Mon, Sep 28, 2009 at 10:58 PM, Daniel Kulp dk...@apache.org wrote: That said, you DO need to tell it where your workspace is. You can use the -D flag on the command line if you want. For me, I added a activeProfile to my settings.xml: activeProfiles activeProfileextra/activeProfile /activeProfiles profile idextra/id properties eclipse.workspace/home/dkulp/working/workspace/eclipse.workspace /properties /profile That's neat. I've always been wondering how I can have custom flags for non-lifecycle plugins. I'm off to tinker with downloadJavadocs and downloadSources on as default... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Shared log4j configuration - best practice?
This piques my curiosity because I find that having added multiple war overlays to our trunk has slowed down the build time required considerably. Has anyone else experienced this? - Damon -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Monday, September 28, 2009 4:17 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? I've done both, depending on the use case. But in general, an image is going to be a servlet context resource and thus is a reasonable use for war overlay. That said, an image certainly could be on the classpath and accessed with ClassLoader.getResourceAsStream(). On Sep 28, 2009, at 7:07 PM, Damon Silver damon.sil...@diio.net wrote: For common images, say, are you putting those in a shared jar or in a war? If the former, how do you reference them at runtime? - Damon -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Monday, September 28, 2009 9:51 AM To: Maven Users List Subject: RE: Shared log4j configuration - best practice? That's just how Maven works. If A depends upon B and B depends upon C, A depends upon C transitively. It's, of course, not always this simple because there are different dependency scopes. See the matrix in http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html. WAR overlays are used specifically (or should be IMHO) for servlet context resources. For classpath resources, just stick the files in a JAR and add it as a dependency. Justin -Original Message- From: Damon Silver [mailto:damon.sil...@diio.net] Sent: Monday, September 28, 2009 12:40 PM To: 'Maven Users List' Subject: RE: Shared log4j configuration - best practice? Can you share an example pom for such a dependent project? I.e., if A depends on B, I'm curious how A imports the dependencies from B. Currently we're accomplishing something similar to this via war overlays, but perhaps that isn't the optimal solution. Thanks, Damon -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Sunday, September 27, 2009 7:55 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? Why don't you just create a submodule only containing that logging configuration (and possible other shared classpath resources) and make it a dependency of all the other modules? That's what we do. Kalle On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict pbened...@apache.org wrote: Brian, it just sounds awfully complex. A simple matter such as sharing a log4j.property at the root of a nested project shouldn't create so much work. Any other avenue? I am glad you shared this information. Paul On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox bri...@infinity.nu wrote: Something like this approach should work: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-pro ject s-in-maven/ On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote: I find myself replicating the same log4j configuration in my Maven projects. It's a typical setup I want my projects to always use. Is there any good way to specify one in a parent POM for all child projects? Would the maven-remote-resources-plugin be useful for this? Paul --- -- 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 - 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
M2Eclipse 0.9.9.200909092308 - Maven Project builder is running endless
Hi, Do you know how to stop M2Ecklipse Project builder from running in all the time? As soon as it reaches the end it starts from begin with info: Maven Builder: AUTO_BUILD requireFullBuild I get each time this warning 29/09/09 12:50:27 PM: [WARN] 'reporting.plugins.plugin.version' is missing for org.apache.maven.plugins:maven-javadoc-plugin @ ... which seems to come from Maven 3.0 snaphot used from the builder (I want it to use Maven 2.0 as long as this isn't fixed - or how do I fix it?) Cheers, Kai
Re: maven snapshot dependencies and recompilation
Comments below... Hi, My question is similar to this one: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/browser but for maven 2.0.9 - 2.2.1. I have two projects A and B. B is dependent upon A. A produces A-1.0-SNAPSHOT.jar. When a change is introduced into A and the new snapshot is installed into the local repository, B is not fully recompiled unless clean is specified when building B. This means that if an interface is changed in A, B will not be recompiled against the changed interface. Is there something wrong with my configuration? If not, what is accepted practice? Manually doing a clean whenever a change in snapshot is detected seems inefficient and error-prone. mvn clean compile -- maven will do clean operaion before the comile I understand that mvn clean compile will do what is required. However, this means that whenever there is the possibility of snapshots being updated (ie. mvn -U or manual compilation of a dependent project) that the clean target should be invoked. I was hoping that maven would be intelligent enough to determine that a dependent jar had changed and be able to automatically do a clean. Is this not possible? Thanks, Dan.
Re: How invoke itblast plugin two times for two different databases?
Well, -D won't do anything, but -P will...can you try
-Prun_tests_oracle,run_tests_sqlserver?
Don
On Tue, Aug 4, 2009 at 6:13 PM, Nafter hdo...@allshare.nl wrote:
When I make a build at the end the maven-itblast-plugin is used to kick off
Junit tests.
This is working just fine.
However I would like to run the same set of JUnit tests against an other db
vendor as well.
In fact the Junit tests should be executed on a Oracle database but also on
a SQL server database.
At the moment I'm trying to invoke the maven-itblast-plugin two times, but
this is only executed once.
I call the build by passing the following profile options:
-e clean install -Drun_tests_oracle -Drun_tests_sqlserver
Does somebody know how to really invoke the Unittests twice using the
maven-itblast-plugin?
See below how the -Drun_tests_oracle -Drun_tests_sqlserver are being
configured.
!-- RUN ACTUAL JUNIT TESTS [ORACLE] --
profile
idrun_tests_oracle_id/id
activation
property
namerun_tests_oracle/name
/property
/activation
build
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
version1.0-beta-2/version
configuration
!-- Container configuration --
container
containerIdjboss42x/containerId
home${JBOSS__HOME}/home
/container
!-- Configuration to use with the container --
configuration
typestandalone/type
home${JBOSS__HOME}/server/default/home
properties
!--cargo.rmi.port${JBOSS_PORT__RMI}/cargo.rmi.port--
cargo.jvmargs${VMARGS__TEST_PROPERTY_FILE_ORACLE}/cargo.jvmargs
/properties
/configuration
/configuration
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
skipfalse/skip
argLine${VMARGS__TEST_PROPERTY_FILE_ORACLE}/argLine
testFailureIgnorefalse/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.twdata.maven/groupId
artifactIdmaven-itblast-plugin/artifactId
version0.5/version
executions
execution
phaseverify/phase
goals
goalexecute/goal
/goals
configuration
containersjboss42x/containers
httpPort${JBOSS_PORT__HTTP}/httpPort
rmiPort${JBOSS_PORT__RMI}/rmiPort
functionalTestPattern${JUNIT__TEST_PATTERN}/functionalTestPattern
systemProperties/systemProperties
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
!-- RUN ACTUAL JUNIT TESTS [SQL SERVER] --
profile
idrun_tests_sqlserver_id/id
activation
property
namerun_tests_sqlserver/name
/property
/activation
build
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
version1.0-beta-2/version
configuration
!-- Container configuration --
container
containerIdjboss42x/containerId
home${JBOSS__HOME}/home
/container
!-- Configuration to use with the container --
configuration
typestandalone/type
home${JBOSS__HOME}/server/default/home
properties
!--cargo.rmi.port${JBOSS_PORT__RMI}/cargo.rmi.port--
cargo.jvmargs${VMARGS__TEST_PROPERTY_FILE_SQLSERVER}/cargo.jvmargs
/properties
/configuration
/configuration
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
skipfalse/skip
argLine${VMARGS__TEST_PROPERTY_FILE_SQLSERVER}/argLine
testFailureIgnorefalse/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.twdata.maven/groupId
artifactIdmaven-itblast-plugin/artifactId
version0.5/version
executions
execution
phaseverify/phase
goals
goalexecute/goal
/goals
configuration
containersjboss42x/containers
httpPort${JBOSS_PORT__HTTP}/httpPort
rmiPort${JBOSS_PORT__RMI}/rmiPort
functionalTestPattern${JUNIT__TEST_PATTERN}/functionalTestPattern
systemProperties/systemProperties
/configuration
/execution
Re: How invoke itblast plugin two times for two different databases?
Doh, nm, didn't see the profiles were activated by a property.
itblast has to do some rather unseemly stuff to get Cargo to run
twice, once for startup and once for shutdown. It is possible itblast
doesn't completely clear out state on shutdown. I'd recommend running
mvnDebug and stepping through to see what is going on.
Don
On Tue, Sep 29, 2009 at 3:22 PM, Don Brown donald.br...@gmail.com wrote:
Well, -D won't do anything, but -P will...can you try
-Prun_tests_oracle,run_tests_sqlserver?
Don
On Tue, Aug 4, 2009 at 6:13 PM, Nafter hdo...@allshare.nl wrote:
When I make a build at the end the maven-itblast-plugin is used to kick off
Junit tests.
This is working just fine.
However I would like to run the same set of JUnit tests against an other db
vendor as well.
In fact the Junit tests should be executed on a Oracle database but also on
a SQL server database.
At the moment I'm trying to invoke the maven-itblast-plugin two times, but
this is only executed once.
I call the build by passing the following profile options:
-e clean install -Drun_tests_oracle -Drun_tests_sqlserver
Does somebody know how to really invoke the Unittests twice using the
maven-itblast-plugin?
See below how the -Drun_tests_oracle -Drun_tests_sqlserver are being
configured.
!-- RUN ACTUAL JUNIT TESTS [ORACLE] --
profile
idrun_tests_oracle_id/id
activation
property
namerun_tests_oracle/name
/property
/activation
build
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
version1.0-beta-2/version
configuration
!-- Container configuration --
container
containerIdjboss42x/containerId
home${JBOSS__HOME}/home
/container
!-- Configuration to use with the container --
configuration
typestandalone/type
home${JBOSS__HOME}/server/default/home
properties
!--cargo.rmi.port${JBOSS_PORT__RMI}/cargo.rmi.port--
cargo.jvmargs${VMARGS__TEST_PROPERTY_FILE_ORACLE}/cargo.jvmargs
/properties
/configuration
/configuration
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
skipfalse/skip
argLine${VMARGS__TEST_PROPERTY_FILE_ORACLE}/argLine
testFailureIgnorefalse/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.twdata.maven/groupId
artifactIdmaven-itblast-plugin/artifactId
version0.5/version
executions
execution
phaseverify/phase
goals
goalexecute/goal
/goals
configuration
containersjboss42x/containers
httpPort${JBOSS_PORT__HTTP}/httpPort
rmiPort${JBOSS_PORT__RMI}/rmiPort
functionalTestPattern${JUNIT__TEST_PATTERN}/functionalTestPattern
systemProperties/systemProperties
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
!-- RUN ACTUAL JUNIT TESTS [SQL SERVER] --
profile
idrun_tests_sqlserver_id/id
activation
property
namerun_tests_sqlserver/name
/property
/activation
build
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
version1.0-beta-2/version
configuration
!-- Container configuration --
container
containerIdjboss42x/containerId
home${JBOSS__HOME}/home
/container
!-- Configuration to use with the container --
configuration
typestandalone/type
home${JBOSS__HOME}/server/default/home
properties
!--cargo.rmi.port${JBOSS_PORT__RMI}/cargo.rmi.port--
cargo.jvmargs${VMARGS__TEST_PROPERTY_FILE_SQLSERVER}/cargo.jvmargs
/properties
/configuration
/configuration
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
skipfalse/skip
argLine${VMARGS__TEST_PROPERTY_FILE_SQLSERVER}/argLine
testFailureIgnorefalse/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.twdata.maven/groupId
artifactIdmaven-itblast-plugin/artifactId
version0.5/version
executions
execution
phaseverify/phase
goals
