[jira] Commented: (MRM-514) Archiva cannot compile and pass tests on JDK 1.6
[ http://jira.codehaus.org/browse/MRM-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109079 ] Dietrich Schulten commented on MRM-514: --- C:\Dokumente und Einstellungen\Dietrich>java -version java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b06) Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing) C:\Dokumente und Einstellungen\Dietrich>echo %java_home% C:\Programme\Java\jdk1.5.0_09 C:\Dokumente und Einstellungen\Dietrich> > Archiva cannot compile and pass tests on JDK 1.6 > > > Key: MRM-514 > URL: http://jira.codehaus.org/browse/MRM-514 > Project: Archiva > Issue Type: Bug > Components: system >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Priority: Minor > Fix For: 1.x > > Attachments: > TEST-org.apache.maven.archiva.policies.ChecksumPolicyTest.zip > > > When using JDK 1.6, Archiva cannot compile and pass all of its unit tests. -- 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-1510) The IRC notifier randomly fails
The IRC notifier randomly fails
---
Key: CONTINUUM-1510
URL: http://jira.codehaus.org/browse/CONTINUUM-1510
Project: Continuum
Issue Type: Bug
Components: Notifier - IRC
Affects Versions: 1.1-beta-3
Reporter: Trygve Laugstol
{code}
INFO | jvm 1| 2007/10/05 09:00:16 | 2007-10-05 09:00:16,329
[pool-1-thread-1] ERROR ContinuumNotificationDispatcher:default - Error while
trying to use the irc notifier.
INFO | jvm 1| 2007/10/05 09:00:16 |
org.codehaus.plexus.notification.NotificationException: Error while notifiying.
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.sendNotification(IrcContinuumNotifier.java:259)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:199)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:151)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:103)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.endBuild(DefaultBuildController.java:230)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:184)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
INFO | jvm 1| 2007/10/05 09:00:16 | at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
INFO | jvm 1| 2007/10/05 09:00:16 | at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
INFO | jvm 1| 2007/10/05 09:00:16 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
INFO | jvm 1| 2007/10/05 09:00:16 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
INFO | jvm 1| 2007/10/05 09:00:16 | at
java.lang.Thread.run(Thread.java:595)
INFO | jvm 1| 2007/10/05 09:00:16 | Caused by:
org.apache.maven.continuum.ContinuumException: Exception while checkConnection
to irc .irc.efnet.net
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.buildComplete(IrcContinuumNotifier.java:331)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.sendNotification(IrcContinuumNotifier.java:254)
INFO | jvm 1| 2007/10/05 09:00:16 | ... 12 more
INFO | jvm 1| 2007/10/05 09:00:16 | Caused by: java.net.SocketException:
Socket closed or already open (-1)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.schwering.irc.lib.IRCConnection.connect(IRCConnection.java:290)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.checkConnection(IrcContinuumNotifier.java:161)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.getIRConnection(IrcContinuumNotifier.java:120)
INFO | jvm 1| 2007/10/05 09:00:16 | at
org.apache.maven.continuum.notification.irc.IrcContinuumNotifier.buildComplete(IrcContinuumNotifier.java:325)
INFO | jvm 1| 2007/10/05 09:00:16 | ... 13 more
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1511) Improve error handling when not able to resolv artifacts
Improve error handling when not able to resolv artifacts
Key: CONTINUUM-1511
URL: http://jira.codehaus.org/browse/CONTINUUM-1511
Project: Continuum
Issue Type: Improvement
Reporter: Trygve Laugstol
When not able to resolve artifact, dump info about the artifact that was
supposed to be resolved and the stack trace into the build log instead of
getting "build error" and a stack trace in wrapper.log like this:
{code}
INFO | jvm 1| 2007/10/05 10:11:12 | 2007-10-05 10:11:12,431
[pool-1-thread-1] ERROR BuildController:default- Error executing action
update-project-from-working-directory '
INFO | jvm 1| 2007/10/05 10:11:12 |
org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing
action 'update-project-from-working-directory'
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:443)
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:148)
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
INFO | jvm 1| 2007/10/05 10:11:12 | at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
INFO | jvm 1| 2007/10/05 10:11:12 | at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
INFO | jvm 1| 2007/10/05 10:11:12 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
INFO | jvm 1| 2007/10/05 10:11:12 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
INFO | jvm 1| 2007/10/05 10:11:12 | at
java.lang.Thread.run(Thread.java:595)
INFO | jvm 1| 2007/10/05 10:11:12 | Caused by:
org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error
while mapping metadata:add.project.artifact.not.found.error
INFO | jvm 1| 2007/10/05 10:11:12 | add.project.unknown.error
INFO | jvm 1| 2007/10/05 10:11:12 |
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:168)
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java
:75)
INFO | jvm 1| 2007/10/05 10:11:12 | at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417)
INFO | jvm 1| 2007/10/05 10:11:12 | ... 8 more
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1487) should not be allowed to delete a build result that is still executing
[ http://jira.codehaus.org/browse/CONTINUUM-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109081 ] Emmanuel Venisse commented on CONTINUUM-1487: - It isn't enough to check the state, because in some case it is always set to BUILDING, for example if you restart Continuum during a build. a build result is still executing if: - state = building - project/build definition of the build result is the current build > should not be allowed to delete a build result that is still executing > -- > > Key: CONTINUUM-1487 > URL: http://jira.codehaus.org/browse/CONTINUUM-1487 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-4 > > > note that deleting the build result from on the build result page also seems > to skip confirmation. All I did was hit the space bar... -- 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: (DOXIA-158) doxia book with APT verbatim text not monospaced in PDF
[ http://jira.codehaus.org/browse/DOXIA-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109092 ] David Roussel commented on DOXIA-158: - Using the file https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-book/src/site/apt/usage.apt as input causes the problem. I don't know how to make a test case that takes in APT and outputs PDF via the itext module. Perhaps there needs to some integration tests in some other module for this purpose. > doxia book with APT verbatim text not monospaced in PDF > --- > > Key: DOXIA-158 > URL: http://jira.codehaus.org/browse/DOXIA-158 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Itext >Affects Versions: 1.0-alpha-9 > Environment: Java 5 on WinXP >Reporter: David Roussel > > I'm using doxia-maven-plugin 1.0-alpha-9 with APT as an imput source. When > I generate xhtml then the verbatim text comes out fine as a pre tag. When I > generate PDF the verbatim text is rendered with a variable width font, thus > my code examples are all over the place. -- 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: (DOXIA-158) doxia book with APT verbatim text not monospaced in PDF
[
http://jira.codehaus.org/browse/DOXIA-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Roussel updated DOXIA-158:
Attachment: doxia-test.zip
Ok, here is a project I generated with archetype:create and then added the
doxia-books plugin and an example APT with a verbatim block.
To build it:
{code}
mvn org.apache.maven.doxia:doxia-maven-plugin:render-books
{code}
Then look at the PDF in target and see that it does not used a fixed-width font.
> doxia book with APT verbatim text not monospaced in PDF
> ---
>
> Key: DOXIA-158
> URL: http://jira.codehaus.org/browse/DOXIA-158
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Itext
>Affects Versions: 1.0-alpha-9
> Environment: Java 5 on WinXP
>Reporter: David Roussel
> Attachments: doxia-test.zip
>
>
> I'm using doxia-maven-plugin 1.0-alpha-9 with APT as an imput source. When
> I generate xhtml then the verbatim text comes out fine as a pre tag. When I
> generate PDF the verbatim text is rendered with a variable width font, thus
> my code examples are all over the place.
--
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: (DOXIA-158) doxia book with APT verbatim text not monospaced in PDF
[ http://jira.codehaus.org/browse/DOXIA-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109090 ] Vincent Siveton commented on DOXIA-158: --- David, could you attach a simple test case? Thanks. > doxia book with APT verbatim text not monospaced in PDF > --- > > Key: DOXIA-158 > URL: http://jira.codehaus.org/browse/DOXIA-158 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Itext >Affects Versions: 1.0-alpha-9 > Environment: Java 5 on WinXP >Reporter: David Roussel > > I'm using doxia-maven-plugin 1.0-alpha-9 with APT as an imput source. When > I generate xhtml then the verbatim text comes out fine as a pre tag. When I > generate PDF the verbatim text is rendered with a variable width font, thus > my code examples are all over the place. -- 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-534) Test failure in RepositoryContentConsumerUtilTest
Test failure in RepositoryContentConsumerUtilTest
-
Key: MRM-534
URL: http://jira.codehaus.org/browse/MRM-534
Project: Archiva
Issue Type: Bug
Components: repository scanning
Environment: JDK 1.5.0_11
Windows XP
Maven 2.0.7
Reporter: ajbanck
Building from archiva/trunk, using 'mvn clean build' from the root, JDK
1.5.0_11
1 test is failing in RepositoryContentConsumerUtilTest:
---
Test set:
org.apache.maven.archiva.repository.scanner.RepositoryContentConsumerUtilTest
---
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.313 sec <<<
FAILURE!
testExecution(org.apache.maven.archiva.repository.scanner.RepositoryContentConsumerUtilTest)
Time elapsed: 0.031 sec <<< FAILURE!
junit.framework.AssertionFailedError:
Expectation failure on verify:
processFile("path/to/test-file.txt"): expected: 1, actual: 0
at org.easymock.MockControl.verify(MockControl.java:205)
at
org.apache.maven.archiva.repository.scanner.RepositoryContentConsumerUtilTest.testExecution(RepositoryContentConsumerUtilTest.java:140)
--
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: (DOXIA-136) Create an FML DTD or XSD
[ http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109087 ] David Roussel commented on DOXIA-136: - The maven1 faq.xsd looks good, go with that, since I just made mine up as an example, where-as I imagine the maven1 faq.xsd has been tested. I don't know about modelo, so no comment. > Create an FML DTD or XSD > > > Key: DOXIA-136 > URL: http://jira.codehaus.org/browse/DOXIA-136 > Project: Maven Doxia > Issue Type: Task > Components: Module - Fml >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0-beta-1 > > Attachments: DOXIA-136.diff > > > Review the M1 FAQ schema is certainly a good start. > http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd -- 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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109102 ] Graham Leggett commented on MNG-3139: - Also encounting this problem. The workaround worked, but I now have the problem of making sure that people who take over my role as build manager are aware that the default behaviour of the site plugin is broken, and that they cannot expect this plugin to work reliably or repeatably on future builds without manual intervention. > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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-935) Gentoo style pom dependencies
[ http://jira.codehaus.org/browse/MNG-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109099 ] Stefano Lenzi commented on MNG-935: --- I think that also the following document is worth noting for the design of a better dependencies resolution and filtering system: http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies Finally, I think that we should keep into account even the needs of projects which use maven for building native-code, like maven-nar-plugin. Some information on such needs are available here: http://docs.codehaus.org/display/MAVEN/Support+for+other+languages > Gentoo style pom dependencies > - > > Key: MNG-935 > URL: http://jira.codehaus.org/browse/MNG-935 > Project: Maven 2 > Issue Type: Wish > Components: Dependencies > Environment: None appropriate >Reporter: Brian C. Dilley > Fix For: 2.x > > > I'm a long time Gentoo Linux (http://www.gentoo.org/) user, and i think that > Maven could adpot some idea's from gentoo's portage > (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1). > Gentoo has a concept of "ebuilds" (which can be compared to poms). An ebuild > is an install script of sorts for installing a particular piece of software. > An ebuild defines, among other things, what it's dependencies (other ebuilds) > are. There are two types of dependencies: optional and required. A required > depency is something that the software needs to be built or run, while an > optional depency is the exact opposite... it is optional at compile and run > time. Basically an optional depency is a feature that the piece of sotware > supports that isn't necessary for it to function. > There is also something in gentoo called "USE flags". Use flags are a system > scope set of parameters that determine how ebuilds are built... and which > features are included or excluded. For instance, "alsa" is a USE flag. If > your use flags have "alsa" in them then any application that supports Alsa > (Advanced Linux Sound Architecture) as an optional dependency will be > compiled with support for alsa. Likewise, if your USE flags contain "-alsa" > then anything that has optional support for alsa will not be compiled with > support for alsa. I should also mention that if a particular ebuild requires > alsa... alsa will be built as well as it (because it requires alsa at > compile/run time)... but it and anything else that requires it will be the > only piece of software on the machine that has alsa support. I should also > note that Gentoo has what is called "profiles". Profiles contain (among > other things) a default set of USE flags for the general user, so in theory a > Gentoo user doesn't have to modify their USE flags whatsoever. > My thinking is that Maven could adopt this. Poms could specify required and > optional dependencies, and at a project level USE flags could be defined to > filter what gets included in a project. For instance someone using the Spring > Framework may not be using Hibernate... in their use flags "-hibernate" could > be defined so that maven knows not to grab hibernate (and all of it's > dependencies) just because they want to use the spring MVC framework. -- 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-1322) Attempt to store value with more than 256 chars
[ http://jira.codehaus.org/browse/CONTINUUM-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109105 ] Pavel Halas commented on CONTINUUM-1322: I did not test it any special way, I've just created my projects in the brand new database... > Attempt to store value with more than 256 chars > --- > > Key: CONTINUUM-1322 > URL: http://jira.codehaus.org/browse/CONTINUUM-1322 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Pavel Halas >Assignee: Emmanuel Venisse > > Using latest snapshot (continuum-20070621.01.war) I get this exception > causing the project build not processed at all -- red X on the project page, > no build statistics to be found. > 690292 [Thread-2] ERROR > org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - > Error executing task > edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: > javax.jdo.JDOFatalUserException: Attempt to store value > "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java > (from > /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" > in column ""NAME"" that has maximum length of 256. Please correct your data! > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) > Caused by: javax.jdo.JDOFatalUserException: Attempt to store value > "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java > (from > /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" > in column ""NAME"" that has maximum length of 256. Please correct your data! > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) > at > org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) > at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideField(ChangeFile.java) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideFields(ChangeFile.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) > at > org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) > at > org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.ja
[jira] Created: (MAVENUPLOAD-1751) JIntellitype 1.2.1
JIntellitype 1.2.1 -- Key: MAVENUPLOAD-1751 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1751 Project: maven-upload-requests Issue Type: Task Reporter: Emil A. Lefkof III Attachments: jintellitype-1.2.1-bundle.jar JIntellitype is a Java API for interacting with Microsoft Intellitype commands as well as registering for Global Hotkeys in your Java application. Have you ever wanted your Java application to use those special Play, Pause, and Stop media keys that are on many keyboards today? Now you can! -- 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-535) metadata-updater is changing lastUpdating timestamp when it shouldn't
metadata-updater is changing lastUpdating timestamp when it shouldn't - Key: MRM-535 URL: http://jira.codehaus.org/browse/MRM-535 Project: Archiva Issue Type: Bug Components: repository scanning Environment: JDK 1.5.0_11, Maven 2.0.7 Reporter: ajbanck Priority: Minor This is a bit of a trivial 'bug' and the result is not harmfull, but I think the metadata-updater should not change data that is valid. As far as I could find the lastUpdated field is the timestamp on which the metadata was last updated, so should not be touched in this case. During scanning, some (~200) maven-metadata.xml files are updated in my repository . The metadata being updated is: com.informatica.profiling.services profiling-model-persist 1.0-SNAPSHOT 20070213.050129 79 20070213050130 After update the lastUpdated field is changed to 20070213050129: 20070213050129 As far as I could find the lastUpdated field is the timestamp on which the metadata was last updated, so should not be touched in this case. Scanlog: 2007-10-05 14:38:41,043 [pool-2-thread-1] DEBUG org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Sending to consumer: metadata-updater 2007-10-05 14:38:41,090 [pool-2-thread-1] INFO org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater - Updated metadata: com/xxx/profiling/services/profiling-model-persist/1.0-SNAPSHOT/maven-metadata.xml 2007-10-05 14:38:46,356 [pool-2-thread-1] INFO org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater - Updated metadata: com/xxx/profiling/services/profiling-model-persist/maven-metadata.xml -- 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: (MSHADE-4) Extraneous directories and uneeded files included after shading
Extraneous directories and uneeded files included after shading --- Key: MSHADE-4 URL: http://jira.codehaus.org/browse/MSHADE-4 Project: Maven 2.x Shade Plugin Issue Type: Bug Reporter: Paul Hammant Refer build of https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/pom.xml Makes a jar that containes ... 0 Fri Oct 05 09:32:28 PDT 2007 META-INF/ 123 Fri Oct 05 09:32:28 PDT 2007 META-INF/MANIFEST.MF 0 Fri Oct 05 09:32:28 PDT 2007 org/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/containers/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/injectors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/lifecycle/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/monitors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/parameters/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/references/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/security/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/visitors/ 3766 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/AbstractAdapter.class 4113 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/InstanceAdapter.class 391 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Cache.class 408 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Inject.class 387 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/Behavior.class 689 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/BehaviorFactory.class 4770 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AbstractBehavior.class 3737 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AbstractBehaviorFactory.class 5132 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AdaptiveBehavior.class 745 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automated.class 1742 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automatic.class 1024 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Behaviors.class 1037 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Cached.class 2685 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Caching.class 1344 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/HiddenImplementation$1.class 4079 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/HiddenImplementation.class 1862 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/ImplementationHiding.class 457 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$Controller.class 1360 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$ControllerImpl.class 1933 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$ControllerWrapper.class 686 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$InterceptorThreadLocal.class 3617 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted.class 1507 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Interception.class 1143 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locked.class 1687 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locking.class 1797 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/OptInCaching.class 1130 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/PropertyApplicator$1.class 10001 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/PropertyApplicator.class 2436 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/PropertyApplying.class 3011 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Stored.class 562 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing$StoreThreadLocal.class 814 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing$StoreWrapper.class 4043 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing.class 842 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Synchronized.class 1660 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Synchronizing.class 1013 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/ThreadCached.class 1806 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/ThreadCaching.class 940 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/Characteristics$ImmutableProperties.class 2039 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/Characteristics.class 993 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentAdapter.class 689 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentFactory.class 1504 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/ComponentMonitor.class 279 Fri Oct 05 09:32:30 PDT 2007
[jira] Created: (MANTTASKS-89) Deploy ignores settings.xml for remoteRepository declared in ant build.xml
Deploy ignores settings.xml for remoteRepository declared in ant build.xml -- Key: MANTTASKS-89 URL: http://jira.codehaus.org/browse/MANTTASKS-89 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: deploy task Affects Versions: 2.0.7 Reporter: Pete Muir Given Any authentication settings declared in settings.xml are ignored. -- 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: (MANTTASKS-89) Deploy ignores settings.xml for remoteRepository declared in ant build.xml
[ http://jira.codehaus.org/browse/MANTTASKS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109119 ] Pete Muir commented on MANTTASKS-89: This requires MANTTASKS-85 to be fixed. > Deploy ignores settings.xml for remoteRepository declared in ant build.xml > -- > > Key: MANTTASKS-89 > URL: http://jira.codehaus.org/browse/MANTTASKS-89 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.7 >Reporter: Pete Muir > > Given > > > > > Any authentication settings declared in settings.xml are ignored. -- 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: (MANTTASKS-89) Deploy ignores settings.xml for remoteRepository declared in ant build.xml
[ http://jira.codehaus.org/browse/MANTTASKS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir closed MANTTASKS-89. -- Resolution: Cannot Reproduce Sorry, this is the result of applying multiple patches. > Deploy ignores settings.xml for remoteRepository declared in ant build.xml > -- > > Key: MANTTASKS-89 > URL: http://jira.codehaus.org/browse/MANTTASKS-89 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.7 >Reporter: Pete Muir > > Given > > > > > Any authentication settings declared in settings.xml are ignored. -- 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: (MANTTASKS-23) antlib:deploy doesn't set correct snapshot version
[ http://jira.codehaus.org/browse/MANTTASKS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109121 ] Pete Muir commented on MANTTASKS-23: When used in MANTTASKS-85, settings.xml is not used for deploy - a call to updateRepositoryWithSettings(repository); is needed in createDeploymentArtifactRepository. > antlib:deploy doesn't set correct snapshot version > -- > > Key: MANTTASKS-23 > URL: http://jira.codehaus.org/browse/MANTTASKS-23 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.4, 2.0.6, 2.0.7 > Environment: win xp, mvn 2.0.2, ant 1.6.5 >Reporter: Michal Stochmialek > Fix For: 2.0.8 > > Attachments: MANTTASKS-23.diff, MANTTASKS-23_site.diff, > maven-artifact-ant-MNG-2060.patch > > > I'm trying to deploy to maven remote repository jars produced by > ant. Those jars are in snapshot version. > Whole deployment process is going properly, but something is wrong with names > of deployed files. > When I'm deploying artifacts using normal 'maven deploy', "SNAPSHOT" in > the name is replaced by the current timestamp and the snapshot number (for > instance: "20060105.123437-3"). > But when I'm deploying with antlib, the name isn't changed. "SNAPSHOT" is > still in the name. And when I deploy snapshot again, the old one is > replaced by the new one (which also different from behavior of normal 'mvn > deploy'). > The metadata.xml also is generated incorrectly. Timestamp in snapshot tag is > missing: > > foo > foo-jar1 > 1.0-SNAPSHOT > > > 4 > > 20060209111228 > > > Here's an fragment of my ant script: > > > > > > depends="maven-poms,generate-jars"> > > > > > > > > > > > > > > > > > > > > > > > > The artifacts poms are in separate files which contain only artifactId, > groupId, > version, dependencies and remote repository url. > I also tried to deploy using 'mvn -f pom-file.xml deploy' to check if my > repository > url is specified correctly. And it works. Jar is deployed to remote > repository with > correct 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] Commented: (MAVENUPLOAD-1552) Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109125 ] Mark Matthews commented on MAVENUPLOAD-1552: Henri, I have the rsync location setup with your public key, however we're not Maven users ourselves, so is there some easy way to go from the -bundle.jar we have to the POM and structure you need to rsync? > Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio > -- > > Key: MAVENUPLOAD-1552 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1552 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/mysql-connector-java-5.0.6-bundle.jar > http://dev.mysql.com/downloads/connector/j/5.0.html > MySQL Connector/J is the official JDBC driver for MySQL. -- 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: (MANTTASKS-35) Support profiles in pom type
[ http://jira.codehaus.org/browse/MANTTASKS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated MANTTASKS-35: --- Attachment: MANTTASKS-35.patch Here is a patch. Use it like: > Support profiles in pom type > > > Key: MANTTASKS-35 > URL: http://jira.codehaus.org/browse/MANTTASKS-35 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement > Components: POM Integration >Reporter: Mark Hobson > Attachments: MANTTASKS-35.patch > > > Need to be able to pass in a list of profiles to activate in pom type - > there's currently a TODO in Pom.java for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1512) Constraint Violation Exception when deleting an empty group
[ http://jira.codehaus.org/browse/CONTINUUM-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109131 ] George Gastaldi commented on CONTINUUM-1512: ... 6) Try to delete the old group (The exception will be raised, complaining that there are some build history associated to the group) > Constraint Violation Exception when deleting an empty group > --- > > Key: CONTINUUM-1512 > URL: http://jira.codehaus.org/browse/CONTINUUM-1512 > Project: Continuum > Issue Type: Bug > Components: Database, Web - UI >Affects Versions: 1.1-beta-3 >Reporter: George Gastaldi >Priority: Minor > > Steps to reproduce the problem: > 1) Create a Group. > 2) Add a Maven 2 Project on it. > 3) Force Build > 4) Create another Group > 5) Move the project to the other group > 6) Try to delete the old group (The exception will be raised, complaining > that there are ) > Workarounds: > Delete all the build history for the moved projects before attempting to > delete the old group. -- 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-1512) Constraint Violation Exception when deleting an empty group
Constraint Violation Exception when deleting an empty group --- Key: CONTINUUM-1512 URL: http://jira.codehaus.org/browse/CONTINUUM-1512 Project: Continuum Issue Type: Bug Components: Database, Web - UI Affects Versions: 1.1-beta-3 Reporter: George Gastaldi Priority: Minor Steps to reproduce the problem: 1) Create a Group. 2) Add a Maven 2 Project on it. 3) Force Build 4) Create another Group 5) Move the project to the other group 6) Try to delete the old group (The exception will be raised, complaining that there are ) Workarounds: Delete all the build history for the moved projects before attempting to delete the old group. -- 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-1512) Constraint Violation Exception when deleting an empty group
[ http://jira.codehaus.org/browse/CONTINUUM-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1512: Fix Version/s: 1.1-beta-4 > Constraint Violation Exception when deleting an empty group > --- > > Key: CONTINUUM-1512 > URL: http://jira.codehaus.org/browse/CONTINUUM-1512 > Project: Continuum > Issue Type: Bug > Components: Database, Web - UI >Affects Versions: 1.1-beta-3 >Reporter: George Gastaldi >Priority: Minor > Fix For: 1.1-beta-4 > > > Steps to reproduce the problem: > 1) Create a Group. > 2) Add a Maven 2 Project on it. > 3) Force Build > 4) Create another Group > 5) Move the project to the other group > 6) Try to delete the old group (The exception will be raised, complaining > that there are ) > Workarounds: > Delete all the build history for the moved projects before attempting to > delete the old group. -- 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-1513) Release does not work when maven 2 executable is not on PATH
Release does not work when maven 2 executable is not on PATH
Key: CONTINUUM-1513
URL: http://jira.codehaus.org/browse/CONTINUUM-1513
Project: Continuum
Issue Type: Bug
Components: Environmental
Affects Versions: 1.1-beta-3
Environment: Maven 2 executable NOT ON PATH, just on profile
Reporter: George Gastaldi
Attachments: wrapper.20071005.log
When trying to release a project, when maven 2 is not on the path, the
following error occurs:
{code}
[INFO] Updating local copy against the scm...
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'aarh-bridge_visao'...
[INFO] Not generating release POMs
[ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Maven
execution failed, exit code: '127'
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:66)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107)
at
org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43)
at
org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Maven
execution failed, exit code: '127'
at
org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:103)
at
org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:121)
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:59)
... 11 more
{code}
It appears that the continuum release feature do not respect the build profile
for maven 2.
Attached is the log file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1487) should not be allowed to delete a build result that is still executing
[ http://jira.codehaus.org/browse/CONTINUUM-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1487. --- Resolution: Fixed fixed in rev 582423. (prevent user deleting buildResult currently building) > should not be allowed to delete a build result that is still executing > -- > > Key: CONTINUUM-1487 > URL: http://jira.codehaus.org/browse/CONTINUUM-1487 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-4 > > > note that deleting the build result from on the build result page also seems > to skip confirmation. All I did was hit the space bar... -- 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-1499) Translate to Brazilian Portuguese
[ http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109145 ] Olivier Lamy commented on CONTINUUM-1499: - Thanks. committed in rev 582425. Can you test ? > Translate to Brazilian Portuguese > - > > Key: CONTINUUM-1499 > URL: http://jira.codehaus.org/browse/CONTINUUM-1499 > Project: Continuum > Issue Type: Sub-task > Components: Web - UI >Reporter: George Gastaldi >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1499-gastaldi-2.patch, > CONTINUUM-1499-gastaldi.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-100) War overlay with merged web.xml
[ http://jira.codehaus.org/browse/MWAR-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109149 ] Richard C. L. Li commented on MWAR-100: --- I am in need of this feature, any progress? I can help to implement this feature if you permitted, this should be easy though. > War overlay with merged web.xml > --- > > Key: MWAR-100 > URL: http://jira.codehaus.org/browse/MWAR-100 > Project: Maven 2.x War Plugin > Issue Type: Wish >Affects Versions: 2.0 >Reporter: Anders Romin > > I'm looking for a way to use the war overlay feature and have the web.xml > merged with the content of both the parent war and the child war. > For example, we have two wars A and B, and B is depending on A using the > overlay feature. Now, I'd like all filters, servlets etc that are configured > in A to be available in the resulting war, as well as all filters, servlets > etc from B. If the id attributes clash, then the objects from B should be > used. > Any ideas how this could be accomplished? -- 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-3231) pom errors are not reported anymore
pom errors are not reported anymore
---
Key: MNG-3231
URL: http://jira.codehaus.org/browse/MNG-3231
Project: Maven 2
Issue Type: Bug
Components: Logging
Affects Versions: 2.1-alpha-1
Reporter: Brian Fox
See the following -e output, there's no indication what is wrong with the pom
{noformat}
$ mvn clean deploy -e
+ Error stacktraces are turned on.
Failed to validate POM for project foo at ...\pom.xml
Error stacktrace:
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for
project foo at ...\pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:298)
at
org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:111)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:165)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:820)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:418)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to
validate POM for project foo at ...\pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:914)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:675)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:426)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:193)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:289)
... 13 more
{noformat}
--
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: (MWAR-121) Maven-war-plugin not installing war. Installs ".jar" and renames it to ".war"
[ http://jira.codehaus.org/browse/MWAR-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-121. Resolution: Won't Fix Not an issue. The definition of the jar plugin in the parent pom conflicts with war > Maven-war-plugin not installing war. Installs ".jar" and renames it to ".war" > - > > Key: MWAR-121 > URL: http://jira.codehaus.org/browse/MWAR-121 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: Windows XP > Maven 2.0.7 > JDK 1.5.0_10 >Reporter: Dave Rathnow >Assignee: Stephane Nicoll > Attachments: war.zip > > > I'm trying to use the maven-war-plugin to install a war into my local > repository. "mvn clean install" runs fine and completes succesfully. If I > look under the target" directory in the project folder, there is, amoung > other things, a .jar and .war file. Both have been built properly. However, > if I look in my local repository, there is a .war file but when I open it, it > is actually the .jar file renamed to .war. > The attached zip file contains the pom for the project, the parent pom and > the output from the command "mvn clean install -X > output.log" -- 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
