[jira] Created: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL) - Key: MSITE-531 URL: http://jira.codehaus.org/browse/MSITE-531 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 3.0-beta-3, 2.1 Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, wagon-webdav-jackrabbit 1.0-beta-7 Reporter: Marcin Kuthan Hi, I configured my project to use Wagon WebDAV provider to deploy project site. In general it works as I expected but it fails if the site is deployed on googlecode. Transfer error: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project corporate-pom: Error uploading site: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project corporate-pom: Error uploading site at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) ... 21 more I filled an issue in googlecode bug tracker (http://code.google.com/p/support/issues/detail?id=4786). There is a suspicion that '/./' part of URL is an error cause. It has been discussed also on Maven mailing list: http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html Thanks, Marcin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MPIR-182) Make order of reports shown in Project Reports configurable
[
http://jira.codehaus.org/browse/MPIR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl reopened MPIR-182:
Re-opening as it won't be included in the 2.3.1 bug-fix release
Make order of reports shown in Project Reports configurable
-
Key: MPIR-182
URL: http://jira.codehaus.org/browse/MPIR-182
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: Andreas Sewe
Assignee: Lukas Theussl
Priority: Minor
Fix For: 2.4
As far as I can tell the plugin's reports are presented in alphabetical order
in the Project Reports menu. While having About come first seems natural,
some of the other menu items (in particular, Source Repository) are placed
less than optimally. Why not make this configurable, e.g., by making the
order significant in which the {{report}} elements occur in the plugin's
configuration?
--
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: (SUREFIRE-501) -Xmx JVM option is not used by the surefire process
[ http://jira.codehaus.org/browse/SUREFIRE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-501: Fix Version/s: (was: 2.7.1) 2.7 -Xmx JVM option is not used by the surefire process --- Key: SUREFIRE-501 URL: http://jira.codehaus.org/browse/SUREFIRE-501 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.2 Environment: Windows XP SP2, JDK 1.6, Maven 2.0.9, surefire 2.4.2 Reporter: Sebastien Peyron Fix For: 2.7 I use the jvm option *-Xmx1024m* to execute maven 2.0.9. I've got heavy integration tests. When the process surefire forks, it does not use this option. His maximum heap size is only 65 MB. -- 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: (SUREFIRE-665) Output to file stops after a while
[
http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-665:
Fix Version/s: (was: 2.7.1)
2.7
Output to file stops after a while
--
Key: SUREFIRE-665
URL: http://jira.codehaus.org/browse/SUREFIRE-665
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Tom Baeyens
Assignee: Kristian Rosenvold
Fix For: 2.7
After some tests of proper behavior, surefire stops logging the console
output (stderr stdout) to the files. For the first tests that are
executed, the X-output.txt files contain the correct console output. But
from some test in the test suite, all those files are blank.
My environment: Mac with
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.6.4 arch: x86_64 Family: mac
Using Surefire 2.6
I've done following observations:
* The exact test where the console capturing stops can vary a couple of
tests, but it always happens. Could it be related to memory? Increasing
from MAVEN_OPTS=-Xmx1024m -Xms512m to MAVEN_OPTS=-Xmx2048m -Xms512m
didn't have an effect
* When debugging, as long as the output is ok, System.err.checkError()
returns false. Once the output files get blank, System.err.checkError()
returns true.
* The problem doesn't occur when running the same test suite in eclipse.
* When I didn't specify surefire version, I got 2.4.something. When I
explicitely set the version to 2.6, then the test suite started failing half
way with out of memory exceptions.
* Then I configured forkModealways/forkMode. That made the whole test
suite run fine (no memory exceptions and all log files being produced) but
then it takes a very long time.
* I traced closing of the system err stream until SystemStreamCapturer
76 public void restoreStreams()
77 {
78 // Note that the fields can be null if the test hasn't even
started yet (an early error)
79 if ( oldOut != null )
80 {
81 System.setOut( oldOut );
82 }
83 if ( oldErr != null )
84 {
85 System.setErr( oldErr );
86 }
87
88 IOUtil.close( newOut );
89 IOUtil.close( newErr );
90 }
But there I couldn't find how to trace it further and gave up.
To reproduce: (only tested on mac)
check out https://svn.codehaus.org/activiti/activiti/trunk and then on the
root do
mvn clean install
only the first executed tests will contain properly captured output in
modules/activiti-engine/target/surefire-reports/*-output.txt
--
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: (SUREFIRE-501) -Xmx JVM option is not used by the surefire process
[ http://jira.codehaus.org/browse/SUREFIRE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-501. --- Resolution: Fixed Assignee: Kristian Rosenvold Got included in 2.7 -Xmx JVM option is not used by the surefire process --- Key: SUREFIRE-501 URL: http://jira.codehaus.org/browse/SUREFIRE-501 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.2 Environment: Windows XP SP2, JDK 1.6, Maven 2.0.9, surefire 2.4.2 Reporter: Sebastien Peyron Assignee: Kristian Rosenvold Fix For: 2.7 I use the jvm option *-Xmx1024m* to execute maven 2.0.9. I've got heavy integration tests. When the process surefire forks, it does not use this option. His maximum heap size is only 65 MB. -- 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: (SUREFIRE-666) Aggregate report is empty for multimodule build.
Aggregate report is empty for multimodule build.
Key: SUREFIRE-666
URL: http://jira.codehaus.org/browse/SUREFIRE-666
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.6
Environment: Maven 2.2.1
Reporter: Marcin Kuthan
When the report aggregation is enabled:
1. On module level empty surefire report page is generated
2. On top level surefire report with 0 tests is generated
Surefire report plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version${plugins.surefireVersion}/version
configuration
reportsDirectories
reportsDirectory${project.build.directory}/surefire-reports//reportsDirectory
reportsDirectory${project.build.directory}/failsafe-reports//reportsDirectory
/reportsDirectories
/configuration
reportSets
reportSet
reports
reportreport-only/report
/reports
/reportSet
/reportSets
/plugin
To reproduce the issue:
1. svn checkout http://m4enterprise.googlecode.com/svn/trunk/
m4enterprise-read-only
2. call mvn install against corporate-pom and modular-war modules.
3. call mvn site:stage -Daggregate=true against modular-war.
4. check the reports in modular-war/target/stage directory.
I was looking for description how to configure surefire and failsafe together
for multi module project. No luck :-(
Thanks,
Marcin
--
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: (SUREFIRE-666) Aggregate report is empty for multimodule build.
[
http://jira.codehaus.org/browse/SUREFIRE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Kuthan updated SUREFIRE-666:
---
Attachment: parent.png
core.png
Screenshot with surefire report pages.
Aggregate report is empty for multimodule build.
Key: SUREFIRE-666
URL: http://jira.codehaus.org/browse/SUREFIRE-666
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.6
Environment: Maven 2.2.1
Reporter: Marcin Kuthan
Attachments: core.png, parent.png
When the report aggregation is enabled:
1. On module level empty surefire report page is generated
2. On top level surefire report with 0 tests is generated
Surefire report plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version${plugins.surefireVersion}/version
configuration
reportsDirectories
reportsDirectory${project.build.directory}/surefire-reports//reportsDirectory
reportsDirectory${project.build.directory}/failsafe-reports//reportsDirectory
/reportsDirectories
/configuration
reportSets
reportSet
reports
reportreport-only/report
/reports
/reportSet
/reportSets
/plugin
To reproduce the issue:
1. svn checkout http://m4enterprise.googlecode.com/svn/trunk/
m4enterprise-read-only
2. call mvn install against corporate-pom and modular-war modules.
3. call mvn site:stage -Daggregate=true against modular-war.
4. check the reports in modular-war/target/stage directory.
I was looking for description how to configure surefire and failsafe together
for multi module project. No luck :-(
Thanks,
Marcin
--
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
EAR installation issues in WAS6.0
Using Maven2 generated the EAR. I am trying to deploy this EAR from WAS 6 adming console. While deploying, getting following exception. Here am pasting my pom.xml content, Please provide a solution asap. Thanks In advance... Krishna.. == POM.XML OF EAR ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent artifactIdBRIDGES/artifactId groupIdcom.montana/groupId version1.0/version /parent artifactIdBRIDGES-EAR/artifactId packagingear/packaging nameBRIDGES-EAR/name dependencies !-- New one AR dependency-- dependency groupIdcom.montana/groupId artifactIdRM/artifactId version1.0/version scopecompile/scope /dependency !-- bridgesWeb,DA and RT dependency-- dependency groupIdcom.montana/groupId artifactIdFW/artifactId version1.0/version scopecompile/scope /dependency !-- bridgesWeb and RTdependency-- dependency groupIdcom.montana/groupId artifactIdDA/artifactId version1.0/version scopecompile/scope /dependency !-- bridgesWeb dependencies-- dependency groupIdcom.montana/groupId artifactIdAL/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdAR/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdBI/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdCO/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdCV/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdDC/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdED/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdHM/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdHP/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdIN/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdIQ/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdMO/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdQC/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdRL/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdRP/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.montana/groupId artifactIdRT/artifactId version1.0/version scopecompile/scope /dependency dependency
[jira] Created: (MNG-4936) Allow to better monitor and adjust a Maven build during CI
Allow to better monitor and adjust a Maven build during CI -- Key: MNG-4936 URL: http://jira.codehaus.org/browse/MNG-4936 Project: Maven 2 3 Issue Type: New Feature Components: Command Line, Settings Affects Versions: 3.0.1 Reporter: Benjamin Bentmann For improved integration into CI, Maven should a) have a means to load an extension (let's call it spy) via CLI b) enable this spy extension to adjust major parameters of the build like the settings c) provide this spy extension with detailed events about the execution -- 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-4936) Allow to better monitor and adjust a Maven build during CI
[ http://jira.codehaus.org/browse/MNG-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248770#action_248770 ] Olivier Lamy commented on MNG-4936: --- very interesting ! What is your implementation idea exactly ? c) you mean a kind of extension of the current ExecutionListener ? Allow to better monitor and adjust a Maven build during CI -- Key: MNG-4936 URL: http://jira.codehaus.org/browse/MNG-4936 Project: Maven 2 3 Issue Type: New Feature Components: Command Line, Settings Affects Versions: 3.0.1 Reporter: Benjamin Bentmann For improved integration into CI, Maven should a) have a means to load an extension (let's call it spy) via CLI b) enable this spy extension to adjust major parameters of the build like the settings c) provide this spy extension with detailed events about the execution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
[ http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MRELEASE-627: Attachment: MRELEASE-627-2 This additional patch fixes a potential NPE when subrepos have no explict SCM tag in their POM. It also fixes an issue where some changes were pushed even if pushChanges was set to false in the base POM. Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories --- Key: MRELEASE-627 URL: http://jira.codehaus.org/browse/MRELEASE-627 Project: Maven 2.x Release Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Henning Schmiedehausen Attachments: MRELEASE-627-2, release-plugin-patch The maven-release-plugin is pretty much designed to work with a single repository and tag and branch from this. As soon as a project tree is more complex and e.g. uses nested or multiple repositories (such as the Mercurial subrepos), it fails. The attached patch fixes most of the use cases that allow releasing large (reactor) projects that span multiple projects and use one repository per project. New properties: revertOrder (boolean) - Default: false Reverts the order in which commit, tag and branch process multi-repos. E.g. in Mercurial, the main repository (which contains the subrepos) must be processed last, because it implicitly records state of the relationship between the main and the sub repository. If it gets committed first, then this state is not recorded correctly. By reverting the order, the main repository is committed last. commitAllChanges (boolean) - Default: false The release plugin tries to explicitly list which files it commits. However, in the case of a multi-repository tree, in then tries e.g. to commit repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of repo which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part of the subrepos a and b). Setting this parameters omits the list of files and tells the SCM to commit everything. E.g. Mercurial then picks up the changes correctly and also records the implicit state between master and sub repositories correctly. tagByProject, branchByProject (boolean) - Default: false Similar to the existing 'commitByProject', these options select whether a tag or a branch should be created by running the tag command in the root of the tree or by looping through all projects and tagging or branching them one-by-one. Default is to tag in the root. tagRequiresCommit / branchRequiresCommit (boolean) - Default: false Mercurial manages tags by adding entries to the '.hgtags' file, which is managed implicitly by the SCM. If a subrepository gets tagged as part of a larger, multi-repo project, then the changes must be explicitly committed, else they don't get picked up by the main repository. This sounds more complicated than it actually is, the summary is that this must be 'true' for Mercurial and probably false for everything else. Those changes *should* work with the 1.4 SCM provider, but were tested only with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges support in the Mercurial provider. If you want to test drive this patch, you should also be interested in SCM-587. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-605) when not pushing changes to remote git repo in 2.1, the release plugin fails on release:perform
[
http://jira.codehaus.org/browse/MRELEASE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248786#action_248786
]
Toni Menzel commented on MRELEASE-605:
--
Any chance seeing pushChanges=false work out of the box without the
-DconnectionUrl=scm:git:file:///directory/where/my/code/is workaround in 2.2 ?
when not pushing changes to remote git repo in 2.1, the release plugin fails
on release:perform
---
Key: MRELEASE-605
URL: http://jira.codehaus.org/browse/MRELEASE-605
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: james strachan
Fix For: 2.2
as it tries to clone the remote repo, which has not yet been pushed - so
there's no tag in the remote repo yet.
Ideally if pushChanges is false, it should use a value of
{code}
scm
developerConnectionLscm:git:file://${baseDir}/developerConnection
...
/scm
{code}
so that it clones from the current local git repo (which has everything
inside it) rather than the remote repo which has yet to be pushed.
BTW a great use case for not pushing is using a staging maven repo like
Nexus; which may reject an attempt to promote a staged build, so you only
want to push after a downstream stage works.
--
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: (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ http://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-599. --- Resolution: Fixed Fix Version/s: 2.7 Assignee: Kristian Rosenvold I am closing this issue because the symptoms described are *exactly* those of the TeeStream memory leak, which has been fixed in 2.7. Feel free to reopen if 2.7 does not fix the issue. Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: http://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania Assignee: Kristian Rosenvold Fix For: 2.7 I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- 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: (SUREFIRE-651) Setting printSummary=true disables redirectTestOutputToFile
[ http://jira.codehaus.org/browse/SUREFIRE-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248789#action_248789 ] Roman Ivashin commented on SUREFIRE-651: Just noticed the typo. the description should read Setting printSummary=FALSE disables redirectTestOutputToFile Setting printSummary=true disables redirectTestOutputToFile --- Key: SUREFIRE-651 URL: http://jira.codehaus.org/browse/SUREFIRE-651 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.4.2, 2.5, 2.6 Environment: Linux, Windows Reporter: Roman Ivashin Fix For: 2.7.1 Attachments: test.zip Setting printSummary=true disables redirectTestOutputToFile, i.e. the reportsDirectory/testName-output.txt files are not created. Please see the testcase attached. -- 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: (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ http://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248787#action_248787 ] Kristian Rosenvold edited comment on SUREFIRE-599 at 12/16/10 12:07 PM: This issue is a combination of two bugs, both of which were fixed for 2.7: There was a minor problem in surefire2.6, where it started loading classes before capturing stdout/stderr. This would allow third party loggers to get hold of the uncaptured stdout/stderr. This has been fixed for 2.7. The TeeStream memory leak explains the per-test increase in logging. This is an old bug that was also fixed for 2.7. was (Author: krosenvold): I am closing this issue because the symptoms described are *exactly* those of the TeeStream memory leak, which has been fixed in 2.7. Feel free to reopen if 2.7 does not fix the issue. Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: http://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania Assignee: Kristian Rosenvold Fix For: 2.7 I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- 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: (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ http://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-599: Comment: was deleted (was: I have tracked this problem to be inside TestListenerInvocationHandler. All is fine inside JunitTestSet.invoke (line 213 in 2.5). Somehow this duplication happens within the dynamic proxy.) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: http://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania Assignee: Kristian Rosenvold Fix For: 2.7 I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- 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: (SUREFIRE-636) Wrong plugin parameter documentation for includes and excludes
[ http://jira.codehaus.org/browse/SUREFIRE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-636: Fix Version/s: 2.7.1 Wrong plugin parameter documentation for includes and excludes -- Key: SUREFIRE-636 URL: http://jira.codehaus.org/browse/SUREFIRE-636 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Reporter: Eric Lewis Priority: Minor Fix For: 2.7.1 The documentation for the plugin parameters includes (http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#includes) and excludes (http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#excludes) states that it expects a List of patterns (separated by commas) used to specify the tests that should be included/excluded in testing. However, that's not the case, as shown in http://maven.apache.org/plugins/maven-surefire-plugin/examples/inclusion-exclusion.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-518) Do not generate empty ouput files when redirectTestOutputToFile is enabled
[ http://jira.codehaus.org/browse/SUREFIRE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-518: Fix Version/s: 2.7.1 Do not generate empty ouput files when redirectTestOutputToFile is enabled -- Key: SUREFIRE-518 URL: http://jira.codehaus.org/browse/SUREFIRE-518 Project: Maven Surefire Issue Type: Improvement Components: process forking Affects Versions: 2.4.3 Reporter: Emmanuel Bourg Fix For: 2.7.1 The redirectTestOutputToFile option could be improved by removing, or not generating, the empty output files. Either by default, or with an additional option. -- 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: (MNG-4936) Allow to better monitor and adjust a Maven build during CI
[
http://jira.codehaus.org/browse/MNG-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4936.
--
Resolution: Fixed
Fix Version/s: 3.0.2
Assignee: Benjamin Bentmann
Done in [r1050096|http://svn.apache.org/viewvc?view=revisionrevision=1050096].
The system property {{maven.ext.class.path}} can point at one or more JARs
which can contribute {{EventSpy}} impls. Such a spy gets notified of both
execution and repository events and other interesting bits.
Allow to better monitor and adjust a Maven build during CI
--
Key: MNG-4936
URL: http://jira.codehaus.org/browse/MNG-4936
Project: Maven 2 3
Issue Type: New Feature
Components: Command Line, Settings
Affects Versions: 3.0.1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0.2
For improved integration into CI, Maven should
a) have a means to load an extension (let's call it spy) via CLI
b) enable this spy extension to adjust major parameters of the build like the
settings
c) provide this spy extension with detailed events about the execution
--
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: (MNG-4937) Allow the platform scripts to avoid loading mavenrc content
Allow the platform scripts to avoid loading mavenrc content --- Key: MNG-4937 URL: http://jira.codehaus.org/browse/MNG-4937 Project: Maven 2 3 Issue Type: New Feature Components: Command Line Affects Versions: 3.0 Reporter: Benjamin Bentmann Attachments: 0001-Added-MAVEN_SKIP_RC-flag-to-disable-loading-of-maven.patch Jason Dillon recently sent me the attached patch, motivated by some troubles with forked Maven invocations where the MAVEN_OPTS env var used for the forked process seemed to be ignored. Actual issue was the override of the variable by the user-specific pre/post scripts. His patch adds a new env var MAVEN_SKIP_RC which allows to disable processing of the hook scripts, thereby decoupling from the user/machine-specific details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4937) Allow the platform scripts to avoid loading mavenrc content
[ http://jira.codehaus.org/browse/MNG-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4937. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Applied in [r1050135|http://svn.apache.org/viewvc?view=revisionrevision=1050135]. Allow the platform scripts to avoid loading mavenrc content --- Key: MNG-4937 URL: http://jira.codehaus.org/browse/MNG-4937 Project: Maven 2 3 Issue Type: New Feature Components: Command Line Affects Versions: 3.0 Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Fix For: 3.0.2 Attachments: 0001-Added-MAVEN_SKIP_RC-flag-to-disable-loading-of-maven.patch Jason Dillon recently sent me the attached patch, motivated by some troubles with forked Maven invocations where the MAVEN_OPTS env var used for the forked process seemed to be ignored. Actual issue was the override of the variable by the user-specific pre/post scripts. His patch adds a new env var MAVEN_SKIP_RC which allows to disable processing of the hook scripts, thereby decoupling from the user/machine-specific details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MOJO-1611 to WAGON-319: - Complexity: (was: Intermediate) Component/s: (was: wagon) wagon-webdav Key: WAGON-319 (was: MOJO-1611) Project: Maven Wagon (was: Mojo) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL) - Key: WAGON-319 URL: http://jira.codehaus.org/browse/WAGON-319 Project: Maven Wagon Issue Type: Bug Components: wagon-webdav Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, wagon-webdav-jackrabbit 1.0-beta-7 Reporter: Marcin Kuthan Hi, I configured my project to use Wagon WebDAV provider to deploy project site. In general it works as I expected but it fails if the site is deployed on googlecode. Transfer error: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project corporate-pom: Error uploading site: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) on project corporate-pom: Error uploading site at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. Return code is: 500 at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) ... 21 more I filled an issue in googlecode bug tracker (http://code.google.com/p/support/issues/detail?id=4786). There is a suspicion that '/./' part of URL is an error cause. It has been discussed also on Maven mailing list: http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html Because I don't know exactly which Maven plugin is responsible for URL pre-processing during site deployment, the similar issue was created for site plugin:
[jira] Updated: (MCHANGES-140) Create a changes check mojo
[ http://jira.codehaus.org/browse/MCHANGES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-140: - Fix Version/s: 2.4 Assignee: Dennis Lundberg Issue Type: New Feature (was: Improvement) Summary: Create a changes check mojo (was: Create an announcement check mojo) Create a changes check mojo --- Key: MCHANGES-140 URL: http://jira.codehaus.org/browse/MCHANGES-140 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: announcement Affects Versions: 2.1 Reporter: Justin Edelson Assignee: Dennis Lundberg Fix For: 2.4 Attachments: AnnouncementCheckMojo.java I meant to submit this for inclusion in changes 2.1, but I guess I just missed it (2.1.1maybe?). We use the attached goal as part of release:prepare to ensure that the changes.xml has correct content before a release is done (changes:announcement-generate) is executed during release:perform. It really does two things: 1) Ensures that the current version is represented in the changes.xml file (no special logic to do this, it's just in AnnouncementMjojo.getLatestRelease()). 2) Ensures that the current version's release date isn't TBD or tbd. This could be easily changed to be in SVN through configuration. If you want to make this the default and I'll add config to our organizational pom to use tbd, fine with me. Since using this goal, we've eliminated a cause of release failures, so that's something... -- 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: (MCHANGES-140) Create a changes check mojo
[ http://jira.codehaus.org/browse/MCHANGES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-140. Resolution: Fixed I modified the original patch to use a date format instead of a special token to recognize an invalid release date. A test case and documentation was also added. Fixed in [r1050224|http://svn.apache.org/viewvc?view=revisionrevision=1050224]. 2.4-SNAPSHOT deployed. Thanks! Create a changes check mojo --- Key: MCHANGES-140 URL: http://jira.codehaus.org/browse/MCHANGES-140 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: announcement Affects Versions: 2.1 Reporter: Justin Edelson Assignee: Dennis Lundberg Fix For: 2.4 Attachments: AnnouncementCheckMojo.java I meant to submit this for inclusion in changes 2.1, but I guess I just missed it (2.1.1maybe?). We use the attached goal as part of release:prepare to ensure that the changes.xml has correct content before a release is done (changes:announcement-generate) is executed during release:perform. It really does two things: 1) Ensures that the current version is represented in the changes.xml file (no special logic to do this, it's just in AnnouncementMjojo.getLatestRelease()). 2) Ensures that the current version's release date isn't TBD or tbd. This could be easily changed to be in SVN through configuration. If you want to make this the default and I'll add config to our organizational pom to use tbd, fine with me. Since using this goal, we've eliminated a cause of release failures, so that's something... -- 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: (MSHADE-91) Allow failing of build if overlapping classes are detected
[
http://jira.codehaus.org/browse/MSHADE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Swan updated MSHADE-91:
--
Attachment: MSHADE-91.patch
Here's a patch that adds a boolean configuration property called
duplicatesAreFatal, defaulting to false to preserve the current behaviour.
When set to true, a BUILD FAILURE message is shown, listing all
duplications detected by the Shader.
Allow failing of build if overlapping classes are detected
--
Key: MSHADE-91
URL: http://jira.codehaus.org/browse/MSHADE-91
Project: Maven 2.x Shade Plugin
Issue Type: New Feature
Affects Versions: 1.4
Environment: N/A
Reporter: Andrew Swan
Attachments: MSHADE-91.patch
Currently if multiple shaded artifacts contain the same fully-qualified class
name, the plugin issues a warning on the console like this:
{code}[WARNING] We have a duplicate foo.bar.Baz.class in
path-to-jar-in-local-repo{code}
In many cases such duplicates are a serious problem, e.g. when they are not
the same version of that class.
It would therefore be useful if the plugin (specifically the DefaultShader
class) provided the option of failing the build if any duplicates are
detected. This would be particularly useful in a continuous integration
environment where there's no human operator to check the console output for
warnings.
--
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-41) Add a list of available language in site plugin
[ http://jira.codehaus.org/browse/MSITE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248859#action_248859 ] Yevgeny Nyden commented on MSITE-41: Dennis, or in fact, anybody who's interested, please take a look at the proposed feature here: http://curre.net/mvn-site/ What browser should we support? I tested this in IE8, FF3.6 (on Mac), and Safari 5 (on Mac), but I think it should work just fine in other browsers as well. I will submit the diff for review after your feedback. Add a list of available language in site plugin --- Key: MSITE-41 URL: http://jira.codehaus.org/browse/MSITE-41 Project: Maven 2.x and 3.x Site Plugin Issue Type: New Feature Components: internationalization Reporter: Vincent Siveton Attachments: language_menu.jpg, language_menu.jpg, language_menu.jpg, language_menu_as_select.jpg Please see the attached screenshots This preference menu could be a list of links or a select/ tag. The site descriptor needs to be updated: * for select/, by adding asSelect attribute in the menu element. * for links list, by adding nostrong attribute in the menu element (to not display as strong the current language and the current page) -- 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: (MNG-4938) pom missing [WARNING] displayed even if it's available
pom missing [WARNING] displayed even if it's available -- Key: MNG-4938 URL: http://jira.codehaus.org/browse/MNG-4938 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Environment: Win 7 x32 Reporter: Christian Moser Attachments: reproduce.zip The error message is displayed everytime after a SUCCESSFUL build (phase install) of every delivered sample project despite deps-libs. Steps for reproducing: deploy selenium-java-client-driver by hand (webinterface) into artifactory repository 2.3.1 (didn't test it with nexus) install projects in the following order: deps-libs, libs-parent, libs-child, libs-comp The message should be displayed at the end of the build [WARNING] The POM for re.produce:selenium-java-client-driver:jar:1.0.1 is missing, no dependency information available. This only happens with artifacts which were deployed by hand, i'm curious if this will also happen with nexus. -- 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-4938) pom missing [WARNING] displayed even if it's available
[ http://jira.codehaus.org/browse/MNG-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248864#action_248864 ] Christian Moser commented on MNG-4938: -- The missing pom is available in the remote repository and in the local repository pom missing [WARNING] displayed even if it's available -- Key: MNG-4938 URL: http://jira.codehaus.org/browse/MNG-4938 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Environment: Win 7 x32 Reporter: Christian Moser Attachments: reproduce.zip The error message is displayed everytime after a SUCCESSFUL build (phase install) of every delivered sample project despite deps-libs. Steps for reproducing: deploy selenium-java-client-driver by hand (webinterface) into artifactory repository 2.3.1 (didn't test it with nexus) install projects in the following order: deps-libs, libs-parent, libs-child, libs-comp The message should be displayed at the end of the build [WARNING] The POM for re.produce:selenium-java-client-driver:jar:1.0.1 is missing, no dependency information available. This only happens with artifacts which were deployed by hand, i'm curious if this will also happen with nexus. -- 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: (MNG-4938) pom missing [WARNING] displayed even if it's available
[ http://jira.codehaus.org/browse/MNG-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248864#action_248864 ] Christian Moser edited comment on MNG-4938 at 12/17/10 1:57 AM: The missing pom is available in the remote repository and in the local repository. This also happens with nexus, just tested it was (Author: onmomo): The missing pom is available in the remote repository and in the local repository pom missing [WARNING] displayed even if it's available -- Key: MNG-4938 URL: http://jira.codehaus.org/browse/MNG-4938 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Environment: Win 7 x32 Reporter: Christian Moser Attachments: reproduce.zip The error message is displayed everytime after a SUCCESSFUL build (phase install) of every delivered sample project despite deps-libs. Steps for reproducing: deploy selenium-java-client-driver by hand (webinterface) into artifactory repository 2.3.1 (didn't test it with nexus) install projects in the following order: deps-libs, libs-parent, libs-child, libs-comp The message should be displayed at the end of the build [WARNING] The POM for re.produce:selenium-java-client-driver:jar:1.0.1 is missing, no dependency information available. This only happens with artifacts which were deployed by hand, i'm curious if this will also happen with nexus. -- 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
