[jira] Updated: (CONTINUUM-856) Create add/edit/delete user group pages
[ http://jira.codehaus.org/browse/CONTINUUM-856?page=all ] Carlos Sanchez updated CONTINUUM-856: - Fix Version/s: 1.1 Create add/edit/delete user group pages --- Key: CONTINUUM-856 URL: http://jira.codehaus.org/browse/CONTINUUM-856 Project: Continuum Issue Type: New Feature Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 Same as user pages, we need the screens to add/edit/delete user groups -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-856) Create add/edit/delete user group pages
Create add/edit/delete user group pages --- Key: CONTINUUM-856 URL: http://jira.codehaus.org/browse/CONTINUUM-856 Project: Continuum Issue Type: New Feature Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 Same as user pages, we need the screens to add/edit/delete user groups -- 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-857) Allow several groups per user
[ http://jira.codehaus.org/browse/CONTINUUM-857?page=all ] Carlos Sanchez updated CONTINUUM-857: - Fix Version/s: 1.1 Component/s: (was: Web interface) Core system Allow several groups per user - Key: CONTINUUM-857 URL: http://jira.codehaus.org/browse/CONTINUUM-857 Project: Continuum Issue Type: New Feature Components: Core system Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 An user may belong to several groups -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-858) Move role add/edit/delete form to user group edit page
Move role add/edit/delete form to user group edit page -- Key: CONTINUUM-858 URL: http://jira.codehaus.org/browse/CONTINUUM-858 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez The form is currently in edit user page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-29) Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable)
[ http://jira.codehaus.org/browse/MDEP-29?page=comments#action_74449 ] Jimisola Laursen commented on MDEP-29: -- I'm working on a patch for this issue. Stay tuned. Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable) --- Key: MDEP-29 URL: http://jira.codehaus.org/browse/MDEP-29 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 1.1, 2.0 Reporter: Jimisola Laursen I haven't used 1.1/2.0 yet myself, but from Brian Fox's comment (http://jira.codehaus.org/browse/MDEP-24#action_69078) it's uncertain whether dependency:resolve outputs the absolute filename at all times. Being able to specify whether the output should be filename onlhy or absolute filename would be very useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-859) improve display of project group permissions page
improve display of project group permissions page - Key: CONTINUUM-859 URL: http://jira.codehaus.org/browse/CONTINUUM-859 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Use extremecomponents table or other method to display the content -- 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-859) improve display of project group permissions page
[ http://jira.codehaus.org/browse/CONTINUUM-859?page=all ] Carlos Sanchez updated CONTINUUM-859: - Fix Version/s: 1.1 improve display of project group permissions page - Key: CONTINUUM-859 URL: http://jira.codehaus.org/browse/CONTINUUM-859 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Assigned To: Teodoro Cue Jr. Fix For: 1.1 Use extremecomponents table or other method to display the content -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1121) Jericho HTML Parser 2.3
Jericho HTML Parser 2.3 --- Key: MAVENUPLOAD-1121 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1121 Project: maven-upload-requests Issue Type: Task Reporter: Martin Jericho Jericho HTML Parser is a simple but powerful java library allowing analysis and manipulation of parts of an HTML document, including some common server-side tags, while reproducing verbatim any unrecognised or invalid HTML. Also provides useful HTML form utilities. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-728) Disable automatic mapping of servlet/* to java classes
[ http://jira.codehaus.org/browse/CONTINUUM-728?page=all ] Carlos Sanchez closed CONTINUUM-728. Assignee: Carlos Sanchez Resolution: Fixed 1.1 no longer uses servlets, so it doesn't apply Disable automatic mapping of servlet/* to java classes -- Key: CONTINUUM-728 URL: http://jira.codehaus.org/browse/CONTINUUM-728 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.0.3 Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Fix For: 1.1 Jetty tries to map all urls continuum/servlet/* to a java class eg. continuum/servlet/x you'll get a ClassNotFoundException: x I know this can be changed in tomcat, in the configuration This causes several problems, see linked issues. -- 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-766) Integrate remember me feature with Acegi
[ http://jira.codehaus.org/browse/CONTINUUM-766?page=all ] Carlos Sanchez updated CONTINUUM-766: - Affects Version/s: 1.1 Integrate remember me feature with Acegi Key: CONTINUUM-766 URL: http://jira.codehaus.org/browse/CONTINUUM-766 Project: Continuum Issue Type: Sub-task Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 http://acegisecurity.org/docbook/acegi.html#remember-me -- 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-832) Remove DB settings duplication in configuration file
[ http://jira.codehaus.org/browse/CONTINUUM-832?page=all ] Carlos Sanchez updated CONTINUUM-832: - Affects Version/s: 1.1 Remove DB settings duplication in configuration file Key: CONTINUUM-832 URL: http://jira.codehaus.org/browse/CONTINUUM-832 Project: Continuum Issue Type: Sub-task Components: Web interface Affects Versions: 1.1 Environment: acegi branch Reporter: Carlos Sanchez Fix For: 1.1 The configuration file application.xml uses the db settings in three places now, this needs to be refactored somehow. -- 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-843) Add user form for self editing user details
[ http://jira.codehaus.org/browse/CONTINUUM-843?page=all ] Carlos Sanchez updated CONTINUUM-843: - Affects Version/s: 1.1 Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Assigned To: Napoleon Esmundo C. Ramirez Fix For: 1.1 Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi -- 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-844) Add user permission edit form in project group page
[ http://jira.codehaus.org/browse/CONTINUUM-844?page=all ] Carlos Sanchez updated CONTINUUM-844: - Fix Version/s: 1.1 Add user permission edit form in project group page --- Key: CONTINUUM-844 URL: http://jira.codehaus.org/browse/CONTINUUM-844 Project: Continuum Issue Type: Sub-task Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Assigned To: Henry S. Isidro Fix For: 1.1 In whatever page currently present for view or edit project groups, add a form to set per user and per project group permissions It needs to show the list of users and something like checkboxes for each permission Permissions are: * View * Edit * Delete * Build -- 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-852) Configuration page shows en error in the form the first time is accessed
[ http://jira.codehaus.org/browse/CONTINUUM-852?page=all ] Carlos Sanchez updated CONTINUUM-852: - Fix Version/s: 1.1 Configuration page shows en error in the form the first time is accessed Key: CONTINUUM-852 URL: http://jira.codehaus.org/browse/CONTINUUM-852 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: acegi-branch Reporter: Carlos Sanchez Fix For: 1.1 Now that the configuration step is back in place, when login the first time you get redirected to http://localhost:8080/continuum/configuration!input.action That page shows You must define a URL. for the BaseURL, seems that it's doing validation *before* submit. Also the css is bad and the message is missaligned -- 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-855) NullPointerException in DefaultContinuum.buildProjects
[ http://jira.codehaus.org/browse/CONTINUUM-855?page=all ] Carlos Sanchez updated CONTINUUM-855: - Fix Version/s: 1.1 NullPointerException in DefaultContinuum.buildProjects --- Key: CONTINUUM-855 URL: http://jira.codehaus.org/browse/CONTINUUM-855 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Environment: continuum-acegi branch Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Priority: Blocker Fix For: 1.1 I believe this was caused with the introduction of project groups. I added the pom http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?view=co 2006-09-07 22:00:00,015 [defaultScheduler_Worker-3] INFO SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 2006-09-07 22:00:00,046 [defaultScheduler_Worker-3] INFO Continuum:default - Building 1 projects 2006-09-07 22:00:00,046 [defaultScheduler_Worker-3] INFO Continuum:default - Processing 1 build definitions for project id = '1' 2006-09-07 22:00:00,046 [defaultScheduler_Worker-3] INFO Continuum:default - Enqueuing 'Apache Maven' (Build definition id=1). 2006-09-07 22:00:00,046 [pool-1-thread-1] INFO BuildController - Initializing build 2006-09-07 22:00:00,093 [pool-1-thread-1] INFO BuildController - Starting build 2006-09-07 22:00:00,093 [defaultScheduler_Worker-3] ERROR JobRunShell - Job DEFAULT.DEFAULT_SCHEDULE threw an unhandled Exception: java.lang.NullPointerException at org.apache.maven.continuum.DefaultContinuum.buildProjects(DefaultContinuum.java:617) at org.apache.maven.continuum.scheduler.ContinuumBuildJob.execute(ContinuumBuildJob.java:63) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) 2006-09-07 22:00:00,109 [defaultScheduler_Worker-3] ERROR ErrorLogger - Job (DEFAULT.DEFAULT_SCHEDULE threw an exception. org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NullPointerException] at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) * Nested Exception (Underlying Cause) --- java.lang.NullPointerException at org.apache.maven.continuum.DefaultContinuum.buildProjects(DefaultContinuum.java:617) at org.apache.maven.continuum.scheduler.ContinuumBuildJob.execute(ContinuumBuildJob.java:63) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) 2006-09-07 22:00:00,125 [pool-1-thread-1] INFO BuildController - Updating working dir 2006-09-07 22:00:00,125 [pool-1-thread-1] INFO BuildController - Performing action check-working-directory 2006-09-07 22:00:00,140 [pool-1-thread-1] INFO BuildController - Performing action update-working-directory-from-scm 2006-09-07 22:00:00,171 [pool-1-thread-1] INFO ContinuumScm - Updating project: id: '1', name 'Apache Maven'. 2006-09-07 22:00:00,187 [pool-1-thread-1] INFO ScmManager - Executing: svn --non-interactive update 2006-09-07 22:00:00,187 [pool-1-thread-1] INFO ScmManager - Working directory: C:\dev\maven\continuum-acegi\continuum-webapp\target\continuum-webapp-1.1-SNAPSHOT\WEB-INF\working-directory\1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-853) Edit user info page errors
[ http://jira.codehaus.org/browse/CONTINUUM-853?page=all ] Carlos Sanchez updated CONTINUUM-853: - Fix Version/s: 1.1 Edit user info page errors -- Key: CONTINUUM-853 URL: http://jira.codehaus.org/browse/CONTINUUM-853 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: continuu-acegi branch Reporter: Carlos Sanchez Assigned To: Lester Ecarma Fix For: 1.1 When clicking on Edit user info menu link: The user name box is empty Null pointer exception trying to save the user because in line 131 user = userManager.getUser( username ); the returned value is null In fact this should call userManager.getMyUser() to prevent people playing with fields and impersonating another user -- 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-858) Move role add/edit/delete form to user group edit page
[ http://jira.codehaus.org/browse/CONTINUUM-858?page=all ] Carlos Sanchez updated CONTINUUM-858: - Fix Version/s: 1.1 Move role add/edit/delete form to user group edit page -- Key: CONTINUUM-858 URL: http://jira.codehaus.org/browse/CONTINUUM-858 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 The form is currently in edit user page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-847) add a friendly cron editor for editSchedule
[ http://jira.codehaus.org/browse/CONTINUUM-847?page=all ] Maria Odea Ching updated CONTINUUM-847: --- Attachment: CONTINUUM-847-continuum-webapp.patch Attached patch with the updated cron expression editor. I applied all the comments in the Please review/comment on the updated cron editor in the continuum white site email thread from the Continuum Dev List. This patch is for continuum-webapp module. Thanks :) add a friendly cron editor for editSchedule --- Key: CONTINUUM-847 URL: http://jira.codehaus.org/browse/CONTINUUM-847 Project: Continuum Issue Type: Improvement Reporter: Maria Odea Ching Assigned To: Maria Odea Ching Attachments: CONTINUUM-847-continuum-uml.patch, CONTINUUM-847-continuum-webapp.patch Original Estimate: 10 hours Time Spent: 8 hours Remaining Estimate: 2 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-90) Exception if version is SNAPSHOT
[ http://jira.codehaus.org/browse/MRELEASE-90?page=comments#action_74452 ] Stefan Rufer commented on MRELEASE-90: -- Hi, Developing on HEAD we decided to give the version simply the name SNAPSHOT. It would be very convenient if maven would be able to handle this without error. thanks a lot Stefan Exception if version is SNAPSHOT Key: MRELEASE-90 URL: http://jira.codehaus.org/browse/MRELEASE-90 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-3 Reporter: Joerg Schaible Assigned To: Brett Porter Fix For: 2.0-beta-4 If the project has a very simple version scheme (i.e. only a simple number) and has therefore set the verstion tag to SNAPSHOT, the plugin fails with a StringIndexOutOfRange exception: [INFO] [release:prepare] [INFO] Verifying there are no local modifications ... [INFO] Checking lineage for snapshots ... [INFO] Checking dependencies for snapshots ... [INFO] Checking plugins for snapshots ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1444) at org.apache.maven.plugins.release.helpers.ProjectVersionResolver.resolveVersion(ProjectVersionResolver.java:61) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:219) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- 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-2157) Properties defined in top-level profiles.xml do no propagate to child modules
[ http://jira.codehaus.org/browse/MNG-2157?page=comments#action_74456 ]
Carsten Karkola commented on MNG-2157:
--
We have encountered the same problem. putting some profile values in the
pom.xml is ok for values shared by all developers. But we have profile
variables with individual values for the different developers. If somebody
wants to change a variable for himself, he has to check out the pom.xml (what
I'd like to avoid, especially in branches/parallel releases). Is there any fix
available for this profile.xml issue?
Properties defined in top-level profiles.xml do no propagate to child modules
-
Key: MNG-2157
URL: http://jira.codehaus.org/browse/MNG-2157
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.2
Reporter: Jason Dillon
Priority: Blocker
Fix For: 2.0.5
I have a multi-module build, and at the top-level I have a profile called
'release-environment', which is activated by -Denv=release.
I need the local release build to use different values for JDBC configuration
to run integration tests, and defined them in a profiles.xml:
{code}
?xml version=1.0 encoding=UTF-8?
settings
profiles
profile
idlocal-release-environment/id
activation
property
nameenv/name
valuerelease/value
/property
/activation
properties
jdbc.usernamemif_jason/jdbc.username
jdbc.passwordmif_jason/jdbc.password
jdbc.schemaMIF_JASON/jdbc.schema
/properties
/profile
/profiles
/settings
{code}
My project looks like:
pom.xml
merchant/pom.xml
merchant/core/pom.xml
merchant/services/pom.xml
If i put profiles.xml as a peer to pom.xml and run {{mvn clean install
-Denv=release}} from the top-level, I get errors because the properties are
not propagated to the merchant/core/pom.xml module.
If I put profiles.xml as a peer to merchant/core/pom.xml and run {{mvn clean
install -Denv=release}}, then it works as expected... properties are set as
they are defined in profiles.xml.
But, this is not manageable, as I need to set some properties for all of the
modules in a multi-module build... But I don't want to use those properties
for all Maven2 projects, so I can not really put it into ~/.m2/settings.xml
I had expected that a top-level profiles.xml would work, but it does not. Is
this by design, is there another recommend way to provide per-top-level
multi-module project configuration on a local user basis (ie. no pom.xml
modifications)?
--
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-2550) ClassNotFoundException and NoClassDefFoundError when running plugin
[ http://jira.codehaus.org/browse/MNG-2550?page=comments#action_74458 ] Joost den Boer commented on MNG-2550: - ok, I overcame my doubts and tried it. And you're right, it works. However, this only solves half of the problem. There still is the problem that when deserializing an object, the class cannot be found. Any ideas how to solve this ? Only this I can think of is that Maven must place the dependend packages on the classpath. ClassNotFoundException and NoClassDefFoundError when running plugin --- Key: MNG-2550 URL: http://jira.codehaus.org/browse/MNG-2550 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Reporter: Joost den Boer I created a plugin which runs a small application which does some parsing, logging and serializing. When running the plugin I get ClassNotFoundExceptions and NoClassDefFoundErrors. The application used BeanUtils (1.7). Somewhere in that package a Log instance is created, but the classloader cannot find org.apache.log4j.Logger and an NoClassDefFoundError is thrown. The application serializes objects to a file using the ObjectOutputStream and ObjectInputStream. Serializing to a file works fine. Serializing from file to an Object throws a ClassNotFoundException because the base classloader does not know any object from any dependency. Both errors are caused by the classloader not knowing any of the dependend packages of the Maven project in which the plugin is used or on which the plugin depends. I tried several solutions: using my own URLClassLoader extention and using ClassWorld and creating a new ClassRealm. To both I added all project.RuntimeClasspathElements. These solutions fixed some problems but not all. In some cases the original classloader is still used (by included packages like org.apache.common.logging or by base java classes like java.io.ObjectInputStream) and that classloaded does not know my project classes and dependend packages. Can't maven itself not just include all dependend packages of the project (and plugin) on the classpath so you don't have to do that yourself inside the plugin ? I searched for similar bugs and found some but they are all fixed and closed in older maven version. Can someone please help me with this issue ? Here part of the stacktrace. As you can see, the ObjectInputStream uses Class.forName() which resolves to the RealmClassLoader, but not to my MyURLClassLoader instance. java.lang.ClassNotFoundException: nl.eid.aegon.rpf.parser.model.ClassDescription at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) Here the stacktrace for the NoClassDefFoundError. It starts when I try to log something in the application using org.apache.common.logging. The only way I could solve this was to put the log4j package in the Maven lib directory, but this is not a prefered solution. The log4j.jar is a dependend package and should be included on the classpath by the classloader. [INFO] [INFO] Trace java.lang.ExceptionInInitializerError at nl.eid.replatforming_framework.parser.Parser.parse(Parser.java:45) at nl.eid.replatforming_framework.maven.RunAllMojo.runAll(RunAllMojo.java:404) at
[jira] Updated: (MDEP-29) Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable)
[ http://jira.codehaus.org/browse/MDEP-29?page=all ] Jimisola Laursen updated MDEP-29: - Attachment: MDEP-29.diff This patch changes DependencyStatusSets.logStatus to logStatus( Log log, boolean outputArtifactFilename ). If outputArtifactFilename is true then the method will output the absolute filename for of resolved artifact. Further, this patch adds the configuration parameter 'outputArtifactFilename to AbstractDependencyFilterMojo. I placed it here since it should be available for all (?) plugin goals. However, not all of the code has been refactored to use DependencyStatusSets so the configuration parameter doesn't do anything (yet) for the other goals. Not sure if this is this the way to go. If it isn't then just move the configuration parameter to ResolveDependenciesMojo. Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable) --- Key: MDEP-29 URL: http://jira.codehaus.org/browse/MDEP-29 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 1.1, 2.0 Reporter: Jimisola Laursen Attachments: MDEP-29.diff I haven't used 1.1/2.0 yet myself, but from Brian Fox's comment (http://jira.codehaus.org/browse/MDEP-24#action_69078) it's uncertain whether dependency:resolve outputs the absolute filename at all times. Being able to specify whether the output should be filename onlhy or absolute filename would be very useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-860) multiple email addresses delimited with commas causes AddressException
multiple email addresses delimited with commas causes AddressException -- Key: CONTINUUM-860 URL: http://jira.codehaus.org/browse/CONTINUUM-860 Project: Continuum Issue Type: Bug Reporter: Adam Hardy Email notification fails with a javax.mail.internet.AddressException: Illegal route-addr in string exception when a comma-delimited list of email addresses is used. See the linked message for the pom.xml node for an example. There is a work-around, see this thread in user list http://mail-archives.apache.org/mod_mbox/maven-continuum-users/200609.mbox/browser -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-90) Exception if version is SNAPSHOT
[ http://jira.codehaus.org/browse/MRELEASE-90?page=all ] Stefan Rufer updated MRELEASE-90: - Attachment: MNG-90-maven-release-plugin.patch Fix for maven-release-plugin that handles the next version more carefully to avoid the NullPointerException described in the issue. If the next version information can not be determined, the proposal for interactive mode is set to empty string. Not nice but I don't see how to get a good default at the moment. Exception if version is SNAPSHOT Key: MRELEASE-90 URL: http://jira.codehaus.org/browse/MRELEASE-90 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-3 Reporter: Joerg Schaible Assigned To: Brett Porter Fix For: 2.0-beta-4 Attachments: MNG-90-maven-release-plugin.patch If the project has a very simple version scheme (i.e. only a simple number) and has therefore set the verstion tag to SNAPSHOT, the plugin fails with a StringIndexOutOfRange exception: [INFO] [release:prepare] [INFO] Verifying there are no local modifications ... [INFO] Checking lineage for snapshots ... [INFO] Checking dependencies for snapshots ... [INFO] Checking plugins for snapshots ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1444) at org.apache.maven.plugins.release.helpers.ProjectVersionResolver.resolveVersion(ProjectVersionResolver.java:61) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:219) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- 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-852) Configuration page shows en error in the form the first time is accessed
[ http://jira.codehaus.org/browse/CONTINUUM-852?page=comments#action_74471 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-852: --- Is it ok to just use a default value for the baseUrl to avoid the validation errors before submitting the configuration? Btw, in the branch, the companyUrl can now be saved. Configuration page shows en error in the form the first time is accessed Key: CONTINUUM-852 URL: http://jira.codehaus.org/browse/CONTINUUM-852 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: acegi-branch Reporter: Carlos Sanchez Assigned To: Napoleon Esmundo C. Ramirez Fix For: 1.1 Now that the configuration step is back in place, when login the first time you get redirected to http://localhost:8080/continuum/configuration!input.action That page shows You must define a URL. for the BaseURL, seems that it's doing validation *before* submit. Also the css is bad and the message is missaligned -- 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-2555) maven-metadata.xml for springframework.spring is missing recent versions
maven-metadata.xml for springframework.spring is missing recent versions Key: MNG-2555 URL: http://jira.codehaus.org/browse/MNG-2555 Project: Maven 2 Issue Type: Bug Components: Repositories Environment: all Reporter: Stephen Coy Priority: Minor The maven-metadata.xml file for springframework.spring @ ibiblio http://www.ibiblio.org/maven2/org/springframework/spring/maven-metadata.xml is missing recent version information - 1.2.7, 1.2.8 and all the 2.0RC releases. The main consequence of this (for me) is that the version range [1.2,1.3) resolves to 1.2.6 instead of 1.2.8. -- 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-853) Edit user info page errors
[ http://jira.codehaus.org/browse/CONTINUUM-853?page=comments#action_74476 ] Carlos Sanchez commented on CONTINUUM-853: -- Fixed the extra user creation in ConfigurationAction Edit user info page errors -- Key: CONTINUUM-853 URL: http://jira.codehaus.org/browse/CONTINUUM-853 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: continuu-acegi branch Reporter: Carlos Sanchez Assigned To: Lester Ecarma Fix For: 1.1 When clicking on Edit user info menu link: The user name box is empty Null pointer exception trying to save the user because in line 131 user = userManager.getUser( username ); the returned value is null In fact this should call userManager.getMyUser() to prevent people playing with fields and impersonating another user -- 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-861) Last login or failed login attempts don't seem to be updated in the database
[ http://jira.codehaus.org/browse/CONTINUUM-861?page=all ] Carlos Sanchez updated CONTINUUM-861: - Fix Version/s: 1.1 Last login or failed login attempts don't seem to be updated in the database Key: CONTINUUM-861 URL: http://jira.codehaus.org/browse/CONTINUUM-861 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 Not sure if we use last login at all, but at least login attempts is needed to block the account after some wrong logins. i think its because the event happens in Acegi world and doesn't reach UserManager, we probably need the Event listener for acegi I mentioned in another issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-861) Last login or failed login attempts don't seem to be updated in the database
Last login or failed login attempts don't seem to be updated in the database Key: CONTINUUM-861 URL: http://jira.codehaus.org/browse/CONTINUUM-861 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 Not sure if we use last login at all, but at least login attempts is needed to block the account after some wrong logins. i think its because the event happens in Acegi world and doesn't reach UserManager, we probably need the Event listener for acegi I mentioned in another issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=all ] Carlos Sanchez reopened CONTINUUM-796: -- Assignee: (was: Carlos Sanchez) Disable account on login failures - Key: CONTINUUM-796 URL: http://jira.codehaus.org/browse/CONTINUUM-796 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Fix For: 1.1 We can hook into acegi authz event system to get unsuccessful logins and add the counter. After a definer number (eg. 3) of unsucessful consecutive logins the account must be disabled. -- 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: (MRELEASE-156) Prompt for customizing commit comment during release preparation
Prompt for customizing commit comment during release preparation Key: MRELEASE-156 URL: http://jira.codehaus.org/browse/MRELEASE-156 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: Dário Oliveros Hi there, I've been trying to use maven-release-plugin to prepare a release, but whenever I do that, it fails since I have a SVN precommit hook that integrates with an issue tracking system which in turn waits for a comment containing an issue number. Since release plugin adds its own comment, such as [maven-release-plugin] prepare release ..., this integration fails. So I was wondering if this could be prompted in the same way for the release and next development iteration versions. Thanks, Dário -- 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: (MCLOVER-47) Align plugin documentation with Maven standards
[ http://jira.codehaus.org/browse/MCLOVER-47?page=all ] Franz Allan Valencia See updated MCLOVER-47: Attachment: MCLOVER-47-maven-clover-plugin-3.patch Good day to you, Vincent, I see your point there. In line with that, I placed all the examples back to the Usage section. However, the organization and some wording have changed. I first introduced the Instrumentation (in the guise of Getting Started) and then followed it up by Checking test coverage, then Generating a clover report, then the rest. Furthermore, I made some parts into subsections of others. The main sections are the usual use cases (except for the last part...but since I can't seem to find a main section to put it under, I simply made it into a main section) while the subsections are the not so often use cases. (btw, I've also fixed the table of contents links and added a back to top.) Furthermore, I changed the Introduction page to match those of the other plugin documentations. Meaning I made some format changes, and added the Goals section. But I did retain your Features section and I no longer modified your Examples section. Maybe we should try and finish this first before raising it in the dev list so that we can stage this up to give the community of the plugin documentation we would be proposing WDYT? Thanks, Franz Align plugin documentation with Maven standards --- Key: MCLOVER-47 URL: http://jira.codehaus.org/browse/MCLOVER-47 Project: Maven 2.x Clover Plugin Issue Type: Task Affects Versions: 2.2 Reporter: John Tolentino Assigned To: Vincent Massol Fix For: 2.3 Attachments: MCLOVER-47-maven-clover-plugin-2.patch, MCLOVER-47-maven-clover-plugin-3.patch, MCLOVER-47-maven-clover-plugin.patch http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPWAR-66) Allow Axis2 archives (.aar files) to be imported into WEB-INF/services directory
Allow Axis2 archives (.aar files) to be imported into WEB-INF/services directory Key: MPWAR-66 URL: http://jira.codehaus.org/browse/MPWAR-66 Project: maven-war-plugin Issue Type: Wish Reporter: John Pfeifer Attachments: AbstractWarMojo.java I have recently been working with axis2 and have found the need to import axis2 archive files (.aar extension) into the WEB-INF/services directory. I have made the changes to the maven war plugin source and they work great. -- 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-1108) Upload Spring 2.0 rc3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1108?page=comments#action_74479 ] Matt Raible commented on MAVENUPLOAD-1108: -- Why are there two versions of Spring being maintained in ibiblio's repo? I just saw this one added this morning: http://mvnrepository.com/artifact/spring/spring/2.0-rc3 Upload Spring 2.0 rc3 - Key: MAVENUPLOAD-1108 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1108 Project: maven-upload-requests Issue Type: Wish Reporter: Matt Raible Assigned To: Carlos Sanchez Can you please upload this bundle? It's spring-2.0-rc3.jar. I know you'd rather have all the child POMs/JARs, but it's s much easier to just do one. ;-) -- 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: (MJXR-15) Parameter sourcePaths like it exists in Javadoc plugin added
Parameter sourcePaths like it exists in Javadoc plugin added Key: MJXR-15 URL: http://jira.codehaus.org/browse/MJXR-15 Project: Maven 2.x JXR Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: WinXp Reporter: Martin Zeltner Attachments: patch_maven-jxr-plugin_parameter-sourcePaths-added.patch I've added the parameter sourcePaths. If this parameter is set the jxr plugin will take the java sources from the given paths instead of the root source path. If it is not set the plugin will work as before. This is very useful to define own sets of jxr report pages. Cheers, Martin -- 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_74480 ]
Mike Perham commented on MANTRUN-37:
This definitely has to do with the xdoclet plugin using antrun 1.0 directly and
then the build later trying to use antrun 1.1. I'd suggest releasing a new
version of xdoclet plugin which uses antrun 1.1. Hopefully sync'ing the two
versions will prevent this problem.
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Priority: Critical
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at
[jira] Commented: (MAVENUPLOAD-1108) Upload Spring 2.0 rc3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1108?page=comments#action_74481 ] Carlos Sanchez commented on MAVENUPLOAD-1108: - Deployed by mistake and removed Upload Spring 2.0 rc3 - Key: MAVENUPLOAD-1108 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1108 Project: maven-upload-requests Issue Type: Wish Reporter: Matt Raible Assigned To: Carlos Sanchez Can you please upload this bundle? It's spring-2.0-rc3.jar. I know you'd rather have all the child POMs/JARs, but it's s much easier to just do one. ;-) -- 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_74483 ]
Mike Perham commented on MANTRUN-37:
I can't upgrade xdoclet to use antrun 1.1 because AbstractAntMojo in 1.1 has
the following injected field:
{code}
/**
* The plugin dependencies.
*
* @parameter expression=${plugin.artifacts}
* @required
* @readonly
*/
private List artifacts;
{code}
When you subclass this class (as the xdoclet plugin does), it appears that
Maven is NOT injecting this field and so {{artifacts}} is null at runtime. If
we can fix this, we could essentially get rid of the xdoclet plugin and just
use antrun directly.
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Priority: Critical
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
[jira] Commented: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=comments#action_74484 ]
Max Bowsher commented on MNG-2456:
--
I think the true issue is in the core component maven-artifact-manager, in the
DefaultArtifactResolver class - which, in the case of a snapshot version,
explicitly overrides the artifact's file property from the version name to
the baseVersion name. Search for the line artifact.setFile( copy ); to find
the relevant place in the code. I suggest that that line should simply be
deleted, allowing artifact.getName() to remain returning the version name.
Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
snapshots
Key: MNG-2456
URL: http://jira.codehaus.org/browse/MNG-2456
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.4
Reporter: Baerrach bonDierne
Attachments: MNG-2456-patch.txt,
MNG-2456-step1-refactoring-patch.txt,
MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
See related problems MJAR-28 and MASSEMBLY-67.
Summary:
The Maven-Archiver uses the file part of the artifact's filename to create
the Class-Path entries in the Manifest.
This works fine for released artifacts and non-deployed snapshot.
The problem occurs when using a deployed snapshot as the assembly plugin will
copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
thus use of java -jar jarfile will fail because of the differing names.
--
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: (MRELEASE-159) Support a pattern to generate the release tag
Support a pattern to generate the release tag - Key: MRELEASE-159 URL: http://jira.codehaus.org/browse/MRELEASE-159 Project: Maven 2.x Release Plugin Issue Type: New Feature Affects Versions: 2.0-beta-4 Reporter: Joerg Schaible The release-plugin uses currently the pattern artifactId-version to create the version tag. A configuration element would be fine to support different requirements for release tags (in our case v_version, since with svn the module is already part of the path). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-863) Error clicking on project build results
Error clicking on project build results --- Key: CONTINUUM-863 URL: http://jira.codehaus.org/browse/CONTINUUM-863 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: David Schwartz Priority: Blocker 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit - ...1 (1)] log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit =A ...1 (1)] 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Locating AclEntry[]s (from set of 3) that apply to Authentication: org.acegisecurity.providers.UsernamePasswordAuthenticationTo ROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_addNotifier, ROLE_addProject, ROLE_admin, ROLE_user, ROLE_deleteBuildDefinition n, ROLE_manageSchedule, ROLE_manageUsers; Password: [PROTECTED]; Authenticated: true; Details: [EMAIL PROTECTED]: RemoteIpAddress: 127.0.0.1; SessionId: 7dsaf0ensj5ok; Gran Definition, ROLE_deleteNotifier, ROLE_editBuildDefinition, ROLE_editNotifier, ROLE_manageConfiguration, ROLE_manageSchedule, ROLE_manageUsers 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - GrantedAuthority: ROLE_admin matches recipient: ROLE_admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Principal (from UserDetails) matches AclEntry recipient: admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Returning effective AclEntry array with 2 elements 2006-09-11 15:01:29,687 [btpool0-4] INFO Action:buildResults- checking the continuum configuration 2006-09-11 15:01:29,953 [btpool0-4] WARN SQL- Object with id 0 not found ! 2006-09-11 15:01:29,953 [btpool0-4] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: No such object. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:2301) at org.apache.maven.continuum.DefaultContinuum.getBuildResultsForProject(DefaultContinuum.java:2261) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject_aroundBody68(AcegiContinuum.java:269) at org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure69.run(AcegiContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject(AcegiContinuum.java:1) at org.apache.maven.continuum.web.action.BuildResultsListAction.execute(BuildResultsListAction.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at
[jira] Commented: (CONTINUUM-863) Error clicking on project build results
[ http://jira.codehaus.org/browse/CONTINUUM-863?page=comments#action_74510 ] David Schwartz commented on CONTINUUM-863: -- Similar when clicking on working copy 2006-09-11 15:06:00,421 [btpool0-4] INFO Action:workingCopy - checking the continuum configuration 2006-09-11 15:06:00,656 [btpool0-4] WARN SQL- Object with id 0 not found ! 2006-09-11 15:06:00,656 [btpool0-4] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: Can't get files list. at org.apache.maven.continuum.DefaultContinuum.getWorkingDirectory(DefaultContinuum.java:1611) at org.apache.maven.continuum.DefaultContinuum.getFiles(DefaultContinuum.java:1637) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getFiles_aroundBody80(AcegiContinuum.java:303) at org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure81.run(AcegiContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getFiles(AcegiContinuum.java:1) at org.apache.maven.continuum.web.action.WorkingCopyAction.execute(WorkingCopyAction.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:62) at
[jira] Closed: (MDEP-24) Sort the dependency:resolve output alphabetically
[ http://jira.codehaus.org/browse/MDEP-24?page=all ] Brian Fox closed MDEP-24. - Resolution: Fixed Fix Version/s: 2.0-ALPHA1 Patch applied, thanks. Sort the dependency:resolve output alphabetically - Key: MDEP-24 URL: http://jira.codehaus.org/browse/MDEP-24 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Brian Fox Assigned To: Brian Fox Priority: Trivial Fix For: 2.0-ALPHA1 Attachments: sorted-output.diff Output looks like this: [INFO] Resolved: fdf-toolkit-1.0.jar [INFO] Resolved: activation-1.0.2.jar [INFO] Resolved: sqlline-1.0.jar [INFO] Resolved: struts-legacy-1.1.jar [INFO] Resolved: jdo-1.0.2.jar [INFO] Resolved: xalan-2.5.1.jar [INFO] Resolved: dom4j-1.5.2.jar [INFO] Resolved: xpp3-1.1.3.3.jar [INFO] Resolved: qdox-1.5.jar [INFO] Resolved: kodo-jdo-3.3.4.jar Would be better sorted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-6) ClassCastException in project with sub-projects
[ http://jira.codehaus.org/browse/MDEP-6?page=all ]
Brian Fox closed MDEP-6.
Resolution: Duplicate
Fix Version/s: 2.0-ALPHA1
ClassCastException in project with sub-projects
---
Key: MDEP-6
URL: http://jira.codehaus.org/browse/MDEP-6
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Environment: JDK1.5
Reporter: Fredrik Holmqvist
Assigned To: Brian Fox
Priority: Critical
Fix For: 2.0-ALPHA1
Attachments: castToArtifactInstead.patch
When a sub-project tries to copy dependencies from another sub-project some
of the artifacts are ActiveProjectArtifact's which doesn't cast to
DefaultArtifact but to Artifact. Changing the casting fixes that.
[INFO] [dependency:copy-dependencies {execution: copy-dependencies}]
[INFO] Including Transitive Dependencies.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] org.apache.maven.project.artifact.ActiveProjectArtifact
[INFO]
[INFO] Trace
java.lang.ClassCastException:
org.apache.maven.project.artifact.ActiveProjectArtifact
at
org.codehaus.mojo.dependency.CopyDependenciesMojo.execute(CopyDependenciesMojo.java:63)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-3) [dependency-maven-plugin] Override existing output file
[ http://jira.codehaus.org/browse/MDEP-3?page=all ] Brian Fox closed MDEP-3. Resolution: Fixed Fix Version/s: 2.0-ALPHA1 [dependency-maven-plugin] Override existing output file --- Key: MDEP-3 URL: http://jira.codehaus.org/browse/MDEP-3 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Laurent Berteau Assigned To: Brian Fox Fix For: 2.0-ALPHA1 Set an option to enable overwriting of existing files in destination location -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-29) Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable)
[ http://jira.codehaus.org/browse/MDEP-29?page=all ] Brian Fox closed MDEP-29. - Resolution: Fixed Fix Version/s: 2.0-ALPHA1 patch applied, thanks. Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable) --- Key: MDEP-29 URL: http://jira.codehaus.org/browse/MDEP-29 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 1.0, 2.0 Reporter: Jimisola Laursen Assigned To: Brian Fox Fix For: 2.0-ALPHA1 Attachments: MDEP-29.diff I haven't used 1.1/2.0 yet myself, but from Brian Fox's comment (http://jira.codehaus.org/browse/MDEP-24#action_69078) it's uncertain whether dependency:resolve outputs the absolute filename at all times. Being able to specify whether the output should be filename onlhy or absolute filename would be very useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-30) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MDEP-30?page=all ] Brian Fox updated MDEP-30: -- Affects Version/s: 2.0-ALPHA1 will review and update before alpha-1 Review Plugin Documentation --- Key: MDEP-30 URL: http://jira.codehaus.org/browse/MDEP-30 Project: Maven 2.x Dependency Plugin Issue Type: Task Affects Versions: 2.0-ALPHA1 Reporter: Allan Ramirez Assigned To: Brian Fox Original Estimate: 1 day Time Spent: 1 day, 9 hours Remaining Estimate: 0 minutes document the plugin based on the standard plugin documentation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-28) Incorregect information on How to use web page
[ http://jira.codehaus.org/browse/MDEP-28?page=all ] Brian Fox closed MDEP-28. - Assignee: Brian Fox Resolution: Fixed Fix Version/s: 2.0-ALPHA1 appears to have been fixed in the rewrite of the documentation Incorregect information on How to use web page Key: MDEP-28 URL: http://jira.codehaus.org/browse/MDEP-28 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Jimisola Laursen Assigned To: Brian Fox Priority: Trivial Fix For: 2.0-ALPHA1 On the How to use web page (http://mojo.codehaus.org/dependency-maven-plugin/howto.html) /exections needs to be replaced with /executions -- 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-853) Edit user info page errors
[ http://jira.codehaus.org/browse/CONTINUUM-853?page=comments#action_74527 ] Lester Ecarma commented on CONTINUUM-853: - All the other issues I posted above have already been fixed as well. Edit user info page errors -- Key: CONTINUUM-853 URL: http://jira.codehaus.org/browse/CONTINUUM-853 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: continuu-acegi branch Reporter: Carlos Sanchez Assigned To: Lester Ecarma Fix For: 1.1 When clicking on Edit user info menu link: The user name box is empty Null pointer exception trying to save the user because in line 131 user = userManager.getUser( username ); the returned value is null In fact this should call userManager.getMyUser() to prevent people playing with fields and impersonating another user -- 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-854) Project tabbed menu doesn't pass the projectId, causing an error
[ http://jira.codehaus.org/browse/CONTINUUM-854?page=comments#action_74528 ] Lester Ecarma commented on CONTINUUM-854: - Can't replicate in current revision (r442352) of continuum-acegi branch. This may have already been fixed. Project tabbed menu doesn't pass the projectId, causing an error Key: CONTINUUM-854 URL: http://jira.codehaus.org/browse/CONTINUUM-854 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 The links in the tabbed menu for projects don't add the projectId, the action assumes is 0 and the DB fails because there's no such element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-21) Option to not copy 'provided' scoped jars
[ http://jira.codehaus.org/browse/MDEP-21?page=all ] Brian Fox closed MDEP-21. - Resolution: Fixed Fix Version/s: 2.0-ALPHA1 Added the ability to specify a scope to exclude. This uses the plexus ScopeArtifactFilter, which defines what scopes are included. For example, since test scope effectively includes all other scopes, then excluding the test scope would exclude everything. (which the plugin won't allow) Option to not copy 'provided' scoped jars - Key: MDEP-21 URL: http://jira.codehaus.org/browse/MDEP-21 Project: Maven 2.x Dependency Plugin Issue Type: Wish Environment: Maven2 Reporter: Gwyn Evans Assigned To: Brian Fox Fix For: 2.0-ALPHA1 It would be useful if there were an option that could be set such that a 'scope=provided' jar would not be copied via copy-dependencies, but I can't see any way of setting such or otherwise excluding such a jar from the copy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-22) copy of provided dependencies
[ http://jira.codehaus.org/browse/MDEP-22?page=all ] Brian Fox closed MDEP-22. - Assignee: Brian Fox Resolution: Fixed Fix Version/s: 2.0-ALPHA1 Added the ability to specify a scope to exclude. This uses the plexus ScopeArtifactFilter, which defines what scopes are included. For example, since test scope effectively includes all other scopes, then excluding the test scope would exclude everything. (which the plugin won't allow) copy of provided dependencies - Key: MDEP-22 URL: http://jira.codehaus.org/browse/MDEP-22 Project: Maven 2.x Dependency Plugin Issue Type: Wish Environment: all Reporter: Jerome CARRE Assigned To: Brian Fox Priority: Minor Fix For: 2.0-ALPHA1 create an attribute to say don't copy 'provided' dependencies, into copy-dependencies goal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-37) setting type in config causes NullPointerException
[ http://jira.codehaus.org/browse/MDEP-37?page=all ] Brian Fox closed MDEP-37. - Assignee: Brian Fox Resolution: Fixed Fix Version/s: 2.0-ALPHA1 patch applied thanks. Obviously this wasn't testedI need to get the full plugin unit tests setup to catch these things. setting type in config causes NullPointerException -- Key: MDEP-37 URL: http://jira.codehaus.org/browse/MDEP-37 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0 Environment: suse10.0, java 1.4.2_11-b06,Maven version: 2.0.4 , latest subverion trunk Reporter: kristian meier Assigned To: Brian Fox Fix For: 2.0-ALPHA1 Attachments: patch class does not set instacne variable factory -- 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: (MPIR-56) Refactor the dependencies report
[ http://jira.codehaus.org/browse/MPIR-56?page=all ] Marvin King updated MPIR-56: Attachment: MPIR-56-maven-project-info-reports-plugin.patch Refactor the dependencies report Key: MPIR-56 URL: http://jira.codehaus.org/browse/MPIR-56 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Marvin King Assigned To: Marvin King Attachments: MPIR-56-maven-project-info-reports-plugin.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-56) Refactor the dependencies report
[ http://jira.codehaus.org/browse/MPIR-56?page=all ] Marvin King updated MPIR-56: Attachment: (was: MPIR-56-maven-project-info-reports-plugin.patch) Refactor the dependencies report Key: MPIR-56 URL: http://jira.codehaus.org/browse/MPIR-56 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Marvin King Assigned To: Marvin King -- 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: (MPIR-56) Refactor the dependencies report
[ http://jira.codehaus.org/browse/MPIR-56?page=all ] Marvin King updated MPIR-56: Attachment: MPIR-56-maven-project-info-reports-plugin.patch Refactor the dependencies report Key: MPIR-56 URL: http://jira.codehaus.org/browse/MPIR-56 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Marvin King Assigned To: Marvin King Attachments: MPIR-56-maven-project-info-reports-plugin.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPIR-56) Refactor the dependencies report
[ http://jira.codehaus.org/browse/MPIR-56?page=all ] Brett Porter closed MPIR-56. Resolution: Fixed Fix Version/s: 2.1 Refactor the dependencies report Key: MPIR-56 URL: http://jira.codehaus.org/browse/MPIR-56 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Marvin King Assigned To: Marvin King Fix For: 2.1 Attachments: MPIR-56-maven-project-info-reports-plugin.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-863) Error clicking on project build results
[ http://jira.codehaus.org/browse/CONTINUUM-863?page=all ] Carlos Sanchez updated CONTINUUM-863: - Fix Version/s: 1.1 Error clicking on project build results --- Key: CONTINUUM-863 URL: http://jira.codehaus.org/browse/CONTINUUM-863 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: David Schwartz Priority: Blocker Fix For: 1.1 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit - ...1 (1)] log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit =A ...1 (1)] 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Locating AclEntry[]s (from set of 3) that apply to Authentication: org.acegisecurity.providers.UsernamePasswordAuthenticationTo ROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_addNotifier, ROLE_addProject, ROLE_admin, ROLE_user, ROLE_deleteBuildDefinition n, ROLE_manageSchedule, ROLE_manageUsers; Password: [PROTECTED]; Authenticated: true; Details: [EMAIL PROTECTED]: RemoteIpAddress: 127.0.0.1; SessionId: 7dsaf0ensj5ok; Gran Definition, ROLE_deleteNotifier, ROLE_editBuildDefinition, ROLE_editNotifier, ROLE_manageConfiguration, ROLE_manageSchedule, ROLE_manageUsers 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - GrantedAuthority: ROLE_admin matches recipient: ROLE_admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Principal (from UserDetails) matches AclEntry recipient: admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Returning effective AclEntry array with 2 elements 2006-09-11 15:01:29,687 [btpool0-4] INFO Action:buildResults- checking the continuum configuration 2006-09-11 15:01:29,953 [btpool0-4] WARN SQL- Object with id 0 not found ! 2006-09-11 15:01:29,953 [btpool0-4] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: No such object. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:2301) at org.apache.maven.continuum.DefaultContinuum.getBuildResultsForProject(DefaultContinuum.java:2261) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject_aroundBody68(AcegiContinuum.java:269) at org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure69.run(AcegiContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject(AcegiContinuum.java:1) at org.apache.maven.continuum.web.action.BuildResultsListAction.execute(BuildResultsListAction.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
[jira] Closed: (MDEP-16) Dependency plugin support for time check on artifacts
[ http://jira.codehaus.org/browse/MDEP-16?page=all ] Brian Fox closed MDEP-16. - Resolution: Fixed Fix Version/s: 2.0-ALPHA1 Added to new refactored filters. The timestamp check is now the default option but overWriteReleases and overWriteSnapshots are still available to override the timestamp check. Dependency plugin support for time check on artifacts - Key: MDEP-16 URL: http://jira.codehaus.org/browse/MDEP-16 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Shash Chatterjee Assigned To: Brian Fox Fix For: 2.0-ALPHA1 Attachments: dependency-timecheck-patch.txt When one or more dependent JARs are rebuilt, they are not being expanded. It is an either/or choice right now, to either overwrite for all JARs, or to delete the marker dir. Instead of checking if the marker exists, I tried a small change in DependencyUtils to check if the artifact is newer than the marker. This works great. Works for the copy mojo as well. A patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-26) New goal to write classpath string with all dependencies from local repo
[ http://jira.codehaus.org/browse/MDEP-26?page=comments#action_74533 ]
Brian Fox commented on MDEP-26:
---
This is still the correct project for the plugin. This is an interesting idea
and I can see how it would be usefull. Once everything else is in order, I will
look into adding this goal. It may have to wait past a few alpha releases.
New goal to write classpath string with all dependencies from local repo
Key: MDEP-26
URL: http://jira.codehaus.org/browse/MDEP-26
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 1.0
Reporter: Anagnostopoulos Kostis
Priority: Minor
Hi to all,
'm wondering whether it would be usefull to make a new mojo that when
executed it will output a text file containing the required classpath string
to run a project directly from the local repository.
For instance, the file would contain a classpath string like that :
{noformat}
/home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/
{noformat}
The result file could then be used like that:
{noformat}
java -cp `cat resultFile` MyClass
{noformat}
The new goal should maybe a sub-class of AbstractFromDependenciesMojo.
In that case, the useSubDirectoryPerType and useSubDirectoryPerArtifact
params should move to (copy/unpack)-dependencies mojo classes. Anyway, these
params are only used by sub-classes, so, their definition should be propably
inside of those.
Next are the parameters of the mojo i propose:
goal name: dependency:printClasspath
params:
|| Param Name || Type || Description
| outputFile| File | The file to write the classpath string into.
|
| overwrite | boolean| If true, re-write file even when nothing has
changed. |
| includeTypes | String | Comma Separated list of Types to include. |
| excludeTypes | String | Comma Separated list of Types to exclude |
| includeProjectArtifact| boolean | see [this
issue|http://jira.codehaus.org/browse/MDEP-25]. |
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-160) The next snapshot version is not used un submodules
The next snapshot version is not used un submodules --- Key: MRELEASE-160 URL: http://jira.codehaus.org/browse/MRELEASE-160 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Joerg Schaible In multi-module mode the release plugin replaces the version of snapshot dependencies in the submodules automatically for dependencies that are also part of the release. But this versions are not set to the next version after the release process. E.g. in a module with two submodules (one EJB and an EAR depedning on this EJB) the EJB depednency is added with a SNAPSHOT depednecny. At release time the plugin replaces this version with the version used for the release. After the release the version tag in the parent section of both POMs are set to the next version, but the verison in the EARs depednency stays at the release. This is higly error-prone, since with the next release the EAR still references the old version of the EJB. -- 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-853) Edit user info page errors
[ http://jira.codehaus.org/browse/CONTINUUM-853?page=comments#action_74468 ] Lester Ecarma commented on CONTINUUM-853: - I can't replicate most of the issues being described here. Instead, I've found other issues that aren't exactly the same as the ones above. - An extra user with empty username and password is added by default. This causes an error when trying to edit/delete that user (i.e., NPE in EditUserAction as described above). - In 'Edit user info' page the roles of the current user is not being retreived, resulting in a blank roles list. The roles, however, are being retrieved correctly when accessed via Users edit. - In Users edit Save, user is redirected to a blank page (i.e., user/saveAccount.action). - The Users menu item is hidden to a user with manageUser ONLY role. The weird thing is that it is visible when accompanied by other Administration roles (e.g., manageSchedule or manageConfiguration). - When in Users edit page, the 'Edit user info' menu link shows the username of the user being edited. Edit user info page errors -- Key: CONTINUUM-853 URL: http://jira.codehaus.org/browse/CONTINUUM-853 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: continuu-acegi branch Reporter: Carlos Sanchez Assigned To: Lester Ecarma Fix For: 1.1 When clicking on Edit user info menu link: The user name box is empty Null pointer exception trying to save the user because in line 131 user = userManager.getUser( username ); the returned value is null In fact this should call userManager.getMyUser() to prevent people playing with fields and impersonating another user -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1122) Upload Xerces xmlParserAPIs version 2.8.0 (lasted is 2.6.2)
Upload Xerces xmlParserAPIs version 2.8.0 (lasted is 2.6.2) --- Key: MAVENUPLOAD-1122 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1122 Project: maven-upload-requests Issue Type: Task Reporter: Jimisola Laursen For some reason xmlParserAPIs version 2.8.0 is not available in the central repo (2.6.2 is latest). xercesImpl 2.8.0 exists however. See: http://mvnrepository.com/artifact/xerces/xmlParserAPIs http://mvnrepository.com/artifact/xerces/xercesImpl -- 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-862) Hide links for project group operations based on users permissions
[ http://jira.codehaus.org/browse/CONTINUUM-862?page=all ] Carlos Sanchez updated CONTINUUM-862: - Fix Version/s: 1.1 Hide links for project group operations based on users permissions -- Key: CONTINUUM-862 URL: http://jira.codehaus.org/browse/CONTINUUM-862 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Fix For: 1.1 Permissions tab should only be visible to users with admin permission over the group Edit group, build group, ... links should be hidden -- 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: (MPLUGIN-22) Allow specification of mojo extractors to be used
[ http://jira.codehaus.org/browse/MPLUGIN-22?page=all ] Jochen Kuhnle updated MPLUGIN-22: - Attachment: MPLUGIN-22-maven-plugin-plugin.patch Updated patch. Older one is obsolete. Allow specification of mojo extractors to be used - Key: MPLUGIN-22 URL: http://jira.codehaus.org/browse/MPLUGIN-22 Project: Maven 2.x Plugin Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Jochen Kuhnle Fix For: 2.2 Attachments: MPLUGIN-22-maven-plugin-plugin.patch, MPLUGIN-22-maven-plugin-plugin.patch, MPLUGIN-22-maven-plugin-tools-api.patch, MPLUGIN-22-maven-plugin-tools-api.patch With the attached patch, plugin plugin configuration is extended with a section extractors. This allows the user to specify which descripters are to be used in the project. The main reason for this patch are the JDK 1.5 problems with the Java extractor, which can be turned off with this patch. Also, there are projects that provide an extractor that uses Java 5 annotations [1], so there may be two kinds of extractors for the same language in the future. With this, the user should decide which one to use. The patch changes maven-plugin-plugin and maven-tools-api. It does not change the default behaviour (use all extractors). Unit tests are included. Example: plugin artifactIdmaven-plugin-plugin/artifactId version2.2-SNAPSHOT/version configuration !-- Use all extractors -- extractors/ !-- Use no extractors -- extractors extractor/ /extractors !-- Use only bsh extractor -- extractors extractorbsh/extractor /extractors /configuration /plugin [1] http://sourceforge.net/projects/mvn-anno-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
[jira] Updated: (MPLUGIN-22) Allow specification of mojo extractors to be used
[ http://jira.codehaus.org/browse/MPLUGIN-22?page=all ] Jochen Kuhnle updated MPLUGIN-22: - Attachment: MPLUGIN-22-maven-plugin-tools-api.patch Updated patch. Older one is obsolete. Allow specification of mojo extractors to be used - Key: MPLUGIN-22 URL: http://jira.codehaus.org/browse/MPLUGIN-22 Project: Maven 2.x Plugin Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Jochen Kuhnle Fix For: 2.2 Attachments: MPLUGIN-22-maven-plugin-plugin.patch, MPLUGIN-22-maven-plugin-plugin.patch, MPLUGIN-22-maven-plugin-tools-api.patch, MPLUGIN-22-maven-plugin-tools-api.patch With the attached patch, plugin plugin configuration is extended with a section extractors. This allows the user to specify which descripters are to be used in the project. The main reason for this patch are the JDK 1.5 problems with the Java extractor, which can be turned off with this patch. Also, there are projects that provide an extractor that uses Java 5 annotations [1], so there may be two kinds of extractors for the same language in the future. With this, the user should decide which one to use. The patch changes maven-plugin-plugin and maven-tools-api. It does not change the default behaviour (use all extractors). Unit tests are included. Example: plugin artifactIdmaven-plugin-plugin/artifactId version2.2-SNAPSHOT/version configuration !-- Use all extractors -- extractors/ !-- Use no extractors -- extractors extractor/ /extractors !-- Use only bsh extractor -- extractors extractorbsh/extractor /extractors /configuration /plugin [1] http://sourceforge.net/projects/mvn-anno-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
[jira] Updated: (MECLIPSE-139) Eclipse plugin cannot handle Java source files in resource directories
[ http://jira.codehaus.org/browse/MECLIPSE-139?page=all ] Jochen Kuhnle updated MECLIPSE-139: --- Attachment: MECLIPSE-139-java-resources.patch Updated patch. Older one is obsolete. Eclipse plugin cannot handle Java source files in resource directories -- Key: MECLIPSE-139 URL: http://jira.codehaus.org/browse/MECLIPSE-139 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Jochen Kuhnle Fix For: 2.3 Attachments: MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch The eclipse plugin cannot handle Java source files in resource directories: The resulting Eclipse configuration compiles the Java files, so the target directory contains the class files, but not the java sources. This is often troublesome in unit tests or when you need to use code templates, because you often get compile errors in the Workbench. The attached plugin allows to handle this situation in the following ways: 1. Default behavior: Work just as the plugin did before 2. Exclude Java files from resource dirs 3. Use an Ant builder to copy Java sources As a sideeffect, the patch also extends the handling of custom builders: Instead of just specifying a name, you can also specify the triggers and arguments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-139) Eclipse plugin cannot handle Java source files in resource directories
[ http://jira.codehaus.org/browse/MECLIPSE-139?page=comments#action_74497 ]
Jochen Kuhnle commented on MECLIPSE-139:
This last patch also adds parameter forcePomProjects (expression
${eclipse.forcepomprojects}, default false).
This parameter forces the creation of .project files for pom projects, even if
no other workspace location is specified.
This is useful when using a flat directory layout where pom projects have their
own directory and no subdirs, e.g:
project
+--rootproject/pom.xml
+--module1/pom.xml
+--module2/pom.xml
Eclipse plugin cannot handle Java source files in resource directories
--
Key: MECLIPSE-139
URL: http://jira.codehaus.org/browse/MECLIPSE-139
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Jochen Kuhnle
Fix For: 2.3
Attachments: MECLIPSE-139-java-resources.patch,
MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch
The eclipse plugin cannot handle Java source files in resource directories:
The resulting Eclipse configuration compiles the Java files, so the target
directory contains the class files, but not the java sources.
This is often troublesome in unit tests or when you need to use code
templates, because you often get compile errors in the Workbench. The
attached plugin allows to handle this situation in the following ways:
1. Default behavior: Work just as the plugin did before
2. Exclude Java files from resource dirs
3. Use an Ant builder to copy Java sources
As a sideeffect, the patch also extends the handling of custom builders:
Instead of just specifying a name, you can also specify the triggers and
arguments.
--
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: (MNG-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=all ] Ralph Goers updated MNG-1577: - Attachment: mng1577.patch Attached is a patch that addresses this issue. Without doing anything maven will behave as it currently does. However, adding overridetrue/override to the dependencyManagement section will cause the dependencyManagement section to be propogated to each child project and the versions in the dependencyManagement entries will override any versions specified in subprojects. This patch applies to 2.0.x at revision 442440. dependencyManagement does not work for transitive dependencies -- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.1 Attachments: mng1577.patch The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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-863) Error clicking on project build results
[ http://jira.codehaus.org/browse/CONTINUUM-863?page=comments#action_74537 ] Carlos Sanchez commented on CONTINUUM-863: -- projectgroup/members list has broken links in the name of the project and the remove link. I dont know if the functionality to remove is in place so we may need to remove the link for now projectgroup/build definitions clicking on add shows white page in projectGroupSummary, clicking on remove shows the confirmation message, but the name of the project is not displayed Error clicking on project build results --- Key: CONTINUUM-863 URL: http://jira.codehaus.org/browse/CONTINUUM-863 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: David Schwartz Assigned To: Lester Ecarma Priority: Blocker Fix For: 1.1 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit - ...1 (1)] log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Parent lookup: org.acegisecurity.acl.basic.NamedEntityObjectIdentity[Classname: org.apache.maven.continuum.model.project.ProjectGroup; log4j:ERROR Attempted to append to closed appender named [default]. 2006-09-11 15:01:27,562 [btpool0-4] DEBUG BasicAclProvider - Added parent to map: org.apache.maven.user.acegi.acl.basic.ExtendedSimpleAclEntry[org.acegisecurity.acl.basic.NamedEntityObjectIdentit =A ...1 (1)] 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Locating AclEntry[]s (from set of 3) that apply to Authentication: org.acegisecurity.providers.UsernamePasswordAuthenticationTo ROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_addNotifier, ROLE_addProject, ROLE_admin, ROLE_user, ROLE_deleteBuildDefinition n, ROLE_manageSchedule, ROLE_manageUsers; Password: [PROTECTED]; Authenticated: true; Details: [EMAIL PROTECTED]: RemoteIpAddress: 127.0.0.1; SessionId: 7dsaf0ensj5ok; Gran Definition, ROLE_deleteNotifier, ROLE_editBuildDefinition, ROLE_editNotifier, ROLE_manageConfiguration, ROLE_manageSchedule, ROLE_manageUsers 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - GrantedAuthority: ROLE_admin matches recipient: ROLE_admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Principal (from UserDetails) matches AclEntry recipient: admin 2006-09-11 15:01:27,562 [btpool0-4] DEBUG GrantedAuthorityEffectiveAclsResolver - Returning effective AclEntry array with 2 elements 2006-09-11 15:01:29,687 [btpool0-4] INFO Action:buildResults- checking the continuum configuration 2006-09-11 15:01:29,953 [btpool0-4] WARN SQL- Object with id 0 not found ! 2006-09-11 15:01:29,953 [btpool0-4] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: No such object. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:2301) at org.apache.maven.continuum.DefaultContinuum.getBuildResultsForProject(DefaultContinuum.java:2261) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject_aroundBody68(AcegiContinuum.java:269) at org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure69.run(AcegiContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.security.acegi.AcegiContinuum.getBuildResultsForProject(AcegiContinuum.java:1) at
[jira] Created: (CONTINUUM-864) Adding a project with a name that already exist causes internal error
Adding a project with a name that already exist causes internal error - Key: CONTINUUM-864 URL: http://jira.codehaus.org/browse/CONTINUUM-864 Project: Continuum Issue Type: Bug Components: Core system, Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez Priority: Minor When adding an ant project with same name as another ant project added before 2006-09-11 22:38:22,375 [http-8080-Processor24] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: A project with the name 'kk' already exist. at org.apache.maven.continuum.core.action.ValidateProject.execute(ValidateProject.java:54) at org.apache.maven.continuum.DefaultContinuum.executeAction(DefaultContinuum.java:2276) at org.apache.maven.continuum.DefaultContinuum.executeAddProjectFromScmActivity(DefaultContinuum.java:949) at org.apache.maven.continuum.DefaultContinuum.addProject(DefaultContinuum.java:920) at org.apache.maven.continuum.security.acegi.AcegiContinuum.addProject_aroundBody20(AcegiContinuum.java:129) at org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure21.run(AcegiContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.security.acegi.AcegiContinuum.addProject(AcegiContinuum.java:1) at org.apache.maven.continuum.web.action.AddProjectAction.execute(AddProjectAction.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at
[jira] Created: (MPMD-40) deploy the pmd.xml with site:deploy
deploy the pmd.xml with site:deploy --- Key: MPMD-40 URL: http://jira.codehaus.org/browse/MPMD-40 Project: Maven 2.x Pmd Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Stephan Heilner Priority: Minor Fix For: 2.2 It would be extremely useful if the pmx.xml file is deployed along with the pmd.html file when you run a mvn site or mvn site:deploy. I'm trying to write a internal report based on the results from my continuous build system (cruisecontrol). Instead of screen-scraping that html, if that xml version was deployed too, I could digest that create my report. -- 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-2486) disallow use of ${project.version} in dependency versions
[ http://jira.codehaus.org/browse/MNG-2486?page=comments#action_74500 ]
Brian Fox commented on MNG-2486:
doht. I got burned on this one. Isn't it possible when a pom is deployed to
resolve the property to the actual version? Then it would be safe to use the
${project.version} in dependencies.
disallow use of ${project.version} in dependency versions
-
Key: MNG-2486
URL: http://jira.codehaus.org/browse/MNG-2486
Project: Maven 2
Issue Type: Improvement
Components: POM, Inheritence and Interpolation, Dependencies
Affects Versions: 2.0.4
Reporter: John Casey
Priority: Critical
when projects specify dependencyManagement sections with a shorthand version
notation using the current project version (using ${project.version}) the
version resolved will be that of the POM in which the dependencyManagement
section is specified. If this POM is a snapshot, these dependency
specifications will get the timestamp/buildnumber of that POM, instead of the
actual one used when the dependency it references gets deployed.
We should look at strategies for limiting or eliminating this practice, or
else (somehow) pulling the real timestamp/buildnumber for that artifact from
the reactor...in order to make these deps transitively resolvable for users.
--
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-230) mercurial plugin
mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- 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
