[jira] Issue Comment Edited: (MSITE-262) site.xml not inherited if build run from parent
[ http://jira.codehaus.org/browse/MSITE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112953 ] Cameron Jones edited comment on MSITE-262 at 11/6/07 8:44 AM: -- Here's a project which displays the behavior. If run from the parent as a recursive build the module's site menu doesn't contain the inherited parent menu. was: Here's a project which displays the behavior site.xml not inherited if build run from parent --- Key: MSITE-262 URL: http://jira.codehaus.org/browse/MSITE-262 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Attachments: MSITE-262.zip I've seen that the site.xml is not being inherited in a module when the build is run from the parent - when run from the module itself the inheritance works correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-262) site.xml not inherited if build run from parent
[ http://jira.codehaus.org/browse/MSITE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MSITE-262: Attachment: MSITE-262.zip Here's a project which displays the behavior site.xml not inherited if build run from parent --- Key: MSITE-262 URL: http://jira.codehaus.org/browse/MSITE-262 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Attachments: MSITE-262.zip I've seen that the site.xml is not being inherited in a module when the build is run from the parent - when run from the module itself the inheritance works correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-263) NullPointerException if build run from a module and no url defined in module or parent
[ http://jira.codehaus.org/browse/MSITE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112951 ] Cameron Jones commented on MSITE-263: - I can't seem to replicate this either - sorry must have been some other configuration option which was affecting this. I've since lost that old config... NullPointerException if build run from a module and no url defined in module or parent -- Key: MSITE-263 URL: http://jira.codehaus.org/browse/MSITE-263 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Priority: Trivial Attachments: MSITE-263.zip i've found that you get a null pointer exception if there is no url defined on a module or on it's parent pom. If the build is run from the parent it works but gives a warning that urls will not be decorated. Adding the url back to the parent fixes the issue. Here's the stacktrace: java.lang.NullPointerException at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83) at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:255) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:277) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:192) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:83) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:251) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:525) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:464) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:114) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 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:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-269) Urls rewritten when they contain the project urls' hostname
[ http://jira.codehaus.org/browse/MSITE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MSITE-269: Attachment: MSITE-269.zip Yeah but the problem is that i don't want the urls to be relative. I have the following environments which i want to link to in the site: build - http://localhost/build staging - http://localhost/staging prod - http://localhost/prod And i want to deploy my site under: http://localhost/project/test/site I want the environment links to be static as they aren't related to the site itself and are there only for navigation but instead they are rewritten to: http://localhost/project/test/site/build http://localhost/project/test/site/staging http://localhost/project/test/site/prod I've included a test project which displays this. Urls rewritten when they contain the project urls' hostname --- Key: MSITE-269 URL: http://jira.codehaus.org/browse/MSITE-269 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Assignee: Dennis Lundberg Attachments: MSITE-269.zip, pom.xml, site.xml Urls in the site.xml file are being rewritten if they contain the hostname of the project url. For example: pom.xml: urlhttp://208.75.85.243/url ... site idtest.site/id urlfile:///srv/www/test/site/url /site ... site.xml: item name=About href=http://208.75.85.243/index.html; / Results in the following link for the About page which is incorrect and includes the deployment location instead of the url: http://208.75.85.243/test/site/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSITE-269) Urls rewritten when they contain the project urls' hostname
[ http://jira.codehaus.org/browse/MSITE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones reopened MSITE-269: - Urls rewritten when they contain the project urls' hostname --- Key: MSITE-269 URL: http://jira.codehaus.org/browse/MSITE-269 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Assignee: Dennis Lundberg Attachments: MSITE-269.zip, pom.xml, site.xml Urls in the site.xml file are being rewritten if they contain the hostname of the project url. For example: pom.xml: urlhttp://208.75.85.243/url ... site idtest.site/id urlfile:///srv/www/test/site/url /site ... site.xml: item name=About href=http://208.75.85.243/index.html; / Results in the following link for the About page which is incorrect and includes the deployment location instead of the url: http://208.75.85.243/test/site/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGELOG-78) Descending date order
[ http://jira.codehaus.org/browse/MCHANGELOG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MCHANGELOG-78: Attachment: changelog.html I've attached the html for a change log report, the first entry is: Changes between 2006-07-18 and 2007-09-20 and the second: Changes between 2007-09-20 and 2007-10-31 And the definition in the pom is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId configuration typedate/type dates date implementation=java.lang.String2006-07-18/date date implementation=java.lang.String2007-09-20/date date implementation=java.lang.String2007-10-31/date /dates dateFormat-MM-dd/dateFormat /configuration /plugin The dates correspond to the project release dates. Descending date order - Key: MCHANGELOG-78 URL: http://jira.codehaus.org/browse/MCHANGELOG-78 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: Cameron Jones Priority: Minor Attachments: changelog.html The reports generated are ordered in ascending order whereas the entries in each report are descending. It's a bit confusing, i'd like to see it all descending so you always have the most recent changes at the top. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-269) Urls rewritten when they contain the project urls' hostname
Urls rewritten when they contain the project urls' hostname --- Key: MSITE-269 URL: http://jira.codehaus.org/browse/MSITE-269 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Cameron Jones Attachments: pom.xml, site.xml Urls in the site.xml file are being rewritten if they contain the hostname of the project url. For example: pom.xml: urlhttp://208.75.85.243/url ... site idtest.site/id urlfile:///srv/www/test/site/url /site ... site.xml: item name=About href=http://208.75.85.243/index.html; / Results in the following link for the About page which is incorrect and includes the deployment location instead of the url: http://208.75.85.243/test/site/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-77) Unable to find repository location for moved then re-created folders
Unable to find repository location for moved then re-created folders Key: MCHANGELOG-77 URL: http://jira.codehaus.org/browse/MCHANGELOG-77 Project: Maven 2.x Changelog Plugin Issue Type: Bug Reporter: Cameron Jones I have a folder in source control which was renamed in order to allow for a new folder to be created in it's place. Since this the changelog plugin can not retrieve the logs giving the error - Unable to find repository location for... After a bit of tracking down i found this: http://svnx.lachoseinteractive.net/ticket/22 It appears that the svn command could include the revision number which would fix the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-77) Unable to find repository location for moved then re-created folders
[ http://jira.codehaus.org/browse/MCHANGELOG-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112293 ] Cameron Jones commented on MCHANGELOG-77: - As a work around you can explicitly set the report date to start after the time the folder was moved. Unable to find repository location for moved then re-created folders Key: MCHANGELOG-77 URL: http://jira.codehaus.org/browse/MCHANGELOG-77 Project: Maven 2.x Changelog Plugin Issue Type: Bug Reporter: Cameron Jones I have a folder in source control which was renamed in order to allow for a new folder to be created in it's place. Since this the changelog plugin can not retrieve the logs giving the error - Unable to find repository location for... After a bit of tracking down i found this: http://svnx.lachoseinteractive.net/ticket/22 It appears that the svn command could include the revision number which would fix the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-78) Descending date order
Descending date order - Key: MCHANGELOG-78 URL: http://jira.codehaus.org/browse/MCHANGELOG-78 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: Cameron Jones Priority: Minor The reports generated are ordered in ascending order whereas the entries in each report are descending. It's a bit confusing, i'd like to see it all descending so you always have the most recent changes at the top. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-262) site.xml not inherited if build run from parent
site.xml not inherited if build run from parent --- Key: MSITE-262 URL: http://jira.codehaus.org/browse/MSITE-262 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones I've seen that the site.xml is not being inherited in a module when the build is run from the parent - when run from the module itself the inheritance works correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-263) NullPointerException if build run from a module and no url defined in module or parent
NullPointerException if build run from a module and no url defined in module or parent -- Key: MSITE-263 URL: http://jira.codehaus.org/browse/MSITE-263 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Cameron Jones Priority: Trivial i've found that you get a null pointer exception if there is no url defined on a module or on it's parent pom. If the build is run from the parent it works but gives a warning that urls will not be decorated. Adding the url back to the parent fixes the issue. Here's the stacktrace: java.lang.NullPointerException at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83) at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:255) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:277) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:192) at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:83) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:251) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:525) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:464) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:114) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 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:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-264) Property names with periods are not resolved
Property names with periods are not resolved
Key: MSITE-264
URL: http://jira.codehaus.org/browse/MSITE-264
Project: Maven 2.x Site Plugin
Issue Type: Bug
Reporter: Cameron Jones
I've been trying to get property filtering to work over the site documents as
specified in http://maven.apache.org/plugins/maven-site-plugin/usage.html by
appending the '.vm' extension to the appropriate files. The problem is that the
property filtering doesn't seem to work when the property names contain periods
for breaking up the context words, for example:
The works:
${currentVersion}
This doesn't:
${current.version}
For some reason the default maven properties which are always available do work
even if they have periods, for example this is resolved correctly:
${project.version}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-114) Copy Dependencies does not have project dependency isolation
Copy Dependencies does not have project dependency isolation Key: MDEP-114 URL: http://jira.codehaus.org/browse/MDEP-114 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0-alpha-4 Reporter: Cameron Jones Assignee: Brian Fox In a multi-module project the copy-dependencies goal gets the list of dependencies from the project and not the individual modules. This has the effect that if the task is run from a module it has only that module's dependencies copied, however if run from the parent the entire project's dependencies are copied. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-114) Copy Dependencies does not have project dependency isolation
[ http://jira.codehaus.org/browse/MDEP-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107873 ] Cameron Jones commented on MDEP-114: The problem i have is that i need to run builds from the parent or the module and get the same result. In my environment the developers use the full build from the parent to verify a checkin whereas the build machine builds each module as a separate task. The goal i'm trying to achieve is to create a client plugin which contains a web service stub module and it's required dependencies. Since the client needs to be as small as possible i need to make sure that only the absolute required dependencies are included in it's packaging. If run from the parent this is not the case and the entire project's dependencies are included, even unrelated modules. I've managed to work around this by using the assembly plugin instead and adding a new module for other reasons...in the case of that plugin it looks at the explicitly defined dependencies on a pom and only includes those. There's also other options for excluding transitive etc. I think the assembly plugin is a bit heavy and that the dependency plugin would be the ideal place for this kind of functionality. Copy Dependencies does not have project dependency isolation Key: MDEP-114 URL: http://jira.codehaus.org/browse/MDEP-114 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0-alpha-4 Reporter: Cameron Jones Assignee: Brian Fox In a multi-module project the copy-dependencies goal gets the list of dependencies from the project and not the individual modules. This has the effect that if the task is run from a module it has only that module's dependencies copied, however if run from the parent the entire project's dependencies are copied. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-286) Classpath errors during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107596 ] Cameron Jones commented on MRELEASE-286: This could be related to MRELEASE-140 Classpath errors during release:perform --- Key: MRELEASE-286 URL: http://jira.codehaus.org/browse/MRELEASE-286 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Cameron Jones Priority: Blocker Attachments: sandbox-release-console.log, sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip I have a standard web app project which consists of a core module, a web app and some web services. In the project build i have some automated tasks setup to create the client stub classes by starting a jetty web container, deploying the web app, and then hitting the web service to access the generated wsdl so it can create a stub library. This process works during a standard 'install' goal and when running the 'release:prepare' goal, however when running 'release:perform' i encounter some library conflicts which i can only guess are as a result of a polluted class path. The specific error i get is that there is more than 1 commons-logging library on the classpath. I know this is a common error but i have it sucessfully working in the other goals and i've spent a lot of time making sure it's not an actual commons-logging issue. Also, i've also seen java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a result of running the same config. Is there anything special about the way that the release:perform task manages it's classpath? I notice that the perform task actually executes several iterations of build during this phase, is it possible that the previous iterations classpath is not isolated? To illustrate the issue i've created a test project which mimics the functionality in my app and illustrates the issue. I've attached the project to this jira and also the logs files from running release:prepare and release:perform. Unfortunately the error in jetty is output to the console so i've got that as a separate file. The test project has the following modules: pom.xml - Parent POM core/pom.xml - Core POM using commons-logging with no concrete loggers packaged or as transitive dependencies web/pom.xml - Web App using commons loggins also with no concrete log implementation (log4j is added explicity just for unit tests) test/pom.xml - Client stub generation module (sorry should have renamed to something better). The client stub module starts jetty using cargo during the initialize phase and deploy the web app. In the real app it would generate the stub classes but in this example it just needs to depoy the app for the error to occur. During the compile phase it shuts down jetty. To test i'm afraid you'll have to create a subversion repo for the app but that should be pretty much it. You might need to reconfigue where the site is deploy to as well. The only external property config should be the scm connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-286) Classpath errors during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MRELEASE-286: --- Attachment: sandbox-release-console.log Classpath errors during release:perform --- Key: MRELEASE-286 URL: http://jira.codehaus.org/browse/MRELEASE-286 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Cameron Jones Priority: Blocker Attachments: sandbox-release-console.log, sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip I have a standard web app project which consists of a core module, a web app and some web services. In the project build i have some automated tasks setup to create the client stub classes by starting a jetty web container, deploying the web app, and then hitting the web service to access the generated wsdl so it can create a stub library. This process works during a standard 'install' goal and when running the 'release:prepare' goal, however when running 'release:perform' i encounter some library conflicts which i can only guess are as a result of a polluted class path. The specific error i get is that there is more than 1 commons-logging library on the classpath. I know this is a common error but i have it sucessfully working in the other goals and i've spent a lot of time making sure it's not an actual commons-logging issue. Also, i've also seen java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a result of running the same config. Is there anything special about the way that the release:perform task manages it's classpath? I notice that the perform task actually executes several iterations of build during this phase, is it possible that the previous iterations classpath is not isolated? To illustrate the issue i've created a test project which mimics the functionality in my app and illustrates the issue. I've attached the project to this jira and also the logs files from running release:prepare and release:perform. Unfortunately the error in jetty is output to the console so i've got that as a separate file. The test project has the following modules: pom.xml - Parent POM core/pom.xml - Core POM using commons-logging with no concrete loggers packaged or as transitive dependencies web/pom.xml - Web App using commons loggins also with no concrete log implementation (log4j is added explicity just for unit tests) test/pom.xml - Client stub generation module (sorry should have renamed to something better). The client stub module starts jetty using cargo during the initialize phase and deploy the web app. In the real app it would generate the stub classes but in this example it just needs to depoy the app for the error to occur. During the compile phase it shuts down jetty. To test i'm afraid you'll have to create a subversion repo for the app but that should be pretty much it. You might need to reconfigue where the site is deploy to as well. The only external property config should be the scm connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-286) Classpath errors during release:perform
Classpath errors during release:perform --- Key: MRELEASE-286 URL: http://jira.codehaus.org/browse/MRELEASE-286 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Cameron Jones Priority: Blocker Attachments: sandbox-release-console.log, sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip I have a standard web app project which consists of a core module, a web app and some web services. In the project build i have some automated tasks setup to create the client stub classes by starting a jetty web container, deploying the web app, and then hitting the web service to access the generated wsdl so it can create a stub library. This process works during a standard 'install' goal and when running the 'release:prepare' goal, however when running 'release:perform' i encounter some library conflicts which i can only guess are as a result of a polluted class path. The specific error i get is that there is more than 1 commons-logging library on the classpath. I know this is a common error but i have it sucessfully working in the other goals and i've spent a lot of time making sure it's not an actual commons-logging issue. Also, i've also seen java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a result of running the same config. Is there anything special about the way that the release:perform task manages it's classpath? I notice that the perform task actually executes several iterations of build during this phase, is it possible that the previous iterations classpath is not isolated? To illustrate the issue i've created a test project which mimics the functionality in my app and illustrates the issue. I've attached the project to this jira and also the logs files from running release:prepare and release:perform. Unfortunately the error in jetty is output to the console so i've got that as a separate file. The test project has the following modules: pom.xml - Parent POM core/pom.xml - Core POM using commons-logging with no concrete loggers packaged or as transitive dependencies web/pom.xml - Web App using commons loggins also with no concrete log implementation (log4j is added explicity just for unit tests) test/pom.xml - Client stub generation module (sorry should have renamed to something better). The client stub module starts jetty using cargo during the initialize phase and deploy the web app. In the real app it would generate the stub classes but in this example it just needs to depoy the app for the error to occur. During the compile phase it shuts down jetty. To test i'm afraid you'll have to create a subversion repo for the app but that should be pretty much it. You might need to reconfigue where the site is deploy to as well. The only external property config should be the scm connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
