[jira] Closed: (MWAR-251) parent project dependencyManagement for test submodule causes adding unnecessary libraries to war
[
http://jira.codehaus.org/browse/MWAR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MWAR-251.
Resolution: Not A Bug
Assignee: Stephane Nicoll
This has nothing to do with the war plugin, please go through the maven user
list for user questions!
The dependency:tree of your war project is the following
{noformat}
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ WarProject ---
[INFO] net.croz.vvidovic.test:WarProject:war:0.0.1-SNAPSHOT
[INFO] +- org.slf4j:jcl-over-slf4j:jar:1.6.1:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] +- net.croz.vvidovic.test:TestProject:jar:0.0.1-SNAPSHOT:test
[INFO] | \- log4j:log4j:jar:1.2.15:compile (scope managed from test)
[INFO] | +- javax.mail:mail:jar:1.4:compile
[INFO] | | \- javax.activation:activation:jar:1.1:compile
[INFO] | +- javax.jms:jms:jar:1.1:compile
[INFO] | +- com.sun.jdmk:jmxtools:jar:1.2.1:compile
[INFO] | \- com.sun.jmx:jmxri:jar:1.2.1:compile
[INFO] \- junit:junit:jar:4.8.1:test
{noformat}
I strongly suggest you *NOT* to use scope in your dependencies management. You
are the culprit here. In your parent project you're saying explicitly that
log4j has a "compile" scope. It's perfectly normal that the war plugin bundles
this dependency since you are overriding the scope from the transitive
dependencies
> parent project dependencyManagement for test submodule causes adding
> unnecessary libraries to war
> -
>
> Key: MWAR-251
> URL: http://jira.codehaus.org/browse/MWAR-251
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-beta-1
>Reporter: Vedran Vidović
>Assignee: Stephane Nicoll
> Attachments: ParentProject.zip
>
>
> Unnecessary libraries are added in a war when we define transitive test
> dependencies of submodule used in test scope of war project:
> - create a parent project with a war submodule and a jar submodule (in
> attachment: ParentProject, WarProject, TestProject)
> - use depencencyManagement in parent pom.xml for setting versions of
> dependencies
> - add a dependency to jar submodule (which is declared in parent pom.xml in
> dependencyManagement)
> - add jar submodule as a dependency to war submodule in test scope
> - call "mvn clean package" on parent project
> --> dependencies of jar submodule will be copied to war's WEB-INF/lib
> directory (IT SHOULDN'T HAPPEN)
> - if we don't add dependency for jar submodule to dependencyManagement in
> parent pom.xml problem doesn't appear
> See attached zip of mvn project with two submodules.
--
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] Closed: (MSITE-566) site:attach-descriptor removes all comments and filters the content
[ http://jira.codehaus.org/browse/MSITE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-566. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Lukas Theussl Fixed in [r1082091|http://svn.apache.org/viewvc?rev=1082091&view=rev]. New snapshot deployed. > site:attach-descriptor removes all comments and filters the content > --- > > Key: MSITE-566 > URL: http://jira.codehaus.org/browse/MSITE-566 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Lukas Theussl > Fix For: 2.3 > > > The site:attach-descriptor goal processes the site.xml file, and removes all > comments, including the licence header. > Furthermore, it filters the source, replacing pom.* and project.* properties > (any others?) > This needs to be clearly documented under the goal and in the page > "Configuring the Site Descriptor". > Also, comments really ought to be retained. -- 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: (ARCHETYPE-255) custom variable filtered in created resources
[
http://jira.codehaus.org/browse/ARCHETYPE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260375#action_260375
]
Björn Mahler commented on ARCHETYPE-255:
it's allready there? look for in metadata.. or am i
missing something?
> custom variable filtered in created resources
> -
>
> Key: ARCHETYPE-255
> URL: http://jira.codehaus.org/browse/ARCHETYPE-255
> Project: Maven Archetype
> Issue Type: Wish
> Components: Creator, Generator
> Environment: Any
>Reporter: Lorand Somogyi
>
> It would be nice to be able to define a custom variable that would be
> filtered for created resources just like artifactId or gourpId.
> Example
>
> Command line: mvn archetype:create ... -DartifactId=my-foo -DmyVar=myValue
> Usage, in archetype-resources pom for example:
>
> https://example.com/foo/${myVar}/${artifactId}/trunk
> Which would translate to:
>
> https://example.com/foo/myValue/my-foo/trunk
--
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-566) site:attach-descriptor removes all comments and filters the content
[ http://jira.codehaus.org/browse/MSITE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SebbASF reopened MSITE-566: --- Does the plugin retain comments now? > site:attach-descriptor removes all comments and filters the content > --- > > Key: MSITE-566 > URL: http://jira.codehaus.org/browse/MSITE-566 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Lukas Theussl > Fix For: 2.3 > > > The site:attach-descriptor goal processes the site.xml file, and removes all > comments, including the licence header. > Furthermore, it filters the source, replacing pom.* and project.* properties > (any others?) > This needs to be clearly documented under the goal and in the page > "Configuring the Site Descriptor". > Also, comments really ought to be retained. -- 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: (MWAR-251) parent project dependencyManagement for test submodule causes adding unnecessary libraries to war
[ http://jira.codehaus.org/browse/MWAR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260379#action_260379 ] Vedran Vidović commented on MWAR-251: -- Thanks, I believed that if I don't add scope in dependencyManagement it is set to compile. > parent project dependencyManagement for test submodule causes adding > unnecessary libraries to war > - > > Key: MWAR-251 > URL: http://jira.codehaus.org/browse/MWAR-251 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-beta-1 >Reporter: Vedran Vidović >Assignee: Stephane Nicoll > Attachments: ParentProject.zip > > > Unnecessary libraries are added in a war when we define transitive test > dependencies of submodule used in test scope of war project: > - create a parent project with a war submodule and a jar submodule (in > attachment: ParentProject, WarProject, TestProject) > - use depencencyManagement in parent pom.xml for setting versions of > dependencies > - add a dependency to jar submodule (which is declared in parent pom.xml in > dependencyManagement) > - add jar submodule as a dependency to war submodule in test scope > - call "mvn clean package" on parent project > --> dependencies of jar submodule will be copied to war's WEB-INF/lib > directory (IT SHOULDN'T HAPPEN) > - if we don't add dependency for jar submodule to dependencyManagement in > parent pom.xml problem doesn't appear > See attached zip of mvn project with two submodules. -- 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] Closed: (MSITE-566) site:attach-descriptor removes all comments and filters the content
[ http://jira.codehaus.org/browse/MSITE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-566. --- Resolution: Fixed Yes > site:attach-descriptor removes all comments and filters the content > --- > > Key: MSITE-566 > URL: http://jira.codehaus.org/browse/MSITE-566 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Lukas Theussl > Fix For: 2.3 > > > The site:attach-descriptor goal processes the site.xml file, and removes all > comments, including the licence header. > Furthermore, it filters the source, replacing pom.* and project.* properties > (any others?) > This needs to be clearly documented under the goal and in the page > "Configuring the Site Descriptor". > Also, comments really ought to be retained. -- 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: (ARCHETYPE-367) boolean requiredProperty used in archetype ressource doesn't work as expected
boolean requiredProperty used in archetype ressource doesn't work as expected
-
Key: ARCHETYPE-367
URL: http://jira.codehaus.org/browse/ARCHETYPE-367
Project: Maven Archetype
Issue Type: Bug
Components: Archetypes
Affects Versions: 2.0
Reporter: Björn Mahler
Priority: Minor
I created a custom Property like ${isCXF} to enable cxf-functionality in our
archetype. In a resource file (web.xml) I've something like this:
#if($isCXF)
[...]
#end
and this doesn't work. isCXF is always true! and the code in the if-block is
always rendered consequently. So I modified it to: ($isCXF == true). And that
worked, but it's more verbose and error-prone.
maybe the Object generated for the variable doesn't overwrite toString
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-566) site:attach-descriptor removes all comments and filters the content
[ http://jira.codehaus.org/browse/MSITE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260383#action_260383 ] SebbASF commented on MSITE-566: --- OK, thanks, it works now. > site:attach-descriptor removes all comments and filters the content > --- > > Key: MSITE-566 > URL: http://jira.codehaus.org/browse/MSITE-566 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Lukas Theussl > Fix For: 2.3 > > > The site:attach-descriptor goal processes the site.xml file, and removes all > comments, including the licence header. > Furthermore, it filters the source, replacing pom.* and project.* properties > (any others?) > This needs to be clearly documented under the goal and in the page > "Configuring the Site Descriptor". > Also, comments really ought to be retained. -- 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: (MECLIPSE-683) UTF8 Byte Order Marks in POM files are not ignored correctly
UTF8 Byte Order Marks in POM files are not ignored correctly Key: MECLIPSE-683 URL: http://jira.codehaus.org/browse/MECLIPSE-683 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Reporter: Martin Müller Attachments: stacktrace.txt This is the same problem as in the maven sql plugin (http://jira.codehaus.org/browse/MSQL-33). If one builds with % mvn eclipse:clean eclipse:eclipse -Declipse.workspace=WORKSPACE_LOCATION and pom.xml files contain the utf8 byte order mark (http://en.wikipedia.org/wiki/Byte_order_mark) the projects in the workspace are not recorgnized correctly in the eclipse workspace. A warning indicates that the procect is not recognized: [WARNING] could not read workspace project:D:\Projekte\Workspaces\Trunk\.metadata\.plugins\org.eclipse.core.resources\.projects\projectname org.codehaus.plexus.util.xml.pull.XmlPullParserException: only whitespace content allowed before start tag and not \uef (position: START_DOCUMENT seen \uef... @1:1) at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1519) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1395) This leads to a external dependencies instead of correct workspace dependencies. Testcase can be easily created with e.g. Copy XML Editor, which defaults to save the byte order mark in UTF-8 files (see options). -- 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-567) nullpointer during site-deploy when your settings configuration is empty
nullpointer during site-deploy when your settings configuration is empty Key: MSITE-567 URL: http://jira.codehaus.org/browse/MSITE-567 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 3.0-beta-3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) Maven home: /usr/share/maven3/apache-maven-3.0.3 Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.32-28-generic", arch: "amd64", family: "unix" Reporter: Jeff Benton My site deploy failed with a null pointer exception. [INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx --- [DEBUG] Configuring mojo org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin realm ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3, parent: sun.misc.Launcher$AppClassLoader@6d6f0472] [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic configurator --> [DEBUG] (f) chmod = true [DEBUG] (f) chmodMode = g+w,a+rX [DEBUG] (f) chmodOptions = -Rf [DEBUG] (f) inputDirectory = xxx [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1 [DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7 [DEBUG] -- end configuration -- [DEBUG] The site will be deployed to url 'scp:///' with id '' [DEBUG] repository protocol scp [DEBUG] getProxy 'protocol' : scp [DEBUG] getProxy 'protocol' : scp no ProxyInfo found [DEBUG] found proxyInfo null [DEBUG] authenticationInfo with id '' : [DEBUG] configureWagon [DEBUG] configureWagon server hope [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 6.455s [INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011 [INFO] Final Memory: 14M/198M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project xxx: Execution default-deploy of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project xxx: Execution default-deploy of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-deploy of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ...
[jira] Commented: (MSITE-567) nullpointer during site-deploy when your settings configuration is empty
[ http://jira.codehaus.org/browse/MSITE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260430#action_260430 ] Dennis Lundberg commented on MSITE-567: --- Please tell us what your configuration looks like. > nullpointer during site-deploy when your settings configuration is empty > > > Key: MSITE-567 > URL: http://jira.codehaus.org/browse/MSITE-567 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) > Maven home: /usr/share/maven3/apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.32-28-generic", arch: "amd64", family: "unix" >Reporter: Jeff Benton > > My site deploy failed with a null pointer exception. > [INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx --- > [DEBUG] Configuring mojo > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin > realm > ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3, > parent: sun.misc.Launcher$AppClassLoader@6d6f0472] > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic > configurator --> > [DEBUG] (f) chmod = true > [DEBUG] (f) chmodMode = g+w,a+rX > [DEBUG] (f) chmodOptions = -Rf > [DEBUG] (f) inputDirectory = xxx > [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1 > [DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml > [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7 > [DEBUG] -- end configuration -- > [DEBUG] The site will be deployed to url 'scp:///' with id > '' > [DEBUG] repository protocol scp > [DEBUG] getProxy 'protocol' : scp > [DEBUG] getProxy 'protocol' : scp no ProxyInfo found > [DEBUG] found proxyInfo null > [DEBUG] authenticationInfo with id '' : > [DEBUG] configureWagon > [DEBUG] configureWagon server hope > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.455s > [INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011 > [INFO] Final Memory: 14M/198M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) > on project xxx: Execution default-deploy of goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project xxx: Execution default-deploy of goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus
[jira] Commented: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
[
http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432
]
Joe Littlejohn commented on MDEP-76:
I think there might now be a case where a valid dependency configuration can
cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the change
that has been made to fix this issue which (funnily enough) is also related to
logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{
[INFO] [dependency:analyze-dep-mgt {execution: default}]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree.
}}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
> It would be nice to analyze dependencyManagement exclusions as well as
> versions
> ---
>
> Key: MDEP-76
> URL: http://jira.codehaus.org/browse/MDEP-76
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: analyze
>Affects Versions: 2.0-alpha-3
>Reporter: Daniel Kulp
>Assignee: Brian Fox
> Fix For: 2.0-alpha-4
>
>
> In my depManagment section, I do:
>
> commons-logging
> commons-logging
> 1.1
>
>
> log4j
> log4j
>
>
>
> to hopefully remove log4j from the build.However, if I depend on
> something else that depends on commons-logging (like spring or neethi), they
> suck in log4j.It would be nice if the analyzer would check if the
> exclusions are really occuring.
--
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] Issue Comment Edited: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
[
http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432
]
Joe Littlejohn edited comment on MDEP-76 at 3/16/11 1:23 PM:
-
I think there might now be a case where a valid dependency configuration can
cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the change
that has been made to fix this issue which (funnily enough) is also related to
logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{ [INFO] [dependency:analyze-dep-mgt {execution: default}] }}
{{ [INFO] Found Resolved Dependency / DependencyManagement mismatches: }}
{{ [INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree. }}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
was (Author: joelittlejohn):
I think there might now be a case where a valid dependency configuration
can cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the
change that has been made to fix this issue which (funnily enough) is also
related to logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{[INFO] [dependency:analyze-dep-mgt {execution: default}]}}
{[[INFO] Found Resolved Dependency / DependencyManagement mismatches:}}
{{[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree.}}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
> It would be nice to analyze dependencyManagement exclusions as well as
> versions
> ---
>
> Key: MDEP-76
> URL: http://jira.codehaus.org/browse/MDEP-76
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: analyze
>Affects Versions: 2.0-alpha-3
>Reporter: Daniel Kulp
>Assignee: Brian Fox
> Fix For: 2.0-alpha-4
>
>
> In my depManagment section, I do:
>
> commons-logging
> commons-logging
> 1.1
>
>
> log4j
> log4j
>
>
>
> to hopefully remove log4j from the build.However, if I depend on
> something else that depends on commons-logging (like spring or neethi), they
> suck in log4j.It would be nice if the analyzer would check if the
> exclusions are really occuring.
--
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] Issue Comment Edited: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
[
http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432
]
Joe Littlejohn edited comment on MDEP-76 at 3/16/11 1:23 PM:
-
I think there might now be a case where a valid dependency configuration can
cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the change
that has been made to fix this issue which (funnily enough) is also related to
logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{[INFO] [dependency:analyze-dep-mgt {execution: default}]}}
{[[INFO] Found Resolved Dependency / DependencyManagement mismatches:}}
{{[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree.}}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
was (Author: joelittlejohn):
I think there might now be a case where a valid dependency configuration
can cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the
change that has been made to fix this issue which (funnily enough) is also
related to logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{
[INFO] [dependency:analyze-dep-mgt {execution: default}]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree.
}}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
> It would be nice to analyze dependencyManagement exclusions as well as
> versions
> ---
>
> Key: MDEP-76
> URL: http://jira.codehaus.org/browse/MDEP-76
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: analyze
>Affects Versions: 2.0-alpha-3
>Reporter: Daniel Kulp
>Assignee: Brian Fox
> Fix For: 2.0-alpha-4
>
>
> In my depManagment section, I do:
>
> commons-logging
> commons-logging
> 1.1
>
>
> log4j
> log4j
>
>
>
> to hopefully remove log4j from the build.However, if I depend on
> something else that depends on commons-logging (like spring or neethi), they
> suck in log4j.It would be nice if the analyzer would check if the
> exclusions are really occuring.
--
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] Issue Comment Edited: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
[
http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432
]
Joe Littlejohn edited comment on MDEP-76 at 3/16/11 1:24 PM:
-
I think there might now be a case where a valid dependency configuration can
cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the change
that has been made to fix this issue which (funnily enough) is also related to
logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{code}
[INFO] [dependency:analyze-dep-mgt {execution: default}]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree.
{code}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
was (Author: joelittlejohn):
I think there might now be a case where a valid dependency configuration
can cause the analyze-dep-mgt goal to fail. I'm hitting a problem with the
change that has been made to fix this issue which (funnily enough) is also
related to logging.
My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that
log4j does not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even
though it is a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'
When I add log4j as a dependency in a child pom, I see this error:
{{ [INFO] [dependency:analyze-dep-mgt {execution: default}] }}
{{ [INFO] Found Resolved Dependency / DependencyManagement mismatches: }}
{{ [INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been
found in the dependency tree. }}
I'm using {{true}} because I really want/need this
feature. I guess the bottom line is that even though I exclude an artifact from
one dependency, I may still want a direct dependency on that artifact to be
valid (particularly when scope=provided).
Does this make sense?
> It would be nice to analyze dependencyManagement exclusions as well as
> versions
> ---
>
> Key: MDEP-76
> URL: http://jira.codehaus.org/browse/MDEP-76
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: analyze
>Affects Versions: 2.0-alpha-3
>Reporter: Daniel Kulp
>Assignee: Brian Fox
> Fix For: 2.0-alpha-4
>
>
> In my depManagment section, I do:
>
> commons-logging
> commons-logging
> 1.1
>
>
> log4j
> log4j
>
>
>
> to hopefully remove log4j from the build.However, if I depend on
> something else that depends on commons-logging (like spring or neethi), they
> suck in log4j.It would be nice if the analyzer would check if the
> exclusions are really occuring.
--
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-567) nullpointer during site-deploy when your settings configuration is empty
[ http://jira.codehaus.org/browse/MSITE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260433#action_260433 ] Jeff Benton commented on MSITE-567: --- source.nexus.public.mirror *,!source.nexus.public.snapshots,!source.nexus.public.snapshots.plugin http://source/nexus/content/groups/public source.nexus.public.snapshots.mirror source.nexus.public.snapshots http://source/nexus/content/groups/public-snapshots source.nexus.public.snapshots.plugin.mirror source.nexus.public.snapshots.plugin http://source/nexus/content/groups/public-snapshots server myuser mypass 664 775 version-title true > nullpointer during site-deploy when your settings configuration is empty > > > Key: MSITE-567 > URL: http://jira.codehaus.org/browse/MSITE-567 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) > Maven home: /usr/share/maven3/apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.32-28-generic", arch: "amd64", family: "unix" >Reporter: Jeff Benton > > My site deploy failed with a null pointer exception. > [INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx --- > [DEBUG] Configuring mojo > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin > realm > ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3, > parent: sun.misc.Launcher$AppClassLoader@6d6f0472] > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic > configurator --> > [DEBUG] (f) chmod = true > [DEBUG] (f) chmodMode = g+w,a+rX > [DEBUG] (f) chmodOptions = -Rf > [DEBUG] (f) inputDirectory = xxx > [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1 > [DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml > [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7 > [DEBUG] -- end configuration -- > [DEBUG] The site will be deployed to url 'scp:///' with id > '' > [DEBUG] repository protocol scp > [DEBUG] getProxy 'protocol' : scp > [DEBUG] getProxy 'protocol' : scp no ProxyInfo found > [DEBUG] found proxyInfo null > [DEBUG] authenticationInfo with id '' : > [DEBUG] configureWagon > [DEBUG] configureWagon server hope > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.455s > [INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011 > [INFO] Final Memory: 14M/198M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) > on project xxx: Execution default-deploy of goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project xxx: Execution default-deploy of goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) >
[jira] Commented: (MSITE-567) nullpointer during site-deploy when your settings configuration is empty
[
http://jira.codehaus.org/browse/MSITE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260440#action_260440
]
Dennis Lundberg commented on MSITE-567:
---
And what does your POM look like?
> nullpointer during site-deploy when your settings configuration is empty
>
>
> Key: MSITE-567
> URL: http://jira.codehaus.org/browse/MSITE-567
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-3
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600)
> Maven home: /usr/share/maven3/apache-maven-3.0.3
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-28-generic", arch: "amd64", family: "unix"
>Reporter: Jeff Benton
>
> My site deploy failed with a null pointer exception.
> {noformat}
> [INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3,
> parent: sun.misc.Launcher$AppClassLoader@6d6f0472]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic
> configurator -->
> [DEBUG] (f) chmod = true
> [DEBUG] (f) chmodMode = g+w,a+rX
> [DEBUG] (f) chmodOptions = -Rf
> [DEBUG] (f) inputDirectory = xxx
> [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1
> [DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7
> [DEBUG] -- end configuration --
> [DEBUG] The site will be deployed to url 'scp:///' with id
> ''
> [DEBUG] repository protocol scp
> [DEBUG] getProxy 'protocol' : scp
> [DEBUG] getProxy 'protocol' : scp no ProxyInfo found
> [DEBUG] found proxyInfo null
> [DEBUG] authenticationInfo with id '' :
> [DEBUG] configureWagon
> [DEBUG] configureWagon server hope
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.455s
> [INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011
> [INFO] Final Memory: 14M/198M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy)
> on project xxx: Execution default-deploy of goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project xxx: Execution default-deploy of goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.ple
[jira] Updated: (MSITE-567) nullpointer during site-deploy when your settings configuration is empty
[
http://jira.codehaus.org/browse/MSITE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-567:
--
Description:
My site deploy failed with a null pointer exception.
{noformat}
[INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3,
parent: sun.misc.Launcher$AppClassLoader@6d6f0472]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic
configurator -->
[DEBUG] (f) chmod = true
[DEBUG] (f) chmodMode = g+w,a+rX
[DEBUG] (f) chmodOptions = -Rf
[DEBUG] (f) inputDirectory = xxx
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1
[DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7
[DEBUG] -- end configuration --
[DEBUG] The site will be deployed to url 'scp:///' with id ''
[DEBUG] repository protocol scp
[DEBUG] getProxy 'protocol' : scp
[DEBUG] getProxy 'protocol' : scp no ProxyInfo found
[DEBUG] found proxyInfo null
[DEBUG] authenticationInfo with id '' :
[DEBUG] configureWagon
[DEBUG] configureWagon server hope
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 6.455s
[INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011
[INFO] Final Memory: 14M/198M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy)
on project xxx: Execution default-deploy of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy)
on project xxx: Execution default-deploy of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-deploy of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugins.site.SiteDeployMojo.configureWagon(SiteDeployMojo.java:474)
at
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:216)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN
[jira] Closed: (MSITE-354) Generation of project-info.html cannot be omitted
[ http://jira.codehaus.org/browse/MSITE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-354. - Resolution: Fixed Fix Version/s: 3.0-beta-4 2.3 Assignee: Dennis Lundberg Fixed in [r1082274|http://svn.apache.org/viewvc?view=revision&revision=1082274] and [r1082280|http://svn.apache.org/viewvc?view=revision&revision=1082280]. > Generation of project-info.html cannot be omitted > - > > Key: MSITE-354 > URL: http://jira.codehaus.org/browse/MSITE-354 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-7 >Reporter: Michael Osipov >Assignee: Dennis Lundberg > Fix For: 2.3, 3.0-beta-4 > > Attachments: outcome.png > > > There is no option to prevent the MPIR to generate the project-info.html. > Please fix this. -- 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-556) Update site documentation related to deployment to sourceforge.
[ http://jira.codehaus.org/browse/MSITE-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-556: -- Fix Version/s: 3.0-beta-4 > Update site documentation related to deployment to sourceforge. > --- > > Key: MSITE-556 > URL: http://jira.codehaus.org/browse/MSITE-556 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Task >Reporter: Thiago Leão Moreira >Assignee: Lukas Theussl >Priority: Minor > Fix For: 2.3, 3.0-beta-4 > > > Since the new changes on sourceforge deployment system the documentation of > the plugin is out of date. > http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web#ChangesasofFebruary2011 > "The upload path for files changed to /home/project-web/PROJECT_NAME. > The old upload path of /home/groups/P/PR/PROJECT_NAME will continue to work > for a while, but you should transition over to the new path as soon as > possible. > You should edit any scripts that refer to the old /home/groups and/or > /home/persistent path" -- 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-553) Incomplete documentation site descriptor inheritance
[ http://jira.codehaus.org/browse/MSITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-553: -- Fix Version/s: 3.0-beta-4 > Incomplete documentation site descriptor inheritance > > > Key: MSITE-553 > URL: http://jira.codehaus.org/browse/MSITE-553 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor > Environment: > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html >Reporter: SebbASF >Assignee: Lukas Theussl >Priority: Minor > Fix For: 2.3, 3.0-beta-4 > > > The page > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > section "Inheritance" says: > bq. By default, only the basic settings are inherited. > However it does not say what "basic settings" are. > It appears to be any items outside the body, but this is not very obvious, as > some of these are definitely not "basic" - e.g. and . If it > really means all top-level child elements of the , apart from > , then it would be helpful to say so. -- 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-537) site:stage-deploy creates wrong directory structure if run from a sub-module
[ http://jira.codehaus.org/browse/MSITE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-537: -- Fix Version/s: 3.0-beta-4 > site:stage-deploy creates wrong directory structure if run from a sub-module > > > Key: MSITE-537 > URL: http://jira.codehaus.org/browse/MSITE-537 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site:deploy, > site:stage(-deploy) >Affects Versions: 2.2 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > On a simple multi-module project with one parent and one child, site:deploy > creates a directory structure like parent/child/ at the target location. If > you run site:deploy from the child module, it gets deployed to parent/child/ > which is correct. > OTOH site:stage-deploy creates parent/staging/child if run from the parent > project, but from the child project it creates parent/child/staging. It > should be parent/staging/child. -- 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-533) make site:stage a local file deploy
[ http://jira.codehaus.org/browse/MSITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-533: -- Fix Version/s: 3.0-beta-4 > make site:stage a local file deploy > --- > > Key: MSITE-533 > URL: http://jira.codehaus.org/browse/MSITE-533 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement > Components: site:deploy, site:stage(-deploy) >Affects Versions: 2.2 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > As I understand it, site:stage is supposed to be a local preview of > site:deploy. However, the site construction is very different in both cases: > site:stage changes the pom element of each reactor project and > generates the site directly at the final target (staging) location. > Unfortunately, this suffers from a couple of bugs, in particular wrt relative > links in multi-module builds, which is potentially confusing for users (and > certain developers...) if they find that the staged site is different from > the deployed site. site:deploy OTOH generates each site into its own target > and then uses wagon to copy the single sites to the final destination. > I also don't see why SiteStageMojo extends SiteMojo, staging shouldn't have > anything to do with site generation. IMO site:deploy, site:stage and > site:stage-deploy should all do the same basic thing: take a pre-generated > site directory and copy it to some target. The difference is only in the > target location: site:deploy goes to distributionManagement.site.url, > site:stage goes to stagingDirectory on the local file system, and > site:stage-deploy goes to stagingSiteURL. > Since site:deploy supports a local file copy, I propose to replace site:stage > by such a local deploy. This would make site:stage and deploy equivalent, > reduce confusion and maintenance efforts and make site:stage a true preview > per definition. Are there any arguments that speak against it? -- 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-534) site:stage gives different links than site:deploy
[ http://jira.codehaus.org/browse/MSITE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-534: -- Fix Version/s: 3.0-beta-4 > site:stage gives different links than site:deploy > - > > Key: MSITE-534 > URL: http://jira.codehaus.org/browse/MSITE-534 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy, site:stage(-deploy) >Affects Versions: 2.2 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: MSITE-534.zip > > > See MSITE-423 for a test project. -- 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-566) site:attach-descriptor removes all comments and filters the content
[ http://jira.codehaus.org/browse/MSITE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-566: -- Fix Version/s: 3.0-beta-4 > site:attach-descriptor removes all comments and filters the content > --- > > Key: MSITE-566 > URL: http://jira.codehaus.org/browse/MSITE-566 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > The site:attach-descriptor goal processes the site.xml file, and removes all > comments, including the licence header. > Furthermore, it filters the source, replacing pom.* and project.* properties > (any others?) > This needs to be clearly documented under the goal and in the page > "Configuring the Site Descriptor". > Also, comments really ought to be retained. -- 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-322) problem with internationalization of multimodule projects
[ http://jira.codehaus.org/browse/MSITE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-322: -- Fix Version/s: 3.0-beta-4 > problem with internationalization of multimodule projects > -- > > Key: MSITE-322 > URL: http://jira.codehaus.org/browse/MSITE-322 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: internationalization >Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0-beta-7 >Reporter: Anne Gerodolle >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: multilingue.zip > > > When trying to internationalize a multimodule project, the "modules" menu > does not work in alternate languages, and it is very difficult to build a > consistent site in the non default language, with links working OK. > e.g. in attached multilingue.zip example, if I run "mvn site" then "mvn > site;deploy" , the "mymodule" link in fr/index.html refers to > fr/mymodule/index.html, wehereas the corresponding page is deployed as > "mymodule/fr/index.html" . > I can think of 2 ways to solve this issues, one of them seems preferable : > one is to correct the link so that it refers to "mymodule.fr.index.html" > the second is to deploy the submodule localized version in fr/mymodule rather > than in mymodule/fr . I think this solution is preferable, because it makes > the localized site more readable. For example, if we want to create a link > that refers to the parent module, with the first solution we should refer to > "../../fr/index.html" whereas with the second we simply refer to ".." -- 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-532) site:attach-descriptor removes modules ref if the project doesn't have any modules
[
http://jira.codehaus.org/browse/MSITE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-532:
--
Fix Version/s: 3.0-beta-4
> site:attach-descriptor removes modules ref if the project doesn't have any
> modules
> --
>
> Key: MSITE-532
> URL: http://jira.codehaus.org/browse/MSITE-532
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 2.2
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: MSITE-532.zip
>
>
> I have a parent project with attached site descriptor which is supposed to be
> inherited by child projects. However, a menu ref like {{ inherit="bottom"/>}} gets removed by the site:attach-descriptor because the
> project itself does not have any modules. This evidently screws up the site
> inheritance.
--
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] Closed: (MSITE-567) nullpointer during site-deploy when your settings configuration is empty
[
http://jira.codehaus.org/browse/MSITE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-567.
---
Resolution: Duplicate
This should be fixed in 3.0-beta-4-SNAPSHOT, see MSITE-546. Please test.
> nullpointer during site-deploy when your settings configuration is empty
>
>
> Key: MSITE-567
> URL: http://jira.codehaus.org/browse/MSITE-567
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-3
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600)
> Maven home: /usr/share/maven3/apache-maven-3.0.3
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-28-generic", arch: "amd64", family: "unix"
>Reporter: Jeff Benton
>
> My site deploy failed with a null pointer exception.
> {noformat}
> [INFO] --- maven-site-plugin:3.0-beta-3:deploy (default-deploy) @ xxx ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.0-beta-3,
> parent: sun.misc.Launcher$AppClassLoader@6d6f0472]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy' with basic
> configurator -->
> [DEBUG] (f) chmod = true
> [DEBUG] (f) chmodMode = g+w,a+rX
> [DEBUG] (f) chmodOptions = -Rf
> [DEBUG] (f) inputDirectory = xxx
> [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@76f1fad1
> [DEBUG] (f) project = MavenProject: xxx:xxx:1.7.3-SNAPSHOT @ xxx/pom.xml
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@6d1576d7
> [DEBUG] -- end configuration --
> [DEBUG] The site will be deployed to url 'scp:///' with id
> ''
> [DEBUG] repository protocol scp
> [DEBUG] getProxy 'protocol' : scp
> [DEBUG] getProxy 'protocol' : scp no ProxyInfo found
> [DEBUG] found proxyInfo null
> [DEBUG] authenticationInfo with id '' :
> [DEBUG] configureWagon
> [DEBUG] configureWagon server hope
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.455s
> [INFO] Finished at: Wed Mar 16 11:03:25 CDT 2011
> [INFO] Final Memory: 14M/198M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy)
> on project xxx: Execution default-deploy of goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project xxx: Execution default-deploy of goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.code
[jira] Updated: (MSITE-488) site:attach shouldn't replace variables from site.xml
[ http://jira.codehaus.org/browse/MSITE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-488: -- Fix Version/s: 3.0-beta-4 > site:attach shouldn't replace variables from site.xml > - > > Key: MSITE-488 > URL: http://jira.codehaus.org/browse/MSITE-488 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site descriptor >Affects Versions: 2.1.1 >Reporter: Krashan Brahmanjara >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > Action site:deploy pushes site.xml to external location. > This action works ok but parse original site description and send different > to server. > For example orignal site.xml contain line > > sended file contain line > > instead.. > I suppose that developers expect that original file will be commited to maven > repository. -- 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-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-502:
--
Fix Version/s: 3.0-beta-4
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module, site descriptor
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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-510) Sitemap generates wrong links to project overview pages
[
http://jira.codehaus.org/browse/MSITE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-510:
--
Fix Version/s: 3.0-beta-4
> Sitemap generates wrong links to project overview pages
> ---
>
> Key: MSITE-510
> URL: http://jira.codehaus.org/browse/MSITE-510
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
>
> The sitemap creates links {{file:///project-info.html}} and
> {{file:///project-reports.html}} to the project-info and project-reports
> pages, ie the links are absolute and not relative to the site root.
--
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-273) Wrong url in banner left url when page has more 2 sub directories
[ http://jira.codehaus.org/browse/MSITE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-273: -- Fix Version/s: 3.0-beta-4 > Wrong url in banner left url when page has more 2 sub directories > - > > Key: MSITE-273 > URL: http://jira.codehaus.org/browse/MSITE-273 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.0-beta-6 > Environment: svn rev 599447 >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > Follow the following steps: > 1. go to http://maven.apache.org/repository/index.html or > http://maven.apache.org/developers/committer-environment.html > 2. and click on the Maven logo (top left) > 3. the page is http://maven.apache.org/ which is the correct behaviour > But try to reproduce the same with 2 sub directories in the url, like > http://maven.apache.org/guides/mini/guide-central-repository-upload.html > The url is http://maven.apache.org/guides/ instead of http://maven.apache.org/ -- 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-503) Site validation doesn't run against xml files processed by velocity
[ http://jira.codehaus.org/browse/MSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-503: -- Fix Version/s: 3.0-beta-4 > Site validation doesn't run against xml files processed by velocity > --- > > Key: MSITE-503 > URL: http://jira.codehaus.org/browse/MSITE-503 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Mike Youngstrom >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > If I turn on "validate" on my site plugin it correctly validates all of my > *.xml files. However, if I preprocess that xml file with velocity (files > named *.xml.vm). Then validation doesn't appear to run on these velocity > processed xdoc files. > To reproduce rename an xdoc file to xml.vm, give it a validation error and > see if the "validate" configuration catches it. -- 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-536) generateSitemap=true creates xdoc that fails to validate with validate=true
[
http://jira.codehaus.org/browse/MSITE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-536:
--
Fix Version/s: 3.0-beta-4
> generateSitemap=true creates xdoc that fails to validate with validate=true
> ---
>
> Key: MSITE-536
> URL: http://jira.codehaus.org/browse/MSITE-536
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
>Reporter: Mike Youngstrom
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: sitemap.xml
>
>
> I configured my site plugin with generateSitemap=true and validate=true.
> When I do so I get the error below. I've attached the generated sitemap.xml
> file.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-s
> ite) on project stack-concurrency-spring: Error during page generation: Error
> parsing 'D:\projects\s
> tack-3.0\stack-build\concurrency-spring\target\generated-site\xdoc\sitemap.xml':
> line [-1] Error val
> idating the model: Error:
> [ERROR] Public ID: null
> [ERROR] System ID: null
> [ERROR] Line number: 1
> [ERROR] Column number: 649
> [ERROR] Message: cvc-complex-type.2.4.a: Invalid content was found starting
> with element 'ul'. One o
> f '{"http://maven.apache.org/XDOC/2.0":li}' is expected.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plug
> ins:maven-site-plugin:3.0-beta-3:site (default-site) on project
> stack-concurrency-spring: Error duri
> ng page generation
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBu
> ilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBu
> ilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter
> .java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
> generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:127)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.j
> ava:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> ... 19 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> parsing 'D:\projects\stack-3
> .0\stack-build\concurrency-spring\target\generated-site\xdoc\sitemap.xml':
> line [-1] Error validatin
> g the model: Error:
> Public ID: null
> System ID: null
> Line number: 1
> Column number: 649
> Message: cvc-complex-type.2.4.a: Invalid content was found starting with
> element 'ul'. One of '{"h
> ttp://maven.apache.org/XDOC/2.0":li}' is expected.
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRendere
> r.java:418)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRen
> derer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.
> java:330)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:1
> 34)
> at
> org.apache.mav
[jira] Updated: (MSITE-244) Relative paths are losing their query parts
[ http://jira.codehaus.org/browse/MSITE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-244: -- Fix Version/s: 3.0-beta-4 > Relative paths are losing their query parts > --- > > Key: MSITE-244 > URL: http://jira.codehaus.org/browse/MSITE-244 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.0-beta-6 > Environment: Windows, French Locale, Maven 2.0.6, Site plugin > maven-site-plugin-2.0-beta-6-20070716.231146-1 >Reporter: Denis Cabasson >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: MSITE-test-case.zip > > > Urls are compared to project url and when necessary are transformed to > relative URLs. > In the process those trimmed url loose their query part. -- 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-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-458:
--
Fix Version/s: 3.0-beta-4
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: demo.tar.gz
>
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
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-535) Do not use project.url for relative link resolution
[ http://jira.codehaus.org/browse/MSITE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-535: -- Fix Version/s: 3.0-beta-4 Summary: Do not use project.url for relative link resolution (was: Do not use project.url for relativ link resolution) > Do not use project.url for relative link resolution > --- > > Key: MSITE-535 > URL: http://jira.codehaus.org/browse/MSITE-535 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement > Components: doxia integration, inheritance, relative links >Affects Versions: 2.2 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > IMO distributionManagement.site.url should be used instead. Imagine a > multi-module site with a distributionManagement url that points to the local > file system. A local deploy will move any child sites to sub-directories of > the parent (by default), but if you forget to adjust the project urls for all > children, the relative links are all wrong because they are calculated from > the project urls. There are numerous examples and JIRAs where people are > confused about this. Having to specify a url for each single child project is > a duplicate information and is also logically not necessary. Note that the > distributionManagement url always exists (otherwise the deploy will fail), > while the project url is optional. IMO the project url should not be used for > the local site generation at all, it is just a piece of user information. -- 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-429) Add Galician locale (gl) support
[ http://jira.codehaus.org/browse/MSITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-429: -- Description: Galician locales (gl, gl_ES), which apply to one of the four official languages of Spain (and native to more than 3 million people), are not supported out-of-the-box by Sun's Java Virtual Machine, but it can be added as a JVM extension, as you can read in http://www.javagalician.org Attached are the files to add Galician (gl) support to the Maven Site Plugin in order to be able to create maven sites in Galician language. was: Galician locales (gl, gl_ES), which apply to one of the four official languages of Spain (and native to more than 3 million people), are not supported out-of-the-box by Sun's Java Virtual Machine, but it can be added as a JVM extension, as you can read in http://www.javagalician.org Attached are the files to add Galician (gl) support to the Maven Site Plugin in order to be able to create maven sites in Galician language. Fix Version/s: 3.0-beta-4 > Add Galician locale (gl) support > > > Key: MSITE-429 > URL: http://jira.codehaus.org/browse/MSITE-429 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement > Components: internationalization >Affects Versions: 2.0.1 >Reporter: Daniel Fernández >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: project-info-report_gl.properties, > site-plugin_gl.properties, site-tool_gl.properties > > > Galician locales (gl, gl_ES), which apply to one of the four official > languages of Spain (and native to more than 3 million people), are not > supported out-of-the-box by Sun's Java Virtual Machine, but it can be added > as a JVM extension, as you can read in http://www.javagalician.org > Attached are the files to add Galician (gl) support to the Maven Site Plugin > in order to be able to create maven sites in Galician language. -- 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-417) CLONE -The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-417: -- Fix Version/s: 3.0-beta-4 > CLONE -The modules menu is not inherited if the parent project has no modules > of its own > > > Key: MSITE-417 > URL: http://jira.codehaus.org/browse/MSITE-417 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0 > Environment: ubuntu linux / debian linux >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: MSITE-417.zip > > > if I have a site.xml in a parent project that contains the line ref="modules" inherit="top" /> it is not inherited by child projects. > works, as does parent. > This happens when the parent project has no modules of its own. -- 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-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-159: -- Fix Version/s: 3.0-beta-4 > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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-423) item hrefs not relativised properly when inherited by child modules
[ http://jira.codehaus.org/browse/MSITE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-423: -- Fix Version/s: 3.0-beta-4 > item hrefs not relativised properly when inherited by child modules > --- > > Key: MSITE-423 > URL: http://jira.codehaus.org/browse/MSITE-423 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.1 > Environment: Linux, JDK 1.6.0_07, Maven 2.1.0 >Reporter: Robert Davey >Assignee: Lukas Theussl > Fix For: 2.3, 3.0-beta-4 > > Attachments: doxia-sitetools.patch, site-plugin_link-problem.tar.gz > > > See attachment for reproducible minimal case. > I have a multi-module project, for the sake of argument laid out thus: > * parent > ** pom.xml > * module1 > ** pom.xml > ** src/site/site.xml > ** apt/index.apt > > ** submodule1 >*** pom.xml >*** src/site/site.xml >*** apt/index.apt > I specify some links in our parent POM that I want to be inherited by all > child multi-modules. I would hope these links would always point to the > relevant html files in the super parent project for all children, no matter > the nesting level. > > > > > > These links work fine for the super parent menu. The same problem, outlined > below, is apparent whether the links are prefixed by "/" or "./" > When navigating down to module1, all the href links become: > ../module1 > Navigating again down to submodule1 of module1, the links become (or > something equally wacky): > ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../submodule1 > All the pom.xml files in each module refer to the staged url correctly, and > these don't seem to make any difference to the eventual href whatsoever... > e.g. > parent: http://server/ > module1: http://server/module1 > submodule1: http://server/module1/submodule1 -- 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: (MCHECKSTYLE-156) Plugin fails to build on Mac OS
[
http://jira.codehaus.org/browse/MCHECKSTYLE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260475#action_260475
]
Savas Ali Tokmen commented on MCHECKSTYLE-156:
--
Fixing this is as easy as:
{noformat}
com.puppycrawl.tools
checkstyle
5.3
com.sun
tools
{noformat}
> Plugin fails to build on Mac OS
> ---
>
> Key: MCHECKSTYLE-156
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-156
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: Mac OS X 10.6.6, java version "1.6.0_22"
>Reporter: Lukas Theussl
>
> Trying to build the plugin on Mac fails:
> {noformat}
> [ERROR] Failed to execute goal on project maven-checkstyle-plugin: Could not
> resolve dependencies for project
> org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.7-SNAPSHOT:
> Could not find artifact com.sun:tools:jar:1.5.0 at specified path
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar
> -> [Help 1]
> {noformat}
> The reason is apparently that the [checkstyle
> pom|http://repo1.maven.org/maven2/com/puppycrawl/tools/checkstyle/5.3/checkstyle-5.3.pom]
> declares a system dependency
> {code:xml}
>
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> which does not exist on Mac. On Mac OS, the tools.jar classes are included in
> classes.jar. There's no need for a systemPath dependency on Mac OS, all
> required classes are already in the runtime classes.jar.
--
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] Closed: (MCHECKSTYLE-156) Plugin fails to build on Mac OS
[
http://jira.codehaus.org/browse/MCHECKSTYLE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MCHECKSTYLE-156.
-
Resolution: Fixed
Fix Version/s: 2.7
Assignee: Lukas Theussl
Thanks. Fixed in [r1082399|http://svn.apache.org/viewvc?rev=1082399&view=rev]
> Plugin fails to build on Mac OS
> ---
>
> Key: MCHECKSTYLE-156
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-156
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: Mac OS X 10.6.6, java version "1.6.0_22"
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 2.7
>
>
> Trying to build the plugin on Mac fails:
> {noformat}
> [ERROR] Failed to execute goal on project maven-checkstyle-plugin: Could not
> resolve dependencies for project
> org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.7-SNAPSHOT:
> Could not find artifact com.sun:tools:jar:1.5.0 at specified path
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar
> -> [Help 1]
> {noformat}
> The reason is apparently that the [checkstyle
> pom|http://repo1.maven.org/maven2/com/puppycrawl/tools/checkstyle/5.3/checkstyle-5.3.pom]
> declares a system dependency
> {code:xml}
>
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> which does not exist on Mac. On Mac OS, the tools.jar classes are included in
> classes.jar. There's no need for a systemPath dependency on Mac OS, all
> required classes are already in the runtime classes.jar.
--
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
