[jira] Commented: (MSUREFIRE-158) Add Parameter that the output of the test to System.out only appears in the surefire logfiles
[ http://jira.codehaus.org/browse/MSUREFIRE-158?page=comments#action_72235 ] Fabian Bauschulte commented on MSUREFIRE-158: - Selecting the version was a mistake - I meant to leave it unassigned because it is a new feature. Sorry for that. > Add Parameter that the output of the test to System.out only appears in the > surefire logfiles > - > > Key: MSUREFIRE-158 > URL: http://jira.codehaus.org/browse/MSUREFIRE-158 > Project: Maven 2.x Surefire Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Fabian Bauschulte > > Many Tests are using a logger that prints to the console. Sometimes you > cannot see the summary because there a lot of logging messages. It would be > very helpful to have a parameter, that this output only appears in the > surefire log files. If a test fails, you have the output in the place you > need it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] Bernd updated SUREFIRE-31: -- Attachment: SUREFIRE-31-maven-surefire-plugin.patch As a first step, this makes the maven surfire plugin use JUnit4DirectoryTestSuite if junit4 is available. JUnit4DirectoryTestSuite will not support mavens pojo approach anymore as this conflict with junit4 tests. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-778) show internal error page on unhandled exceptions
[ http://jira.codehaus.org/browse/CONTINUUM-778?page=comments#action_72240 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-778: --- I think I'd still go for chaining, knowing that http://jira.opensymphony.com/browse/WW-731 has been reported. I hope it gets done soon (but it doesn't matter if it doesn't). We could configure exception handling better by chaining subclasses of ContinuumException to specific actions, which may in turn implement the necessary checking of levels of details. For the meantime, I submitted an ExceptionLoggingInterceptor to serve our purpose. IMHO, using an interceptor would reduce the refactoring needed than if a base class were to be used. I'd be glad to discuss on this further. :) > show internal error page on unhandled exceptions > > > Key: CONTINUUM-778 > URL: http://jira.codehaus.org/browse/CONTINUUM-778 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-778.patch, error-mapping.patch > > > It's possible to setup a servlet filter or something similar that maybe > webwork already has (Struts has it) to catch all unhandled exceptions, log > them to the log file and redirect the user to a "internal error" page. > Related to this we should make ContinuumException a RuntimeException, don't > catch it in the web layer and let the previous mechanism do it. We'll save a > lot of exception handling code not needed. > Note that this is only for system exceptions, eg. if database is down, and > not model exceptions, eg. when looking up by id it the record doesn't exist. -- 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-778) show internal error page on unhandled exceptions
[ http://jira.codehaus.org/browse/CONTINUUM-778?page=all ] Napoleon Esmundo C. Ramirez updated CONTINUUM-778: -- Attachment: CONTINUUM-778-2.patch CONTINUUM-778-2.patch provides the support for chained exception handling. Chaining the exceptions to actions will enable the checking of levels of details to show to the resulting page. The ExceptionLoggingInterceptor would have to deal with server logs in the meantime. > show internal error page on unhandled exceptions > > > Key: CONTINUUM-778 > URL: http://jira.codehaus.org/browse/CONTINUUM-778 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-778-2.patch, CONTINUUM-778.patch, > error-mapping.patch > > > It's possible to setup a servlet filter or something similar that maybe > webwork already has (Struts has it) to catch all unhandled exceptions, log > them to the log file and redirect the user to a "internal error" page. > Related to this we should make ContinuumException a RuntimeException, don't > catch it in the web layer and let the previous mechanism do it. We'll save a > lot of exception handling code not needed. > Note that this is only for system exceptions, eg. if database is down, and > not model exceptions, eg. when looking up by id it the record doesn't exist. -- 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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=comments#action_72242 ]
Maurice le Rutte commented on MPCHECKSTYLE-20:
--
I have the same problem, but with a single, FQN'ed exception. Works fine in
Eclipse 3.2 with plugin, but fails in Ant.
[checkstyle] Running Checkstyle 4.2 on 11 files
[checkstyle]
H:\projects\attic-cards\src\main\com\cuhka\attic\renderer\RendererFactory.java:0:
Got an exception - java.lang.RuntimeException: Unable to get class information
for @throws tag 'com.cuhka.attic.renderer.RendererFactoryException'.
Code:
/**
* Get the renderer for a figure.
*
* @param figureClass figure class to get renderer for
* @return renderer class
* @throws com.cuhka.attic.renderer.RendererFactoryException on error
*/
@SuppressWarnings("unchecked")
public synchronized FigureRenderer getRenderer(Class
figureClass)
throws com.cuhka.attic.renderer.RendererFactoryException {
}
> Unable to get class information for custom exceptions
> -
>
> Key: MPCHECKSTYLE-20
> URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20
> Project: maven-checkstyle-plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: maven-1.0-rc2
>Reporter: Ryan Sonnek
>
> checkstyle reports an error "Unable to get class information" for custom
> exceptions within the same project. it is able to load exceptions that are
> listed as dependencies for the project, but not for other exceptions. one
> workaround is to only use throws Exception in the signiture, but that's
> really a hack.
--
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-2406) Add @since javadoc tags to plugin parameters
[ http://jira.codehaus.org/browse/MNG-2406?page=comments#action_72244 ] Dennis Lundberg commented on MNG-2406: -- I have a couple of questions about this issue: 1. Shouldn't "since" be added to the plugin metadata model as well? I'm not sure what the model is used for, but it seems to include most of the other things. 2. Is there a special reason for not putting this in the 2.0.x branch? Just because it's a new feature? The reason I'm asking is because I wanted to try to fix MNG-2454, and I want to do it the correct way. > Add @since javadoc tags to plugin parameters > > > Key: MNG-2406 > URL: http://jira.codehaus.org/browse/MNG-2406 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 2.0.4 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Fix For: 2.1 > > Attachments: MNG-2406-maven-plugin-descriptor.patch, > MNG-2406-maven-plugin-tools-api.patch, > MNG-2406-maven-plugin-tools-java.patch, MNG-2406-maven-plugin-tools-java.patch > > Original Estimate: 4 hours > Time Spent: 1 hour, 30 minutes > Remaining Estimate: 0 minutes > > also, update the plugin report and add a separate column for this tag -- 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: (WAGON-60) wagon-webdav fails with commons-logging classloader issues
[ http://jira.codehaus.org/browse/WAGON-60?page=comments#action_72245 ] Carlos Sanchez commented on WAGON-60: - I've be using wagon-webdav as build extension without problems. > wagon-webdav fails with commons-logging classloader issues > -- > > Key: WAGON-60 > URL: http://jira.codehaus.org/browse/WAGON-60 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-1 > Environment: maven 2.0.4 >Reporter: Yuri Schimke >Priority: Critical > > I tried it with a build extension and also putting jars in $M2_HOME/lib, but > both ways I get classloader issues with commons-logging. > My project uses commons logging and I've seen at least one other report that > it can be a problem. > with things in lib: > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.)) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) > at > org.apache.commons.httpclient.HttpClient.(HttpClient.java:69) > ... 30 more > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) > ... 34 more > Caused by: org.apache.commons.logging.LogConfigurationException: Invalid > class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385) > using build extension: > java.lang.ExceptionInInitializerError > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145) > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127) > at > org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408) > at > org.apache.webdav.lib.WebdavResource.(WebdavResource.java:290) > at > org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.(CorrectedWebdavResource.java:52) > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.openConnection(WebDavWagon.java:139) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:132) > 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.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultL
[jira] Commented: (MAVENUPLOAD-1040) remove unused folder "not-really-jelly/commons-jelly/"
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1040?page=comments#action_72248 ] Rainer Wasserfuhr commented on MAVENUPLOAD-1040: ok, now it's gone. Thx :) > remove unused folder "not-really-jelly/commons-jelly/" > -- > > Key: MAVENUPLOAD-1040 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1040 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Rainer Wasserfuhr > Assigned To: Carlos Sanchez > > http://www.ibiblio.org/maven2/not-really-jelly/commons-jelly/ is empty, > so both > http://www.ibiblio.org/maven2/not-really-jelly/commons-jelly/ and > http://www.ibiblio.org/maven2/not-really-jelly > could be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-60) wagon-webdav fails with commons-logging classloader issues
[ http://jira.codehaus.org/browse/WAGON-60?page=comments#action_72249 ] Yuri Schimke commented on WAGON-60: --- I'm assuming its because there are two copies of commons-logging loaded by different extensions or plugins. Is there somewhere I can put the commons-logging jars so they don't get loaded by extension, plugin or reportingPlugin classloaders that conflict. > wagon-webdav fails with commons-logging classloader issues > -- > > Key: WAGON-60 > URL: http://jira.codehaus.org/browse/WAGON-60 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-1 > Environment: maven 2.0.4 >Reporter: Yuri Schimke >Priority: Critical > > I tried it with a build extension and also putting jars in $M2_HOME/lib, but > both ways I get classloader issues with commons-logging. > My project uses commons logging and I've seen at least one other report that > it can be a problem. > with things in lib: > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.)) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) > at > org.apache.commons.httpclient.HttpClient.(HttpClient.java:69) > ... 30 more > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) > ... 34 more > Caused by: org.apache.commons.logging.LogConfigurationException: Invalid > class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385) > using build extension: > java.lang.ExceptionInInitializerError > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145) > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127) > at > org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408) > at > org.apache.webdav.lib.WebdavResource.(WebdavResource.java:290) > at > org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.(CorrectedWebdavResource.java:52) > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.openConnection(WebDavWagon.java:139) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:132) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
[jira] Created: (MAVENUPLOAD-1045) pom.xml~ in plexus/plexus-mail-senders
pom.xml~ in plexus/plexus-mail-senders -- Key: MAVENUPLOAD-1045 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1045 Project: maven-upload-requests Issue Type: Wish Reporter: Rainer Wasserfuhr see: http://ibiblio.org/maven2/plexus/plexus-mail-senders/1.0/plexus-mail-senders-1.0.pom~ http://ibiblio.org/maven2/plexus/plexus-mail-sender/1.0/plexus-mail-senders-1.0.pom~ http://ibiblio.org/maven2/plexus/plexus-mail-sender/1.0/plexus-mail-sender-1.0.pom~ -- 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-1046) pom~ in org/apache/maven/wagon/wagon/
pom~ in org/apache/maven/wagon/wagon/ - Key: MAVENUPLOAD-1046 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1046 Project: maven-upload-requests Issue Type: Wish Reporter: Rainer Wasserfuhr see http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.md5 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.asc http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~ http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.sha1 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.md5 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.asc http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~ -- 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-1046) pom~ in org/apache/maven/wagon/wagon/
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1046?page=comments#action_72250 ] Carlos Sanchez commented on MAVENUPLOAD-1046: - Please stop creating issues for these, we'll search for files with ~ and delete them > pom~ in org/apache/maven/wagon/wagon/ > - > > Key: MAVENUPLOAD-1046 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1046 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Rainer Wasserfuhr > > see > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.md5 > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.asc > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~ > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.sha1 > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.md5 > > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.asc > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~ > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-18) complete commands and expose through ScmManager
[ http://jira.codehaus.org/browse/SCM-18?page=comments#action_72251 ] Mike Perham commented on SCM-18: I've found that when you enter a broad, open-ended type of issue like this, it tends to be pushed off version after version. I suggest closing this issue and in the future, open specific issues per provider. > complete commands and expose through ScmManager > --- > > Key: SCM-18 > URL: http://jira.codehaus.org/browse/SCM-18 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-cvs, maven-scm-provider-svn, > maven-scm-provider-local, maven-scm-provider-clearcase, > maven-scm-provider-perforce, maven-scm-provider-starteam, maven-scm-api >Reporter: Brett Porter > Fix For: 1.0.1 > > > many commands are not completely implemented, or not implemented at all, and > some that are have not been exposed through the ScmManager interface. > These all need to be rounded out and tested via the TCK for a final 1.0 > release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-17) test structure needs further clean up
[ http://jira.codehaus.org/browse/SCM-17?page=comments#action_72252 ] Mike Perham commented on SCM-17: I've found that when you enter a broad, open-ended type of issue like this, it tends to be pushed off version after version. I suggest closing this issue and in the future, open specific issues per provider. > test structure needs further clean up > - > > Key: SCM-17 > URL: http://jira.codehaus.org/browse/SCM-17 > Project: Maven SCM > Issue Type: Test > Components: maven-scm-provider-cvs, maven-scm-provider-svn, > maven-scm-provider-local, maven-scm-provider-clearcase, > maven-scm-provider-perforce, maven-scm-provider-starteam >Reporter: Brett Porter > Fix For: 1.0.1 > > > The following is needed: > - all providers need to utilise the TCK where possible. > - any tests in providers that can be generalised should be moved to the TCK > - other tests in the providers should just test provider specific functions, > and probably not be integration tests like the TCK is > - need further tests for other commands, including those yet to be added > - review coverage for each provider -- 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-1046) pom~ in org/apache/maven/wagon/wagon/
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1046?page=comments#action_72253 ] Rainer Wasserfuhr commented on MAVENUPLOAD-1046: that's what I did. Except MAVENUPLOAD-1045 there shouldnd be any other pom~'s :) > pom~ in org/apache/maven/wagon/wagon/ > - > > Key: MAVENUPLOAD-1046 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1046 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Rainer Wasserfuhr > > see > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.md5 > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.asc > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~ > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.sha1 > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.md5 > > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.asc > http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~ > -- 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: (MNGECLIPSE-149) Preferences->Maven2 fails
[ http://jira.codehaus.org/browse/MNGECLIPSE-149?page=all ] * updated MNGECLIPSE-149: - Attachment: .log Eclipse Callisto + W2K > Preferences->Maven2 fails > - > > Key: MNGECLIPSE-149 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-149 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 > Environment: Eclipse 3.2, JVM 1.5.0_06, XPsp2 >Reporter: George Lindholm > Attachments: .log > > > Trying to invoke Maven2 preferences gives me: > Unable to create the selected preference page > Reason: >Plug-in org.maven.ide.eclipse was unable to load class >org.maven.ide.eclipse.preferences.Maven2PreferencePage -- 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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_72256 ] Ralph Goers commented on MNG-1577: -- Cocoon now has an issue at http://issues.apache.org/jira/browse/COCOON-1890 which is a hack to try to deal with this issue. This is getting out of hand. > 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 > > > 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] Closed: (CONTINUUM-778) show internal error page on unhandled exceptions
[ http://jira.codehaus.org/browse/CONTINUUM-778?page=all ] Carlos Sanchez closed CONTINUUM-778. Assignee: Carlos Sanchez (was: Napoleon Esmundo C. Ramirez) Resolution: Fixed Applied the patch with changes: - no need to redirect to an action on error, in fact it can cause infinite loop if the error is in webwork - no need to separate two types of exceptions, at least for now - use already existing error.jsp - moved the exception logger interceptor to plexus-xwork integration as it can be used elsewhere - files without license header > show internal error page on unhandled exceptions > > > Key: CONTINUUM-778 > URL: http://jira.codehaus.org/browse/CONTINUUM-778 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-778-2.patch, CONTINUUM-778.patch, > error-mapping.patch > > > It's possible to setup a servlet filter or something similar that maybe > webwork already has (Struts has it) to catch all unhandled exceptions, log > them to the log file and redirect the user to a "internal error" page. > Related to this we should make ContinuumException a RuntimeException, don't > catch it in the web layer and let the previous mechanism do it. We'll save a > lot of exception handling code not needed. > Note that this is only for system exceptions, eg. if database is down, and > not model exceptions, eg. when looking up by id it the record doesn't exist. -- 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-779) Creation of AbstractActionLogger that extends ActionSupport and implements LogEnabled
[ http://jira.codehaus.org/browse/CONTINUUM-779?page=all ] Carlos Sanchez closed CONTINUUM-779. Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 1.1 Made actions throw exceptions not handled to be intercepted later by webwork interceptors > Creation of AbstractActionLogger that extends ActionSupport and implements > LogEnabled > - > > Key: CONTINUUM-779 > URL: http://jira.codehaus.org/browse/CONTINUUM-779 > Project: Continuum > Issue Type: Sub-task >Reporter: Teodoro Cue Jr. > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-779-continuum-webapp.patch, CONTINUUM-779.patch > > > A class that will be use by all actions. This is to eliminate code repetition > when actions implements the LogEnabled interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-17) test structure needs further clean up
[ http://jira.codehaus.org/browse/SCM-17?page=comments#action_72260 ] Brett Porter commented on SCM-17: - I didn't notice the version change. The idea was that I felt this was a prerequisite for a 1.0 release. > test structure needs further clean up > - > > Key: SCM-17 > URL: http://jira.codehaus.org/browse/SCM-17 > Project: Maven SCM > Issue Type: Test > Components: maven-scm-provider-cvs, maven-scm-provider-svn, > maven-scm-provider-local, maven-scm-provider-clearcase, > maven-scm-provider-perforce, maven-scm-provider-starteam >Reporter: Brett Porter > Fix For: 1.0.1 > > > The following is needed: > - all providers need to utilise the TCK where possible. > - any tests in providers that can be generalised should be moved to the TCK > - other tests in the providers should just test provider specific functions, > and probably not be integration tests like the TCK is > - need further tests for other commands, including those yet to be added > - review coverage for each provider -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-18) complete commands and expose through ScmManager
[ http://jira.codehaus.org/browse/SCM-18?page=comments#action_72261 ] Brett Porter commented on SCM-18: - Like SCM-17, I didn't notice the version change. The idea was that I felt this was a prerequisite for a 1.0 release. > complete commands and expose through ScmManager > --- > > Key: SCM-18 > URL: http://jira.codehaus.org/browse/SCM-18 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-cvs, maven-scm-provider-svn, > maven-scm-provider-local, maven-scm-provider-clearcase, > maven-scm-provider-perforce, maven-scm-provider-starteam, maven-scm-api >Reporter: Brett Porter > Fix For: 1.0.1 > > > many commands are not completely implemented, or not implemented at all, and > some that are have not been exposed through the ScmManager interface. > These all need to be rounded out and tested via the TCK for a final 1.0 > release. -- 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-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=comments#action_72262 ] Brett Porter commented on MNG-2454: --- addressing the questions raised here: http://jira.codehaus.org/browse/MNG-2406#action_72244 This was added to the metamodel (see maven-plugin-descriptor/src/main/java/org/apache/maven/plugin/descriptor/Parameter.java), its just that this isn't driven by modello. The same change needs to be made to MojoDescriptor. I agree with porting it to 2.0.5, but believe as it is a feature we should vote for that first, after the work is done on trunk. I did that for MNG-2406 but voting stopped after we realised we needed this too. > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Assigned To: Dennis Lundberg > Fix For: 2.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: (MNG-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=all ] Dennis Lundberg updated MNG-2454: - Attachment: plugin-descriptor.patch Patch for the plugin descriptor. > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Assigned To: Dennis Lundberg > Fix For: 2.1 > > Attachments: plugin-descriptor.patch, plugin-tools.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: (MNG-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=all ] Dennis Lundberg updated MNG-2454: - Attachment: plugin-tools.patch Patch for plugin tools. > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Assigned To: Dennis Lundberg > Fix For: 2.1 > > Attachments: plugin-descriptor.patch, plugin-tools.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=comments#action_72265 ] Dennis Lundberg commented on MNG-2454: -- Yes I saw that the plugin descriptor needs to be updated. But there is also a modello driven thing in maven-plugin-tools-model. That is not the same as the plugin-descriptor, is it? I'm curious about what it is used for. > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Assigned To: Dennis Lundberg > Fix For: 2.1 > > Attachments: plugin-descriptor.patch, plugin-tools.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=comments#action_72266 ] Brett Porter commented on MNG-2454: --- I think that's for ant mojos - John C might know more. > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Assigned To: Dennis Lundberg > Fix For: 2.1 > > Attachments: plugin-descriptor.patch, plugin-tools.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2406) Add @since javadoc tags to plugin parameters
[ http://jira.codehaus.org/browse/MNG-2406?page=comments#action_72267 ] Edwin Punzalan commented on MNG-2406: - Dennis, 1. I agree. It should also appear there for the scripting-based plugins to use it. > Add @since javadoc tags to plugin parameters > > > Key: MNG-2406 > URL: http://jira.codehaus.org/browse/MNG-2406 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 2.0.4 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Fix For: 2.1 > > Attachments: MNG-2406-maven-plugin-descriptor.patch, > MNG-2406-maven-plugin-tools-api.patch, > MNG-2406-maven-plugin-tools-java.patch, MNG-2406-maven-plugin-tools-java.patch > > Original Estimate: 4 hours > Time Spent: 1 hour, 30 minutes > Remaining Estimate: 0 minutes > > also, update the plugin report and add a separate column for this tag -- 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-140) refactor maven-artifact
[ http://jira.codehaus.org/browse/MNG-140?page=comments#action_72269 ] Brett Porter commented on MNG-140: -- the code in the wagon manager might be able to be replaced/integrated with the proxy code in the MRM. The default wagon manager couldn't used there due to the difficulty to change it and some bugs, but it has better testing. > refactor maven-artifact > --- > > Key: MNG-140 > URL: http://jira.codehaus.org/browse/MNG-140 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.1 > > > currently, there are a few inconsistencies in the way the artifact resolution > is implemented. > ArtifactRepository objects are created from the project builder. It makes > more sense that the artifact resolver actually factory these on behalf of the > builder - currently setting any additional parameters on them requires it be > in the project, or that the project builder has knowledge of wagon. > It is also uncertain if the wagon manager is required at all and may be able > to be folded into the artifact resolver. -- 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-1047) Upload Retroweaver 1.2.4
Upload Retroweaver 1.2.4 Key: MAVENUPLOAD-1047 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1047 Project: maven-upload-requests Issue Type: Task Reporter: Xavier Le Vourch Retroweaver is a tool, which converts Java 5 (or 6) compliant class files into Java 1.x compliant class files. The jar file retroweaver.jar contains both the class processor (which may be used at compile time) and the runtime classes. Additionally there is the jar file retroweaver-rt.jar (which contains the runtime classes only). The bundle contains file for both the retroweaver and retroweaver-rt subpackages. -- 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-812) Fix resolution of ${plexus.home}
Fix resolution of ${plexus.home}
Key: CONTINUUM-812
URL: http://jira.codehaus.org/browse/CONTINUUM-812
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1
Reporter: Carlos Sanchez
Continuum creates the DB in a folder called ${plexus.home}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-175) Log message shows wrong port number for site:run
Log message shows wrong port number for site:run
Key: MSITE-175
URL: http://jira.codehaus.org/browse/MSITE-175
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Wendy Smoak
Priority: Trivial
mvn site:run -Dport=8123 works correctly, but the log message still says that
Jetty was started on 8080.
The port number is hard coded in the log message on line 86 of SiteRunMojo:
Index: src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
===
--- src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
(revision 428603)
+++ src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
(working copy)
@@ -83,7 +83,7 @@
handlers[1] = notFoundHandler;
server.setHandlers( handlers );
-getLog().info( "Starting Jetty on http://localhost:8080/"; );
+getLog().info( "Starting Jetty on http://localhost:"; + port + "/" );
try
{
server.start();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-186) Using the wrong command-line option to set the perforce host
[ http://jira.codehaus.org/browse/SCM-186?page=all ] Mike Perham closed SCM-186. --- Resolution: Fixed Fix Version/s: 1.0 > Using the wrong command-line option to set the perforce host > > > Key: SCM-186 > URL: http://jira.codehaus.org/browse/SCM-186 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Reporter: John Didion > Assigned To: Mike Perham >Priority: Critical > Fix For: 1.0 > > > In PerforceScmProvider.createP4Command, you are using -H to set the perforce > host. The option should actually be -p. -H sets the hostname of the client. > Horrible terminology, I agree. > See for info: > http://www.perforce.com/perforce/doc.052/manuals/cmdref/env.P4PORT.html#1040647 -- 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-813) When uploading an uncommitted pom : this is the pom currently on scm which is used
When uploading an uncommitted pom : this is the pom currently on scm which is used --- Key: CONTINUUM-813 URL: http://jira.codehaus.org/browse/CONTINUUM-813 Project: Continuum Issue Type: Bug Components: SCM, Web interface Affects Versions: 1.0.3 Reporter: Simon Lebettre Priority: Trivial - I created a test project, without any scm data in the pom. I commited the pom as is. - then I modified the POM locally to include scm information (I just used a local cvs , no viewcvs installed ) - I deleted my project and re-uploaded the local pom with the correct scm tag ==> continuum replaces the correct uploaded pom by the incorrect pom from cvs, and tells there is no scm metadata in the pom ! - I suggest just adding a mention on the upload page : "warning : the __committed__ pom will be used for the build, not the __uploaded__ pom" -- 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-2203) Problem with duplicates
[ http://jira.codehaus.org/browse/MNG-2203?page=all ] Maria Odea Ching updated MNG-2203: -- Due Date: 15/Aug/06 (was: 14/Aug/06) > Problem with duplicates > --- > > Key: MNG-2203 > URL: http://jira.codehaus.org/browse/MNG-2203 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.1, 2.0.3 > Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1-SNAPSHOT >Reporter: Francesco Tinti > Assigned To: Maria Odea Ching > Fix For: 2.0.5 > > Attachments: pomerr.zip > > Time Spent: 7 hours > Remaining Estimate: 20 hours > > Declare in POM a duplicate group-artifact dependency but with different > versions.: there's no log of duplicate entry. > Maven will also take care only of the latest dependency, so if the version is > ancient of the other, you can obtain (of course) compilation error. > In attachment a simple demonstration with a specific commons-io 1.2 function. -- 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-2203) Problem with duplicates
[ http://jira.codehaus.org/browse/MNG-2203?page=all ] Maria Odea Ching updated MNG-2203: -- Remaining Estimate: 13 hours (was: 20 hours) > Problem with duplicates > --- > > Key: MNG-2203 > URL: http://jira.codehaus.org/browse/MNG-2203 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.1, 2.0.3 > Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1-SNAPSHOT >Reporter: Francesco Tinti > Assigned To: Maria Odea Ching > Fix For: 2.0.5 > > Attachments: pomerr.zip > > Time Spent: 7 hours > Remaining Estimate: 13 hours > > Declare in POM a duplicate group-artifact dependency but with different > versions.: there's no log of duplicate entry. > Maven will also take care only of the latest dependency, so if the version is > ancient of the other, you can obtain (of course) compilation error. > In attachment a simple demonstration with a specific commons-io 1.2 function. -- 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-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Due Date: 22/Aug/06 Remaining Estimate: 1 day, 6 hours Original Estimate: 1 day, 6 hours > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 1 day, 6 hours > Remaining Estimate: 1 day, 6 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: (MPARTIFACT-70) java.lang.IllegalAccessException in artifact:artifact-install
[ http://jira.codehaus.org/browse/MPARTIFACT-70?page=comments#action_72271 ] dion gillard commented on MPARTIFACT-70: Switching my maven_home to the snapshot, all works fine. If i switch my maven_home back to 1.1-beta-3, it fails again, as expected. That's fixed! > java.lang.IllegalAccessException in artifact:artifact-install > - > > Key: MPARTIFACT-70 > URL: http://jira.codehaus.org/browse/MPARTIFACT-70 > Project: maven-artifact-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: dion gillard > Fix For: 1.8.1 > > > I get the following when installing a plugin: > --- Nested Exception --- > java.lang.IllegalAccessException: org/apache/maven/MavenUtils > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:79) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:41) > at java.lang.reflect.Method.invoke(Method.java:386) > at > org.apache.maven.artifact.PomRewriter.getRewrittenModel(PomRewriter.j > ava:85) > at > org.apache.maven.artifact.PomRewriter.getRewrittenPom(PomRewriter.jav > a:50) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleInst > all(DefaultArtifactDeployer.java:165) > From reading > http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/artifact/src/main/org/apache/maven/artifact/PomRewriter.java?view=markup > PomRewriter calls MavenUtils.getNonJellyProject and > MavenUtils.getJellyProject, of which both are declared as private static -- 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: (MNG-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=all ] Baerrach bonDierne reopened MNG-2493: - Unfortunately the codehaus repository is at http://snapshots.repository.codehaus.org. (this is the new location for the codehaus repo after the crash) Will send in another patch. > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Assigned To: Vincent Siveton > Fix For: 2.0.5 > > Attachments: MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=all ] Baerrach bonDierne updated MNG-2493: Attachment: MNG-2493-patch-2.txt Patch contains corrected codehaus location and also includes a repository definition (not just a plugin repo) > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Assigned To: Vincent Siveton > Fix For: 2.0.5 > > Attachments: MNG-2493-patch-2.txt, MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
New patch file working with the latest trunk code base that has created unit
tests and integration tests done by John Casey.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt, Maven
> Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
(patch included another patch which is now removed)
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt,
> MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_72277 ] Wonne Keysers commented on MWAR-9: -- Compile time dependencies can be excluded from the WEB-INF/lib by using the true flag. However, this currently does not work recursively. For example: if the war has a dependency on A.jar, but A.jar itself s dependant from B.jar, putting the A-dependency optional excludes it from the war (yet it includes it in the manifest), but B.jar is still included in the WEB-INF/lib. If the optional flag would be working recursively, I think the solution would be complete? > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mike Perham > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-812) Fix resolution of ${plexus.home}
[ http://jira.codehaus.org/browse/CONTINUUM-812?page=comments#action_72278
]
Emmanuel Venisse commented on CONTINUUM-812:
this parameter must be added in plexus context in plexus-xwork-integration.
I think some other parameters should be added too.
> Fix resolution of ${plexus.home}
>
>
> Key: CONTINUUM-812
> URL: http://jira.codehaus.org/browse/CONTINUUM-812
> Project: Continuum
> Issue Type: Bug
> Components: Database
>Affects Versions: 1.1
>Reporter: Carlos Sanchez
>
> Continuum creates the DB in a folder called ${plexus.home}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
