[jira] Commented: (MCHECKSTYLE-97) Dependency Problem: commons-beanutils / antlr
[
http://jira.codehaus.org/browse/MCHECKSTYLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137794#action_137794
]
André Fügenschuh commented on MCHECKSTYLE-97:
-
"Why me, Lord?"
Here's the whole story, I try to explain it as short as possible, but keep on
reading, the result is very interesting.
After faking my settings, running {{mvn checkstyle:checkstyle}} I get a simple
'fresh' repo - and it *works*!
Manually comparing the artifacts with my original local repo, I found a dozen
differences.
The ones that strikes me most were:
missing artifacts for
- commons-lang-1.0 (just a pom)
- junit-3.7 (just a pom, either)
and *most important*
- checkstyle-4.4.jar
has a different size and different compilation date!
So, I copied the _new_ {{checkstyle-4.4}} to my original local repo, ran {{mvn
checkstyle:checkstyle}}, the two missing poms mentioned above were downloaded -
and it *works*!
I'm using Checkstyle for years now (for Ant based projects), so by the time I
started migrating to Maven I imported the 4.4 version manually into my local
repo (compilation date: 2007-12-17, that was short after release date, if I
remember rightly), and get it running successfully with Maven 2.0.8 and
checkstyle-plugin 2.1!
The _new_ {{checkstyle-4.4.jar}} (from central repo) has a different size and a
different compilation date: 2008-02-20!
Do You have any additional information about this?
Especially: if its not the Maven team that is responsible for the new
compilation of an identical Checkstyle release, I suggest this should be
reported to the Checkstyle team.
Thanks for investigating, and sorry for stealing (a bit of) Your time ;)
Regards,
André
> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
> Attachments: checkstyle-dependencies.zip
>
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO]
>
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: ja
[jira] Commented: (MSITE-330) Wagon nukes the permission bits of uploaded files.
[
http://jira.codehaus.org/browse/MSITE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137781#action_137781
]
Dennis Lundberg commented on MSITE-330:
---
Perhaps you have a server section in your settings.xml that overrides the file
permissions?
Something like this:
{code:xml}
myUserId
apache.website
775
664
{code}
> Wagon nukes the permission bits of uploaded files.
> --
>
> Key: MSITE-330
> URL: http://jira.codehaus.org/browse/MSITE-330
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Reporter: Henning Schmiedehausen
>
> Uploading a site using wagon might nuke permission bits of e.g. CGI scripts
> thus making these unavailable.
> For Apache webserver, a CGI script can have the permission bit set and is
> then executed. This is e.g. used for the "download.cgi" script on many Apache
> project sites.
> The wagon uploader (at least ssh and ssh-external) unconditionally change the
> permissions of all files to be 664. Which kills the execution bits. Which is
> bad (TM).
--
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-316) Broken links to submodules when staging site
[ http://jira.codehaus.org/browse/MSITE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-316. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-7 Fixed in r664376. New 2.0-beta-7-SNAPSHOT deployed. Please verify. > Broken links to submodules when staging site > > > Key: MSITE-316 > URL: http://jira.codehaus.org/browse/MSITE-316 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module, relative links >Affects Versions: 2.0-beta-6 > Environment: Linux >Reporter: Martin von Gagern >Assignee: Dennis Lundberg > Fix For: 2.0-beta-7 > > Attachments: testcase.zip > > > The attached testcase has a broken link when staged, and the relative path to > it looks horrible. > I had assumed that recent development in maven-doxia-tools might have been to > address this issue, so I tried to reproduce with the latest SVN version. > There I hit MSITE-315, so I'm reporting this for 2.0-beta-6 as well. > You might want to make a staging testcase out of this, and have links > checked. I don't yet understand all the magic behind the integration tests, > so I didn't provide a patch for 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] Commented: (MSITE-316) Broken links to submodules when staging site
[ http://jira.codehaus.org/browse/MSITE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137778#action_137778 ] Dennis Lundberg commented on MSITE-316: --- The ugly relative paths are tracked by MSITE-275 > Broken links to submodules when staging site > > > Key: MSITE-316 > URL: http://jira.codehaus.org/browse/MSITE-316 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module, relative links >Affects Versions: 2.0-beta-6 > Environment: Linux >Reporter: Martin von Gagern > Attachments: testcase.zip > > > The attached testcase has a broken link when staged, and the relative path to > it looks horrible. > I had assumed that recent development in maven-doxia-tools might have been to > address this issue, so I tried to reproduce with the latest SVN version. > There I hit MSITE-315, so I'm reporting this for 2.0-beta-6 as well. > You might want to make a staging testcase out of this, and have links > checked. I don't yet understand all the magic behind the integration tests, > so I didn't provide a patch for 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-304) site:stage-deploy creates different directory structure than site:stage or site:site
[
http://jira.codehaus.org/browse/MSITE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MSITE-304:
Component/s: relative links
multi module
> site:stage-deploy creates different directory structure than site:stage or
> site:site
>
>
> Key: MSITE-304
> URL: http://jira.codehaus.org/browse/MSITE-304
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links
>Affects Versions: 2.0-beta-6
>Reporter: Benjamin Bentmann
>
> Given a parent and a child module, the regular site directory structure is
> {noformat}
>/
> child/
> {noformat}
> which is expected by all the inter-module links.
> In contrast, site:stage-deploy will create
> {noformat}
> /
> staging/
> child/
> staging/
> {noformat}
> instead of
> {noformat}
> /
> staging/
> child/
> {noformat}
> This is due to the configuration of the mojo paramter stagingSiteURL which is
> constructed by the site URL of the *current* project and appending a subdir
> like "staging". This is only usuable for the parent project, for child
> modules the subdir "staging" needs to be inserted before the subdir for the
> child module is appended.
>
--
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-287) Clarify/fix documentation about encoding for translated resource bundles.
[
http://jira.codehaus.org/browse/MSITE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137770#action_137770
]
Benjamin Bentmann commented on MSITE-287:
-
If I may change my mind: Go for option 3, i.e. require all properties to be in
ASCII (in particular, don't mention ISO-8859-1 if extended characters are not
allowed, this would add confusion). Contributors can create files using their
platform encoding and simply pass them through {{native2ascii}} before
submitting.
I previously misunderstood the reason that caused damage to the files edited by
Vincent. Files were changed by using some plugin/editor, that wasn't properly
configured. So far, the Maven community doesn't seem to have any convention
about file encoding so I believe that using ASCII is simply the most robust
choice to prevent further accidents to the resource bundles.
> Clarify/fix documentation about encoding for translated resource bundles.
> -
>
> Key: MSITE-287
> URL: http://jira.codehaus.org/browse/MSITE-287
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
>Affects Versions: 2.0-beta-6
>Reporter: Benjamin Bentmann
>Assignee: Dennis Lundberg
>Priority: Minor
>
> According to http://maven.apache.org/plugins/maven-site-plugin/i18n.html
> translators are expected to provide their properties files in UTF-8 encoding.
> However, the JRE reads properties files using ISO-8859-1 encoding (see [class
> javadoc for
> PropertyResourceBundle|http://java.sun.com/javase/6/docs/api/java/util/PropertyResourceBundle.html]).
> Either the documentation should be fixed to state ISO-8859-1 or it should be
> made clear why Maven requires another encoding than usual.
--
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: (ARCHETYPE-181) Missing class org/apache/commons/lang/StringUtils
[ http://jira.codehaus.org/browse/ARCHETYPE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphaël Piéroni closed ARCHETYPE-181. - Resolution: Not A Bug as stated in the comment > Missing class org/apache/commons/lang/StringUtils > - > > Key: ARCHETYPE-181 > URL: http://jira.codehaus.org/browse/ARCHETYPE-181 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.0-alpha-3 > Environment: mvn 2.0.9 > java 1.6_06 >Reporter: Andreas Höhmann > Attachments: 2008-06-05-trace.txt, mvn-debug.txt > > > mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes > -DgroupId=com.mycompany.app -DartifactId=my-app > > throws ... > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/lang/StringUtils > org.apache.commons.lang.StringUtils > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils > at > org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(R > esourceManagerImpl.java:165) > at > org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager > (RuntimeInstance.java:594) > Any ideas? -- 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: (MNG-3220) Allow managed dependencies to be imported into other projects
[ http://jira.codehaus.org/browse/MNG-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137764#action_137764 ] Bugittaa Pahasti commented on MNG-3220: --- To me it seems that what is currently implemented is "Allow dependency management entries to be imported into other projects" instead of "Allow managed dependencies to be imported into other projects". Perhaps this issue should be reopened? This is discussed in more detail in http://www.nabble.com/Trouble-with-import-scope-td17678013.html. > Allow managed dependencies to be imported into other projects > - > > Key: MNG-3220 > URL: http://jira.codehaus.org/browse/MNG-3220 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.7 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.0.9 > > > Managed dependencies can currently only be incorporated into a project from > another project via inheritance. This is problematic as it is often not > possible to include projects that have required dependencies as a parent. > This issue is being created to track proposals and the resolution of this > issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-287) Clarify/fix documentation about encoding for translated resource bundles.
[ http://jira.codehaus.org/browse/MSITE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137762#action_137762 ] Dennis Lundberg commented on MSITE-287: --- So where do we stand on this? 1. Submissions should use UTF-8 encoding. 2. Submissions should use ISO-8859-1 encoding and can make use of all accented characters in there. Characters not in there must use unicode escape sequences. 3. Submissions should use ISO-8859-1 encoding, but can only use US-ASCII characters. Any other characters, including accented characters included in Latin 1, must use unicode escape sequences. I vote for 2. > Clarify/fix documentation about encoding for translated resource bundles. > - > > Key: MSITE-287 > URL: http://jira.codehaus.org/browse/MSITE-287 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-6 >Reporter: Benjamin Bentmann >Priority: Minor > > According to http://maven.apache.org/plugins/maven-site-plugin/i18n.html > translators are expected to provide their properties files in UTF-8 encoding. > However, the JRE reads properties files using ISO-8859-1 encoding (see [class > javadoc for > PropertyResourceBundle|http://java.sun.com/javase/6/docs/api/java/util/PropertyResourceBundle.html]). > Either the documentation should be fixed to state ISO-8859-1 or it should be > made clear why Maven requires another encoding than usual. -- 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-228) Try and unable to resolve org.apache.maven.skins:maven-default-skin:jar:RELEASE when another skin is specified
[
http://jira.codehaus.org/browse/MSITE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137761#action_137761
]
Dennis Lundberg commented on MSITE-228:
---
Patrick, a skin is not a plugin - so I'd call it a feature, or at least the
expected behavior.
> Try and unable to resolve
> org.apache.maven.skins:maven-default-skin:jar:RELEASE when another skin is
> specified
> --
>
> Key: MSITE-228
> URL: http://jira.codehaus.org/browse/MSITE-228
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Stefano Bagnara
>
> 1) My project does not use external repositories for dependencies but only
> for plugins.
> 2) For dependencies I have a "stage" folder that is a "legacy structured"
> local repository I reference this way:
> {code}
> local-james-stage-m1
> Local James stage repository
> file://c:/lab/void/projects/server-trunk-modular/stage
> legacy
>
> true
> ignore
>
>
> true
> ignore
>
> {code}
> 3) in my site.xml I have this:
> {code}
> org.apache.james
> maven-skin
> 1.1-SNAPSHOT
> {code}
> 4) and in my local stage repository I have the
> org.apache.james/poms/maven-skin-1.1-SNAPSHOT.pom and
> org.apache.james/jars/maven-skin-1.1-SNAPSHOT.jar files.
> If I try to build the project, package it, run tests and everything else it
> works, but when I try to build "mvn site" if fails with this error:
> {code}
> [DEBUG] maven-default-skin: using locally installed snapshot
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] The skin does not exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
> org.apache.maven.skins:maven-default-skin:jar:RELEASE
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.BuildFailureException: The skin does not exist: Unable to
> determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
> org.apache.maven.skins:maven-default-skin:jar:RELEASE
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoFailureException: The skin does not
> exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins
> -DartifactId=maven-default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
> org.apache.maven.skins:maven-default-skin:jar:RELEASE
> at
> org.apache.maven.plugins.
[jira] Updated: (MJAVADOC-78) Add a flag to provide standard doclet parameters to custom ones too
[ http://jira.codehaus.org/browse/MJAVADOC-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-78: Attachment: JAVADOC-78.patch Here is a proposed patch. Is it enough for your use case? Could you also send us a test case, so I could include it? > Add a flag to provide standard doclet parameters to custom ones too > --- > > Key: MJAVADOC-78 > URL: http://jira.codehaus.org/browse/MJAVADOC-78 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Andrea Aime > Attachments: JAVADOC-78.patch > > > I'm working on a custom doclet that wraps the standard doclet and add extra > behaviour (automated class diagram generation in class javadocs and package > javadocs). I want to run it under maven 2, but I've stumbled against the > default behaviour: standard doclet parameters such as -link are provided only > if the javadoc is the standard one (in AbstractJavadocMojo.java, the check is > "if ( StringUtils.isEmpty( doclet ) ) ..."). > A generally good behaviour would be not perform assumptions, but to call > XXXDoclet.optionLength for each parameter, and see if the doclet accepts them > or not (and thus provide only the one accepted). As an alternative, add at > least a flag to allow the provision of the standard doclet parameters to the > custom ones as well. -- 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-312) Interpolation not working in inherited elements
[ http://jira.codehaus.org/browse/MSITE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137758#action_137758 ] Dennis Lundberg commented on MSITE-312: --- MSITE-135 is not fixed. It was slated to be included in the 2.0-beta-7 release, which has now been changed to 2.0-beta-8. The issue isn't fixed until the "Status" field says so. > Interpolation not working in inherited elements > --- > > Key: MSITE-312 > URL: http://jira.codehaus.org/browse/MSITE-312 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-7 > Environment: JDK 1.5.0_13 on OS/X 10.5.2 >Reporter: Brian Hanafee > Attachments: example.zip > > > Properties defined in the local POM are not interpolated into elements of the > site that are inherited. > In the attached example, the property "parentprop" is defined in the parent > POM and "childprop" is defined in the child POM. The parent project has a > site.xml that defines an inherited menu with items that reference both > properties. Only parentprop is interpolated. The child project has an > identical menu and the properties are interpolated 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-305) Left menu not generated when run site:site outside the pom.xm directory specifying the pom.xml location with -f maven argument
[ http://jira.codehaus.org/browse/MSITE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137757#action_137757 ] Dennis Lundberg commented on MSITE-305: --- I think this has been resolved in 2.0-beta-7-SNAPSHOT. Please give it a try. If it's not working, then please supply a sample project for this. > Left menu not generated when run site:site outside the pom.xm directory > specifying the pom.xml location with -f maven argument > -- > > Key: MSITE-305 > URL: http://jira.codehaus.org/browse/MSITE-305 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: Windows XP Professional Version 2002 Service Pack 2 >Reporter: Mael Caldas >Priority: Critical > > When a run the mvn site:site outside the root pom.xml 's directory, > specifying the location of the pom.xml with the -f argument, the site menu is > generated empty! > That is my dir structure: > My_CC_View\ >| >|My_CC_VOB\ > | > |project > > | > |___pom.xml > So, I go to the My_CC_View and run the command: > mvn -f My_CC_VOB/project/pom.xml site:site site:deploy > The build goes ok, the site is generated, but without the left menu > This is because I'm using Continuum with ClearCase, and the directory > structure is aways created like this on checkout, so I have to specify the > pom.xml file with the relative path, and continuum runs the maven commands on > the root view directory... and that is used as the basedir, not the pom.xml > 's dir... -- 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-318) site:deploy unable to utilize UNC paths
[ http://jira.codehaus.org/browse/MSITE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137756#action_137756 ] Dennis Lundberg commented on MSITE-318: --- Josh, is it OK with you if we close this issue now? > site:deploy unable to utilize UNC paths > --- > > Key: MSITE-318 > URL: http://jira.codehaus.org/browse/MSITE-318 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-6 > Environment: Windows XP >Reporter: Josh Peters >Priority: Minor > > Currently under windows, a UNC path (even one represented as a file:// URL) > cannot be written to. There seems to be something in the guts of Ant and > Maven that doesn't understand how to treat UNC paths as valid paths. > In an effort to avoid the "wontfix" status: mapping the UNC path as a network > drive is effective but terribly kludgey as a long-term solution. Different > developers in an organization _may_ have drives already mapped to something > else. Given a vanilla Windows network, UNC paths may be the best choice for > deploying sites. > Leaving this as a minor bug since it mainly affects internal projects of an > organization, but it is an important one as it can keep folks from adopting > Maven for use in corporate environments. -- 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-321) multi module, hierarichal project broken link in site and site:stage
[ http://jira.codehaus.org/browse/MSITE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137755#action_137755 ] Dennis Lundberg commented on MSITE-321: --- Can you elaborate on what it is that you think is broken and how you think it should work. You should never use *target/site* in a element. The element should show the destination of the published web site. > multi module, hierarichal project broken link in site and site:stage > > > Key: MSITE-321 > URL: http://jira.codehaus.org/browse/MSITE-321 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module, relative links >Affects Versions: 2.0-beta-6 > Environment: Mac OS X / maven 2.0.7 >Reporter: jens breitenstein > Attachments: maven-site-plugin-error.zip > > > when creating the documentation using "site" or "site:stage" all module links > are broken. Using the URL element only the first level can be fixed. Please > see attached sample ZIP containing a multi module project consisting of three > pom's which demonstrate the error. > Maybe this is closely related to "MSITE-316"? > -- 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-330) Wagon nukes the permission bits of uploaded files.
[ http://jira.codehaus.org/browse/MSITE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137754#action_137754 ] Dennis Lundberg commented on MSITE-330: --- Currently the site-plugin does this: chmod -Rf g+w,a+rX on the deployment directory. So it shoudn't remove any bits - just add them. > Wagon nukes the permission bits of uploaded files. > -- > > Key: MSITE-330 > URL: http://jira.codehaus.org/browse/MSITE-330 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Reporter: Henning Schmiedehausen > > Uploading a site using wagon might nuke permission bits of e.g. CGI scripts > thus making these unavailable. > For Apache webserver, a CGI script can have the permission bit set and is > then executed. This is e.g. used for the "download.cgi" script on many Apache > project sites. > The wagon uploader (at least ssh and ssh-external) unconditionally change the > permissions of all files to be 664. Which kills the execution bits. Which is > bad (TM). -- 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: (MSITE-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
fdk edited comment on MSITE-331 at 6/7/08 7:40 AM:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
. a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
So, the site web genereted is :
{code}
http://Mon site/a/myparent
http://Mon site/a/b/parent
http://Mon site/a/b/module1
http://Mon site/a/b/module2
http://Mon site/a/c/parent
http://Mon site/a/c/module1
http://Mon site/a/c/module2
{code}
Or the good one is :
{code}
http://Mon site/a/myparent
http://Mon site/a/b/parent
http://Mon site/a/b/module1
http://Mon site/a/c/parent
http://Mon site/a/c/module2
{code}
was (Author: fdk):
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
. a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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: (MSITE-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
fdk edited comment on MSITE-331 at 6/7/08 7:37 AM:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
. a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
was (Author: fdk):
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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: (MSITE-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
fdk edited comment on MSITE-331 at 6/7/08 7:36 AM:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
was (Author: fdk):
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
\t \t \t a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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: (MSITE-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
fdk edited comment on MSITE-331 at 6/7/08 7:35 AM:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
\t \t \t a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
was (Author: fdk):
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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: (MSITE-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
fdk edited comment on MSITE-331 at 6/7/08 7:32 AM:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parent a.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
was (Author: fdk):
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parenta.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137753#action_137753
]
Arnaud commented on MSITE-331:
--
I am sorry , in my description there is a error
To be more accurate I will use this expression "groupID:ArtifactId"
Exemple : org.apache.maven.plugins:plugins-parent
{code}
a:myparent
/ \
a.b:parenta.c:parent
/ \
a.b:module1 a.c:module2
{code}
i hope you can understand me ...
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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-268) Declaring a site with a file:// location one layer deep results in site-deploy failure
[ http://jira.codehaus.org/browse/MSITE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-268. - Resolution: Cannot Reproduce Please reopen and attach a sample project and provide more details if it's still not working for you. > Declaring a site with a file:// location one layer deep results in > site-deploy failure > -- > > Key: MSITE-268 > URL: http://jira.codehaus.org/browse/MSITE-268 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Tom Guyette > Attachments: MSITE-268.zip > > > To reproduce: > 1 - Create a project that has a declaration that uses a > file:///usr/local/test/ > 2 - Make sure the directory /usr/local/test exists and has appropriate write > permissions > 3 - Run site-deploy on the project > 4 - Receive error that looks something like this: > [INFO] [site:deploy] > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Opened > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Disconnecting > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Error copying directory structure > /usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar/./checkstyle.html > (No such file or directory) > 5 - Change the site such that maven will have to create *TWO NEW* > layers of directory, run site-deploy, note that it works! > 6 - Change the site such that maven will have to create ZERO new layers > of directory, run site-deploy, note that it also works! > site-deploy only seems to fail in the case where Maven has to create a single > subdirectory for the current project. It looks like wagon doesn't realize it > has to create the first layer of directory... possibly something to do with > explicit mention of "." as a directory in the wagon code. -- 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-268) Declaring a site with a file:// location one layer deep results in site-deploy failure
[ http://jira.codehaus.org/browse/MSITE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-268: -- Attachment: MSITE-268.zip Here's a sample project that works for me. > Declaring a site with a file:// location one layer deep results in > site-deploy failure > -- > > Key: MSITE-268 > URL: http://jira.codehaus.org/browse/MSITE-268 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Tom Guyette > Attachments: MSITE-268.zip > > > To reproduce: > 1 - Create a project that has a declaration that uses a > file:///usr/local/test/ > 2 - Make sure the directory /usr/local/test exists and has appropriate write > permissions > 3 - Run site-deploy on the project > 4 - Receive error that looks something like this: > [INFO] [site:deploy] > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Opened > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Disconnecting > file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar > - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Error copying directory structure > /usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar/./checkstyle.html > (No such file or directory) > 5 - Change the site such that maven will have to create *TWO NEW* > layers of directory, run site-deploy, note that it works! > 6 - Change the site such that maven will have to create ZERO new layers > of directory, run site-deploy, note that it also works! > site-deploy only seems to fail in the case where Maven has to create a single > subdirectory for the current project. It looks like wagon doesn't realize it > has to create the first layer of directory... possibly something to do with > explicit mention of "." as a directory in the wagon code. -- 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-302) mvn install site-deploy does not follow the reactor build sequence
[ http://jira.codehaus.org/browse/MSITE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137750#action_137750 ] Dennis Lundberg commented on MSITE-302: --- Can you provide a sample project for this? > mvn install site-deploy does not follow the reactor build sequence > -- > > Key: MSITE-302 > URL: http://jira.codehaus.org/browse/MSITE-302 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > Attachments: > OvereenkomstService_site-OvereenkomstService_site.1006-build.log > > > We have a multi pom project. We have one parent, one EJB and one Impl > project. The EJB project uses the Impl. The reactor sequence is Parent, EJB, > Impl. When first doing "mvn install" and then "mvn site-deploy" the build is > succesful. When doing "mvn install site-deploy" (on clean repository) the > build fails because it first builds the Ejb instead of the Impl. It won't > build because it is missing the installed Impl 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] Updated: (MSITE-82) M2 Site Plugin too strict about document structure
[ http://jira.codehaus.org/browse/MSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-82: - Issue Type: New Feature (was: Bug) > M2 Site Plugin too strict about document structure > -- > > Key: MSITE-82 > URL: http://jira.codehaus.org/browse/MSITE-82 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-4 > Environment: Java 1.5, WinXP SP2 >Reporter: John R Fallows > Fix For: 2.0-beta-8 > > > Site generation generally assumes total ownership of the generated HTML > content, such that complete HTML pages are expected to be generated. > Therefore, strict rules are specified when parsing APT documentation files as > input to site generation process, to make sure that APT files have full page > structure. > Unfortunately, this restriction is too brittle for Java.Net based Maven2 > projects that want to generate site documentation. > Java.Net adds chrome dynamically at runtime to all pages (not a problem) but > it also adds a project summary and a header for the project "Description" > around any HTML content in the top level index.html page for a project. > This means that the generated index.html page needs to have a structure such > as ...Next Section > As you can see, this is not a valid HTML document, but an HTML fragments. > Unfortunately, the APT parser is too strict to support the corresponding > index.apt syntax logically required to produce such an index.html. > Please allow the syntax checking during parsing to be relaxed as necessary to > achieve the desired generated HTML. > As mentioned by Brett, we could support out-of-order elements, but with > warnings This might be generally useful for fragment generation in general, > anywhere a server-side include could be used by the generated site. > However, if we take this approach, it would be useful to be able to still get > a clean build with no warnings, possibly by specifying which site files are > fragments so that warnings could still be generated for user errors in other > non-fragment pages. > Perhaps the .aptf extension could be used to indicate a fragment APT file. -- 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-307) Site generation broken with multi-module property inheritence
[
http://jira.codehaus.org/browse/MSITE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137749#action_137749
]
Dennis Lundberg commented on MSITE-307:
---
Can someone provide a sample project for this issue?
> Site generation broken with multi-module property inheritence
> -
>
> Key: MSITE-307
> URL: http://jira.codehaus.org/browse/MSITE-307
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.0-beta-6
> Environment: Ubuntu 7.10, Maven 2.0.8
>Reporter: Eric Ryan
>
> Maven2 site plugin inheritence
> I have a multi-module project with the following directory structure:
> my-app
> |
> |---my-client-ui
> | |
> | |---pom.xml
> |
> |---my-core
> | |
> | |---pom.xml
> |
> |---my-common
> | |
> | |---pom.xml
> |
> |---pom.xml
> I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in
> the parent pom. These properties are used by the child poms to resolve the
> parent pom (they are used in the tags). These properties are
> inherited by the children (as expected) when running goals such as clean,
> package, or install.
> I start to see problems when I try to use the site plugin. I first run the
> install goal to install my project's jars and poms into my local
> repo(~/.m2/repository/). I then verify that the jars and poms are in my
> local repo. When I try to run the site plugin it seems as though maven is
> unable to interpret the properties defined in the parent pom. I receive the
> following output for each module:
> [INFO]
>
> [INFO] Building my-client-ui
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] [site:site]
> Downloading:
> http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
> [WARNING] Unable to load parent project from repository: Failed to validate
> POM for project ${myGroupId}:${myArtifactId} at Artifact
> [${myGroupId}:${myArtifactId}:pom:${myVersion}]
> [INFO] Generating "Continuous Integration" report...
> I've tried using site:deploy, site:run, and site:stage. In all cases I
> recieve a sucessful build, but all sites generated contain broken links.
> (Note. parent pom's distributionManagement site url=file:///home/eric/tmp)
> When using site:deploy, there are two issues with the site. The first is
> that none of the modules are listed for the project on the left hand side of
> the screen. The second is that when I go to the Dependence Convergence
> section, the links to my project's modules are broken. In example, the link
> to my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui
> when it is in fact located at file:///home/eric/tmp/my-client-ui (Note.
> http://www.mycompany.com is defined in the parent pom as the project's url).
> site:run demonstrates the same problems as site:deploy.
> When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two
> issues w/ the site. The first is the same, none of the modules are listed on
> the left hand side of the screen. The second is also the same, except that
> the links in the Dependency Convergence section now point to
> file:///home/eric/localhost/home/eric/tmp/my-client-ui. This is incorrect
> because the files are actually located at
> file:///home/eric/tmp/localhost/home/eric/tmp/my-client-ui. It is missing
> the tmp directory in the url string.
> The only way I've been able to get the modules to be displayed on the left
> hand side of the screen is using mvn -N site site:deploy. In this case, the
> links point to the "correct" place (file:///home/eric/tmp/my-client-ui), but
> the submodule's sites are never build because of the -N (non-recursive) flag.
> Another thing to note is that the Dependency Convergence section is totally
> missing from this site.
> The only way I've been able to build a site with links that resolve properly
> is if I remove all instances of properties in all of my poms and replace them
> with hard coded values. In this case, the links for the modules do appear on
> the left hand side of the screen. The downfall to this approach is that the
> links in the Dependency Convergence section now point to
> http://www.mycompany.com/my-client-ui.
> From my discussion with others on the Maven mailing list, it seems as though
> some other users are experiencing this same issue with site property
> inheritence.
--
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 JIR
[jira] Closed: (MJAVADOC-191) Add a new Mojo for test-jar
[ http://jira.codehaus.org/browse/MJAVADOC-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-191. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.5 added new goal javadoc:test-jar, snapshot deployed > Add a new Mojo for test-jar > --- > > Key: MJAVADOC-191 > URL: http://jira.codehaus.org/browse/MJAVADOC-191 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.5 > > > Similar to JavadocJar, but for test -- 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-78) Add an option for google adsense
[ http://jira.codehaus.org/browse/MSITE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137747#action_137747 ] Dennis Lundberg commented on MSITE-78: -- Should this be configured once using parameters in the Site plugin, and then a suitable html-snippet should be applied to all the generated pages? Need to figure out how to handle this in Doxia... > Add an option for google adsense > > > Key: MSITE-78 > URL: http://jira.codehaus.org/browse/MSITE-78 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > > Would need to support the account id and channel id for adsense. We could > utilize the new custom element for the additional 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] Commented: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137746#action_137746 ] Dennis Lundberg commented on MSITE-256: --- Andreas, are you using Hudson as well? Can you provide a sample project? > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-SNAPSHOT -- 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-169) links to modules where not working if a modules dir is used
[ http://jira.codehaus.org/browse/MSITE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-169: -- Attachment: MSITE-169.zip I cannot reproduce this issue using the latest 2.0-beta-7-SNAPSHOT version of the Site plugin. The attached sample project works as expected. > links to modules where not working if a modules dir is used > --- > > Key: MSITE-169 > URL: http://jira.codehaus.org/browse/MSITE-169 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Mathias Brökelmann > Attachments: MNG-MSITE-169-maven-site-plugin.patch, MSITE-169.zip > > > I've to place the modules into a separate directory: > root/ > ..pom.xml > ..modules/ > module1 > module2 > this is supported by maven through > > modules/module1 > modules/module2 > > in pom. > but the site generation seems to be broken: > if mvn site-deploy is used the links to the modules contain > modules/module1/index.html which is ok but unfortunately the generated site > structure will be generated as follows: > root/ > ..module1 > ..module2 > The result is that the links do not work. > If I run mvn site-stage everything looks ok. The links doesn't contain > modules dir anymore and eveything is working. -- 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-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137743#action_137743
]
Dennis Lundberg commented on MSITE-275:
---
I used the sample-project attached to MSITE-195 to try this.
Using the latest 2.0-beta-7-SNAPSHOT this issue no longer seems to be a problem.
Can someone else please confirm this?
> site:stage for multimodule project creates wrong links
> ---
>
> Key: MSITE-275
> URL: http://jira.codehaus.org/browse/MSITE-275
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Debian testing,maven 2.0.8
>Reporter: Roman Kitko
>
> For multimodule project when I exec 'mvn site:stage
> -DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
> with path to project dir :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> When I exec mvn site", then index.html in target/site is correctly generated.
> There is workaround : use site-deploy and specify some property that is
> resolved in pom.xml as your deploy site url :
> mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
> My site.xml :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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-331) if parent project have the same artifactID (but different grouId) the site is not ok
[
http://jira.codehaus.org/browse/MSITE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-331:
--
Description:
When you have 2 parent project with the same artifactId, the site show all
their module on the page of both
Ex : some project like this :
{code}
1-Parent (groupId = A)
/\
Parent (A.B) Parent (B.C)
/\
module1 module2
{code}
When i do mvn site, module1 AND module2 are on the page of the parent with
groupId A.B ANS on the page of the parent with the groupId A.C
There is an exemple in the zip file:
Just run mvn site on the top project "1-parent" and look the page :
"1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
Normaly, there is ONE module but here, its doesn't work.
was:
When you have 2 parent project with the same artifacID, the site show all their
module on the page of both
Ex : some project like this :
1-Parent (groupId = A)
/\
Parent (A.B)Parent (B.C)
/ \
module1module2
When i do mvn site, module1 AND module2 are on the page of the parent with
groupId A.B ANS on the page of the parent with the groupId A.C
There is an exemple in the zip file:
Just run mvn site on the top project "1-parent" and look the page :
"1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
Normaly, there is ONE module but here, its doesn't work.
Add formating
> if parent project have the same artifactID (but different grouId) the site
> is not ok
> -
>
> Key: MSITE-331
> URL: http://jira.codehaus.org/browse/MSITE-331
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Windows, Maven 2.0.8
>Reporter: Arnaud
> Attachments: 1.zip
>
>
> When you have 2 parent project with the same artifactId, the site show all
> their module on the page of both
> Ex : some project like this :
> {code}
> 1-Parent (groupId = A)
>/\
> Parent (A.B) Parent (B.C)
> /\
> module1 module2
> {code}
> When i do mvn site, module1 AND module2 are on the page of the parent with
> groupId A.B ANS on the page of the parent with the groupId A.C
> There is an exemple in the zip file:
> Just run mvn site on the top project "1-parent" and look the page :
> "1/2/parent/target/site/index.html" AND "1/3/parent/target/site/index.html"
> Normaly, there is ONE module but here, its doesn't work.
--
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-238) multi project default URL is wrong
[ http://jira.codehaus.org/browse/MSITE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137741#action_137741 ] Dennis Lundberg commented on MSITE-238: --- Can you provide a sample project that demonstrates exactly was is wrong. Are you talking about the element in the pom? How did you go about finding its value if it isn't specified anywhere? > multi project default URL is wrong > -- > > Key: MSITE-238 > URL: http://jira.codehaus.org/browse/MSITE-238 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Reporter: Paul Sundling >Priority: Trivial > > In multi module projects the default URL if non is included is > //target/site//index.html , but it > should be ///target/site/index.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-195. - Assignee: Dennis Lundberg Resolution: Cannot Reproduce > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Assignee: Dennis Lundberg >Priority: Minor > Attachments: MSITE-195.zip > > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- 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-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-195: -- Attachment: MSITE-195.zip Sample project that works for me using Maven 2.0.8 and the latest 2.0-beta-7-SNAPSHOT of the Site plugin. > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Priority: Minor > Attachments: MSITE-195.zip > > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- 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-335) Use maven-doxia-tools 1.0.1
Use maven-doxia-tools 1.0.1 --- Key: MSITE-335 URL: http://jira.codehaus.org/browse/MSITE-335 Project: Maven 2.x Site Plugin Issue Type: Task Affects Versions: 2.0-beta-7 Reporter: Dennis Lundberg Fix For: 2.0-beta-7 -- 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-335) Use maven-doxia-tools 1.0.1
[ http://jira.codehaus.org/browse/MSITE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-335: -- Assignee: Dennis Lundberg Fix Version/s: 2.0-beta-7 > Use maven-doxia-tools 1.0.1 > --- > > Key: MSITE-335 > URL: http://jira.codehaus.org/browse/MSITE-335 > Project: Maven 2.x Site Plugin > Issue Type: Task >Affects Versions: 2.0-beta-7 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.0-beta-7 > > -- 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-332) SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
[
http://jira.codehaus.org/browse/MSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MSITE-332.
-
Resolution: Fixed
Thanks Benjamin. I've updated the Site plugin to use the latest version of
maven-doxia-tools.
> SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
> ---
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project
> directory.
> This started occurring last night for us, using
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] SiteToolException: Error reading default site descriptor:
> ${OUTPUTENCODING}
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error reading
> default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:527)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226)
> ... 20 more
> Caused by: java.io.UnsupportedEncodingException: ${OUTPUTENCODING}
> at sun.io.Converters.getConverterClass(Converters.java:218)
> at sun.io.Converters.newConverter(Converters.java:251)
> at
> sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:68)
> at sun.nio.cs.StreamDecoder$ConverterSD.(StreamDecoder.java:224)
> at sun.nio.cs.StreamDecoder$ConverterSD.(StreamDecoder.java:210)
>
[jira] Commented: (MSITE-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137738#action_137738
]
Dennis Lundberg commented on MSITE-227:
---
How do you specify and in the parent and child
POMs?
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-332) SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
[
http://jira.codehaus.org/browse/MSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137736#action_137736
]
Benjamin Bentmann commented on MSITE-332:
-
Fixed for maven-doxia-tools in
[r664309|http://svn.apache.org/viewvc?view=rev&revision=664309]. Fixing this
for the Site Plugin requires as such a new release of the Doxia Tools.
> SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
> ---
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project
> directory.
> This started occurring last night for us, using
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] SiteToolException: Error reading default site descriptor:
> ${OUTPUTENCODING}
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error reading
> default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:527)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226)
> ... 20 more
> Caused by: java.io.UnsupportedEncodingException: ${OUTPUTENCODING}
> at sun.io.Converters.getConverterClass(Converters.java:218)
> at sun.io.Converters.newConverter(Converters.java:251)
> at
> sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:68)
> at sun.nio.cs.StreamDecoder$
[jira] Updated: (MSITE-293) Submodule inherit menu but this should not happend
[ http://jira.codehaus.org/browse/MSITE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-293: -- Component/s: site descriptor inheritance > Submodule inherit menu but this should not happend > -- > > Key: MSITE-293 > URL: http://jira.codehaus.org/browse/MSITE-293 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, site descriptor >Affects Versions: 2.0-beta-6 > Environment: maven 2.0.8 > jdk 1.6 > windows >Reporter: Andreas Höhmann >Priority: Critical > > Projectstructur: > modul > | pom.xml > | src/site/site.xml > | src/site/xdoc/index.xml > +-- submodul 1 > | pom.xml > | src/site/xdoc/index.xml > +-- submodul 2 > | pom.xml > | src/site/xdoc/index.xml > modul :: site.xml > ... > > > > > > > > > > > > > >href="http://lp2p067c:82/maven2/repositories/"; /> > > > > > > ... > after "mvn clean install site" each submodules has a menu "Maven" ... but i > want this only for the "main-modul". > whats wrong? > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > ... Inheritance ... "By default, only the basic settings are inherited. From > the body, only the links are inherited, and these accumulate to contain all > the parents' site descriptor links." -- 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-297) Child site.xml not used from parent + inheritance
[ http://jira.codehaus.org/browse/MSITE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-297. - Resolution: Duplicate > Child site.xml not used from parent + inheritance > - > > Key: MSITE-297 > URL: http://jira.codehaus.org/browse/MSITE-297 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > > When using a parent child project building from the parent, the child > site.xml is not used. Instead I get the parent lay-out with menu's I don't > want and links that won't work. -- 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-262) site.xml not inherited if build run from parent
[ http://jira.codehaus.org/browse/MSITE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-262. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-7 Thanks to the fix for MSHARED-18, Cameron's sample project now work correctly with the latest 2.0-beta-7-SNAPSHOT. > site.xml not inherited if build run from parent > --- > > Key: MSITE-262 > URL: http://jira.codehaus.org/browse/MSITE-262 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-6 >Reporter: Cameron Jones >Assignee: Dennis Lundberg > Fix For: 2.0-beta-7 > > Attachments: MSITE-262.zip > > > I've seen that the site.xml is not being inherited in a module when the build > is run from the parent - when run from the module itself the inheritance > works correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-332) SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
[
http://jira.codehaus.org/browse/MSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MSITE-332:
Summary: SiteToolException: Error reading default site descriptor:
${OUTPUTENCODING} (was: Unable to load parent project from a relative path:
Could not find the model file '/pom.xml'. for project unknown)
> SiteToolException: Error reading default site descriptor: ${OUTPUTENCODING}
> ---
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project
> directory.
> This started occurring last night for us, using
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] SiteToolException: Error reading default site descriptor:
> ${OUTPUTENCODING}
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error reading
> default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:527)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226)
> ... 20 more
> Caused by: java.io.UnsupportedEncodingException: ${OUTPUTENCODING}
> at sun.io.Converters.getConverterClass(Converters.java:218)
> at sun.io.Converters.newConverter(Converters.java:251)
> at
> sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:68)
> at sun.nio.cs.StreamDecoder$ConverterSD.(StreamD
[jira] Commented: (MSITE-332) Unable to load parent project from a relative path: Could not find the model file '/pom.xml'. for project unknown
[
http://jira.codehaus.org/browse/MSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137732#action_137732
]
Benjamin Bentmann commented on MSITE-332:
-
bq. Benjamin can you shed some light on why that change was made?
The intention was to make the resource reading platform independent. However, I
wasn't aware of the special encoding value in the {{default-site.xml}}, sorry.
The fix will be to use a fixed encoding, e.g. {{IOUtil.toString(stream,
"UTF-8"]}}, instead of encoding detection. This is perfectly valid for the
{{default-site.xml}} since this file is under our control, i.e. we know the
employed encoding.
I will commit this change today once I have some unit test for this in place.
> Unable to load parent project from a relative path: Could not find the model
> file '/pom.xml'. for project unknown
> --
>
> Key: MSITE-332
> URL: http://jira.codehaus.org/browse/MSITE-332
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 2.0-beta-7
>Reporter: Michael Stevens
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-7
>
> Attachments: MSITE-332.tar.gz
>
>
> Execute site:site
> The plugin seems to look for a pom file in the directory above the project
> directory.
> This started occurring last night for us, using
> maven-site-plugin:2.0-beta-7-SNAPSHOT.
> Note that the project in question uses a parent POM, but does not specify a
> relative path.
> Here is the stack trace:
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file 'c:\workdir\projects\pom.xml'. for project unknown
> [INFO] Parent project loaded from repository.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] SiteToolException: Error reading default site descriptor:
> ${OUTPUTENCODING}
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error reading default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:230)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error reading
> default site descriptor: ${OUTPUTENCODING}
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:527)
> at
> org.apache.mav
[jira] Closed: (MSITE-132) Use instead of for staged directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-132. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-8 Patch applied in r664306. Thanks! > Use instead of for staged directories > - > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller >Assignee: Dennis Lundberg > Fix For: 2.0-beta-8 > > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artifactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-132) Use instead of for staged directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-132: -- Description: The of a project in the POM may contain characters that cause trouble when used in directory names. E.g. my open-source project: http://svn.projxpert.com/mmm/trunk/ Uses names such as "MMM::Configuration". Now when I stage the site of the entire project, the relative link "MMM::Configuration" causes mozilla to say something like "Unknown protocol 'mmm:'". Could you please use the artifactId instead. I think personally think that this is a lot better anyways. BTW - Thanks for your greate work. M2 is awesome!!! was: The of a project in the POM may contain characters that cause trouble when used in directory names. E.g. my open-source project: http://svn.projxpert.com/mmm/trunk/ Uses names such as "MMM::Configuration". Now when I stage the site of the entire project, the relative link "MMM::Configuration" causes mozilla to say something like "Unknown protocol 'mmm:'". Could you please use the artefactId instead. I think personally think that this is a lot better anyways. BTW - Thanks for your greate work. M2 is awesome!!! Summary: Use instead of for staged directories (was: Use instead of for directories) > Use instead of for staged directories > - > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artifactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-131) Not inheriting the site settings for distributionManagement from a super pom
[
http://jira.codehaus.org/browse/MSITE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MSITE-131.
-
Resolution: Cannot Reproduce
For a working example of this check the setup for Maven plugins that uses this
exact mechanism. The parent has distributionManagement set up like this:
{code:xml}
apache.website
scp://people.apache.org/www/maven.apache.org/plugins/
{code}
And the plugins don't have any distributionManagement set up in their own pom.
> Not inheriting the site settings for distributionManagement from a super pom
>
>
> Key: MSITE-131
> URL: http://jira.codehaus.org/browse/MSITE-131
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Reporter: Malcolm Wong Ho
>
--
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-270) site.xml: menus inherited that should not
[ http://jira.codehaus.org/browse/MSITE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-270: -- Component/s: site descriptor inheritance > site.xml: menus inherited that should not > - > > Key: MSITE-270 > URL: http://jira.codehaus.org/browse/MSITE-270 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, site descriptor >Affects Versions: 2.0-beta-6 >Reporter: Jörg Hohwiller > Attachments: site-inherit-bug.zip > > > I have a project with multiple levels of modules. > In the toplevel project I declare a site-descriptor with some general menu's > that have no inherit attribute (I also tried inherit='none') together with > > > > Now a module of the toplevel project that itself has modules declares a > site-descriptor with an additional regular menu that is inherited. > However the site of that module contains the menus from the toplevel project > that are NOT declared to be inherited. -- 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-97) Dependency Problem: commons-beanutils / antlr
[
http://jira.codehaus.org/browse/MCHECKSTYLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137725#action_137725
]
Dennis Lundberg commented on MCHECKSTYLE-97:
Thanks for the sample project André, that is really helpful.
I think that you have something wrong in your local repository, because the
sample projects works just fine for me. I'd like you to try this:
Delete the following directories from your local repository (usually in
${user.home}/.m2/repository/)
* antlr
* commons-beanutils
* org/apache/maven/plugins/maven-checkstyle-plugin/
Run 'mvn clean' and then 'mvn checkstyle:checkstyle' on your sample project.
For me the first invocation of Maven downloads maven-checkstyle-plugin 2.2. The
second invocation downloads antlr 2.7.6 and commons-beanutils-core 1.7.0.
> Dependency Problem: commons-beanutils / antlr
> -
>
> Key: MCHECKSTYLE-97
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-97
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: W2K, Java 6u6, Maven 2.0.9
>Reporter: André Fügenschuh
>Priority: Minor
> Attachments: checkstyle-dependencies.zip
>
>
> I guess this issue is a follow-up to *MCHECKSTYLE-90*.
> With version 2.2, I get the following errors running 'checkstyle:checkstyle':
> 1) commons-beanutils
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] org/apache/commons/beanutils/Converter
> org.apache.commons.beanutils.Converter
> [INFO]
>
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:839)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:635)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.beanutils.Converter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>
