[jira] Commented: (MRELEASE-184) Ability to perform releases with unsupported SCMs
[ http://jira.codehaus.org/browse/MRELEASE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=205204#action_205204 ] Trygve Laugstol commented on MRELEASE-184: -- That's the obvious solution if you have the time to do it. It's actually still relevant (even if my SCMs are supported) because the release plugin often fails in fantastic ways. The main point was that splitting up the quite big process into smaller parts in one way or another would be nice as the parts are useful in itself. Imagine for example a utility that tries to do automated updates of dependencies. For such a utility a tool to (correctly) update a pom.xml file would be very useful. Ability to perform releases with unsupported SCMs - Key: MRELEASE-184 URL: http://jira.codehaus.org/browse/MRELEASE-184 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: scm Reporter: Trygve Laugstol The current functionality of the release plugin is very useful, but requires that you use a supported SCM. It should be possible to change this requirement in (at least) two ways: o When doing the release process, pause and wait for the user to manually perform the steps that maven-scm normally would do, or o Break up the current monolitic goals into smaller parts so that the user can call them manually and to SCM operations in the background. I think this would be my approach, as there are several features of the release plugin that are useful outside of a release procedure context, the pom re-writing is the first that comes to mind. -- 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: (MCHANGES-159) Publish the schema with the JAR file
Publish the schema with the JAR file Key: MCHANGES-159 URL: http://jira.codehaus.org/browse/MCHANGES-159 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Trygve Laugstol Use something like the build helper plugin to attach the generated .xsd to the build so that others can use the schema format. -- 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: (MCHANGES-160) Support creating a plain text version of the report
Support creating a plain text version of the report --- Key: MCHANGES-160 URL: http://jira.codehaus.org/browse/MCHANGES-160 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Trygve Laugstol Useful when the change log is to be included in a native package or in a WAR as documentation. -- 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: (MCHANGES-159) Publish the schema with the JAR file
[ http://jira.codehaus.org/browse/MCHANGES-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=181859#action_181859 ] Trygve Laugstol commented on MCHANGES-159: -- Ok, but that still make it hard to use as a dependency Publish the schema with the JAR file Key: MCHANGES-159 URL: http://jira.codehaus.org/browse/MCHANGES-159 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Trygve Laugstol Use something like the build helper plugin to attach the generated .xsd to the build so that others can use the schema format. -- 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-2081) grails-maven-plugin 0.3
grails-maven-plugin 0.3 --- Key: MAVENUPLOAD-2081 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2081 Project: Maven Upload Requests Issue Type: Wish Reporter: Trygve Laugstol The upload bundles was created by me from: http://forge.octo.com/archiva/browse/com.octo.mtg/grails-maven-plugin/0.3 I'm a developer on the project, see -- 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-144) Custom filter list does not work
[
http://jira.codehaus.org/browse/MWAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124148
]
Trygve Laugstol commented on MWAR-144:
--
Verified, works like a charm!
Custom filter list does not work
Key: MWAR-144
URL: http://jira.codehaus.org/browse/MWAR-144
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Trygve Laugstol
Assignee: Olivier Lamy
Fix For: 2.1-alpha-2
When specifying filters on the plugin (not inside project) like this:
{code}
configuration
resource
directorypolopoly-resources/config_ptest/directory
targetPathWEB-INF/config/targetPath
/resource
warNameptest/warName
workDirectorytarget/ptest-work/workDirectory
filters
filtersrc/main/filters/filter.ptest.properties/filter
/filters
webResources
resource
directorysrc/main/resources/directory
targetPathWEB-INF/classes/targetPath
filteringtrue/filtering
/resource
/webResources
{code}
the list of filters is ignored. If I move the filters list to inside the
project they work as expected. The documentation explicitly say that this
is possible under the section Filtering webResources.
--
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-144) Custom filter list does not work
[
http://jira.codehaus.org/browse/MWAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124008
]
Trygve Laugstol commented on MWAR-144:
--
No, I haven't. If the latest SNAPSHOT fixes is, consider this a documentation
bug as it should be specified with a since description.
Also, if ${basedir} really is required (if it is a File[] array it isn't), that
is also a bug. All file references are *always* relative to the project itself.
Custom filter list does not work
Key: MWAR-144
URL: http://jira.codehaus.org/browse/MWAR-144
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Trygve Laugstol
Assignee: Olivier Lamy
Fix For: 2.1-alpha-2
When specifying filters on the plugin (not inside project) like this:
{code}
configuration
resource
directorypolopoly-resources/config_ptest/directory
targetPathWEB-INF/config/targetPath
/resource
warNameptest/warName
workDirectorytarget/ptest-work/workDirectory
filters
filtersrc/main/filters/filter.ptest.properties/filter
/filters
webResources
resource
directorysrc/main/resources/directory
targetPathWEB-INF/classes/targetPath
filteringtrue/filtering
/resource
/webResources
{code}
the list of filters is ignored. If I move the filters list to inside the
project they work as expected. The documentation explicitly say that this
is possible under the section Filtering webResources.
--
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: (MWAR-144) Custom filter list does not work
Custom filter list does not work
Key: MWAR-144
URL: http://jira.codehaus.org/browse/MWAR-144
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Trygve Laugstol
When specifying filters on the plugin (not inside project) like this:
{code}
configuration
resource
directorypolopoly-resources/config_ptest/directory
targetPathWEB-INF/config/targetPath
/resource
warNameptest/warName
workDirectorytarget/ptest-work/workDirectory
filters
filtersrc/main/filters/filter.ptest.properties/filter
/filters
webResources
resource
directorysrc/main/resources/directory
targetPathWEB-INF/classes/targetPath
filteringtrue/filtering
/resource
/webResources
{code}
the list of filters is ignored. If I move the filters list to inside the
project they work as expected. The documentation explicitly say that this is
possible under the section Filtering webResources.
--
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-1656) Spam
[ http://jira.codehaus.org/browse/CONTINUUM-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123493 ] Trygve Laugstol commented on CONTINUUM-1656: How do you propose to fix this issue? Is it pretty hard for continuum to tell what happened other than failure. Spam Key: CONTINUUM-1656 URL: http://jira.codehaus.org/browse/CONTINUUM-1656 Project: Continuum Issue Type: Bug Components: Notification Subsystem Affects Versions: 1.1 Environment: Windows 2003 server, JRE 1.6.0_04-b12 Reporter: Dan Peder Eriksen Fix For: 1.2 If subversion is not available continuum will continue to send an ERROR message until it is available, even though continuum is set to only send notifcations on status change. This resulted in 2400 emails during a night when the subversion repository did not come online during a reboot. Build result: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/svn/x/trunk/sub-projects/email-service' svn: PROPFIND of '/svn/x/trunk/sub-projects/email-service': could not connect to server (http://x..no:8082) --- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3382) Upload and download terminal output is not suitable for logging to a text file
[ http://jira.codehaus.org/browse/MNG-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trygve Laugstol closed MNG-3382. Assignee: Trygve Laugstol Resolution: Won't Fix Use -B (non-interactive) which has been in Maven for years. Upload and download terminal output is not suitable for logging to a text file -- Key: MNG-3382 URL: http://jira.codehaus.org/browse/MNG-3382 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.8 Reporter: Matt Read Assignee: Trygve Laugstol We are using Maven with Bamboo on Windows, the page used to display the build log performs very badly when rendering large logs and we've discovered that the single biggest contributor is the thousands of lines that record progress on uploading and downloading dependencies. E.g. 04-Feb-2008 14:50:22 592/#8203;2310K 04-Feb-2008 14:50:22 596/#8203;2310K 04-Feb-2008 14:50:22 600/#8203;2310K 04-Feb-2008 14:50:22 604/#8203;2310K 04-Feb-2008 14:50:22 608/#8203;2310K 04-Feb-2008 14:50:22 612/#8203;2310K 04-Feb-2008 14:50:22 616/#8203;2310K 04-Feb-2008 14:50:22 620/#8203;2310K 04-Feb-2008 14:50:22 624/#8203;2310K What's a sensible way to switch this off or change the increment for each line? If someone can suggest an approach and area of the code to focus on I'll try to supply a 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] Created: (MRM-648) Add description field to the different types of repositories and proxies
Add description field to the different types of repositories and proxies Key: MRM-648 URL: http://jira.codehaus.org/browse/MRM-648 Project: Archiva Issue Type: New Feature Affects Versions: 1.0 Reporter: Trygve Laugstol When looking over the repositories page it would be useful to have a description for each of the repositories configured. Personally I need it to be able to describe the owner of the repository and indended purpose. -- 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] Created: (CONTINUUM-1349) Improve add project screen flow
Improve add project screen flow - Key: CONTINUUM-1349 URL: http://jira.codehaus.org/browse/CONTINUUM-1349 Project: Continuum Issue Type: Improvement Reporter: Trygve Laugstol After successfully adding a project I don't know of the project was added or not because I'm taken back to the front page without any messages or anything. Either show a message that the project (with project name and project group) was added or take me directly to the project's overview 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] Updated: (CONTINUUM-1347) WebDAV enable the working copies
[ http://jira.codehaus.org/browse/CONTINUUM-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trygve Laugstol updated CONTINUUM-1347: --- Description: When debugging test failures it would be nice to be able to mount the working copies on my local laptop so I can browse and view files with Finder (on os x), Nautilus on Gnome or cadaver. Complexity: Expert (was: Intermediate) WebDAV enable the working copies Key: CONTINUUM-1347 URL: http://jira.codehaus.org/browse/CONTINUUM-1347 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Trygve Laugstol When debugging test failures it would be nice to be able to mount the working copies on my local laptop so I can browse and view files with Finder (on os x), Nautilus on Gnome or cadaver. -- 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-1347) WebDAV enable the working copies
WebDAV enable the working copies Key: CONTINUUM-1347 URL: http://jira.codehaus.org/browse/CONTINUUM-1347 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Trygve Laugstol -- 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-1346) Error while parsing test results
[
http://jira.codehaus.org/browse/CONTINUUM-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102155
]
Trygve Laugstol commented on CONTINUUM-1346:
Additional locale info:
{code}
$ locale
LANG=
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LC_ALL=C
{code}
Error while parsing test results
Key: CONTINUUM-1346
URL: http://jira.codehaus.org/browse/CONTINUUM-1346
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1-alpha-2
Reporter: Trygve Laugstol
{code}
2007-07-13 14:16:42,290 [pool-1-thread-1] ERROR Action:execute-builder
- Error getting test results
java.lang.NumberFormatException: For input string: 1,721.377
at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Double.parseDouble(Double.java:482)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:307)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:272)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:184)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
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:613)
{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-1346) Error while parsing test results
Error while parsing test results
Key: CONTINUUM-1346
URL: http://jira.codehaus.org/browse/CONTINUUM-1346
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1-alpha-2
Reporter: Trygve Laugstol
{code}
2007-07-13 14:16:42,290 [pool-1-thread-1] ERROR Action:execute-builder
- Error getting test results
java.lang.NumberFormatException: For input string: 1,721.377
at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Double.parseDouble(Double.java:482)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:307)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:272)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:184)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
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:613)
{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: (MNG-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94213
]
Trygve Laugstol commented on MNG-2854:
--
A couple of code comments:
* Call the class PomPropertiesUtil instead of Manager. There are a lot of other
Manager classes in Maven and they are Plexus components, while this is a normal
utility class.
* Use org.codehaus.plexus.util.IOUtil.close() to close streams.
* When comparing the properties file why not generate Properties object and
load the existing properties file and use Properties.equals()? That should save
you some hassle.
Recreating pom.properties always breaks the archivers uptodate check
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties-2.patch,
maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation.
(Unless the flag addMavenDescriptor is set to false, which few people do.)
This forced recreation makes the uptodate check fail. In other words, jar
files are always recreated, regardless whether anything was recompiled.
Obviously, this makes the uptodate check of war files etc. fail as well,
because the included jar files are always changed.. This is a major drawback,
because it makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch
does:
- It is obviously bad, that the generated pom.properties file is in the
projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which
seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create
multiple artifacts. In other
words, it isn't good to have a single file. The patch renames the
pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
unique.
- Finally, the patch makes the maven-archiver check, whether the
pom.properties file has
actually changed. (In other words, whether groupId, artifactId, or version
have changed.)
It does so, by writing the file to an internal buffer and comparing the
file on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version
haven't changed, the pom.properties file remains unchanged. In particular,
the jar file doesn't need to be recreated.
--
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-2816) Pom without xsd import is not validated
[ http://jira.codehaus.org/browse/MNG-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87339 ] Trygve Laugstol commented on MNG-2816: -- This is a feature, not a bug! ;) Maven doesn't use the schemas to validate in any case, and in addition it allows any element as a way to be flexible so that other tools can add extenstions without breaking maven. Pom without xsd import is not validated --- Key: MNG-2816 URL: http://jira.codehaus.org/browse/MNG-2816 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 2.0.4 Reporter: Kristoffer Moum I added a dependency to a module a couple of days ago. I did it just a tad too quickly (copy and paste from dependency management), and forgot to enclose with the dependency tag, i.e. I had the following structure: dependencies groupIdorg.springframework/groupId artifactIdspring-web/artifactId /dependencies So - what happened when I did an mvn install the dependency was ignored rather than producing an error message as the pom was actually valid xml. It would be nice to have some defaulting of xsd if none was specified. -- 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-2773) Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5 candidate
Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5
candidate
-
Key: MNG-2773
URL: http://jira.codehaus.org/browse/MNG-2773
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Repositories
Affects Versions: 2.0.5
Reporter: Trygve Laugstol
Trussing the mvn process shows that Maven tries to connect to the plugin
repository on every run, instead of the daily check.
{code}
[16:38:[EMAIL PROTECTED]:monitor-core]$ truss -t connect mvn
-Dmaven.test.skip=true install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for
updates from codehaus-snapshots
/1: connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT) = 0
/1: connect(7, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for
updates from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for
updates from codehaus-snapshots
/1: connect(9, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for updates
from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
updates from codehaus-snapshots
[INFO] [plexus:descriptor {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the
local scope.
{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: (MAVENUPLOAD-1309) iBatis 2.2.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1309?page=comments#action_84400 ] Trygve Laugstol commented on MAVENUPLOAD-1309: -- I've added a bundle for iBatis 2.3.0 too, this one including source and javadoc tarballs. http://codehaus.org/~trygvis/ibatis-2.3.0.jar iBatis 2.2.0 Key: MAVENUPLOAD-1309 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1309 Project: maven-upload-requests Issue Type: Bug Reporter: Trygve Laugstol http://codehaus.org/~trygvis/ibatis-common-2.2.0.jar http://codehaus.org/~trygvis/ibatis-sqlmap-2.2.0.jar http://codehaus.org/~trygvis/ibatis-dao-2.2.0.jar Note that these jars use a different group id compared to the old ones. This one uses (the correct IMO) org.apache.ibatis, while the old ones used com.ibatis. -- 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-1309) iBatis 2.2.0
iBatis 2.2.0 Key: MAVENUPLOAD-1309 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1309 Project: maven-upload-requests Issue Type: Bug Reporter: Trygve Laugstol http://codehaus.org/~trygvis/ibatis-common-2.2.0.jar http://codehaus.org/~trygvis/ibatis-sqlmap-2.2.0.jar http://codehaus.org/~trygvis/ibatis-dao-2.2.0.jar Note that these jars use a different group id compared to the old ones. This one uses (the correct IMO) org.apache.ibatis, while the old ones used com.ibatis. -- 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-2727) Fix Logging in threadsafe components
[ http://jira.codehaus.org/browse/MNG-2727?page=comments#action_83894 ] Trygve Laugstol commented on MNG-2727: -- Shouldn't the component use a monitor instead of logging in the cases where the output is useful on a per-build basis? Fix Logging in threadsafe components Key: MNG-2727 URL: http://jira.codehaus.org/browse/MNG-2727 Project: Maven 2 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Assigned To: Jason van Zyl -- 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-1094) Continuum does not build with Sun JDK 6
[ http://jira.codehaus.org/browse/CONTINUUM-1094?page=comments#action_83459
]
Trygve Laugstol commented on CONTINUUM-1094:
This issue is rather useless unless you can say what failed. Please add the
surefire test reports.
Continuum does not build with Sun JDK 6
---
Key: CONTINUUM-1094
URL: http://jira.codehaus.org/browse/CONTINUUM-1094
Project: Continuum
Issue Type: Bug
Environment: continuum trunk r490449
linux 2.6.12
Sun JDK 6 (build 1.6.0-b105)
Reporter: Minto van der Sluis
snippet of the build output (mvn clean install).
...
[INFO]
[INFO] Building Continuum Data Management API
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/minto/rommel/svn-src/continuum/continuum-data-management/target
[INFO] Deleting directory
/home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
[INFO] Deleting directory
/home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
[INFO] [plexus:descriptor {execution: generate}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 2 source files to
/home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/minto/rommel/svn-src/continuum/continuum-data-management/target/surefire-reports
---
T E S T S
---
Running org.apache.maven.continuum.management.DataManagementToolTest
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.348 sec
FAILURE!
Results :
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
Builds with JDK 5 runs just fine.
--
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: (MPRELEASE-23) Ability to perform releases with unsupported SCMs
Ability to perform releases with unsupported SCMs - Key: MPRELEASE-23 URL: http://jira.codehaus.org/browse/MPRELEASE-23 Project: maven-release-plugin Issue Type: New Feature Reporter: Trygve Laugstol The current functionality of the release plugin is very useful, but requires that you use a supported SCM. It should be possible to change this requirement in (at least) two ways: o When doing the release process, pause and wait for the user to manually perform the steps that maven-scm normally would do, or o Break up the current monolitic goals into smaller parts so that the user can call them manually and to SCM operations in the background. I think this would be my approach, as there are several features of the release plugin that are useful outside of a release procedure context, the pom re-writing is the first that comes to mind. -- 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: (MDEP-26) New goal to write classpath string with all dependencies from local repo
[ http://jira.codehaus.org/browse/MDEP-26?page=comments#action_81869 ]
Trygve Laugstol commented on MDEP-26:
-
The classpath should definitely *not* be sorted alphabeticaly by default as
applications might depend on the order of the classpath.
New goal to write classpath string with all dependencies from local repo
Key: MDEP-26
URL: http://jira.codehaus.org/browse/MDEP-26
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 1.0
Reporter: Anagnostopoulos Kostis
Assigned To: Brian Fox
Priority: Minor
Attachments: MDEP-26_BuildClasspathMojo.java
Hi to all,
'm wondering whether it would be usefull to make a new mojo that when
executed it will output a text file containing the required classpath string
to run a project directly from the local repository.
For instance, the file would contain a classpath string like that :
{noformat}
/home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/
{noformat}
The result file could then be used like that:
{noformat}
java -cp `cat resultFile` MyClass
{noformat}
The new goal should maybe a sub-class of AbstractFromDependenciesMojo.
In that case, the useSubDirectoryPerType and useSubDirectoryPerArtifact
params should move to (copy/unpack)-dependencies mojo classes. Anyway, these
params are only used by sub-classes, so, their definition should be propably
inside of those.
Next are the parameters of the mojo i propose:
goal name: dependency:printClasspath
params:
|| Param Name || Type || Description
| outputFile| File | The file to write the classpath string into.
|
| overwrite | boolean| If true, re-write file even when nothing has
changed. |
| includeTypes | String | Comma Separated list of Types to include. |
| excludeTypes | String | Comma Separated list of Types to exclude |
| includeProjectArtifact| boolean | see [this
issue|http://jira.codehaus.org/browse/MDEP-25]. |
--
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: (MDEP-26) New goal to write classpath string with all dependencies from local repo
[ http://jira.codehaus.org/browse/MDEP-26?page=comments#action_80861 ]
Trygve Laugstol commented on MDEP-26:
-
Check out the appassembler [1] plugin. It is a useful add-on to the assembly
plugin that generates complete wrapper scripts for your main classes.
[1]: http://mojo.codehaus.org/appassembler
New goal to write classpath string with all dependencies from local repo
Key: MDEP-26
URL: http://jira.codehaus.org/browse/MDEP-26
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 1.0
Reporter: Anagnostopoulos Kostis
Assigned To: Brian Fox
Priority: Minor
Attachments: MDEP-26_BuildClasspathMojo.java
Hi to all,
'm wondering whether it would be usefull to make a new mojo that when
executed it will output a text file containing the required classpath string
to run a project directly from the local repository.
For instance, the file would contain a classpath string like that :
{noformat}
/home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/
{noformat}
The result file could then be used like that:
{noformat}
java -cp `cat resultFile` MyClass
{noformat}
The new goal should maybe a sub-class of AbstractFromDependenciesMojo.
In that case, the useSubDirectoryPerType and useSubDirectoryPerArtifact
params should move to (copy/unpack)-dependencies mojo classes. Anyway, these
params are only used by sub-classes, so, their definition should be propably
inside of those.
Next are the parameters of the mojo i propose:
goal name: dependency:printClasspath
params:
|| Param Name || Type || Description
| outputFile| File | The file to write the classpath string into.
|
| overwrite | boolean| If true, re-write file even when nothing has
changed. |
| includeTypes | String | Comma Separated list of Types to include. |
| excludeTypes | String | Comma Separated list of Types to exclude |
| includeProjectArtifact| boolean | see [this
issue|http://jira.codehaus.org/browse/MDEP-25]. |
--
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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=comments#action_80471 ] Trygve Laugstol commented on MNG-2664: -- This is not a good idea until the webdav wagon is working properly. It's probably better to add support loading custom wagons in the deploy plugin directly. Add native support for webdav - Key: MNG-2664 URL: http://jira.codehaus.org/browse/MNG-2664 Project: Maven 2 Issue Type: New Feature Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Arnaud Heritier Fix For: 2.0.5 Attachments: MNG-2664.patch Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an artifact on a remote repository with webdav. This is really annoying for archiva which supports webdav for uploads. -- 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-965) Use a jndi object for mail notifier
[ http://jira.codehaus.org/browse/CONTINUUM-965?page=comments#action_78095 ] Trygve Laugstol commented on CONTINUUM-965: --- What does this mean? You want to use something other than the simple mailer thing? Use a jndi object for mail notifier --- Key: CONTINUUM-965 URL: http://jira.codehaus.org/browse/CONTINUUM-965 Project: Continuum Issue Type: Task Components: Mail Notifier Affects Versions: 1.1 Reporter: Emmanuel Venisse Fix For: 1.1 -- 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: (MINSTALL-29) Can't use maven-install-plugin with goalinstall-file/goal in POM
[ http://jira.codehaus.org/browse/MINSTALL-29?page=comments#action_76633 ] Trygve Laugstol commented on MINSTALL-29: - A working work-around for this issue is to use this within project: properties groupIdjflex/groupId artifactIdjflex/artifactId versionunknown/version filebootstrap/jflex.jar/file packagingjar/packaging generatePomtrue/generatePom /properties Can't use maven-install-plugin with goalinstall-file/goal in POM Key: MINSTALL-29 URL: http://jira.codehaus.org/browse/MINSTALL-29 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.2 Environment: WinXP, running M2 in Cygwin Reporter: Brad Harper Priority: Minor This issue is related to another I submitted recently. In fact, the earlier issue was encounted in an earlier attempt to get the same results. (see bottom, below.) Consider the POM descriptor containing pluginRepositories pluginRepository idsnapshots/id urlhttp://svn.apache.org/maven-snapshot-repository/url /pluginRepository /pluginRepositories build plugins plugin artifactIdmaven-install-plugin/artifactId version2.2-SNAPSHOT/version executions execution idinstall-library/id phaseinstall/phase goals goalinstall-file/goal /goals configuration groupIdcom.epsiia.dxr.third-party/groupId artifactIddxr-third-party-WINDOWS-X86-com-emc-centera-fplibrary-lib/artifactId version2.0SP1/version packaginglib/packaging fileFPLibrary.lib/file /configuration /execution /executions /plugin /plugins /build M2 fails to build in this project because all /configuration elements are read-only. [I'm attempting to use the 2.2-SNAPSHOT because I get the same error in stable versions. ] Shouldn't this execution be allowable and equivalent to the CLI invocation % mvn install:install-file -DgroupId=com.epsiia.dxr.third-party .. I'm trying to create a mind-numbingly simple environment, so that other less-experienced developers aren't required to know which of the third-party libraries need to be manually installed via once-only occurances should the local repository need to be re-constructed. -- 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-529) Modules (child) scm connection URLs are not constructed correctly
[ http://jira.codehaus.org/browse/CONTINUUM-529?page=comments#action_75068
]
Trygve Laugstol commented on CONTINUUM-529:
---
I'm not sure how to solve this because this means that Maven will construct a
different SCM URL given the child POM and a repository than Continuum will.
An alternative is to include the artifact and group id in the module section
to make it possible to correctly map the path and the artifact.
Modules (child) scm connection URLs are not constructed correctly
-
Key: CONTINUUM-529
URL: http://jira.codehaus.org/browse/CONTINUUM-529
Project: Continuum
Issue Type: Bug
Components: Core system, SCM
Affects Versions: 1.0.2
Reporter: Grégory Joseph
Priority: Critical
Fix For: 1.1
It *seems* to me that, when adding a parent pom to continuum, which has
modules defined, but the scm url only defined in the parent, it gets and
parses the child poms correctly, but their scm URLs are build as
${parentScmUrl}/${childArtifactId} , while I think they should rather be
${parentScmUrl}/${modulePath}
Maybe this is a maven inheritance issue, though ?
--
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-529) Modules (child) scm connection URLs are not constructed correctly
[ http://jira.codehaus.org/browse/CONTINUUM-529?page=all ]
Trygve Laugstol updated CONTINUUM-529:
--
Priority: Major (was: Critical)
Setting the priority level back to normal.
Modules (child) scm connection URLs are not constructed correctly
-
Key: CONTINUUM-529
URL: http://jira.codehaus.org/browse/CONTINUUM-529
Project: Continuum
Issue Type: Bug
Components: Core system, SCM
Affects Versions: 1.0.2
Reporter: Grégory Joseph
Fix For: 1.1
It *seems* to me that, when adding a parent pom to continuum, which has
modules defined, but the scm url only defined in the parent, it gets and
parses the child poms correctly, but their scm URLs are build as
${parentScmUrl}/${childArtifactId} , while I think they should rather be
${parentScmUrl}/${modulePath}
Maybe this is a maven inheritance issue, though ?
--
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-812) Fix resolution of ${plexus.home}
[ http://jira.codehaus.org/browse/CONTINUUM-812?page=comments#action_72280
]
Trygve Laugstol commented on CONTINUUM-812:
---
I'm pretty sure the code for finding out plexus.hom is in plexus-servlet
somewhere, I'm sure something can be stolen from that code.
I think some clever code for figuring out how to handle un-exploded webapps
needs to be written too.
Fix resolution of ${plexus.home}
Key: CONTINUUM-812
URL: http://jira.codehaus.org/browse/CONTINUUM-812
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1
Reporter: Carlos Sanchez
Continuum creates the DB in a folder called ${plexus.home}
--
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: (MECLIPSE-138) Design Plugin classes for extension
[ http://jira.codehaus.org/browse/MECLIPSE-138?page=comments#action_71043 ] Trygve Laugstol commented on MECLIPSE-138: -- That is not how one designs for extentions. You'd rather make a plug-in mechanism or a selected, few methods protected to be able to enhance the current implementation. Another alternative is to move the functionality you need out of the core plugin and re-use that in another plugin. Design Plugin classes for extension --- Key: MECLIPSE-138 URL: http://jira.codehaus.org/browse/MECLIPSE-138 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Andrew Perepelytsya Please, replace all private access and methods in plugin classes with protected. I'm trying to create a WSAD plugin by reusing (and subclassing) a number of pure-Eclipse plugin classes, but it's impossible to accomplish without changing the original sources. Doing this will simplify contributions. -- 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-775) Add a finger service/interface that users can query for the current status of a project.
Add a finger service/interface that users can query for the current status of a
project.
Key: CONTINUUM-775
URL: http://jira.codehaus.org/browse/CONTINUUM-775
Project: Continuum
Type: Wish
Components: Core system
Reporter: Trygve Laugstol
Beeing able to go:
{code}
$ finger [EMAIL PROTECTED]
[EMAIL PROTECTED]
{code}
would be pretty shibby
http://en.wikipedia.org/wiki/Finger_protocol
--
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-769) Jira Notifier
[ http://jira.codehaus.org/browse/CONTINUUM-769?page=comments#action_69494 ] Trygve Laugstol commented on CONTINUUM-769: --- Good idea. Just as a note this should probably use the Maven Issue API to be able to work with any issue tracking system. It should also be possible to implement this as a notifiers so no core changes should be required (as it seems to me now anyway) Jira Notifier - Key: CONTINUUM-769 URL: http://jira.codehaus.org/browse/CONTINUUM-769 Project: Continuum Type: Wish Components: Notification Reporter: Henri Yandell Couldn't see this mentioned yet, so thought I'd suggest that Continuum have a Jira notifier so that build failures/successes can be submitted to Jira as issues. Pretty sure I've heard of people doing that. -- 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: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=comments#action_69168 ] Trygve Laugstol commented on MEJB-13: - I suggested that the ejb plugin had a resources section that it could apply to the ejb client jar. The ejb jar itself has to behave in the exact same way as the normal jar plugin. This will give you what you are asking for without breaking the normal Maven way of packaging an artifact. The bug here is that the ejb plugin applies the includes and excludes in addition to the one specified in the pom. Add support for configuring exclusion filter for main ejb jar - Key: MEJB-13 URL: http://jira.codehaus.org/browse/MEJB-13 Project: Maven 2.x Ejb Plugin Type: New Feature Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 Reporter: Fredrik Vraalsen Attachments: MEJB-configure-excludes.patch, maven-ejb-plugin-configure-main-jar-excludes-2.patch, maven-ejb-plugin-configure-main-jar-excludes.patch In my ejb project I have certain files that must only be included in the ejb-client jar and not the main ejb jar (jboss-client.xml, application-client.xml and jndi.properties). When these files are present in the main ejb jar, JBoss refuses to deploy my ejbs. Thus, I need a way to configure the exclusion filter for the main ejb jar. This is currently hardcoded in EjbMojo.java. I am attaching a patch to make this configurable in the same way as clientExcludes. Below is an example of the kind of configuration I am using: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId version2.1-SNAPSHOT/version configuration excludes excludejndi.properties/exclude excludeMETA-INF/*-client.xml/exclude exclude**/interfaces//exclude exclude**/assetrepository/Asset.class/exclude /excludes generateClienttrue/generateClient clientExcludes clientExcludeMETA-INF/ejb-jar.xml/clientExclude clientExcludeMETA-INF/jboss.xml/clientExclude clientExclude**/dao//clientExclude clientExclude**/entity//clientExclude clientExclude**/jaxb//clientExclude clientExclude**/session//clientExclude clientExclude**/xmldb//clientExclude /clientExcludes /configuration /plugin -- 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: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=comments#action_69049 ] Trygve Laugstol commented on MEJB-13: - I'm -1 to this solution. The ejb.jar's resources should be completly controlled with the normal resources section inside the build as all other JARs. The client jar should have a similar resources section to control what goes in the client jar. Add support for configuring exclusion filter for main ejb jar - Key: MEJB-13 URL: http://jira.codehaus.org/browse/MEJB-13 Project: Maven 2.x Ejb Plugin Type: New Feature Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 Reporter: Fredrik Vraalsen Attachments: MEJB-configure-excludes.patch, maven-ejb-plugin-configure-main-jar-excludes-2.patch, maven-ejb-plugin-configure-main-jar-excludes.patch In my ejb project I have certain files that must only be included in the ejb-client jar and not the main ejb jar (jboss-client.xml, application-client.xml and jndi.properties). When these files are present in the main ejb jar, JBoss refuses to deploy my ejbs. Thus, I need a way to configure the exclusion filter for the main ejb jar. This is currently hardcoded in EjbMojo.java. I am attaching a patch to make this configurable in the same way as clientExcludes. Below is an example of the kind of configuration I am using: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId version2.1-SNAPSHOT/version configuration excludes excludejndi.properties/exclude excludeMETA-INF/*-client.xml/exclude exclude**/interfaces//exclude exclude**/assetrepository/Asset.class/exclude /excludes generateClienttrue/generateClient clientExcludes clientExcludeMETA-INF/ejb-jar.xml/clientExclude clientExcludeMETA-INF/jboss.xml/clientExclude clientExclude**/dao//clientExclude clientExclude**/entity//clientExclude clientExclude**/jaxb//clientExclude clientExclude**/session//clientExclude clientExclude**/xmldb//clientExclude /clientExcludes /configuration /plugin -- 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: (MDEP-7) [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact
[ http://jira.codehaus.org/browse/MDEP-7?page=all ] Trygve Laugstol closed MDEP-7: -- Assign To: Trygve Laugstol (was: Brian Fox) Resolution: Fixed Patch applied. [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact Key: MDEP-7 URL: http://jira.codehaus.org/browse/MDEP-7 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Christian Schulte Assignee: Trygve Laugstol Priority: Trivial Attachments: ActiveProjectArtifact.patch I reproducible got a ClassCastException during copy-dependencies goal. There is a cast to DefaultArtifact which fails if the actual instance is ActiveProjectArtifact which does not extend DefaultArtifact. After patching the plugin and trying the old version again to verify reproducibility the exception magically never appeared again so I cannot reproduce the stacktrace somehow. However, the cast to DefaultArtifact can be changed to Artifact, I think. -- 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: (MDEP-7) [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact
[ http://jira.codehaus.org/browse/MDEP-7?page=all ] Trygve Laugstol updated MDEP-7: --- Fix Version: 2.0 [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact Key: MDEP-7 URL: http://jira.codehaus.org/browse/MDEP-7 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Christian Schulte Assignee: Trygve Laugstol Priority: Trivial Fix For: 2.0 Attachments: ActiveProjectArtifact.patch I reproducible got a ClassCastException during copy-dependencies goal. There is a cast to DefaultArtifact which fails if the actual instance is ActiveProjectArtifact which does not extend DefaultArtifact. After patching the plugin and trying the old version again to verify reproducibility the exception magically never appeared again so I cannot reproduce the stacktrace somehow. However, the cast to DefaultArtifact can be changed to Artifact, I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2418) Norwegian translation for maven-site-plugin
[ http://jira.codehaus.org/browse/MNG-2418?page=all ] Trygve Laugstol closed MNG-2418: Assign To: Trygve Laugstol Resolution: Fixed Added. Takk! Norwegian translation for maven-site-plugin --- Key: MNG-2418 URL: http://jira.codehaus.org/browse/MNG-2418 Project: Maven 2 Type: New Feature Components: Multiple Language Support Environment: All Reporter: Hermod Opstvedt Assignee: Trygve Laugstol Attachments: site-plugin_no.properties Attached properties file with Norwegian translation of the site-plugin.properties 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: (MNG-2419) Norwegian translation for maven-project-info-reports-plugin
[ http://jira.codehaus.org/browse/MNG-2419?page=all ] Trygve Laugstol closed MNG-2419: Assign To: Trygve Laugstol Resolution: Fixed Added. Takk! Norwegian translation for maven-project-info-reports-plugin --- Key: MNG-2419 URL: http://jira.codehaus.org/browse/MNG-2419 Project: Maven 2 Type: New Feature Components: Multiple Language Support Environment: All Reporter: Hermod Opstvedt Assignee: Trygve Laugstol Attachments: project-info-report_no.properties Attached Norwegian translation of project-info-report.properties. -- 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-759) Generate plexus-request.xml with plexus-cdc
[ http://jira.codehaus.org/browse/CONTINUUM-759?page=comments#action_69139 ] Trygve Laugstol commented on CONTINUUM-759: --- What is a plexus-request.xml? Generate plexus-request.xml with plexus-cdc --- Key: CONTINUUM-759 URL: http://jira.codehaus.org/browse/CONTINUUM-759 Project: Continuum Type: Task Components: Web interface Versions: 1.1 Reporter: Emmanuel Venisse Priority: Trivial Fix For: 1.1 -- 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-735) XmlRpc does not expose getBuildOutput
[ http://jira.codehaus.org/browse/CONTINUUM-735?page=all ] Trygve Laugstol closed CONTINUUM-735: - Assign To: Trygve Laugstol Resolution: Fixed XmlRpc does not expose getBuildOutput - Key: CONTINUUM-735 URL: http://jira.codehaus.org/browse/CONTINUUM-735 Project: Continuum Type: Improvement Components: XMLRPC Interface Environment: Debian linux etc Reporter: Andrew Williams Assignee: Trygve Laugstol Fix For: 1.1 Attachments: DefaultContinuumXmlRpc_java.patch, all_changes.patch, continuum_py-tidy.patch, continuum_py-tidy.patch, continuum_py.patch the XmlRpc does not expose the rather useful getBuildOutput method. The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc the module and continuum.py in the continuum-core-it module fixes this. Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2410) adding a method in AbstractMavenReport to obtain newSink()
[ http://jira.codehaus.org/browse/MNG-2410?page=comments#action_68366 ] Trygve Laugstol commented on MNG-2410: -- I'm +1 for applying Kenney's patch, that's the way to go. adding a method in AbstractMavenReport to obtain newSink() -- Key: MNG-2410 URL: http://jira.codehaus.org/browse/MNG-2410 Project: Maven 2 Type: New Feature Components: Sites Reporting Versions: 2.0.4 Environment: all Reporter: Olivier Lamy Actually when extending AbstractMavenReport, I can get a Sink for write only one page. For report, I need to create some pages. I like to have a new method called newSink(FileWriter) to write some other pages. Or could we have a SinkFactory object injected in AbstractMavenReport ? Note, I need a Sink with the current site skin. Thanks, -- Olivier -- 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-1905) Delete remote files before uploading them to avoid permission problems
[ http://jira.codehaus.org/browse/MNG-1905?page=comments#action_66459 ] Trygve Laugstol commented on MNG-1905: -- Wouldn't it be best to write the files to a temporary name and the move them once the upload is complete? This is what we do when downloading files from a remote repository and would make the most sense when uploading too. Delete remote files before uploading them to avoid permission problems -- Key: MNG-1905 URL: http://jira.codehaus.org/browse/MNG-1905 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Carlos Sanchez Fix For: 2.0.5 If metadata files in server are owned by other person and not group writeable wagon doesn't try to delete them first, causing a permission denied error org.apache.maven.lifecycle.LifecycleExecutionException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:414) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:99) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) ... 18 more Caused by: org.apache.maven.artifact.repository.metadata.RepositoryMetadataDeploymentException: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:433) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83) ... 19 more Caused by: org.apache.maven.wagon.TransferFailedException: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.wagon.providers.sshext.ScpExternalWagon.executeScpCommand(ScpExternalWagon.java:294) at
[jira] Commented: (MECLIPSE-112) Extending the Maven Plugin to allow reuse from other plugins
[ http://jira.codehaus.org/browse/MECLIPSE-112?page=comments#action_66461 ] Trygve Laugstol commented on MECLIPSE-112: -- Moving the issue would be better than closing this and opening a new one :) Extending the Maven Plugin to allow reuse from other plugins Key: MECLIPSE-112 URL: http://jira.codehaus.org/browse/MECLIPSE-112 Project: Maven 2.x Eclipse Plugin Type: New Feature Versions: 2.0 Environment: Eclipse 3.x Reporter: Philip Dodds Attachments: newMethod.patch I am currently working to build out some tooling around the ServiceMix/FUSE platform and I have been successful at integrating the Maven2 Eclipse Plugin to allow the re-use of the archetype plugin in Eclipse (ie. a wizard using the archetype under the hood) and also the working with using the JBI plugins to enable integration with publishing to servers. In order to maximise reuse I wanted to leverage the Maven 2 Eclipse Plugin to provide access to the MavenEmbedded infrastructure, however it required some changes to the plugin to provide access from other plugins and to give a clean simple interface. Can you review the attached patch for the Maven 2 plugin that offers the required functionality Thanks -- 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-1905) Delete remote files before uploading them to avoid permission problems
[ http://jira.codehaus.org/browse/MNG-1905?page=comments#action_66464 ] Trygve Laugstol commented on MNG-1905: -- Ok, I understand the case better now, but deleting the files first is not a good solution as you risk messing up the repository. I know that uploading the artifact before doing a server side move gives the risk of first uploading a file and then the build fails might be annoying but I don't see a better way right now. Delete remote files before uploading them to avoid permission problems -- Key: MNG-1905 URL: http://jira.codehaus.org/browse/MNG-1905 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Carlos Sanchez Fix For: 2.0.5 If metadata files in server are owned by other person and not group writeable wagon doesn't try to delete them first, causing a permission denied error org.apache.maven.lifecycle.LifecycleExecutionException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:414) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error installing artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:99) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) ... 18 more Caused by: org.apache.maven.artifact.repository.metadata.RepositoryMetadataDeploymentException: Error while deploying metadata: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:433) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83) ... 19 more Caused by: org.apache.maven.wagon.TransferFailedException: Exit code: 1 - pscp: unable to open /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: permission denied at
[jira] Commented: (MNG-2333) Plugins need to offer up all information without executing
[ http://jira.codehaus.org/browse/MNG-2333?page=comments#action_66275 ] Trygve Laugstol commented on MNG-2333: -- This sounds like a Maven Extension Proposal (MEP) to me! Plugins need to offer up all information without executing -- Key: MNG-2333 URL: http://jira.codehaus.org/browse/MNG-2333 Project: Maven 2 Type: New Feature Components: Embedding Versions: 2.0.5 Reporter: Jason van Zyl Assignee: Jason van Zyl In an IDE environment, you want to know what will be generated by a plugin without having it execute. For example, if you have a plugin that generates a source directory you want to know that without having actually execute the plugin because it can take a long time if you have a lot of plugins. Another issue will probably have to be created to outline changes to the plugin api so that external tools can call this method to get all the information up-front. I couldn't find any related issues. This should also work when reactor projects are run. Another example is any plugin that produces resources that need to be added to the UI. -- 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: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=comments#action_66146 ] Trygve Laugstol commented on MSUREFIRE-121: --- I still don't understand what you're after here, you're saying something about the boot class path and something about the -classpath. How will making a URLClassLoader containing all the JAR files different from adding them to -classpath? The ability to add stuff to the boot strap class path is useful, but you need to explain why you need to add stuff to -classpath. ability to add dependency to jvm's classpath rather in surefirebooter classloader - Key: MSUREFIRE-121 URL: http://jira.codehaus.org/browse/MSUREFIRE-121 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Environment: xp Reporter: Dan Tran Fix For: 2.3 Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch I have a usecase where i have a jar file got loaded by -Xbootclasspath, that jar file then loads classes from another jar ( my dependency) expected in the classpath. The problem is that surefire plugin does not add my dependencies at JVM commanline thru -classpath option, but after the JVM starts -- 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: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=comments#action_66194 ] Trygve Laugstol commented on MSUREFIRE-121: --- I would still like to understand the real use case that you have here. Will classes in the bootstrap classloader really load stuff from the system classpath (i.e. the one given with -classpath)? Instead of adding all of the dependencies to the -classpath it might be better to be able to give a set of artifacts to add. Ideally it should be given a set of artifacts and use Maven's code to resolve the rest of the required artifacts. ability to add dependency to jvm's classpath rather in surefirebooter classloader - Key: MSUREFIRE-121 URL: http://jira.codehaus.org/browse/MSUREFIRE-121 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Environment: xp Reporter: Dan Tran Fix For: 2.3 Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch I have a usecase where i have a jar file got loaded by -Xbootclasspath, that jar file then loads classes from another jar ( my dependency) expected in the classpath. The problem is that surefire plugin does not add my dependencies at JVM commanline thru -classpath option, but after the JVM starts -- 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: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=comments#action_66056 ] Trygve Laugstol commented on MSUREFIRE-121: --- The boot class path is not the same classpath as -classpath, which one are you really after here? I'm pretty sure the boot class path is an optional class path (it might be the same as -classpath). ability to add dependency to jvm's classpath rather in surefirebooter classloader - Key: MSUREFIRE-121 URL: http://jira.codehaus.org/browse/MSUREFIRE-121 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Environment: xp Reporter: Dan Tran Fix For: 2.3 Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch I have a usecase where i have a jar file got loaded by -Xbootclasspath, that jar file then loads classes from another jar ( my dependency) expected in the classpath. The problem is that surefire plugin does not add my dependencies at JVM commanline thru -classpath option, but after the JVM starts -- 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-2312) The mvn script doesn't work on Solaris
The mvn script doesn't work on Solaris -- Key: MNG-2312 URL: http://jira.codehaus.org/browse/MNG-2312 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0.2, 2.0.3, 2.0.4 Reporter: Trygve Laugstol The usage of -e in mvn stops Solaris' sh because it's not implemented. -r does the same trick. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2312) The mvn script doesn't work on Solaris
[ http://jira.codehaus.org/browse/MNG-2312?page=all ] Trygve Laugstol closed MNG-2312: Assign To: Trygve Laugstol Resolution: Fixed Fix Version: 2.1 2.0.5 Fixed in revision 408737 and 408749. The mvn script doesn't work on Solaris -- Key: MNG-2312 URL: http://jira.codehaus.org/browse/MNG-2312 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0.2, 2.0.3, 2.0.4 Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 2.1, 2.0.5 The usage of -e in mvn stops Solaris' sh because it's not implemented. -r does the same trick. -- 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: (MCOMPILER-35) Possibility to skip just the running of tests
[ http://jira.codehaus.org/browse/MCOMPILER-35?page=comments#action_65568 ] Trygve Laugstol commented on MCOMPILER-35: -- I think this is a good default, but another flag to force compilation would be nice. Possibility to skip just the running of tests - Key: MCOMPILER-35 URL: http://jira.codehaus.org/browse/MCOMPILER-35 Project: Maven 2.x Compiler Plugin Type: Improvement Versions: 2.0, 2.0.1 Environment: All Reporter: Bugittaa Pahasti Currently setting -Dmaven.test.skip=true skips also compiling of the tests. It would be really useful to have a property, which would still compile the tests but skip running of them. Currently we need two continuum build definitions to achieve that (install with skip tests and test-compile). It easily causes some confusion for example when both main and test doens't compile, then main is fixed and a build mail is received saying build succeeded, but test aren't still compiling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MCOMPILER-35) Possibility to skip just the running of tests
[ http://jira.codehaus.org/browse/MCOMPILER-35?page=all ] Trygve Laugstol moved MSUREFIRE-116 to MCOMPILER-35: Version: (was: 2.2) 2.0 2.0.1 Key: MCOMPILER-35 (was: MSUREFIRE-116) Project: Maven 2.x Compiler Plugin (was: Maven 2.x Surefire Plugin) Possibility to skip just the running of tests - Key: MCOMPILER-35 URL: http://jira.codehaus.org/browse/MCOMPILER-35 Project: Maven 2.x Compiler Plugin Type: Improvement Versions: 2.0, 2.0.1 Environment: All Reporter: Bugittaa Pahasti Currently setting -Dmaven.test.skip=true skips also compiling of the tests. It would be really useful to have a property, which would still compile the tests but skip running of them. Currently we need two continuum build definitions to achieve that (install with skip tests and test-compile). It easily causes some confusion for example when both main and test doens't compile, then main is fixed and a build mail is received saying build succeeded, but test aren't still compiling. -- 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-70) assembly:directory does not honor fileMode
[ http://jira.codehaus.org/browse/MASSEMBLY-70?page=all ]
Trygve Laugstol closed MASSEMBLY-70:
Resolution: Fixed
Fix Version: 2.1
This was fixed a while back.
assembly:directory does not honor fileMode
Key: MASSEMBLY-70
URL: http://jira.codehaus.org/browse/MASSEMBLY-70
Project: Maven 2.x Assembly Plugin
Type: Bug
Versions: 2.0.1
Environment: Linux 2.6.10-gentoo-r4 #1 SMP Mon Jan 10 14:53:56 EST 2005 i686
AMD Athlon(tm) MP 2400+ AuthenticAMD GNU/Linux
java version 1.4.2_10
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
Reporter: Andrew Moore
Assignee: Trygve Laugstol
Fix For: 2.1
When running {{assembly:assembly}}, the {{fileMode}} specified in the
assembly descriptor [[#1]] is honored in the resulting archive [[#2]].
When running {{assembly:directory}}, the {{fileMode}} is not honored in the
resulting directory structure [[#3]].
{anchor:1}
{code:xml|title=Listing 1: package.xml}
assembly
idpackage/id
formats
formattar.gz/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directorytarget/directory
outputDirectory/lib/outputDirectory
includes
include*.jar/include
/includes
fileMode0640/fileMode
/fileSet
fileSet
directorysrc/main/shell/bin/directory
outputDirectory/bin/outputDirectory
includes
include**/*/include
/includes
fileMode0750/fileMode
/fileSet
fileSet
directorysrc/main/shell/environments/directory
outputDirectory/environments/outputDirectory
includes
include**/*/include
/includes
fileMode0640/fileMode
/fileSet
fileSet
directorysrc/main/shell/etc/directory
outputDirectory/etc/outputDirectory
includes
include**/*/include
/includes
fileMode0640/fileMode
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/lib/outputDirectory
scoperuntime/scope
fileMode0640/fileMode
/dependencySet
/dependencySets
/assembly
{code}
{anchor:2}
{code:title=Listing 2: target/nabpoc-b1_0_0001-package.tar.gz}
$ tar -tvzf target/nabpoc-b1_0_0001-package.tar.gz
drwxr-xr-x / 0 2006-02-16 10:23:40 environments/databases/
-rw-r- /257398 2006-02-16 10:56:41 lib/nabpoc-b1_0_0001.jar
...
-rwxr-x--- / 1152 2006-02-16 10:23:40 bin/sting
-rwxr-x--- / 392 2006-02-16 10:23:40 bin/distra
-rwxr-x--- / 578 2006-02-16 10:23:40 bin/get_classpath
-rwxr-x--- / 1545 2006-02-16 10:23:40 bin/set_rate
-rwxr-x--- / 1817 2006-02-16 10:23:40 bin/sting.bat
-rw-r- / 1570 2006-02-16 10:23:40
environments/databases/lab-installation.xml
-rw-r- / 729 2006-02-16 10:23:40 environments/nabpoc.xml
-rw-r- / 990 2006-02-16 10:23:40 environments/systest.xml
-rw-r- / 3084 2006-02-16 10:23:41 etc/switch.conf
-rw-r- / 2820 2006-02-16 10:23:41 etc/sim.conf
-rw-r- / 1523 2006-02-16 10:23:41 etc/distra.conf
-rw-r- / 1322 2006-02-16 10:23:41 etc/harouter.conf
{code}
{anchor:3}
{code:title=Listing 3: target/nabpoc-b1_0_0001-package/}
files under bin/ should be rwxr-x--- as in tar.gz, above
$ find target/nabpoc-b1_0_0001-package -ls
25964120 drwxr-sr-x 6 amm coders152 Feb 16 11:02
target/nabpoc-b1_0_0001-package
25964620 drwxr-sr-x 2 amm coders184 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin
25964634 -rw-r--r-- 1 amm coders 1152 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin/sting
25964644 -rw-r--r-- 1 amm coders392 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin/distra
25964654 -rw-r--r-- 1 amm coders578 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin/get_classpath
25964664 -rw-r--r-- 1 amm coders 1545 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin/set_rate
25964674 -rw-r--r-- 1 amm coders 1817 Feb 16 11:02
target/nabpoc-b1_0_0001-package/bin/sting.bat
25964720 drwxr-sr-x 2 amm coders168 Feb 16 11:02
target/nabpoc-b1_0_0001-package/etc
25964734 -rw-r--r-- 1 amm coders 3084 Feb 16 11:02
target/nabpoc-b1_0_0001-package/etc/switch.conf
25964744 -rw-r--r-- 1 amm coders 2820 Feb 16 11:02
target/nabpoc-b1_0_0001-package/etc/sim.conf
25964754 -rw-r--r-- 1 amm coders 1523 Feb 16 11:02
target/nabpoc-b1_0_0001-package/etc/distra.conf
25964794 -rw-r--r-- 1 amm coders 1322 Feb 16 11:02
[jira] Commented: (CONTINUUM-651) DefaultContinuumScm.getScmRepository should not set project scm username/password if they are the empty string
[ http://jira.codehaus.org/browse/CONTINUUM-651?page=comments#action_63048
]
Trygve Laugstol commented on CONTINUUM-651:
---
Why?
DefaultContinuumScm.getScmRepository should not set project scm
username/password if they are the empty string
--
Key: CONTINUUM-651
URL: http://jira.codehaus.org/browse/CONTINUUM-651
Project: Continuum
Type: Bug
Components: Core system
Reporter: John Didion
Should be using StringUtils.isEmpty instead of doing a null check.
{noformat}
if ( !StringUtils.isEmpty(project.getScmUsername()) )
{
providerRepository.setUser( project.getScmUsername() );
if ( project.getScmPassword() != null )
{
providerRepository.setPassword( project.getScmPassword() );
}
else
{
providerRepository.setPassword( );
}
}
{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
