[jira] Commented: (MPEAR-20) Deploy error because of display name
The following comment has been added to this issue: Author: Joerg Schaible Created: Thu, 16 Sep 2004 2:47 AM Body: Well, the display name can be set anyway, but it should work for as many J2EE servers as possible OOTB. - View this comment: http://jira.codehaus.org/browse/MPEAR-20?page=comments#action_24138 - View the issue: http://jira.codehaus.org/browse/MPEAR-20 Here is an overview of the issue: - Key: MPEAR-20 Summary: Deploy error because of display name Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ear-plugin Versions: 1.5 Assignee: Reporter: Joerg Schaible Created: Wed, 15 Sep 2004 6:32 AM Updated: Thu, 16 Sep 2004 2:47 AM Environment: IONA Orbix Application Server Platform, Windows Description: The IONA Orbix J2EE server uses the display name as root directory for the exploaded EAR. Unfortunately this contains by default a colon ("${pom.groupId}:${pom.artifactId}") for a generated application.xml which is obviously not an allowed character for files in Windows. This default value should be set to something, that does not break any app server. Proposal: dot - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patches for tar options on site:sshdeploy
>Applied. Thanks! -- Sean -- --- M. Sean Gilligan: 831-466-9788 x11 Catalla Systems, Inc. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patches for tar options on site:sshdeploy
Applied. On Wed, 15 Sep 2004 16:24:14 -0700, M. Sean Gilligan <[EMAIL PROTECTED]> wrote: > I just submitted a patch to maven-site-plugin to add a property for the > tar options to be used on the server: > http://jira.codehaus.org/browse/MPSITE-15 > > (My motivation is that OS X Server 10.2 doesn't seem to support the 'U' option, so I > can't use site:sshdeploy to put my project documentation on my Intranet server.) > > There is another patch submitted to allow turning on/off the verbose option for tar: > http://jira.codehaus.org/browse/MPSITE-10 > > The patch for MPSITE-15 will solve the user need in MPSITE-10 since it places the > entire "options" argument of tar into a property. In any event, these two patches > are closely related. > > Regards, > > Sean > > -- > --- > M. Sean Gilligan: 831-466-9788 x11 > Catalla Systems, Inc. > --- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPEAR-20) Deploy error because of display name
The following comment has been added to this issue: Author: dion gillard Created: Wed, 15 Sep 2004 8:52 PM Body: If we do this, make it a property rather than hard coding a dot. - View this comment: http://jira.codehaus.org/browse/MPEAR-20?page=comments#action_24128 - View the issue: http://jira.codehaus.org/browse/MPEAR-20 Here is an overview of the issue: - Key: MPEAR-20 Summary: Deploy error because of display name Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ear-plugin Versions: 1.5 Assignee: Reporter: Joerg Schaible Created: Wed, 15 Sep 2004 6:32 AM Updated: Wed, 15 Sep 2004 8:52 PM Environment: IONA Orbix Application Server Platform, Windows Description: The IONA Orbix J2EE server uses the display name as root directory for the exploaded EAR. Unfortunately this contains by default a colon ("${pom.groupId}:${pom.artifactId}") for a generated application.xml which is obviously not an allowed character for files in Windows. This default value should be set to something, that does not break any app server. Proposal: dot - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPSITE-15) maven site:sshdeploy doesn't work all tars (needs property for options)
Message: The following issue has been closed. Resolver: dion gillard Date: Wed, 15 Sep 2004 8:34 PM Fixed in 1.5.2/1.6 - View the issue: http://jira.codehaus.org/browse/MPSITE-15 Here is an overview of the issue: - Key: MPSITE-15 Summary: maven site:sshdeploy doesn't work all tars (needs property for options) Type: Bug Status: Closed Priority: Major Resolution: FIXED Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven-site-plugin Fix Fors: 1.6 Versions: 1.5.1 1.6 Assignee: dion gillard Reporter: M. Sean Gilligan Created: Wed, 15 Sep 2004 6:49 PM Updated: Wed, 15 Sep 2004 8:34 PM Environment: Mac OS X 10.3 client, Mac OS X Server 10.2 Description: The (only) tar installed on Mac OS X Server 10.2 does not support the 'U' option, so the site:sshdeploy goal doesn't work without installing a new tar command. Attached is a quick patch that allows the tar options to be configured in a properties file. The default setting is: maven.site.tar.options=xUvf (This problem could affect other BSDs and/or Solaris) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPSITE-10) Add property to configure tar verbose option
Message: The following issue has been closed. Resolver: dion gillard Date: Wed, 15 Sep 2004 8:35 PM Fixed by MPSITE-15 - View the issue: http://jira.codehaus.org/browse/MPSITE-10 Here is an overview of the issue: - Key: MPSITE-10 Summary: Add property to configure tar verbose option Type: Improvement Status: Closed Priority: Trivial Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-site-plugin Fix Fors: 1.6 Versions: 1.5 Assignee: Reporter: Carlos Sanchez Created: Thu, 24 Jun 2004 8:41 AM Updated: Wed, 15 Sep 2004 8:35 PM Description: This property allows hiding list of files processed - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/site/xdocs properties.xml changes.xml
dion2004/09/15 17:30:20 Modified:site plugin.properties plugin.jelly project.xml site/xdocs properties.xml changes.xml Log: MPSITE-15 Revision ChangesPath 1.5 +1 -0 maven-plugins/site/plugin.properties Index: plugin.properties === RCS file: /home/cvs/maven-plugins/site/plugin.properties,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- plugin.properties 4 Mar 2004 18:38:55 - 1.4 +++ plugin.properties 16 Sep 2004 00:30:19 - 1.5 @@ -27,6 +27,7 @@ maven.site.deploy.method=ssh maven.site.tar.executable=tar +maven.site.tar.options=xUvf maven.site.gunzip.executable=gunzip maven.username=USERNAME_NOT_SET 1.26 +1 -1 maven-plugins/site/plugin.jelly Index: plugin.jelly === RCS file: /home/cvs/maven-plugins/site/plugin.jelly,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- plugin.jelly 8 Mar 2004 11:08:41 - 1.25 +++ plugin.jelly 16 Sep 2004 00:30:19 - 1.26 @@ -143,7 +143,7 @@ - + 1.37 +1 -1 maven-plugins/site/project.xml Index: project.xml === RCS file: /home/cvs/maven-plugins/site/project.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- project.xml 11 Jul 2004 02:28:50 - 1.36 +++ project.xml 16 Sep 2004 00:30:19 - 1.37 @@ -23,7 +23,7 @@ 3 maven-site-plugin Maven Site Plugin - 1.5.1 + 1.5.2-SNAPSHOT Generate web site. Requires Maven 1.0 RC2. Generate web site http://maven.apache.org/reference/plugins/site/ 1.6 +10 -0 maven-plugins/site/xdocs/properties.xml Index: properties.xml === RCS file: /home/cvs/maven-plugins/site/xdocs/properties.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- properties.xml23 Aug 2004 21:09:01 - 1.5 +++ properties.xml16 Sep 2004 00:30:19 - 1.6 @@ -83,6 +83,16 @@ system has a default version of tar that is failing. + + maven.site.tar.options + Yes + +Specifies the options to use for 'tar' when deploying the site. +Defaults to xUvf. Override this property if your +system has a version of tar that is failing, e.g. it doesn't support the +U option. + + maven.site.gunzip.executable 1.20 +3 -0 maven-plugins/site/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/maven-plugins/site/xdocs/changes.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- changes.xml 11 Jul 2004 02:29:54 - 1.19 +++ changes.xml 16 Sep 2004 00:30:19 - 1.20 @@ -24,6 +24,9 @@ dIon Gillard + + Allow tar options as a property + Update commons-httpclient and commons-net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patches for tar options on site:sshdeploy
I just submitted a patch to maven-site-plugin to add a property for the tar options to be used on the server: http://jira.codehaus.org/browse/MPSITE-15 (My motivation is that OS X Server 10.2 doesn't seem to support the 'U' option, so I can't use site:sshdeploy to put my project documentation on my Intranet server.) There is another patch submitted to allow turning on/off the verbose option for tar: http://jira.codehaus.org/browse/MPSITE-10 The patch for MPSITE-15 will solve the user need in MPSITE-10 since it places the entire "options" argument of tar into a property. In any event, these two patches are closely related. Regards, Sean -- --- M. Sean Gilligan: 831-466-9788 x11 Catalla Systems, Inc. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMULTIPROJECT-39) Multiproject inheritance (again)
The following comment has been added to this issue: Author: Dan Tran Created: Wed, 15 Sep 2004 7:04 PM Body: Sorry, I have one more fact. If I go to the last node of the tree and do my normal build (not multiproject:install) My goal can see the properties I defined at the top node, which can be many levels up. - View this comment: http://jira.codehaus.org/browse/MPMULTIPROJECT-39?page=comments#action_24125 - View the issue: http://jira.codehaus.org/browse/MPMULTIPROJECT-39 Here is an overview of the issue: - Key: MPMULTIPROJECT-39 Summary: Multiproject inheritance (again) Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-multiproject-plugin Versions: 1.3 Assignee: dion gillard Reporter: John Taylor Created: Tue, 13 Jul 2004 9:38 AM Updated: Wed, 15 Sep 2004 7:04 PM Environment: WinXP Description: This may be a duplicate of http://jira.codehaus.org/browse/MPMULTIPROJECT-32 in which case I apologise. I'm finding that sub projects only inherit *properties* from one level deep if run via multiproject. Furthermore, certain "built-in" properties don't get inherited at all. In the attached code, sub inherits from base which inherits from basebase. When run as a multiproject from the root project (goal: doit->multiproject:clean), sub sees the props defined in base, but not basebase. Also, the property maven.repo.central, overridden in base, retains its default value of login.ibiblio.org However, running sub directly (from sub's folder with goal "clean") gives the correct behaviour. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMULTIPROJECT-39) Multiproject inheritance (again)
The following comment has been added to this issue: Author: Dan Tran Created: Wed, 15 Sep 2004 6:56 PM Body: Furthur more, If I get my sub tree to inherit from the root,rather then from its parent dir, I am build the subtree. - View this comment: http://jira.codehaus.org/browse/MPMULTIPROJECT-39?page=comments#action_24124 - View the issue: http://jira.codehaus.org/browse/MPMULTIPROJECT-39 Here is an overview of the issue: - Key: MPMULTIPROJECT-39 Summary: Multiproject inheritance (again) Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-multiproject-plugin Versions: 1.3 Assignee: dion gillard Reporter: John Taylor Created: Tue, 13 Jul 2004 9:38 AM Updated: Wed, 15 Sep 2004 6:56 PM Environment: WinXP Description: This may be a duplicate of http://jira.codehaus.org/browse/MPMULTIPROJECT-32 in which case I apologise. I'm finding that sub projects only inherit *properties* from one level deep if run via multiproject. Furthermore, certain "built-in" properties don't get inherited at all. In the attached code, sub inherits from base which inherits from basebase. When run as a multiproject from the root project (goal: doit->multiproject:clean), sub sees the props defined in base, but not basebase. Also, the property maven.repo.central, overridden in base, retains its default value of login.ibiblio.org However, running sub directly (from sub's folder with goal "clean") gives the correct behaviour. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMULTIPROJECT-39) Multiproject inheritance (again)
The following comment has been added to this issue: Author: Dan Tran Created: Wed, 15 Sep 2004 6:53 PM Body: I ran into the same problem where I have a tree of projects, a project can have multiproject. A project always inherit its parent dir project, which also inherits parernt's parent dir. This way all projects inherit the root project. So from the root, I can issue maven multiproject:install, it will tranverse all projects and build them nice , very nice. However, I go to middle of the tree and issue maven multiproject:build to build a sub tree Any properites I declare at the root project (top) are not seen. - View this comment: http://jira.codehaus.org/browse/MPMULTIPROJECT-39?page=comments#action_24123 - View the issue: http://jira.codehaus.org/browse/MPMULTIPROJECT-39 Here is an overview of the issue: - Key: MPMULTIPROJECT-39 Summary: Multiproject inheritance (again) Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-multiproject-plugin Versions: 1.3 Assignee: dion gillard Reporter: John Taylor Created: Tue, 13 Jul 2004 9:38 AM Updated: Wed, 15 Sep 2004 6:53 PM Environment: WinXP Description: This may be a duplicate of http://jira.codehaus.org/browse/MPMULTIPROJECT-32 in which case I apologise. I'm finding that sub projects only inherit *properties* from one level deep if run via multiproject. Furthermore, certain "built-in" properties don't get inherited at all. In the attached code, sub inherits from base which inherits from basebase. When run as a multiproject from the root project (goal: doit->multiproject:clean), sub sees the props defined in base, but not basebase. Also, the property maven.repo.central, overridden in base, retains its default value of login.ibiblio.org However, running sub directly (from sub's folder with goal "clean") gives the correct behaviour. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPSITE-15) maven site:sshdeploy doesn't work all tars (needs property for options)
The following issue has been updated: Updater: M. Sean Gilligan (mailto:[EMAIL PROTECTED]) Date: Wed, 15 Sep 2004 6:51 PM Comment: Patch for plugin.jelly and plugin.properties is attached. Changes: Attachment changed to maven-site-plugin_patch.diff - For a full history of the issue, see: http://jira.codehaus.org/browse/MPSITE-15?page=history - View the issue: http://jira.codehaus.org/browse/MPSITE-15 Here is an overview of the issue: - Key: MPSITE-15 Summary: maven site:sshdeploy doesn't work all tars (needs property for options) Type: Bug Status: Unassigned Priority: Major Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven-site-plugin Versions: 1.5.1 1.6 Assignee: Reporter: M. Sean Gilligan Created: Wed, 15 Sep 2004 6:49 PM Updated: Wed, 15 Sep 2004 6:51 PM Environment: Mac OS X 10.3 client, Mac OS X Server 10.2 Description: The (only) tar installed on Mac OS X Server 10.2 does not support the 'U' option, so the site:sshdeploy goal doesn't work without installing a new tar command. Attached is a quick patch that allows the tar options to be configured in a properties file. The default setting is: maven.site.tar.options=xUvf (This problem could affect other BSDs and/or Solaris) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPSITE-15) maven site:sshdeploy doesn't work all tars (needs property for options)
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPSITE-15 Here is an overview of the issue: - Key: MPSITE-15 Summary: maven site:sshdeploy doesn't work all tars (needs property for options) Type: Bug Status: Unassigned Priority: Major Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven-site-plugin Versions: 1.5.1 1.6 Assignee: Reporter: M. Sean Gilligan Created: Wed, 15 Sep 2004 6:49 PM Updated: Wed, 15 Sep 2004 6:49 PM Environment: Mac OS X 10.3 client, Mac OS X Server 10.2 Description: The (only) tar installed on Mac OS X Server 10.2 does not support the 'U' option, so the site:sshdeploy goal doesn't work without installing a new tar command. Attached is a quick patch that allows the tar options to be configured in a properties file. The default setting is: maven.site.tar.options=xUvf (This problem could affect other BSDs and/or Solaris) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPANT-19) Overwrites existing build.xml files without warning
The following comment has been added to this issue: Author: Arnaud HERITIER Created: Wed, 15 Sep 2004 6:06 PM Body: I can try to add a warning if the file already exists but I'm not in favor to change the default file name. You can use the property 'maven.ant.generatebuild.file' to define yourself another name for this file. - View this comment: http://jira.codehaus.org/browse/MPANT-19?page=comments#action_24121 - View the issue: http://jira.codehaus.org/browse/MPANT-19 Here is an overview of the issue: - Key: MPANT-19 Summary: Overwrites existing build.xml files without warning Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ant-plugin Versions: 1.8.1 Assignee: Arnaud HERITIER Reporter: Richard Easterling Created: Wed, 15 Sep 2004 3:16 AM Updated: Wed, 15 Sep 2004 6:06 PM Description: This plugin has caused much grief by overwriting existing build.xml files without warning. The default build name should be changed to something less commonly used, 'build-from-pom.xml' for example. Or the user should be prompted to confirm overwriting on the command line. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENPROXY-13) SNAPSHOT artifacts are cached
The following comment has been added to this issue: Author: Ben Walding Created: Wed, 15 Sep 2004 5:38 PM Body: Are you running under a French language pack or something like that? It looks like Jetty's language handling might be sub-par. I'll take a better look today hopefully. - View this comment: http://jira.codehaus.org/browse/MAVENPROXY-13?page=comments#action_24120 - View the issue: http://jira.codehaus.org/browse/MAVENPROXY-13 Here is an overview of the issue: - Key: MAVENPROXY-13 Summary: SNAPSHOT artifacts are cached Type: Bug Status: Open Priority: Critical Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-component-proxy Assignee: Ben Walding Reporter: Joerg Schaible Created: Thu, 9 Sep 2004 5:56 AM Updated: Wed, 15 Sep 2004 5:38 PM Description: Hi Ben, I've configured the Maven-proxy to use Codehaus' repo, since I want to use the Pico/Nano-SNAPSHOTS. These are generated by DamageControl after each commit. Unfortunately the Maven-proxy seems not to look for newer snapshots, because all of them are of an old date (first time download) in Maven-proxy's cache. Since this happens silently, it is absolutely not transparent for any user nor the expected behaviour. Regards, Jörg - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/aspectj/xdocs index.xml
carlos 2004/09/15 13:15:43 Modified:aspectj/xdocs index.xml Log: Added weaveInto clarification Revision ChangesPath 1.9 +1 -0 maven-plugins/aspectj/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/maven-plugins/aspectj/xdocs/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 29 Jun 2004 08:54:42 - 1.8 +++ index.xml 15 Sep 2004 20:15:43 - 1.9 @@ -100,6 +100,7 @@ ]]> + The jar contents, with classes weaved, are extracted to maven.build.dest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENPROXY-13) SNAPSHOT artifacts are cached
The following comment has been added to this issue: Author: Joerg Schaible Created: Wed, 15 Sep 2004 10:51 AM Body: Just detected in the log of maven-proxy, that the reason for not downloading a newer SNAPSHOT might be causewd by following log entry. The date is the date of the file in the proxy's cache on the local file system. Any idea how to circumvent the problem? === %< 16:23:07.355 WARN!! Exception for /picocontainer/jars/picocontainer-1.1-SNAPSHOT.jar java.lang.IllegalArgumentException: Cannot convert date: Fr, 03-Sep-04 09:57:14 at org.mortbay.http.HttpFields.getDateField(HttpFields.java:916) at org.mortbay.http.HttpMessage.getDateField(HttpMessage.java:457) at org.mortbay.jetty.servlet.ServletHttpRequest.getDateHeader(ServletHttpRequest.java:275) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360) at org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:651) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.http.HttpServer.service(HttpServer.java:863) at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) 108732 [PoolThread-0] INFO maven.proxy.RepositoryServlet - Received request: /picocontainer/jars/picocontainer-1.1-SNAPSHOT.jar.md5 139477 [PoolThread-0] WARN maven.proxy.RepositoryServlet - Could not find upstream resource :/picocontainer/jars/picocontainer-1.1-SNAPSHOT.jar.md5 === %< - View this comment: http://jira.codehaus.org/browse/MAVENPROXY-13?page=comments#action_24112 - View the issue: http://jira.codehaus.org/browse/MAVENPROXY-13 Here is an overview of the issue: - Key: MAVENPROXY-13 Summary: SNAPSHOT artifacts are cached Type: Bug Status: Open Priority: Critical Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-component-proxy Assignee: Ben Walding Reporter: Joerg Schaible Created: Thu, 9 Sep 2004 5:56 AM Updated: Wed, 15 Sep 2004 10:51 AM Description: Hi Ben, I've configured the Maven-proxy to use Codehaus' repo, since I want to use the Pico/Nano-SNAPSHOTS. These are generated by DamageControl after each commit. Unfortunately the Maven-proxy seems not to look for newer snapshots, because all of them are of an old date (first time download) in Maven-proxy's cache. Since this happens silently, it is absolutely not transparent for any user nor the expected behaviour. Regards, Jörg - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPDASHBOARD-12) New aggregator : JCoverage total code lines
The following issue has been updated: Updater: Thomas Recloux (mailto:[EMAIL PROTECTED]) Date: Wed, 15 Sep 2004 9:40 AM Comment: The aggregator Changes: Attachment changed to jcoveragelitot.jelly - For a full history of the issue, see: http://jira.codehaus.org/browse/MPDASHBOARD-12?page=history - View the issue: http://jira.codehaus.org/browse/MPDASHBOARD-12 Here is an overview of the issue: - Key: MPDASHBOARD-12 Summary: New aggregator : JCoverage total code lines Type: New Feature Status: Unassigned Priority: Major Original Estimate: 5 minutes Time Spent: Unknown Remaining: 5 minutes Project: maven-dashboard-plugin Versions: 1.5 Assignee: Reporter: Thomas Recloux Created: Wed, 15 Sep 2004 9:39 AM Updated: Wed, 15 Sep 2004 9:40 AM Description: Hello, I've developped this new aggregator, it computes the number of code lines from jcoverage report. I'll attach the patch file ant the aggregator jsl file. Thomas - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPDASHBOARD-12) New aggregator : JCoverage total code lines
The following issue has been updated: Updater: Thomas Recloux (mailto:[EMAIL PROTECTED]) Date: Wed, 15 Sep 2004 9:39 AM Comment: The patch file Changes: Attachment changed to patch.txt - For a full history of the issue, see: http://jira.codehaus.org/browse/MPDASHBOARD-12?page=history - View the issue: http://jira.codehaus.org/browse/MPDASHBOARD-12 Here is an overview of the issue: - Key: MPDASHBOARD-12 Summary: New aggregator : JCoverage total code lines Type: New Feature Status: Unassigned Priority: Major Original Estimate: 5 minutes Time Spent: Unknown Remaining: 5 minutes Project: maven-dashboard-plugin Versions: 1.5 Assignee: Reporter: Thomas Recloux Created: Wed, 15 Sep 2004 9:39 AM Updated: Wed, 15 Sep 2004 9:39 AM Description: Hello, I've developped this new aggregator, it computes the number of code lines from jcoverage report. I'll attach the patch file ant the aggregator jsl file. Thomas - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPDASHBOARD-12) New aggregator : JCoverage total code lines
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPDASHBOARD-12 Here is an overview of the issue: - Key: MPDASHBOARD-12 Summary: New aggregator : JCoverage total code lines Type: New Feature Status: Unassigned Priority: Major Original Estimate: 5 minutes Time Spent: Unknown Remaining: 5 minutes Project: maven-dashboard-plugin Versions: 1.5 Assignee: Reporter: Thomas Recloux Created: Wed, 15 Sep 2004 9:39 AM Updated: Wed, 15 Sep 2004 9:39 AM Description: Hello, I've developped this new aggregator, it computes the number of code lines from jcoverage report. I'll attach the patch file ant the aggregator jsl file. Thomas - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reflexion about a dashboard aggregator
> -Original Message- > From: Thomas Recloux [mailto:[EMAIL PROTECTED] > Sent: mercredi 15 septembre 2004 13:53 > To: Maven Developers List > Subject: Re: Reflexion about a dashboard aggregator > > Vincent Massol wrote: > > > There is already one jcoverage aggregator but it's not doing LOC > computation > > (see http://tinyurl.com/6824w). > > I know, it I developped it :-) Oh, sorry! :-) Ah, ok, that's why your name was reminding me of something but I could not fathom it... :-) I should have checked. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reflexion about a dashboard aggregator
Vincent Massol wrote: > There is already one jcoverage aggregator but it's not doing LOC computation > (see http://tinyurl.com/6824w). I know, it I developped it :-) > If you develop one please create a JIRA issue and attach the patch to it > (please provide a patch against CVS HEAD). OK. -- Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPCHANGES-20) Mispelled attribute in documentation
Message: The following issue has been closed. Resolver: Vincent Massol Date: Wed, 15 Sep 2004 7:08 AM Done. Thanks. - View the issue: http://jira.codehaus.org/browse/MPCHANGES-20 Here is an overview of the issue: - Key: MPCHANGES-20 Summary: Mispelled attribute in documentation Type: Improvement Status: Closed Priority: Trivial Resolution: FIXED Original Estimate: 1 minute Time Spent: Unknown Remaining: 1 minute Project: maven-changes-plugin Fix Fors: 1.6 Assignee: Vincent Massol Reporter: Christian Madsen Created: Wed, 15 Sep 2004 6:58 AM Updated: Wed, 15 Sep 2004 7:09 AM Description: Hi, There is a little error in the example on the documentation page http://maven.apache.org/reference/plugins/changes/index.html In fact the attribute issues="JIRA-XXX" is mispelled and should be issue="JIRA-XXX" (without the 's'). Thanks, - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/changes/xdocs index.xml changes.xml
vmassol 2004/09/15 04:05:12 Modified:changes/xdocs index.xml changes.xml Log: MPCHANGES-20. Fixed typo in changes.xml example on plugin web site. Revision ChangesPath 1.5 +1 -1 maven-plugins/changes/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/maven-plugins/changes/xdocs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 20 Apr 2004 19:39:52 - 1.4 +++ index.xml 15 Sep 2004 11:05:11 - 1.5 @@ -55,7 +55,7 @@ Added blah blah. - + Corrected bug blah blah. 1.30 +3 -0 maven-plugins/changes/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/maven-plugins/changes/xdocs/changes.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- changes.xml 6 Aug 2004 21:40:46 - 1.29 +++ changes.xml 15 Sep 2004 11:05:11 - 1.30 @@ -25,6 +25,9 @@ + +Fixed typo in changes.xml example on plugin web site. + Close output file in ReleaseVersion.releaseVersion() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHANGES-20) Mispelled attribute in documentation
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPCHANGES-20 Here is an overview of the issue: - Key: MPCHANGES-20 Summary: Mispelled attribute in documentation Type: Improvement Status: Unassigned Priority: Trivial Original Estimate: 1 minute Time Spent: Unknown Remaining: 1 minute Project: maven-changes-plugin Assignee: Reporter: Christian Madsen Created: Wed, 15 Sep 2004 6:58 AM Updated: Wed, 15 Sep 2004 6:58 AM Description: Hi, There is a little error in the example on the documentation page http://maven.apache.org/reference/plugins/changes/index.html In fact the attribute issues="JIRA-XXX" is mispelled and should be issue="JIRA-XXX" (without the 's'). Thanks, - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPEAR-20) Deploy error because of display name
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPEAR-20 Here is an overview of the issue: - Key: MPEAR-20 Summary: Deploy error because of display name Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ear-plugin Versions: 1.5 Assignee: Reporter: Joerg Schaible Created: Wed, 15 Sep 2004 6:32 AM Updated: Wed, 15 Sep 2004 6:32 AM Environment: IONA Orbix Application Server Platform, Windows Description: The IONA Orbix J2EE server uses the display name as root directory for the exploaded EAR. Unfortunately this contains by default a colon ("${pom.groupId}:${pom.artifactId}") for a generated application.xml which is obviously not an allowed character for files in Windows. This default value should be set to something, that does not break any app server. Proposal: dot - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reflexion about a dashboard aggregator
> -Original Message- > From: Thomas Recloux [mailto:[EMAIL PROTECTED] > Sent: mercredi 15 septembre 2004 12:09 > To: Maven Developers List > Subject: Re: Reflexion about a dashboard aggregator > > Vincent, > > > I think that it's such a good idea that it is already implemented... :-) > > > > Check the Dashboard Maven plugin: > > http://maven.apache.org/reference/plugins/dashboard/aggregators.html > > Oooops, I did not the cloverloc aggregator. > > As I do not use clover ut Jcoverage, I will code the jcoverage > aggregator and send it to you. > > Do you prefer to receive it in your mailbox or in Jira ? There is already one jcoverage aggregator but it's not doing LOC computation (see http://tinyurl.com/6824w). If you develop one please create a JIRA issue and attach the patch to it (please provide a patch against CVS HEAD). Thanks Thomas -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reflexion about a dashboard aggregator
Vincent, > I think that it's such a good idea that it is already implemented... :-) > > Check the Dashboard Maven plugin: > http://maven.apache.org/reference/plugins/dashboard/aggregators.html Oooops, I did not the cloverloc aggregator. As I do not use clover ut Jcoverage, I will code the jcoverage aggregator and send it to you. Do you prefer to receive it in your mailbox or in Jira ? -- Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reflexion about a dashboard aggregator
> -Original Message- > From: Thomas Recloux [mailto:[EMAIL PROTECTED] > Sent: mercredi 15 septembre 2004 11:58 > To: [EMAIL PROTECTED] > Subject: Reflexion about a dashboard aggregator > > Hello, > > I think that a dashboard aggregator which would compute the total > number of code lines could be a good a good idea. > > But on which plugin could this aggregator be based ? > > I see three solutions : >- Clover XML report >- JCoverage XML report >- Parsing java files (existing tool ?) > > For the moment, I think that using Clover and JCoverage informations > is the simplier way but it will not count javadoc or java comments. > > What do you think of this stuff ? I think that it's such a good idea that it is already implemented... :-) Check the Dashboard Maven plugin: http://maven.apache.org/reference/plugins/dashboard/aggregators.html -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reflexion about a dashboard aggregator
Hello, I think that a dashboard aggregator which would compute the total number of code lines could be a good a good idea. But on which plugin could this aggregator be based ? I see three solutions : - Clover XML report - JCoverage XML report - Parsing java files (existing tool ?) For the moment, I think that using Clover and JCoverage informations is the simplier way but it will not count javadoc or java comments. What do you think of this stuff ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1446) Dependencies with identical artifactId, but different types
The following comment has been added to this issue: Author: Brett Porter Created: Wed, 15 Sep 2004 3:30 AM Body: why? It's better to fix the bug. - View this comment: http://jira.codehaus.org/browse/MAVEN-1446?page=comments#action_24099 - View the issue: http://jira.codehaus.org/browse/MAVEN-1446 Here is an overview of the issue: - Key: MAVEN-1446 Summary: Dependencies with identical artifactId, but different types Type: Bug Status: Closed Priority: Major Resolution: DUPLICATE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.0 Assignee: Reporter: Richard Easterling Created: Wed, 15 Sep 2004 2:49 AM Updated: Wed, 15 Sep 2004 3:30 AM Description: The central repository contains spring-1.0.jar and spring-1.0.tld entries under the springframework groupId. This should not be allowed because if you enter: spring springframework 1.0.2 tld spring springframework 1.0.2 The second dependency (i.e. the jar file) can't be accessed from the POM code, it is simply ignored. The POM could should raise an excpetion if it finds a duplicate artifactId. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1446) Dependencies with identical artifactId, but different types
The following comment has been added to this issue: Author: Carlos Sanchez Created: Wed, 15 Sep 2004 3:16 AM Body: The tlds should be renamed in the repo to something like spring-tld-1.0.tld - View this comment: http://jira.codehaus.org/browse/MAVEN-1446?page=comments#action_24096 - View the issue: http://jira.codehaus.org/browse/MAVEN-1446 Here is an overview of the issue: - Key: MAVEN-1446 Summary: Dependencies with identical artifactId, but different types Type: Bug Status: Closed Priority: Major Resolution: DUPLICATE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.0 Assignee: Reporter: Richard Easterling Created: Wed, 15 Sep 2004 2:49 AM Updated: Wed, 15 Sep 2004 3:16 AM Description: The central repository contains spring-1.0.jar and spring-1.0.tld entries under the springframework groupId. This should not be allowed because if you enter: spring springframework 1.0.2 tld spring springframework 1.0.2 The second dependency (i.e. the jar file) can't be accessed from the POM code, it is simply ignored. The POM could should raise an excpetion if it finds a duplicate artifactId. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPANT-19) Overwrites existing build.xml files without warning
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPANT-19 Here is an overview of the issue: - Key: MPANT-19 Summary: Overwrites existing build.xml files without warning Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ant-plugin Versions: 1.8.1 Assignee: Arnaud HERITIER Reporter: Richard Easterling Created: Wed, 15 Sep 2004 3:16 AM Updated: Wed, 15 Sep 2004 3:16 AM Description: This plugin has caused much grief by overwriting existing build.xml files without warning. The default build name should be changed to something less commonly used, 'build-from-pom.xml' for example. Or the user should be prompted to confirm overwriting on the command line. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-1446) Dependencies with identical artifactId, but different types
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/browse/MAVEN-1446 Here is an overview of the issue: - Key: MAVEN-1446 Summary: Dependencies with identical artifactId, but different types Type: Bug Status: Closed Priority: Major Resolution: DUPLICATE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.0 Assignee: Reporter: Richard Easterling Created: Wed, 15 Sep 2004 2:49 AM Updated: Wed, 15 Sep 2004 3:16 AM Description: The central repository contains spring-1.0.jar and spring-1.0.tld entries under the springframework groupId. This should not be allowed because if you enter: spring springframework 1.0.2 tld spring springframework 1.0.2 The second dependency (i.e. the jar file) can't be accessed from the POM code, it is simply ignored. The POM could should raise an excpetion if it finds a duplicate artifactId. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1087) Dependency type should participate in equals() and hashcode()
The following comment has been added to this issue: Author: Julien Kirch Created: Wed, 15 Sep 2004 3:09 AM Body: I observed a side effect of the patch, I'm not sure it's the one that causes the bug on cactus but this one will probably requires a look and/or some changes in the plugins : in a script we are getting a dependency of type zip, and we were accessing it with a : (dependency of group "fooGroup" and of name "barName") with the patch, this leads to an empty dependency, so the code is now : hope this may help - View this comment: http://jira.codehaus.org/browse/MAVEN-1087?page=comments#action_24094 - View the issue: http://jira.codehaus.org/browse/MAVEN-1087 Here is an overview of the issue: - Key: MAVEN-1087 Summary: Dependency type should participate in equals() and hashcode() Type: Bug Status: Unassigned Priority: Major Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven Components: model Fix Fors: 1.1 Versions: 1.0 Assignee: Reporter: Eric Bottard Created: Mon, 22 Dec 2003 3:48 PM Updated: Wed, 15 Sep 2004 3:09 AM Description: I was trying to bundle taglibs in a war project when i stumbled into this unexpected behavior : for each and every taglib in my web-app, either the jar file or the tld got copied to the target web-app, but I could not get them to be copied together. After a moment I realized that the dependency for a given taglib (one jar and one tld) had the same artifactId but different types (jar and tld). A quick hack in the war plugin shows that the forEach loop only sees one of the two. So I guess that the dependency type should participate in equals() and hashcode() for a dependency (or modify the getId() of Dependency, but I don't know the other impacts). - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-120) Faster execution of xdoc:jelly-transform with ant:parallel
The following comment has been added to this issue: Author: Matthias Kerkhoff Created: Wed, 15 Sep 2004 3:04 AM Body: I suggested ant:parallel because its threadsPerProcessor attribute. I'm not sure how to model a similar behaviour with the jelly:threads taglib. - View this comment: http://jira.codehaus.org/browse/MPXDOC-120?page=comments#action_24093 - View the issue: http://jira.codehaus.org/browse/MPXDOC-120 Here is an overview of the issue: - Key: MPXDOC-120 Summary: Faster execution of xdoc:jelly-transform with ant:parallel Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Assignee: Arnaud HERITIER Reporter: Matthias Kerkhoff Created: Tue, 14 Sep 2004 6:07 AM Updated: Wed, 15 Sep 2004 3:04 AM Description: In larger projects or in multiproject builds transforming the xdoc files into html may take a significant amount of time. After looking into the plugin.jelly - especially into the definition of the doc:performJsl tag - I would think that there is an opportunity to distribute the transformation workload over multiple threads/cpus. The best candidate for doing so would be the for-each loop over docFiles (lines 328-367). It should possible to reduce the overall transformation time with the ant:parallel task. The effect should be noticeable on multiprocessor build machines and/or builds which transform many xdoc files, as they may for example occur in conjunction with the statcvs-plugin. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]