Results of clean bootstrap at 20030802-2200
Last 500 lines of a clean bootstrap build of maven at 20030802-2200 [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/was40/target/maven-was40-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Webserver Plugin [exec] | Memory: 7M/15M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 1 file to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes/plugin-resources [exec] Copying 4 files to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/maven-webserver-plugin-2.0-dev.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Wizard Plug-in [exec] | Memory: 7M/15M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 2 files to /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/maven-wizard-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Word to HTML Plug-in [exec] | Memory: 7M/15M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 1 file to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes/plugin-resources [exec] Copying 4 files to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/maven-word2html-plugin-1.3-SNAPSHOT.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec]
[Apache Newsletter Draft] News from Apache Maven Project in July, 2003
Dear Apache Maven Development Team, (http://maven.apache.org/) Hello, I am now in the process of preparing the first all-Apache-wide newsletter. http://www.apache.org/newsletter/ 'The Apache Newsletter Issue 1' ... ASF-wide-newsletter of July 2003, which will be published in the middle of August 2003. Please feel free to write statement/comment/article etc. to the Apache Newsletter (Issue 1) using ApacheWiki or in this mailing list. Hope to hear from you. http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 This 'The Apache Newsletter' will be published as a result of the outgrowth of the previous 'Jakarta Newsletter' and 'Apache Newsletter' can now cover all the projects under apache.org including infrastructure, incubator, xml, webservice, PHP, et cetra. == WHAT WAS JAKARTA NEWSLETTER?? - http://jakarta.apache.org/site/news/ 'The Apache Newsletter Issue 1' will be appeared at http://www.apache.org/newsletter/200307.html and the editorial deadline will be 00:00 GMT, 9th August. ApacheWiki (http://nagoya.apache.org/wiki/apachewiki.cgi) had been already set up. If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 and fill up what you want to append in. If there's nothing news-worthy on your project, then please write something you *hope* (e.g. XX project will release FINAL version of XX product in the middle of August, etc etc). If you have been voted in warmly as a new committer in ASF the last month (July) please add your name to the list on ApacheWiki. If your project really want some 'ADVERTISEMENT' (to recruit new comers, etc etc), please write nice and catchy blurb at the 'advertisement' section so that it will attract the readers' attentions. Probably, the former newsletter final draft and newsletter itself (Jakarta Newsletter Issue 9) will give you some hints in writing the articles. cf. http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaNewsletterDrafts/Issue9 http://jakarta.apache.org/site/news/200305.html If you have any questions about this, please send your messages to [EMAIL PROTECTED] or this mailing list. This Newsletter will be published as webpage and be announced at [EMAIL PROTECTED] (the ASF-wide announcement list) To subscribe to [EMAIL PROTECTED], please follow this instruction: http://www.apache.org/foundation/mailinglists.html#foundation-announce Hope to hear from Apache Maven Project!! (If you feel hesitation in writing articles on ApacheWiki, please write your memo in this mailing list or give me a note). http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) P.S. Contributions from anyone are cordially invited!! - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-647) Maven built from CVS no longer recognizes pom property
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647
Here is an overview of the issue:
-
Key: MAVEN-647
Summary: Maven built from CVS no longer recognizes pom property
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Versions:
1.0-rc1
Assignee:
Reporter: Jeff French
Created: Sun, 3 Aug 2003 9:36 AM
Updated: Sun, 3 Aug 2003 9:36 AM
Environment: OS: Linux Mandrake 7.2, kernel 2.2.17-21mdk
Java: 1.4.0
Description:
Maven built from CVS will no longer recognize when I reference the
pom.build.sourceDirectory property from within the project.properties file. This is as
of Sun Aug 3 08:54:18 CDT 2003.
I have this line in project.properties:
admin.dir = ${pom.build.sourceDirectory}/admin
and this in project.xml:
project
...
build
sourceDirectorysrc/sourceDirectory
...
/build
/project
The test:test-resources preGoal in maven.xml is doing a copy where it references
${admin.dir}. I reloaded each version of Maven and wiped out my ~/.maven directory
prior to running each test.
A build using b10 is successful. Here is a summary of the exception I get when using
the CVS version. So as not to clog up the description, I'll submit the full output as
an attachment.
BUILD FAILED
Unable to obtain goal [EMAIL PROTECTED]test:test-resources] -- null:32:28: copy
/home/jeff/work/test/mvtests/mvemrapi/${pom.build.sourceDirectory}/admin not found.
-
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: (MAVEN-647) Maven built from CVS no longer recognizes pom property
The following issue has been updated:
Updater: Jeff French (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 9:37 AM
Comment:
Full output of maven -Dmaven.test.skip=true clean jar:jar
Changes:
Attachment changed to fromcvs.log
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647
Here is an overview of the issue:
-
Key: MAVEN-647
Summary: Maven built from CVS no longer recognizes pom property
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Versions:
1.0-rc1
Assignee:
Reporter: Jeff French
Created: Sun, 3 Aug 2003 9:36 AM
Updated: Sun, 3 Aug 2003 9:37 AM
Environment: OS: Linux Mandrake 7.2, kernel 2.2.17-21mdk
Java: 1.4.0
Description:
Maven built from CVS will no longer recognize when I reference the
pom.build.sourceDirectory property from within the project.properties file. This is as
of Sun Aug 3 08:54:18 CDT 2003.
I have this line in project.properties:
admin.dir = ${pom.build.sourceDirectory}/admin
and this in project.xml:
project
...
build
sourceDirectorysrc/sourceDirectory
...
/build
/project
The test:test-resources preGoal in maven.xml is doing a copy where it references
${admin.dir}. I reloaded each version of Maven and wiped out my ~/.maven directory
prior to running each test.
A build using b10 is successful. Here is a summary of the exception I get when using
the CVS version. So as not to clog up the description, I'll submit the full output as
an attachment.
BUILD FAILED
Unable to obtain goal [EMAIL PROTECTED]test:test-resources] -- null:32:28: copy
/home/jeff/work/test/mvtests/mvemrapi/${pom.build.sourceDirectory}/admin not found.
-
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]
IntelliJ plugin
Hi, Is anyone working on the IDEA plugin? dIon and Kurt are listed in the POM, but no one owns it according to the Wiki page for plugin ownership. I'm currently working on pulling the files out into templates, and creating version 4 ipr, iws and iml templates for Aurora, while I wait for CVS HEAD to settle down. Cheers, Brett -- Brett Porter Team Leader, Core Systems f2 network ~ everything essential
Re: is HEAD relatively safe to use again?
No. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Colin Sampaleanu [EMAIL PROTECTED] wrote on 02/08/2003 05:39:08 AM: I know after the refactoring last week it was not recommended that HEAD be touched for a while. Is it relatively usable again? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/java/org/apache/maven/project Project.java
dion2003/08/03 18:11:14
Modified:src/java/org/apache/maven/plugin JellyPlugin.java
PluginManager.java
src/java/org/apache/maven/verifier DependencyVerifier.java
src/java/org/apache/maven Maven.java
ArtifactListBuilder.java
src/java/org/apache/maven/project Project.java
Log:
More reworking to include JellyPlugin
Revision ChangesPath
1.2 +61 -5 maven/src/java/org/apache/maven/plugin/JellyPlugin.java
Index: JellyPlugin.java
===
RCS file: /home/cvs/maven/src/java/org/apache/maven/plugin/JellyPlugin.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JellyPlugin.java 1 Aug 2003 07:39:24 - 1.1
+++ JellyPlugin.java 4 Aug 2003 01:11:13 - 1.2
@@ -30,8 +30,7 @@
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
- * 5. Products derived from this software may not be called Apache,
- *Apache Maven, nor may Apache appear in their name, without
+ * 5. Products derived from this software may not be called Apache, *Apache
Maven, nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
@@ -61,9 +60,11 @@
import java.net.MalformedURLException;
import org.apache.commons.jelly.Script;
+import org.apache.maven.MavenException;
import org.apache.maven.jelly.JellyUtils;
import org.apache.maven.jelly.MavenJellyContext;
import org.apache.maven.project.Project;
+import org.apache.maven.util.Expand;
import org.apache.maven.verifier.ChecksumVerificationException;
import org.apache.maven.verifier.RepoConfigException;
import org.apache.maven.verifier.UnsatisfiedDependencyException;
@@ -81,7 +82,13 @@
/** the id of the plugin */
private String id;
+
+/** the jar file the plugin was extracted from */
+private File jarFile;
+/** the directory to unpack the plugin into */
+private File unpackDirectory;
+
/** the directory the plugin is installed into */
private File directory;
@@ -134,6 +141,10 @@
*/
public File getDirectory()
{
+if (directory == null unpackDirectory != null)
+{
+directory = new File(unpackDirectory, id);
+}
return directory;
}
@@ -159,7 +170,7 @@
public File getScriptFile()
{
if (scriptFile == null) {
-scriptFile = new File( directory, plugin.jelly);
+scriptFile = new File( getDirectory(), plugin.jelly);
}
return scriptFile;
}
@@ -170,7 +181,7 @@
public File getDescriptor()
{
if (descriptor == null) {
-descriptor = new File( directory, project.xml);
+descriptor = new File( getDirectory(), project.xml);
}
return descriptor;
}
@@ -182,7 +193,7 @@
{
if (processedMarker == null)
{
-processedMarker = new File(directory, .processed);
+processedMarker = new File(getDirectory(), .processed);
}
return processedMarker;
}
@@ -272,5 +283,50 @@
compiledScript = JellyUtils.compileScript( getScriptFile(), context );
}
return compiledScript;
+}
+/**
+ * @param file the jar file containing the plugin
+ */
+public void setJarFile(File file)
+{
+jarFile = file;
+}
+
+/**
+ * @param file the directory to unpack the plugin into
+ */
+public void setUnpackDirectory(File file)
+{
+unpackDirectory = file;
+}
+
+/**
+ */
+public void unpack() throws MavenException
+{
+File unzipDir = getDirectory();
+
+// if there's no directory, or the jar is newer, expand the jar
+if ( !unzipDir.exists()
+|| jarFile.lastModified() unzipDir.lastModified() )
+{
+File processed = getProcessedMarker();
+if ( processed.exists() )
+{
+processed.delete();
+}
+
+try
+{
+Expand unzipper = new Expand();
+unzipper.setSrc( jarFile );
+unzipper.setDest( unzipDir );
+unzipper.execute();
+}
+catch ( IOException e )
+{
+throw new MavenException( Unable to extract plugin: + jarFile, e
);
+}
+}
}
}
1.59 +139
[jira] Updated: (MAVEN-155) plugin-dependency element
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 8:17 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-155page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-155 Here is an overview of the issue: - Key: MAVEN-155 Summary: plugin-dependency element Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: Requested POM Additions Fix Fors: 1.0-final Versions: 1.0-beta-8 Assignee: Reporter: tim stephenson Created: Thu, 21 Nov 2002 5:16 PM Updated: Sun, 3 Aug 2003 8:17 PM Description: I would like to be able to distribute a project.xml and maven.xml to the rest of the dev team that employed a plugin they have no knowledge of (say the great new j2ee plugins). If I could specifu in the POM a plugin dependency element and have maven download it from the remote repository if it is not found that would be great! I know it requires more than just the POM change but I thought I'd start with that since Jason was asking for thoughts something like this: dependencies ... plugin-dependency idmaven-ear-plugin/id version1.1/version ... /plugin-dependency ... /dependencies - 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: is HEAD relatively safe to use again?
On Fri, 2003-08-01 at 15:39, Colin Sampaleanu wrote: I know after the refactoring last week it was not recommended that HEAD be touched for a while. Is it relatively usable again? No, wait until further notice. It was put in to show the code, I wasn't going to check it in and again I wish I didn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Results of clean bootstrap at 20030801-2200
Last 500 lines of a clean bootstrap build of maven at 20030801-2200 [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/was40/target/maven-was40-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Webserver Plugin [exec] | Memory: 14M/17M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 1 file to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes/plugin-resources [exec] Copying 4 files to /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/webserver/target/maven-webserver-plugin-2.0-dev.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Wizard Plug-in [exec] | Memory: 14M/17M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 2 files to /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/wizard/target/maven-wizard-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec] + [exec] | Building Maven Word to HTML Plug-in [exec] | Memory: 14M/17M [exec] + [exec] clean: [exec] clean:clean: [exec] clean:clean: [exec] clean: [exec] plugin: [exec] plugin: [exec] jar:jar: [exec] test:test: [exec] test:compile: [exec] java:compile: [exec] java:prepare-filesystem: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] java:compile: [exec] [echo] Compiling to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] java:jar-resources: [exec] Copying 1 file to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes/plugin-resources [exec] Copying 4 files to /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/classes [exec] test:prepare-filesystem: [exec] test:prepare-filesystem: [exec] test:test-resources: [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test sources to compile. [exec] test:test: [exec] jar:jar: [exec] [jar] Building jar: /usr/local/builds/maven/src/maven/src/plugins-build/word2html/target/maven-word2html-plugin-1.3-SNAPSHOT.jar [exec] [copy] Copying 1 file to /home/tirsen/.maven/repository/maven/jars [exec]
[jira] Commented: (MAVEN-646) reports dont seem to be merged with parent pom
The following comment has been added to this issue: Author: dion gillard Created: Sun, 3 Aug 2003 8:30 PM Body: There is no concept of 'merge' in project inheritance, except for dependencies. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-646 Here is an overview of the issue: - Key: MAVEN-646 Summary: reports dont seem to be merged with parent pom Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: core Assignee: Reporter: gilles dodinet Created: Sat, 2 Aug 2003 4:45 AM Updated: Sat, 2 Aug 2003 4:45 AM Description: i have three poms, say pomA pomB and pomC, that all extend parentPom. in parentPom i declare some reports that are to be shared between all the subprojects. in addition pomC must declare maven-faq-plugin, not the other two. So since faq-plugin requires a faq.fml that is not present in pomA and pomB, i have to declare it only in pomC. however since reports are not merged with parentPom, i have to redeclare all reports in pomC. That is really not a blocker but is tho a bit inconvenient. Adding a property allowing to control the reports inheritance (like maven.reports.merge=true|false) would perhaps be util. - 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: (MAVEN-646) reports dont seem to be merged with parent pom
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 8:40 PM Changes: Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-646page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-646 Here is an overview of the issue: - Key: MAVEN-646 Summary: reports dont seem to be merged with parent pom Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.1 Assignee: Reporter: gilles dodinet Created: Sat, 2 Aug 2003 4:45 AM Updated: Sun, 3 Aug 2003 8:40 PM Description: i have three poms, say pomA pomB and pomC, that all extend parentPom. in parentPom i declare some reports that are to be shared between all the subprojects. in addition pomC must declare maven-faq-plugin, not the other two. So since faq-plugin requires a faq.fml that is not present in pomA and pomB, i have to declare it only in pomC. however since reports are not merged with parentPom, i have to redeclare all reports in pomC. That is really not a blocker but is tho a bit inconvenient. Adding a property allowing to control the reports inheritance (like maven.reports.merge=true|false) would perhaps be util. - 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: is HEAD relatively safe to use again?
Should there be a branch created off of the tag and everyone can commit there and use it as stable, then merge it back to HEAD when it is happy again? - Brett -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Saturday, 2 August 2003 6:32 AM To: Maven Developers List Subject: Re: is HEAD relatively safe to use again? On Fri, 2003-08-01 at 15:39, Colin Sampaleanu wrote: I know after the refactoring last week it was not recommended that HEAD be touched for a while. Is it relatively usable again? No, wait until further notice. It was put in to show the code, I wasn't going to check it in and again I wish I didn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-647) Maven built from CVS no longer recognizes pom property
The following comment has been added to this issue:
Author: dion gillard
Created: Sun, 3 Aug 2003 8:41 PM
Body:
You do know that maven CVS is currently unstable?
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647
Here is an overview of the issue:
-
Key: MAVEN-647
Summary: Maven built from CVS no longer recognizes pom property
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Versions:
1.0-rc1
Assignee:
Reporter: Jeff French
Created: Sun, 3 Aug 2003 9:36 AM
Updated: Sun, 3 Aug 2003 9:37 AM
Environment: OS: Linux Mandrake 7.2, kernel 2.2.17-21mdk
Java: 1.4.0
Description:
Maven built from CVS will no longer recognize when I reference the
pom.build.sourceDirectory property from within the project.properties file. This is as
of Sun Aug 3 08:54:18 CDT 2003.
I have this line in project.properties:
admin.dir = ${pom.build.sourceDirectory}/admin
and this in project.xml:
project
...
build
sourceDirectorysrc/sourceDirectory
...
/build
/project
The test:test-resources preGoal in maven.xml is doing a copy where it references
${admin.dir}. I reloaded each version of Maven and wiped out my ~/.maven directory
prior to running each test.
A build using b10 is successful. Here is a summary of the exception I get when using
the CVS version. So as not to clog up the description, I'll submit the full output as
an attachment.
BUILD FAILED
Unable to obtain goal [EMAIL PROTECTED]test:test-resources] -- null:32:28: copy
/home/jeff/work/test/mvtests/mvemrapi/${pom.build.sourceDirectory}/admin not found.
-
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: (MAVEN-647) Maven built from CVS no longer recognizes pom property
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 8:43 PM
Changes:
Fix Version changed to 1.0-rc1
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-647
Here is an overview of the issue:
-
Key: MAVEN-647
Summary: Maven built from CVS no longer recognizes pom property
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0-rc1
Versions:
1.0-rc1
Assignee:
Reporter: Jeff French
Created: Sun, 3 Aug 2003 9:36 AM
Updated: Sun, 3 Aug 2003 8:43 PM
Environment: OS: Linux Mandrake 7.2, kernel 2.2.17-21mdk
Java: 1.4.0
Description:
Maven built from CVS will no longer recognize when I reference the
pom.build.sourceDirectory property from within the project.properties file. This is as
of Sun Aug 3 08:54:18 CDT 2003.
I have this line in project.properties:
admin.dir = ${pom.build.sourceDirectory}/admin
and this in project.xml:
project
...
build
sourceDirectorysrc/sourceDirectory
...
/build
/project
The test:test-resources preGoal in maven.xml is doing a copy where it references
${admin.dir}. I reloaded each version of Maven and wiped out my ~/.maven directory
prior to running each test.
A build using b10 is successful. Here is a summary of the exception I get when using
the CVS version. So as not to clog up the description, I'll submit the full output as
an attachment.
BUILD FAILED
Unable to obtain goal [EMAIL PROTECTED]test:test-resources] -- null:32:28: copy
/home/jeff/work/test/mvtests/mvemrapi/${pom.build.sourceDirectory}/admin not found.
-
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-643) ejb-2.1.jar cannot be downloaded due to incorrect location on ibiblio
The following comment has been added to this issue: Author: dion gillard Created: Sun, 3 Aug 2003 8:47 PM Body: I didn't think we were allowed to distribute this jar? - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-643 Here is an overview of the issue: - Key: MAVEN-643 Summary: ejb-2.1.jar cannot be downloaded due to incorrect location on ibiblio Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: Repo Jar Requests Assignee: Reporter: Alwyn Schoeman Created: Fri, 1 Aug 2003 2:51 AM Updated: Fri, 1 Aug 2003 2:51 AM Description: ejb-2.1.jar is under /maven/ejb on ibiblio instead of /maven/ejb/jars. - 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: (MAVEN-224) remote and local repo overrides in project.properties does not work for plugins
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 8:58 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224 Here is an overview of the issue: - Key: MAVEN-224 Summary: remote and local repo overrides in project.properties does not work for plugins Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: 1.0-beta-8 1.0-final Assignee: Reporter: Colin Sampaleanu Created: Tue, 28 Jan 2003 2:41 PM Updated: Sun, 3 Aug 2003 8:58 PM Environment: cvs HEAD from 2003-1-28, win2k Description: It is possible to override both the local and remote repos by using entris such as the following in a project's project.properties file: --- from project.properties # override remote repo since we want to also point to a cvs based remote repo # to get some jars not found at ibiblio maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:../../shared/repository # overrid local repo since we want to allow this set of related source projects # to be built from multiple locations without conflicting maven.repo.local=../mavenrepo However, while this works for satisfying dependencies declared in the project's project.xml file, when building that project, if using any plugins, it does not override the repos that a plugin itself will use when trying to satisfy it's own dependencies specified in its own project.xml file. The only solution would seem to be to modify each plugin in the maven plugins dir to point to the correct repo, relatively impractical since there are a lot of plugins, and they get blown away on rebuilding maven. - 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-639) Add maven.javadoc.overview property to the javadoc plugin
The following comment has been added to this issue:
Author: dion gillard
Created: Sun, 3 Aug 2003 8:58 PM
Body:
does this work when the javadoc overview property isn't set??
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-639
Here is an overview of the issue:
-
Key: MAVEN-639
Summary: Add maven.javadoc.overview property to the javadoc plugin
Type: Improvement
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-other
Fix Fors:
1.1
Versions:
1.0-beta-10
Assignee:
Reporter: Kai Runte
Created: Thu, 31 Jul 2003 4:33 PM
Updated: Fri, 1 Aug 2003 3:37 AM
Environment: system independent
Description:
It would be nice to have an additional property in the javadoc plugin for setting an
overview.html file (option -overview in javadoc). A possible patch for the
maven-javadoc-plugin-1.3-SNAPSHOT would be:
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven/src/plugins-build/javadoc/plugin.jelly,v
retrieving revision 1.17
diff -r1.17 plugin.jelly
98a99
overview=${maven.javadoc.overview}
Index: plugin.properties
===
RCS file: /home/cvspublic/maven/src/plugins-build/javadoc/plugin.properties,v
retrieving revision 1.4
diff -r1.4 plugin.properties
14a15
maven.javadoc.overview =
-
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: is HEAD relatively safe to use again?
I'm glad you did. Its at least a step along the way to getting you to commit more regularly :-) -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Jason van Zyl [EMAIL PROTECTED] wrote on 02/08/2003 06:32:14 AM: On Fri, 2003-08-01 at 15:39, Colin Sampaleanu wrote: I know after the refactoring last week it was not recommended that HEAD be touched for a while. Is it relatively usable again? No, wait until further notice. It was put in to show the code, I wasn't going to check it in and again I wish I didn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: is HEAD relatively safe to use again?
I'd much rather the developers focussed on getting a 1.0 release ready. There are plenty of issues to work on -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Brett Porter [EMAIL PROTECTED] wrote on 04/08/2003 11:36:24 AM: Should there be a branch created off of the tag and everyone can commit there and use it as stable, then merge it back to HEAD when it is happy again? - Brett -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Saturday, 2 August 2003 6:32 AM To: Maven Developers List Subject: Re: is HEAD relatively safe to use again? On Fri, 2003-08-01 at 15:39, Colin Sampaleanu wrote: I know after the refactoring last week it was not recommended that HEAD be touched for a while. Is it relatively usable again? No, wait until further notice. It was put in to show the code, I wasn't going to check it in and again I wish I didn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-224) remote and local repo overrides in project.properties does not work for plugins
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 8:59 PM Changes: Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224 Here is an overview of the issue: - Key: MAVEN-224 Summary: remote and local repo overrides in project.properties does not work for plugins Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: 1.0-beta-8 1.0-final Assignee: Reporter: Colin Sampaleanu Created: Tue, 28 Jan 2003 2:41 PM Updated: Sun, 3 Aug 2003 8:59 PM Environment: cvs HEAD from 2003-1-28, win2k Description: It is possible to override both the local and remote repos by using entris such as the following in a project's project.properties file: --- from project.properties # override remote repo since we want to also point to a cvs based remote repo # to get some jars not found at ibiblio maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:../../shared/repository # overrid local repo since we want to allow this set of related source projects # to be built from multiple locations without conflicting maven.repo.local=../mavenrepo However, while this works for satisfying dependencies declared in the project's project.xml file, when building that project, if using any plugins, it does not override the repos that a plugin itself will use when trying to satisfy it's own dependencies specified in its own project.xml file. The only solution would seem to be to modify each plugin in the maven plugins dir to point to the correct repo, relatively impractical since there are a lot of plugins, and they get blown away on rebuilding maven. - 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: (MAVEN-122) FTP repository support
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 9:01 PM Comment: Need to release at some point Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-122page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-122 Here is an overview of the issue: - Key: MAVEN-122 Summary: FTP repository support Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.1 Assignee: Reporter: Carlo Conserva Created: Tue, 1 Oct 2002 9:45 AM Updated: Sun, 3 Aug 2003 9:01 PM Description: I've done some work to implement an FTP repository support in maven, for dependency downloading and artifact deploying, and I'd like my work to be included in the project if maven developers consider it well made and useful. In attachment I put all the necessary files to include my FTP patch in maven, together with installation instructions and a description of the modifications. The code is tested with maven 1.0 beta 7. - 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: (MAVEN-639) Add maven.javadoc.overview property to the javadoc plugin
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 9:02 PM
Comment:
New functionality in 1.1 unless a developer can squeeze it in 1.0
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-639page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-639
Here is an overview of the issue:
-
Key: MAVEN-639
Summary: Add maven.javadoc.overview property to the javadoc plugin
Type: Improvement
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-other
Fix Fors:
1.1
Versions:
1.0-beta-10
Assignee:
Reporter: Kai Runte
Created: Thu, 31 Jul 2003 4:33 PM
Updated: Sun, 3 Aug 2003 9:02 PM
Environment: system independent
Description:
It would be nice to have an additional property in the javadoc plugin for setting an
overview.html file (option -overview in javadoc). A possible patch for the
maven-javadoc-plugin-1.3-SNAPSHOT would be:
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven/src/plugins-build/javadoc/plugin.jelly,v
retrieving revision 1.17
diff -r1.17 plugin.jelly
98a99
overview=${maven.javadoc.overview}
Index: plugin.properties
===
RCS file: /home/cvspublic/maven/src/plugins-build/javadoc/plugin.properties,v
retrieving revision 1.4
diff -r1.4 plugin.properties
14a15
maven.javadoc.overview =
-
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: (MAVEN-123) creating Class-Path in manifest file
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 9:10 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-123page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-123 Here is an overview of the issue: - Key: MAVEN-123 Summary: creating Class-Path in manifest file Type: New Feature Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.1 Assignee: Reporter: Xuhua Lin Created: Tue, 1 Oct 2002 10:26 AM Updated: Sun, 3 Aug 2003 9:10 PM Description: It would be nice for Maven to create Class-Path attribute in the manifest.mf file, the value of which containing a list of dependency jar file separated by space. Can be controlled by maven.jar.manifest.class-path property. - 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-227) Still can't get Touchstone goal - C interplugin to work
Message: The following issue has been closed. Resolver: dion gillard Date: Sun, 3 Aug 2003 9:29 PM I believe this has been fixed a while back - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-227 Here is an overview of the issue: - Key: MAVEN-227 Summary: Still can't get Touchstone goal - C interplugin to work Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Remaining: 0 minutes Project: maven Components: core Versions: 1.0-beta-8 Assignee: Reporter: David Eric Pugh Created: Wed, 29 Jan 2003 5:06 PM Updated: Sun, 3 Aug 2003 9:29 PM Environment: Win2K with CVS Head as of 1/29 5:00 PM EST. Ant 1.5 Description: I am still recieving errors on the touchstone build. I believe I saw on an email that this was a possibly environmental thing, that some get the error, and others don't. Is this still true? I am trying to push forward on the cactus plugin, but I need the interplugin ability to retrieve properties. Stack Trace: [exec] java:jar: [exec] [jar] Building jar: C:\java\jakarta-turbine-maven\src\test\touchstone-build\target\touchstone-1.0.jar [exec] touchstone-tests: [exec] touchstone-goal-A: [exec] [echo] Overriding touchstone-goal-A [exec] touchstone-goal-B: [exec] [echo] touchstone-goal-B defined in plugin. [exec] test-addPath: [exec] test-plugin-property-override: [exec] com.werken.werkz.UnattainableGoalException: Unable to obtain goal [touchstone-tests] -- Inter-plugin preGoal s are not being dealt with correctly. File: null At tag fail: line: 150 column: 24 [exec] [echo] maven.touchstone.A = override.maven.touchstone.A [exec] touchstone-goal-C: [exec] at com.werken.werkz.Goal.fire(Goal.java:639) [exec] [echo] touchstone-goal-C defined in plugin. [exec] at com.werken.werkz.Goal.attain(Goal.java:568) [exec] [echo] checkValue = [exec] at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:383) [exec] at org.apache.maven.MavenSession.attainGoals(MavenSession.java:372) [exec] at org.apache.maven.jelly.tags.maven.MavenTag.doTag(MavenTag.java:116) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:232) [exec] at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:87) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:232) [exec] at com.werken.werkz.jelly.PostGoalTag$1.firePostGoal(PostGoalTag.java:86) [exec] at com.werken.werkz.Goal.firePostGoalCallbacks(Goal.java:703) [exec] at com.werken.werkz.Goal.fire(Goal.java:647) [exec] at com.werken.werkz.Goal.attain(Goal.java:568) [exec] at com.werken.werkz.Goal.attainPrecursors(Goal.java:481) [exec] at com.werken.werkz.Goal.attain(Goal.java:566) [exec] at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:383) [exec] at org.apache.maven.MavenSession.attainGoals(MavenSession.java:360) [exec] at org.apache.maven.cli.App.doMain(App.java:523) [exec] at org.apache.maven.cli.App.main(App.java:1079) [exec] at java.lang.reflect.Method.invoke(Native Method) [exec] at com.werken.forehead.Forehead.run(Forehead.java:543) [exec] at com.werken.forehead.Forehead.main(Forehead.java:573) [exec] org.apache.commons.jelly.JellyException: Inter-plugin preGoals are not being dealt with correctly. File: nul l At tag fail: line: 150 column: 24 [exec] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:659) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:284) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:232) [exec] at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:87) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:232) [exec] at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:108) [exec] at com.werken.werkz.Goal.fire(Goal.java:632) [exec]
[jira] Updated: (MAVEN-253) allows to specify cvs tag when using dist plugin
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 9:30 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-253page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-253 Here is an overview of the issue: - Key: MAVEN-253 Summary: allows to specify cvs tag when using dist plugin Type: New Feature Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-dist Versions: 1.0-beta-8 1.1 Assignee: Reporter: Alexey Styrov Created: Tue, 4 Feb 2003 11:33 AM Updated: Sun, 3 Aug 2003 9:30 PM Description: It would be really cool if I could tell maven to checkout and build some version specified in versions/ part of POM Pete Kazmier told me that this feature has been dropped while migrating maven to jelly from ant. He also told me that it should be a part of dist 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]
[jira] Updated: (MAVEN-253) allows to specify cvs tag when using dist plugin
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 9:32 PM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-253page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-253 Here is an overview of the issue: - Key: MAVEN-253 Summary: allows to specify cvs tag when using dist plugin Type: New Feature Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-dist Fix Fors: 1.1 Versions: 1.0-beta-8 1.1 Assignee: Reporter: Alexey Styrov Created: Tue, 4 Feb 2003 11:33 AM Updated: Sun, 3 Aug 2003 9:32 PM Description: It would be really cool if I could tell maven to checkout and build some version specified in versions/ part of POM Pete Kazmier told me that this feature has been dropped while migrating maven to jelly from ant. He also told me that it should be a part of dist 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]
[jira] Updated: (MAVEN-309) Order of classpath entries should be changed
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 9:35 PM
Changes:
Fix Version changed to 1.0-final
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-309page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-309
Here is an overview of the issue:
-
Key: MAVEN-309
Summary: Order of classpath entries should be changed
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-test
Fix Fors:
1.0-final
Versions:
1.0-beta-9
Assignee:
Reporter: Michal Maczka
Created: Mon, 3 Mar 2003 5:07 AM
Updated: Sun, 3 Aug 2003 9:35 PM
Description:
Behavior of my application is controlled through set of configuration files(like
log4j.propertrties).
I want to control behavior of my application differently for the test
environment and differently for the production environment.
The problem is that currently in maven the production resources are preceding the
test resources in the classpath
and [test] plugin is always taking them in first order.
I am including short example showing where is the problem.
Basically in it I have two log4j.properties files: one in
'test-resources', second in 'resources' directory.
This example shows that the the one kept in test-resources is never used and it is not
possible to easily control
the test environment when it is overlapping with production'
environment.
As a result of this program the output of log statements is always written to
production.log. Test resources are containing log4j.properties file which configures
the log system for tests and directs log statements to a file test.log. This example
shows that
this file is never created.
Other problem here is: if any of the dependencies in the classpath contains
log4j.properties this file will even preceeds the log4j.properties in the classpath.
So the best solution in my opinion will be to have followiing order of entries in the
class path:
classpath
pathelement location=${maven.test.dest}/
path refid=maven.dependency.classpath/
pathelement location=${maven.build.dest}/
pathelement path=${plugin.getDependencyPath('junit')}/
/classpath
The problem is generic and not only typical to log4j. The same applies for example to
jndi.properties.
Michal Maczka
-
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/src/plugins-build/plugin plugin.jelly project.xml
dion2003/08/03 19:32:35
Modified:src/plugins-build/plugin plugin.jelly project.xml
Log:
Start of work on a maven plugin:download.
See MAVEN-536
Revision ChangesPath
1.10 +22 -0 maven/src/plugins-build/plugin/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/plugin/plugin.jelly,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- plugin.jelly 28 Jul 2003 06:30:17 - 1.9
+++ plugin.jelly 4 Aug 2003 02:32:35 - 1.10
@@ -1,7 +1,9 @@
?xml version=1.0?
project
+ xmlns:http=jelly:http
xmlns:j=jelly:core
+ xmlns:maven=jelly:maven
xmlns:u=jelly:util
xmlns:x=jelly:xml
@@ -158,5 +160,25 @@
/j:file
/j:if
+ /goal
+
+ !-- download a plugin from a remote repo --
+ goal name=plugin:download
+maven:param-check value=${artifactId} fail=true message='artifactId' must
be specified/
+maven:param-check value=${groupId} fail=true message='groupId' must be
specified/
+maven:param-check value=${version} fail=true message='version' must be
specified/
+j:set var=repoList${maven.repo.remote}/j:set
+u:tokenize var=repos delim=,${repoList.trim()}/u:tokenize
+j:forEach var=repo items=${repos}
+ echorepo is '${repo}'/echo
+ u:file var=localPlugin
+name=${maven.home}/plugins/${artifactId}-${version}.jar /
+ j:if test=${!localPlugin.exists()}
+j:set var=remoteFile
+ value=${repo}/${groupId}/jars/${artifactId}-${version}.jar /
+echotrying to download ${remoteFile}/echo
+http:get uri=${remoteFile} var=outputVar /
+ /j:if
+/j:forEach
/goal
/project
1.15 +12 -0 maven/src/plugins-build/plugin/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven/src/plugins-build/plugin/project.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- project.xml 29 Jul 2003 04:49:40 - 1.14
+++ project.xml 4 Aug 2003 02:32:35 - 1.15
@@ -41,5 +41,17 @@
version20030211.142705/version
urlhttp://jakarta.apache.org/commons/jelly/libs/xml//url
/dependency
+dependency
+ groupIdcommons-jelly/groupId
+ artifactIdcommons-jelly-tags-http/artifactId
+ version20030211.143043/version
+ urlhttp://jakarta.apache.org/commons/jelly/libs/http//url
+/dependency
+dependency
+ groupIdcommons-httpclient/groupId
+ artifactIdcommons-httpclient/artifactId
+ version2.0-rc1/version
+ urlhttp://jakarta.apache.org/commons/httpclient//url
+/dependency
/dependencies
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-349) Consistent properties for jar, war, ejb and ear
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 9:47 PM
Changes:
Version changed from 1.0-final
Fix Version changed to 1.0-final
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-349page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-349
Here is an overview of the issue:
-
Key: MAVEN-349
Summary: Consistent properties for jar, war, ejb and ear
Type: Improvement
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-java
plugin-war
Fix Fors:
1.0-final
Versions:
1.0-beta-9
Assignee:
Reporter: Aslak Hellesoy
Created: Tue, 25 Mar 2003 5:11 AM
Updated: Sun, 3 Aug 2003 9:47 PM
Description:
The current naming conventions for properties defining the names of jar, ejb, war and
ear are somewhat inconsistent.
This patch introduces 4 new properties:
# defined in the java plugin's plugin.properties
maven.jar.final.name = ${maven.final.name}.jar
# defined in the war plugin's plugin.properties
maven.war.final.name = ${maven.final.name}.war
# defined in the ejb plugin's plugin.properties
maven.ejb.final.name = ${maven.final.name}.jar
# defined in the ear plugin's plugin.properties
maven.ear.final.name = ${maven.final.name}.ear
This patch solves the following problems:
1) It removes the risk of name clashes for projects that produce both plain
jar files and ejb jar files, since the maven.ejb.final.name property can be overridden.
2) When packaging wars and ejbs inside ears, it is sometimes desirable to have
different names for ejbs and wars, like foo-ejb-1.0.jar and foo-war-1.0.war. This is
necessary when the contents of an ear file is to be deployed on different weblogic
servers with weblogic.deploy. This can now be achieved by overriding
maven.ejb.final.name and/or maven.war.final.name.
This patch should not change any of the current functionality, and the documentation
has been updated too.
-
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/src/conf driver.jelly
dion2003/08/03 19:53:06 Modified:src/conf driver.jelly Log: Add warning Revision ChangesPath 1.26 +5 -0 maven/src/conf/driver.jelly Index: driver.jelly === RCS file: /home/cvs/maven/src/conf/driver.jelly,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- driver.jelly 31 Jul 2003 06:52:10 - 1.25 +++ driver.jelly 4 Aug 2003 02:53:06 - 1.26 @@ -6,5 +6,10 @@ xmlns:define=jelly:define xmlns:util=jelly:util + !-- WARNING WARNING WARNING WARNING WARNING WARNING WARNING + | + | THIS FILE IS NO LONGER IN USE BY MAVEN AND WILL BE DELETED + |-- + /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-426) Allow genapp to support multiple templates
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:09 PM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-426page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-426 Here is an overview of the issue: - Key: MAVEN-426 Summary: Allow genapp to support multiple templates Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.1 Versions: 1.0-beta-9 1.1 Assignee: Reporter: Brian Ewins Created: Wed, 14 May 2003 10:27 AM Updated: Sun, 3 Aug 2003 11:09 PM Environment: all Description: At the moment the genapp plugin is pretty rudimentary, you only get the 'standard' maven template project. I'd like maven to support multiple project templates, to make it easier to (for example) set up a beginner's webapp, ejb, maven-plugin project; a project with a standard setup for a company (logos, developers, scm); etc etc. Attached is some code to support this proposal. It changes the structure of the genapp 'plugin.resources' directory so that it more closely matches a normal project: plugin-resources/: project.properties project.xml src plugin-resources/src: conf java test plugin-resources/src/conf: app.properties plugin-resources/src/java: App.java plugin-resources/src/test: AbstractTestCase.java AppTest.java NaughtyTest.java Next we identify the three kinds of resource which need copied - those which need 'repackaged' like java, test; those which need filtered (project.xml), and those which just need copied (everything else). I do this by adding a plugin.properties with the lines: maven.genapp.repackage=java,test maven.genapp.filter=project.xml Finally I updated the plugin.jelly (attached). The plugin.jelly was written for b8, (hence the missing 'ant:' stuff) and takes an extra parameter: maven -Dpackage=blah -Dtemplate=example genapp this will try to copy the 'example' project from the user's home dir. This code isn't really sophisticated enough, it should try the user's home dir first then fall back on the plugin.resources dir, with the 'default' output of genapp moved to a project called 'default'; this would let maven ship with more examples (including a reactor example!) while giving the user a way to override them. If the comments on this idea involve more changes to the plugin I'd be happy to oblige. - 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: (MAVEN-464) Reactor cannot find goals in plugin
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:16 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-464page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-464 Here is an overview of the issue: - Key: MAVEN-464 Summary: Reactor cannot find goals in plugin Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: maven-new-unreleased Assignee: Reporter: Charles Chan Created: Wed, 4 Jun 2003 12:44 PM Updated: Sun, 3 Aug 2003 11:16 PM Description: Hi, I am trying to setup a very simple plugin with a reactor inside. (See Attached Zip file). When I invoke maven reactor-test-maven I got the following output. I have no idea why this is happening. I am testing against Maven from CVS. Any help is appreciated. Charles Our processing order: Project A Project B Project C Project Master Template Test Plugin + | Building Project A | Memory: 2M/3M + [DEBUG] Adding reference: maven.dependency.classpath - [DEBUG] Adding reference: maven-classpath - test-maven: test-plugin-default-variable: [echo] Variable: test.conf.dir is /this/is/A/conf.dir + | Building Project B | Memory: 2M/3M + BUILD FAILED Unknown goal test-maven com.werken.werkz.UnattainableGoalException: Unable to obtain goal [reactor-test-maven] -- null:17:43: maven:reactor Unknown goal test-maven at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:403) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:357) at org.apache.maven.cli.App.doMain(App.java:525) at org.apache.maven.cli.App.main(App.java:1088) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) org.apache.commons.jelly.JellyTagException: null:17:43: maven:reactor Unknown goal test-maven at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:383) - 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: (MAVEN-541) test-compile doesn't allow for same options as java-compile
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:21 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-541page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-541 Here is an overview of the issue: - Key: MAVEN-541 Summary: test-compile doesn't allow for same options as java-compile Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-test Fix Fors: 1.0-final Versions: 1.0-beta-10 Assignee: Reporter: Wandy Wang Created: Wed, 2 Jul 2003 6:34 PM Updated: Sun, 3 Aug 2003 11:21 PM Description: test-compile doesn't use the same compile options that are allowd by java-compile. Most noteably, the ability to fork. This caused my test classes to not compile. - 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: (MAVEN-542) SnapshotResolver hardcodes the ibibio repo instead of using the custom repos
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:24 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-542page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-542 Here is an overview of the issue: - Key: MAVEN-542 Summary: SnapshotResolver hardcodes the ibibio repo instead of using the custom repos Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: release Fix Fors: 1.0-final Versions: 1.0-beta-10 Assignee: Reporter: Wandy Wang Created: Wed, 2 Jul 2003 6:35 PM Updated: Sun, 3 Aug 2003 11:24 PM Description: SnapshotResolver hardcodes the ibibio repo instead of using the custom repos set up in the project.properties. String url = http://www.ibiblio.org/maven/; + groupId + /jars/ + artifactId + -snapshot-version; - 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/src/java/org/apache/maven/plugin PluginManager.java
dion2003/08/03 21:30:39
Modified:src/java/org/apache/maven/plugin PluginManager.java
Log:
Refactor werkz project creation into helper method
Revision ChangesPath
1.61 +25 -11maven/src/java/org/apache/maven/plugin/PluginManager.java
Index: PluginManager.java
===
RCS file: /home/cvs/maven/src/java/org/apache/maven/plugin/PluginManager.java,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- PluginManager.java4 Aug 2003 02:41:10 - 1.60
+++ PluginManager.java4 Aug 2003 04:30:39 - 1.61
@@ -369,18 +369,10 @@
buildAntProject( project, baseContext );
Session session = getJellySession(baseContext);
-
// add the global session to the pluginContext so that it can be used by
tags
baseContext.setVariable( GLOBAL_SESSION_KEY, session );
-// We put in our listener to frob the session.
-MavenAttainGoalListener listener = new MavenAttainGoalListener();
-listener.setBaseContext( baseContext );
-listener.setPluginManager( this );
-
-WerkzProject werkzProject = new WerkzProject();
-werkzProject.addAttainGoalListener( listener );
-baseContext.setWerkzProject( werkzProject );
+WerkzProject werkzProject = buildWerkzProject( baseContext );
//
-
// Execution of the Jelly scripts:
@@ -407,6 +399,8 @@
//mapper.parse( new InputStreamReader( driver ), driverHousing );
//runJellyScriptHousing( driverHousing, baseContext );
+// FIXME: Part of this belongs as a method on Project, e.g. the name and
+//construction of maven.xml
// Project's Jelly script
if ( project.getFile() != null )
{
@@ -423,8 +417,11 @@
}
// Parent's Jelly script
+// FIXME: What about further up the chain?
if ( project.hasParent() )
{
+// FIXME: this is a badly named method
+
File f = project.parentMavenXml();
if ( f.exists() )
@@ -478,6 +475,23 @@
}
/**
+ *
+ * @param context the base context for the werkz project
+ * @return a configured werkz project
+ */
+private WerkzProject buildWerkzProject(MavenJellyContext context)
+{
+// We put in our listener to frob the session.
+MavenAttainGoalListener listener = new MavenAttainGoalListener();
+listener.setBaseContext( context );
+listener.setPluginManager( this );
+WerkzProject werkzProject = new WerkzProject();
+werkzProject.addAttainGoalListener( listener );
+context.setWerkzProject( werkzProject );
+return werkzProject;
+}
+
+/**
* Get the Werkz Session
* FIXME: Describe what it's for?
* @param baseContext the maven context the session should use
@@ -606,7 +620,7 @@
* @return an Ant project
* @throws Exception When any error occurs. FIXME this is bad.
*/
-public GrantProject buildAntProject( Project project, MavenJellyContext context
)
+private GrantProject buildAntProject( Project project, MavenJellyContext
context )
throws Exception
{
// Create the build listener.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-125) Documentation enhancements
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:33 PM Changes: environment changed to Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-125page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-125 Here is an overview of the issue: - Key: MAVEN-125 Summary: Documentation enhancements Type: Improvement Status: Assigned Priority: Minor Time Spent: Unknown Remaining: 1 week Project: maven Fix Fors: 1.1 Assignee: dion gillard Reporter: dion gillard Created: Tue, 1 Oct 2002 10:44 PM Updated: Sun, 3 Aug 2003 11:33 PM Description: Ok, Here are some changes I would recommend (as dIon asked for it ;-): 1) Change the welcome page to have direct links to gettting started. This is what I want to see when I visit the front page 2) The user guide should have information from the download and install sections to make it a more complete user's guide 3) getting started and user's guide should possibly be rethought into user's guide and developer's guide. 4) The plug-ins should be split into core and additional (or optional) 5) Someone who has written a plug-in should write a plug-in development howto and integrate that with the developer's guide. 6) Plug-ins should be described on the listing page 7) In the user's guide it would be nice to have a link to an example maven.xml file Let me know what you guys think, when I get a chance to look at it further I may have some further suggestions (and maybe patches ;-). -warner +warner onstine+ - 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: (MAVEN-156) classpath or jelly:xml issue with XSLT transformations
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 3 Aug 2003 11:36 PM
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Fix Version changed to 1.0-final
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-156page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-156
Here is an overview of the issue:
-
Key: MAVEN-156
Summary: classpath or jelly:xml issue with XSLT transformations
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
jelly-integ
Fix Fors:
1.0-final
Versions:
1.0-beta-7
Assignee:
Reporter: tim stephenson
Created: Thu, 21 Nov 2002 5:28 PM
Updated: Sun, 3 Aug 2003 11:36 PM
Environment: win2k, 1.4.1-b21, maven b7 and also winxp, jdk 1.3.1-01, maven b6
Description:
see also my mail to the user list titled 'Style task / x:transform problem'
It seems there is a general problem with XSLT launched from maven. My own transforms
in the maven.xml and that in the docbook plugin behave the same. Behaviour is that
instead of transforming as expected the transform command is printed to console. Some
processing has occurred (eg var substitution). For example the following:
style in=project.xml
out=${meta.dir}/orion-application.xml
style=${code.templates.dir}/orion-application.xsl/
prints this to the console:
style in=project.xml out=META-INF/orion-application.xml
style=c:/projects/jdf3/utils/templates/codegen/orion-application.xsl/style
but no transform.
The same thing results when using x:transform. Other jelly:xml commands such as
x:parse and so on work fine
Using a java command to fork a VM and launch a Xalan Process command, taking control
of the classpath works ok so I am using this a workaround.
Hopefully it will be obvious to someone that better understands the way maven loads
its classes!
-
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-156) classpath or jelly:xml issue with XSLT transformations
The following comment has been added to this issue:
Author: dion gillard
Created: Sun, 3 Aug 2003 11:36 PM
Body:
see how this is done in the latka plugin
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-156
Here is an overview of the issue:
-
Key: MAVEN-156
Summary: classpath or jelly:xml issue with XSLT transformations
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: 0 minutes
Project: maven
Components:
jelly-integ
Fix Fors:
1.0-final
Versions:
1.0-beta-7
Assignee:
Reporter: tim stephenson
Created: Thu, 21 Nov 2002 5:28 PM
Updated: Fri, 11 Apr 2003 2:28 PM
Environment: win2k, 1.4.1-b21, maven b7 and also winxp, jdk 1.3.1-01, maven b6
Description:
see also my mail to the user list titled 'Style task / x:transform problem'
It seems there is a general problem with XSLT launched from maven. My own transforms
in the maven.xml and that in the docbook plugin behave the same. Behaviour is that
instead of transforming as expected the transform command is printed to console. Some
processing has occurred (eg var substitution). For example the following:
style in=project.xml
out=${meta.dir}/orion-application.xml
style=${code.templates.dir}/orion-application.xsl/
prints this to the console:
style in=project.xml out=META-INF/orion-application.xml
style=c:/projects/jdf3/utils/templates/codegen/orion-application.xsl/style
but no transform.
The same thing results when using x:transform. Other jelly:xml commands such as
x:parse and so on work fine
Using a java command to fork a VM and launch a Xalan Process command, taking control
of the classpath works ok so I am using this a workaround.
Hopefully it will be obvious to someone that better understands the way maven loads
its classes!
-
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: (MAVEN-202) unable to override java:jar
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:39 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-202page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-202 Here is an overview of the issue: - Key: MAVEN-202 Summary: unable to override java:jar Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.1 Versions: 1.0-beta-8 Assignee: Reporter: Charles Chan Created: Tue, 14 Jan 2003 10:09 AM Updated: Sun, 3 Aug 2003 11:39 PM Description: (I am using Maven-CVS Head) Hi, I am trying to replace java:jar target but when I invoke jar:install, I get the following error: INTERNAL ERROR Reference made to goal 'test:test' which has no definition. Here's my maven.xml: project xmlns:j=jelly:core goal name=java:jar echoTEST/echo /goal /project project.xml ?xml version=1.0 encoding=ISO-8859-1? project pomVersion3/pomVersion idtest/id nameTest/name /project I invoke maven jar:install However, if I duplicate jar:install (copy and paste from plugin.jelly) in my maven.xml, everything works (I have to change prereqs to attainGoal, however) Any idea? Charles - 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-202) unable to override java:jar
The following comment has been added to this issue: Author: dion gillard Created: Sun, 3 Aug 2003 11:39 PM Body: Is this still an issue? - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-202 Here is an overview of the issue: - Key: MAVEN-202 Summary: unable to override java:jar Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 0 minutes Project: maven Components: core Fix Fors: 1.1 Versions: 1.0-beta-8 Assignee: Reporter: Charles Chan Created: Tue, 14 Jan 2003 10:09 AM Updated: Fri, 11 Apr 2003 2:22 PM Description: (I am using Maven-CVS Head) Hi, I am trying to replace java:jar target but when I invoke jar:install, I get the following error: INTERNAL ERROR Reference made to goal 'test:test' which has no definition. Here's my maven.xml: project xmlns:j=jelly:core goal name=java:jar echoTEST/echo /goal /project project.xml ?xml version=1.0 encoding=ISO-8859-1? project pomVersion3/pomVersion idtest/id nameTest/name /project I invoke maven jar:install However, if I duplicate jar:install (copy and paste from plugin.jelly) in my maven.xml, everything works (I have to change prereqs to attainGoal, however) Any idea? Charles - 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-225) Missing xdoclet module results in silent failure in maven, but not in pure ant build
The following comment has been added to this issue: Author: dion gillard Created: Sun, 3 Aug 2003 11:39 PM Body: Does this still happen on 1.0-beta-10? - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-225 Here is an overview of the issue: - Key: MAVEN-225 Summary: Missing xdoclet module results in silent failure in maven, but not in pure ant build Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 0 minutes Project: maven Components: core Versions: 1.0-beta-8 Assignee: Reporter: Colin Sampaleanu Created: Tue, 28 Jan 2003 5:34 PM Updated: Fri, 11 Apr 2003 2:22 PM Environment: maven CVS HEAD 2003-1-28 Description: There appears to be a silent failure and continue (instead of the appropriate build-breakage) happening when xdoclet is run and a needed module is not found on the classpath, and this would appear to be a maven problem. Consider the following code in a pure ant based build, which uses xdoclet: ejbdoclet ... jboss xxx= yyy=ddd / ... /ejbdoclet Now the JBossSubtask class which is a subtask of EjbDocletTask, also uses the JMXDocletTask, which is found in another xdoclet module entirely. When the ant based build is run, if the xdoclet jmx module is not found on the classpath, the build fails as follows: excerpt xdoclet: BUILD FAILED file:./proj/buildTargets.xml:153: Couldn't find the class xdoclet.modules.jmx.JM XDocletTask on the classpath: D:\src\tira\cvs\core\data-access\lib\core\log4j.ja r;D:\src\tira\cvs\core\data-access\lib\forbuild\ejb.jar;D:\src\tira\cvs\shared\l ib\xdoclet\xdoclet-1.2\commons-collections.jar;D:\src\tira\cvs\shared\lib\xdocle t\xdoclet-1.2\commons-logging.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2 \xdoclet-bea-module.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-e jb-module.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-jboss-modul e.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-mvcsoft-module.jar; D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-web-module.jar;D:\src\tir a\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-xjavadoc.jar;D:\src\tira\cvs\shared \lib\xdoclet\xdoclet-1.2\xdoclet.jar but when maven is run, with a goal using the exact same ejbdoclet task definition, there is no error printed, the build is not stopped, and there is no indication that there is a problem, except that xdoclet does not run at all. I do not believe that this is an xdoclet problem. As indicated in the pure ant case, xdoclet is trying to stop the build when it can't find a needed module, but in the maven environment, that is not happening. - 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: (MAVEN-225) Missing xdoclet module results in silent failure in maven, but not in pure ant build
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:43 PM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-225page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-225 Here is an overview of the issue: - Key: MAVEN-225 Summary: Missing xdoclet module results in silent failure in maven, but not in pure ant build Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: 1.0-beta-8 Assignee: Reporter: Colin Sampaleanu Created: Tue, 28 Jan 2003 5:34 PM Updated: Sun, 3 Aug 2003 11:43 PM Environment: maven CVS HEAD 2003-1-28 Description: There appears to be a silent failure and continue (instead of the appropriate build-breakage) happening when xdoclet is run and a needed module is not found on the classpath, and this would appear to be a maven problem. Consider the following code in a pure ant based build, which uses xdoclet: ejbdoclet ... jboss xxx= yyy=ddd / ... /ejbdoclet Now the JBossSubtask class which is a subtask of EjbDocletTask, also uses the JMXDocletTask, which is found in another xdoclet module entirely. When the ant based build is run, if the xdoclet jmx module is not found on the classpath, the build fails as follows: excerpt xdoclet: BUILD FAILED file:./proj/buildTargets.xml:153: Couldn't find the class xdoclet.modules.jmx.JM XDocletTask on the classpath: D:\src\tira\cvs\core\data-access\lib\core\log4j.ja r;D:\src\tira\cvs\core\data-access\lib\forbuild\ejb.jar;D:\src\tira\cvs\shared\l ib\xdoclet\xdoclet-1.2\commons-collections.jar;D:\src\tira\cvs\shared\lib\xdocle t\xdoclet-1.2\commons-logging.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2 \xdoclet-bea-module.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-e jb-module.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-jboss-modul e.jar;D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-mvcsoft-module.jar; D:\src\tira\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-web-module.jar;D:\src\tir a\cvs\shared\lib\xdoclet\xdoclet-1.2\xdoclet-xjavadoc.jar;D:\src\tira\cvs\shared \lib\xdoclet\xdoclet-1.2\xdoclet.jar but when maven is run, with a goal using the exact same ejbdoclet task definition, there is no error printed, the build is not stopped, and there is no indication that there is a problem, except that xdoclet does not run at all. I do not believe that this is an xdoclet problem. As indicated in the pure ant case, xdoclet is trying to stop the build when it can't find a needed module, but in the maven environment, that is not happening. - 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: (MAVEN-256) attainGoal does not use the global session
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:55 PM Comment: Is this still the case post beta 10? Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-256page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-256 Here is an overview of the issue: - Key: MAVEN-256 Summary: attainGoal does not use the global session Type: Bug Status: Assigned Priority: Critical Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: 1.0-beta-8 Assignee: bob mcwhirter Reporter: Peter Lynch Created: Thu, 6 Feb 2003 4:00 AM Updated: Sun, 3 Aug 2003 11:55 PM Description: The problem: Basically there needs to be a way to call a goal from inside another goal and have the called goal use the current session. The result being no new session created and all already attained goals would not be called again by the called goal's prereqs attribute or nested attainGoal tags. The only way to create a new session would be to use the attain tags or set attainGoal newsession=true name=someGoal/ if an attribute is decided to be the way to flag session creation. Alternatively it was suggested a new tag be added called callGoal which would always create a new session, and attainGoal would be reverted to use the current session. Here is the thread from the mailing lists describing the problems and soltuions. - Original Message - From: Colin Sampaleanu [EMAIL PROTECTED] To: Turbine Maven Users List [EMAIL PROTECTED] Cc: Turbine Maven Developers List [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 7:27 AM Subject: Re: goals are broken, let's fix it bob mcwhirter wrote: On Thu, 30 Jan 2003, Colin Sampaleanu wrote: I think that there is currently a serious problem in maven and a number of plugins, in that 'attainGoal' is being used in various places (goals, preGoals, and postGoals) with the expectation that the goal being named to be attained will be part of the dependency graph of the main build itself, and will be attained only once. However, due to the way the werkz 'attainGoal' tag is implemented, there is no integration into the main maven dependency session, and each invocation of attainGoal with a specific goal will call that goal again including all its dependencies, becoming more of a subroutine call. At best, I would say it's confusing as hell, since the name 'attainGoal' implies something; certainly there is some code which is using the tag with the expectation that it is integrating into the dependency graph, and there is other code which is using it like a subroutine call. I would also suggest there need to be clearly named, different mechanisms, to handle both usage semantics. Yah, this is a well-understood problem (at least by me, having written werkz). Though, my non-scientific polling has resulted in me thinking that most folks are now taking advantage of the fact that attainGoal doesn't participate in the global session. ie: attainGoal name=clean/ attainGoal name=myproj:something/ attainGoal name=clean/ attainGoal name=myproj:something.else/ Where 'clean' wouldn't fire the 2nd time if we shared in the global session. We noodled around with keeping the current syntax and semantics the same but adding a session=true attribute for folks needing new semantics. Or, since so many other things have changed lately, retaining backwards compatibility is less important, and we could certain make attainGoal behave has expected, and rename the current functionality to callGoal or forceAttainGoal or somesuch. The biggest use-case we must accomodate is folks wanting to 'clean' multple times and not have werkz think everything is still attained. Though, that could maybe be rememdied with something like: goal name=clean !-- normal clean stuff -- resetWerkzSession/ /goal That'd allow us to invalidate the werkz session and allow for rebuilds without confusing werkz. IRC would probably be a glad place to hammer out the details. (still cross-posting, as I think this has big implications for users as well as developers...) How are the IRC sessions typically arranged? i.e. when are you guys normally on?. My main issue with IRC is that unfortunately it is blocked for me during the day due to the firewall at work,
[jira] Updated: (MAVEN-316) Ability to disable a single report via POM
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:57 PM Changes: environment changed to timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-316page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-316 Here is an overview of the issue: - Key: MAVEN-316 Summary: Ability to disable a single report via POM Type: New Feature Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: Requested POM Additions Fix Fors: 1.1 Assignee: Reporter: Quinton McCombs Created: Thu, 6 Mar 2003 10:40 AM Updated: Sun, 3 Aug 2003 11:57 PM Description: I would like to be able to disable one or more reports in the POM without having to list all of the reports that I do want. For example: reports default-reports/ disabled-reports reportmaven-linkcheck-plugin/report /disabled-reports /reports - 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: (MAVEN-295) New junit test runner
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Sun, 3 Aug 2003 11:56 PM Changes: environment changed to Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-295page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-295 Here is an overview of the issue: - Key: MAVEN-295 Summary: New junit test runner Type: Wish Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 4 hours Project: maven Fix Fors: 1.1 Assignee: Reporter: Ben Walding Created: Wed, 26 Feb 2003 4:27 AM Updated: Sun, 3 Aug 2003 11:56 PM Description: The existing junit runner only has an all or nothing approach to forking for tests. It would be advantageous (speedwise) if the jvm could be forked once for the entire set of tests. (JVM forks are SLOOWW) - 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: (MAVEN-318) OutOfMemoryError during site:generate
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:03 AM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-318page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-318 Here is an overview of the issue: - Key: MAVEN-318 Summary: OutOfMemoryError during site:generate Type: Bug Status: Assigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.0-final Versions: 1.0-beta-9 Assignee: Ben Walding Reporter: Quinton McCombs Created: Thu, 6 Mar 2003 1:35 PM Updated: Mon, 4 Aug 2003 12:03 AM Environment: SuSE Linux 8.0, Java 1.4.1-b21 Description: I have started getting OutOfMemoryErrors being thrown during the execution of the linkcheck 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]
[jira] Updated: (MAVEN-321) Make clover run over unit tests as well
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:03 AM Changes: environment changed to Fix Version changed to 1.0-final - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-321page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-321 Here is an overview of the issue: - Key: MAVEN-321 Summary: Make clover run over unit tests as well Type: Improvement Status: Assigned Priority: Major Time Spent: Unknown Remaining: 1 hour Project: maven Fix Fors: 1.0-final Assignee: Ben Walding Reporter: Ben Walding Created: Mon, 10 Mar 2003 5:05 AM Updated: Mon, 4 Aug 2003 12:03 AM Description: A slightly more radical approach to code coverage is to get the coverage program to instrument the test cases to make sure they are all running properly also. Add this as an optional capability for clover and make it off by default. eg. maven.clover.instrument.tests = true | false - 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: (MAVEN-324) wrong parameter order in deploy plugin
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Mon, 4 Aug 2003 12:03 AM
Comment:
Is this still an issue?
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Fix Version changed to 1.0-final
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-324page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-324
Here is an overview of the issue:
-
Key: MAVEN-324
Summary: wrong parameter order in deploy plugin
Type: Bug
Status: In Progress
Priority: Minor
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-dist
Fix Fors:
1.0-final
Versions:
1.0-beta-9
Assignee: Ben Walding
Reporter: Fabian Ritzmann
Created: Tue, 11 Mar 2003 4:10 AM
Updated: Mon, 4 Aug 2003 12:03 AM
Environment: Windows 2000
Putty (ssh implementation)
Description:
The plugin.jelly in the deploy plugin contains the following lines:
exec dir=. executable=${commander}
arg line=${siteAddress} -l ${username} '${assureDirectoryCommand}
${resolvedDirectory}'/
/exec
This doesn't work with my ssh client (Putty). The parameters (-l ${username}) need to
be before the siteAddress.
-
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: (MAVEN-344) provide build:start goal to attach other goals to
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Mon, 4 Aug 2003 12:05 AM
Changes:
Fix Version changed to 1.1
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-344page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-344
Here is an overview of the issue:
-
Key: MAVEN-344
Summary: provide build:start goal to attach other goals to
Type: Improvement
Status: Assigned
Priority: Major
Time Spent: Unknown
Remaining: 1 hour
Project: maven
Components:
core
Fix Fors:
1.1
Versions:
1.0-beta-9
Assignee: Jason van Zyl
Reporter: Ben Walding
Created: Sun, 23 Mar 2003 6:02 AM
Updated: Mon, 4 Aug 2003 12:05 AM
Description:
We need a goal that occurs before dependency resolution so that tasks that help fix
dep resolution can occur.
eg.
I would like to create the concept of project repository files that get pushed to the
local repository - eg. activation / mail and all that other stuff we can't have on
ibiblio.
preGoal name=build:start
copy todir=${maven.home}/repository
fileset dir=lib
includes name=**/*.jar/
/fileset
/copy
/preGoal
-
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-347) Torque plugin goals can't access JDBC driver
Message: The following issue has been closed. Resolver: dion gillard Date: Mon, 4 Aug 2003 12:07 AM Applied patch - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-347 Here is an overview of the issue: - Key: MAVEN-347 Summary: Torque plugin goals can't access JDBC driver Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Remaining: 0 minutes Project: maven Components: core Fix Fors: 1.0-rc1 Versions: 1.0-beta-9 Assignee: Reporter: Jim Crossley Created: Mon, 24 Mar 2003 6:08 PM Updated: Mon, 4 Aug 2003 12:07 AM Description: Since torque's behavior is encapsulated in Ant tasks, and Ant requires its libs to be in the root classloader, it seems the only way to make the driver available is to put something like this in the plugin's pom: dependency idmysql/id version2.0.14/version jarmysql-connector-java-2.0.14-bin.jar/jar urlhttp://www.mysql.com//url properties classloaderroot/classloader /properties /dependency But it's gross to do that for all the possible jdbc drivers. It's less gross to put the above in the project's pom, but that doesn't work. :-( Even less gross might be to reimplement the torque behavior without Ant. - 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: (MAVEN-375) App server plugin docs are out of date
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:10 AM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-375page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-375 Here is an overview of the issue: - Key: MAVEN-375 Summary: App server plugin docs are out of date Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 1 hour Project: maven Fix Fors: 1.1 Versions: 1.0-beta-9 Assignee: Reporter: Ben Walding Created: Sat, 5 Apr 2003 7:19 PM Updated: Mon, 4 Aug 2003 12:10 AM Description: The app server docs should be updated to match the plugin. They are a mess of J2EE plugin references - 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-384) War and Ear Plugin Don't Handle Jar Overrides For Bundling
The following comment has been added to this issue: Author: dion gillard Created: Mon, 4 Aug 2003 12:10 AM Body: Is this still an issue? - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-384 Here is an overview of the issue: - Key: MAVEN-384 Summary: War and Ear Plugin Don't Handle Jar Overrides For Bundling Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 0 minutes Project: maven Components: plugin-war Fix Fors: 1.1 Assignee: Reporter: Anthony Vito Created: Thu, 10 Apr 2003 5:51 PM Updated: Tue, 29 Apr 2003 9:03 AM Environment: NA Description: The war and ear plugin both suffer from the same flaw of hard coding the local repository jar path for the means of bundling dependencies. This obviously doesn't work when jar overriding has occured. The solution is probably not to have all plugins handle overrides, but a more global approach. The Project Objects getDependencyPath(String id) Method might be of interest here, I'm hoping they're miss documented. - 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: (MAVEN-384) War and Ear Plugin Don't Handle Jar Overrides For Bundling
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:11 AM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-384page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-384 Here is an overview of the issue: - Key: MAVEN-384 Summary: War and Ear Plugin Don't Handle Jar Overrides For Bundling Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-war Fix Fors: 1.1 Assignee: Reporter: Anthony Vito Created: Thu, 10 Apr 2003 5:51 PM Updated: Mon, 4 Aug 2003 12:11 AM Environment: NA Description: The war and ear plugin both suffer from the same flaw of hard coding the local repository jar path for the means of bundling dependencies. This obviously doesn't work when jar overriding has occured. The solution is probably not to have all plugins handle overrides, but a more global approach. The Project Objects getDependencyPath(String id) Method might be of interest here, I'm hoping they're miss documented. - 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: (MAVEN-351) ant-plugin not obeying jar override
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:15 AM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-351page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-351 Here is an overview of the issue: - Key: MAVEN-351 Summary: ant-plugin not obeying jar override Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.1 Versions: 1.0-beta-9 Assignee: Reporter: Mike Bowler Created: Tue, 25 Mar 2003 12:16 PM Updated: Mon, 4 Aug 2003 12:15 AM Environment: Sun JDK1.3.1 on windows. Maven from cvs on March 24, 2003 Description: When using the ant-plugin to generate an ant build file, the generated get tags do not obey the jar overrides specified in project.properties. All get tags attempt to load the jars from ibiblio even though an override was specified that points to the local harddrive. Overrides are being used because the jar files in question are proprietary and cannot be uploaded to ibiblio. - 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-409) Add new goal to plugin plugin to download and manipulate installed plugins
Message: The following issue has been closed. Resolver: dion gillard Date: Mon, 4 Aug 2003 12:16 AM Dupe of maven-536 - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-409 Here is an overview of the issue: - Key: MAVEN-409 Summary: Add new goal to plugin plugin to download and manipulate installed plugins Type: Improvement Status: Closed Priority: Minor Resolution: DUPLICATE Time Spent: Unknown Remaining: 2 hours Project: maven Versions: 1.0-beta-10 Assignee: Ben Walding Reporter: Ben Walding Created: Sun, 20 Apr 2003 5:57 PM Updated: Mon, 4 Aug 2003 12:16 AM Description: Create some new goals to manipulate the installed plugins eg. maven plugin:remove maven-jar-plugin maven plugin:get http://maven-plugins.sf.net/maven-jar-plugin-v1.0.jar (This will get us away from forcing new releases down on users to get plugin fixes). More thought will be need in so far that the pom will need to specify minimum core versions, but that is on it's way anyway. - 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: (MAVEN-391) FAQ Plugin - CDATA section is not processed correctly in answer tag.
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:17 AM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-391page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-391 Here is an overview of the issue: - Key: MAVEN-391 Summary: FAQ Plugin - CDATA section is not processed correctly in answer tag. Type: Bug Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 1 week Project: maven Fix Fors: 1.1 Versions: 1.0-beta-10 Assignee: Reporter: dion gillard Created: Sun, 13 Apr 2003 7:55 PM Updated: Mon, 4 Aug 2003 12:17 AM Environment: N/A Description: Willie Vu 14/04/2003 02:34 AM CDATA section is not processed correctly in answer tag. For instance, I have the following: source![CDATA[ jbosscmp-jdbc defaults ... ]]/source It results source![CDATA[ lt;jbosscmp-jdbcgt; lt;defaultsgt; ... ]]/source - 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: (MAVEN-413) Allow support in pdf plugin for alternative navigation.xml
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:19 AM Comment: Got a patch? Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-413page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-413 Here is an overview of the issue: - Key: MAVEN-413 Summary: Allow support in pdf plugin for alternative navigation.xml Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.1 Versions: 1.0-beta-9 Assignee: Reporter: Yannick Menager Created: Tue, 22 Apr 2003 6:11 AM Updated: Mon, 4 Aug 2003 12:19 AM Description: I've been playing with the pdf plugin to generate documentations as well as the project website. However the standard navigation.xml isn't very appropriate for that ( generates empty pages for external links, or deeply nested pages don't show up ). So I've come to use an alternative navigation.xml to generate the pdf file. It would be nice if the plugin supported a property allowing to set an alternative navigation.xml ( as a hack I'm currently using preGoal and postGoal to move the 2 navigation.xml around ). - 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: (MAVEN-460) Overhaul of docbook plugin
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:20 AM Comment: Still waiting for Gabriel Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-460page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-460 Here is an overview of the issue: - Key: MAVEN-460 Summary: Overhaul of docbook plugin Type: New Feature Status: Assigned Priority: Major Time Spent: Unknown Remaining: 1 week Project: maven Components: documentation Fix Fors: 1.1 Assignee: dion gillard Reporter: Gabriel Sjoberg Created: Tue, 3 Jun 2003 11:38 AM Updated: Mon, 4 Aug 2003 12:20 AM Environment: java Description: I've pretty much completely redone the docbook plugin. I merged the current plugin with the one at sourceforge. It now supports full, chunked, and simple docbook. It can translate into pdf, html, and fo. Soon I'll add a few more output formats. Because of the differences, a diff isn't really helpful, so I'm attaching a zip of the plugin as it stands now. It still needs a bit of work, but I want to hear from others before I do too much more with this. - 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: (MAVEN-515) unit test levels
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:21 AM Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-515page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-515 Here is an overview of the issue: - Key: MAVEN-515 Summary: unit test levels Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Fix Fors: 1.1 Assignee: Reporter: Brett Porter Created: Mon, 23 Jun 2003 9:53 AM Updated: Mon, 4 Aug 2003 12:21 AM Description: This is to track the progress of what is decided about this feature. Once again, happy to implement when I get time as I need it for work :) here is the proposal sent to the list: proposal: allow multiple unit test sets in the POM justification: some take a long time to run or require resources not always present, and should be omitted in regular development, but run in nightly builds for example. implementation: unitTest typedefault/type (same as if type ommitted) ... as before ... /unitTest unitTest typeperformance/type ... /unitTest unitTest typeintegration/type ... /unitTest unitTest typetouchstone/type ... /unitTest By default, just the first is run, but by setting -Dmaven.test.sets=performance,integration Then those will be run (and default which is always run) There will also be the special case of -Dmaven.test.sets=all, which will run everything. Or perhaps test:test-all? They could all use the same unitTestSourceDirectory, or move those into each unitTest set (with code to keep it backwards compatible). Each set would have its own junit report I imagine. - 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: (MAVEN-526) Add timeouts to the test plugin
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Mon, 4 Aug 2003 12:22 AM
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Fix Version changed to 1.1
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-526page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-526
Here is an overview of the issue:
-
Key: MAVEN-526
Summary: Add timeouts to the test plugin
Type: Improvement
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-test
Fix Fors:
1.1
Versions:
1.0-beta-8
1.0-beta-9
1.0-beta-10
Assignee:
Reporter: Julian Payne
Created: Mon, 30 Jun 2003 7:43 AM
Updated: Mon, 4 Aug 2003 12:22 AM
Description:
I need to be able to set a timeout in the unit tests because we have graphical tests
that block from time to time.
Here is what I would like to be added in the plugin.jelly as part of the junit element:
junit printSummary=${maven.junit.printsummary}
failureProperty=maven.test.failure
fork=${maven.junit.fork}
dir=${maven.junit.dir}
!-- start of script to control the timeouut --
j:if test=${context.getVariable('maven.junit.timeout') != null}
setProperty name=timeout value=${maven.junit.timeout} /
/j:if
!-- end of script to control the timeouut --
-
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: (MAVEN-525) maven-eclipse-plugin does not generate all artifacts one could expect
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:22 AM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-525page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-525 Here is an overview of the issue: - Key: MAVEN-525 Summary: maven-eclipse-plugin does not generate all artifacts one could expect Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-other Fix Fors: 1.1 Versions: 1.0-beta-10 Assignee: Reporter: gilles dodinet Created: Mon, 30 Jun 2003 1:43 AM Updated: Mon, 4 Aug 2003 12:22 AM Description: eclipse plugin doesnot generate all expected artifacts. for instance : * if build/aspectSourceDirectory is present in the pom, a source folder corresponding to this source directory should be added to the project AND aspectj nature should be attached to the eclipse project (assuming aspectj plugin has been installed) * if build/resource(s) are declared in the pom, a source folder should be created in the eclipse project for every unique resource folder. same goes for unitTest/resources (and perhaps integrationUnitTest ? never used it so im not sure of whats declared in the pom) - 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: (MAVEN-527) I would like to control the output of the unit tests
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Mon, 4 Aug 2003 12:23 AM
Comment:
A patch would help
Changes:
timeoriginalestimate changed from 0
timeestimate changed from 0 minutes
Fix Version changed to 1.1
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-527page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-527
Here is an overview of the issue:
-
Key: MAVEN-527
Summary: I would like to control the output of the unit tests
Type: Improvement
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-test
Fix Fors:
1.1
Versions:
1.0-beta-8
1.0-beta-9
1.0-beta-10
Assignee:
Reporter: Julian Payne
Created: Mon, 30 Jun 2003 7:52 AM
Updated: Mon, 4 Aug 2003 12:23 AM
Description:
I would like to be able to control the printing of exceptions when running the unit
tests. Today the output is hardcoded as:
junit printSummary=yes
and with the following report generators:
formatter type=xml/
formatter type=plain usefile=${maven.junit.usefile}/
Ideally what I would like is to have a property to control the printSummary:
junit printSummary=${maven.junit.printsummary}
-
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: (MAVEN-528) I would like more control over the packages that javadoc uses to generate online documentation
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:50 AM Comment: Patches would help Changes: timeoriginalestimate changed from 0 timeestimate changed from 0 minutes Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-528page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-528 Here is an overview of the issue: - Key: MAVEN-528 Summary: I would like more control over the packages that javadoc uses to generate online documentation Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-other Fix Fors: 1.1 Versions: 1.0-beta-8 1.0-beta-9 1.0-beta-10 Assignee: Reporter: Julian Payne Created: Mon, 30 Jun 2003 7:58 AM Updated: Mon, 4 Aug 2003 12:50 AM Description: Today the javadoc plugin takes the list of packages to be what is in the POM and it then appends .* on the end of pom.package. In our case we will put a.b.c as the package but there are some sub-packages that should not be documented via javadoc. In this case I would like to be able to specify a.b.c.d,a.b.c.e.f as the list of packages to document. I can suggest 2 possible ways to implement this: 1) If pom.package has a comma in it then don't add the .* 2) Add a new property for the plugin that overrides the pom.package if, and only if, it exists Thanks, Julian Payne - 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: (MAVEN-594) NullPointerException in jbuilder-plugin
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:53 AM Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-594page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-594 Here is an overview of the issue: - Key: MAVEN-594 Summary: NullPointerException in jbuilder-plugin Type: Bug Status: Unassigned Priority: Blocker Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-other Fix Fors: 1.1 Versions: 1.0-beta-10 Assignee: Reporter: Aleksander Blomsk?ld Created: Mon, 21 Jul 2003 6:16 AM Updated: Mon, 4 Aug 2003 12:53 AM Description: I get the following error while trying to use the jbuilder plugin. BUILD FAILED File.. file:/C:/Documents and Settings/Aleksander Blomskold/.maven/plugins/maven-jbuilder-plugin-1.3-SNAPSHOT/ Element... jbuilder:generateDependencyLibrary Line.. 482 Column 47 java.lang.NullPointerException Total time: 3 seconds - 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: (MAVEN-604) [multiproject] maven.multiproject.excludes should include default excludes values.
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:54 AM Comment: A patch would help Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-604page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-604 Here is an overview of the issue: - Key: MAVEN-604 Summary: [multiproject] maven.multiproject.excludes should include default excludes values. Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-other Fix Fors: 1.1 Versions: 1.0-beta-10 Assignee: Reporter: matthew hawthorne Created: Wed, 23 Jul 2003 6:26 PM Updated: Mon, 4 Aug 2003 12:54 AM Environment: windows 2k // CYGWIN_NT-5.0 Description: When the multiproject plugin searches for project.xml files, it finds them even if they are in directories that are typically excluded, such as a CVS directory. For example, it found a project.xml file that was not only in projectRoot, but also in projectRoot/CVS/Base, which caused it to build the project twice. I think that the default excludes values from ant should be good enough. - 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: (MAVEN-607) Updated IDEA plugin for Aurora (plugin attached)
The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Aug 2003 12:54 AM Comment: The issues discussed here haven't been resolved Changes: Fix Version changed to 1.1 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-607page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-607 Here is an overview of the issue: - Key: MAVEN-607 Summary: Updated IDEA plugin for Aurora (plugin attached) Type: Improvement Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Components: plugin-other Fix Fors: 1.1 Versions: 1.0-beta-10 Assignee: Reporter: Mike Cannon-Brookes Created: Thu, 24 Jul 2003 4:22 AM Updated: Mon, 4 Aug 2003 12:54 AM Description: We've created a plugin which generates IDEA's .ipr, .iml and .iws files. It works with IDEA Aurura EAP 856 build. Not sure it will work with other builds yet, but we will endeavour to update it going forward. I've attached a ZIP of the plugin here. - 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]
