Re: Getting log4j output from ANT tasks to maven output
ez wrote: > > instead i get this: > log4j:WARN No appenders could be found for logger > (com.i18n.Excel2Properties). > log4j:WARN Please initialize the log4j system properly. > The warning is because the log4j.properties or log4j.xml is not present in the classpath. Where have you placed it? -- View this message in context: http://www.nabble.com/Getting-log4j-output-from-ANT-tasks-to-maven-output-tp21558678p21598939.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: FW: Failed to resolve artifact
Varini H.P. wrote: > > > GroupId: org.apache.maven.plugins > ArtifactId: maven-compiler-plugin > Version: 2.0.2 > > Reason: Unable to download the artifact from any repository > > org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2 > > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > java.net (http://download.java.net/maven/1/) > Strange. I just tried accessing http://repo1.maven.org/maven2 and it automatically redirected me to http://repo2.maven.org/maven2 So try adding http://repo2.maven.org/maven2 to the list of repositories in your settings.xml -- View this message in context: http://www.nabble.com/FW%3A-Failed-to-resolve-artifact-tp21579179p21598922.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: Passing system properties to JUnit using "-D" on Linux
Being discussed here http://www.nabble.com/Passing-system-properties-to-JUnit-tests-using-%22-D%22-on-Linux-td21593651.html -- View this message in context: http://www.nabble.com/Passing-system-properties-to-JUnit-using-%22-D%22-on-Linux-tp21593649p21598861.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: Passing system properties to JUnit using "-D" on Linux
Being discussed in your other post here http://www.nabble.com/Passing-system-properties-to-JUnit-tests-using-%22-D%22-on-Linux-td21593651.html -- View this message in context: http://www.nabble.com/Passing-system-properties-to-JUnit-using-%22-D%22-on-Linux-tp21593647p21598856.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: Passing system properties to JUnit tests using "-D" on Linux
james_d wrote:
>
> However, I noticed that when I run my build on Linux that the properties
> are not available. Specifically, calling System.getProperty("key1")
> returns null. What's going on? I'm using maven 2.0.9 for both.
>
The OS shouldn't matter, it should have worked. Please post the exact
command that you are using and the piece of code where you using this
property. Also post the output of
mvn -version
--
View this message in context:
http://www.nabble.com/Passing-system-properties-to-JUnit-tests-using-%22-D%22-on-Linux-tp21593651p21598842.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: hibernate3-maven-plugin Error
Jean-Philippe Steinmetz-3 wrote: > > The odd thing about this is that I have a persistence.xml at the path > src/main/java/META-INF/persistence.xml. I guess you should place it in src/main/resources/META-INF/persistence.xml -- View this message in context: http://www.nabble.com/hibernate3-maven-plugin-Error-tp21579183p21598817.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: Can the maven-upload-plugin be used in a open source project?
David, Tim and Dan - extremely sorry about this delayed reply. I actually read these replies immediately when you posted but since it was too late in the night, i just rushed home with replying and forgot about this until today :) David and Tim, thanks for explaining the licenses to me - that helped. Dan, thanks for pointing me to the moved plugin. I will give it a try. -- View this message in context: http://www.nabble.com/Can-the-maven-upload-plugin-be-used-in-a-open-source-project--tp21543256p21598800.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: Maven inheritence works with 2.1-SNAPSHOT but not with 2.0.9
Don't mean to interrupt but mine is using pom packaging and inheritance does
not work with 2.0.9. Is this a known issue?
FYI - I'm basically using Michael Yuan's seam parent example located here:
http://www.michaelyuan.com/blog/2007/10/09/jboss-seam-project-setup-with-maven-%E2%80%94-part-2-ear-deployment/
http://www.michaelyuan.com/blog/2007/10/09/jboss-seam-project-setup-with-maven-%E2%80%94-part-2-ear-deployment/
With the parent element in *my* main pom being:
org.jboss.seam
root
2.1.1.GA
Would this create an issue?
Thanks
Brian E Fox wrote:
>
> You found a bug in 2.1-SNAPSHOT. The parents must be pom packaging types.
>
> If you want to share checkstyle, just bundle it into a jar with assembly,
> and then you can add that jar as a dependency to your checkstyle config.
> You
> don't need to inherit from the checkstyle jar itself, Checkstyle will find
> the xml on the classpath. I wrote some examples about this here:
> http://blogs.sonatype.com/people/2008/04/how-to-share-resources-across-proje
> cts-in-maven/
>
> http://blogs.sonatype.com/people/2008/04/how-to-override-a-plugins-dependenc
> y-in-maven/
>
> --Brian
>
> On 1/20/09 8:03 AM, "kukudas" wrote:
>
>> Hi,
>>
>> i have a problem and i hope somebody can help me. I'm kinda new to this
>> things so maybe my approach is generaly wrong.
>>
>> i'm having a parent for example like this:
>>
>> 4.0.0
>> org.test
>> parent
>> 1
>>
>>
>> org.apache.maven.plugins
>> maven-checkstyle-plugin
>>
>>
>> ${pom.parent.groupId}
>> ${pom.parent.artifactId}
>> ${pom.parent.version}
>>
>>
>>
>>
>>
>> org.apache.maven.plugins
>> maven-checkstyle-plugin
>>
>> checkstyle.xml
>>
>>
>>
>>
>>
>>
>> And a child like this:
>>
>>
>> org.test
>> parent
>> 1
>>
>>
>> 4.0.0
>> org.test
>> child
>>
>> When i use Maven 2.0.9 i get the error that parent packaging has to be
>> pom.
>> But it has to be jar so my child can access the checkstyle.xml which is
>> in
>> the parent projects resource folder.
>> With Maven 2.1-SNAPSHOT it works as expected (checkstyle runs with my
>> rules
>> which are in the parents resource folder). Is there maybe a better way to
>> solve this or somehow make it work with both versions? I don't want to
>> use
>> packaging jar, run clean install for my parent and then change it to pom
>> so
>> that it will work with 2.0.9.
>>
>>
>> Thanks in advance
>>
>> kukudas
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Maven-inheritence-works-with-2.1-SNAPSHOT-but-not-with-2.0.9-tp21562721p21598594.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
Error when executing "mvn eclipse:clean eclipse:eclipse"
This is not at all urgent for me as I don't get an error if I just execute each goal separately, but I thought this might be something the developers would want to know about. $ mvn -v /usr/lib/jvm/java Maven version: 2.0.7 Java version: 1.6.0_03 OS name: "linux" version: "2.6.18-92.1.6.el5" arch: "i386" $ rm -Rf ~/.m2/repository $ mvn archetype:create -DgroupId=foo -DartifactId=bar ... Build Successful $ cd bar $ mvn -e eclipse:clean eclipse:eclipse Gives me this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-eclipse-plugin:2.5.1:eclipse': Unable to find the mojo 'org.apache.m aven.plugins:maven-eclipse-plugin:2.5.1:eclipse' in the plugin 'org.apache.maven.plugins:maven-eclipse-plugin' org/codehaus/plexus/resource/loader/ResourceNotFoundException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-eclipse-plugin:2.5. 1:eclipse': Unable to find the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5.1:eclipse' in the plugin 'org.apache.maven.plugins:maven-eclipse-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5.1:eclipse' in the plugin 'org.apache.maven.plugins:maven-eclipse-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.mave n.plugins:maven-eclipse-plugin:2.5.1:eclipse', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) ... 18 more Caused by: org.codehaus.plexus.component.factory.ComponentInstantiationException: Could not instanciate component: role: 'null', implementation: 'org.apache.ma ven.plugin.eclipse.EclipsePlugin' at org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactory.java:77) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:62) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) ... 20 more Caused by: java.lang.NoClassDefFoundError: org/codehaus/plexus/resource/loader/Re
How do you clean the site files from the deploy location?
Hello, I am using the site plugin to publish the reports for my project to a local web server. I am able to get it to deploy correctly, but I noticed that it does not deploy cleanly. 1) It does not clean out what was already there. I found maven 1.x had a maven.site.deploy.clean property, but this does not work in maven 2.x. 2) It copies the site information for the projects as it is building so the site has broken links until the build is complete. What is the recommended way to handle these issues with the current plugin? Thanks, Todd
Re: Iterating through a files using maven plugin
Would referencing it as a in your POM and allowing it to bind by default to the generate-sources phase work, rather than running the individual mojo? Brett On Thu, Jan 22, 2009 at 4:49 PM, arve wrote: > > hi, > I run a maven task mvn appfuse:gen -Dentity=Pojo name. > if i have 100 pojos in a folder i have to run the same command 100 times. > Instead is there some plugin/trick whcih could iterate the same command > with > different pojo names with a single command? > -- > View this message in context: > http://www.nabble.com/Iterating-through-a-files-using-maven-plugin-tp21598334p21598334.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 > >
Iterating through a files using maven plugin
hi, I run a maven task mvn appfuse:gen -Dentity=Pojo name. if i have 100 pojos in a folder i have to run the same command 100 times. Instead is there some plugin/trick whcih could iterate the same command with different pojo names with a single command? -- View this message in context: http://www.nabble.com/Iterating-through-a-files-using-maven-plugin-tp21598334p21598334.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: [SORRY FOR SPAMMING] hibernate 3 maven plugin
+1 for the display of a good release process. On Wed, Jan 21, 2009 at 3:07 PM, Siegfried Goeschl wrote: > Shows that your release process is properly set up ... ;-) > > Siegfried Goeschl > > da...@davidkarlsen.com wrote: >> >> Sorry for spamming you all - I ran this on the top level artifact and >> should of course only have done that on the plugin. >> >> Sorry - here's my 4th mail to you on the subject today. :-I >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
"inverse" depencency tree
Hi, I am aware that I can get Maven to build me a dependency tree for a given project of mine and that is fine. Is there any way to get help with generating the broader dependency tree? Let me clarify. In my organization we have a lot of multi module applications. Some applications refer to each other but information about these dependencies are spread aorund in different pom.xml files. We would like to have this larger dependency tree documented centrally (for example as automatically generated report), so that an application owner can look at this report and see which other applications are using his software. Is there any tooling that can help me with that or do I have to code it myself. Best regards M. Hansen
Passing system properties to JUnit tests using "-D" on Linux
When I compile/test my software on Windows any -D system properties I
specify on the command line (e.g., mvn clean install -Dkey1=value1) are
available inside my JUnit tests by calling the System.getProperty() method
(e.g., System.getProperty("key1") returns "value1").
However, I noticed that when I run my build on Linux that the properties are
not available. Specifically, calling System.getProperty("key1") returns
null. What's going on? I'm using maven 2.0.9 for both.
Thanks for the help!
--
View this message in context:
http://www.nabble.com/Passing-system-properties-to-JUnit-tests-using-%22-D%22-on-Linux-tp21593651p21593651.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
Passing system properties to JUnit using "-D" on Linux
When I compile/test my software on Windows any -D system properties I
specify on the command line (e.g., mvn clean install -Dkey1=value1) are
available inside my JUnit tests by calling the System.getProperty() method
(e.g., System.getProperty("key1") returns "value1").
However, I noticed that when I run my build on Linux that the properties are
not available. Specifically, calling System.getProperty("key1") returns
null. What's going on? I'm using maven 2.0.9 for both.
Thanks for the help!
--
View this message in context:
http://www.nabble.com/Passing-system-properties-to-JUnit-using-%22-D%22-on-Linux-tp21593649p21593649.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
Passing system properties to JUnit using "-D" on Linux
When I compile/test my software on Windows any -D system properties I
specify on the command line (e.g., mvn clean install -Dkey1=value1) are
available inside my JUnit tests by calling the System.getProperty() method
(e.g., System.getProperty("key1") returns "value1").
However, I noticed that when I run my build on Linux that the properties are
not available. Specifically, calling System.getProperty("key1") returns
null. What's going on? I'm using maven 2.0.9 for both.
Thanks for the help!
--
View this message in context:
http://www.nabble.com/Passing-system-properties-to-JUnit-using-%22-D%22-on-Linux-tp21593647p21593647.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: [SORRY FOR SPAMMING] hibernate 3 maven plugin
Shows that your release process is properly set up ... ;-) Siegfried Goeschl da...@davidkarlsen.com wrote: > > Sorry for spamming you all - I ran this on the top level artifact and > should of course only have done that on the plugin. > > Sorry - here's my 4th mail to you on the subject today. :-I > > -- > David J. M. Karlsen - +47 90 68 22 43 > http://www.davidkarlsen.com > http://mp3.davidkarlsen.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Configuration by exception?
When I define a dependency do I really need to arduously and decoratively exclude each of it's dependencies? Naturally I'd rather just say don't include any dependencies except these... Thanks -- View this message in context: http://www.nabble.com/Configuration-by-exception--tp21592144p21592144.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to specify conflicting versions in Maven?
I wonder if OSGi would help (for example, Apache Felix)? It might help at runtime, but I don't know if it would help with the maven builds. Perhaps the Apache Felix documentation offers suggestions when using maven. Martin Kacer wrote: Simple but not always true. First, the fact that EXTENDED depends on BASIC is an internal issue of the EXTENDED library. Future versions may not depend on it and top-level projects should not be aware of the dependency. Second, the conflict may also occur between projects (libraries) without a direct dependecy. Imagine we have two optional modules, each of them may be used separately by a top-level project. But if both of them are used together, there are some limits on version numbers (such as, module A will not work with B of version smaller than 2.0). Martin On Wed, 21 Jan 2009, Jeff MAURY wrote: # If EXTENDED depends on BASIC, then your POM user should only declare # EXTENDED as a dependency and not BASIC. # # Jeff MAURY # # On Tue, Jan 20, 2009 at 9:02 PM, Martin Kacer wrote: # # > Hi there, # > # > I am wondering whether it is possible to specify that some existing JAR # > version will NOT work with my artifact (library), though it is not my # > own dependency. # > # > Let me illustrate the problem by a very simplified example: # > We have two libraries, both managed by Maven: Library 1 is called BASIC and # > provides some common utilities used in many other projects. # > Library 2 is called EXTENDED and it depends on BASIC because it uses # > those utilities. # > # > Both libraries exist in many versions: 1.0, 1.1, etc. In a repository, # > we have various jar artifacts (such as BASIC-1.4.jar, EXTENDED-1.2.jar # > etc.) and also POM files specifying dependencies between them. For example, # > EXTENDED-1.2.pom defines a dependency on artifactId="BASIC", # > version="[1.0,)". # > # > After some time, I decide to release a new version of BASIC, numbered 2.0. # > Unfortunately, there is an incompatible change in the library API that will # > cause the EXTENDED library version 1.x to stop working. Therefore, # > I also have to release a new version of EXTENDED: EXTENDED-2.0.jar. # > # > Is there some way to specify that BASIC-2.0 will _not_ work with EXTENDED # > version < 2.0? In other words, I want to prevent top projects from declaring # > something like: # > # > # > BASIC2.0 # > # > EXTENDED1.2 # > # > Of course, the conflict could be specified in the POM of EXTENDED 1.2. # > But it was not known in the time of 1.2 release yet. # > # > # > Sorry if I overlooked something, but I was not able to find this in the # > Maven documentation and it is a crucial feature for me. # > # > Thanks for any help... # > Martin Kacer # > # > - # > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org # > For additional commands, e-mail: users-h...@maven.apache.org # > # > # # # -- # La mélancolie c'est communiste # Tout le monde y a droit de temps en temps # La mélancolie n'est pas capitaliste # C'est m?me gratuit pour les perdants # La mélancolie c'est pacifiste # On ne lui rentre jamais dedans # La mélancolie oh tu sais ça existe # Elle se prend m?me avec des gants # La mélancolie c'est pour les syndicalistes # Il faut juste sa carte de permanent # # Miossec (2006) # # http://www.jeffmaury.com # http://riadiscuss.jeffmaury.com # http://www.lastfm.fr/listen/user/jeffmaury/personal # Mes CDs ? récupérer: # http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en # - 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
[SORRY FOR SPAMMING] hibernate 3 maven plugin
Sorry for spamming you all - I ran this on the top level artifact and should of course only have done that on the plugin. Sorry - here's my 4th mail to you on the subject today. :-I -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Hibernate3 Maven Plugin 2.2 released
The Hibernate3 Maven Plugin team is pleased to announce the hibernate3-maven-plugin-2.2 release! Maven plugin based on the hibernate-tools project. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the hibernate3-maven-plugin-2.2 here: http://mojo.codehaus.org/hibernate3/hibernate3-maven-plugin Have fun! -Hibernate3 Maven Plugin team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Maven Hibernate3 Implementation - JDK15 2.2 released
The Maven Hibernate3 Implementation - JDK15 team is pleased to announce the maven-hibernate3-jdk15-2.2 release! Hibernate 3 Maven 2 Integration. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the maven-hibernate3-jdk15-2.2 here: http://mojo.codehaus.org/hibernate3/maven-hibernate3-components/maven-hibernate3-jdk15 Have fun! -Maven Hibernate3 Implementation - JDK15 team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Maven Hibernate3 Implementation - JDK14 2.2 released
The Maven Hibernate3 Implementation - JDK14 team is pleased to announce the maven-hibernate3-jdk14-2.2 release! Hibernate 3 Maven 2 Integration. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the maven-hibernate3-jdk14-2.2 here: http://mojo.codehaus.org/hibernate3/maven-hibernate3-components/maven-hibernate3-jdk14 Have fun! -Maven Hibernate3 Implementation - JDK14 team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Maven Hibernate3 Components 2.2 released
The Maven Hibernate3 Components team is pleased to announce the maven-hibernate3-components-2.2 release! Hibernate 3 Maven 2 Integration. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the maven-hibernate3-components-2.2 here: http://mojo.codehaus.org/hibernate3/maven-hibernate3-components Have fun! -Maven Hibernate3 Components team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Maven Hibernate3 API 2.2 released
The Maven Hibernate3 API team is pleased to announce the maven-hibernate3-api-2.2 release! Hibernate 3 Maven 2 Integration. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the maven-hibernate3-api-2.2 here: http://mojo.codehaus.org/hibernate3/maven-hibernate3-api Have fun! -Maven Hibernate3 API team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCEMENT] - Hibernate 3 Maven 2 Integration 2.2 released
The Hibernate 3 Maven 2 Integration team is pleased to announce the maven-hibernate3-2.2 release! Hibernate 3 Maven 2 Integration. Changes in this version include: Fixed Bugs: o slf4j exception on build Issue: MHIBERNATE-88. o Generated sources not compiling Issue: MHIBERNATE-86. o Duplicate/Unwanted adding of the outputDirectory to the compileSourceRoot Issue: MHIBERNATE-84. o ClassNotFoundException with hbm2java Issue: MHIBERNATE-83. o Fatal Error with jcl-over-slf4j Issue: MHIBERNATE-81. o component properties configuration "templatepath" ist not recognized correctly Issue: MHIBERNATE-77. o DuplicateMappingException: Duplicate class/entity mapping Issue: MHIBERNATE-75. Changes: o Plugin must use latest Hibernate version 3.3 Issue: MHIBERNATE-82. o Docs: default value for 'update' Issue: MHIBERNATE-79. o Docs: refer to component properties page from parameter detail documentation Issue: MHIBERNATE-78. For a manual installation, you can download the maven-hibernate3-2.2 here: http://mojo.codehaus.org/hibernate3/ Have fun! -Hibernate 3 Maven 2 Integration team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Exclude plugin dependency defined in parent pom?
Addendum: I know that we can turn WTP off by overriding the configuration. I was just wondering if there is a way to exclude the plugin in the child pom to prevent any other compatibility issues that may arise. -Original Message- From: Hoover, William [mailto:whoo...@nemours.org] Sent: Wednesday, January 21, 2009 1:24 PM To: users@maven.apache.org Subject: Exclude plugin dependency defined in parent pom? Is there a way to Exclude a plugin dependency declared in a parent pom? We have an enterprise level pom that turns WTP capabilities by default: org.apache.maven.plugins maven-eclipse-plugin true true 2.0 The problem is that we have some projects using the parent pom where we are also using m2eclipse. That causes an error while importing a project using the parent pom: "An internal error occurred during: "Importing Maven projects". loader constraint violation: when resolving method "org.codehaus.plexus.util.xml.Xpp3DomWriter.write(Lorg/codehaus/plexus/u til/xml/XMLWriter;Lorg/codehaus/plexus/util/xml/Xpp3Dom;)V" the class loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class, org/apache/maven/plugin/eclipse/writers/wtp/EclipseWtpApplicationXMLWrit er, and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) for resolved class, org/codehaus/plexus/util/xml/Xpp3DomWriter, have different Class objects for the type org/codehaus/plexus/util/xml/XMLWriter used in the signature" - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Unsubscribe
You have to send an email to users-unsubscr...@maven.apache.org to unsubscribe Shahzad Qureshi Systems Analyst/Programmer Applications Directorate, CIOB Environment Canada shahzad.qure...@ec.gc.ca -Original Message- From: Durbha, Praveen (GE Healthcare) [mailto:praveen.dur...@ge.com] Sent: Wednesday, January 21, 2009 2:35 AM To: Maven Users List Subject: FW: Unsubscribe Please unsubscribe me. not sure why this isn't getting thru From: Durbha, Praveen (GE Healthcare) Sent: Tuesday, January 20, 2009 2:43 AM To: 'users-unsubscr...@maven.apache.org' Subject: Unsubscribe Please unsubscribe me.. Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven resource processing
Hello list - we have a profile in one of our war projects that copies over (only) any web content to the unpacked location. So if a developer tweaks a jsp or html or what have you, they can run mvn process-resources -P and that moves things over for them. Is there a way to see what's being copied over? If not, can I request that as a feature to the plugin?
Exclude plugin dependency defined in parent pom?
Is there a way to Exclude a plugin dependency declared in a parent pom? We have an enterprise level pom that turns WTP capabilities by default: org.apache.maven.plugins maven-eclipse-plugin true true 2.0 The problem is that we have some projects using the parent pom where we are also using m2eclipse. That causes an error while importing a project using the parent pom: "An internal error occurred during: "Importing Maven projects". loader constraint violation: when resolving method "org.codehaus.plexus.util.xml.Xpp3DomWriter.write(Lorg/codehaus/plexus/u til/xml/XMLWriter;Lorg/codehaus/plexus/util/xml/Xpp3Dom;)V" the class loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class, org/apache/maven/plugin/eclipse/writers/wtp/EclipseWtpApplicationXMLWrit er, and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) for resolved class, org/codehaus/plexus/util/xml/Xpp3DomWriter, have different Class objects for the type org/codehaus/plexus/util/xml/XMLWriter used in the signature" - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Testing Doxia-1.1-SNAPSHOT HOWTO
For those who are interested: I have added a wiki page with a brief list of steps explaining how to test Doxia-1.1-SNAPSHOT and the sandbox pdf plugin [1]. Currently you have to build and use a local version of Maven 2.1.0-M2-SNAPSHOT, but we plan to switch 2.1.0-M3 over to Doxia-1.1 as soon as M2 is released, so early feedback and volunteer testers are very welcome! Cheers, -Lukas [1] http://docs.codehaus.org/display/DOXIA/Testing+Doxia-1.1-SNAPSHOT+and+the+pdf+plugin
Re: Out of memory using docbkx plugin?
One of the last things I added to the m1 pdf plugin was an option to move the table of contents to the end of the pdf. This removes the page-number forward references and solved some reported memory problems, see http://jira.codehaus.org/browse/MPPDF-62. So if this is an option for you, you can try to move the TOC to the end of the pdf, or skip it entirely. HTH, -Lukas Siegfried Goeschl wrote: Hi Kent, I do not know the current incarnation of the plugin but worked with DocBook before - the transformation takes a lot of memory since it requires the PDF to be generated completely in-memory to resolve all the page numbers and cross-references. I think with M1 it took more than 1GB to generate th O'Reily SVN book ... Cheers, Siegfried Goeschl Kent Närling wrote: When I try to build some of our project using the docbkx docbook plugin, I get the following out of memory exception: INFO] Trace java.lang.OutOfMemoryError: Java heap space at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:183) at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) at org.apache.fop.fo.properties.CommonBorderPaddingBackground.(CommonBorderPaddingBackground.java:172) at org.apache.fop.fo.PropertyList.getBorderPaddingBackgroundProps(PropertyList.java:577) at org.apache.fop.fo.pagination.Region.bind(Region.java:64) at org.apache.fop.fo.pagination.RegionBody.bind(RegionBody.java:56) at org.apache.fop.fo.FObj.processNode(FObj.java:125) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at com.agilejava.docbkx.maven.AbstractPdfMojo.postProcessResult(AbstractPdfMojo.java:85) at com.agilejava.docbkx.maven.AbstractTransformerMojo.execute(AbstractTransformerMojo.java:174) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) It only occurs when I build the docbook pdf files, anyone know why this happens? Also, it does go away if I increase the heap space to 1,5 Mb, but that is hard to change in all environments etc... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to specify conflicting versions in Maven?
Simple but not always true. First, the fact that EXTENDED depends on BASIC is an internal issue of the EXTENDED library. Future versions may not depend on it and top-level projects should not be aware of the dependency. Second, the conflict may also occur between projects (libraries) without a direct dependecy. Imagine we have two optional modules, each of them may be used separately by a top-level project. But if both of them are used together, there are some limits on version numbers (such as, module A will not work with B of version smaller than 2.0). Martin On Wed, 21 Jan 2009, Jeff MAURY wrote: # If EXTENDED depends on BASIC, then your POM user should only declare # EXTENDED as a dependency and not BASIC. # # Jeff MAURY # # On Tue, Jan 20, 2009 at 9:02 PM, Martin Kacer wrote: # # > Hi there, # > # > I am wondering whether it is possible to specify that some existing JAR # > version will NOT work with my artifact (library), though it is not my # > own dependency. # > # > Let me illustrate the problem by a very simplified example: # > We have two libraries, both managed by Maven: Library 1 is called BASIC and # > provides some common utilities used in many other projects. # > Library 2 is called EXTENDED and it depends on BASIC because it uses # > those utilities. # > # > Both libraries exist in many versions: 1.0, 1.1, etc. In a repository, # > we have various jar artifacts (such as BASIC-1.4.jar, EXTENDED-1.2.jar # > etc.) and also POM files specifying dependencies between them. For example, # > EXTENDED-1.2.pom defines a dependency on artifactId="BASIC", # > version="[1.0,)". # > # > After some time, I decide to release a new version of BASIC, numbered 2.0. # > Unfortunately, there is an incompatible change in the library API that will # > cause the EXTENDED library version 1.x to stop working. Therefore, # > I also have to release a new version of EXTENDED: EXTENDED-2.0.jar. # > # > Is there some way to specify that BASIC-2.0 will _not_ work with EXTENDED # > version < 2.0? In other words, I want to prevent top projects from declaring # > something like: # > # > # > BASIC2.0 # > # > EXTENDED1.2 # > # > Of course, the conflict could be specified in the POM of EXTENDED 1.2. # > But it was not known in the time of 1.2 release yet. # > # > # > Sorry if I overlooked something, but I was not able to find this in the # > Maven documentation and it is a crucial feature for me. # > # > Thanks for any help... # > Martin Kacer # > # > - # > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org # > For additional commands, e-mail: users-h...@maven.apache.org # > # > # # # -- # La mélancolie c'est communiste # Tout le monde y a droit de temps en temps # La mélancolie n'est pas capitaliste # C'est m?me gratuit pour les perdants # La mélancolie c'est pacifiste # On ne lui rentre jamais dedans # La mélancolie oh tu sais ça existe # Elle se prend m?me avec des gants # La mélancolie c'est pour les syndicalistes # Il faut juste sa carte de permanent # # Miossec (2006) # # http://www.jeffmaury.com # http://riadiscuss.jeffmaury.com # http://www.lastfm.fr/listen/user/jeffmaury/personal # Mes CDs ? récupérer: # http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en # - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven inheritence works with 2.1-SNAPSHOT but not with 2.0.9
This approach is ok too and sometimes required. Checkstyle can read its
config from the classpath so unpack isn't needed, but this isn't true for
all tools. In that case, dependency unpack is the best alternative.
On 1/21/09 7:47 AM, "jie...@gmail.com" wrote:
> Just thought I would chime in with yet another alternative approach, I
> employ a solution slightly different than Brian's assembly solution.
> It is possibly not to be considered clean by the Maven crocodiles. :-)
>
> My top level enterprise parent pom has a few support modules
> immediately in its SCM hierarchy. Some of these modules are nothing
> more than configuration files, e.g. checkstyle.xml, stylesheet.css
> (for maven-javadoc-plugin), etc. They are default jar and
> contain nothing but a src/main/resources/com/acme/base/.
> Then, in the enterprise parent pom I do something like:
>
>
>
>
> maven-dependency-plugin
>
>
> Explode com.acme.base:common-config-checkstyle
> generate-resources
>
> unpack
>
>
>
>
> com.acme.base
> common-config-checkstyle
> false
> src/main/resources
>
>
> true
>
>
>
> Since this is executed for every sub-module, everyone that inherits
> from this master enterprise base parent (every Maven project in our
> shop) will automatically get the most up to date, and corporate policy
> adhering, configuration file. In your plugins which exploit these
> configuration files, you can simply refer to
> ${basedir}/src/main/resources/com/acme/base/checkstyle.xml, e.g.
>
> I think the only thing that I would change about this solution is that
> having these things unpack during the generate-resources phase is a
> bit too aggressive for our usage pattern. I could probably bring to
> something closer to the install phase, but we then might lose the
> ability to do clever things like mvn checkstyle:checkstyle directly...
> Ideally, I could refer to a resource in a Spring-like manner, e.g.
> classpath:com/acme/base/checkstyle.xml and then I wouldn't need any
> unpack executions in the at all!! Oooh, what a sweet dream
> that would be.. :-) Anyhow, I have a half dozen of these
> common-config-* modules and things are working out pretty smooth
> otherwise.
>
> Good luck!
> -jesse
>
> On Wed, Jan 21, 2009 at 4:01 AM, kukudas wrote:
>>
>> Thanks for the clearing Brian,
>>
>> i have read your tutorial and it seems a good approach, however i thought
>> about an alternative aproach maybe you can give me your opinion about it.
>>
>
> -
> 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: Out of memory using docbkx plugin?
Hi Kent! I think Sigi is right. Try to use export MAVEN_OPTS="-Xmx640m -XX:MaxPermSize=256m" in your /etc/mavenrc or where ever it is on your installation. This btw also helps if the JavaDoc process crashes with OutOfMemoryErrors. LieGrue, strub --- Siegfried Goeschl schrieb am Mi, 21.1.2009: > Von: Siegfried Goeschl > Betreff: Re: Out of memory using docbkx plugin? > An: "Maven Users List" > Datum: Mittwoch, 21. Januar 2009, 15:32 > Hi Kent, > > I do not know the current incarnation of the plugin but > worked with > DocBook before - the transformation takes a lot of memory > since it > requires the PDF to be generated completely in-memory to > resolve all the > page numbers and cross-references. I think with M1 it took > more than 1GB > to generate th O'Reily SVN book ... > > Cheers, > > Siegfried Goeschl > > > > Kent Närling wrote: > > When I try to build some of our project using the > docbkx docbook plugin, I > > get the following out of memory exception: > > > > INFO] Trace > > java.lang.OutOfMemoryError: Java heap space > > at > org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:183) > > at > org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) > > at > org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) > > at > > > org.apache.fop.fo.properties.CommonBorderPaddingBackground.(CommonBorderPaddingBackground.java:172) > > at > > > org.apache.fop.fo.PropertyList.getBorderPaddingBackgroundProps(PropertyList.java:577) > > at > org.apache.fop.fo.pagination.Region.bind(Region.java:64) > > at > org.apache.fop.fo.pagination.RegionBody.bind(RegionBody.java:56) > > at org.apache.fop.fo.FObj.processNode(FObj.java:125) > > at > > > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) > > at > org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) > > at > > > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) > > at > org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown > Source) > > at > org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown > > Source) > > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown > > Source) > > at > > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > > Source) > > at > > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > > Source) > > at > org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) > > at > org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) > > at org.apache.xerces.parsers.XMLParser.parse(Unknown > Source) > > at > org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown > Source) > > at > > > org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) > > at > > > com.agilejava.docbkx.maven.AbstractPdfMojo.postProcessResult(AbstractPdfMojo.java:85) > > at > > > com.agilejava.docbkx.maven.AbstractTransformerMojo.execute(AbstractTransformerMojo.java:174) > > at > > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > > at > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > > at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > > > > It only occurs when I build the docbook pdf files, > anyone know why this > > happens? > > Also, it does go away if I increase the heap space to > 1,5 Mb, but that is > > hard to change in all environments etc... > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Out of memory using docbkx plugin?
Hi Kent, I do not know the current incarnation of the plugin but worked with DocBook before - the transformation takes a lot of memory since it requires the PDF to be generated completely in-memory to resolve all the page numbers and cross-references. I think with M1 it took more than 1GB to generate th O'Reily SVN book ... Cheers, Siegfried Goeschl Kent Närling wrote: > When I try to build some of our project using the docbkx docbook plugin, I > get the following out of memory exception: > > INFO] Trace > java.lang.OutOfMemoryError: Java heap space > at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:183) > at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) > at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) > at > org.apache.fop.fo.properties.CommonBorderPaddingBackground.(CommonBorderPaddingBackground.java:172) > at > org.apache.fop.fo.PropertyList.getBorderPaddingBackgroundProps(PropertyList.java:577) > at org.apache.fop.fo.pagination.Region.bind(Region.java:64) > at org.apache.fop.fo.pagination.RegionBody.bind(RegionBody.java:56) > at org.apache.fop.fo.FObj.processNode(FObj.java:125) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) > at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) > at > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) > at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) > at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown > Source) > at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) > at > com.agilejava.docbkx.maven.AbstractPdfMojo.postProcessResult(AbstractPdfMojo.java:85) > at > com.agilejava.docbkx.maven.AbstractTransformerMojo.execute(AbstractTransformerMojo.java:174) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > > It only occurs when I build the docbook pdf files, anyone know why this > happens? > Also, it does go away if I increase the heap space to 1,5 Mb, but that is > hard to change in all environments etc... > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven inheritence works with 2.1-SNAPSHOT but not with 2.0.9
Just thought I would chime in with yet another alternative approach, I
employ a solution slightly different than Brian's assembly solution.
It is possibly not to be considered clean by the Maven crocodiles. :-)
My top level enterprise parent pom has a few support modules
immediately in its SCM hierarchy. Some of these modules are nothing
more than configuration files, e.g. checkstyle.xml, stylesheet.css
(for maven-javadoc-plugin), etc. They are default jar and
contain nothing but a src/main/resources/com/acme/base/.
Then, in the enterprise parent pom I do something like:
maven-dependency-plugin
Explode com.acme.base:common-config-checkstyle
generate-resources
unpack
com.acme.base
common-config-checkstyle
false
src/main/resources
true
Since this is executed for every sub-module, everyone that inherits
from this master enterprise base parent (every Maven project in our
shop) will automatically get the most up to date, and corporate policy
adhering, configuration file. In your plugins which exploit these
configuration files, you can simply refer to
${basedir}/src/main/resources/com/acme/base/checkstyle.xml, e.g.
I think the only thing that I would change about this solution is that
having these things unpack during the generate-resources phase is a
bit too aggressive for our usage pattern. I could probably bring to
something closer to the install phase, but we then might lose the
ability to do clever things like mvn checkstyle:checkstyle directly...
Ideally, I could refer to a resource in a Spring-like manner, e.g.
classpath:com/acme/base/checkstyle.xml and then I wouldn't need any
unpack executions in the at all!! Oooh, what a sweet dream
that would be.. :-) Anyhow, I have a half dozen of these
common-config-* modules and things are working out pretty smooth
otherwise.
Good luck!
-jesse
On Wed, Jan 21, 2009 at 4:01 AM, kukudas wrote:
>
> Thanks for the clearing Brian,
>
> i have read your tutorial and it seems a good approach, however i thought
> about an alternative aproach maybe you can give me your opinion about it.
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Out of memory using docbkx plugin?
When I try to build some of our project using the docbkx docbook plugin, I get the following out of memory exception: INFO] Trace java.lang.OutOfMemoryError: Java heap space at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:183) at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161) at org.apache.fop.fo.properties.CommonBorderPaddingBackground.(CommonBorderPaddingBackground.java:172) at org.apache.fop.fo.PropertyList.getBorderPaddingBackgroundProps(PropertyList.java:577) at org.apache.fop.fo.pagination.Region.bind(Region.java:64) at org.apache.fop.fo.pagination.RegionBody.bind(RegionBody.java:56) at org.apache.fop.fo.FObj.processNode(FObj.java:125) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at com.agilejava.docbkx.maven.AbstractPdfMojo.postProcessResult(AbstractPdfMojo.java:85) at com.agilejava.docbkx.maven.AbstractTransformerMojo.execute(AbstractTransformerMojo.java:174) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) It only occurs when I build the docbook pdf files, anyone know why this happens? Also, it does go away if I increase the heap space to 1,5 Mb, but that is hard to change in all environments etc...
AW: Getting classpath list from non ant-run plugins
Hi Chris!
The classpath to the compiled classes can be injected into your Java Mojo:
/**
* List of all class path elements that will be searched for...
*
* @parameter expression="${project.compileClasspathElements}"
* @required
* @readonly
*/
protected List classpathElements;
So you don't even need an additional configuration in your pom.
LieGrue,
strub
--- Chris Graham schrieb am Mi, 21.1.2009:
> Von: Chris Graham
> Betreff: Getting classpath list from non ant-run plugins
> An: users@maven.apache.org
> Datum: Mittwoch, 21. Januar 2009, 12:42
> Hi all.
>
> Using the ant-run plugin, you can get properties, like
> this:
>
> refid="maven.compile.classpath" />
>
> What I'd like to do it to get access to the same
> classpath entries but from
> a normal (ie not an ant-run derivative) plugin.
>
> Ideally, I'd like to use something like this:
>
>
>
> ${maven.compile.classpath}
>
>
> Or some other variable.
>
> Can this be done?
>
> -Chris
>
> --
> View this message in context:
> http://www.nabble.com/Getting-classpath-list-from-non-ant-run-plugins-tp21581532p21581532.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail:
> users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Getting classpath list from non ant-run plugins
Hi all.
Using the ant-run plugin, you can get properties, like this:
What I'd like to do it to get access to the same classpath entries but from
a normal (ie not an ant-run derivative) plugin.
Ideally, I'd like to use something like this:
${maven.compile.classpath}
Or some other variable.
Can this be done?
-Chris
--
View this message in context:
http://www.nabble.com/Getting-classpath-list-from-non-ant-run-plugins-tp21581532p21581532.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to specify conflicting versions in Maven?
If EXTENDED depends on BASIC, then your POM user should only declare EXTENDED as a dependency and not BASIC. Jeff MAURY On Tue, Jan 20, 2009 at 9:02 PM, Martin Kacer wrote: > Hi there, > > I am wondering whether it is possible to specify that some existing JAR > version will NOT work with my artifact (library), though it is not my > own dependency. > > Let me illustrate the problem by a very simplified example: > We have two libraries, both managed by Maven: Library 1 is called BASIC and > provides some common utilities used in many other projects. > Library 2 is called EXTENDED and it depends on BASIC because it uses > those utilities. > > Both libraries exist in many versions: 1.0, 1.1, etc. In a repository, > we have various jar artifacts (such as BASIC-1.4.jar, EXTENDED-1.2.jar > etc.) and also POM files specifying dependencies between them. For example, > EXTENDED-1.2.pom defines a dependency on artifactId="BASIC", > version="[1.0,)". > > After some time, I decide to release a new version of BASIC, numbered 2.0. > Unfortunately, there is an incompatible change in the library API that will > cause the EXTENDED library version 1.x to stop working. Therefore, > I also have to release a new version of EXTENDED: EXTENDED-2.0.jar. > > Is there some way to specify that BASIC-2.0 will _not_ work with EXTENDED > version < 2.0? In other words, I want to prevent top projects from declaring > something like: > > > BASIC2.0 > > EXTENDED1.2 > > Of course, the conflict could be specified in the POM of EXTENDED 1.2. > But it was not known in the time of 1.2 release yet. > > > Sorry if I overlooked something, but I was not able to find this in the > Maven documentation and it is a crucial feature for me. > > Thanks for any help... > Martin Kacer > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal Mes CDs à récupérer: http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en
Re: How do I add all the jars in a directory in junit test exeicution classpath
I have the same problem but I'm not able to make it work. Assume I have to add to CLASSPATH about 10 jars all coming from other products of my society. for the moment all this products are not built using maven, so I have to use them in a quite "ANT" fashion adding these jars to the classpath taking them from a /lib directory. I have created a directory %M2_REPO%/myNewGroup/myNewArtifacId/ and I have copied all my jar in the lib. It does not work. How can getiing out of this? Do I have to recreate all a well structured directory tree with each jar in his own artifactid subdir and respecting all the naming convention? There is an unelegant but straightforward solution? thanks -- View this message in context: http://www.nabble.com/Re%3A-How-do-I-add-all-the-jars-in-a-directory-in-junit-test-exeicution-classpath-tp21373497p21580902.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
Big slowdown on Linux when upgrading assembly plugin from 2.2-beta-1 to 2.2-beta-3
Our build on Linux (redhat) has more than doubled in time since we upgraded
the assembly plugin from 2.2-beta-1 to 2.2-beta-3.
I did some testing with a tiny project for different versions of the
assembly plugin:
2.2-beta-1: 9 seconds
2.2-beta-2: 17 seconds
2.2-beta-3: 30 seconds
The project is really small, it contains only 1 source file. The assembly
plugin declaration in the pom is:
maven-assembly-plugin
2.2-beta-3
src/main/assembly/descriptor.xml
${project.build.directory}/dist
${project.build.directory}/assembly/work
true
${parent.version}
${buildNumber}
${timestamp}
${copyright}
assemble
single
package
The descriptor.xml includes a few local files and then about 20 jars from
dependencies, most of them are included through the transitive mechanism.
bin
zip
src/main/bin
bin
*
774
src/main/resources
resources
*
target
lib
*.jar
false
lib
Any idea what causes the slowdown? How can we avoid id?
We are running Java 1.6 and Maven 2.0.9. We use an Artifactory proxy but it
should not be a factor as I run the tests repeatedly so everything should be
in the local repo.
Regards,
Peter
--
View this message in context:
http://www.nabble.com/Big-slowdown-on-Linux-when-upgrading-assembly-plugin-from-2.2-beta-1-to-2.2-beta-3-tp21580492p21580492.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
release:perform fails to compile test classes
hallo
i encounter a very strange situation with the maven release plugin. we
have done quite some releases but for some reason a release:perform
fails to compile test classes depending on another module.
the setup looks like this:
pom.xml (parent pom)
- module1
- module2 (with test2.jar)
- module3
- module4 (with test4.jar depending on test2.jar and module 2)
- module5
a "maven clean install" runs fine on both parent pom and module4 pom
level. also the mvn release:prepareruns well.
when release:perform is executed there are compile errors for the
test-classes in module4:
[INFO] Uploading: ./wagon38229.zip to
scp://host/data/mvn/repositories/core-modules/2008.1.25-rc-1/module3
[INFO]
[INFO] ##
[INFO] Transfer finished. 9780019 bytes copied in 2.61 seconds
[...]
[INFO] [INFO]
[INFO] [INFO] Building module4
[INFO] [INFO]task-segment: [deploy, site-deploy]
[INFO] [INFO]
[INFO] [INFO] [edoras-banner-echo:echo {execution: default}]
[INFO] [INFO] [resources:resources]
[INFO] [INFO] Using encoding: 'UTF-8' to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 14 source files to
/home/mvn5/releases/svn-trunk-core-modules/target/checkout/module5/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using encoding: 'UTF-8' to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] Compiling 2 source files to
/home/mvn5/releases/svn-trunk-core-modules/target/checkout/module5/target/test-classes
[INFO] [INFO]
[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO]
[INFO] [INFO] Compilation failure
[INFO]
[INFO]
/home/mvn5/releases/svn-trunk-core-modules/target/checkout/module5/src/test/java/ch/module5/server/sync/ProfileSynchronizerTest.java:[16,36]
cannot find symbol
[INFO] symbol : class ConfigurationException
[INFO] location: package ch.edoras.core.configuration
[INFO]
[...]
if i change the path to (the working copy of the created tag in the
release:prepare step)
/home/mvn5/releases/svn-trunk-core-modules/target/checkout/ or
/home/mvn5/releases/svn-trunk-core-modules/target/checkout/module5
and execute "mvn clean install" it runs just fine.
i have this problem out of nowhere in two projects. I tried different
release plugin versions already (the two latest ones) but that did not help.
Does anyone have an idea what is causing the release plugin to have a
different classpath for test executions compared to install?
Or any other thought may help!
Thanks a lot
ossi
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
submodule not compiling
Hi, My project structure is as follows. parent/implementation/folder1/pom.xml --- parent/implementation/framework/pom.xml --- parent/implementation/framework/client/pom.xml --- parent/implementation/framework/server/pom.xml --- child1/implementation/pom.xml --- child1/implementation/server/pom.xml In the above structure framework/server/pom.xml has dependencies on spring-bean package and the dependency scope is 'compile'. pom available in child1/implementation/server/pom.xml includes this submodule dependency with scope compile. Eventhough the spring-bean package is not required by the source in child1/implementation/server/ folder it throws compilation errors when doing 'mvn clean install' from that submodule. It works perfect when running 'mvn clean install' from parent folder. (parent/implementation/folder1/pom.xml). Can someone throw more light on this? Thanks in advance. -Senthil -- View this message in context: http://www.nabble.com/submodule-not-compiling-tp21580390p21580390.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
Can I only build a specific module in the root of a multiple module project ?
Hi, For a multiple module project, if I want to only build one module, I have to go to the root of that module to build it. Could I only build it in the parent root of that module? Thanks Guofeng
Re: debugging netbeans modules configured as maven projects
I'm not really clear on your setup. is the 3rd party platform app in your repository, or you only have the installation somewhere? if you have the 3.0-SNAPSHOT version of the plugin, the the only meaningful project to start debugging is the one with nbm-application packaging, using the http://codehaus.org/~mkleint/run-platform-mojo.html goal. an obvious fallback solution is to start the 3rd party application with our modules from command line (with the correct debugging params) and then Attach Debugger.. from the IDE. Milos Nathan Rice wrote: The version of the plug-in I have was built on 11/10/08. I am trying to debug modules that plug into a 3rd party platform application. I specified the netbeans.installation parameter, however I was unsure of what to use for the clusterbuilddir and userbuilddir parameters, so I did not specify them. I had issues with the maven actions dialogue in the project properties stripping quotation marks and removing backslashes if not enclosed in quotes or escaped as well. When properly formed, with only the netbeans.installation parameter for the run-ide action, I get the following error: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:770) at java.lang.StringBuffer.deleteCharAt(StringBuffer.java:382) at org.codehaus.mojo.nbm.RunNetBeansMojo.execute(RunNetBeansMojo.java:118) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) Is this related to the fact that several parameters that were specified as required but were listed as having a default value were not passed? Nathan On Tue, Jan 20, 2009 at 12:05 PM, Milos Kleint wrote: what version of the nbm-maven-plugin are you using? there's nbm:run-ide goal that should allow debugging as well. http://mojo.codehaus.org/nbm-maven-plugin/run-ide-mojo.html Milos On Tue, Jan 20, 2009 at 7:49 PM, Nathan Rice wrote: Hello, I would like to debug a maven netbeans module which plugs into a custom platform application. Can someone provide the action configuration to accomplish this? Nathan - 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 inheritence works with 2.1-SNAPSHOT but not with 2.0.9
Thanks for the clearing Brian,
i have read your tutorial and it seems a good approach, however i thought
about an alternative aproach maybe you can give me your opinion about it.
What i want to archive is simply that i fetch every duplicate configuration
within my projects make a parent pom and inherit those things to them.
With this i will save redundency and i think my configuration files will be
better to read.
My problem was that with this aproach i could not set the path for a custom
xml file which would contain my checkstyle rules within the parents
reporting node, because when i inherited the xml file which was reachable in
the parent is not in the children.
For example in my parent project the custom.xml file (for checkstyle) was in
src/main/resources and my parent pom referenced to it. When inherited this
for the child, the child will look in his own src/main/resources and not
into the parents one which is pretty clear will result into a file not found
exception unless i inherit somehow those xml files too.
So my first guess was i need to somehow inherit those xml files too or make
them available on compile/run time which i thought would work as i descirbed
in my first posting, the problem is that i now found out (with your help)
that it isnt possible, because i have to use packaging pom and can not
provide a jar.
However i could just do it like this:
org.apache.maven.plugins
maven-checkstyle-plugin
file:../checkstyle.xml
placing the custom checkstyle.xml on a server so every project which
inherits this can access it.
I don't know if this aproach brings any disadvantages or is recommendable
for my use case.
Thanks kukudas.
Brian E Fox wrote:
>
> You found a bug in 2.1-SNAPSHOT. The parents must be pom packaging types.
>
> If you want to share checkstyle, just bundle it into a jar with assembly,
> and then you can add that jar as a dependency to your checkstyle config.
> You
> don't need to inherit from the checkstyle jar itself, Checkstyle will find
> the xml on the classpath. I wrote some examples about this here:
> http://blogs.sonatype.com/people/2008/04/how-to-share-resources-across-proje
> cts-in-maven/
>
> http://blogs.sonatype.com/people/2008/04/how-to-override-a-plugins-dependenc
> y-in-maven/
>
> --Brian
>
> On 1/20/09 8:03 AM, "kukudas" wrote:
>
>> Hi,
>>
>> i have a problem and i hope somebody can help me. I'm kinda new to this
>> things so maybe my approach is generaly wrong.
>>
>> i'm having a parent for example like this:
>>
>> 4.0.0
>> org.test
>> parent
>> 1
>>
>>
>> org.apache.maven.plugins
>> maven-checkstyle-plugin
>>
>>
>> ${pom.parent.groupId}
>> ${pom.parent.artifactId}
>> ${pom.parent.version}
>>
>>
>>
>>
>>
>> org.apache.maven.plugins
>> maven-checkstyle-plugin
>>
>> checkstyle.xml
>>
>>
>>
>>
>>
>>
>> And a child like this:
>>
>>
>> org.test
>> parent
>> 1
>>
>>
>> 4.0.0
>> org.test
>> child
>>
>> When i use Maven 2.0.9 i get the error that parent packaging has to be
>> pom.
>> But it has to be jar so my child can access the checkstyle.xml which is
>> in
>> the parent projects resource folder.
>> With Maven 2.1-SNAPSHOT it works as expected (checkstyle runs with my
>> rules
>> which are in the parents resource folder). Is there maybe a better way to
>> solve this or somehow make it work with both versions? I don't want to
>> use
>> packaging jar, run clean install for my parent and then change it to pom
>> so
>> that it will work with 2.0.9.
>>
>>
>> Thanks in advance
>>
>> kukudas
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Maven-inheritence-works-with-2.1-SNAPSHOT-but-not-with-2.0.9-tp21562721p21579235.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to reference home directory in linux?
On Wednesday 21 January 2009 keepfocusing wrote:
> I want to set the local repository position with this expression
> "~/m2/repo", which is also used as an example in settings.xml. But it
> seems not working unless I change it into absolute path such as
> "/home/abc/m2/repo".
>
> 1) Is it a bug of maven?
No. "~" is (usually) interpreted by the shell you are using. If it's in a
configuration file the shell never sees it thus cannot replace it with the
user's home directory. For maven "~" is just a character, nothing more.
> 2) How can I do if a reference to home directory is needed here?
As Haim said, try ${user.home}. I think this is a system property.
hth,
- martin
signature.asc
Description: This is a digitally signed message part.
Re: Interdependencies between modules
Hi Richard! You have to be online to pull in updates of third-party artifacts, but you don't want updates of your own artefacts? Well, I'd say there is only one solution to this: use snapshot versions for the artifacts you want updates for and define non-snapshot versions for all others. Regarding reproducability: an artifact with a snapshot-dependency is never reproducable, that's the nature of snapshots. hth, - martin On Tuesday 20 January 2009 Richard Chamberlain wrote: > Apologies for not being clear. > > In my second mail i had thought of another situation where > interdependencies between artefacts you have built cause an > unpredictable build. > > Let me illustrate the problem clearer. > > Parent P > Project A > Project B > Project C -> depends on A > > mvn install > > My reactor build would do: > > - Build Project P > - Build Project A -> installed into local repo > - Build project B -> installed into local repo > > During the build of Project B, an updated Project A was put into the > remote repository by, say an automated build > > - Build Project C (during build of project C it would have downloaded > project A) > > Therefore project C would not build with my project A. I cannot use > offline with this multi-module project as I want A, B and C to pull in > any changes to third-party artefacts. > > I may have understood the way that maven works in this regards, please > could you let me know if this is an issue. > > Regards, > > Richard > > > > > -Original Message- > From: bmat...@gmail.com [mailto:bmat...@gmail.com] On Behalf Of Baptiste > MATHUS > Sent: 20 January 2009 15:43 > To: Maven Users List > Subject: Re: Interdependencies between modules > > What do you mean by "someone deployed to the repository". It has to be > you, > particularly if you're working offline. As the local maven repository is > "local", this should not be possible. You're not sharing your local > repository with others are you? > > Did you try with mvn -o? You're not very clear about it in your last > mail. > > Cheers > > 2009/1/20 Richard Chamberlain > > > This is worse when incorporated into a multi-module build: > > > > When the reactor builds B it is not guaranteed to use locally built A. > > If someone deployed to the repository, then it would use that one. > > > > Is this an issue? Or have I missed something? > > > > > > -Original Message- > > From: bmat...@gmail.com [mailto:bmat...@gmail.com] On Behalf Of > > Baptiste > > > MATHUS > > Sent: 20 January 2009 12:56 > > To: Maven Users List > > Subject: Re: Interdependencies between modules > > > > Just a thought: use profile to disable your repository? Or simply work > > offline (mvn -o)? This way it will only use your local jar. > > > > Cheers. > > > > 2009/1/20 Richard Chamberlain > > > > > Hi All, > > > > > > > > > > > > I've got a question about how maven works when there is a newer > > remote > > > > library than a locally installed artefact. > > > > > > > > > > > > Say I've got project A and project B. B depends on A. > > > > > > > > > > > > - I build A and install it, to test that B will work with > > the > > > > API changes in A. > > > > > > - If I build B it will use my locally built copy of A, > > > everything is fine > > > > > > > > > > > > UNLESS: The continuous integration tool builds a new copy of A after > > I > > > > build A and install locally. When I come to build B it pulls in the > > > remote copy of A and my local change in A is ignored. > > > > > > > > > > > > How can I stop this happening as it does not give a predicatable > > > > build? > > > > > I really need to tell B to update its dependencies except for A. > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Rich > > > > -- > > Baptiste MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org signature.asc Description: This is a digitally signed message part.
[ANNOUNCEMENT] - Maven Axis Tools Plugin 1.3 released
The Maven Axis Tools Plugin team is pleased to announce the axistools-maven-plugin-1.3 release! This plugin supports the wsdl2java and java2wsdl tools from the Apache Axis (1) project. Changes in this version include: Fixed Bugs: o subPackageByFileName creates classes with a "file/\(sourceDirectory)" path prefix on win32 Issue: MAXISTOOLS-40. For a manual installation, you can download the axistools-maven-plugin-1.3 here: http://mojo.codehaus.org/axistools-maven-plugin Have fun! -Maven Axis Tools Plugin team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Failed to resolve artifact
Hi, I am very new to Maven. I need to generate java classes from the attached WSDL file. I installed Maven and set environment variable. When I run mvn generate-sources command I get following errors. C:\workspace\customerservice>mvn generate-sources [INFO] Scanning for projects... [INFO] [INFO] Building customerservice [INFO]task-segment: [generate-sources] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compil er-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom Downloading: http://download.java.net/maven/1//org.apache.maven.plugins/poms/mav en-compiler-plugin-2.0.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compil er-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-compiler-plugin Version: 2.0.2 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Wed Jan 21 09:07:00 IST 2009 [INFO] Final Memory: 1M/2M [INFO] Please help me how to resolve this issue. Regards, Varini - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
hibernate3-maven-plugin Error
Hello all, I'm having some trouble with the hibernate3-maven-plugin. I keep getting the following error message whenever I run mvn hibernate3:hbm2ddl... Org.hibernate.ejb.Ejb3Configuration - Could not find any META-INF/persistence.xml file in the classpath. The odd thing about this is that I have a persistence.xml at the path src/main/java/META-INF/persistence.xml. I have also tried copying it several other places and it hasn't made any difference. My pom looks like this... org.codehaus.mojo hibernate3-maven-plugin 2.1 process-classes hbm2ddl hbm2ddl annotationconfiguration jpaconfiguration Default schema.ddl false true false true Anybody have a clue why this might be happening? Jean-Philippe
Unable to download the artifact from any repository
I am very new to Maven. I need to generate java classes from the attached WSDL file. I installed Maven and set environment variable. When I run mvn generate-sources command I get following errors. C:\workspace\customerservice>mvn generate-sources [INFO] Scanning for projects... [INFO] [INFO] Building customerservice [INFO]task-segment: [generate-sources] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compil er-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom Downloading: http://download.java.net/maven/1//org.apache.maven.plugins/poms/mav en-compiler-plugin-2.0.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compil er-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-compiler-plugin Version: 2.0.2 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Wed Jan 21 09:07:00 IST 2009 [INFO] Final Memory: 1M/2M [INFO] Please help me how to resolve this issue. Regards, Varini http://www.nabble.com/file/p21579152/pom.xml pom.xml http://www.nabble.com/file/p21579152/CustomerService.wsdl CustomerService.wsdl -- View this message in context: http://www.nabble.com/Unable-to-download-the-artifact-from-any-repository-tp21579152p21579152.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
How to specify conflicting versions in Maven?
Hi there, I am wondering whether it is possible to specify that some existing JAR version will NOT work with my artifact (library), though it is not my own dependency. Let me illustrate the problem by a very simplified example: We have two libraries, both managed by Maven: Library 1 is called BASIC and provides some common utilities used in many other projects. Library 2 is called EXTENDED and it depends on BASIC because it uses those utilities. Both libraries exist in many versions: 1.0, 1.1, etc. In a repository, we have various jar artifacts (such as BASIC-1.4.jar, EXTENDED-1.2.jar etc.) and also POM files specifying dependencies between them. For example, EXTENDED-1.2.pom defines a dependency on artifactId="BASIC", version="[1.0,)". After some time, I decide to release a new version of BASIC, numbered 2.0. Unfortunately, there is an incompatible change in the library API that will cause the EXTENDED library version 1.x to stop working. Therefore, I also have to release a new version of EXTENDED: EXTENDED-2.0.jar. Is there some way to specify that BASIC-2.0 will _not_ work with EXTENDED version < 2.0? In other words, I want to prevent top projects from declaring something like: BASIC2.0 EXTENDED1.2 Of course, the conflict could be specified in the POM of EXTENDED 1.2. But it was not known in the time of 1.2 release yet. Sorry if I overlooked something, but I was not able to find this in the Maven documentation and it is a crucial feature for me. Thanks for any help... Martin Kacer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: compiltaion of .java problem
SHAILJA schrieb:
Hi,
Hi,
I have directory strucute like this
a/b
a/c
a/d.java
a/e.java
Understood.
I have one pom.xml under "a" directory .. Having code for compilation and
redirecting directories from there
Like
m
4.0.0
a
1.0
pom
b
c
${TOPDIR}/${JAVA_CLASSES_SRC}/${CUR_DIR} -- all properties are defined
${TOPDIR}/${JAVA_CLASSES_DEST}
${basedir}/test
${TOPDIR}/${JAVA_CLASSES_DEST}
--- code for compilation->
maven-compiler-plugin
If this should somehow represent the contents of your a/pom.xml it's
just plainly unreadable. The chances that someone on this list will help
you are much higher if you post the pom in some more readable format,
like just pasting the actual xml content.
What happen when I do mvn compile ,under "a " directory .. Directories b
and c get compiled but not all .java files under a
means a/d.java and a/e.java is not getting compild . WHY ? Plz help me
As far as I can guess from the crippled pom information above, the root
of your problem is that you want to compile code in the aggregation pom
(which has its packaging element set to pom and a modules tag for your
modules b and c). This will not work out of the box and (and in my
opinion) is bad style.
Each packaging type has an associated build lifecycle [1]. The default
lifecycle for pom packagings just doesn't compile any code or does any
other useful stuff for projects containing java code. What you should do
is move the java code contained directly under a/ to its own module and
use the a/pom.xml just for aggregation of the submodules.
If that's not an option for you, you will have to configure each step of
the build pocess by yourself (bind the compiler plugin to the compile
phase, bind the jar plugin to the package phase, ...) To make this
clear: I discourage you from doing this. I strongly recommed you
reconsider your current project structure and move the top level java
code to its own module. And while you're at it, it might be worth to
also refactor the directory layout to the standard layout [2] proposed
by maven.
-Tim
[1]
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
[2]
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
