[jira] Closed: (JXR-19) More info on the website
[ http://jira.codehaus.org/browse/JXR-19?page=all ] Vincent Siveton closed JXR-19. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Fixed in svn More info on the website Key: JXR-19 URL: http://jira.codehaus.org/browse/JXR-19 Project: Maven JXR Issue Type: Improvement Reporter: Gilles Scokart Assigned To: Vincent Siveton Priority: Minor Fix For: 1.1 The URL http://maven.apache.org/jxr/ shows very few info on how to use JXR. At the minimum, it should have a link to http://maven.apache.org/plugins/maven-jxr-plugin/howto.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] Commented: (CONTINUUM-968) Tests for continuum-release fail randomly
[ http://jira.codehaus.org/browse/CONTINUUM-968?page=comments#action_79014 ] thierry lach commented on CONTINUUM-968: I'm getting a consistent fail with the following output from surefire: -- Test set: org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.932 sec FAILURE! testReleases(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) Time elapsed: 3.869 sec ERROR! java.io.FileNotFoundException: C:\continuum-1.1-src\continuum-release\target\test-classes\work-dir\pom.xml (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) at org.codehaus.plexus.util.FileUtils.fileRead(FileUtils.java:273) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:98) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:115) and the following output on the console [INFO] Surefire report directory: C:\continuum-1.1-src\continuum-release\target\surefire-reports --- T E S T S --- Running org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest [INFO] Executing: svn --non-interactive checkout file://localhost/C:/continuum-1.1-src/continuum-release/target/scm-test/trunk work-dir [INFO] Working directory: C:\continuum-1.1-src\continuum-release\target\test-classes Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.948 sec FAILURE! Results : Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 16 seconds [INFO] Finished at: Wed Nov 01 09:46:54 EST 2006 [INFO] Final Memory: 15M/28M [INFO] When I try the svn command manually, I get C:\continuum-1.1-srcsvn --non-interactive checkout file://localhost/C:/continuum-1.1-src/continuum-release/target/scm-test/trunk work-dir svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file://localhost/C:/continuum-1.1-src/continuum-release/target/scm-test/trunk' C:\continuum-1.1-src But I can use svnadmin to verify the repository... C:\continuum-1.1-srcsvnadmin verify C:/continuum-1.1-src/continuum-release/target/scm-test * Verified revision 0. * Verified revision 1. * Verified revision 2. C:\continuum-1.1-src Hopefully this will help Tests for continuum-release fail randomly - Key: CONTINUUM-968 URL: http://jira.codehaus.org/browse/CONTINUUM-968 Project: Continuum Issue Type: Test Affects Versions: 1.1 Environment: tests fail for some environments and pass for others. For some they fail at random Reporter: Philippe Faes Priority: Minor Fix For: 1.1 Attachments: continuum-release.diff The test for continuum-release fails randomly. This is because the two test methods are executed in a random order (this is intended JUnit behavior), and the tests alter files. Solution is to restore files between tests (method setUp) and to force the order of the two tests (create one test method that calls the two other methods one by one). Patch is attached. Please verify and commit. -- 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: (MASSEMBLY-157) maven assembly plugin, includes/excludes in moduleSet
[ http://jira.codehaus.org/browse/MASSEMBLY-157?page=comments#action_79019
]
John Casey commented on MASSEMBLY-157:
--
If you use the latest snapshot of the assembly plugin, you should be able to
specify includes this way:
{code:xml}
moduleSets
moduleSet
includes
includeautoguard:autocontrol-core/include
/includes
[...]
/moduleSet
[...]
/moduleSets
{code}
maven assembly plugin, includes/excludes in moduleSet
--
Key: MASSEMBLY-157
URL: http://jira.codehaus.org/browse/MASSEMBLY-157
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: Maven 2.0.4, JDK 6.0, assembly plugin
Reporter: #321;ukasz Dywicki
Priority: Minor
Fix For: 2.2
Hello everyone, I've some assembly descriptor with operations in modulesSet,
but maven ignore my excludes/includes.
I've got all modules in bin directory, all modules in modules ditectory and
all modules in libs.
?xml version=1.0 encoding=UTF-8?
assembly
idpackage/id
includeBaseDirectoryfalse/includeBaseDirectory
formats
formatzip/format
/formats
moduleSets
!-- include modules --
moduleSet
binaries
outputDirectorymodules//outputDirectory
includeDependenciesfalse/includeDependencies
unpackfalse/unpack
excludes
excludeautoguard:autocontrol-core/exclude
/excludes
/binaries
/moduleSet
!-- copy autoguard:autocontrol-core to bin --
moduleSet
binaries
outputDirectorybin//outputDirectory
includeDependenciesfalse/includeDependencies
unpackfalse/unpack
includes
includeautoguard:autocontrol-core/include
/includes
/binaries
/moduleSet
!-- include module libs --
moduleSet
binaries
outputDirectorylibs//outputDirectory
includeDependenciestrue/includeDependencies
unpackfalse/unpack
excludes
!-- exclude modules --
exclude${project.groupId}/exclude
/excludes
/binaries
/moduleSet
/moduleSets
!-- include project libs --
dependencySets
dependencySet
outputDirectorylibs//outputDirectory
unpackfalse/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
--
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-45) It should be possible to configure checkstyle:check to fail on warnings.
[ http://jira.codehaus.org/browse/MCHECKSTYLE-45?page=comments#action_79023 ] Mark Roder commented on MCHECKSTYLE-45: --- I have a similar problem/need to Fabian and Jacob. The supplied patch will support what I need to do for my projects and allow different levels of checkstyle alerts to fail the build. It should be possible to configure checkstyle:check to fail on warnings. -- Key: MCHECKSTYLE-45 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 Project: Maven 2.x Checkstyle Plugin Issue Type: New Feature Affects Versions: 2.1 Reporter: Fabian Bauschulte Attachments: MCHECKSTYLE-45-maven-checkstyle-plugin.patch As mentioned in MCHECKSTYLE-38 it should be possible to configure that checkstyle:check fails on warnings or not. -- 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: (MNGECLIPSE-210) plugin fails to start (class not found)
plugin fails to start (class not found) --- Key: MNGECLIPSE-210 URL: http://jira.codehaus.org/browse/MNGECLIPSE-210 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Affects Versions: 0.0.9 Environment: windows, eclipse3.2 with wtp Reporter: thomas fischer Priority: Critical I can not use the plugin (see below). I have restarted eclipse using -clean. In the Plugins-View and the Plugin-Registriy View i can not found a maven entry. In Product Confiuration Window the maven entry seems to be ok. Thomas Problems: 1) if i try to vistit the preference page I got following message : Unable to create the selected prefenrens page. Reasen plugin was unable to load class ..Maven2Preference page 2) if i try to enable maven 2 plugin i got following 3 stacktraces: stacktrace 1### eclipse.buildId=M20060921-0945 java.version=1.5.0_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86 -clean Error Wed Nov 01 16:38:38 CET 2006 Could not create action delegate for id: org.maven.ide.eclipse.enableAction stacktrace 2 ## eclipse.buildId=M20060921-0945 java.version=1.5.0_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86 -clean Error Wed Nov 01 16:38:38 CET 2006 An error occurred while automatically activating bundle org.maven.ide.eclipse (400). org.osgi.framework.BundleException: Exception in org.maven.ide.eclipse.Maven2Plugin.start() of bundle org.maven.ide.eclipse. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.preFindLocalClass(EclipseLazyStarter.java:86) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:409) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:334) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:386) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:278) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1245) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:147) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:759) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:242) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:238) at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAction.java:120) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:225) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_79025 ]
Richard van der Hoff commented on MASSEMBLY-90:
---
Right, well, that doesn't work any better.
It seems that the pattern is tested against the entire transitive dependency
tree.
On a related note, the following doesn't match anything at all:
{code:xml}
includes
include!*:so:*/include
/includes
{code}
It seems that you need at least one positive pattern in an includes or
excludes block to make this work.
add a DependencySet filter based on type
Key: MASSEMBLY-90
URL: http://jira.codehaus.org/browse/MASSEMBLY-90
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Reporter: Jason Chaffee
Assigned To: John Casey
Fix For: 2.2
Attachments: AbstractAssemblyMojo-patch.txt,
AbstractAssemblyMojo.java, AbstractAssemblyMojo.java,
AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java,
AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java,
component.mdo, component.mdo-patch.txt, descriptor.mdo,
descriptor.mdo-patch-.txt
It would be nice to create a distribution bundle that contains both jars and
webapps. These would be built by different projects and then an assembly
project would list these in the pom. However, there is no way to filter the
dependencies based on their type. This would be be a pretty easy thing to
add. I have attached a new class, AssemblyTypeArtifactFilter and the
required change to AbstractAsseblyMojo. The DependencySet class needs to be
modified as well to add the type field, but I was not able to find it in the
maven repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=comments#action_79028 ]
Richard van der Hoff commented on MASSEMBLY-90:
---
To clarify this a little:
One of my project's dependencies is com.wapmx.etc:libnativeapp:so:1.0-SNAPSHOT.
It depends on com.wapmx.etc:native-app-java:jar:1.0-SNAPSHOT.
1)
In my assembly descriptor, I have:
{code:xml}
dependencySet
includes
include*:jar:*/include
/includes
/dependencySet
{code}
This should include the dependencies of type jar, but not the so. It includes
everything.
2)
In my assembly descriptor, I have
{code:xml}
dependencySet
includes
include!*:so:*/include
/includes
/dependencySet
{code}
This should also include the dependencies of type jar, but not the so (I
think!). It includes nothing. Adding an explicit include*/include makes it
work ok, modulo point (1) above.
add a DependencySet filter based on type
Key: MASSEMBLY-90
URL: http://jira.codehaus.org/browse/MASSEMBLY-90
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Reporter: Jason Chaffee
Assigned To: John Casey
Fix For: 2.2
Attachments: AbstractAssemblyMojo-patch.txt,
AbstractAssemblyMojo.java, AbstractAssemblyMojo.java,
AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java,
AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java,
component.mdo, component.mdo-patch.txt, descriptor.mdo,
descriptor.mdo-patch-.txt
It would be nice to create a distribution bundle that contains both jars and
webapps. These would be built by different projects and then an assembly
project would list these in the pom. However, there is no way to filter the
dependencies based on their type. This would be be a pretty easy thing to
add. I have attached a new class, AssemblyTypeArtifactFilter and the
required change to AbstractAsseblyMojo. The DependencySet class needs to be
modified as well to add the type field, but I was not able to find it in the
maven repository.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2646) [PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles
[PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles -- Key: MNG-2646 URL: http://jira.codehaus.org/browse/MNG-2646 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Reporter: Christian Schulte Attachments: profile.patch Currently profiles are not injected into models retrieved from a repository. The attached patch was written against /tags/maven-2.0.4 and should apply cleanly. It adds a ProfileManager parameter to the corresponding MavenProjectBuilder.buildFromRepository(...) methods so that profiles are also injected into models build from a repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_79032 ] Sasha A commented on MSUREFIREREP-6: The workaround I've been using is the problem Peter Anning has above is the following. First I run a target that invokes the tests, like: mvn test OR mvn install Then, if the tests fail, I run: mvn -Dmaven.test.skip=true surefire-report:report OR mvn -Dmaven.test.skip=true site Either of these commands runs the surefire report goal without running the tests again. Obviously, this is just a workaround, and it doesn't work well for continuous integration systems that need to run everything automagically, but it has helped me a lot. surefire-report reruns tests Key: MSUREFIREREP-6 URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 Project: Maven 2.x Surefire report Plugin Issue Type: Bug Environment: maven 2.0 Reporter: Dirk Sturzebecher surefire-report reruns the tests. In my case this is not just annoying, but leads to a failure, as the VM (probably) is reused and leftovers from the first tests are (definitly) still present. I run maven with: clean package site -- 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: (MEAR-36) Add classifier fonctionnality to Maven EAR Plugin
[ http://jira.codehaus.org/browse/MEAR-36?page=all ]
Stephane Nicoll closed MEAR-36.
---
Resolution: Fixed
Applied and a added a test case.
Thanks Eric!
Add classifier fonctionnality to Maven EAR Plugin
-
Key: MEAR-36
URL: http://jira.codehaus.org/browse/MEAR-36
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.2
Environment: Any
Reporter: Mathieu Rozieres
Assigned To: Stephane Nicoll
Fix For: 2.3
Attachments: MEAR-36-maven-ear-plugin.patch
The classifier tag is not implemented into Maven EAR Plugin.
For example, while using this configuration :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
classifierdev/classifier
/configuration
/plugin
The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-215) Fails to build from clean checkout
Fails to build from clean checkout -- Key: MRM-215 URL: http://jira.codehaus.org/browse/MRM-215 Project: Archiva Issue Type: Bug Environment: Linux, Maven 2.0.4 Reporter: Max Bowsher $ svn co $ra/maven/archiva/trunk archiva-trunk $ cd archiva-trunk/ $ mvn install [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.archiva:archiva-plexus-application POM Location: /home/maxb/work/proving/archiva-trunk/archiva-plexus-application/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.maven.archiva:archiva-webapp Reason: Failed to validate POM .. This patch made the build work for me: --- archiva-plexus-application/pom.xml (revision 470042) +++ archiva-plexus-application/pom.xml (working copy) @@ -49,6 +49,7 @@ dependency groupIdorg.apache.maven.archiva/groupId artifactIdarchiva-webapp/artifactId + typewar/type /dependency /dependencies !-- For filtering -- -- 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: (CONTINUUM-988) clean out model (and deriviative usages) of the user group, permission and perhaps the continuum user objects
clean out model (and deriviative usages) of the user group, permission and perhaps the continuum user objects - Key: CONTINUUM-988 URL: http://jira.codehaus.org/browse/CONTINUUM-988 Project: Continuum Issue Type: Task Components: Core system Affects Versions: 1.1 Reporter: Jesse McConnell a few of the objects in the continuum model are no longer required, with the functionality they used to embody being provided by other sources so we should clean out some of this cruft -- 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: (CONTINUUM-989) There are two component definitions for role org.codehaus.plexus.mailsender.MailSender
There are two component definitions for role org.codehaus.plexus.mailsender.MailSender -- Key: CONTINUUM-989 URL: http://jira.codehaus.org/browse/CONTINUUM-989 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Reporter: John Didion In continuum-webapp/src/main/resources/META-INF/plexus.application.xml, there are two component definitions for role org.codehaus.plexus.mailsender.MailSender. When Plexus is configured, the last component definition wins, so unless you configure the last (or both) mail sender components, the MailSender will always try to send via localhost. It appears that the second one is redundant and can be removed. -- 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-187) Inheritance of site.xml sometimes leads to incorrect links
Inheritance of site.xml sometimes leads to incorrect links -- Key: MSITE-187 URL: http://jira.codehaus.org/browse/MSITE-187 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Dennis Lundberg This issue occurred for me after a change recently was made to the maven plugins. The change introduced a menu that is inherited from the parent's site.xml. Sometimes this works well and sometimes it doesn't. Preparations: - Remove the whole doxia and maven-site-plugin folders from the local repo - i.e. all versions, to make sure that the released versions from the central repo get downloaded. - Build a freshly copy of maven 2.0.5-SNAPSHOT from source and use it for the following tests. When it works: - Add a menu to src/test/projects/site-plugin-test8/project8/src/site/site.xml in maven-site-plugin that will be inherited by the sub-projects - Run mvn site in one of the sub-projects src/test/projects/site-plugin-test8/project8/framework and note that the menu items are correctly linked When it doesn't work: - Check out a fresh copy of maven-release-plugin to a completely new location where there is no maven plugin-parent in sight - Run mvn site on it and the inherited menu items are not correctly linked. They go to ../whatever.html instead of whatever.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-990) Pass some continuum information to build tools when executing a build
Pass some continuum information to build tools when executing a build - Key: CONTINUUM-990 URL: http://jira.codehaus.org/browse/CONTINUUM-990 Project: Continuum Issue Type: New Feature Components: Core system Reporter: John Didion Priority: Minor Attachments: maven2-build-properties.diff It would be nice to access some information (specifically build numbers) in the build script itself - for example, if I wanted to embed the build number in the jar manifest. I've attached a patch that does this for m2. I'm not sure if you could generalize it to work for all builds, or if you'd have to implement it separately for each build executor. -- 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: (MAVENUPLOAD-1210) upload sources for hibernate-tools 3.2.0.beta8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1210?page=all ] Carlos Sanchez closed MAVENUPLOAD-1210. --- Assignee: Carlos Sanchez Resolution: Fixed upload sources for hibernate-tools 3.2.0.beta8 -- Key: MAVENUPLOAD-1210 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1210 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Assigned To: Carlos Sanchez Attachments: hibernate-tools-3.2.0.beta8-bundle.jar Upload sources only -- 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: (CONTINUUM-566) Build numbers are essential
[ http://jira.codehaus.org/browse/CONTINUUM-566?page=all ] John Didion updated CONTINUUM-566: -- Attachment: add-build-number-to-mail-subject.diff Build numbers are essential --- Key: CONTINUUM-566 URL: http://jira.codehaus.org/browse/CONTINUUM-566 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.0.2 Reporter: Bob Herrmann Attachments: add-build-number-to-mail-subject.diff Without a build number (and a sub-build number for failures - or repeat attempts) matching an email to a generated failure report is extremely difficult. For example, when using a ant project a with the junit-report tag, junit generates a complete listing of all failed unit tests per test run. With out a build number, matching a generated junit-report to a notification email is very difficult. -- 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: (CONTINUUM-990) Pass some continuum information to build tools when executing a build
[ http://jira.codehaus.org/browse/CONTINUUM-990?page=all ] John Didion reopened CONTINUUM-990: --- Oops...closed the wrong issue Pass some continuum information to build tools when executing a build - Key: CONTINUUM-990 URL: http://jira.codehaus.org/browse/CONTINUUM-990 Project: Continuum Issue Type: New Feature Components: Core system Reporter: John Didion Priority: Minor Attachments: maven2-build-properties.diff It would be nice to access some information (specifically build numbers) in the build script itself - for example, if I wanted to embed the build number in the jar manifest. I've attached a patch that does this for m2. I'm not sure if you could generalize it to work for all builds, or if you'd have to implement it separately for each build executor. -- 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: (CONTINUUM-990) Pass some continuum information to build tools when executing a build
[ http://jira.codehaus.org/browse/CONTINUUM-990?page=all ] John Didion closed CONTINUUM-990. - Resolution: Duplicate Dupliate of CONTINUUM-566 Pass some continuum information to build tools when executing a build - Key: CONTINUUM-990 URL: http://jira.codehaus.org/browse/CONTINUUM-990 Project: Continuum Issue Type: New Feature Components: Core system Reporter: John Didion Priority: Minor Attachments: maven2-build-properties.diff It would be nice to access some information (specifically build numbers) in the build script itself - for example, if I wanted to embed the build number in the jar manifest. I've attached a patch that does this for m2. I'm not sure if you could generalize it to work for all builds, or if you'd have to implement it separately for each build executor. -- 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: (CONTINUUM-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=all ] John Didion updated CONTINUUM-605: -- Attachment: change-list-recipient-source.diff Add a RecipientSource that derives addresses from the change list - Key: CONTINUUM-605 URL: http://jira.codehaus.org/browse/CONTINUUM-605 Project: Continuum Issue Type: New Feature Components: Notification Reporter: John Didion Fix For: 1.1 Attachments: change-list-recipient-source.diff, ChangeListRecipientSource.diff CruiseControl has the nice feature of only sending notification email to those users who submitted the changes in the build. I missed that feature when switching to Continuum, so I implemented it. It compiles a list of scm ids from the change list, then matches them against the developers in the POM to get email addresses. It delegates to the default RecipientSource if there is no change list. -- 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: (CONTINUUM-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=comments#action_79052 ] John Didion commented on CONTINUUM-605: --- I've added a new diff against the 1.0.3 tag. It would be idea if RecipientSources could be associated with notifiers (or at least notifier types) rather than just having one for the whole application. This involves a change to plexus, however. Add a RecipientSource that derives addresses from the change list - Key: CONTINUUM-605 URL: http://jira.codehaus.org/browse/CONTINUUM-605 Project: Continuum Issue Type: New Feature Components: Notification Reporter: John Didion Fix For: 1.1 Attachments: change-list-recipient-source.diff, ChangeListRecipientSource.diff CruiseControl has the nice feature of only sending notification email to those users who submitted the changes in the build. I missed that feature when switching to Continuum, so I implemented it. It compiles a list of scm ids from the change list, then matches them against the developers in the POM to get email addresses. It delegates to the default RecipientSource if there is no change list. -- 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: (CONTINUUM-991) Add meta refresh header to summary pages
Add meta refresh header to summary pages Key: CONTINUUM-991 URL: http://jira.codehaus.org/browse/CONTINUUM-991 Project: Continuum Issue Type: New Feature Reporter: John Didion Priority: Minor It's nice to refresh summary pages automatically to update build statuses without the user having to continually click the refresh button. I didn't include a patch because I'm working against the Maestro codebase, which has migrated all the UI to jsp. Should be the same concept, though. Just add meta http-equiv=refresh content=900/ to the head section. -- 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: (CONTINUUM-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=comments#action_79054 ] John Didion commented on CONTINUUM-418: --- I've created a patch against the Maestro source that provides RSS feeds on a per-project and per-group basis. When will those changes be RI'd into the trunk (i.e. the switch from velocity to JSP)? I will submit my patch as soon as I can do it against Continuum proper rather than Maestro. RSS feed for build status - Key: CONTINUUM-418 URL: http://jira.codehaus.org/browse/CONTINUUM-418 Project: Continuum Issue Type: Wish Components: Web interface Affects Versions: 1.0 Reporter: David Blevins Priority: Minor Fix For: 1.1 Attachments: rss.patch Lyndon Samson suggested on the Geronimo dev list that an rss feed for reporting build status would be a really great way to report build status. A neat application of that feature would be the ability to include continuum data on a confluence 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] Commented: (CONTINUUM-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=comments#action_79056 ] Brett Porter commented on CONTINUUM-418: Not sure what you mean by RI'd, but Continuum trunk is already based on WW2/JSP. In fact, we don't have any active branches any more, just trunk. RSS feed for build status - Key: CONTINUUM-418 URL: http://jira.codehaus.org/browse/CONTINUUM-418 Project: Continuum Issue Type: Wish Components: Web interface Affects Versions: 1.0 Reporter: David Blevins Priority: Minor Fix For: 1.1 Attachments: rss.patch Lyndon Samson suggested on the Geronimo dev list that an rss feed for reporting build status would be a really great way to report build status. A neat application of that feature would be the ability to include continuum data on a confluence 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: (MAVENUPLOAD-1211) OpenWFE 1.7.1 upload request
OpenWFE 1.7.1 upload request Key: MAVENUPLOAD-1211 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1211 Project: maven-upload-requests Issue Type: Task Reporter: John Mettraux http://www.openwfe.org/upload/openwfe-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-applic-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-apre-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-decision-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-embed-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-engine-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-engine-actions-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-jcr-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-query-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-sql-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-syndication-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-uman-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-uman-actions-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-webflow-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-webserver-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-worklist-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-worklist-actions-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-ws-1.7.2-bundle.jar http://www.openwfe.org/upload/openwfe-xlob-1.7.2-bundle.jar OpenWFE is an open source workflow engine under a BSD license -- 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: (MASSEMBLY-90) add a DependencySet filter based on type
[ http://jira.codehaus.org/browse/MASSEMBLY-90?page=all ] John Casey closed MASSEMBLY-90. --- Resolution: Fixed Ok, I've added both of the use cases you mention, and my unit tests seem to work. FWIW, the artifact filters in question have been factored out into their own project, to facilitate reuse in other projects. Give it a spin, and see what you think. The latest snapshot should have these changes incorporated. add a DependencySet filter based on type Key: MASSEMBLY-90 URL: http://jira.codehaus.org/browse/MASSEMBLY-90 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Jason Chaffee Assigned To: John Casey Fix For: 2.2 Attachments: AbstractAssemblyMojo-patch.txt, AbstractAssemblyMojo.java, AbstractAssemblyMojo.java, AbstractAssemblyMojo.java, AssemblyClassifierArtifactFilter.java, AssemblyTypeArtifactFilter.java, AssemblyTypeArtifactFilter.java, component.mdo, component.mdo-patch.txt, descriptor.mdo, descriptor.mdo-patch-.txt It would be nice to create a distribution bundle that contains both jars and webapps. These would be built by different projects and then an assembly project would list these in the pom. However, there is no way to filter the dependencies based on their type. This would be be a pretty easy thing to add. I have attached a new class, AssemblyTypeArtifactFilter and the required change to AbstractAsseblyMojo. The DependencySet class needs to be modified as well to add the type field, but I was not able to find it in the maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-968) Tests for continuum-release fail randomly
[ http://jira.codehaus.org/browse/CONTINUUM-968?page=comments#action_79068
]
Baerrach bonDierne commented on CONTINUUM-968:
--
I'm working off HEAD (revision 470234) with a local snapshot build of
maven-release-manager.
Windows XP (no cygwin)
Trying mvn clean install from project root fails at continuum-release with the
reason that:
{noformat}
junit.framework.AssertionFailedError: Test released version
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:111)
at
org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:115)
{noformat}
If go into the continuum-release module and run mvn clean it will sometimes
work and sometimes fail with the same error.
Because this error is intermittent it feels like a timing issue with the
Microsoft clock not being accurate enough. If I remember rightly it is only
even milliseconds or something. This might be causing the issue with the tests.
I remember that mvn release:prepare had similar issues too.
Tests for continuum-release fail randomly
-
Key: CONTINUUM-968
URL: http://jira.codehaus.org/browse/CONTINUUM-968
Project: Continuum
Issue Type: Test
Affects Versions: 1.1
Environment: tests fail for some environments and pass for others.
For some they fail at random
Reporter: Philippe Faes
Priority: Minor
Fix For: 1.1
Attachments: continuum-release.diff
The test for continuum-release fails randomly. This is because the two test
methods are executed in a random order (this is intended JUnit behavior), and
the tests alter files.
Solution is to restore files between tests (method setUp) and to force the
order of the two tests (create one test method that calls the two other
methods one by one).
Patch is attached. Please verify and commit.
--
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: (MNGECLIPSE-210) plugin fails to start (class not found)
[ http://jira.codehaus.org/browse/MNGECLIPSE-210?page=all ] Eugene Kuleshov closed MNGECLIPSE-210. -- Resolution: Duplicate plugin fails to start (class not found) --- Key: MNGECLIPSE-210 URL: http://jira.codehaus.org/browse/MNGECLIPSE-210 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Affects Versions: 0.0.9 Environment: windows, eclipse3.2 with wtp Reporter: thomas fischer Priority: Critical I can not use the plugin (see below). I have restarted eclipse using -clean. In the Plugins-View and the Plugin-Registriy View i can not found a maven entry. In Product Confiuration Window the maven entry seems to be ok. Thomas Problems: 1) if i try to vistit the preference page I got following message : Unable to create the selected prefenrens page. Reasen plugin was unable to load class ..Maven2Preference page 2) if i try to enable maven 2 plugin i got following 3 stacktraces: stacktrace 1### eclipse.buildId=M20060921-0945 java.version=1.5.0_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86 -clean Error Wed Nov 01 16:38:38 CET 2006 Could not create action delegate for id: org.maven.ide.eclipse.enableAction stacktrace 2 ## eclipse.buildId=M20060921-0945 java.version=1.5.0_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86 -clean Error Wed Nov 01 16:38:38 CET 2006 An error occurred while automatically activating bundle org.maven.ide.eclipse (400). org.osgi.framework.BundleException: Exception in org.maven.ide.eclipse.Maven2Plugin.start() of bundle org.maven.ide.eclipse. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.preFindLocalClass(EclipseLazyStarter.java:86) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:409) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:334) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:386) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:278) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1245) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:147) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:759) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:242) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:238) at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAction.java:120) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:225) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at
