[continuum build - FAILED - update] Tue Nov 29 11:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051129.11.txt
interface thought
Hi, Thought I'd throw this out for discussion before considering forming it in JIRA for, say, 1.2. I was thinking about the process of adding a parent pom and having all the modules added, and wondered what should happen when a new module is added, or a module is removed from the parent. Here, I think it would be a good idea to link them on setup, so that the subproject is added/removed when its module goes from the parent. I think this one is fairly straightforward and I'll drop it into JIRA (1.1?) tomorrow. But I also thought about the option of having a always, never, ask choice when adding such a project in regards to whether to add/remove found or lost modules. Here - always behaves like above, never behaves like now, and ask would prompt the user. However, this happens in the background - when an update is found. How could the user be asked? I was thinking that this could be directed to a group or project administrator, and stored in an inbox. The user/group would be notified of the request, and when logging in to Continuum would see they have a pending action. Once dealt with (by accepting/declining the add/remove request), the message is removed for all users. Maybe they are all notified of the action. This seems useful to me, though too much work for just this use case. Are there any other actions that might be similar to this? I think in particular POM updates (like changes in notifiers, developers, SCM location), and admin actions - maybe even a notice that a new version of continuum is available, here's how to autoupdate :D What do others think? Cheers, Brett
[jira] Updated: (CONTINUUM-483) Setting RUN_AS_USER causes startup script to fail.
[ http://jira.codehaus.org/browse/CONTINUUM-483?page=all ] Emmanuel Venisse updated CONTINUUM-483: --- Fix Version: 1.0.2 Setting RUN_AS_USER causes startup script to fail. -- Key: CONTINUUM-483 URL: http://jira.codehaus.org/browse/CONTINUUM-483 Project: Continuum Type: Bug Components: Core system Versions: 1.0.1 Environment: gentoo 2.6.5 kernel, bash 2.05 Reporter: Corridor Software Developer Fix For: 1.0.2 If the run.sh script is modified to include a RUN_AS_USER, this line in the script su -m $RUN_AS_USER -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE fails with the following error: /bin/bash: continuum: No such file or directory reducing the line yields the same error right down to the 'su -m user_name'. However, if the -m is moved to beyond the user, everything works out: su $RUN_AS_USER -m -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE note that it occurs twice in the 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] Commented: (CONTINUUM-483) Setting RUN_AS_USER causes startup script to fail.
[ http://jira.codehaus.org/browse/CONTINUUM-483?page=comments#action_52292 ] Emmanuel Venisse commented on CONTINUUM-483: Is it fix CONTINUUM-410 too? Setting RUN_AS_USER causes startup script to fail. -- Key: CONTINUUM-483 URL: http://jira.codehaus.org/browse/CONTINUUM-483 Project: Continuum Type: Bug Components: Core system Versions: 1.0.1 Environment: gentoo 2.6.5 kernel, bash 2.05 Reporter: Corridor Software Developer Fix For: 1.0.2 If the run.sh script is modified to include a RUN_AS_USER, this line in the script su -m $RUN_AS_USER -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE fails with the following error: /bin/bash: continuum: No such file or directory reducing the line yields the same error right down to the 'su -m user_name'. However, if the -m is moved to beyond the user, everything works out: su $RUN_AS_USER -m -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE note that it occurs twice in the 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] Commented: (CONTINUUM-69) Make sure /webapp only contains web resources and not classes.
[ http://jira.codehaus.org/browse/CONTINUUM-69?page=comments#action_52293 ] Emmanuel Venisse commented on CONTINUUM-69: --- I move it to 1.1, because actually, continuum isn't a war but a jar. This file is exploded in /webapp, so we have all classes in /webapp/org/apache/maven/continuum/web In 1.1, we'll have a war with webwork, so we won't have classes in /webapp Make sure /webapp only contains web resources and not classes. -- Key: CONTINUUM-69 URL: http://jira.codehaus.org/browse/CONTINUUM-69 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 1.1 We'll need to deal with this next version, it's not critical in any way. -- 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-69) Make sure /webapp only contains web resources and not classes.
[ http://jira.codehaus.org/browse/CONTINUUM-69?page=comments#action_52311 ] John Casey commented on CONTINUUM-69: - thanks. I wanted to make sure it was on the radar, and figure out where it belongs. Make sure /webapp only contains web resources and not classes. -- Key: CONTINUUM-69 URL: http://jira.codehaus.org/browse/CONTINUUM-69 Project: Continuum Type: Task Versions: 1.0-alpha-3 Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 1.1 We'll need to deal with this next version, it's not critical in any way. -- 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
[continuum build - SUCCESS - update] Tue Nov 29 19:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051129.19.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051129.19.txt
[continuum build - SUCCESS - checkout] Wed Nov 30 01:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051130.013000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051130.013000.txt
[jira] Created: (SCM-86) Release:prepare not working in ClearCase in multiproject
Release:prepare not working in ClearCase in multiproject Key: SCM-86 URL: http://jira.codehaus.org/browse/SCM-86 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Attachments: modules.zip I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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: (SCM-87) [patch] Release:prepare not working in ClearCase in multiproject
[patch] Release:prepare not working in ClearCase in multiproject Key: SCM-87 URL: http://jira.codehaus.org/browse/SCM-87 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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: (SCM-87) [patch] Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-87?page=comments#action_52280 ] Wim Deblauwe commented on SCM-87: - I created this issue next to SCM-86 to mark the difference between the error message that needs improvement and the patch for making release:prepare work. See attachements of this issue for patches to make release:prepare work with ClearCase. regards, Wim [patch] Release:prepare not working in ClearCase in multiproject Key: SCM-87 URL: http://jira.codehaus.org/browse/SCM-87 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Attachments: maven-scm.patch, release.patch I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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: (SCM-87) [patch] Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-87?page=all ] Wim Deblauwe updated SCM-87: Attachment: release.patch maven-scm.patch [patch] Release:prepare not working in ClearCase in multiproject Key: SCM-87 URL: http://jira.codehaus.org/browse/SCM-87 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Attachments: maven-scm.patch, release.patch I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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
Re: [jira] Commented: (SCM-80) [patch] update for the release and clearcase plugins
See http://jira.codehaus.org/browse/SCM-87 for patches to make it work with multiproject. Enjoy!
regards,
Wim2005/11/29, Wim Deblauwe [EMAIL PROTECTED]:
http://jira.codehaus.org/browse/SCM-862005/11/28, Emmanuel Venisse
[EMAIL PROTECTED]
:you can use the j2ee archetype
EmmanuelWim Deblauwe a écrit :
Thanks, it's ok now. I do not have a project with modules. I would be nice if there was some simple project to test with. Maybe someone should create a archetype of a project with modules so we have something to test with?
regards, Wim 2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: You have a conflict on this file. Delete it and run after svn update Emmanuel Wim Deblauwe a écrit : I'm having problems updating the maven-release-plugin to the latest
version. I ran 'update' but the PrepareReleaseMojo.java file remains with a red exclamation mark. I don't know how to solve it. When I look at the file, there are sections who looks like this:
private void writePom( File pomFile, Model model, String versionName ) throws MojoExecutionException { .mine
ScmHelper scm = getScm( basedir.getAbsolutePath() ); === pomFiles.add( pomFile );
ScmHelper scm = getScm( basedir.getAbsolutePath() ); .r348924 regards, Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
:
if you can test with a simple project and with a project with modules, it will be great. Emmanuel Wim Deblauwe a écrit :
Sure, do you have an example project with modules that I can test? Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: Wim,
Can you test it with clearcase? Emmanuel
Wim Deblauwe (JIRA) a écrit :
[ http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
]
Wim Deblauwe commented on SCM-80:
-
Thanks amillion Emmanuel![patch]
update for the release and clearcase plugins
Key: SCM-80
URL: http://jira.codehaus.org/browse/SCM-80
http://jira.codehaus.org/browse/SCM-80
Project: Maven SCMType:
TaskReporter:
Wim DeblauweAssignee:
Emmanuel Venisse
Fix For: 1.0-beta-2
Attachments: clearcase-release.patch , release.patchThese
are 2 patches. One for the release plugin and one for the
clearcase plugin to make the release:prepare goal work on clearcase.
This has been tested on my machine and it works, so anybody else
willing to test this is very welcome.regards,Wim
Re: [jira] Commented: (SCM-80) [patch] update for the release and clearcase plugins
Come to think of it, it does not exactly what I hoped it would do.
Currently all modules get labeled (tagged) with the same label. Each
module should be labeled with it's own label. Also, the pom.xml files
are not updated to the next snapshot version. These things are probably
the same for other providers?
regards,
Wim2005/11/29, Wim Deblauwe [EMAIL PROTECTED]:
See http://jira.codehaus.org/browse/SCM-87 for patches to make it work with multiproject. Enjoy!
regards,
Wim2005/11/29, Wim Deblauwe [EMAIL PROTECTED]
:
http://jira.codehaus.org/browse/SCM-862005/11/28, Emmanuel Venisse
[EMAIL PROTECTED]
:you can use the j2ee archetype
EmmanuelWim Deblauwe a écrit :
Thanks, it's ok now. I do not have a project with modules. I would be nice if there was some simple project to test with. Maybe someone should create a archetype of a project with modules so we have something to test with?
regards, Wim 2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: You have a conflict on this file. Delete it and run after svn update Emmanuel Wim Deblauwe a écrit : I'm having problems updating the maven-release-plugin to the latest
version. I ran 'update' but the PrepareReleaseMojo.java file remains with a red exclamation mark. I don't know how to solve it. When I look at the file, there are sections who looks like this:
private void writePom( File pomFile, Model model, String versionName ) throws MojoExecutionException { .mine
ScmHelper scm = getScm( basedir.getAbsolutePath() ); === pomFiles.add( pomFile );
ScmHelper scm = getScm( basedir.getAbsolutePath() ); .r348924 regards, Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
:
if you can test with a simple project and with a project with modules, it will be great. Emmanuel Wim Deblauwe a écrit :
Sure, do you have an example project with modules that I can test? Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: Wim,
Can you test it with clearcase? Emmanuel
Wim Deblauwe (JIRA) a écrit :
[ http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
]
Wim Deblauwe commented on SCM-80:
-
Thanks amillion Emmanuel![patch]
update for the release and clearcase plugins
Key: SCM-80
URL: http://jira.codehaus.org/browse/SCM-80
http://jira.codehaus.org/browse/SCM-80
Project: Maven SCMType:
TaskReporter:
Wim DeblauweAssignee:
Emmanuel Venisse
Fix For: 1.0-beta-2
Attachments: clearcase-release.patch , release.patchThese
are 2 patches. One for the release plugin and one for the
clearcase plugin to make the release:prepare goal work on clearcase.
This has been tested on my machine and it works, so anybody else
willing to test this is very welcome.regards,Wim
Re: [jira] Commented: (SCM-80) [patch] update for the release and clearcase plugins
if you want to tag only one project, you must release only it. if you release an entire project, you
have one tag for all. A tag is a photo of sources at an instant.
It's the same for all providers.
Emmanuel
Wim Deblauwe a écrit :
Come to think of it, it does not exactly what I hoped it would do.
Currently all modules get labeled (tagged) with the same label. Each
module should be labeled with it's own label. Also, the pom.xml files
are not updated to the next snapshot version. These things are probably
the same for other providers?
regards,
Wim
2005/11/29, Wim Deblauwe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
See http://jira.codehaus.org/browse/SCM-87 for patches to make it
work with multiproject. Enjoy!
regards,
Wim
2005/11/29, Wim Deblauwe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
http://jira.codehaus.org/browse/SCM-86
2005/11/28, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] :
you can use the j2ee archetype
Emmanuel
Wim Deblauwe a écrit :
Thanks, it's ok now.
I do not have a project with modules. I would be nice if
there was some
simple project to test with. Maybe someone should create a
archetype of
a project with modules so we have something to test with?
regards,
Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
You have a conflict on this file. Delete it and run
after svn update
Emmanuel
Wim Deblauwe a écrit :
I'm having problems updating the
maven-release-plugin to the latest
version. I ran 'update' but the
PrepareReleaseMojo.java file remains
with a red exclamation mark. I don't know how to
solve it. When I
look
at the file, there are sections who looks like this:
private void writePom( File pomFile, Model
model, String
versionName )
throws MojoExecutionException
{
.mine
ScmHelper scm = getScm(
basedir.getAbsolutePath() );
===
pomFiles.add( pomFile );
ScmHelper scm = getScm(
basedir.getAbsolutePath() );
.r348924
regards,
Wim
2005/11/25, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
if you can test with a simple project and with a
project with
modules, it will be great.
Emmanuel
Wim Deblauwe a écrit :
Sure, do you have an example project with
modules that I
can test?
Wim
2005/11/25, Emmanuel Venisse
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Wim,
Can you test it with clearcase?
Emmanuel
Wim Deblauwe (JIRA) a écrit :
[
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
http://jira.codehaus.org/browse/SCM-80?page=comments#action_51978
]
Wim Deblauwe commented on SCM-80:
-
Thanks a million Emmanuel!
[patch] update for the release and
clearcase plugins
Key: SCM-80
URL:
http://jira.codehaus.org/browse/SCM-80
[jira] Closed: (SCM-79) Add remaining operations to Perforce provider
[ http://jira.codehaus.org/browse/SCM-79?page=all ] Emmanuel Venisse closed SCM-79: --- Assign To: Emmanuel Venisse Resolution: Fixed All patches are applied Add remaining operations to Perforce provider - Key: SCM-79 URL: http://jira.codehaus.org/browse/SCM-79 Project: Maven SCM Type: Improvement Components: maven-scm-provider-perforce Versions: 1.0-beta-2 Reporter: mike perham Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: checkout_list.txt, perforce.zip, release_prepare.txt I am in the process of implementing the rest of the Perforce operations. I completed add, remove and checkin last night and should have the rest of the operations done in the next day. -- 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: (SCM-86) Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-86?page=all ] Emmanuel Venisse closed SCM-86: --- Assign To: Emmanuel Venisse Resolution: Fixed I fixed message Release:prepare not working in ClearCase in multiproject Key: SCM-86 URL: http://jira.codehaus.org/browse/SCM-86 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: modules.zip I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-87) [patch] Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-87?page=all ] Emmanuel Venisse reopened SCM-87: - [patch] Release:prepare not working in ClearCase in multiproject Key: SCM-87 URL: http://jira.codehaus.org/browse/SCM-87 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: maven-scm.patch, release.patch I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-86) Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-86?page=all ] Emmanuel Venisse reopened SCM-86: - Release:prepare not working in ClearCase in multiproject Key: SCM-86 URL: http://jira.codehaus.org/browse/SCM-86 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: modules.zip I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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: (SCM-87) [patch] Release:prepare not working in ClearCase in multiproject
[ http://jira.codehaus.org/browse/SCM-87?page=all ] Emmanuel Venisse closed SCM-87: --- Resolution: Fixed Fix Version: 1.0-beta-2 [patch] Release:prepare not working in ClearCase in multiproject Key: SCM-87 URL: http://jira.codehaus.org/browse/SCM-87 Project: Maven SCM Type: Bug Reporter: Wim Deblauwe Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: maven-scm.patch, release.patch I create a multiproject to test ClearCase and release:prepare, but I get the following error: [INFO] [release:prepare] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Missing release preparation information. [INFO] I have attached the project for testing. regards, Wim -- 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: (SCM-88) Add transparent support for locking providers
Add transparent support for locking providers - Key: SCM-88 URL: http://jira.codehaus.org/browse/SCM-88 Project: Maven SCM Type: Improvement Components: maven-scm-api Versions: 1.0-beta-2 Reporter: mike perham Fix For: 1.0-beta-2 Currently the release plugin requires a command line parameter useEditMode to work with the Clearcase and Perforce providers. Please integrate the notion of locking vs non-locking providers into the SCM API so this does not need to be passed on the command line. -- 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
RE: Exercising more commands?
Any samples or docs on how to use the plugin? -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 11:35 AM To: scm-dev@maven.apache.org Subject: Re: Exercising more commands? maven-scm-plugin in maven-scm tree Emmanuel Mike Perham a écrit : How do I exercise the commands which are not used by the release plugin? I'm thinking mostly of the diff and changelog commands - are there any m2 plugins that use these commands? mike
[jira] Commented: (SCM-88) Add transparent support for locking providers
[ http://jira.codehaus.org/browse/SCM-88?page=comments#action_52387 ] Wim Deblauwe commented on SCM-88: - I voted for this, because you don't release every day, and I found out how easy I forgot to pass that option, so this improvement would be very welcome. Add transparent support for locking providers - Key: SCM-88 URL: http://jira.codehaus.org/browse/SCM-88 Project: Maven SCM Type: Improvement Components: maven-scm-api Versions: 1.0-beta-2 Reporter: mike perham Fix For: 1.0-beta-2 Currently the release plugin requires a command line parameter useEditMode to work with the Clearcase and Perforce providers. Please integrate the notion of locking vs non-locking providers into the SCM API so this does not need to be passed on the command line. -- 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
Re: [vote] surefire/maven-surefire-plugin release
Does this mean that I'll finally be able to specify enable-assertions for my unit tests without having to remind every developer who downloads my code to set MAVEN_OPTS=-ea I hope so. Kind regards, Dave Sag Jason van Zyl [EMAIL PROTECTED] wrote on 28-11-2005 03:02:25: Hi, Surefire will now fork tests and I've updated the surefire plugin accordingly so I think it's time for a release. +1 -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r349651 - /maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
Hi John,
this is not needed, the issue has already been fixed some time ago.
Take a look at the comments in
http://jira.codehaus.org/browse/MNG-1216 for the solution, the fix has
been committed in rev 326881
http://svn.apache.org/viewcvs.cgi?rev=326881view=rev
fabrizio
On 11/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Mon Nov 28 21:13:22 2005
New Revision: 349651
URL: http://svn.apache.org/viewcvs?rev=349651view=rev
Log:
PR: MNG-1579
Submitted By: John Casey
Added try/catch to a new wrapper method for getBundle(..) that will report
failure to retrieve the ResourceBundle for a given locale, and default over
to usage of Locale.ENGLISH where necessary. Changed all references to
getBundle(..) to this new method.
Modified:
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
Modified:
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
URL:
http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java?rev=349651r1=349650r2=349651view=diff
==
---
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
(original)
+++
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
Mon Nov 28 21:13:22 2005
@@ -28,6 +28,7 @@
import com.puppycrawl.tools.checkstyle.api.Configuration;
import com.puppycrawl.tools.checkstyle.api.FilterSet;
import com.puppycrawl.tools.checkstyle.filters.SuppressionsLoader;
+
import org.apache.maven.project.MavenProject;
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
@@ -46,6 +47,7 @@
import java.util.List;
import java.util.Locale;
import java.util.Map;
+import java.util.MissingResourceException;
import java.util.Properties;
import java.util.ResourceBundle;
@@ -198,7 +200,7 @@
*/
public String getName( Locale locale )
{
-return getBundle( locale ).getString( report.checkstyle.name );
+return getBundleWithDefaultLocale( locale ).getString(
report.checkstyle.name );
}
/**
@@ -206,7 +208,7 @@
*/
public String getDescription( Locale locale )
{
-return getBundle( locale ).getString(
report.checkstyle.description );
+return getBundleWithDefaultLocale( locale ).getString(
report.checkstyle.description );
}
/**
@@ -247,9 +249,29 @@
Map files = executeCheckstyle();
-CheckstyleReportGenerator generator = new CheckstyleReportGenerator(
getSink(), getBundle( locale ) );
+CheckstyleReportGenerator generator = new CheckstyleReportGenerator(
getSink(), getBundleWithDefaultLocale( locale ) );
generator.generateReport( files );
+}
+
+private ResourceBundle getBundleWithDefaultLocale( Locale locale )
+{
+ResourceBundle bundle;
+try
+{
+bundle = getBundle( locale );
+}
+catch ( MissingResourceException e )
+{
+Locale defaultLocale = Locale.ENGLISH;
+
+getLog().warn( Cannot find checkstyle message bundle for
locale: + locale.getDisplayName() + . Using default: +
defaultLocale.getDisplayName() + instead. );
+getLog().debug( Error locating message bundle., e );
+
+bundle = getBundle( defaultLocale );
+}
+
+return bundle;
}
private Map executeCheckstyle()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MRM-31) Create Reporting Standard APIs
Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Maria Odea Ching updated MRM-31: Attachment: MRM-31-repository-manager Attached a patch for the reporting api interfaces. Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Maria Odea Ching updated MRM-31: Attachment: MRM-31-repository-manager.patch Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Maria Odea Ching updated MRM-31: Attachment: (was: MRM-31-repository-manager) Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Edwin Punzalan updated MRM-31: -- Attachment: (was: MRM-31-repository-manager.patch) Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager-reports-standard.patch, MRM-31-repository-manager.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1703) pluginManagementexecutions is not propagated to child POMs
pluginManagementexecutions is not propagated to child POMs -- Key: MNG-1703 URL: http://jira.codehaus.org/browse/MNG-1703 Project: Maven 2 Type: Bug Components: POM Versions: 2.0 Reporter: Yann Le Du executions section in pluginManagement isn't propagated to child POMs (as configuration is). The workaround is to use plugins with inheritedtrue/inherited Is this on 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Maria Odea Ching updated MRM-31: Attachment: MRM-31-repository-manager-reports-standard.patch MRM-31-repository-manager.patch Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager-reports-standard.patch, MRM-31-repository-manager.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MRM-31) Create Reporting Standard APIs
[ http://jira.codehaus.org/browse/MRM-31?page=all ] Edwin Punzalan resolved MRM-31: --- Assign To: Maria Odea Ching Resolution: Fixed Applied. Thanks! Create Reporting Standard APIs -- Key: MRM-31 URL: http://jira.codehaus.org/browse/MRM-31 Project: Maven Repository Manager Type: Task Components: reporting Reporter: Edwin Punzalan Assignee: Maria Odea Ching Fix For: 1.0-alpha-1 Attachments: MRM-31-repository-manager-reports-standard.patch, MRM-31-repository-manager.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-85) Allow svn username/password to be set in servers section of settings.xml
[ http://jira.codehaus.org/browse/SCM-85?page=comments#action_52286 ] Emmanuel Venisse commented on SCM-85: - Your patch break all tests in svn provider, so i can't apply it. You must fix your modifications in SvnScmProviderRepository Allow svn username/password to be set in servers section of settings.xml Key: SCM-85 URL: http://jira.codehaus.org/browse/SCM-85 Project: Maven SCM Type: Improvement Components: maven-scm-provider-svn Reporter: Micah Schehl Attachments: MNG-85-maven-scm.patch Allow developers to have their own subversion username/password set in settings.xml.Also, this would prevent having to use the web setup to enter username/password in Continuum since the info would be in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[maven2 build - SUCCESS - update] Tue Nov 29 10:45:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051129.104500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051129.104500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Nov 29 11:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051129.113000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051129.113000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
repository manager
Hi, There has been some work started on the repository manager. Basically, this is an application that will sit on top of the repository to watch over it, help deal with the partner syncs, and provide basic search. I've started to move some of the code from repoclean over there and added a bunch of tests (and squashed a bug or three on the way :) There's still some more to go in that regard. The code that is there is for walking the repository and discovering artifacts: still to do is matching pom artifacts, pairing poms up with appropriate artifacts, and matching attached artifacts with their pom. After that, locating metadata files in the repository. Edwin has checked in some initial interfaces for the reporting modules. These would be called out to as new artifacts are discovered in a repository, and will report on any inconsistencies, bad metadata, etc. Please send in some feedback! The projects that are there are in continuum. I'll be putting together more coherent thoughts on the wiki tomorrow and filling out JIRA with some more ideas. I know we already have one volunteer to integrate maven-proxy-like functionality - is anyone else interested in working on any pieces of functionality? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1704) License report ignores proxy settings
License report ignores proxy settings - Key: MNG-1704 URL: http://jira.codehaus.org/browse/MNG-1704 Project: Maven 2 Type: Bug Components: maven-project-info-reports-plugin Versions: 2.0 Reporter: Jochen Wiedmann Priority: Minor In LicenseReport.java, the following line is used to read a license from an remote URL: in = licenseUrl.openStream(); The proxy settings from settings.xml are ignored completely. Consequently, the site target fails, if the user is sitting behind a firewall and must use a proxy server. Workaround: Start maven like this mvn -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=3128 I am ready to supply a patch, if anyone can tell me how to obtain the Settings object within a Mojo. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/29-Nov-2005_08.30.51/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-483) Setting RUN_AS_USER causes startup script to fail.
[ http://jira.codehaus.org/browse/CONTINUUM-483?page=comments#action_52295 ] Jason Lowmiller commented on CONTINUUM-483: --- Emmanuel .. I believe it would yes! Let me know if it does, just for curiosity sake. Setting RUN_AS_USER causes startup script to fail. -- Key: CONTINUUM-483 URL: http://jira.codehaus.org/browse/CONTINUUM-483 Project: Continuum Type: Bug Components: Core system Versions: 1.0.1 Environment: gentoo 2.6.5 kernel, bash 2.05 Reporter: Corridor Software Developer Fix For: 1.0.2 If the run.sh script is modified to include a RUN_AS_USER, this line in the script su -m $RUN_AS_USER -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE fails with the following error: /bin/bash: continuum: No such file or directory reducing the line yields the same error right down to the 'su -m user_name'. However, if the -m is moved to beyond the user, everything works out: su $RUN_AS_USER -m -c exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE note that it occurs twice in the 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] Commented: (MNG-1704) License report ignores proxy settings
[ http://jira.codehaus.org/browse/MNG-1704?page=comments#action_52297 ]
Vincent Siveton commented on MNG-1704:
--
Thanks for your support, Jochen.
In the LicenseReport class, just add a new parameter, eg:
/**
* @parameter default-value=${settings.proxies}
* @required
* @readonly
*/
private List proxies;
And, you need to add maven-settings dependency, eg:
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-settings/artifactId
version2.0/version
/dependency
HTH
License report ignores proxy settings
-
Key: MNG-1704
URL: http://jira.codehaus.org/browse/MNG-1704
Project: Maven 2
Type: Bug
Components: maven-project-info-reports-plugin
Versions: 2.0
Reporter: Jochen Wiedmann
Priority: Minor
In LicenseReport.java, the following line is used to read a license from an
remote URL:
in = licenseUrl.openStream();
The proxy settings from settings.xml are ignored completely. Consequently,
the site target fails, if the user is sitting behind a firewall and must
use a proxy server.
Workaround: Start maven like this
mvn -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=3128
I am ready to supply a patch, if anyone can tell me how to obtain the
Settings object within a Mojo.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: interface thought
Brett Porter a écrit : Hi, Thought I'd throw this out for discussion before considering forming it in JIRA for, say, 1.2. I was thinking about the process of adding a parent pom and having all the modules added, and wondered what should happen when a new module is added, or a module is removed from the parent. I was thinking to this yesterday, and i think we need to work on it in 1.1 Here, I think it would be a good idea to link them on setup, so that the subproject is added/removed when its module goes from the parent. I think this one is fairly straightforward and I'll drop it into JIRA (1.1?) tomorrow. thanks. Yes, 1.1, but we can do an auto-add/remove of modules for 1.0.2 But I also thought about the option of having a always, never, ask choice when adding such a project in regards to whether to add/remove found or lost modules. I'm not sure this feature will be use by users. Perhaps only for remove. If a user add a new module in a project, i'm pretty sure he want to add it in ci Here - always behaves like above, never behaves like now, and ask would prompt the user. However, this happens in the background - when an update is found. How could the user be asked? I was thinking that this could be directed to a group or project administrator, and stored in an inbox. The user/group would be notified of the request, and when logging in to Continuum would see they have a pending action. Once dealt with (by accepting/declining the add/remove request), the message is removed for all users. Maybe they are all notified of the action. ok This seems useful to me, though too much work for just this use case. Are there any other actions that might be similar to this? I think in particular POM updates (like changes in notifiers, developers, SCM location), and admin actions - maybe even a notice that a new version of continuum is available, here's how to autoupdate :D hmm, not sure, i personnaly consider the pom as the reference. Autoupdate will be a good feature, but very hard to do. Emmanuel What do others think? Cheers, Brett
[jira] Created: (CONTINUUM-487) Allow for specifying the location of the Ant build file
Allow for specifying the location of the Ant build file --- Key: CONTINUUM-487 URL: http://jira.codehaus.org/browse/CONTINUUM-487 Project: Continuum Type: Improvement Versions: 1.0.1 Reporter: Tomislav Stojcevich Priority: Minor There is currently no way to specify the location of the Ant build file if it does not reside in the project root directory. In some of my projects, the build.xml file is in a subdirectory of the project root directory. -- 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-487) Allow for specifying the location of the Ant build file
[ http://jira.codehaus.org/browse/CONTINUUM-487?page=all ] Emmanuel Venisse updated CONTINUUM-487: --- Fix Version: 1.0.2 Allow for specifying the location of the Ant build file --- Key: CONTINUUM-487 URL: http://jira.codehaus.org/browse/CONTINUUM-487 Project: Continuum Type: Improvement Versions: 1.0.1 Reporter: Tomislav Stojcevich Priority: Minor Fix For: 1.0.2 There is currently no way to specify the location of the Ant build file if it does not reside in the project root directory. In some of my projects, the build.xml file is in a subdirectory of the project root directory. -- 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-1596) Add security role definitions to maven-ear-plugin
[ http://jira.codehaus.org/browse/MNG-1596?page=comments#action_52302 ]
Martijn de Bruijn commented on MNG-1596:
The id attribute of the security-role element is used by WSAD to link the roles
to an IBM specific deployment descriptor. Therefore we need to be able to set
the id with Maven.
In general: I think all data (elements and attributes) defined in the
application_1_3.dtd (and other versions) should be configurable from within
Maven.
Add security role definitions to maven-ear-plugin
-
Key: MNG-1596
URL: http://jira.codehaus.org/browse/MNG-1596
Project: Maven 2
Type: New Feature
Components: maven-ear-plugin
Versions: 2.0
Reporter: Martijn de Bruijn
Assignee: Stephane Nicoll
Priority: Minor
The maven-ear-plugin is not capable of defining security-roles. This should
be added.
An example of the pom.xml:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
resourcesDir${basedir}/META-INF/resourcesDir
security
security-role id=SecurityRole_1131964323008
description/description
role-namemanager/role-name
/security-role
security-role id=SecurityRole_1131964323018
description/description
role-nameteller/role-name
/security-role
/security
/configuration
/plugin
It should be possible to add the id field to the security-role element to be
able to link the roles to other generated artifacts.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Brett, the continuum seems to be dead... at least i have some proxy errors instead of it tx ~t~ Brett Porter wrote: Hi, There has been some work started on the repository manager. Basically, this is an application that will sit on top of the repository to watch over it, help deal with the partner syncs, and provide basic search. I've started to move some of the code from repoclean over there and added a bunch of tests (and squashed a bug or three on the way :) There's still some more to go in that regard. The code that is there is for walking the repository and discovering artifacts: still to do is matching pom artifacts, pairing poms up with appropriate artifacts, and matching attached artifacts with their pom. After that, locating metadata files in the repository. Edwin has checked in some initial interfaces for the reporting modules. These would be called out to as new artifacts are discovered in a repository, and will report on any inconsistencies, bad metadata, etc. Please send in some feedback! The projects that are there are in continuum. I'll be putting together more coherent thoughts on the wiki tomorrow and filling out JIRA with some more ideas. I know we already have one volunteer to integrate maven-proxy-like functionality - is anyone else interested in working on any pieces of functionality? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1705) Release plugin loses namespace information from pom.xml
Release plugin loses namespace information from pom.xml --- Key: MNG-1705 URL: http://jira.codehaus.org/browse/MNG-1705 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Wim Deblauwe When a pom.xml defines the correct namespace, like this: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; then this information gets lost when doing a release:prepare. This should remain because xml editors (like XMLSpy) use this info for code completion and validation of the xml. regards, Wim -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-checkstyle-plugin 2.0-beta-2
Right, deleted that card from my address book. :) Brett Porter wrote: (m2-dev list doesn't exist any more :) +1 for a beta including these. When we get to releasing a final, let's have it finished and offered for testing first, before voting on the release though. - Brett John Casey wrote: Hi everyone, I wanted to call a vote on releasing the next version of the checkstyle plugin. I'm currently working on some major bugfixes, including custom rulesets and configurations, more robust error handling for missing locale resource bundles, and a couple other things (trying to trim the list on jira down as much as possible). However, I believe that even with only those two issues that I specifically mentioned above, it would be worth a new release. These issues are not completely resolved, but should be by the time the vote closes. What do you think? I'll give it the traditional 72 hours, and we'll see where we are then. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (SCM-78) scm:checkout should default checkout dir to %{project.build.directory}
[ http://jira.codehaus.org/browse/SCM-78?page=all ]
Emmanuel Venisse closed SCM-78:
---
Assign To: Emmanuel Venisse
Resolution: Fixed
Applied.
scm:checkout should default checkout dir to %{project.build.directory}
--
Key: SCM-78
URL: http://jira.codehaus.org/browse/SCM-78
Project: Maven SCM
Type: Bug
Components: maven-plugin
Versions: 1.0-beta-1
Environment: xp
Reporter: Dan Tran
Assignee: Emmanuel Venisse
Fix For: 1.0-beta-2
Attachments: SCM-78-2.patch, SCM-78.patch
Make m2's maven-scm-plugin's scm:checkout have the same behavior as m1
- remove check out dir before perform checkout
- default checkout dir to ${project.build.directory}
--
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-598) Geronimo dependency on IZPack compiler
[ http://jira.codehaus.org/browse/MAVENUPLOAD-598?page=comments#action_52316 ] Erik Daughtrey commented on MAVENUPLOAD-598: Thanks for doing this. Geronimo dependency on IZPack compiler -- Key: MAVENUPLOAD-598 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-598 Project: maven-upload-requests Type: Task Reporter: Erik Daughtrey Assignee: Carlos Sanchez Attachments: izpack.jar, izpack.jar Something tells me that the bundle url will not work as expected. I'm pointing to the IZPack install jar in the bundle URL, but what's needed is in this attachment. This upload is for the IZPack compiler. Geronimo build is dependent on the IZPack compiler to build the installer. Juliene Ponge, the IZPack development leader, has OK'd this upload. Juliene is at [EMAIL PROTECTED] if there's a need to contact him. He's listed on their main page: http://izforge.com/izpack -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (SCM-81) Unable to checkout starteam project to another path rather than current directory
[ http://jira.codehaus.org/browse/SCM-81?page=all ] Emmanuel Venisse closed SCM-81: --- Assign To: Emmanuel Venisse Resolution: Fixed Applied Unable to checkout starteam project to another path rather than current directory -- Key: SCM-81 URL: http://jira.codehaus.org/browse/SCM-81 Project: Maven SCM Type: Bug Components: maven-scm-provider-starteam Versions: 1.0-beta-1 Environment: xp Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: SCM-81-82.patch Currently starteam provider only allows checking out to current directoy -- 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: (SCM-82) Support startDate, endDate in Starteam's changelog
[ http://jira.codehaus.org/browse/SCM-82?page=all ] Emmanuel Venisse closed SCM-82: --- Assign To: Emmanuel Venisse Resolution: Fixed Applied Support startDate, endDate in Starteam's changelog -- Key: SCM-82 URL: http://jira.codehaus.org/browse/SCM-82 Project: Maven SCM Type: Bug Versions: 1.0-beta-1 Environment: xp Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 The current implementation throws exception when arguments contains start and end dates. This issue prevents continuum to build when there are changes -- 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-1706) site doesn't display the Last Published: in the top left
site doesn't display the Last Published: in the top left Key: MNG-1706 URL: http://jira.codehaus.org/browse/MNG-1706 Project: Maven 2 Type: Bug Components: maven-site-plugin Environment: all Reporter: Olivier Lamy I don't if it's a bug but the Last Published: is not in the top left ? Maybe there is a configuration way to do it but I didn't find it. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-6) Search in repository fails for log4j
Search in repository fails for log4j Key: MNGECLIPSE-6 URL: http://jira.codehaus.org/browse/MNGECLIPSE-6 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Windows XP, Eclipse 3.1, MyEclipse Reporter: Lee Meador Assigned to: Eugene Kuleshov Priority: Minor The repository search doesn't seem to see all the things in my repository. It couldn't find anything when I typed 'log4j' or 'log4' but found things for 'log' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-7) Search repository: Versions in local repo not seen
Search repository: Versions in local repo not seen -- Key: MNGECLIPSE-7 URL: http://jira.codehaus.org/browse/MNGECLIPSE-7 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Window XP, Eclipse 3.1, MyEclipse, local repo, no mirror, central=IBiblio Reporter: Lee Meador Assigned to: Eugene Kuleshov Priority: Minor I searched for 'mail' and it seemed to find version 1.3.2. The only version in my repository is 1.3.3_01 which it didn't show. Not noticing the difference I picked the 1.3.2 version and, though it was added to the POM, the red X at the top of the POM showed an error saying it couldn't find the jar. I edited the POM by hand and put in the 1.3.3_01 version and all was well. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-7) Search repository: Versions in local repo not seen
[ http://jira.codehaus.org/browse/MNGECLIPSE-7?page=comments#action_52322 ] Lee Meador commented on MNGECLIPSE-7: - Similar issue (most likely) : I have jaf-1.0.2 in my repository in the folder jaf/jaf/1.0.2/jaf-1.0.2.jar and an empty .pom. IBiblio has the POM only in jaf/activation/1.0.2/jaf-1.0.2.pom. Only the version in IBiblio showed up and when I picked it it put the dependency in the POM as jaf:activation:1.0.2 which couldn't find anything, again, in my repository. Search repository: Versions in local repo not seen -- Key: MNGECLIPSE-7 URL: http://jira.codehaus.org/browse/MNGECLIPSE-7 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Window XP, Eclipse 3.1, MyEclipse, local repo, no mirror, central=IBiblio Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor I searched for 'mail' and it seemed to find version 1.3.2. The only version in my repository is 1.3.3_01 which it didn't show. Not noticing the difference I picked the 1.3.2 version and, though it was added to the POM, the red X at the top of the POM showed an error saying it couldn't find the jar. I edited the POM by hand and put in the 1.3.3_01 version and all was well. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-checkstyle-plugin 2.0-beta-2
John Casey wrote: Hi everyone, I wanted to call a vote on releasing the next version of the checkstyle plugin. I'm currently working on some major bugfixes, including custom rulesets and configurations, more robust error handling for missing locale resource bundles, and a couple other things (trying to trim the list on jira down as much as possible). However, I believe that even with only those two issues that I specifically mentioned above, it would be worth a new release. These issues are not completely resolved, but should be by the time the vote closes. What do you think? I'll give it the traditional 72 hours, and we'll see where we are then. +1 Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/29-Nov-2005_12.31.20/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-8) Jar from remote repo not loaded and causes error in POM
Jar from remote repo not loaded and causes error in POM --- Key: MNGECLIPSE-8 URL: http://jira.codehaus.org/browse/MNGECLIPSE-8 Project: Maven 2.x Plug-in for Eclipse Type: Improvement Environment: Windows XP, Eclipse 3.1, MyEclipse, local repo, no mirrors, central repo is IBiblio, maven2 eclipse plugin 0.0.3 Reporter: Lee Meador Assigned to: Eugene Kuleshov Priority: Minor It seems like the code that transfers things from the POM to the Eclipse classpath needs the jar to be in the local repository but the repository searcher looks in the central repository. That means you can pick a dependency in the searcher and, if its in a remote repository, although the dependency is added to the POM, the guy that is updating the Eclipse classpath seems to look in the POM and then look in the local repo. Finding it isn't there, we get a red X on the POM and no valid maven classpath at all. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Brett Porter wrote: I've started to move some of the code from repoclean over there and added a bunch of tests (and squashed a bug or three on the way :) There's still some more to go in that regard. The code that is there is for walking the repository and discovering artifacts: still to do is matching pom artifacts, pairing poms up with appropriate artifacts, and matching attached artifacts with their pom. After that, locating metadata files in the repository. Cool. Edwin has checked in some initial interfaces for the reporting modules. These would be called out to as new artifacts are discovered in a repository, and will report on any inconsistencies, bad metadata, etc. Please send in some feedback! The projects that are there are in continuum. I'll be putting together more coherent thoughts on the wiki tomorrow and filling out JIRA with some more ideas. I know we already have one volunteer to integrate maven-proxy-like functionality - is anyone else interested in working on any pieces of functionality? Eugene has some indexing code that we can take out of the Eclipse plugin and we might want to talk to Ben about integrating the acutal Maven-Proxy code into the repository manager. I also have the client/server setup for submitting bundles. The client side is in Java but the server side is in Ruby, but that could easily be flipped over. It's just a simple xmlrpc server. It would probably make more sense to put this in the repository manger. I can sync up with you IRC. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org you are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-9) Classpath entries based on M2_REPO interfere with plugin classpath entries
Classpath entries based on M2_REPO interfere with plugin classpath entries -- Key: MNGECLIPSE-9 URL: http://jira.codehaus.org/browse/MNGECLIPSE-9 Project: Maven 2.x Plug-in for Eclipse Type: Wish Environment: Windows XP, Eclipse 3.1, MyEclipse, local repo, no mirrors, IBiblio is central repo, plugin version 0.0.3 Reporter: Lee Meador Assigned to: Eugene Kuleshov Priority: Minor My projects had originally been set up using mvn eclipse:eclipse so there were a bunch of M2_REPO based items in the classpath. When I added the maven2Nature with the menu selection, it added the maven based dependencies which, of course, duplicated the M2_REPO ones and caused an error. Perhaps there could be some way to remove the M2_REPO ones that are duplicates of the ones from the POM. I don't imagine everyone is so meticulous as to keep the two in sync when doing it by hand. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-6) Search in repository fails for log4j
[ http://jira.codehaus.org/browse/MNGECLIPSE-6?page=comments#action_52325 ] Lee Meador commented on MNGECLIPSE-6: - More environment infor: local repo, no mirrors, IBiblio is central repo, plugin version 0.0.3 Search in repository fails for log4j Key: MNGECLIPSE-6 URL: http://jira.codehaus.org/browse/MNGECLIPSE-6 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Windows XP, Eclipse 3.1, MyEclipse Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor The repository search doesn't seem to see all the things in my repository. It couldn't find anything when I typed 'log4j' or 'log4' but found things for 'log' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-239) Dumbster uses invalid Sun jar names
Dumbster uses invalid Sun jar names --- Key: MEV-239 URL: http://jira.codehaus.org/browse/MEV-239 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: mike perham http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-7) Search repository: Versions in local repo not seen
[ http://jira.codehaus.org/browse/MNGECLIPSE-7?page=comments#action_52326 ] Lee Meador commented on MNGECLIPSE-7: - More environment infor: plugin version 0.0.3 Search repository: Versions in local repo not seen -- Key: MNGECLIPSE-7 URL: http://jira.codehaus.org/browse/MNGECLIPSE-7 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Window XP, Eclipse 3.1, MyEclipse, local repo, no mirror, central=IBiblio Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor I searched for 'mail' and it seemed to find version 1.3.2. The only version in my repository is 1.3.3_01 which it didn't show. Not noticing the difference I picked the 1.3.2 version and, though it was added to the POM, the red X at the top of the POM showed an error saying it couldn't find the jar. I edited the POM by hand and put in the 1.3.3_01 version and all was well. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-9) Classpath entries based on M2_REPO interfere with plugin classpath entries
[ http://jira.codehaus.org/browse/MNGECLIPSE-9?page=comments#action_52328 ] Eugene Kuleshov commented on MNGECLIPSE-9: -- What do you think would be the right way to do this? Should we wipe out all the entries that are using M2_REPO variable? Currently you would have to manually remove all jars pointing to M2_REPO variable from the Eclipse build path. Classpath entries based on M2_REPO interfere with plugin classpath entries -- Key: MNGECLIPSE-9 URL: http://jira.codehaus.org/browse/MNGECLIPSE-9 Project: Maven 2.x Plug-in for Eclipse Type: Wish Environment: Windows XP, Eclipse 3.1, MyEclipse, local repo, no mirrors, IBiblio is central repo, plugin version 0.0.3 Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor My projects had originally been set up using mvn eclipse:eclipse so there were a bunch of M2_REPO based items in the classpath. When I added the maven2Nature with the menu selection, it added the maven based dependencies which, of course, duplicated the M2_REPO ones and caused an error. Perhaps there could be some way to remove the M2_REPO ones that are duplicates of the ones from the POM. I don't imagine everyone is so meticulous as to keep the two in sync when doing it by hand. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-checkstyle-plugin 2.0-beta-2
+1 Emmanuel John Casey a écrit : Hi everyone, I wanted to call a vote on releasing the next version of the checkstyle plugin. I'm currently working on some major bugfixes, including custom rulesets and configurations, more robust error handling for missing locale resource bundles, and a couple other things (trying to trim the list on jira down as much as possible). However, I believe that even with only those two issues that I specifically mentioned above, it would be worth a new release. These issues are not completely resolved, but should be by the time the vote closes. What do you think? I'll give it the traditional 72 hours, and we'll see where we are then. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Tue Nov 29 18:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051129.18.txt
[jira] Created: (CONTINUUM-488) Continuum will not use mirrors or alternate repositories
Continuum will not use mirrors or alternate repositories Key: CONTINUUM-488 URL: http://jira.codehaus.org/browse/CONTINUUM-488 Project: Continuum Type: Bug Components: Core system Versions: 1.0.1 Reporter: David Hawkins I can't get Continuum to use a repository other than repo1.maven.org. Running mvn manually for my user works fine and fetches the dependencies from the mirror specified in settings.xml. However, when I start continuum and it attempts the build, it always tries to get dependencies from repo1.maven.org. I have tried specifying a mirror and also specified my server in a profile/repositories/repository in settings.xml. Neither worked. -- 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-1707) eclipse:eclipse should execute in a later phase than generate-sources
eclipse:eclipse should execute in a later phase than generate-sources --- Key: MNG-1707 URL: http://jira.codehaus.org/browse/MNG-1707 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann Fix For: 2.0.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Tue Nov 29 18:30:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051129.183001.txt
RE: Exercising more commands?
I don't have time to do this right now. It'll have to wait until we deploy continuum here internally. -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 12:04 PM To: scm-dev@maven.apache.org Subject: Re: Exercising more commands? not yet, look at sources. Can you test perforce provider with continuum? Emmanuel Mike Perham a écrit : Any samples or docs on how to use the plugin? -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 11:35 AM To: scm-dev@maven.apache.org Subject: Re: Exercising more commands? maven-scm-plugin in maven-scm tree Emmanuel Mike Perham a écrit : How do I exercise the commands which are not used by the release plugin? I'm thinking mostly of the diff and changelog commands - are there any m2 plugins that use these commands? mike
[jira] Commented: (MNG-1706) site doesn't display the Last Published: in the top left
[ http://jira.codehaus.org/browse/MNG-1706?page=comments#action_52332 ] Olivier Lamy commented on MNG-1706: --- Note I use snapshot from http://snapshots.maven.codehaus.org/maven2 site doesn't display the Last Published: in the top left Key: MNG-1706 URL: http://jira.codehaus.org/browse/MNG-1706 Project: Maven 2 Type: Bug Components: maven-site-plugin Environment: all Reporter: Olivier Lamy I don't if it's a bug but the Last Published: is not in the top left ? Maybe there is a configuration way to do it but I didn't find it. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-410) Assigning a runAs user in the rc script yields directory does not exist error.
[ http://jira.codehaus.org/browse/CONTINUUM-410?page=comments#action_52333 ] Corridor Software Developer commented on CONTINUUM-410: --- Yep, it's the best approach. It uses the existing run.sh script with continuum, which operates as an rc script. rc-update add continuum default causes gentoo to start the service on boot. run.sh uses the wrapper. If continuum is run as root, then root would have to be set up to run java and maven 2, which I don't want to add to the path since it's not a development account. Assigning a runAs user in the rc script yields directory does not exist error. Key: CONTINUUM-410 URL: http://jira.codehaus.org/browse/CONTINUUM-410 Project: Continuum Type: Bug Versions: 1.0-beta-1 Environment: gentoo linux Reporter: Corridor Software Developer Priority: Critical Fix For: 1.0.2 Created a symlink to the linux run.sh script in init.d. Change the runAs to a defined user named continuum On attempts to run the server, I receive a directory does not exist error at the su -m continuum command. I'll attach the exact debug when I have the machine available. -- 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
Re: [vote] release maven-checkstyle-plugin 2.0-beta-2
On Tue, 2005-11-29 at 16:38 +1100, Brett Porter wrote: (m2-dev list doesn't exist any more :) +1 for a beta including these. +1 When we get to releasing a final, let's have it finished and offered for testing first, before voting on the release though. - Brett John Casey wrote: Hi everyone, I wanted to call a vote on releasing the next version of the checkstyle plugin. I'm currently working on some major bugfixes, including custom rulesets and configurations, more robust error handling for missing locale resource bundles, and a couple other things (trying to trim the list on jira down as much as possible). However, I believe that even with only those two issues that I specifically mentioned above, it would be worth a new release. These issues are not completely resolved, but should be by the time the vote closes. What do you think? I'll give it the traditional 72 hours, and we'll see where we are then. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1709) Project source path not generated correctly
Project source path not generated correctly --- Key: MNG-1709 URL: http://jira.codehaus.org/browse/MNG-1709 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Reporter: mike perham Maven's project reports require the source directories to reflect the artifactId of the related POM. We do not currently use that format and find that the source repository path, for instance, is not generated correctly in our case. I don't know if it is possible to support our source layout: wsf/ pom.xml support/ pom.xml (artifactId = wsf-support) common/ pom.xml (artifactId = wsf-common-support) We do this so that our directory structure is not redundant, as the maven structure is now: maven-scm/ maven-scm-providers/ maven-scm-provider-perforce/ Is there any way to support this type of layout? I would like to specify the top-level repository location and have maven figure out the correct structure to tack on to the end of the URL. The generated repository URL is: http://server/wsf/wsf-support/wsf-common-support when it should be: http://server/wsf/support/common If you are not going to support this alternative multi-module layout, could you document the existing naming standards required when doing this type of inheritance? The current documentation [http://maven.apache.org/guides/mini/guide-multi-module.html] is somewhat lacking. :-) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Dashboard Plugin Plans
Did anybody put any more work on this? I started to look at Brett's suggestions, but could not link the names to the classes. Looking at some of the plugins (Surefire, checkstyle and pmd) I think that when Brett mentions that we have the parsers, I think he's talking about the PmdReportListener, CheckstyleReportListener and an instance of org.codehaus.surefire.report.Reporter for example. Is that correct? Currently most of the plugins hardcode their parsers based on specific rules. To force the plugins to create and maintain the parsers might be too intrusive. Is there a lower level that we could use for this integration? Was it the intention to use a different SiteRenderer for this? Mauro Brett Porter wrote: (comments also added to the wiki). I think we should layer this. We already have the parsers for the reports, and could attach listeners that generate/update the metric data. From there, we need an aggregation step (Which the reports need to do also), and then the dashboard is a summary of those aggregations, but could also be a summary on a per-project level. I'd like to see this work without a database to get to this stage, and then add historical ability as a bonus. How does this sound? Can we contact xradar and see if they are interested along with David? - Brett David Le Strat wrote: Vincent, Thanks for the diagram. I started experimenting a little bit. I need some time to come up with a solid approach so far though. I am looking forward to your input and comments. I am making the assumption that there will be a dashboard project with the following subsystems (similar to your diagram): - Parser, data collectors: API will have to be specified. Some plugins such as the PMD work in memory, this may require to incorporate a listening mechanism for data collection in such plugins. - Data repository: How should the collected data be organized. - Data aggregation and Dashboard generation: I have been exploring the possibility of embedding BIRT from the eclipse project. Any strong opinion on the list on doing so? I believe that this would allow the dashboard to easily be customizable for different cuts of data aggregation using BIRT's design capabilities. The key here is to define the type of data that should be collected. I am currently further exploring the BIRT embedding. How do you want to pursue on this? Should I submit patches as I move along? Regards, David Le Strat. --- Vincent Massol [EMAIL PROTECTED] wrote: Hi David, -Original Message- From: David Le Strat [mailto:[EMAIL PROTECTED] Sent: lundi 26 septembre 2005 04:27 To: Maven Developers List Subject: Re: [M2] Dashboard Plugin Plans Thanks for the response I will enter my requests for features in Jira. If nobody has started working on such plugin, I may go ahead. I just wanted to make sure I was not duplicating any work. Does anyone have any strong opinion on how different they want the design for the new plugin to be from the M1 one? Yes, I've been thinking about this one for a very long time... It's a complex project and it requires a separate project to be set (same as Maven SCM, Maven Wagon, etc). It could be called Maven Dashboard, Maven Quality, Maven Metrics, etc. The main architectural decision is that it requires a Database to store all parsed results and analysis. Here's the architecture I would use: http://people.apache.org/~vmassol/dashboardv2.jpg Then, after this Maven Dashboard project is created we could have a Dashboard plugin in Maven proper that would use it and integrate it with Maven. I also know that Jason and Brett have some ideas on this topic. Thanks -Vincent Regards, David Le Strat. --- Edwin Punzalan [EMAIL PROTECTED] wrote: Hi, David. I doubt if anyone is working on the Dashboard plugin... right now, we are focusing on higher priority plugins towards the lesser ones. We'll soon get there ^_^ But still, anyone can contribute and start on the Dashboard plugin, it they want. We do appreciate volunteers. :D I suggest you also send your feature/mojo requests as jira improvement requests here: http://jira.codehaus.org/browse/MOJO. That way, you can monitor its progress and probably the plugin author could comment/ask more information about it. Thanks David Le Strat wrote: All, I am not sure what the plans are for the dashboard plugin for M2. According to the WIKI, it may need to be significantly rewritten. Is anyone currently working on the plugin for M2? What are the requirements for the M2 dashboard plugin? In addition to the what the M1 plugin provides: - Aggregation of information for all subprojects
[jira] Updated: (MNG-1113) Plugin does not support using custom checkstyle XML config file
[ http://jira.codehaus.org/browse/MNG-1113?page=all ] Joakim Erdfelt updated MNG-1113: Attachment: checkstyle-config-location-and-docs.tar.bz2 (re: checkstyle-config-location-and-docs.tar.bz2) I promised brett I would submit this patch (first mentioned in #maven). This patch does a few things. * Allows custom checker configurations to work. * Allows custom checker modules to work. * Allows for multi-module plugin configuration to work. * Properly documents the property expansion mechanism in checkstyle and how it relates to this plugin. * Condenses / Simplifies configuration options to be more reasonable. * Increases the ability to find the configuration information. (URL / File / Resource supported). Included in this tarball is the patch against the codebase and a sample static site (html) that can be viewed to see what the configuration and docs look like (before you apply the patch). The patch: * modifies the CheckstyleReport.java * adds a Locator.java * adds customize.apt * adds tips.apt * modifies the sample-checkstyle.html What is not included: * Code on my side that performs a merge of configurations and properties to allow for heirarchical checker configurations. * CheckstyleCheckerReport that produces a report showing what rules are actively being checked for, and how many violations of each occured during the checkstyle run. Plugin does not support using custom checkstyle XML config file --- Key: MNG-1113 URL: http://jira.codehaus.org/browse/MNG-1113 Project: Maven 2 Type: Bug Components: maven-checkstyle-plugin Versions: 2.0-beta-3 Reporter: Vincent Massol Assignee: John Casey Attachments: CheckstyleReport.java, MNG-1113-maven-checkstyle-plugin.patch, checkstyle-config-file.patch, checkstyle-config-location-and-docs.tar.bz2, recommended.txt The plugin source code says: /** * Specifies the location of the checkstyle properties that will be used to check the source. * * @parameter */ private File propertiesFile; But in practice it's only loading *properties* and not the XML. The getConfigFile() method is not right and needs to be modified to take into account a custom checkstyle config 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Jason van Zyl wrote: Eugene has some indexing code that we can take out of the Eclipse plugin I've looked. It'll be a starting point, but doesn't index all the information we need and is JAR only I think. and we might want to talk to Ben about integrating the acutal Maven-Proxy code into the repository manager. Yep, between maven-proxy and proximity we should have enough to incorporate there. I'll ping Ben when that part kicks off. I also have the client/server setup for submitting bundles. The client side is in Java but the server side is in Ruby, but that could easily be flipped over. It's just a simple xmlrpc server. It would probably make more sense to put this in the repository manger. I can sync up with you IRC. I didn't realise that, cool. We can probably put the same xmlrpc interface on the repository manager. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r349651 - /maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
alright, will back out.
Fabrizio Giustina wrote:
Hi John,
this is not needed, the issue has already been fixed some time ago.
Take a look at the comments in
http://jira.codehaus.org/browse/MNG-1216 for the solution, the fix has
been committed in rev 326881
http://svn.apache.org/viewcvs.cgi?rev=326881view=rev
fabrizio
On 11/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Mon Nov 28 21:13:22 2005
New Revision: 349651
URL: http://svn.apache.org/viewcvs?rev=349651view=rev
Log:
PR: MNG-1579
Submitted By: John Casey
Added try/catch to a new wrapper method for getBundle(..) that will report
failure to retrieve the ResourceBundle for a given locale, and default over to
usage of Locale.ENGLISH where necessary. Changed all references to
getBundle(..) to this new method.
Modified:
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
Modified:
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
URL:
http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java?rev=349651r1=349650r2=349651view=diff
==
---
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
(original)
+++
maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
Mon Nov 28 21:13:22 2005
@@ -28,6 +28,7 @@
import com.puppycrawl.tools.checkstyle.api.Configuration;
import com.puppycrawl.tools.checkstyle.api.FilterSet;
import com.puppycrawl.tools.checkstyle.filters.SuppressionsLoader;
+
import org.apache.maven.project.MavenProject;
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
@@ -46,6 +47,7 @@
import java.util.List;
import java.util.Locale;
import java.util.Map;
+import java.util.MissingResourceException;
import java.util.Properties;
import java.util.ResourceBundle;
@@ -198,7 +200,7 @@
*/
public String getName( Locale locale )
{
-return getBundle( locale ).getString( report.checkstyle.name );
+return getBundleWithDefaultLocale( locale ).getString(
report.checkstyle.name );
}
/**
@@ -206,7 +208,7 @@
*/
public String getDescription( Locale locale )
{
-return getBundle( locale ).getString( report.checkstyle.description
);
+return getBundleWithDefaultLocale( locale ).getString(
report.checkstyle.description );
}
/**
@@ -247,9 +249,29 @@
Map files = executeCheckstyle();
-CheckstyleReportGenerator generator = new CheckstyleReportGenerator(
getSink(), getBundle( locale ) );
+CheckstyleReportGenerator generator = new CheckstyleReportGenerator(
getSink(), getBundleWithDefaultLocale( locale ) );
generator.generateReport( files );
+}
+
+private ResourceBundle getBundleWithDefaultLocale( Locale locale )
+{
+ResourceBundle bundle;
+try
+{
+bundle = getBundle( locale );
+}
+catch ( MissingResourceException e )
+{
+Locale defaultLocale = Locale.ENGLISH;
+
+getLog().warn( Cannot find checkstyle message bundle for locale: +
locale.getDisplayName() + . Using default: + defaultLocale.getDisplayName() +
instead. );
+getLog().debug( Error locating message bundle., e );
+
+bundle = getBundle( defaultLocale );
+}
+
+return bundle;
}
private Map executeCheckstyle()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1303) surefire should include bootclasspath when running tests
[ http://jira.codehaus.org/browse/MNG-1303?page=comments#action_52350 ] John Casey commented on MNG-1303: - committed version of IsolatedClassLoader with loadClass(..) impl commented out, and new constructor allowing a parent ClassLoader. This works for this test case, but since it dramatically changes the classloading strategy for surefire, I wanted jason to take a look at it. surefire should include bootclasspath when running tests Key: MNG-1303 URL: http://jira.codehaus.org/browse/MNG-1303 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Environment: commons-digester 1.7; JDK 1.5.0_05 Reporter: Boris Boehlen Attachments: my-app.zip I use the common-digester to parse a configuration file. When I do this in a test case I get the following error. javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.SAXParserFactory cannot be found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at org.apache.commons.digester.Digester.getFactory(Digester.java:490) at org.apache.commons.digester.Digester.getParser(Digester.java:693) at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1704) at i3.grasgxl.core.ConfigurationLoader.load(ConfigurationLoader.java:107) Worked properly with Maven 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1707) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MNG-1707?page=comments#action_52351 ] Brett Porter commented on MNG-1707: --- it doesn't run in any phase. What I did in the idea plugin was to run generate-sources as part of the idea plugin: @execute phase=generate-sources eclipse:eclipse should execute in a later phase than generate-sources --- Key: MNG-1707 URL: http://jira.codehaus.org/browse/MNG-1707 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann Fix For: 2.0.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1705) Release plugin loses namespace information from pom.xml
[ http://jira.codehaus.org/browse/MNG-1705?page=all ] Brett Porter closed MNG-1705: - Assign To: Brett Porter Resolution: Duplicate Release plugin loses namespace information from pom.xml --- Key: MNG-1705 URL: http://jira.codehaus.org/browse/MNG-1705 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Wim Deblauwe Assignee: Brett Porter When a pom.xml defines the correct namespace, like this: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; then this information gets lost when doing a release:prepare. This should remain because xml editors (like XMLSpy) use this info for code completion and validation of the xml. regards, Wim -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1708) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MNG-1708?page=all ] Brett Porter updated MNG-1708: -- Fix Version: (was: 2.0.1) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin - Key: MNG-1708 URL: http://jira.codehaus.org/browse/MNG-1708 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann The maven-compiler-plugin allows a configuration such as: plugin artifactIdmaven-compiler-plugin/artifactId configuration excludes exclude**/idl/*Factory.java/exclude /excludes /configuration /plugin the generated .classpath file currently does not mention the excluded part: classpathentry kind=src path=src/main/java/ classpathentry kind=src path=target/generated-sources/idl/ which should be: classpathentry excluding=**/idl/*Factory.java kind=src path=src/main/java/ classpathentry excluding=**/idl/*Factory.java kind=src path=target/generated-sources/idl/ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/29-Nov-2005_04.31.04/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-9) Classpath entries based on M2_REPO interfere with plugin classpath entries
[ http://jira.codehaus.org/browse/MNGECLIPSE-9?page=comments#action_52353 ] Matt Brozowski commented on MNGECLIPSE-9: - Wouldn't it make sense to completely blow away the .classpath when enabling the mavenNature (or at least rename it or something) on a maven project manual classpath management doesn't make sense does it? Classpath entries based on M2_REPO interfere with plugin classpath entries -- Key: MNGECLIPSE-9 URL: http://jira.codehaus.org/browse/MNGECLIPSE-9 Project: Maven 2.x Plug-in for Eclipse Type: Wish Environment: Windows XP, Eclipse 3.1, MyEclipse, local repo, no mirrors, IBiblio is central repo, plugin version 0.0.3 Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor My projects had originally been set up using mvn eclipse:eclipse so there were a bunch of M2_REPO based items in the classpath. When I added the maven2Nature with the menu selection, it added the maven based dependencies which, of course, duplicated the M2_REPO ones and caused an error. Perhaps there could be some way to remove the M2_REPO ones that are duplicates of the ones from the POM. I don't imagine everyone is so meticulous as to keep the two in sync when doing it by hand. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1707) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MNG-1707?page=comments#action_52354 ] Mark Donszelmann commented on MNG-1707: --- sorry, my misunderstanding of that tag. Please correct the subject of this issue, I do not seem to have privs to do so. Indeed the eclipsePlugin has this tag as well. However I do thing that it needs a later phase here, because other plugins may add paths to the compileSourceRoots and testCompileSourceRoots. phases such as process-sources, process-test-sources (which may filter some files and put the result elsewhere). should not be neglected. Looking at the default lifecycle I guess that the test phase (or just before) should be executed as part of the eclipse:eclipse goal, to make sure one has all the paths for sources, test-sources, resources and test-resources. I may be wrong... eclipse:eclipse should execute in a later phase than generate-sources --- Key: MNG-1707 URL: http://jira.codehaus.org/browse/MNG-1707 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann Fix For: 2.0.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHANGELOG-77) Generated links to files in scm are based on the scm url tag in the pom (but should they be??)
Generated links to files in scm are based on the scm url tag in the pom (but should they be??) -- Key: MPCHANGELOG-77 URL: http://jira.codehaus.org/browse/MPCHANGELOG-77 Project: maven-changelog-plugin Type: New Feature Environment: OSX 10.4.3, java 1.4.2_09 Reporter: Julian Wood The problem is that the scm url element in the pom which is supposed to be a link to The URL to the project's browsable CVS repository. is not necessarily the same link you might use to show a file in the repository. I think this should be a configurable parameter instead. As such, it is impossible for me to have both the Source Repository report generate a correct link _and_ have the changelog generate a correct link. I have to choose one or the other. Examples: To browse repository: http://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgtrev=0sc=0path=/trunk/pmgt-jar To see a file: http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgtrev=0sc=0path=/trunk/pmgt-jar/src/main/java/ca/ucalgary/commons/pmgt/model/solution/Counter.java The difference is the script used to generate the page. I have a patch which uses a configurable parameter if interested, but I'm not sure this is the best approach, given some work also needs to be done with regards to submodule report generation. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHANGELOG-78) The time in the timestamp of the changelog report is always 00:00:00
The time in the timestamp of the changelog report is always 00:00:00 Key: MPCHANGELOG-78 URL: http://jira.codehaus.org/browse/MPCHANGELOG-78 Project: maven-changelog-plugin Type: Bug Environment: OSX 10.4.3, java 1.4.2_09 Reporter: Julian Wood Priority: Minor The time in the timestamp of the changelog report is always 00:00:00 The ChangeLogHandler ignores the time element in changelog.xml. One solution is to handle that element, as in the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPCHANGELOG-78) The time in the timestamp of the changelog report is always 00:00:00
[ http://jira.codehaus.org/browse/MPCHANGELOG-78?page=all ] Julian Wood updated MPCHANGELOG-78: --- Attachment: MNG-78-changelog-maven-plugin.patch Deals with the time element. Presumes the date element has already been parsed, and adds time to it. The time in the timestamp of the changelog report is always 00:00:00 Key: MPCHANGELOG-78 URL: http://jira.codehaus.org/browse/MPCHANGELOG-78 Project: maven-changelog-plugin Type: Bug Environment: OSX 10.4.3, java 1.4.2_09 Reporter: Julian Wood Priority: Minor Attachments: MNG-78-changelog-maven-plugin.patch The time in the timestamp of the changelog report is always 00:00:00 The ChangeLogHandler ignores the time element in changelog.xml. One solution is to handle that element, as in the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-9) Classpath entries based on M2_REPO interfere with plugin classpath entries
[ http://jira.codehaus.org/browse/MNGECLIPSE-9?page=comments#action_52360 ] Lee Meador commented on MNGECLIPSE-9: - Blowing it away completely seems somewhat draconian. Perhaps just removing the ones in M2_REPO that are duplicated in the maven dependencies classpath. Then you could at least look at them and transfer them to the POM if you had some in the classpath when you enabled Maven2 on the project. As they were added to the POM the one with M2_REPO would get removed. Classpath entries based on M2_REPO interfere with plugin classpath entries -- Key: MNGECLIPSE-9 URL: http://jira.codehaus.org/browse/MNGECLIPSE-9 Project: Maven 2.x Plug-in for Eclipse Type: Wish Environment: Windows XP, Eclipse 3.1, MyEclipse, local repo, no mirrors, IBiblio is central repo, plugin version 0.0.3 Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor My projects had originally been set up using mvn eclipse:eclipse so there were a bunch of M2_REPO based items in the classpath. When I added the maven2Nature with the menu selection, it added the maven based dependencies which, of course, duplicated the M2_REPO ones and caused an error. Perhaps there could be some way to remove the M2_REPO ones that are duplicates of the ones from the POM. I don't imagine everyone is so meticulous as to keep the two in sync when doing it by hand. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-6) Search in repository fails for log4j
[ http://jira.codehaus.org/browse/MNGECLIPSE-6?page=comments#action_52361 ] Lee Meador commented on MNGECLIPSE-6: - BTW the thing it found for log was a taglib that I didn't recognize. Search in repository fails for log4j Key: MNGECLIPSE-6 URL: http://jira.codehaus.org/browse/MNGECLIPSE-6 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: Windows XP, Eclipse 3.1, MyEclipse Reporter: Lee Meador Assignee: Eugene Kuleshov Priority: Minor The repository search doesn't seem to see all the things in my repository. It couldn't find anything when I typed 'log4j' or 'log4' but found things for 'log' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1711) Tests Using Relative Paths Fail From Parent - Absolute Paths are Non-portable
Tests Using Relative Paths Fail From Parent - Absolute Paths are Non-portable - Key: MNG-1711 URL: http://jira.codehaus.org/browse/MNG-1711 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Environment: Code base and repository on Unix. Build from Windows and Unix. Reporter: Mike Whittemore Tests in a child project fail to find files via relative path if they are run from a parent project, as the basedir of the child evaluates to the project where mvn test is run from. For example, a child project with a test-data directory in its base dir might have a unit test that loads a data file: new File(test-data/data1.xml). Running mvn test from that child project's basedir works fine. If mvn test is run from the parent directory (which has no test-data directory in this example), the child project's test cannot find the file. This was not a problem with Maven 1. According to closed issue MNG-1570, this will not be fixed. One workaround is to use an aboslute path in the test file. Unfortunately, this instantly makes it non-portable, i.e. the test cannot be run from both windows and unix (as we routinely do on my software project). There are ugly workarounds available to the test develoeprs, but I request the Maven 1 behavior be added to Maven 2 so they are not necessary. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1711) Tests Using Relative Paths Fail From Parent - Absolute Paths are Non-portable
[ http://jira.codehaus.org/browse/MNG-1711?page=all ] Brett Porter closed MNG-1711: - Assign To: Brett Porter Resolution: Won't Fix you can't reliably set the user.dir in java without forking. Your options: 1) don't use paths at all (use getResource[AsStream]() and resources) 2) use System.getProperty( basedir ) to obtain the project basedir (Maven provides it, not portable outside Maven) 3) fork the tests (functionality yet to land, but when forked user.dir = basedir) Tests Using Relative Paths Fail From Parent - Absolute Paths are Non-portable - Key: MNG-1711 URL: http://jira.codehaus.org/browse/MNG-1711 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Environment: Code base and repository on Unix. Build from Windows and Unix. Reporter: Mike Whittemore Assignee: Brett Porter Tests in a child project fail to find files via relative path if they are run from a parent project, as the basedir of the child evaluates to the project where mvn test is run from. For example, a child project with a test-data directory in its base dir might have a unit test that loads a data file: new File(test-data/data1.xml). Running mvn test from that child project's basedir works fine. If mvn test is run from the parent directory (which has no test-data directory in this example), the child project's test cannot find the file. This was not a problem with Maven 1. According to closed issue MNG-1570, this will not be fixed. One workaround is to use an aboslute path in the test file. Unfortunately, this instantly makes it non-portable, i.e. the test cannot be run from both windows and unix (as we routinely do on my software project). There are ugly workarounds available to the test develoeprs, but I request the Maven 1 behavior be added to Maven 2 so they are not necessary. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Brett Porter wrote: Jason van Zyl wrote: Eugene has some indexing code that we can take out of the Eclipse plugin I've looked. It'll be a starting point, but doesn't index all the information we need and is JAR only I think. No, but easy enough add and there are three things that I'm looking for short term which I would like to add: POMs (for existing project setup) Archetypes (for new project setup) JARs (for existing projects that need converting) Plugins (for plugin metadata) The work on the eclipse plugin is starting up again so Eugene, Dmitr and myself can certainly help with that code. and we might want to talk to Ben about integrating the acutal Maven-Proxy code into the repository manager. Yep, between maven-proxy and proximity we should have enough to incorporate there. I'll ping Ben when that part kicks off. I already talked to him and he's fine with us bring the code into the repository manager. I also have the client/server setup for submitting bundles. The client side is in Java but the server side is in Ruby, but that could easily be flipped over. It's just a simple xmlrpc server. It would probably make more sense to put this in the repository manger. I can sync up with you IRC. I didn't realise that, cool. We can probably put the same xmlrpc interface on the repository manager. Sure, or a subset. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Jason van Zyl wrote: Brett Porter wrote: Jason van Zyl wrote: Eugene has some indexing code that we can take out of the Eclipse plugin I've looked. It'll be a starting point, but doesn't index all the information we need and is JAR only I think. No, but easy enough add and there are three things that I'm looking for short term which I would like to add: POMs (for existing project setup) Archetypes (for new project setup) JARs (for existing projects that need converting) Plugins (for plugin metadata) Three, huh? :) I realise its easy enough, but that's exactly what I was getting at. The work on the eclipse plugin is starting up again so Eugene, Dmitr and myself can certainly help with that code. Sounds good. It should live in the repository manager somewhere, agree? I will push over the notes I have. Yep, between maven-proxy and proximity we should have enough to incorporate there. I'll ping Ben when that part kicks off. I already talked to him and he's fine with us bring the code into the repository manager. That's cool. I just need to take a look at both and see how they fit with the overall structure I outlined. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1702) Add ant property referencing plugin classpath to antrun plugin
[ http://jira.codehaus.org/browse/MNG-1702?page=all ] Carlos Sanchez updated MNG-1702: Attachment: (was: patch.patch) Add ant property referencing plugin classpath to antrun plugin -- Key: MNG-1702 URL: http://jira.codehaus.org/browse/MNG-1702 Project: Maven 2 Type: Improvement Components: maven-antrun-plugin Versions: 2.0 Reporter: Carlos Sanchez Attachments: MNG-1702.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1702) Add ant property referencing plugin classpath to antrun plugin
[ http://jira.codehaus.org/browse/MNG-1702?page=all ] Carlos Sanchez updated MNG-1702: Attachment: MNG-1702.patch Add ant property referencing plugin classpath to antrun plugin -- Key: MNG-1702 URL: http://jira.codehaus.org/browse/MNG-1702 Project: Maven 2 Type: Improvement Components: maven-antrun-plugin Versions: 2.0 Reporter: Carlos Sanchez Attachments: MNG-1702.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1702) Add ant property referencing plugin classpath to antrun plugin
[ http://jira.codehaus.org/browse/MNG-1702?page=all ] Carlos Sanchez updated MNG-1702: Attachment: (was: MNG-1702.patch) Add ant property referencing plugin classpath to antrun plugin -- Key: MNG-1702 URL: http://jira.codehaus.org/browse/MNG-1702 Project: Maven 2 Type: Improvement Components: maven-antrun-plugin Versions: 2.0 Reporter: Carlos Sanchez Attachments: MNG-1702.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1702) Add ant property referencing plugin classpath to antrun plugin
[ http://jira.codehaus.org/browse/MNG-1702?page=all ] Carlos Sanchez updated MNG-1702: Attachment: MNG-1702.patch Add ant property referencing plugin classpath to antrun plugin -- Key: MNG-1702 URL: http://jira.codehaus.org/browse/MNG-1702 Project: Maven 2 Type: Improvement Components: maven-antrun-plugin Versions: 2.0 Reporter: Carlos Sanchez Attachments: MNG-1702.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository manager
Brett Porter wrote: No, but easy enough add and there are three things that I'm looking for short term which I would like to add: POMs (for existing project setup) Archetypes (for new project setup) JARs (for existing projects that need converting) Plugins (for plugin metadata) Three, huh? :) I realise its easy enough, but that's exactly what I was getting at. I can't count and generally I don't know what day it is but hey, it makes life interesting. The work on the eclipse plugin is starting up again so Eugene, Dmitr and myself can certainly help with that code. Sounds good. It should live in the repository manager somewhere, agree? +1 I will push over the notes I have. This is something I think we should formalize i.e. things usually happen as - notes taken by certain folks and distilled into some first thoughts document - would be good then to have an open document where users can comment and add any ideas and thoughts they might have - then we distill that into the requirements - translate that into issues I really wish there was a tool we could use to track the transition of the feature request/idea - requirement - task so you could see the lifecycle of the thought. This is where JIRA and Confluence break down and where something like TRAC might be interesting although we're not going to just jump off the JIRA/Confluence diet just yet. Yep, between maven-proxy and proximity we should have enough to incorporate there. I'll ping Ben when that part kicks off. I already talked to him and he's fine with us bring the code into the repository manager. That's cool. I just need to take a look at both and see how they fit with the overall structure I outlined. Not sure what you mean here. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
