[jira] (MNG-5085) Add a CLI option to ignore missing modules
[ https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306329#comment-306329 ] Ivan commented on MNG-5085: --- Paul, Of course it is related to our process and I understand this is a feature request not a bug. Regarding the "building the whole thing" I don't think using hudson/jenkins would solve my problem: My idea was that a developer should be able to generate a version for testing/demo with its modified sources. I can't see how hudson could be able to pickup sources in its workspace and the missing module sources in the SCM. And, further more, that means a developer can't build the software if he has not access to hudson. (which is likely to happen often in our case) Anyway, I will simply stick to the "use profile" solution for now. Thanks for your feedback > Add a CLI option to ignore missing modules > -- > > Key: MNG-5085 > URL: https://jira.codehaus.org/browse/MNG-5085 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Stephan Pauxberger > > Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. > we do not checkout the whole project. Example: > Full Project (as in Repository): > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B > pom.xml > Now, do a checkout (svn co xxx --depth children; svn update --set-depth > inifity A) > Working Copy: > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B (no pom!!, since we only did a sparse checkout) > Now, this setup is not buildable, since maven complains (rightfully) about a > missing pom for B. > What I propose is an option to change this behaviour with a command-line > option (-imm, --ignore-missing-modules) that would simply ignore missing > modules during pom resolution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-298) Confluence: Problem with relative links
[ https://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306333#comment-306333 ] Tuukka Mustonen commented on DOXIA-298: --- Opened a new ticket for the problem identified in Valter's comment. See DOXIA-476. > Confluence: Problem with relative links > --- > > Key: DOXIA-298 > URL: https://jira.codehaus.org/browse/DOXIA-298 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel >Assignee: Lukas Theussl > Fix For: 1.1.1 > > Attachments: MNG-298-module-confluence.patch, > MNG-298-module-confluence.patch > > > Relative links, for example [Overview|overview/index] are not generated > correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5280) Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3)
[ https://jira.codehaus.org/browse/MNG-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306338#comment-306338 ] Stephen Connolly commented on MNG-5280: --- Integration test added to core it suite in r1373759 > Inconsistent order of repositories and pluginRepositories from profiles in > settings (regression Maven 3) > > > Key: MNG-5280 > URL: https://jira.codehaus.org/browse/MNG-5280 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.3, 3.0.4 > Environment: Mac OS 10.7 and Windows XP > Java 1.6.0 >Reporter: Anders Hammar > Attachments: fake-maven-plugin-1.0.jar, MNG-5280-IT.patch, > MNG-5280-maven-model-builder.patch > > > Repositories and pluginRepositories defined in profiles in settings.xml are > not order consistently. This is a regression compared to Maven 2. > Scenario: > * Settings.xml defines two profiles, A and B (in this order). > * Both profiles define a repository and a pluginRepository, > A-repo/A-pluginrepo and B-repo/B-pluginrepo respectively. > When checking the effective pom (help:effective-pom) the resulting list of > repositories and pluginRepositories shows that they are not ordered > consistently. The order is B-repo, A-repo and A-pluginrepo, B-pluginrepo > respectively. With Maven 2.2.1 they are ordered consistently (and what I > argue is correct): B-repo, A-repo and B-pluginrepo, A-pluginrepo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5280) Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3)
[ https://jira.codehaus.org/browse/MNG-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MNG-5280. - Resolution: Fixed Fix Version/s: 3.0.5 r1373761 > Inconsistent order of repositories and pluginRepositories from profiles in > settings (regression Maven 3) > > > Key: MNG-5280 > URL: https://jira.codehaus.org/browse/MNG-5280 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.3, 3.0.4 > Environment: Mac OS 10.7 and Windows XP > Java 1.6.0 >Reporter: Anders Hammar > Fix For: 3.0.5 > > Attachments: fake-maven-plugin-1.0.jar, MNG-5280-IT.patch, > MNG-5280-maven-model-builder.patch > > > Repositories and pluginRepositories defined in profiles in settings.xml are > not order consistently. This is a regression compared to Maven 2. > Scenario: > * Settings.xml defines two profiles, A and B (in this order). > * Both profiles define a repository and a pluginRepository, > A-repo/A-pluginrepo and B-repo/B-pluginrepo respectively. > When checking the effective pom (help:effective-pom) the resulting list of > repositories and pluginRepositories shows that they are not ordered > consistently. The order is B-repo, A-repo and A-pluginrepo, B-pluginrepo > respectively. With Maven 2.2.1 they are ordered consistently (and what I > argue is correct): B-repo, A-repo and B-pluginrepo, A-pluginrepo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MNG-5207: Attachment: mng5207-it.tgz IT test to be integrated into the core-it-suite. Succeeds with M221, fails with M304. > [Regression] Maven 3 fails to calculate proper build order > -- > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Joerg Schaible >Priority: Critical > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-902) Allow M
Chris Rankin created SUREFIRE-902: - Summary: Allow M Key: SUREFIRE-902 URL: https://jira.codehaus.org/browse/SUREFIRE-902 Project: Maven Surefire Issue Type: New Feature Reporter: Chris Rankin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-902) Allow M
[ https://jira.codehaus.org/browse/SUREFIRE-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin closed SUREFIRE-902. - Resolution: Incomplete > Allow M > --- > > Key: SUREFIRE-902 > URL: https://jira.codehaus.org/browse/SUREFIRE-902 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Chris Rankin > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-903) Execute tests by group as well as by class
Chris Rankin created SUREFIRE-903:
-
Summary: Execute tests by group as well as by class
Key: SUREFIRE-903
URL: https://jira.codehaus.org/browse/SUREFIRE-903
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.12.2
Environment: Maven 3, TestNG 6.7, NetBeans 7.2
Reporter: Chris Rankin
Similar to SUREFIRE-577, only execute methods on a class if they belong to a
certain group or groups.
NetBean's "Test File" action invokes a particular TestNG class via
{{-Dtest=className}}. However, this completely ignores the TestNG groups and
executes _every_ {{@Test}}, including {{@BeforeClass}} methods that were
supposed to have been excluded (and mutually exclusive!).
Using {{-Dgroups=...}} respects the grouping but also executes all classes,
whereas I am trying to debug only one class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-903) Execute tests by group as well as by class
[
https://jira.codehaus.org/browse/SUREFIRE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306355#comment-306355
]
Chris Rankin commented on SUREFIRE-903:
---
Perhaps via extended syntax like {{-Dtest=MyClass@group1+group2}}.
> Execute tests by group as well as by class
> --
>
> Key: SUREFIRE-903
> URL: https://jira.codehaus.org/browse/SUREFIRE-903
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 2.12.2
> Environment: Maven 3, TestNG 6.7, NetBeans 7.2
>Reporter: Chris Rankin
>
> Similar to SUREFIRE-577, only execute methods on a class if they belong to a
> certain group or groups.
> NetBean's "Test File" action invokes a particular TestNG class via
> {{-Dtest=className}}. However, this completely ignores the TestNG groups and
> executes _every_ {{@Test}}, including {{@BeforeClass}} methods that were
> supposed to have been excluded (and mutually exclusive!).
> Using {{-Dgroups=...}} respects the grouping but also executes all classes,
> whereas I am trying to debug only one class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5213) Maven reported incorrect "total time" of the build
[
https://jira.codehaus.org/browse/MNG-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306364#comment-306364
]
Tomas Klubal commented on MNG-5213:
---
It looks like maven is reporting on the processor time rather than user time
(was running this on Linux Centos 6.2).
I have started maven like this (using time command to measure the time):
time mvn clean install -Pci,coverage
...
And this was the result:
...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:55.327s
[INFO] Finished at: Thu Aug 16 14:58:10 BST 2012
[INFO] Final Memory: 63M/382M
[INFO]
real1m56.169s
user2m46.911s
sys 0m9.420s
> Maven reported incorrect "total time" of the build
> --
>
> Key: MNG-5213
> URL: https://jira.codehaus.org/browse/MNG-5213
> Project: Maven 2 & 3
> Issue Type: Bug
> Environment: [cstamas@marvin nexus (timeline-into-plugin)]$ mvn -v
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/share/maven
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "i386", family: "mac"
>Reporter: Tamás Cservenák
>
> Maven reported incorrect "total time" of the build.
> I started a "full" build (all of the ITs enabled) of Nexus OSS. It is known
> to take over two hours. But when I returned to my machine, this was the
> output:
> {noformat}
> ...
> [INFO] Nexus : Core Plugins : Migration Plugin : Packaging SUCCESS [5.872s]
> [INFO] Nexus : Core Plugins : Migration Plugin : Test harness SUCCESS
> [44:45.692s]
> [INFO] Nexus : Launcher .. SUCCESS [4.120s]
> [INFO] Nexus : Clients : Lightweight REST SUCCESS [0.057s]
> [INFO] Nexus : Clients : Lightweight REST : Common ... SUCCESS [1.545s]
> [INFO] Nexus : Clients : Lightweight REST : ITs .. SUCCESS [2.550s]
> [INFO] Nexus : Clients : Lightweight REST : Staging/BP ... SUCCESS [3.347s]
> [INFO] Nexus : Clients : Lightweight REST : M2 Settings .. SUCCESS [2.656s]
> [INFO] Nexus : Clients : Lightweight REST : Core . SUCCESS [3.509s]
> [INFO] Nexus : Distros : Nexus OSS Bundle Tattletale . SUCCESS [10.448s]
> [INFO] Nexus : Stories ... SUCCESS [0.876s]
> [INFO] Nexus : Test Harness : Core ITs ... SUCCESS [1:48.181s]
> [INFO] Nexus : Maven Plugins : Parent SUCCESS [0.075s]
> [INFO] Nexus : Maven Plugins : Nexus . SUCCESS [19.127s]
> [INFO] Nexus : Aggregator SUCCESS [24.694s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1:15:25.587s
> [INFO] Finished at: Thu Dec 08 00:15:39 CET 2011
> [INFO] Final Memory: 135M/368M
> [INFO]
>
> [cstamas@marvin nexus (timeline-into-plugin)]$ date
> 2011 Dec 8 Csü 00:25:07 CET
> {noformat}
> The "total time" reported of 1 hour 15 minutes is clearly wrong: just look
> the two modules:
> * Nexus : Core Plugins : Migration Plugin : Test harness took 44 minutes.
> * Nexus : Test Harness : Core ITs took 1 hour 48 minutes.
> And, we _know_ (CI confirms too) that this build should take over than two
> hours.
> One thing to remark: the build was started before, but did finish after
> midnight
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5085) Add a CLI option to ignore missing modules
[ https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306366#comment-306366 ] Paul Benedict commented on MNG-5085: Ivan, have you considered private branches for your developers? It is a great help on large projects because large projects cannot tolerate work that isn't ready for integration. This will then allow Hudson to build "the whole thing" and test/demo. > Add a CLI option to ignore missing modules > -- > > Key: MNG-5085 > URL: https://jira.codehaus.org/browse/MNG-5085 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Stephan Pauxberger > > Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. > we do not checkout the whole project. Example: > Full Project (as in Repository): > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B > pom.xml > Now, do a checkout (svn co xxx --depth children; svn update --set-depth > inifity A) > Working Copy: > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B (no pom!!, since we only did a sparse checkout) > Now, this setup is not buildable, since maven complains (rightfully) about a > missing pom for B. > What I propose is an option to change this behaviour with a command-line > option (-imm, --ignore-missing-modules) that would simply ignore missing > modules during pom resolution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306367#comment-306367
]
Jeff Black commented on MWAR-280:
-
We are seeing the same war overlay performance hit difference between versions
2.1.1 and 2.2.
> Big performance hit in overlay
> --
>
> Key: MWAR-280
> URL: https://jira.codehaus.org/browse/MWAR-280
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.2
>Reporter: Simone Bordet
>
> Here is the output of version 2.1.1 of the maven war plugin when overlaying
> org.cometd.javascript:cometd-javascript-dojo:
> {code}
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [tutorials-skeleton] in
> [/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
> [INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
> [INFO] Webapp assembled in [7026 msecs]
> {code}
> Note how it took 7026 ms.
> This is the output for the same project, but using version 2.2 of the maven
> war plugin:
> {code}
> [INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [tutorials-skeleton] in
> [/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
> [INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
> [INFO] Webapp assembled in [24151 msecs]
> {code}
> Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5085) Add a CLI option to ignore missing modules
[ https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306370#comment-306370 ] Ivan commented on MNG-5085: --- Yes, this is already what we are doing. A given developer wants to improve the plugin A which depends on the Core. He create a branch with that plugin only. (Branching all projects should not be necessary in my opinion) In its workspace he has only the plugin A and the "main" project (top parent project which reference all the modules and the assembly). If he wants to compile it, no problem, the Core is resolved as jar-artifacts and retrieved from the maven repository.(local or remote) Now if he wants someone to test its modifications before requesting integration to the trunk. He has to generate a testable version. That's were he needs to trigger the "main" project which has a reference on all modules and does the assembly part. > Right now it will fail unless he checkout the other modules I'm not sure of how you think I can "workaround" that with hudson: > Checkout every modules from Trunk except the ones that are in developer's > branch > Run mvn package on the main project which will trigger ALL the submodules > Add a CLI option to ignore missing modules > -- > > Key: MNG-5085 > URL: https://jira.codehaus.org/browse/MNG-5085 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Stephan Pauxberger > > Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. > we do not checkout the whole project. Example: > Full Project (as in Repository): > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B > pom.xml > Now, do a checkout (svn co xxx --depth children; svn update --set-depth > inifity A) > Working Copy: > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B (no pom!!, since we only did a sparse checkout) > Now, this setup is not buildable, since maven complains (rightfully) about a > missing pom for B. > What I propose is an option to change this behaviour with a command-line > option (-imm, --ignore-missing-modules) that would simply ignore missing > modules during pom resolution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-649) The staged site is still deployed to a wrong place
Herve Boutemy created MSITE-649:
---
Summary: The staged site is still deployed to a wrong place
Key: MSITE-649
URL: https://jira.codehaus.org/browse/MSITE-649
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.1
Reporter: Herve Boutemy
in MSITE-602, the site was deployed with extra
"plugins/maven-checkstyle-plugin" subdirectory
with m-site-p 3.1, the "plugins" directory isn't there any more but
maven-checkstyle-plugin is still here
{noformat}[INFO] --- maven-site-plugin:3.1:stage-deploy (default-cli) @
maven-checkstyle-plugin ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT
[INFO] Parent project loaded from repository:
org.apache.maven.plugins:maven-plugins:pom:23
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:22
Using private key: /home/herve/.ssh/id_dsa
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
- Session: Opened
[INFO] Pushing
/home/herve/projets/maven/trunks/plugins/maven-checkstyle-plugin/target/site
[INFO]>>> to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
Executing command: scp -t
"/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin/wagon7871216691157601745.zip"
Uploading: maven-checkstyle-plugin/wagon7871216691157601745.zip to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
##
Transfer finished. 790672 bytes copied in 2.02 seconds
Executing command: cd
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin;
unzip -q -o wagon7871216691157601745.zip; rm -f wagon7871216691157601745.zip
Executing command: chmod -Rf g+w,a+rX
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
- Session: Disconnecting
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
- Session: Disconnected{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-649) The staged site is still deployed to a wrong place
[
https://jira.codehaus.org/browse/MSITE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-649.
---
Resolution: Fixed
Fix Version/s: 3.2
Assignee: Herve Boutemy
IT added in [r1374111|http://svn.apache.org/viewvc?rev=1374111&view=rev]
bug fixed in [r1374112|http://svn.apache.org/viewvc?rev=1374112&view=rev]
> The staged site is still deployed to a wrong place
> --
>
> Key: MSITE-649
> URL: https://jira.codehaus.org/browse/MSITE-649
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Affects Versions: 3.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.2
>
>
> in MSITE-602, the site was deployed with extra
> "plugins/maven-checkstyle-plugin" subdirectory
> with m-site-p 3.1, the "plugins" directory isn't there any more but
> maven-checkstyle-plugin is still here
> {noformat}[INFO] --- maven-site-plugin:3.1:stage-deploy (default-cli) @
> maven-checkstyle-plugin ---
> [INFO] Using this server ID for stage deploy: apache.website
> [INFO] Using this base URL for stage deploy:
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT
> [INFO] Parent project loaded from repository:
> org.apache.maven.plugins:maven-plugins:pom:23
> [INFO] Parent project loaded from repository:
> org.apache.maven:maven-parent:pom:22
> Using private key: /home/herve/.ssh/id_dsa
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
> - Session: Opened
> [INFO] Pushing
> /home/herve/projets/maven/trunks/plugins/maven-checkstyle-plugin/target/site
> [INFO]>>> to
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
> Executing command: mkdir -p
> /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
> Executing command: mkdir -p
> /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin
> Executing command: scp -t
> "/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin/wagon7871216691157601745.zip"
> Uploading: maven-checkstyle-plugin/wagon7871216691157601745.zip to
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
> ##
> Transfer finished. 790672 bytes copied in 2.02 seconds
> Executing command: cd
> /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/maven-checkstyle-plugin;
> unzip -q -o wagon7871216691157601745.zip; rm -f wagon7871216691157601745.zip
> Executing command: chmod -Rf g+w,a+rX
> /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
> - Session: Disconnecting
> scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.10-SNAPSHOT/
> - Session: Disconnected{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-645) Menu no longer accepts "href" attribute
[
https://jira.codehaus.org/browse/MSITE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306386#comment-306386
]
Herve Boutemy commented on MSITE-645:
-
yeah, documentation is wrong: this href attribute doesn't exist either now (see
http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_menu)
nor in old 1.0.x Doxia (see
http://maven.apache.org/doxia/doxia-sitetools-1.0.x/doxia-decoration-model/decoration.html#class_menu)
I suppose this is a typo nobody reported yet
> Menu no longer accepts "href" attribute
> ---
>
> Key: MSITE-645
> URL: https://jira.codehaus.org/browse/MSITE-645
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.1
>Reporter: Paul Benedict
>
> Section "Including Generated Content":
> http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
> I used the example:
> {noformat}
>
> {noformat}
> Error reported:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on project
> leave: SiteToolException: Error parsing site descriptor: Unknown attribute
> 'href' for tag 'menu' (position: START_TAG seen ...\r\n name="Foo" href="foo.html" />... @3:40) -> [Help 1]
> Either the documentation is wrong or the site schema has changed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-645) Menu no longer accepts "href" attribute
[
https://jira.codehaus.org/browse/MSITE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-645.
---
Resolution: Fixed
Fix Version/s: 3.2
Assignee: Herve Boutemy
fixed in [r1374117|http://svn.apache.org/viewvc?rev=1374117&view=rev]
> Menu no longer accepts "href" attribute
> ---
>
> Key: MSITE-645
> URL: https://jira.codehaus.org/browse/MSITE-645
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.1
>Reporter: Paul Benedict
>Assignee: Herve Boutemy
> Fix For: 3.2
>
>
> Section "Including Generated Content":
> http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
> I used the example:
> {noformat}
>
> {noformat}
> Error reported:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on project
> leave: SiteToolException: Error parsing site descriptor: Unknown attribute
> 'href' for tag 'menu' (position: START_TAG seen ...\r\n name="Foo" href="foo.html" />... @3:40) -> [Help 1]
> Either the documentation is wrong or the site schema has changed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[
https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306397#comment-306397
]
Andrei Pozolotin commented on MRELEASE-459:
---
fyi: this is still a problem as of 2.3.2;
hey, this soon will make it into a book of records! :-)
it will be named: "the curse of the maven release plugin"
http://stackoverflow.com/questions/3291938/maven-release-plugin-ignores-releaseprofile
workaround is still the same: put a dummy profile in settings.xml
{code:title=settings.xml|borderStyle=solid}
default
default
{code}
> releaseProfiles has no effect without passing profiles in the command line
> ---
>
> Key: MRELEASE-459
> URL: https://jira.codehaus.org/browse/MRELEASE-459
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-8, 2.0-beta-9
>Reporter: Andreas Christoforides
> Labels: contributers-welcome, help-requested,
> missing-integration-tests
> Attachments: MRELEASE-459.1.patch, patch.txt
>
>
> The releaseProfiles parameter on the perform goal is not taken into
> consideration when no other profiles are passed in the command line. In other
> words, the current code only uses the value of the parameter if you have
> additional profiles passed in.
> Example:
> mvn release:perform -P someProfile (uses releaseProfiles value)
> mvn release:perform (does NOT use releaseProfiles value)
> The plugin should use the parameter even if no other profiles are passed. It
> should actually encourage release profiles configured in your POM as opposed
> to arbitrary profiles passed in the command line.
> I have included a patch that uses the releaseProfiles parameter regardless of
> any profiles passed in the command line.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
