[jira] Commented: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96821
]
Phil Webb commented on WAGON-73:
Are you sure that this is fixed on the trunk? I believe that the maven eclipse
project was tested with the patch applied. The SVN code does not appear to
have the patch.
Looking at the code I cannot see how the loop in the connect method will return
when the connection is successful (ie when there are no exceptions).
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1284) Per-group editable (selectable) policies for build trigging / dependency mgmgt
Per-group editable (selectable) policies for build trigging / dependency mgmgt -- Key: CONTINUUM-1284 URL: http://jira.codehaus.org/browse/CONTINUUM-1284 Project: Continuum Issue Type: New Feature Components: Project Grouping Affects Versions: 1.1-alpha-1 Reporter: Eirik Maus The groups and trigging of dependent modules are great (and necessary) features for large projects, but I am not so happy with all of the trigging/dependency mechanisms. I think a few different trigging and scm-relative policies should be available, and that these should be selectable in the group setup (radio buttons or something). These are separate jira issues. We have tried continuum alpha-1 in a large organization building software that transfers large amounts of money. We use several groups, each with 15-30 modules, containing a few installable artifacts that must fit together. I have a number of suggestions on improvements that should give faster large-project builds and more precise control over the actual contents of modules with several in-house dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1285) option to make all modules in a group build from the same SCM timestamp
option to make all modules in a group build from the same SCM timestamp --- Key: CONTINUUM-1285 URL: http://jira.codehaus.org/browse/CONTINUUM-1285 Project: Continuum Issue Type: New Feature Components: Core system Affects Versions: 1.1-alpha-1 Reporter: Eirik Maus In order to have better relations between the contents of the SCM and the versions built, the SCM timestamp should be propagated to the triggered dependent modules in a group, so all modules and deployable artifacts are build from checkouts with the same timestamp. This will provide a better control of the actual content of the deployables in environments where commits are frequent. It also provides better tracking of errors, as the developer can checkout the source code with the same timestamp for all affected modules. Ideally, the timestamp appended to the name of the snapshot artifacts should be the same (but this is not that important, since it is only a matter of seconds difference). Probably this should be an per-group selectable option: to choose either this or "build dependent modules always from head-at-time-of-build" (today's policy). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1286) better control with trigging of builds through dependencies
better control with trigging of builds through dependencies --- Key: CONTINUUM-1286 URL: http://jira.codehaus.org/browse/CONTINUUM-1286 Project: Continuum Issue Type: Improvement Components: Core system Affects Versions: 1.1-alpha-1 Reporter: Eirik Maus seems like a build for a dependent module is triggered each time a dependency is built. This seems to cause modules several levels down in the dependency graph to be built many times for the same change in a root module (propagated once for each intermediate dependency relation). A module should not be added to the build queue if it already is in the build queue. Also, if scm timestamps are propagated through the builds (seperate jira issue), it would easily be confirmed that the dependent module already is in the build queue with the same timestamp, and that one build of the module would be sufficient. Today it would be several builds, each from head with a few minutes between, with modules near the end of the dependency chain being built often and against different scm timestamps than the intermediate modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1287) editable build queue
editable build queue Key: CONTINUUM-1287 URL: http://jira.codehaus.org/browse/CONTINUUM-1287 Project: Continuum Issue Type: New Feature Affects Versions: 1.1-alpha-1 Reporter: Eirik Maus It should be possible to interact with the build queue. - to see the order of the modules in queue - to remove entries if you want to cancel the 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] Commented: (CONTINUUM-1197) Continuum aborts when using Oracle database after applying patch in CONTINUUM-961
[ http://jira.codehaus.org/browse/CONTINUUM-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96823 ] cla monsch commented on CONTINUUM-1197: --- you can replace the attribute length="8192" by jdbc-type="CLOB" inside continuum-model-1.1-alpha-1.jar/package.jdo. with continuum-1.0.3 it run in that way. > Continuum aborts when using Oracle database after applying patch in > CONTINUUM-961 > - > > Key: CONTINUUM-1197 > URL: http://jira.codehaus.org/browse/CONTINUUM-1197 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-alpha-1 > Environment: Oracle database 9.2.0.1.0 > Oracle jdbc driver 10.2.0.1.0 >Reporter: thierry lach > Fix For: 1.1-alpha-# > > > I changed the transaction isolation using the patch I just attached to > CONTINUUM-961 and rebuilt, but now I'm coming up with the following error. > I'm running against oracle 9.2.0.1.0 and using the oracle jdbc driver version > 10.2.0.1.0. According to their latest release documentation (release 10g, > http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements001.htm#i54330) > Oracle has a max length for varchar2 of 4000. > jvm 1 | 2007-03-01 14:19:05,953 [main] ERROR RDBMS - Error thrown executing > CREATE TABLE CHANGESET > jvm 1 | ( > jvm 1 | CHANGESET_ID NUMBER NOT NULL, > jvm 1 | AUTHOR VARCHAR2(256) NULL, > jvm 1 | "COMMENT" VARCHAR2(8192) NULL, > jvm 1 | "DATE" NUMBER NOT NULL, > jvm 1 | ID VARCHAR2(256) NULL, > jvm 1 | MODEL_ENCODING VARCHAR2(256) NULL, > jvm 1 | CHANGES_SCMRESULT_ID_OID NUMBER NULL, > jvm 1 | CHANGES_INTEGER_IDX NUMBER(10) NULL > jvm 1 | ) : ORA-00910: specified length too long for its datatype > jvm 1 | > jvm 1 | java.sql.SQLException: ORA-00910: specified length too long for its > datatype > jvm 1 | > jvm 1 | at > oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) > jvm 1 | at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) > jvm 1 | at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) > jvm 1 | at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743) > jvm 1 | at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:207) > jvm 1 | at > oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:946) > jvm 1 | at > oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) > jvm 1 | at > oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1687) > jvm 1 | at > oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1653) > jvm 1 | at > org.jboss.resource.adapter.jdbc.WrappedStatement.execute(WrappedStatement.java:84) > jvm 1 | at > org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614) > jvm 1 | at > org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570) > jvm 1 | at > org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297) > jvm 1 | at > org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341) > jvm 1 | at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052) > jvm 1 | at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313) > jvm 1 | at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554) > jvm 1 | at > org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406) > jvm 1 | at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821) > jvm 1 | at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835) > jvm 1 | at > org.jpox.store.StoreManager.getDatastoreClass(StoreManager.java:1161) > jvm 1 | at org.jpox.store.rdbms.RDBMSManager.getExtent(RDBMSManager.java:1354) > jvm 1 | at > org.jpox.AbstractPersistenceManager.getExtent(AbstractPersistenceManager.java:2324) > jvm 1 | at > org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached(PlexusJdoUtils.java:358) > jvm 1 | at > org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached(PlexusJdoUtils.java:342) > jvm 1 | at > org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:1302) > jvm 1 | at > org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:1287) > jvm 1 | at > org.apache.maven.continuum.store.JdoContinuumStore.getAllProjectsByNameWithBuildDetails(JdoContinuumStore.java:843) > jvm 1 | at > org.apache.maven.continuum.DefaultContinuum.initialize(DefaultContinuum.java:2209) > jvm 1 | at > org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33) > jvm 1 | at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > jvm 1
[jira] Created: (MRM-352) When logging for the very first time as admin, the "add repository" page fails
When logging for the very first time as admin, the "add repository" page fails
--
Key: MRM-352
URL: http://jira.codehaus.org/browse/MRM-352
Project: Archiva
Issue Type: Bug
Components: web application
Affects Versions: 1.0-alpha-1
Reporter: Fabrice BELLINGARD
_[ To reproduce the bug, clean your file system like it would be the first time
you run Archiva (basically, delete the database and the archiva files in .m2) ]_
When you start Archiva for the first time, you have to create an admin user
first, and then you are redirected to the repository configuration page, which
fails with the following stack trace:
{code}
2007-05-23 11:20:32,137 [http-8080-Processor25] INFO
com.opensymphony.xwork.interceptor.Interceptor:configurationInterceptor - No
repositories exist - forwarding to repository configuration page
2007-05-23 11:21:22,200 [http-8080-Processor24] ERROR
com.opensymphony.xwork.util.CompoundRootAccessor - No object in the
CompoundRoot has a publicly accessible property named 'externalResult' (no
setter could be found).
2007-05-23 11:21:22,263 [http-8080-Processor24] ERROR
com.opensymphony.xwork.util.OgnlValueStack - Error setting expr
'externalResult' with value '[Ljava.lang.String;@160088f'
No object in the CompoundRoot has a publicly accessible property named
'externalResult' (no setter could be found). - [unknown location]
at
com.opensymphony.xwork.util.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:69)
at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1629)
at ognl.ASTProperty.setValueBody(ASTProperty.java:105)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177)
at ognl.SimpleNode.setValue(SimpleNode.java:246)
at ognl.Ognl.setValue(Ognl.java:476)
at com.opensymphony.xwork.util.OgnlUtil.setValue(OgnlUtil.java:186)
at
com.opensymphony.xwork.util.OgnlValueStack.setValue(OgnlValueStack.java:154)
at
com.opensymphony.xwork.util.OgnlValueStack.setValue(OgnlValueStack.java:137)
at
com.opensymphony.xwork.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:139)
at
com.opensymphony.xwork.interceptor.ParametersInterceptor.before(ParametersInterceptor.java:114)
at
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:30)
at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
at
com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:113)
at
com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:225)
at
com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:595)
2007-05-23 11:21:22,403 [http-8080-Processor24] ER
[jira] Created: (CONTINUUM-1288) Should not deploy modules unless all modules in a group build successfully
Should not deploy modules unless all modules in a group build successfully -- Key: CONTINUUM-1288 URL: http://jira.codehaus.org/browse/CONTINUUM-1288 Project: Continuum Issue Type: Improvement Components: Project Grouping Affects Versions: 1.1-alpha-1 Reporter: Eirik Maus Continuum should not deploy the modules to a maven repository unless all the modules in a group build successfully. If one module fails, this means that the source code is such a state that the modules do not create a functional artifact portfoilo. Hence, they should not be the basis for other builds. This should perhaps be a selectable per-group policy: choose "always deploy module" (like today) or "deploy only if all successfull". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen commented on MSITE-232: -- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Issue Comment Edited: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen edited comment on MSITE-232 at 5/23/07 4:17 AM: --- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that is still deployed something and just not the subprojects. And the deploying of jars works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. was: Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Issue Comment Edited: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen edited comment on MSITE-232 at 5/23/07 4:19 AM: --- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that it still deployed the root of the site and just not the subprojects. And the deploying of jars (deploy plugin) works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. was: Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that is still deployed something and just not the subprojects. And the deploying of jars works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1562) xreporter-grouping-1.2.1.1.jar
xreporter-grouping-1.2.1.1.jar -- Key: MAVENUPLOAD-1562 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1562 Project: maven-upload-requests Issue Type: Task Reporter: Marc Portier * grouping functions for xreporter * and a grouping transformer for usage inside apache Cocoon is required by xreporter-expression-1.2.1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1563) xreporter-expression-1.2.1.1.jar
xreporter-expression-1.2.1.1.jar Key: MAVENUPLOAD-1563 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1563 Project: maven-upload-requests Issue Type: Task Reporter: Marc Portier * expression language for xreporter requires by xreporter-grouping-1.2.1.1 see http://jira.codehaus.org/browse/MAVENUPLOAD-1562 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-351) Ability to disable the checksum applet used in Find Artifact
[ http://jira.codehaus.org/browse/MRM-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96836 ] Brett Porter commented on MRM-351: -- you can type in the md5, so maybe we should just put a conditional around it that is configurable, and disable it by default (the function makes more sense on a central repository mirror than it does in a corporate repository anyway). > Ability to disable the checksum applet used in Find Artifact > > > Key: MRM-351 > URL: http://jira.codehaus.org/browse/MRM-351 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak > Fix For: 1.0-alpha-1 > > > Applets that access the local filesystem are forbidden in some corporate > environments. We need a way to disable the Find Artifact applet without > breaking the web UI. > The ability to find an artifact by providing the md5 checksum should be > preserved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-150) Can't add prefix to tags without affecting version
[
http://jira.codehaus.org/browse/MRELEASE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96837
]
Roberto Lo Giacco commented on MRELEASE-150:
It would be very nice to allow for something like
X-${project.relase.version}
Any hint how it can be performed?
> Can't add prefix to tags without affecting version
> --
>
> Key: MRELEASE-150
> URL: http://jira.codehaus.org/browse/MRELEASE-150
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Yuri Schimke
>Priority: Minor
>
> I added the following to my POM
>
> maven-release-plugin
>
> XXX-${artifactId}-${version}
>
>
> However the tag comes out incorrectly.
> [INFO] Full run would be tagging C:\PerforceViews\... with label:
> 'XXX-myproject-0.5.4-SNAPSHOT
> What is the default? ${artifactId}-${version}
> Note: this seems to be missing from the plugin documentation, it only
> mentions releaseLabel, which defaults to 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] Created: (MRM-353) java.lang.ArithmeticException: / by zero - when scanning repository.
java.lang.ArithmeticException: / by zero - when scanning repository.
Key: MRM-353
URL: http://jira.codehaus.org/browse/MRM-353
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0-alpha-1
Reporter: Joakim Erdfelt
Stack trace ...
{code}
INFO | jvm 1| 2007/05/23 07:39:42 | 571013 [Thread-6] ERROR
org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:repository-scanning -
Error executing task
INFO | jvm 1| 2007/05/23 07:39:42 |
edu.emory.mathcs.backport.java.util.concurrent.ExecutionException:
java.lang.ArithmeticException: / by zero
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299)
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118)
INFO | jvm 1| 2007/05/23 07:39:42 | at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159)
INFO | jvm 1| 2007/05/23 07:39:42 | at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127)
INFO | jvm 1| 2007/05/23 07:39:42 | Caused by:
java.lang.ArithmeticException: / by zero
INFO | jvm 1| 2007/05/23 07:39:42 | at
org.apache.maven.archiva.model.RepositoryContentStatistics.toDump(RepositoryContentStatistics.java:275)
INFO | jvm 1| 2007/05/23 07:39:42 | at
org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:107)
INFO | jvm 1| 2007/05/23 07:39:42 | at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
INFO | jvm 1| 2007/05/23 07:39:42 | at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
INFO | jvm 1| 2007/05/23 07:39:42 | at
java.lang.Thread.run(Thread.java:595)
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MRELEASE-128:
-
Priority: Critical (was: Major)
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Fix For: 2.0-beta-5
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll reopened MRELEASE-128:
--
Tested on my first release with beta-5 and the scm url is still badly updated.
:(
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
> Fix For: 2.0-beta-5
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MJAVADOC-124) Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag
Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag Key: MJAVADOC-124 URL: http://jira.codehaus.org/browse/MJAVADOC-124 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Paolo Brocco I'm trying to generate a maven2 site. During the javadoc report generation I get these errors: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - java.util.MissingResourceException: Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag at java.util.ResourceBundle.getObject(ResourceBundle.java:325) at java.util.ResourceBundle.getString(ResourceBundle.java:285) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:114) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.warning(MessageRetriever.java:290) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.redirectRelativeLinks(HtmlDocletWriter.java:1526) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.commentTagsToString(HtmlDocletWriter.java:1438) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:164) at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:89) at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) 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.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) Command line was:/opt/sun-jdk-1.5.0.11/jre/../bin/javadoc @options @packages Alternatively, if I export the javadoc by clicking "export" > java > javadoc... on the project, I get this error: java.util.MissingResourceException: Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag at java.util.ResourceBundle.getObject(ResourceBundle.java:325) at java.util.ResourceBundle.getString(ResourceBundle.java:285) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:114) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.warning(MessageRetriever.java:290) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.redirectRelativeLinks(HtmlDocletWriter.java:1526) at com.sun.tools.doclets.formats.html.HtmlDocletWriter.commentTagsToS
[jira] Commented: (ARCHETYPE-40) Duplicate code in portlet archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96842 ] Clifton Craig commented on ARCHETYPE-40: I'm having the same issue. Will this bug be fixed anytime soon? Can I safely download the jars attached to this bug and use them instead? > Duplicate code in portlet archetype > --- > > Key: ARCHETYPE-40 > URL: http://jira.codehaus.org/browse/ARCHETYPE-40 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 >Reporter: Craig Doremus > Attachments: maven-archetype-portlet-1.0-alpha-4.jar, > maven-archetype-portlet-1.0.jar, maven-archetype-portlet.patch > > > The maven portlet archetype (maven-archetype-portlet under > maven-archetype-bundles) in source control contains duplicate code in all > files except the root pom.xml. The code for a file appears to be copied into > the file multiple times in every source file in each directory, rendering the > archetype to be unusable. > The fix is pretty evident when one looks at the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1289) Sorting Usernames in Build Management's Project Group member list does not work in Firefox 2
Sorting Usernames in Build Management's Project Group member list does not work in Firefox 2 Key: CONTINUUM-1289 URL: http://jira.codehaus.org/browse/CONTINUUM-1289 Project: Continuum Issue Type: Bug Components: Web interface Environment: Firefox 2 Reporter: Napoleon Esmundo C. Ramirez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1289) Sorting Usernames in Build Management's Project Group member list does not work in Firefox 2
[ http://jira.codehaus.org/browse/CONTINUUM-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Napoleon Esmundo C. Ramirez updated CONTINUUM-1289: --- Attachment: CONTINUUM-1289-continuum-webapp.patch The patch replaces "sortlist.submit()" with the more standard "document.forms['sortlist'].submit()" > Sorting Usernames in Build Management's Project Group member list does not > work in Firefox 2 > > > Key: CONTINUUM-1289 > URL: http://jira.codehaus.org/browse/CONTINUUM-1289 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: Firefox 2 >Reporter: Napoleon Esmundo C. Ramirez > Attachments: CONTINUUM-1289-continuum-webapp.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: (SCM-319) Maven Mercurial SCM Provider is missing "tag" command
[ http://jira.codehaus.org/browse/SCM-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96850 ] Ryan Daum commented on SCM-319: --- Note re: the patch, I produced this using "svn diff" after manually copying over and adding the new files, thus avoiding "svn copy", but the format still seems to be incorrect (I am unable to apply it with patch). Hopefully this will work o.k. for you. > Maven Mercurial SCM Provider is missing "tag" command > - > > Key: SCM-319 > URL: http://jira.codehaus.org/browse/SCM-319 > Project: Maven SCM > Issue Type: Sub-task > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.0 >Reporter: Ryan Daum > Attachments: maven-scm-hg-provider-tag-command.svn-diff, > maven-scm-hg-provider-tag-command.svn-diff.may23 > > > Maven SCM provider is missing the tag command, making it useless for mvn > release usage. > I am attaching a patch which rectifies this problem by adding the command and > associated test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-319) Maven Mercurial SCM Provider is missing "tag" command
[ http://jira.codehaus.org/browse/SCM-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Daum updated SCM-319: -- Attachment: maven-scm-hg-provider-tag-command.svn-diff.may23 Newer version of the patch. > Maven Mercurial SCM Provider is missing "tag" command > - > > Key: SCM-319 > URL: http://jira.codehaus.org/browse/SCM-319 > Project: Maven SCM > Issue Type: Sub-task > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.0 >Reporter: Ryan Daum > Attachments: maven-scm-hg-provider-tag-command.svn-diff, > maven-scm-hg-provider-tag-command.svn-diff.may23 > > > Maven SCM provider is missing the tag command, making it useless for mvn > release usage. > I am attaching a patch which rectifies this problem by adding the command and > associated test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-270) Add support for classpathentry attributes
Add support for classpathentry attributes - Key: MECLIPSE-270 URL: http://jira.codehaus.org/browse/MECLIPSE-270 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Mike Youngstrom Fix For: 2.4 With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute nested inside of the .classpath file's element Like so: It would be nice if it were possible to add attributes to classpathentry's with some kind of configuration syntax where maybe the dependency artifact and group are specified and then the attributes for that dependency. Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-213) jar-with-dependencies and signed jars issue again
jar-with-dependencies and signed jars issue again - Key: MASSEMBLY-213 URL: http://jira.codehaus.org/browse/MASSEMBLY-213 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: TAKATA, Satoshi /META-INF/*.RSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.sf These files are not excluded with the configuration below. maven-assembly-plugin jar-with-dependencies my.MainClass my -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3008) Multiple executions of embedder reuse the ProjectBuildCache
Multiple executions of embedder reuse the ProjectBuildCache --- Key: MNG-3008 URL: http://jira.codehaus.org/browse/MNG-3008 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Carlos Sanchez In DefaultModelLineageBuilder.resumeBuildingModelLineage( ModelLineage lineage, ArtifactRepository localRepository, ProfileManager profileManager ) there's a call to resolveParentPom passing the projectBuildCache This test breaks /trunk/pom.xml (a:b:1.0-SNAPSHOT) /trunk/child/pom.xml (has a:b:1.0-SNAPSHOT as parent) when running a goal in /trunk/child/pom.xml it will cache that a:b:1.0-SNAPSHOT is in /trunk/pom.xml now if it's moved or copied to /trunk2 or any other place and the embedder is called again it will use the parent in /trunk/pom.xml instead of /trunk2/pom.xml as it's in the cache If it doesn't exist it will throw a FileNotFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-123) Encoding Error When Getting project.name For JavaDoc -doctitle
[ http://jira.codehaus.org/browse/MJAVADOC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Coco updated MJAVADOC-123: - Attachment: javadoc-encoding-3-4.tar.gz JavaDoc encoding bug tests, versions 3 & 4. > Encoding Error When Getting project.name For JavaDoc -doctitle > -- > > Key: MJAVADOC-123 > URL: http://jira.codehaus.org/browse/MJAVADOC-123 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug > Environment: Linux coco-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 > 07:36:31 UTC 2007 i686 GNU/Linux > Maven version: 2.0.6 >Reporter: Steven Coco >Assignee: Vincent Siveton > Fix For: 2.3 > > Attachments: javadoc-encoding-2.tar.gz, javadoc-encoding-3-4.tar.gz, > javadoc-encoding.tar.gz > > > I have found an encoding handling error in JavaDoc generation. > The POM for this project is in UTF-8 encoding. the project.name element > contains the trade mark character, U+2122. > When the JavaDoc plugin builds the documentation, the default HTML charset is > used: ISO-8859-1. > When viewing the JavaDoc pages, the trade mark character in the title has > been munged: "™". > At some location, the project name's text is being copied and ported to the > JavaDoc tool in the wrong encoding. > The attachment has a test case. Since it's very small, the javadoc has > already been built there to prevent any unwanted encoding mismatches during > transmission of the attachment. View the POM to see the trade mark character > in the name. View target/site/apidocs/index.html to see the munged trade mark > character. View the src/main/java/overview.html file to see the other content > used for the API overview page. > N.B.: In the attachment, all files are in UTF-8 encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-123) Encoding Error When Getting project.name For JavaDoc -doctitle
[ http://jira.codehaus.org/browse/MJAVADOC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96856 ] Steven Coco commented on MJAVADOC-123: -- This Web app is broken. I wrote a lengthy comment and apparently my session timed out. When I submitted I got an error message saying I was not alows to post. And I can't go "back" and get the text that I entered into the form. I have to start now from scratch and that's totally unacceptable. [This version shorter because I'm out of time.] I tried both options. I made 2 new projects: version 3 and 4. They contain the plugin snapshot repository declaration. Version 3 POM has been switched to ISO-8859-1: declared in the XML declaration, and correctly saved. Building with this command: mvn -U -X -e -Ddebug=true -Dfile.encoding=UTF-8 clean javadoc:javadoc Verify that maven is using the JavaDoc snapshot plugin. In each case the options file is in UTF-8 encoding. However, in the version 3 file, the (R) has been inserted as the Unicode replacement character (correctly encoded in UTF-8). This should never happen since that character exists in both charsets. Tried switching to -Dfile.encoding=ISO-8859-1 and building both again -- both builds would still be valid builds this way. Similar problem, only seemingly worse: options file is again in UTF-8 encoding (with the replacement character). Something is using the wrong encoding. I'm not sure when I'll get to look at the sources. I'll keep trying. Ciao. > Encoding Error When Getting project.name For JavaDoc -doctitle > -- > > Key: MJAVADOC-123 > URL: http://jira.codehaus.org/browse/MJAVADOC-123 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug > Environment: Linux coco-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 > 07:36:31 UTC 2007 i686 GNU/Linux > Maven version: 2.0.6 >Reporter: Steven Coco >Assignee: Vincent Siveton > Fix For: 2.3 > > Attachments: javadoc-encoding-2.tar.gz, javadoc-encoding-3-4.tar.gz, > javadoc-encoding.tar.gz > > > I have found an encoding handling error in JavaDoc generation. > The POM for this project is in UTF-8 encoding. the project.name element > contains the trade mark character, U+2122. > When the JavaDoc plugin builds the documentation, the default HTML charset is > used: ISO-8859-1. > When viewing the JavaDoc pages, the trade mark character in the title has > been munged: "™". > At some location, the project name's text is being copied and ported to the > JavaDoc tool in the wrong encoding. > The attachment has a test case. Since it's very small, the javadoc has > already been built there to prevent any unwanted encoding mismatches during > transmission of the attachment. View the POM to see the trade mark character > in the name. View target/site/apidocs/index.html to see the munged trade mark > character. View the src/main/java/overview.html file to see the other content > used for the API overview page. > N.B.: In the attachment, all files are in UTF-8 encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-319) Maven Mercurial SCM Provider is missing "tag" command
[ http://jira.codehaus.org/browse/SCM-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-319. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Applied. Thanks. > Maven Mercurial SCM Provider is missing "tag" command > - > > Key: SCM-319 > URL: http://jira.codehaus.org/browse/SCM-319 > Project: Maven SCM > Issue Type: Sub-task > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.0 >Reporter: Ryan Daum >Assignee: Emmanuel Venisse > Fix For: 1.0 > > Attachments: maven-scm-hg-provider-tag-command.svn-diff, > maven-scm-hg-provider-tag-command.svn-diff.may23 > > > Maven SCM provider is missing the tag command, making it useless for mvn > release usage. > I am attaching a patch which rectifies this problem by adding the command and > associated test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-123) Encoding Error When Getting project.name For JavaDoc -doctitle
[
http://jira.codehaus.org/browse/MJAVADOC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96864
]
Vincent Siveton commented on MJAVADOC-123:
--
> Building with this command:
>
> mvn -U -X -e -Ddebug=true -Dfile.encoding=UTF-8 clean javadoc:javadoc
-Dfile.encoding=UTF-8 is specify to the Maven jvm *NOT* to the javadoc one.
Specify this is similar to:
{noformat}
MAVEN_OPTS=-Dfile.encoding=UTF-8
JAVA_OPTS=-Dfile.encoding=UTF-8
{noformat}
You need to use *-J-Dfile.encoding=UTF-8* for the javadoc. To handle this, you
need the snapshot from svn (not yet deployed on any snapshot repo) and add
-J-Dfile.encoding=UTF-8 to the parameter.
HTH
> Encoding Error When Getting project.name For JavaDoc -doctitle
> --
>
> Key: MJAVADOC-123
> URL: http://jira.codehaus.org/browse/MJAVADOC-123
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
> Environment: Linux coco-laptop 2.6.20-15-generic #2 SMP Sun Apr 15
> 07:36:31 UTC 2007 i686 GNU/Linux
> Maven version: 2.0.6
>Reporter: Steven Coco
>Assignee: Vincent Siveton
> Fix For: 2.3
>
> Attachments: javadoc-encoding-2.tar.gz, javadoc-encoding-3-4.tar.gz,
> javadoc-encoding.tar.gz
>
>
> I have found an encoding handling error in JavaDoc generation.
> The POM for this project is in UTF-8 encoding. the project.name element
> contains the trade mark character, U+2122.
> When the JavaDoc plugin builds the documentation, the default HTML charset is
> used: ISO-8859-1.
> When viewing the JavaDoc pages, the trade mark character in the title has
> been munged: "™".
> At some location, the project name's text is being copied and ported to the
> JavaDoc tool in the wrong encoding.
> The attachment has a test case. Since it's very small, the javadoc has
> already been built there to prevent any unwanted encoding mismatches during
> transmission of the attachment. View the POM to see the trade mark character
> in the name. View target/site/apidocs/index.html to see the munged trade mark
> character. View the src/main/java/overview.html file to see the other content
> used for the API overview page.
> N.B.: In the attachment, all files are in UTF-8 encoding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MASSEMBLY-214) java.lang.NullPointerException: version was null for junit:junit
java.lang.NullPointerException: version was null for junit:junit Key: MASSEMBLY-214 URL: http://jira.codehaus.org/browse/MASSEMBLY-214 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Christian Schulte Priority: Blocker Released version completely does not work for me anymore. [INFO] [INFO] version was null for junit:junit [INFO] [INFO] Trace java.lang.NullPointerException: version was null for junit:junit at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) at org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142) at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345) at org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:82) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:155) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:100) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-339) Roles aren't created if the repository isn't created within the web UI
[ http://jira.codehaus.org/browse/MRM-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96873 ] Jesse McConnell commented on MRM-339: - arnaud, your second comment was also fixed just now in MRM-349 > Roles aren't created if the repository isn't created within the web UI > -- > > Key: MRM-339 > URL: http://jira.codehaus.org/browse/MRM-339 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Arnaud Heritier >Assignee: Jesse McConnell > Fix For: 1.0-alpha-1 > > > If we create some repositories directly in the archiva.xml config file, we > don't have the roles to observe or manage these repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-339) Roles aren't created if the repository isn't created within the web UI
[ http://jira.codehaus.org/browse/MRM-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed MRM-339. --- Assignee: Jesse McConnell Resolution: Fixed added role creation to the configuration synchronization > Roles aren't created if the repository isn't created within the web UI > -- > > Key: MRM-339 > URL: http://jira.codehaus.org/browse/MRM-339 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Arnaud Heritier >Assignee: Jesse McConnell > Fix For: 1.0-alpha-1 > > > If we create some repositories directly in the archiva.xml config file, we > don't have the roles to observe or manage these repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-349) No access to repositories with guest as a global repo observer
[ http://jira.codehaus.org/browse/MRM-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed MRM-349. --- Assignee: Jesse McConnell Resolution: Fixed fixed, I had a typo in the permissions for repository observers > No access to repositories with guest as a global repo observer > -- > > Key: MRM-349 > URL: http://jira.codehaus.org/browse/MRM-349 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-alpha-1 > Environment: Archiva 1.0-alpha-1-SNAPSHOT r539760 2007-05-19 16:15 on > Plexus Runtime >Reporter: Wendy Smoak >Assignee: Jesse McConnell >Priority: Blocker > Fix For: 1.0-alpha-1 > > > After granting the Global Repository Observer role to the guest user, I am > prompted for an id and password when accessing the url for a managed > repository such as the preconfigured 'internal' repo. > MRM-323 seems to be the same thing, but on Tomcat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2258) Wrong execution order of plugins in same phase
[
http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96876
]
Sebastian Davids commented on MNG-2258:
---
This bug should be solved independent of MNG-1412.
This is a *serious* defect.
Considering the high number of votes and watchers it is important to a lot of
people.
It should be backported to 2.0.x stream.
After that a new 2.0.x release should be made.
Having to wait over one year for a simple HashSet -> LinkedHashSet and HashMap
-> LinkedHashMap replacement is ridiculous.
Even more so, considering that a patch has been supplied over half a year ago.
@@ Use Case @@
...
ejb
war
...
...
maven-antrun-plugin
false
install
... deploy to server ...
run
...
...
Let's say "ejb" contains EJB stuff and "war" contains the web application;
"war" depends on "ejb"; and both are children of a parent POM, so that the
generated "ejb" JAR gets packaged into the WAR.
Now we want to be able to use "install" to deploy the created WAR to the server
(yes, there's Cargo, but it does not support all JEE containers, yet.)
We have to set false so Maven won't run the deployment
for "ejb" and "war".
But it does not work because "maven-antrun-plugin" is run before the children
("ejb" and "war") are run.
> Wrong execution order of plugins in same phase
> --
>
> Key: MNG-2258
> URL: http://jira.codehaus.org/browse/MNG-2258
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.4
> Environment: N/A
>Reporter: David J. M. Karlsen
> Fix For: 2.1.x
>
>
> AFAIK plugins should be execute in the same order as they are listed in the
> POM, when bound to the same phase. This does not happen, the execution order
> is arbitrary.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2981) [PATCH] NPE in PluginXDocGenerator while creating plugin site
[ http://jira.codehaus.org/browse/MNG-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Melnick updated MNG-2981: --- Attachment: PluginXdocGenerator.patch The previous patch did a null check after the error would have happened - typo? Anyway, here is the correct patch. > [PATCH] NPE in PluginXDocGenerator while creating plugin site > - > > Key: MNG-2981 > URL: http://jira.codehaus.org/browse/MNG-2981 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.6 >Reporter: Steve Rowe > Attachments: PluginXdocGenerator.diff, PluginXdocGenerator.patch > > > I'm running into (what appears to be) the exact same problem that Tom > Huybrechts described on the Maven user list a few months ago (quoted below), > with Maven v2.0.6, maven-plugin-plugin v2.3, and maven-plugin-tools-api v2.1. > I attach a patch that fixes the problem for me. > Output: > [INFO] [site:site] > [INFO] Skipped "About" report, file "index.html" already exists for the > English version. > [INFO] Skipped "Maven Surefire Report" report, file > "surefire-report.html" already exists for the English version. > [INFO] Generate "Plugin documentation" report. > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 3 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.filterParameters(PluginXdocGenerator.java:253) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeGoalParameterTable(PluginXdocGenerator.java:239) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeBody(PluginXdocGenerator.java:122) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.processMojoDescriptor(PluginXdocGenerator.java:61) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:49) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:192) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:141) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >
[jira] Issue Comment Edited: (MNG-2981) [PATCH] NPE in PluginXDocGenerator while creating plugin site
[ http://jira.codehaus.org/browse/MNG-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96883 ] Jason Melnick edited comment on MNG-2981 at 5/23/07 4:34 PM: - The previous patch did a null check after the error would have happened - typo? Anyway, here is the correct patch. Thanks Steve for finding the problem, I just modified it. was: The previous patch did a null check after the error would have happened - typo? Anyway, here is the correct patch. > [PATCH] NPE in PluginXDocGenerator while creating plugin site > - > > Key: MNG-2981 > URL: http://jira.codehaus.org/browse/MNG-2981 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.6 >Reporter: Steve Rowe > Attachments: PluginXdocGenerator.diff, PluginXdocGenerator.patch > > > I'm running into (what appears to be) the exact same problem that Tom > Huybrechts described on the Maven user list a few months ago (quoted below), > with Maven v2.0.6, maven-plugin-plugin v2.3, and maven-plugin-tools-api v2.1. > I attach a patch that fixes the problem for me. > Output: > [INFO] [site:site] > [INFO] Skipped "About" report, file "index.html" already exists for the > English version. > [INFO] Skipped "Maven Surefire Report" report, file > "surefire-report.html" already exists for the English version. > [INFO] Generate "Plugin documentation" report. > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 3 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.filterParameters(PluginXdocGenerator.java:253) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeGoalParameterTable(PluginXdocGenerator.java:239) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeBody(PluginXdocGenerator.java:122) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.processMojoDescriptor(PluginXdocGenerator.java:61) > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:49) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:192) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:141) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codeh
[jira] Created: (MAVENUPLOAD-1565) upload vraptor 2.3.3
upload vraptor 2.3.3 Key: MAVENUPLOAD-1565 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1565 Project: maven-upload-requests Issue Type: Task Reporter: Nico Steppat VRaptor 2.3.3 framework update with bug-fiexe and new docs. VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that configuration should be minimal and conventions should be maximized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAR-68) multi module release fails because of test-jar
[ http://jira.codehaus.org/browse/MJAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96884 ] Dan Batten commented on MJAR-68: I'm having the same problem and the only "solution" I've found is the one mentioned above. > multi module release fails because of test-jar > -- > > Key: MJAR-68 > URL: http://jira.codehaus.org/browse/MJAR-68 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: maven 2.0.5 >Reporter: Yuri Schimke > > The release plugin is failing in the prepare task > mvn release:prepare > seemingly because it can't find the test-jar that has just been built by the > previous module i.e. built within. > Are there some examples in the wild of using the test-jar on a multi module > project that does releases? > The (nasty) workaround I have for now, is to wait for the build to fail and > then > mvn install > So the test-jar (and other artifacts) are in my local repository and then > continue > mvn release:prepare -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-324) Global Repository Manager privililege do not grant deployment privilege
[ http://jira.codehaus.org/browse/MRM-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed MRM-324. --- Resolution: Cannot Reproduce I can't marked this fixed directly since I am not 100% what caused it, but its working now and it might have something to do with a tweak on MRM-349 test1 user has the Global Repository Manager role and is able to deploy. test1 ;seng93 local > Global Repository Manager privililege do not grant deployment privilege > > > Key: MRM-324 > URL: http://jira.codehaus.org/browse/MRM-324 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-alpha-1 > Environment: Mac OS X >Reporter: Lennart Jörelid >Assignee: Jesse McConnell > Fix For: 1.0-alpha-1 > > > Archiva sends status 401/Unauthorized when deploying a snapshot > release to Archiva with a user holding the "Global Repository Manager" > role. > Deployment works when the user is granted individual repository > manager roles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAR-68) multi module release fails because of test-jar
[ http://jira.codehaus.org/browse/MJAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96888 ] Dan Batten commented on MJAR-68: After a bit more reading I found that there is a configuration parameter called preparationGoals. The default is "clean integration-test" but you can change this to the goals you want. I used "clean install" to fix the problem. > multi module release fails because of test-jar > -- > > Key: MJAR-68 > URL: http://jira.codehaus.org/browse/MJAR-68 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: maven 2.0.5 >Reporter: Yuri Schimke > > The release plugin is failing in the prepare task > mvn release:prepare > seemingly because it can't find the test-jar that has just been built by the > previous module i.e. built within. > Are there some examples in the wild of using the test-jar on a multi module > project that does releases? > The (nasty) workaround I have for now, is to wait for the build to fail and > then > mvn install > So the test-jar (and other artifacts) are in my local repository and then > continue > mvn release:prepare -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-353) java.lang.ArithmeticException: / by zero - when scanning repository.
[
http://jira.codehaus.org/browse/MRM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse McConnell closed MRM-353.
---
Assignee: Jesse McConnell (was: Fabrice BELLINGARD)
Resolution: Fixed
fixed check for 0 and skip the division if it is 0
> java.lang.ArithmeticException: / by zero - when scanning repository.
>
>
> Key: MRM-353
> URL: http://jira.codehaus.org/browse/MRM-353
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0-alpha-1
>Reporter: Joakim Erdfelt
>Assignee: Jesse McConnell
>
> Stack trace ...
> {code}
> INFO | jvm 1| 2007/05/23 07:39:42 | 571013 [Thread-6] ERROR
> org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:repository-scanning
> - Error executing task
> INFO | jvm 1| 2007/05/23 07:39:42 |
> edu.emory.mathcs.backport.java.util.concurrent.ExecutionException:
> java.lang.ArithmeticException: / by zero
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127)
> INFO | jvm 1| 2007/05/23 07:39:42 | Caused by:
> java.lang.ArithmeticException: / by zero
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> org.apache.maven.archiva.model.RepositoryContentStatistics.toDump(RepositoryContentStatistics.java:275)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:107)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> INFO | jvm 1| 2007/05/23 07:39:42 | at
> java.lang.Thread.run(Thread.java:595)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-40) Duplicate code in portlet archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed ARCHETYPE-40. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0 applied, thanks! > Duplicate code in portlet archetype > --- > > Key: ARCHETYPE-40 > URL: http://jira.codehaus.org/browse/ARCHETYPE-40 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 >Reporter: Craig Doremus >Assignee: Brett Porter > Fix For: 1.0 > > Attachments: maven-archetype-portlet-1.0-alpha-4.jar, > maven-archetype-portlet-1.0.jar, maven-archetype-portlet.patch > > > The maven portlet archetype (maven-archetype-portlet under > maven-archetype-bundles) in source control contains duplicate code in all > files except the root pom.xml. The code for a file appears to be copied into > the file multiple times in every source file in each directory, rendering the > archetype to be unusable. > The fix is pretty evident when one looks at the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-236: -- Attachment: pom.xml I've attached the POM that was causing the problem. Though I think its self evident from the code what the problem is. > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Priority: Blocker > Attachments: pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-236: -- Attachment: MRELEASE-236-patch.txt I believe this patch fixes the issue. > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Priority: Blocker > Attachments: MRELEASE-236-patch.txt, pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-236) ArrayindexoutofBoundsException rewriting the Poms for release
ArrayindexoutofBoundsException rewriting the Poms for release - Key: MRELEASE-236 URL: http://jira.codehaus.org/browse/MRELEASE-236 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: William Ferguson Priority: Blocker Attachments: Stacktrace.txt Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed that it always fails on release:prepare when it is rewriting the Poms. Looking at the source code, the while loop at lines 249:252 of RewritePomsForReleasePhase class will always iterate past the end of the char arrays. I'm not sure, but I suspect the appropriate soltuion is to check to ensure that i < tagPathChars.length and i < trunkPathChars.length within the loop and if so to break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-354) Show Artifact Reports results to HTTP ERROR: 500
Show Artifact Reports results to HTTP ERROR: 500 Key: MRM-354 URL: http://jira.codehaus.org/browse/MRM-354 Project: Archiva Issue Type: Bug Components: reporting Reporter: Dawn Angelito Clicking the Reports tab of an artifact will result to: HTTP ERROR: 500 Internal Server Error RequestURI=/archiva/showArtifactReports.action -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-235) Need ability to execute goals during prepare after scm-tag but before scm-commit-development phase
[ http://jira.codehaus.org/browse/MRELEASE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-235: -- Attachment: MRELEASE-235-patch.txt This patch adds another preparation phase (run-post-preparation-goals) that runs like so: scm-commit-development run-post-preparation-goals end-release It allows execution of user-defined goals during the release:prepare but after the project has been released. Eg updating of SCM properties to refer to new tag - subclipse:tags property. I have added test case for it which is essentially a copy of the RunPreparationGoalsPhaseTest. Any chance it can be included with 2.0-beta-6 since another build is going to be required anyway (due to http://jira.codehaus.org/browse/MRELEASE-236) ? > Need ability to execute goals during prepare after scm-tag but before > scm-commit-development phase > -- > > Key: MRELEASE-235 > URL: http://jira.codehaus.org/browse/MRELEASE-235 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-235-patch.txt > > > During release:prepare I have a plugin that needs to be called after the > scm-tag phase but before the scm-commit-development phase. > My plugin updates the subclipse-tags property trunk folder so that Subclipse > (Eclipse plugin for SVN) can provide good visual clues on the history tab > showing which revisions were released and a what. > My plugin needs to be able to > 1) read release.properties to get the scm.tag > 2) use SVN to retrieve the SVN Revision for the scm.tag (hence need to > execute after scm-tag phase) > 3) use SVN to retrieve the subclipse-tags property from the trunk > 4) Append the appropriate tag lines to the retrieve property. > 5) use SVN to update the subclipse-tags property on the trunk > 6) Either use SVN to commit or be comfortable that an SVN commit will occur > by other means (hence need to execute before scm-commit-development-phase) > I'm not sure of the best approach to take. A new phase needs to available in > which to execute. Either > a) after scm-tag but before scm-commit-development in which case I leave the > commit to the scm-commit-development phase. Perhaps a little too coupled and > hides a little too much meaning, but only generates 2 commits for a release > instead of 3. > b) after scm-commit-development (eg run-post-preparation-goals) which is self > contained as it needs to commit. It will generate an extra commit each > release, but the commit message can at least clearly relate to update of the > subclipse-tags property. I think I'll attempt this. > I thought I could take the easy approach and run the goal during > release:perform, but the basedir during run-perform-goals is > project.basedir/target/checkout and points to the Tag not the trunk. So my > plugin would become highly coupled to being executed during release:perform > as well as having intimate knowledge of expecting execution folders. > Unless someone interjects I intend on having a go at this and providing it as > a patch. > So if I'm way off base please provide feedback to guide me. > What's the expected release date for 2.0-beta-6 ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-355) Unable to sort users by Tasks
Unable to sort users by Tasks - Key: MRM-355 URL: http://jira.codehaus.org/browse/MRM-355 Project: Archiva Issue Type: Bug Components: Users/Security Reporter: Dawn Angelito In the List of Users page, the Tasks column header is not clickable. Therefore, sorting of users by tasks is impossible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2461) Write JavaDoc documentation
[ http://jira.codehaus.org/browse/MNG-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96899 ] Vincent Siveton commented on MNG-2461: -- Added some javadoc in the maven model > Write JavaDoc documentation > --- > > Key: MNG-2461 > URL: http://jira.codehaus.org/browse/MNG-2461 > Project: Maven 2 > Issue Type: Task > Components: Documentation: General >Reporter: Simon Kepp Nielsen >Priority: Critical > > There hardly exists any JavaDoc documentation for Maven 2. Even very central > classes such as Mojo, AbstractMojo, MavenProject, MavenProjectHelper and > Artifact are completely undocumented. This makes it very difficult to write > your own plugins, which seriously limits adoption of Maven 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] Updated: (SUREFIRE-311) system properties within execution elements are not set
[ http://jira.codehaus.org/browse/SUREFIRE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-311: -- Fix Version/s: 2.4 > system properties within execution elements are not set > --- > > Key: SUREFIRE-311 > URL: http://jira.codehaus.org/browse/SUREFIRE-311 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin), 2.3 > Environment: mac osx, java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Valerio Schiavoni > Fix For: 2.4 > > Attachments: my-app-surefire-error.tgz > > > Configuring some system properties in the elements of the > configuration doesn't result in those settings being available when executing > tests. > I'm attacching a toy project to demostrate the bug: mvn test results in a > test failure; uncommenting the configuration element in the pom (and removing > the element) result in a test success. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-303) Ignored/Skipped tests are not reported
[
http://jira.codehaus.org/browse/SUREFIRE-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-303:
--
Description:
Tests that are skipped with a @Ignore("Test doesn't work") annotation only
appear in the report as an increment in the "Skipped" column.Neither the
names of the skipped tests nor the text/reason for the skip appear at all.
was:
Tests that are skipped with a @Ignore("Test doesn't work") annotation only
appear in the report as an increment in the "Skipped" column.Neither the
names of the skipped tests nor the text/reason for the skip appear at all.
Fix Version/s: 2.4
> Ignored/Skipped tests are not reported
> --
>
> Key: SUREFIRE-303
> URL: http://jira.codehaus.org/browse/SUREFIRE-303
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support, report plugin, xml generation
>Affects Versions: 2.3
>Reporter: Daniel Kulp
> Fix For: 2.4
>
>
> Tests that are skipped with a @Ignore("Test doesn't work") annotation only
> appear in the report as an increment in the "Skipped" column.Neither the
> names of the skipped tests nor the text/reason for the skip appear at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-180) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/SUREFIRE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-180: -- Fix Version/s: 2.4 > Ability to add additions to classpath > - > > Key: SUREFIRE-180 > URL: http://jira.codehaus.org/browse/SUREFIRE-180 > Project: Maven Surefire > Issue Type: Improvement > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: fabrizio giustina > Fix For: 2.4 > > Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, > SurefirePlugin.java-diff > > > There should be a possibility to add arbritary resources to the classpath > while executing the tests. These resources would only be available while > executing the tests, so they won't be added in the archive. > i suggest a configuration element > > some/path > /some/other/path > > This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / > ability to exclude/include filtering in archiver/jar-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-327) java.lang.StringIndexOutOfBoundsException in XMLReporter
[ http://jira.codehaus.org/browse/SUREFIRE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-327: -- Fix Version/s: 2.3.1 > java.lang.StringIndexOutOfBoundsException in XMLReporter > > > Key: SUREFIRE-327 > URL: http://jira.codehaus.org/browse/SUREFIRE-327 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Tom Spengler >Priority: Critical > Fix For: 2.3.1 > > Attachments: SUREFIRE-327.patch > > > XMLReporter don't works correct if the classes dont have line-numbers. > The stacktrace don't show line-numbers and the XMLReporter has a > java.lang.StringIndexOutOfBoundsException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-326) Unable to load lib/ext classes since 2.3
[ http://jira.codehaus.org/browse/SUREFIRE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-326: -- Fix Version/s: 2.3.1 > Unable to load lib/ext classes since 2.3 > > > Key: SUREFIRE-326 > URL: http://jira.codehaus.org/browse/SUREFIRE-326 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.3 > Environment: Windows XP, Java 1.5. >Reporter: Phil Webb >Priority: Critical > Fix For: 2.3.1 > > Attachments: MavenLibExtTest.zip > > > Since upgrading to surefire 2.3 I am unable to locate any classes in my jre > lib/ext directory. This means that test cases that use JDBC no longer work. > Attached is an example project the loads com.sun.crypto.provider.AESCipher > that is normally in the sunjce_provider.jar in lib/ext. If I uncomment the > pom line that sets surefure version to 2.2 the project compiles, with 2.3 I > get a ClassNotFoundException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException
[ http://jira.codehaus.org/browse/SUREFIRE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-328: -- Fix Version/s: 2.4 > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException > - > > Key: SUREFIRE-328 > URL: http://jira.codehaus.org/browse/SUREFIRE-328 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 > Environment: Windows XP > Maven 2.0.6 >Reporter: Wim Deblauwe > Fix For: 2.4 > > > I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build > anymore. I get a NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException. This is the console > output with the -e option: > >mvn -e clean test > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException > Exception in thread "main" > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (DefaultLifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments > (DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode > (Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > at org.apache.maven.plugin.surefire.SurefirePlugin.execute > (SurefirePlugin.java:413) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java > :539) > ... 16 more > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon May 14 10:45:43 CEST 2007 > [INFO] Final Memory: 8M/25M > [INFO] > > I'm using the snapshot release because I use TestNG 5.5. Any solution to make > my build work again would be highly appriciated. > regards, > Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-322) MalformedURLException on windows when useSystemClassLoader set to true
[ http://jira.codehaus.org/browse/SUREFIRE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-322: -- Fix Version/s: 2.3.1 > MalformedURLException on windows when useSystemClassLoader set to true > -- > > Key: SUREFIRE-322 > URL: http://jira.codehaus.org/browse/SUREFIRE-322 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: Windows XP (and probably all win32 OS) >Reporter: Mark Palmer > Fix For: 2.3.1 > > Attachments: SUREFIRE-322.patch > > > useSystemClassLoader does not work on windows XP, due to the way that the > surefire plugin creates a manifest.mf which includes all necessary jars to > run the projects tests. > The manifest.mf file created in surefirebooter[1-9]*.jar contains absolute > paths that begin with the drive letter, e.g. c:\somedir\somejar.jar on > on unix this would be /somedir/somejar.jar which java.net.URL can cope with, > on windows c:/somedir/somejar.jar needs to be changed to > file:///c:\somedir\somejar.jar > steps to recreate are simple: > 1. mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > 2. add the following entry in pom.xml for my-app > > > > org.apache.maven.plugins > maven-surefire-plugin > > > true > > > > > 3. mvn install > which will fail with > [INFO] Building jar: > c:\DOCUME~1\username\LOCALS~1\Temp\surefirebooter43635.jar > java.net.MalformedURLException: unknown protocol: c > at java.net.URL.(URL.java:573) > at java.net.URL.(URL.java:463) > at > sun.misc.URLClassPath$JarLoader.parseClassPath(URLClassPath.java:923) > at sun.misc.URLClassPath$JarLoader.getClassPath(URLClassPath.java:896) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:351) > at sun.misc.URLClassPath.getResource(URLClassPath.java:205) > at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:846) > at java.security.AccessController.doPrivileged1(Native Method) > at > java.security.AccessController.doPrivileged(AccessController.java:389) > at java.net.URLClassLoader.findClass(URLClassLoader.java:371) > at java.lang.ClassLoader.loadClass(ClassLoader.java:570) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442) > at java.lang.ClassLoader.loadClass(ClassLoader.java:502) > The java class is not found: org/apache/maven/surefire/booter/SurefireBooter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-319) true cannot be overridden using mvn -Dmaven.test.skip=false test
[ http://jira.codehaus.org/browse/SUREFIRE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-319: -- Fix Version/s: 2.4 > true cannot be overridden using mvn -Dmaven.test.skip=false test > - > > Key: SUREFIRE-319 > URL: http://jira.codehaus.org/browse/SUREFIRE-319 > Project: Maven Surefire > Issue Type: Bug > Environment: java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) >Reporter: Graham Leggett > Fix For: 2.4 > > > If the pom file is configured to skip tests using true, and an > attempt is made to override this on the command line using mvn > -Dmaven.test.skip=false test, the attempt does not work (the test is still > skipped). > In theory, the command line flag should override the pom setting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-323) Running a single test using -Dtest has no effect
[ http://jira.codehaus.org/browse/SUREFIRE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-323: -- Fix Version/s: 2.3.1 > Running a single test using -Dtest has no effect > > > Key: SUREFIRE-323 > URL: http://jira.codehaus.org/browse/SUREFIRE-323 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) >Reporter: Graham Leggett > Fix For: 2.3.1 > > > Using the -D option from the command line to run a test as per the > instructions at > http://maven.apache.org/plugins/maven-surefire-plugin/examples/single-test.html, > the test is ignored. > The test is not configured within the pom, because the test should only be > run by hand, not as part of the build. Thus the need to run the test on its > own. > bash-3.00$ mvn -Dtest=**/*TestConcurrency test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Alchemy Measure > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] No sources to compile > [INFO] [surefire:test] > [INFO] No tests to run. > The following command line options also do not work: > bash-3.00$ mvn -Dtest=TestConcurrency test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Alchemy Measure > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] No sources to compile > [INFO] [surefire:test] > [INFO] No tests to run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-324) Deploy the 2.3 documentation
[ http://jira.codehaus.org/browse/SUREFIRE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-324: -- Fix Version/s: 2.3.1 > Deploy the 2.3 documentation > > > Key: SUREFIRE-324 > URL: http://jira.codehaus.org/browse/SUREFIRE-324 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Affects Versions: 2.3 >Reporter: Jerome Lacoste >Priority: Critical > Fix For: 2.3.1 > > > 2.3 doc not online. Support for JUnit 4 is in and documentation is misleading. > See > http://www.nabble.com/surefire-and-junit-4-website-out-of-date-t3584296s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-325) when parsing excludedGroups config prop, trim leading and trailing whitespace off of group names
[ http://jira.codehaus.org/browse/SUREFIRE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-325: -- Fix Version/s: 2.4 > when parsing excludedGroups config prop, trim leading and trailing whitespace > off of group names > > > Key: SUREFIRE-325 > URL: http://jira.codehaus.org/browse/SUREFIRE-325 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support >Affects Versions: 2.3 >Reporter: Ian Springer >Priority: Minor > Fix For: 2.4 > > > If I specify: > agent-comm, comm-client, native-system > it gets parsed into: > "agent-comm", " comm-client", " native-system" > It would be nice if, after tokenizing on commas, leading and trailing > whitespace were stripped off of the group names. That is, so results for the > above example would be: > "agent-comm", "comm-client", "native-system" > I know that TestNG group names technically could truly contain leading or > trailing whitespace, but realistically I don't think anyone would ever do > such a thing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-307) Tests fail if in path with spaces
[
http://jira.codehaus.org/browse/SUREFIRE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-307:
--
Fix Version/s: 2.4
> Tests fail if in path with spaces
> -
>
> Key: SUREFIRE-307
> URL: http://jira.codehaus.org/browse/SUREFIRE-307
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 2.3
> Environment: Windows XP
> Maven 2.0.5
> Java 1.6.0
>Reporter: Wim Deblauwe
> Fix For: 2.4
>
>
> I use TestNG with Surefire. My build fails if my project is in a path with
> spaces, because my tests fail. In my tests I have the following code:
> new File( getClass().getResource( "sample-java-utils-log.xml" ).toURI() )
> This results in the following error:
> java.net.URISyntaxException: Illegal character in path at index 18:
> file:/C:/Documents and
> Settings/wdb/.hudson/jobs/Vigilog/workspace/trunk/target/test-classes/net/sourceforge/vigilog/parse/sample-
> java-utils-log.xml
> at java.net.URI$Parser.fail(Unknown Source)
> at java.net.URI$Parser.checkChars(Unknown Source)
> at java.net.URI$Parser.parseHierarchical(Unknown Source)
> at java.net.URI$Parser.parse (Unknown Source)
> at java.net.URI.(Unknown Source)
> at java.net.URL.toURI(Unknown Source)
> at
> net.sourceforge.vigilog.parse.JavaLoggingXMLFileLogFileParserTest.testParse(JavaLoggingXMLFileLogFileParserTest.java
> :38)
> If I put my project in a path without spaces, I don't have this problem (I
> noticed this problem, because I tried Hudson build server and it checks the
> project out to my home directory)
> According to Jesse Glick from the Hudson mailing list, the problem is due to
> the following fact (full thread:
> http://www.nabble.com/Build-fails-under-hudson-due-to-TestNG-unit-tests-tf3354110.html):
> Wim Deblauwe wrote:
> > If it is any help, this is the source code of IsolatedClassLoader:
> > http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/IsolatedClassLoader.java?view=markup
> It sure does help, because this class is probably to blame for your problem:
> http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-api/src/main/java/org/apache/maven/surefire/util/UrlUtils.java
> Note the call to File.toURL(), deprecated as of JDK 6 because
> $ jrunscript
> js> println(new java.io.File("/tmp/foo and bar/baz").toURI().toURL())
> file:/tmp/foo%20and%20bar/baz
> js> println(new java.io.File("/tmp/foo and bar/baz").toURL())
> file:/tmp/foo and bar/baz
> js> println(new java.io.File("/tmp/foo and bar/baz").toURL().toURI())
> script error: sun.org.mozilla.javascript.internal.WrappedException:
> Wrapped java.net.URISyntaxException: Illegal character in path at index
> 13: file:/tmp/foo and bar/baz (#1) in at line number 1
> js>
> If you want to reproduce this, check out my open source project to a
> directory with spaces from:
> https://vigilog.svn.sourceforge.net/svnroot/vigilog/trunk
> and run 'mvn test'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-318) Fails to run build on Windows Server 2003
[ http://jira.codehaus.org/browse/SUREFIRE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-318: -- Fix Version/s: 2.3.1 > Fails to run build on Windows Server 2003 > - > > Key: SUREFIRE-318 > URL: http://jira.codehaus.org/browse/SUREFIRE-318 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.5 or 2.0.6 , Windows Server 2003, Java 1.5 or > 1.6 >Reporter: Vlad Skarzhevskyy > Fix For: 2.3.1 > > Attachments: build-log.txt > > > After Upgrade to Surefire 2.3 our build server fails to run tests on any > project. > Get the message: > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > All works fine on Linux, WinXP and Win2000. > But when I try to build on any Windows Server 2003 build will fail. > See the log > mvn -X test > build-log.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2461) Write JavaDoc documentation
[ http://jira.codehaus.org/browse/MNG-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96909 ] Vincent Siveton commented on MNG-2461: -- Added some javadoc in the settings project > Write JavaDoc documentation > --- > > Key: MNG-2461 > URL: http://jira.codehaus.org/browse/MNG-2461 > Project: Maven 2 > Issue Type: Task > Components: Documentation: General >Reporter: Simon Kepp Nielsen >Priority: Critical > > There hardly exists any JavaDoc documentation for Maven 2. Even very central > classes such as Mojo, AbstractMojo, MavenProject, MavenProjectHelper and > Artifact are completely undocumented. This makes it very difficult to write > your own plugins, which seriously limits adoption of Maven 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] Created: (MRM-356) Remove '*' in Password and Confirm Password fields
Remove '*' in Password and Confirm Password fields -- Key: MRM-356 URL: http://jira.codehaus.org/browse/MRM-356 Project: Archiva Issue Type: Improvement Components: Users/Security Reporter: Dawn Angelito Priority: Trivial It would be better if we remove the '*' in the Password and Confirm Password fields in the Create User page since both fields are not required. It might just cause confusion to the 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: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
gpg plugin hangs when it should prompt for the secret key passphrase hangs -- Key: MGPG-9 URL: http://jira.codehaus.org/browse/MGPG-9 Project: Maven 2.x GPG Plugin Issue Type: Bug Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x Reporter: Alex Karasulu When used in conjunction with the release plugin the release:perform command hangs when it should prompt for the secret key passphrase. Interestingly enough when I put the passphrase into the settings.xml file the plugin does not hang. I suspect the prompt is failing to show up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MECLIPSE-271) Ability to skip
Ability to skip --- Key: MECLIPSE-271 URL: http://jira.codehaus.org/browse/MECLIPSE-271 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Components: multiproject Affects Versions: 2.3 Environment: xp, linux Reporter: Dan Tran Fix For: 2.4 I would like mvn eclipse:eclipse to skip its execution use case: currently eclipse:eclipse goal can not generate my webapp project file correctly using WTP 2.0 so I ended up to handcraft eclipse project and setting files and check them into SCM. By supporting 'skip' configuration, I can have eclipse to generate other project file and skip my web app ( until WTP 2.0 feature is added in the example) comments? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-357) Update Consumers button in Repository Scanning doesn't work
Update Consumers button in Repository Scanning doesn't work --- Key: MRM-357 URL: http://jira.codehaus.org/browse/MRM-357 Project: Archiva Issue Type: Bug Components: repository scanning Reporter: Dawn Angelito 1) Log in as admin. 2) Click the Repository Scanning button in the left menu under Administration. 3) In Repository Scanning - Consumers of Known Content, check "validate-checksums" to enable it. 4) Click the Update Consumers button. Once the page is refreshed, notice that "validate-checksums" is still 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: (MRM-358) Update Consumers button in Database - Artifact Scanning doesn't work
Update Consumers button in Database - Artifact Scanning doesn't work Key: MRM-358 URL: http://jira.codehaus.org/browse/MRM-358 Project: Archiva Issue Type: Bug Reporter: Dawn Angelito 1) Log in as admin. 2) Click the Database button in the left menu under Administration. 3) In Database - Unprocessed Artifacts Scanning, uncheck "validate-repository-metadata" to disable it. 4) Click the Update Consumers button. Once the page is refreshed, notice that "validate-repository-metadata" is still enabled. Note: Try the same procedure in Database - Artifact Cleanup Scanning. The changes made will not be saved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
