Re: cobertura plugin
Hi Brett I have files jira issue http://jira.codehaus.org/browse/MOJO-299 and included an example project that displays the bug. if you could put your repo manager code somewhere in a zip file I can try it out here and see if I get the same problems. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:33:08: Hi David, There might be a release coming up, but we haven't worked on your issue and there are still some other issues outstanding that should be fixed first. If you could confirm that cobertura fails for you on the repository manager app (if SVN is a problem I can upload it somewhere), that would isolate it to you environment over your particular project. Thanks, Brett On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry brett the last i heard from you was that you were working on the problem and there would be a release late this week. So I have been working on other things and waiting paitiently. But if you are now telling me I need to file a jira issue then that's what i'll do. I'll have to put together a minimal project and reproduce the problem in some code that is not the EPOs tho. This probably won't happen today. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:20:42: On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry are you talking about maven 1 or 2 plugin? They are talking about Maven 1.0 I was told that 2.0-SNAPSHOT is the one to use for maven 2 but since updating to maven 2.0.2 the reporting part of cobertura hasn't worked. I can't reproduce it. If it never gets filed in JIRA, it'll never get fixed... can you please do that at http://jira.codehaus.org/browse/MOJO? Did you try the repository manager example I showed you last time that is working for me? - Brett
Re: cobertura plugin
Maven 2 is what I am on about. see the jira issue, but i am getting the same problem as you describe. perhaps you'd like to vote on that issue and add your comments there. Kind regards, Dave Sag javed mandary [EMAIL PROTECTED] wrote on 17-02-2006 14:14:17: ok , what about the cobertura plugin for maven 2 ? In maven site I am getting a problem after cobertura runs the junit tests and try to create a report it crashes and fails the build. Has anyone got similar problems and any solutions to that? this is what i am using: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0-SNAPSHOT/version executions execution goals goalclean/goal /goals /execution /executions /plugin regards, Javed On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Hi Brett I have files jira issue http://jira.codehaus.org/browse/MOJO-299 and included an example project that displays the bug. if you could put your repo manager code somewhere in a zip file I can try it out here and see if I get the same problems. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:33:08: Hi David, There might be a release coming up, but we haven't worked on your issue and there are still some other issues outstanding that should be fixed first. If you could confirm that cobertura fails for you on the repository manager app (if SVN is a problem I can upload it somewhere), that would isolate it to you environment over your particular project. Thanks, Brett On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry brett the last i heard from you was that you were working on the problem and there would be a release late this week. So I have been working on other things and waiting paitiently. But if you are now telling me I need to file a jira issue then that's what i'll do. I'll have to put together a minimal project and reproduce the problem in some code that is not the EPOs tho. This probably won't happen today. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:20:42: On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry are you talking about maven 1 or 2 plugin? They are talking about Maven 1.0 I was told that 2.0-SNAPSHOT is the one to use for maven 2 but since updating to maven 2.0.2 the reporting part of cobertura hasn't worked. I can't reproduce it. If it never gets filed in JIRA, it'll never get fixed... can you please do that at http://jira.codehaus.org/browse/MOJO? Did you try the repository manager example I showed you last time that is working for me? - Brett
Re: cobertura plugin
I guess we are having different problems. In a reply to my Jira issue Carlos Sanchez points out that my problem lies in the fact that cobertura is trying to instrument the classes twice. I am not sure why this is happening, nor am i sure why this is even a problem, but clearly you are not getting this problem. could you show me your pom.xml so i can look for any obvious differences between what you are doing and what I am doing. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 20-02-2006 09:05:19: this problem was fixed in SVN (asm is no longer propogated to tests themselves) On 2/20/06, javed mandary [EMAIL PROTECTED] wrote: Hi David, I solved the problem with the Cobertura plugin running hibernate junit tests by adding the following dependency in my POM: dependency groupIdasm/groupId artifactIdasm/artifactId version1.5.3/version /dependency It seems that Cobertura is looking for asm-2.1 in its POM while hibernate requires asm-1.5.3. By setting the dependency asm-1.5.3 , this is placed in classpath and everything works fine , cobertura site report is generated successfully. regards, Javed On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Maven 2 is what I am on about. see the jira issue, but i am getting the same problem as you describe. perhaps you'd like to vote on that issue and add your comments there. Kind regards, Dave Sag javed mandary [EMAIL PROTECTED] wrote on 17-02-2006 14:14:17: ok , what about the cobertura plugin for maven 2 ? In maven site I am getting a problem after cobertura runs the junit tests and tryto create a report it crashes and fails the build. Has anyone got similar problems and any solutions to that? this is what i am using: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0-SNAPSHOT/version executions execution goals goalclean/goal /goals /execution /executions /plugin regards, Javed On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Hi Brett I have files jira issue http://jira.codehaus.org/browse/MOJO-299 and included an example project that displays the bug. if you could put your repo manager code somewhere in a zip file I can try it out here and see if I get the same problems. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:33:08: Hi David, There might be a release coming up, but we haven't worked on your issue and there are still some other issues outstanding that should be fixed first. If you could confirm that cobertura fails for you on the repository manager app (if SVN is a problem I can upload it somewhere), that would isolate it to you environment over your particular project. Thanks, Brett On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry brett the last i heard from you was that you were working on the problem and there would be a release late this week. So I have been working on other things and waiting paitiently. But if you are now telling me I need to file a jira issue then that's what i'll do. I'll have to put together a minimal project and reproduce the problem in some code that is not the EPOs tho. This probably won't happen today. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 17-02-2006 13:20:42: On 2/17/06, David Sag [EMAIL PROTECTED] wrote: Sorry are you talking about maven 1 or 2 plugin? They are talking about Maven 1.0 I was told that 2.0-SNAPSHOT is the one to use for maven 2 but since updating to maven 2.0.2 the reporting part of cobertura hasn't worked. I can't reproduce it. If it never gets filed in JIRA, it'll never get fixed... can you please do that at http://jira.codehaus.org/browse/MOJO? Did you try the repository manager example I showed you last time that is working for me? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cobertura plugin
Interesting
the main difference between the way
you do it and the way I am doing is that I specify the goal and execution
phase in my build declarations thusly:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
executions
execution
idinstrument-classes/id
phaseprocess-classes/phase
goals
goalinstrument/goal
/goals
/execution
/executions
/plugin
could this be causing my problem? i
doubt it.
Also I explicitly tell surefire where
the instrumented classes are:
!-- run
the unit tests on the cobertura instrumented classes --
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.0/version
configuration
classesDirectory${project.build.directory}/classes-instrumented/classesDirectory
/configuration
/plugin
otherwise we are doing pretty much
the same thing.
I can't see in your pom.xml how your
tests know to run the instrumented classes, nor is it obvious in what phase
you are instrumenting your classes. what sort of coverage reports
are you getting?
Kind regards,
Dave Sag
javed mandary [EMAIL PROTECTED]
wrote on 20-02-2006 13:57:41:
Am running maven site with cobertura report generation:
?xml version=1.0 encoding=UTF-8?
project
[.]
build
resources
resource
directorysrc/main/resources/directory
includes
include*.xls/include
include**/*.xml/include
include*.properties/include
/includes
/resource
/resources
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
version2.0-beta-1/version
configuration
testFailureIgnoretrue/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
version2.0-beta-1/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
/plugin
/plugins
/reporting
dependencies
dependency
groupIdasm/groupId
artifactIdasm/artifactId
version1.5.3/version
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-mock/artifactId
version1.2.6/version
scopetest/scope
exclusions
exclusion
artifactIdjta/artifactId
groupIdjavax.transaction/groupId
/exclusion
exclusion
artifactIdjdbc-stdext/artifactId
groupIdjavax.sql/groupId
/exclusion
exclusion
artifactIdjsf-api/artifactId
groupIdjavax.faces/groupId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-remoting/artifactId
version1.2.6/version
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-core/artifactId
version1.2.6/version
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis/artifactId
version1.2.1/version
exclusions
exclusion
artifactIdactivation/artifactId
groupIdjavax.activation/groupId
/exclusion
exclusion
artifactIdmail/artifactId
groupIdjavax.mail/groupId
/exclusion
/exclusions
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis-jaxrpc/artifactId
version1.2.1/version
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis-saaj/artifactId
version1.2.1/version
/dependency
/dependencies
/project
On 2/20/06, David Sag [EMAIL PROTECTED] wrote:
I guess we are having different problems. In a reply to
my Jira issue
Carlos Sanchez points out that my problem lies in the fact that
cobertura is
trying to instrument the classes twice. I am not sure why
this is
happening, nor am i sure why this is even a problem, but clearly
you are not
getting this problem.
could you show me your pom.xml so i can look for any obvious
differences
between what you are doing and what I am doing.
Kind regards,
Dave Sag
Brett Porter [EMAIL PROTECTED] wrote
on 20-02-2006 09:05:19:
this problem was fixed in SVN (asm is no longer propogated
to tests
themselves)
On 2/20/06, javed mandary [EMAIL PROTECTED] wrote:
Hi David,
I solved
the problem with the Cobertura plugin running
hibernate
RE: cobertura plugin
You are so right. Removing the extra
configuration solved all of my cobertura problems.
Kind regards,
Dave Sag
Mike Perham [EMAIL PROTECTED]
wrote on 20-02-2006 15:44:17:
David, you are way overcomplicating the cobertura setup. Remove
your
executions and the surefire config. There's no need - all this
is
handled internally when the plugin executes with 'cobertura:cobertura'.
_
From: David Sag [mailto:[EMAIL PROTECTED]
Sent: Monday, February 20, 2006 7:20 AM
To: Maven Users List
Subject: Re: cobertura plugin
Interesting
the main difference between the way you do it and the way I am doing
is
that I specify the goal and execution phase in my build declarations
thusly:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
executions
execution
idinstrument-classes/id
phaseprocess-classes/phase
goals
goalinstrument/goal
/goals
/execution
/executions
/plugin
could this be causing my problem? i doubt it.
Also I explicitly tell surefire where the instrumented classes are:
!-- run the unit tests on the cobertura instrumented
classes --
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.0/version
configuration
classesDirectory${project.build.directory}/classes-instrumented/class
esDirectory
/configuration
/plugin
otherwise we are doing pretty much the same thing.
I can't see in your pom.xml how your tests know to run the instrumented
classes, nor is it obvious in what phase you are instrumenting your
classes. what sort of coverage reports are you getting?
Kind regards,
Dave Sag
javed mandary [EMAIL PROTECTED] wrote on 20-02-2006
13:57:41:
Am running maven site with cobertura report generation:
?xml version=1.0 encoding=UTF-8?
project
[.]
build
resources
resource
directorysrc/main/resources/directory
includes
include*.xls/include
include**/*.xml/include
include*.properties/include
/includes
/resource
/resources
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
version2.0-beta-1/version
configuration
testFailureIgnoretrue/testFailureIgnore
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
version2.0-beta-1/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0-SNAPSHOT/version
/plugin
/plugins
/reporting
dependencies
dependency
groupIdasm/groupId
artifactIdasm/artifactId
version1.5.3/version
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-mock/artifactId
version1.2.6/version
scopetest/scope
exclusions
exclusion
artifactIdjta/artifactId
groupIdjavax.transaction/groupId
/exclusion
exclusion
artifactIdjdbc-stdext/artifactId
groupIdjavax.sql/groupId
/exclusion
exclusion
artifactIdjsf-api/artifactId
groupIdjavax.faces/groupId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-remoting/artifactId
version1.2.6/version
/dependency
dependency
groupIdorg.springframework/groupId
artifactIdspring-core/artifactId
version1.2.6/version
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis/artifactId
version1.2.1/version
exclusions
exclusion
artifactIdactivation/artifactId
groupIdjavax.activation/groupId
/exclusion
exclusion
artifactIdmail/artifactId
groupIdjavax.mail/groupId
/exclusion
/exclusions
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis-jaxrpc/artifactId
version1.2.1/version
/dependency
dependency
groupIdaxis/groupId
artifactIdaxis-saaj/artifactId
version1.2.1/version
/dependency
/dependencies
/project
On 2/20/06, David Sag [EMAIL PROTECTED] wrote:
I guess we are having different problems. In a reply
to my Jira
issue
Carlos
tests are running 3 times when i generate my site
For some reason as of today the unit tests in one of my projects are now running 3 times when i do mvn install site. I declare the surefire plugin in my build as per normal and in my reporting as per normal so am not sure why this could be. I also generate pmd, cobertura, findbugs and qalab reports - all that has changed is i now have cobertura working. could the cobertura reporting plugin be running the tests again separately to surefire? When the surefire report runs (this only runs once) i am now getting a 'failure to parse file at [[snipped]]/surefire-reports/TEST-org.epoFopTransformerTest.xml and sure enough when i look at that file it ends unexpectedly at property value= on line 4 but if i mvn clean then mvn install, the tests run once and the xml file is okay. if i then as a separate task run mvn site the tests still appear to run 3 times but the xml file remains uncorrupted. so my questions. 1) why does surefire run the tests more than once. surely the report should just take the results of the run from the build phase. 2) why does it make a difference if i run mvn clean install site vs mvn clean; mvn install; mvn site as three separate commands 3) is the interaction between the various common plugins documented anywhere? for example cobertura is smart enough to tell surefire to run the tests against the instrumented classes behind the scenes, but this is not documented anywhere that I have seen. what other side effects might it have? Kind regards, Dave Sag
Re: tests are running 3 times when i generate my site
unfortunately cobertura is not working again as it now demands maven 2.0.3 to run and breaks my builds. i was at home last night so had access to svn, checked out the latest maven2 from the trunk and built it and cobertura ran runs ok now when i go mvn site I am now again getting the the skin does not exist error i had the other day (but fixed by setting up the snapshot stuff in my setting.xml). this is rather frustrating i must say. when i have something that works reliably, and still keeps working reliably the following day, i'll happily put together a canonical example pom.xml for you. so far that's a pipe dream for me however. using maven 2 is a bit like arm wrestling the blob. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 21-02-2006 17:15:09: I previously sent a link to the repository manager. I use: reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdchangelog-maven-plugin/artifactId /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdtaglist-maven-plugin/artifactId /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdjxr-maven-plugin/artifactId /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdsurefire-report-maven-plugin/artifactId /plugin plugin artifactIdmaven-javadoc-plugin/artifactId /plugin plugin artifactIdmaven-pmd-plugin/artifactId /plugin /plugins /reporting On 2/22/06, Wayne Fay [EMAIL PROTECTED] wrote: Since we're on the subject of cobertura, could I ask one of you guys to perhaps post your pom to the list? I had trouble getting cobertura to run, must be doing something wrong. ;-) Especially interested in David's because I'm already running PMD Findbugs reports... Once I get cobertura working, then I'm happy to assist as best I can in looking into why its running tests 3 times etc. ;-) Wayne On 2/21/06, Brett Porter [EMAIL PROTECTED] wrote: I'm now seeing the tests run twice under cobertura (once silently, which is a bit sneaky :) This is standalone, so that could be the reason for the corruption you get if it conflicts with the other run. As for cobertura and surefire report running tests again as part of the site, even after install - yes, that always happens. It's a known issue that requires some optimizations in the Maven lifecycle. Plugins really don't interact directly. Everything is driven via the lifecycle bindings, with the project object holding any information that might change. - Brett On 2/22/06, David Sag [EMAIL PROTECTED] wrote: For some reason as of today the unit tests in one of my projects are now running 3 times when i do mvn install site. I declare the surefire plugin in my build as per normal and in my reporting as per normal so am not sure why this could be. I also generate pmd, cobertura, findbugs and qalab reports - all that has changed is i now have cobertura working. could the cobertura reporting plugin be running the tests again separately to surefire? When the surefire report runs (this only runs once) i am now getting a 'failure to parse file at [[snipped]]/surefire-reports/TEST- org.epoFopTransformerTest.xml and sure enough when i look at that file it ends unexpectedly at property value= on line 4 but if i mvn clean then mvn install, the tests run once and the xml file is okay. if i then as a separate task run mvn site the tests still appear to run 3 times but the xml file remains uncorrupted. so my questions. 1) why does surefire run the tests more than once. surely the report should just take the results of the run from the build phase. 2) why does it make a difference if i run mvn clean install site vs mvn clean; mvn install; mvn site as three separate commands 3) is the interaction between the various common plugins documented anywhere? for example cobertura is smart enough to tell surefire to run the tests against the instrumented classes behind the scenes, but this is not documented anywhere that I have seen. what other side effects might it have? Kind regards, Dave Sag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tests are running 3 times when i generate my site
Hi Brett, I am well looking forward to that release. Once 2.0.3 is out and Cobertura is out I hope I can turn off snapshots for a while as official policy here won't allow their use (understandably). Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 22-02-2006 23:10:03: On 2/22/06, David Sag [EMAIL PROTECTED] wrote: unfortunately cobertura is not working again as it now demands maven 2.0.3to run and breaks my builds. Sorry, that was the only way to resolve the issue. i was at home last night so had access to svn, checked out the latest maven2 from the trunk and built it and cobertura ran runs ok now when i go mvn site I am now again getting the the skin does not exist error i had the other day (but fixed by setting up the snapshot stuff in my setting.xml). I think the skins are stable. I will release them. when i have something that works reliably, and still keeps working reliably the following day, i'll happily put together a canonical example pom.xmlfor you. so far that's a pipe dream for me however. using maven 2 is a bit like arm wrestling the blob. Sorry, but this is sometimes an unavoidable result of using nightly builds. There's a reason why they haven't been released yet :) It seems like cobertura is pretty close now. I'll try and get it released after the Maven 2.0.3 release is finalised. - Brett
jpox enhancing
I want to use JPOX there is a maven-jpox-plugin in repo1.maven.org/maven2/maven-plugins/ but when i add a reference to it in my pom.xml i get a FATAL ERROR null doing a mvn clean. is anyone out there using JPOX and Maven 2? Downloading: http://snapshots.maven.codehaus.org/maven2/maven-plugins/maven-jpox-plugin/1.0.0/maven-jpox-plugin-1.0.0.pom [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) Downloading: http://repo1.maven.org/maven2/maven-plugins/maven-jpox-plugin/1.0.0/maven-jpox-plugin-1.0.0.pom 164b downloaded Downloading: http://snapshots.maven.codehaus.org/maven2/maven-plugins/maven-jpox-plugin/1.0.0/maven-jpox-plugin-1.0.0.jar [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) Downloading: http://repo1.maven.org/maven2/maven-plugins/maven-jpox-plugin/1.0.0/maven-jpox-plugin-1.0.0.jar 4K downloaded [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1216) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:982) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:254) 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:324) 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) Kind regards, Dave Sag
default skin - where do i get it?
Hi, I had to rebuild maven from the source files in svn as the cobertura plugin is now demanding version 2.0.3 to run. but now the site plugin is complaining that it can't find the skin org.apache.maven.skins:maven-default-skin:jar:RELEASE so where do I find that - please don't say I have to build it from source as I am at work now where I can't access your svn repo. the mvn output says to try downloading it from the project website - but does not mention where that site is. Kind regards, Dave Sag
Re: default skin - where do i get it?
Hi Brett I added that to the pluginRepositories section of my settings.xml (it was already in the repositories section) and while i can see it trying to look for stuff in there, i still get the same problem. fixing the site plugin to 2.0-beta-4 fixed my problem for now though Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 24-02-2006 13:38:16: You'll need to use this repository until the site skins and site plugin are released: repository urlhttp://cvs.apache.org/maven-snapshot-repository//url /repository Or, you can lock your site plugin to version 2.0-beta-4 (the current release). - Brett On 2/24/06, David Sag [EMAIL PROTECTED] wrote: Hi, I had to rebuild maven from the source files in svn as the cobertura plugin is now demanding version 2.0.3 to run. but now the site plugin is complaining that it can't find the skin org.apache.maven.skins:maven-default-skin:jar:RELEASE so where do I find that - please don't say I have to build it from source as I am at work now where I can't access your svn repo. the mvn output says to try downloading it from the project website - but does not mention where that site is. Kind regards, Dave Sag
RE : default skin - where do i get it?
yes that's what I thought and indeed already had that site configured in my normal repositories config. but as that didn't work i tried adding it as a plugin too - but that didn't work either. specifying site beta-4 fixed the problem for now however. making my own skin is a good plan and we'll eventually do this - but for now i have to worry each morning that what worked the day before will break tomorrow and have precious little time to piss about making skins. i am giving another presentation internally here next thursday and for all i know there'll be a new maven 2.0.3 out with a fixed cobertura. my problem is that i need the snapshots to demo cobertura, but that makes my whole build rather fragile. is there some way of locking down what i currently have that works and not allowing any more recent snapshots until after my presentation; short of building my own repository and forcing my dns lookup to fail on ibiblio and other external repositories? Kind regards, Dave Sag Olivier Lamy [EMAIL PROTECTED] wrote on 24-02-2006 15:09:38: AFAIK, skin are resolved as artifacts but not as plugin [1] see method getSkinArtifactFile But to not depends on this create your own skin ;-) (very nice feature) - Olivier [1] http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-site-plugin/ src/main/java/org/apache/maven/plugins/site/SiteMojo.java?rev=370214vie w=markup -Message d'origine- De : David Sag [mailto:[EMAIL PROTECTED] Envoyé : vendredi 24 février 2006 14:51 À : Maven Users List Objet : Re: default skin - where do i get it? Hi Brett I added that to the pluginRepositories section of my settings.xml (it was already in the repositories section) and while i can see it trying to look for stuff in there, i still get the same problem. fixing the site plugin to 2.0-beta-4 fixed my problem for now though Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 24-02-2006 13:38:16: You'll need to use this repository until the site skins and site plugin are released: repository urlhttp://cvs.apache.org/maven-snapshot-repository//url /repository Or, you can lock your site plugin to version 2.0-beta-4 (the current release). - Brett On 2/24/06, David Sag [EMAIL PROTECTED] wrote: Hi, I had to rebuild maven from the source files in svn as the cobertura plugin is now demanding version 2.0.3 to run. but now the site plugin is complaining that it can't find the skin org.apache.maven.skins:maven-default-skin:jar:RELEASE so where do I find that - please don't say I have to build it from source as I am at work now where I can't access your svn repo. the mvn output says to try downloading it from the project website - but does not mention where that site is. Kind regards, Dave Sag This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] multi-project problems
Dear people, I am having my first proper stab at doing a milti-project build, but naturally have hit some immediate problems. Firstly I have scoured the maven site and google but can't find any sound documentation on how the multi-project builds are meant to work. I did find this page http://maven.apache.org/guides/mini/guide-multi-module.html but it's a little low on detail. But from the bits and pieces I could patch together from this mailing list I have done the following. I have created a master pom.xml file that specifies packaging: pom version: 2.3-SNAPSHOT (i just made this up for now - yes snapshots are working) url: a url for the group of projects description: a description for the group of projects modules: i just listed one module for now issueManagement: same for all projects so i put it here ciManagement: same for all projects so i put that here too organization: EPO developers: mostly the same for all projects with a few exceptions. should I put all of the developers who are common to all projects here and then add specific decelopers to the sub-poms on a project by project basis? ditto for contributors build: the build plugins are the same for all projects profiles: once again same for all projects, excpet for the distributionManagement which varies from one project to the next. if i list the main profile definition here can i just override a profile defn with the same id in a sub-pom to add the distributionManagement data? dependencies: junit and some of the commons libs are common to all projects assume i declare them here and then declare any additional ones i need in a sub-pom. reporting: the same for all projects so I put that here. in my sub-project's pom i have pulled out everything that's already in the parent. I am not sure what to put in the 'parent' tag though, but tried setting a parent with the same groupId and artifactId and version as my parent pom file. when i try to build now however, the first thing maven does is complain it can't download the parent project from any of the repositories and then it gives up. naturally the parent is not in any repository as it has never ever been built before. so I tried just commenting out the reference to parent in the sub-project and then, using the parent pom, mvn clean works fine but compiling fails as it is not picking up any of the parent dependencies. i checked in the maven plugin's project to see how you do it there and i note that the version listed as the ant plugin's pom's parent is 2.0 but the parent pom itself has a version 2.0.1 Could someone please exaplain how this is all meant to work? cheers dave Kind regards, Dave Sag
Re: [m2] multi-project problems
Okay that's going to be useful to know as I know in the mid-term i do not have the freedom to change the project heiracrchies. do you (and any other interested reader) have any pointers on docs relating to the config of the parent tag in a sub-project? Kind regards, Dave Sag Piéroni Raphaël [EMAIL PROTECTED] wrote on 01-03-2006 14:14:29: Hi Dave, Have you tryed to call mvn install from the parent directory ? You can also reference the parent by adding a relativePath in the parent definition in the child pom. (never used it myself) May that helps. Raphaël 2006/3/1, David Sag [EMAIL PROTECTED]: Dear people, I am having my first proper stab at doing a milti-project build, but naturally have hit some immediate problems. Firstly I have scoured the maven site and google but can't find any sound documentation on how the multi-project builds are meant to work. I did find this page http://maven.apache.org/guides/mini/guide-multi-module.html but it's a little low on detail. But from the bits and pieces I could patch together from this mailing list I have done the following. I have created a master pom.xml file that specifies packaging: pom version: 2.3-SNAPSHOT (i just made this up for now - yes snapshots are working) url: a url for the group of projects description: a description for the group of projects modules: i just listed one module for now issueManagement: same for all projects so i put it here ciManagement: same for all projects so i put that here too organization: EPO developers: mostly the same for all projects with a few exceptions. should I put all of the developers who are common to all projects here and then add specific decelopers to the sub-poms on a project by project basis? ditto for contributors build: the build plugins are the same for all projects profiles: once again same for all projects, excpet for the distributionManagement which varies from one project to the next. if i list the main profile definition here can i just override a profile defn with the same id in a sub-pom to add the distributionManagement data? dependencies: junit and some of the commons libs are common to all projects assume i declare them here and then declare any additional ones i need in a sub-pom. reporting: the same for all projects so I put that here. in my sub-project's pom i have pulled out everything that's already in the parent. I am not sure what to put in the 'parent' tag though, but tried setting a parent with the same groupId and artifactId and version as my parent pom file. when i try to build now however, the first thing maven does is complain it can't download the parent project from any of the repositories and then it gives up. naturally the parent is not in any repository as it has never ever been built before. so I tried just commenting out the reference to parent in the sub-project and then, using the parent pom, mvn clean works fine but compiling fails as it is not picking up any of the parent dependencies. i checked in the maven plugin's project to see how you do it there and i note that the version listed as the ant plugin's pom's parent is 2.0 but the parent pom itself has a version 2.0.1 Could someone please exaplain how this is all meant to work? cheers dave Kind regards, Dave Sag
RE: [m2] multi-project problems
aha. okay i had my parent pom called generic-pom.xml as I was only interesed in building some of our 'generic' projects for now. just to get a first-stab working i have renamed it to pom.xml and moved my local folder heirarchy about a bit and voila - it seems to work when i run mvn test but when i run mvn install from the parent it complains that there are no source directories to process for checkstyle - that's right the only thing in the parent is the pom.xml file. is that a bug in checkstyle, or a design feature that build plugins in a parent pom actually expect something to be in the parent project folder other than the pom. in general I am going to want to put all common build, test and reporting config in an otherwise void parent project and extend as needed in sub-projects is that not the right idea? maybe i have misunderstood it. on this point, say i have set up checktyle in the master pom but for some reason checktyle crashes while processing a sub-project (it happens if there are way too many checktyle errors for examplek that it can run out of memory.) is there a way of subtractively extending the parent, ie to tell one specific sub-project not to generate a checkstyle report, or would i have to remove it from the master and add it in to all sub-projects by hand until the offending project has been fixed? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 14:33:40: It will try to find the parent at ../pom.xml and then look in the local repository. If you never built the parent before and you don't have the pom one folder up, then it won't work. The safest thing is to keep your parent pom immediately above your children: Parent pom.xml module a module b sub modules parent pom.xml sub a sub b etc -Original Message- From: Piéroni Raphaël [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:14 AM To: Maven Users List Subject: Re: [m2] multi-project problems Hi Dave, Have you tryed to call mvn install from the parent directory ? You can also reference the parent by adding a relativePath in the parent definition in the child pom. (never used it myself) May that helps. Raphaël 2006/3/1, David Sag [EMAIL PROTECTED]: Dear people, I am having my first proper stab at doing a milti-project build, but naturally have hit some immediate problems. Firstly I have scoured the maven site and google but can't find any sound documentation on how the multi-project builds are meant to work. I did find this page http://maven.apache.org/guides/mini/guide-multi-module.html but it's a little low on detail. But from the bits and pieces I could patch together from this mailing list I have done the following. I have created a master pom.xml file that specifies packaging: pom version: 2.3-SNAPSHOT (i just made this up for now - yes snapshots are working) url: a url for the group of projects description: a description for the group of projects modules: i just listed one module for now issueManagement: same for all projects so i put it here ciManagement: same for all projects so i put that here too organization: EPO developers: mostly the same for all projects with a few exceptions. should I put all of the developers who are common to all projects here and then add specific decelopers to the sub-poms on a project by project basis? ditto for contributors build: the build plugins are the same for all projects profiles: once again same for all projects, excpet for the distributionManagement which varies from one project to the next. if i list the main profile definition here can i just override a profile defn with the same id in a sub-pom to add the distributionManagement data? dependencies: junit and some of the commons libs are common to all projects assume i declare them here and then declare any additional ones i need in a sub-pom. reporting: the same for all projects so I put that here. in my sub-project's pom i have pulled out everything that's already in the parent. I am not sure what to put in the 'parent' tag though, but tried setting a parent with the same groupId and artifactId and version as my parent pom file. when i try to build now however, the first thing maven does is complain it can't download the parent project from any of the repositories and then it gives up. naturally the parent is not in any repository as it has never ever been built before. so I tried just commenting out the reference to parent in the sub-project and then, using the parent pom, mvn clean works fine but compiling fails as it is not picking up any of the parent dependencies. i checked in the maven plugin's project to see how you do it there and i note that the version listed as the ant plugin's pom's parent is 2.0 but the parent pom itself has
RE: [m2] multi-project problems
Hi Brian, thanks for that tip - i'll give it a try now. where are you getting this knowledge from? hard-won experience or is there a docuement somewhere I could read? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 15:28:25: if you put something in the plugins section of the parent, it will run with the parent. To do what you want, you should put the config in the parent's pluginManagement section. Then in each child you just need to put the plugin group and id in the build/plugin section but the configuration will be inherited. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:49 AM To: Maven Users List Subject: RE: [m2] multi-project problems aha. okay i had my parent pom called generic-pom.xml as I was only interesed in building some of our 'generic' projects for now. just to get a first-stab working i have renamed it to pom.xml and moved my local folder heirarchy about a bit and voila - it seems to work when i run mvn test but when i run mvn install from the parent it complains that there are no source directories to process for checkstyle - that's right the only thing in the parent is the pom.xml file. is that a bug in checkstyle, or a design feature that build plugins in a parent pom actually expect something to be in the parent project folder other than the pom. in general I am going to want to put all common build, test and reporting config in an otherwise void parent project and extend as needed in sub-projects is that not the right idea? maybe i have misunderstood it. on this point, say i have set up checktyle in the master pom but for some reason checktyle crashes while processing a sub-project (it happens if there are way too many checktyle errors for examplek that it can run out of memory.) is there a way of subtractively extending the parent, ie to tell one specific sub-project not to generate a checkstyle report, or would i have to remove it from the master and add it in to all sub-projects by hand until the offending project has been fixed? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 14:33:40: It will try to find the parent at ../pom.xml and then look in the local repository. If you never built the parent before and you don't have the pom one folder up, then it won't work. The safest thing is to keep your parent pom immediately above your children: Parent pom.xml module a module b sub modules parent pom.xml sub a sub b etc -Original Message- From: Piéroni Raphaël [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:14 AM To: Maven Users List Subject: Re: [m2] multi-project problems Hi Dave, Have you tryed to call mvn install from the parent directory ? You can also reference the parent by adding a relativePath in the parent definition in the child pom. (never used it myself) May that helps. Raphaël 2006/3/1, David Sag [EMAIL PROTECTED]: Dear people, I am having my first proper stab at doing a milti-project build, but naturally have hit some immediate problems. Firstly I have scoured the maven site and google but can't find any sound documentation on how the multi-project builds are meant to work. I did find this page http://maven.apache.org/guides/mini/guide-multi-module.html but it's a little low on detail. But from the bits and pieces I could patch together from this mailing list I have done the following. I have created a master pom.xml file that specifies packaging: pom version: 2.3-SNAPSHOT (i just made this up for now - yes snapshots are working) url: a url for the group of projects description: a description for the group of projects modules: i just listed one module for now issueManagement: same for all projects so i put it here ciManagement: same for all projects so i put that here too organization: EPO developers: mostly the same for all projects with a few exceptions. should I put all of the developers who are common to all projects here and then add specific decelopers to the sub-poms on a project by project basis? ditto for contributors build: the build plugins are the same for all projects profiles: once again same for all projects, excpet for the distributionManagement which varies from one project to the next. if i list the main profile definition here can i just override a profile defn with the same id in a sub-pom to add the distributionManagement data? dependencies: junit and some of the commons libs are common to all projects assume i declare them here and then declare any additional ones i need in a sub-pom. reporting: the same for all projects so I put that here
Re: xDoc i18n base language HTML placed in wrong directory
Lance Bader
wisely said:
Automatic
redirection based on browser locale is a good idea for a consumer
site but our multi-lingual users are aggravated if they have to change
the
browser's locale in order to view a particular language. A multi-lingual
front page allowing quick choices to a particular version is much
preferred.
as an expat aussie living in europe
i couldn't agree more. try buying anything from the apple store in
the netherlands as an english speaker - it's insanity. i am happy for sites
to pick up the country from the browser (or ip number) but they should
always allow the user to select their preferred language.
that's my 2cents (ie my euro 0.01421512)
worth
Kind regards,
Dave Sag
Lance Bader [EMAIL PROTECTED]
wrote on 01-03-2006 15:58:42:
No, I double checked my prototype web site. If a directory does
not contain
any xdoc source files (like images or styles in my structure), it
is copied
to the base directory but not the language directories. Maybe
this is a
defect?
Better yet, use the value specified as the base language, ${
maven.xdoc.locale.default}, if specified explicitly rather than left
unspecified, in the root of docs.
Automatic redirection based on browser locale is a good idea for a
consumer
site but our multi-lingual users are aggravated if they have to change
the
browser's locale in order to view a particular language. A multi-lingual
front page allowing quick choices to a particular version is much
preferred.
Lance
On 2/27/06, Arnaud HERITIER [EMAIL PROTECTED] wrote:
I think that user resources (images, ..) are copied in each language
directory and in the top directory.
We put the default language in the root of the documentation
because we
didn't know what to add in the root of the docs without it ?
A default home page with links for all documentations ? It's
not very nice
for a project homepage.
What I prefered was to have a redirection page which move the
user to the
default language subdirectory.
But how to do that ? It's not really standard to use the meta
tag
refresh.
Arnaud
On 2/27/06, Lance Bader [EMAIL PROTECTED] wrote:
I'm willing to believe I'm wrong, but if the base langague
is xx,
shouldn't
the generated HTML be placed in ${maven.docs.dest}/xx?
Consider this scenario.
- Assume that there are number of files that are copied,
not generated
from
XML source, including images, style sheets, Javadoc, and
code templates.
- The base language source files contain relative URLs to
these files.
- The team who translates the base language source files
are only
changing
the text between the tags. They are not changing relative
URLs. Even
if
they understand URLs, they don't know which relative URLs
must be
modified.
- For each supported language yy, the generated HTML is
placed in ${
maven.docs.dest}/yy. If the base language xx is placed
in ${
maven.docs.dest}
instead of ${maven.docs.dest}/xx, all of the relative URLs
that
reference
files that are not generated by the xDoc plugin must be
different for
the
base language and the other languages.
Of course, for me, it is much more pleasing to see all the
supported
languages, including the base language, appear in parallel
directory
trees
where the name of the root is the ISO language code. However,
if my
sense
of aesthetics and symmetry is blinding me a better solution,
I will just
have to ignore my senses.
Lance
RE: [m2] multi-project problems
Hi Brian, Your suggestion worked well, while it's not quite what I was after (I wanted to leave the build details out of the sub-project altogether) but hey, we can't always get what we want. But there is no equivalent for the reporting section of the pom. how do I define a standard suite of reports in a parent pom? or failing that at least define how the report plugins are configured in the parent. any tips? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 15:28:25: if you put something in the plugins section of the parent, it will run with the parent. To do what you want, you should put the config in the parent's pluginManagement section. Then in each child you just need to put the plugin group and id in the build/plugin section but the configuration will be inherited. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:49 AM To: Maven Users List Subject: RE: [m2] multi-project problems aha. okay i had my parent pom called generic-pom.xml as I was only interesed in building some of our 'generic' projects for now. just to get a first-stab working i have renamed it to pom.xml and moved my local folder heirarchy about a bit and voila - it seems to work when i run mvn test but when i run mvn install from the parent it complains that there are no source directories to process for checkstyle - that's right the only thing in the parent is the pom.xml file. is that a bug in checkstyle, or a design feature that build plugins in a parent pom actually expect something to be in the parent project folder other than the pom. in general I am going to want to put all common build, test and reporting config in an otherwise void parent project and extend as needed in sub-projects is that not the right idea? maybe i have misunderstood it. on this point, say i have set up checktyle in the master pom but for some reason checktyle crashes while processing a sub-project (it happens if there are way too many checktyle errors for examplek that it can run out of memory.) is there a way of subtractively extending the parent, ie to tell one specific sub-project not to generate a checkstyle report, or would i have to remove it from the master and add it in to all sub-projects by hand until the offending project has been fixed? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 14:33:40: It will try to find the parent at ../pom.xml and then look in the local repository. If you never built the parent before and you don't have the pom one folder up, then it won't work. The safest thing is to keep your parent pom immediately above your children: Parent pom.xml module a module b sub modules parent pom.xml sub a sub b etc -Original Message- From: Piéroni Raphaël [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:14 AM To: Maven Users List Subject: Re: [m2] multi-project problems Hi Dave, Have you tryed to call mvn install from the parent directory ? You can also reference the parent by adding a relativePath in the parent definition in the child pom. (never used it myself) May that helps. Raphaël 2006/3/1, David Sag [EMAIL PROTECTED]: Dear people, I am having my first proper stab at doing a milti-project build, but naturally have hit some immediate problems. Firstly I have scoured the maven site and google but can't find any sound documentation on how the multi-project builds are meant to work. I did find this page http://maven.apache.org/guides/mini/guide-multi-module.html but it's a little low on detail. But from the bits and pieces I could patch together from this mailing list I have done the following. I have created a master pom.xml file that specifies packaging: pom version: 2.3-SNAPSHOT (i just made this up for now - yes snapshots are working) url: a url for the group of projects description: a description for the group of projects modules: i just listed one module for now issueManagement: same for all projects so i put it here ciManagement: same for all projects so i put that here too organization: EPO developers: mostly the same for all projects with a few exceptions. should I put all of the developers who are common to all projects here and then add specific decelopers to the sub-poms on a project by project basis? ditto for contributors build: the build plugins are the same for all projects profiles: once again same for all projects, excpet for the distributionManagement which varies from one project to the next. if i list the main profile definition here can i just override a profile defn with the same id in a sub-pom to add the distributionManagement data
RE: [m2] multi-project problems
Yep I looked there but no-dice. I'll have to give up on this now as I am offline until mid-next week. thanks for your help and perhaps (fingers xxed) someone who's actually done what I am trying to do (use a master pom.xml to define all common build/dependency/reporting/profile/developer details, thus making the poms for each subproject very very simple and generate a common and consistent suite of build-artifacts and reports) will post to this list with some definitive answers. thanks for your help however. I am documenting all of this as I go as I need to write up impact assesments later this month and assess at that point if we migrate to m2 or stick with ant. so far it's much simpler to just import an ant script with the appropriate reporting targets from a common location than it is to set up pom-inheritance. but that's probably because I still don't really know what I am doing with m2. (and that's partially because every time i want to try something new i need to research it and often end up having to write my own documentation, wheras Ant is very well understood by everyone here and there is a vast existing base [spaghetti mostly] of ant scripts.) if i can get what i want to work working i am happy to contribute documentation to the maven project. but i am still not sure i have my head in the right place to qualify myself for that task. Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 16:56:41: There might be a reportManagement section, there is a dependencyManagement section. Take a look at the project descriptor under where is it on the maven page. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 10:40 AM To: Maven Users List Subject: RE: [m2] multi-project problems Hi Brian, Your suggestion worked well, while it's not quite what I was after (I wanted to leave the build details out of the sub-project altogether) but hey, we can't always get what we want. But there is no equivalent for the reporting section of the pom. how do I define a standard suite of reports in a parent pom? or failing that at least define how the report plugins are configured in the parent. any tips? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 15:28:25: if you put something in the plugins section of the parent, it will run with the parent. To do what you want, you should put the config in the parent's pluginManagement section. Then in each child you just need to put the plugin group and id in the build/plugin section but the configuration will be inherited. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:49 AM To: Maven Users List Subject: RE: [m2] multi-project problems aha. okay i had my parent pom called generic-pom.xml as I was only interesed in building some of our 'generic' projects for now. just to get a first-stab working i have renamed it to pom.xml and moved my local folder heirarchy about a bit and voila - it seems to work when i run mvn test but when i run mvn install from the parent it complains that there are no source directories to process for checkstyle - that's right the only thing in the parent is the pom.xml file. is that a bug in checkstyle, or a design feature that build plugins in a parent pom actually expect something to be in the parent project folder other than the pom. in general I am going to want to put all common build, test and reporting config in an otherwise void parent project and extend as needed in sub-projects is that not the right idea? maybe i have misunderstood it. on this point, say i have set up checktyle in the master pom but for some reason checktyle crashes while processing a sub-project (it happens if there are way too many checktyle errors for examplek that it can run out of memory.) is there a way of subtractively extending the parent, ie to tell one specific sub-project not to generate a checkstyle report, or would i have to remove it from the master and add it in to all sub-projects by hand until the offending project has been fixed? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 14:33:40: It will try to find the parent at ../pom.xml and then look in the local repository. If you never built the parent before and you don't have the pom one folder up, then it won't work. The safest thing is to keep your parent pom immediately above your children: Parent pom.xml module a module b sub modules parent pom.xml sub a sub b etc -Original Message- From: Piéroni Raphaël [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:14 AM To: Maven Users List Subject: Re
Re: [m2] Multiple Goals In Pom
After setting up your pom you'd just call [mvn clean deploy] and it will do everything in the build lifecycle to that point. see http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Kind regards, Dave Sag Adam Leggett [EMAIL PROTECTED] wrote on 01-03-2006 17:03:44: Hi all, May be a simple answer to this, but how in my pom do I define multiple goals to be executed. I can achieve the desired result by typing at cmd prompt mvn [plugin1:goal1] [plugin2:goal2] ... [pluginn:goaln] But I would like to be able to simply type mvn and have these goals execute. Specifically I wish to run clean, install then jboss:deploy. Can this been done via the pom? In ANT I would define a 'master' target to aggregate the others. What is the maven approach to this? TIA Adam Adam Leggett [EMAIL PROTECTED] Senior Consultant UPCO Direct Line: 0113 20 10 631 Fax: 0113 20 10 666 http://www.upco.co.uk === The contents of this email are intended for the named addresses and may contain confidential and/or privileged material. If received in error, please contact UPCO head office on +44(0)113 201 0600 and then delete the entire mail from your system. Unauthorised review, distribution, disclosure or other use of information could constitute a breach of confidence. Your co-operation in this matter is greatly appreciated. Every effort has been taken to ensure that this email and any attachments are virus-free. However, UPCO does not make any warranty to this effect, and is not liable for any damage done by an infected email message or attachment. UPCO recommends that all emails and attachments are checked before opening. All views or opinions expressed in this electronic message and its attachements are those of the sender and do not necessarily reflect the views and opinions of The Ultimate People Company Ltd. === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] multi-project problems
Interesting - for me it's the cobertura report that is breaking my overall site build. i'll have to experiment offline for a few days tho as I am about to be away. seems strange to have a different general philosophy for reports as for build. indeed i find it odd that the reporting is so clearly separate from the overall build lifecycle. almost like it was an afterthought. for me the reports are the most important part of a build. Kind regards, Dave Sag [EMAIL PROTECTED] wrote on 01-03-2006 17:12:36: Here is a section from my parent pom.xml that causes all the reports to run on the parent and alll the children. The parent has no source and so checkstyle complains but it doesn't kill the site build and continues on. The generated site does end up with some links in the left sidebar that go nowhere though. I just live with it. One thing (or two) to note is that the changelog report requires a valid scm section in the pom. I also have a distributionManagementsite section in each of the poms (parent and child) to tell the site:deploy target where to put the generated stuff on my site server. That may be because of the way I have done things and not really be required. You get to fiddling around with the maven setup and when it works good enough it gets frozen without any backtracking to do it a better way. reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjxr-maven-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration source1.4/source /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdsurefire-report-maven-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId configuration configLocation../AA-IFS-checkstyle-rules.xml /configLocation headerLocation../license.txt/headerLocation /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdchangelog-maven-plugin/artifactId /plugin /plugins /reporting On 3/1/06, Brian E. Fox [EMAIL PROTECTED] wrote: There might be a reportManagement section, there is a dependencyManagement section. Take a look at the project descriptor under where is it on the maven page. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 10:40 AM To: Maven Users List Subject: RE: [m2] multi-project problems Hi Brian, Your suggestion worked well, while it's not quite what I was after (I wanted to leave the build details out of the sub-project altogether) but hey, we can't always get what we want. But there is no equivalent for the reporting section of the pom. how do I define a standard suite of reports in a parent pom? or failing that at least define how the report plugins are configured in the parent. any tips? Kind regards, Dave Sag Brian E. Fox [EMAIL PROTECTED] wrote on 01-03-2006 15:28:25: if you put something in the plugins section of the parent, it will run with the parent. To do what you want, you should put the config in the parent's pluginManagement section. Then in each child you just need to put the plugin group and id in the build/plugin section but the configuration will be inherited. From: David Sag [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 8:49 AM To: Maven Users List Subject: RE: [m2] multi-project problems aha. okay i had my parent pom called generic-pom.xml as I was only interesed in building some of our 'generic' projects for now. just to get a first-stab working i have renamed it to pom.xml and moved my local folder heirarchy about a bit and voila - it seems to work when i run mvn test but when i run mvn install from the parent it complains that there are no source directories to process for checkstyle - that's right the only thing in the parent is the pom.xml file. is that a bug in checkstyle, or a design feature that build plugins in a parent pom actually expect something to be in the parent project folder other than the pom. in general I am going to want to put all common build, test and reporting config in an otherwise void parent project and extend as needed in sub-projects is that not the right idea? maybe i have misunderstood it. on this point, say i have set up checktyle in the master pom but for some reason checktyle crashes while processing a sub-project (it happens if there are way
custom src directory layout - how to get it to not checkstyle/javadoc the tests too.
Hi All, I am beginning now to migrate many of our projects to maven 2, but I am not permitted to move the location of the stuff in the src directory as CVS is unable to retain the history in this case and we have no plans to move to something more useful such as subversion. the directory structure we have is pom.xml src/ - org/ -- epo/ -- etc - site/ -- apt/ --- index.apt -- fml/ --- faq.fml -- site.xml -test/ -- java/ --- org/ epo/ - etc i tried setting my sourceDirectory to src/ but the compiler then tries to build everything in the test directory as well. so i tell maven2 to exclude src/test and src/site from the main compile goal excludes exclude**/test/**/exclude exclude**/site/**/exclude /excludes into my parent pom's compiler config, and that works fine, but now cobertura is not instrumenting any of my classes (or indeed even being invoked as far as i can tell) running mvn site however pretends to generate a cobertura report but it just ends up being blank - this is a showstopper for me. cobertura generates the following error: net.sourceforge.cobertura.reporting.ComplexityCalculator - cannot find source file during CNN computation ... so clearly cobertura is not finding the source files. (i have added a comment to this effect to http://jira.codehaus.org/browse/MCOBERTURA-2) the following problems are annoying but i have live with them for now: also the javadocs are being generated for the test classes. there is no excludes config for the javadoc tool according to the documentation. i tried adding an excludes config as per the compiler plugin but, while it threw no error, neither did it actually have any effect. checkstyle's excludes config param uses a different syntax to the compiler's excludes syntax and the format is not documented. is it a comma separated list of paths? either way i tried adding excludes**/test/**/excludes but that made no difference at all. pmd reports fail as they are looking for the src in src/main/java and ignoring the sourceDirectory (but PMD is being a pain anyway so i am not so concerned with this at the moment) it seems to me that the sourceDirectory tag could do with having some in-build excludes and includes sub-tags Kind regards, Dave Sag
Re: Maven documentation (was Re: how to include all dependencies in your jar)
I heard about a very interesting way to attack this problem a couple of years ago in the Cocoon project. At one of the big cocoon user/dveleoper conferences (it could even have been at an apachecon) a small room of people with varying degrees of familiarity with the source code worked collaborativly for a stretch of about 6 hours to clean up the top 100 issues facing cocoon, including tons of documentation. The proceedure was very simple but needs some tools. Ingredients: - 1 projector to display the list of issues for all to see - some developers with commit rights - 5 x that many other people willing to collaborate - everyone needs an apple mac and SubEthaEdit (collaborative text editor) and iChat. method - small teams (max 6 including the key-dev ala the dinner party principle) rally about a developer with commit rights - the key-dev as i shall call her - and choose an issue to address. - key-dev opens master copy of code in SEE and other developers connect to that via bonjour. - everyone makes changes / be they code, javadocs, useage docs or whatever. - using ichat's status indicators to show others if you are still working or done with your specific changes. - when all done key-dev saves / builds / tests etc - fix any new issues that have emerged from this cycle - when done key-dev commits to SVN and the team is free to disband and form a new team, or just keep on going with another issue. I use the term swarm development to describe this approach and after hearing about it from an apache mate we tried it within my old workplace where many of the developers used macs. it was quite astounding how quickly issues, especially documentation issues were nailed. My suggestion is to coordinate a maven users / developers conference somwhere where the weather is nice (I hear the April sun in Cuba is nice) and we all collaboratively fix as many of the outstanding documentation issues as we can. iChat and SEE work over the wider internet too but there's nothing quite like having a bunch of people in a single room attacking a set of problems at once. the vibe is intense. Kind regards, Dave Sag Brett Porter [EMAIL PROTECTED] wrote on 07-03-2006 04:14:18: I tihnk you both make pretty good points on this, even where you might agree to disagree. Unfortunately I don't have time to reply to this entire thread, but I couldn't resist this point: On 3/7/06, Brian K. Wallace [EMAIL PROTECTED] wrote: And fourthly, the developers are often *not* the best people to write the documentation. For someone who knows all the details of an implementation it's quite hard to step back and write good introductory tutorials. On a roll here - although I'd replace often with definitely. What would be truly beneficial would be to have someone IN CHARGE (as much as certain people are IN CHARGE of certain parts of the code) of providing USER documentation for each release. A developer? Sure. But NOT a core developer that just knows. All you are talking about here is a contributing user. There is nothing stopping any user making that transition, and it would be welcomed - in fact, the minute we find one we'll hold on and never let go. It's rare for people to only contribute to documentation, and the couple who have volunteered to do so in the past have either ended up preferring to code or getting burned out on it very quickly. By the way, in our projects, its rare for anyone to be in charge for anything code or documentation. The whole project is responsible for everything, and people do what they have to for their work or itches as time allows. As a project, we try and direct people with the capacity to the right areas. Now, we do know there are missing pieces of documentation, and are correcting that over time. It's also my personal vendatta to write docs for new functionality at least going forward, and even if they are brief so that people can expand on them easily. The key point of this all was that it is impossible for developers to know exactly where the holes are now. Rants about documentation are not going to change anything - *we already know* it needs work, and always will need work, as you've both said. But there are many ways you can contribute: * file a bug for specific documentation problems. Even if you don't know the answer, say what you couldn't find or couldn't understand. * pick up a bug and research that single topic and write a doc for it. * put together outlines for other people to flesh out. As for the wiki, we consider that a workspace. Please use it if you can, and suggest ways to integrate it into the site if you find uesful things there. Patches are best - APT is no harder to write than wiki markup. Thanks for your concern! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom src directory layout - how to get it to not checkstyle/javadoc the tests too.
Thorsten Heit [EMAIL PROTECTED] wrote on 10-03-2006 13:46:19: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the directory structure we have is pom.xml src/ - org/ Maven uses src/java/... per default. Have you tried that? unfortunately I do not have permission to change the folder heirarchy for our projects. This is mostly because: 1) we have hundreds of projects 2) we have hundreds of developers 3) we use CVS not SVN internally and CVS don't do folder heirarchy changes while preserving version histories. I am able to move the tests into the m2 preferred folder heirarchy however as we have SFA tests in any of our projects. I wonder if I would be better off with a heirarchy more like pom.xml src/ - org/... test/ - java/ -- org/... that would certainly keep the tests apart from the main source, but I'd really rather at least start the process of moving to the m2 preferred arrangement. thoughts? dave
Re: custom src directory layout - how to get it to not checkstyle/javadoc the tests too.
Wayne Fay [EMAIL PROTECTED] wrote on 10-03-2006 18:00:22: Easiest answer is to move to Subversion. There are tools to facilitate this so you can save your history out of CVS. easier said than done here I am afraid. certainly that's what I have done for all of my personal and freelance projects, but in here at the EPO we face considerable technological inertia. getting permission to begin to migrate projects from ant builds to maven 2 was a huge effort here. if i was the supreme executive dark lord of development i'd have replaced our lotus notes based bug tracker with jira, cvs with svn and cruise-control with continuum too. they are battles i'll not win here as such wide-ranging changes affect many hundreds of developers across many departments and I am a but a mere contractor. Hell it took some doing just to get an english language keyboard instead of the standard swiss-german one they issue you with here. Even now I can't properly enter single or double quotes and have to copy and paste should I need one. In fact when I aksed the help-desk people about it they just laughed and told me the single quote key has been remapped as so many of our staff have characters like 'é' or 'ü' in their names. (and they wonder why i prefer to work on my mac!) as an old boss of mine used to say politiics is the art of the possible. cheers dave Then restructure your project. Wayne On 3/10/06, Thorsten Heit [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the directory structure we have is pom.xml src/ - org/ Maven uses src/java/... per default. Have you tried that? Regards Thorsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) iD8DBQFEEXUbQvObkgCcDe0RAurvAJ9R6yQpsS7OKSBa+mnJkkwvNkTVTQCfWdx9 PKyRi1m9fa9lNLqFYjMP1uU= =Jkxh -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] Jcoverage plugin?
There are a few serious bugs with cobertura and maven 2. i've been plugging away with it for a while now and if you build maven from source it does work but only for single project builds. multi-project builds all report zero coverage. see http://jira.codehaus.org/browse/MCOBERTURA-2 and http://jira.codehaus.org/browse/MCOBERTURA-5 for examples. i urge you to vote on these issues in Jira. cobertura not working properly is pretty much my final showstopper for getting maven 2 approved for use here at work. Kind regards, Dave Sag Siegmann Daniel, NY [EMAIL PROTECTED] wrote on 13-03-2006 23:16:13: Will it be moved out of the sandbox when 2.0.3 is released, do you think? Anyway, thanks for the info. ~Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 1:39 PM To: Maven Users List Subject: Re: [M2] Jcoverage plugin? The Cobertura plug-in for Maven2 depends on features introduced in Maven 2.0.3. Until 2.0.3 is released, I personally wouldn't use it (the Cobertura plug-in) in Production code. Ian snip There is, cobertura, I don't know if it is ok though. I had to build it from cvs. But that was a while ago... On 3/13/06, Siegmann Daniel, NY [EMAIL PROTECTED] wrote: Is there a jcoverage plugin for Maven 2, or any plans to create one? I did not see one on Mojo. If not, is there an equivalent tool I can use? -- Daniel Siegmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A required plugin was not found: Plugin could not be found
The cobertura plugin is not finished yet. I recommend you pop over to http://jira.codehaus.org/browse/MCOBERTURA-2 and http://jira.codehaus.org/browse/MCOBERTURA-5 and vote on those issues Kind regards, Dave Sag Boris Lenzinger [EMAIL PROTECTED] wrote on 15-03-2006 11:03:35: Hi, I'm newbie in Maven and I'm exploring this great tool. I'm using it for a personnal project but I encounter a problem that I cannot fix. I've searched on the ML and googled with no result on this problem. I'm using Maven 2.0.2. I want to generate code coverage reports on the project (and some other like jdepend, changes, etc). I saw cobertura-maven-plugin and wanted to use it. In the central repository, it seems to be working with Maven1 only. I get a NullPointerException that is raised which is caracteristic of trying to use a plugin of Maven1 with Maven2 no ? I saw some mails about this in the ML saying plugins were not up-to-date. I've searched for a repository that could have the plugins I'm interested in for Maven2. I found one here (http://snapshots.maven.codehaus.org/maven2). I then added to settings.xml a profile where I added the repository. At last I've set the profile as always active. Here is the declaration: profiles profile idadditional-repository/id repositories repository idcodehaus/id nameCode Haus snapshots./name urlhttp://snapshots.maven.codehaus.org/maven2/url layoutdefault/layout /repository /repositories /profile /profiles activeProfiles activeProfileadditional-repository/activeProfile /activeProfiles Declaration in the pom file: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0-20060130.214008-3/version /plugin Then I execute the command mvn site. Maven starts to download the pom file related to the plugin and then say that it cannot find the plugin. Here is the exact message: +-+-+-+-+-+-+-+-+-+ START OF MESSAGE +-+-+-+-+-+-+-+-+-+ [INFO] Building Common Classes [INFO] task-segment: [site] [INFO] Downloading: http://snapshots.maven.codehaus. org/maven2/org/codehaus/mojo/cobertura-maven-plugin/2.0- SNAPSHOT/cobertura-maven-plugin-2.0-20060130.214008-3.pom 3K downloaded [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository org.codehaus.mojo:cobertura-maven-plugin:maven-plugin:2.0-20060130.214008-3 from the specified remote repositories: central (http://repo1.maven.org/maven2) org.codehaus.mojo:cobertura-maven-plugin:maven-plugin:2.0-20060130.214008-3 from the specified remote repositories: central (http://repo1.maven.org/maven2) +-+-+-+-+-+-+-+-+-+ END OF MESSAGE +-+-+-+-+-+-+-+-+-+ I've tried tons of things but with no success. I've search in the mailing list but found nothing (well for the problem else I found some interesting references to plugin or some fixes for other problems I could have). In the FAQ there is a section that answers to this but it is not applying to me since I'm not behind a proxy and it was working fine until I want those plugins from a special repository. So I ask for help since I cannot find a solution. Any help would be greatly appreciated. thanks in advance Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
