[Upload Request] cglib-asm-1.0.jar and cglib-bcel-1.0.jar
Please download those 2 files, and place them in cglib/jars http://sourceforge.net/project/showfiles.php?group_id=56933 Thanks -Dan
[Upload request] struts' validator-rules.xml
Hi Please upload validator-rules.xml which is part of strut 1.1 distribution located in struts' lib directory This file shoud be placed in struts/xmls dirctory , the file has this name: validator-rules-1.1.xml Thanks -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-564) PATCH - check for MAVEN_HOME variable at bootstrap
The following issue has been updated:
Updater: Felipe Leme (mailto:[EMAIL PROTECTED])
Date: Fri, 18 Jul 2003 10:14 AM
Comment:
file with the patch (as suggested in http://wiki.codehaus.org/maven/SubmittingPatches)
Changes:
Attachment changed to patch
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-564&page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-564
Here is an overview of the issue:
-
Key: MAVEN-564
Summary: PATCH - check for MAVEN_HOME variable at bootstrap
Type: Improvement
Status: Unassigned
Priority: Minor
Time Spent: Unknown
Remaining: 10 minutes
Project: maven
Components:
core
Versions:
1.0-beta-10
1.0-final
Assignee:
Reporter: Felipe Leme
Created: Mon, 14 Jul 2003 12:51 AM
Updated: Fri, 18 Jul 2003 10:14 AM
Environment: Any
Description:
Hi,
I tried to compile Maven from CVS, but it didn't work because I didn't have MAVEN_HOME
set.
It took me a while to figure that out, so I wrote a small patch to check that on ant.
Regards,
Felipe
[EMAIL PROTECTED]/cvs/maven-patched: cvs diff -u build-bootstrap.xml
Index: build-bootstrap.xml
===
RCS file: /home/cvspublic/maven/build-bootstrap.xml,v
retrieving revision 1.201
diff -u -r1.201 build-bootstrap.xml
--- build-bootstrap.xml 4 Jul 2003 22:43:13 - 1.201
+++ build-bootstrap.xml 14 Jul 2003 05:08:24 -
@@ -8,8 +8,12 @@
+
+ maven.home = ${maven.home}
+
+
-
+
maven.home = ${maven.home}
maven.home.local = ${maven.home.local}
maven.repo.local = ${maven.repo.local}
-
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-540) Property: maven.plugin.dir doesn't work
The following comment has been added to this issue:
Author: Olaf Kaus
Created: Fri, 18 Jul 2003 10:12 AM
Body:
If I can change the location of maven's plugin dir to a netfolder, everbody in my
company can use the same plugin-realeases.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540
Here is an overview of the issue:
-
Key: MAVEN-540
Summary: Property: maven.plugin.dir doesn't work
Type: Bug
Status: Unassigned
Priority: Trivial
Time Spent: Unknown
Remaining: 0 minutes
Project: maven
Components:
release
Versions:
1.0-beta-10
Assignee:
Reporter: Olaf Kaus
Created: Wed, 2 Jul 2003 10:37 AM
Updated: Fri, 18 Jul 2003 9:49 AM
Environment: Windows NT, JDK1.3.1_04
Description:
I put the following lines in the build.properties-File in $user.home\build.properties
(c:\Winnt\profiles\account\build.properties)
maven.repo.local = ${maven.home}/../maven_repository
maven.plugin.dir = ${maven.home}/../maven_plugins
The entry for the repository works fine, but for the maven.plugin.dir doesn't work.
The NT file-structure looks like this:
d:\maven-1.0-beta-9\bin\..
d:\maven-1.0-beta-9\lib\..
d:\maven_repository
d:\maven_plugins
The MAVEN_HOME-Env maps to: d:\maven-1.0-beta-9\
so, whats wrong?
-
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-540) Property: maven.plugin.dir doesn't work
The following comment has been added to this issue:
Author: Jason van Zyl
Created: Fri, 18 Jul 2003 10:01 AM
Body:
What do you need maven's plugin dir for. If you're going to add an issue please give
some sort of reason.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540
Here is an overview of the issue:
-
Key: MAVEN-540
Summary: Property: maven.plugin.dir doesn't work
Type: Bug
Status: Unassigned
Priority: Trivial
Time Spent: Unknown
Remaining: 0 minutes
Project: maven
Components:
release
Versions:
1.0-beta-10
Assignee:
Reporter: Olaf Kaus
Created: Wed, 2 Jul 2003 10:37 AM
Updated: Fri, 18 Jul 2003 9:49 AM
Environment: Windows NT, JDK1.3.1_04
Description:
I put the following lines in the build.properties-File in $user.home\build.properties
(c:\Winnt\profiles\account\build.properties)
maven.repo.local = ${maven.home}/../maven_repository
maven.plugin.dir = ${maven.home}/../maven_plugins
The entry for the repository works fine, but for the maven.plugin.dir doesn't work.
The NT file-structure looks like this:
d:\maven-1.0-beta-9\bin\..
d:\maven-1.0-beta-9\lib\..
d:\maven_repository
d:\maven_plugins
The MAVEN_HOME-Env maps to: d:\maven-1.0-beta-9\
so, whats wrong?
-
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-540) Property: maven.plugin.dir doesn't work
The following issue has been updated:
Updater: Olaf Kaus (mailto:[EMAIL PROTECTED])
Date: Fri, 18 Jul 2003 9:49 AM
Comment:
- New Constants: maven.plugin.dir
Changes:
Attachment changed to MavenConstants.patch
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540&page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540
Here is an overview of the issue:
-
Key: MAVEN-540
Summary: Property: maven.plugin.dir doesn't work
Type: Bug
Status: Unassigned
Priority: Trivial
Time Spent: Unknown
Remaining: 0 minutes
Project: maven
Components:
release
Versions:
1.0-beta-10
Assignee:
Reporter: Olaf Kaus
Created: Wed, 2 Jul 2003 10:37 AM
Updated: Fri, 18 Jul 2003 9:49 AM
Environment: Windows NT, JDK1.3.1_04
Description:
I put the following lines in the build.properties-File in $user.home\build.properties
(c:\Winnt\profiles\account\build.properties)
maven.repo.local = ${maven.home}/../maven_repository
maven.plugin.dir = ${maven.home}/../maven_plugins
The entry for the repository works fine, but for the maven.plugin.dir doesn't work.
The NT file-structure looks like this:
d:\maven-1.0-beta-9\bin\..
d:\maven-1.0-beta-9\lib\..
d:\maven_repository
d:\maven_plugins
The MAVEN_HOME-Env maps to: d:\maven-1.0-beta-9\
so, whats wrong?
-
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-540) Property: maven.plugin.dir doesn't work
The following issue has been updated:
Updater: Olaf Kaus (mailto:[EMAIL PROTECTED])
Date: Fri, 18 Jul 2003 9:48 AM
Comment:
- The Property: maven.plugin.dir is now used
- New Method for validating dir-access
Changes:
Attachment changed to PluginManager.patch
-
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540&page=history
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540
Here is an overview of the issue:
-
Key: MAVEN-540
Summary: Property: maven.plugin.dir doesn't work
Type: Bug
Status: Unassigned
Priority: Trivial
Time Spent: Unknown
Remaining: 0 minutes
Project: maven
Components:
release
Versions:
1.0-beta-10
Assignee:
Reporter: Olaf Kaus
Created: Wed, 2 Jul 2003 10:37 AM
Updated: Fri, 18 Jul 2003 9:48 AM
Environment: Windows NT, JDK1.3.1_04
Description:
I put the following lines in the build.properties-File in $user.home\build.properties
(c:\Winnt\profiles\account\build.properties)
maven.repo.local = ${maven.home}/../maven_repository
maven.plugin.dir = ${maven.home}/../maven_plugins
The entry for the repository works fine, but for the maven.plugin.dir doesn't work.
The NT file-structure looks like this:
d:\maven-1.0-beta-9\bin\..
d:\maven-1.0-beta-9\lib\..
d:\maven_repository
d:\maven_plugins
The MAVEN_HOME-Env maps to: d:\maven-1.0-beta-9\
so, whats wrong?
-
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-340) Pb with maven -g listing all goals (even the non public ones)
The following issue has been updated: Updater: Brett Porter (mailto:[EMAIL PROTECTED]) Date: Fri, 18 Jul 2003 9:38 AM Comment: while it was already implemented, the plugin cache was causing null's to be loaded as "null" instead of a real null. patch attached to fix it Changes: Attachment changed to MAVEN-340.diff - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-340&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-340 Here is an overview of the issue: - Key: MAVEN-340 Summary: Pb with maven -g listing all goals (even the non public ones) Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: 0 minutes Project: maven Components: core Versions: 1.0-beta-9 Assignee: Reporter: Vincent Massol Created: Wed, 19 Mar 2003 12:51 PM Updated: Fri, 18 Jul 2003 9:38 AM Description: It seems doing a "maven -g" nows lists *all* goals, even those that do not have a description. Thus my question is: how do you make a goal private (i.e. not visible by the end user)? For example, typing "maven -g" get the following for the cactus plugin: [cactus] ( NO DEFAULT GOAL ) compile Compile Cactus tests generate ... Generate HTML report init ... null merge-webxml ... null single . Execute a single test defined using the ' mavencactustestcase' variable test ... Execute all testcases test-init .. null test-swing . Start the tests using the swing runner test-text .. Start the tests using the text runner test-text-single ... Start the tests using the text runner webapp . Create the Cactus webapp webapp-update .. null BTW, "null" is not a very nice description... ;-) Thanks -Vincent - 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-535) maven-ydoc plugin
The following comment has been added to this issue: Author: Brett Porter Created: Fri, 18 Jul 2003 9:01 AM Body: Sorry, but you'll have to upload to maven-plugins.sf.net At present maven can't distribute JARs not licensed under the ASL (I assume this is the case here). - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-535 Here is an overview of the issue: - Key: MAVEN-535 Summary: maven-ydoc plugin Type: New Feature Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 0 minutes Project: maven Versions: 1.0-beta-10 Assignee: Reporter: Tobias Rademacher Created: Tue, 1 Jul 2003 7:18 AM Updated: Tue, 1 Jul 2003 7:24 AM Environment: Tests on WindowsNT, Solaris Description: YDoc is commercial tool on top of JavaDoc (a Doclet) that generates UML Diagrams right into your JavaDoc. You need a valid licences file to get ydoc running. The current plugin jelly-script assumes that the licenes key is installed under $maven.repo.remote/ydoc/resources. You have to change it to $maven.repo.local or to any other place you may favor. - 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-584) multiproject - make aggregation directory path configurable
The following issue has been updated: Updater: Rafal Krzewski (mailto:[EMAIL PROTECTED]) Date: Fri, 18 Jul 2003 8:56 AM Comment: The patch Changes: Attachment changed to multiproject-aggregateDir.diff - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-584&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-584 Here is an overview of the issue: - Key: MAVEN-584 Summary: multiproject - make aggregation directory path configurable Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Assignee: Reporter: Rafal Krzewski Created: Fri, 18 Jul 2003 8:56 AM Updated: Fri, 18 Jul 2003 8:56 AM Description: At this moment the directory where the aggregated subsites are copied to is fixed at target/multiproject/. I've made a patch that allows the user to configure this as 'maven.multiproject.aggregateDir'. The directories where the sites itselves are copied to are right now named afer $pom.name. I think it's not a good idea because project names may contain spaces, which results in urls with embedded '%20' strings showing up. The patch makes the plugin use $pom.artifactId instead. Note that this patch contains also the patch for MAVEN-574. - If you apply this patch, please discard the other one. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-584) multiproject - make aggregation directory path configurable
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-584 Here is an overview of the issue: - Key: MAVEN-584 Summary: multiproject - make aggregation directory path configurable Type: Improvement Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: maven Assignee: Reporter: Rafal Krzewski Created: Fri, 18 Jul 2003 8:56 AM Updated: Fri, 18 Jul 2003 8:56 AM Description: At this moment the directory where the aggregated subsites are copied to is fixed at target/multiproject/. I've made a patch that allows the user to configure this as 'maven.multiproject.aggregateDir'. The directories where the sites itselves are copied to are right now named afer $pom.name. I think it's not a good idea because project names may contain spaces, which results in urls with embedded '%20' strings showing up. The patch makes the plugin use $pom.artifactId instead. Note that this patch contains also the patch for MAVEN-574. - If you apply this patch, please discard the other one. - 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-386) Ampersands in navigation.xml being escaped twice during xml parsing
The following comment has been added to this issue: Author: Brett Porter Created: Fri, 18 Jul 2003 7:33 AM Body: works for me! Can you confirm it is still present in beta-10? - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-386 Here is an overview of the issue: - Key: MAVEN-386 Summary: Ampersands in navigation.xml being escaped twice during xml parsing Type: Bug Status: Unassigned Priority: Minor Time Spent: Unknown Remaining: 0 minutes Project: maven Components: plugin-xdoc Versions: 1.0-beta-8 Assignee: Reporter: Andrew Mace Created: Fri, 11 Apr 2003 6:21 AM Updated: Fri, 11 Apr 2003 6:21 AM Description: Within my Maven navigation.xml i would like to include a URL that includes parameter (&s). So if I place & or & after the xml is parsed the URL that is generated in the html files have '&' instead of an '&' I have the xml encoding ISO-8859-1 - 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-574) multiproject:site fails with "Goal [xdoc:register-reports] has no action definition."
The following issue has been updated: Updater: Rafal Krzewski (mailto:[EMAIL PROTECTED]) Date: Fri, 18 Jul 2003 7:31 AM Comment: Here's a patch for the plugin.jelly file, that detects the situation when the super project is included into the subproject set at preprocessing stage, and stops the build with an apropriate message. Changes: Attachment changed to multiproject-excludeParent.difff - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-574&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-574 Here is an overview of the issue: - Key: MAVEN-574 Summary: multiproject:site fails with "Goal [xdoc:register-reports] has no action definition." Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0-beta-10 Assignee: Reporter: Rafal Krzewski Created: Wed, 16 Jul 2003 4:13 AM Updated: Fri, 18 Jul 2003 7:31 AM Environment: Linux, JDK 1.4.2 Description: I'm trying out the multiporoject integration plugin, but can't get it to work. I'm able to run "maven site" on the main project and all subproject individually, I'm also able to run goals on the whole project using multiproject plugin, like "maven -Dgoal=install-snapshot multiproject:goal". The problem occurs when running "maven multisite", or "maven -Dgoal=site multiproject:goal". I'm attaching a minimal testcase that exhibits the error, and sample output of "maven -X multiproject" run. - 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-395) Shrinkwrapped maven install should not have duplicate xerces / xml-api jars
Message: The following issue has been closed. Resolver: Ben Walding Date: Fri, 18 Jul 2003 6:57 AM MAVEN-470 - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-395 Here is an overview of the issue: - Key: MAVEN-395 Summary: Shrinkwrapped maven install should not have duplicate xerces / xml-api jars Type: Improvement Status: Closed Priority: Trivial Resolution: DUPLICATE Time Spent: Unknown Remaining: 30 minutes Project: maven Versions: 1.0-beta-9 Assignee: Reporter: Ben Walding Created: Mon, 14 Apr 2003 8:45 AM Updated: Fri, 18 Jul 2003 6:57 AM Description: The shrinkwrapped jars that get produced for releases have copies of the xerces jars in both the lib and lib/endorsed directories. This is an unnecessary 1M download. We should also consider precopying everything in lib to the repository on the first run. This will also save download time for new users. Not everyone has insanity speed broadband! - 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-395) Shrinkwrapped maven install should not have duplicate xerces / xml-api jars
The following comment has been added to this issue: Author: Brett Porter Created: Fri, 18 Jul 2003 6:40 AM Body: patch already submitted under MAVEN-470 - this is a dupe. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-395 Here is an overview of the issue: - Key: MAVEN-395 Summary: Shrinkwrapped maven install should not have duplicate xerces / xml-api jars Type: Improvement Status: Unassigned Priority: Trivial Time Spent: Unknown Remaining: 30 minutes Project: maven Versions: 1.0-beta-9 Assignee: Reporter: Ben Walding Created: Mon, 14 Apr 2003 8:45 AM Updated: Mon, 14 Apr 2003 8:45 AM Description: The shrinkwrapped jars that get produced for releases have copies of the xerces jars in both the lib and lib/endorsed directories. This is an unnecessary 1M download. We should also consider precopying everything in lib to the repository on the first run. This will also save download time for new users. Not everyone has insanity speed broadband! - 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]
Maven B10 build from CVS HEAD 2003-07-18 broken?!
Hi folks, I just downloaded CVSHEAD to test my plugins and the build fails on my Windows box. Thanks in advance Siegfried Goeschl + | Building Maven Changelog Plug-in | Memory: 45M/65M + clean:clean: clean: plugin: java:prepare-filesystem: [mkdir] Created dir: W:\work\jakarta\maven\src\plugins- build\changelog\target\classes java:compile: [echo] Compiling to W:\work\jakarta\maven\src\plugins- build\changelog/target/classes [javac] Compiling 17 source files to W:\work\jakarta\maven\src\plugins-build\changelog\target\classes W:\work\jakarta\maven\src\plugins- build\changelog\src\main\org\apache\maven\cvslib\CvsChangeLogGenerator .java:106: cannot res olve symbol symbol : method splitSCMConnection (java.lang.String) location: class org.apache.maven.project.Repository String tokens[] = Repository.splitSCMConnection(getConnection()); ^ 1 error BUILD FAILED File.. file:/W:/work/jakarta/maven/ Element... maven:reactor Line.. 60 Column 7 Unable to obtain goal [plugin] -- file:/c:/apps/java/maven/plugins/maven-java-plugin-1.3/:55:48: Compile failed; see the compiler error output for details. Total time: 18 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Results of clean bootstrap at 20030718-0317
Last 500 lines of a clean bootstrap build of maven at 20030718-0317 [exec] [jar] Building jar: /home/bwalding/src/maven/src/plugins-build/vdoclet/target/maven-vdoclet-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/bwalding/.maven/repository/maven/jars [exec] + [exec] | Building Maven WAR Plugin [exec] | Memory: 145M/179M [exec] + [exec] clean:clean: [exec] clean: [exec] plugin: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/war/target/classes [exec] java:compile: [exec] [echo] Compiling to /home/bwalding/src/maven/src/plugins-build/war/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] [copy] Copying 4 files to /home/bwalding/src/maven/src/plugins-build/war/target/classes [exec] test:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/war/target/test-classes [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/war/target/test-reports [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test source files to compile. [exec] test:test: [exec] [echo] No tests to run. [exec] jar:jar: [exec] [jar] Building jar: /home/bwalding/src/maven/src/plugins-build/war/target/maven-war-plugin-1.4-SNAPSHOT.jar [exec] [copy] Copying 1 file to /home/bwalding/.maven/repository/maven/jars [exec] + [exec] | Building Maven WebSphere 4.0 Plug-in [exec] | Memory: 145M/179M [exec] + [exec] clean:clean: [exec] clean: [exec] plugin: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/was40/target/classes [exec] java:compile: [exec] [echo] Compiling to /home/bwalding/src/maven/src/plugins-build/was40/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] [copy] Copying 4 files to /home/bwalding/src/maven/src/plugins-build/was40/target/classes [exec] test:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/was40/target/test-classes [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/was40/target/test-reports [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test source files to compile. [exec] test:test: [exec] [echo] No tests to run. [exec] jar:jar: [exec] [jar] Building jar: /home/bwalding/src/maven/src/plugins-build/was40/target/maven-was40-plugin-1.0.jar [exec] [copy] Copying 1 file to /home/bwalding/.maven/repository/maven/jars [exec] + [exec] | Building Maven Webserver Plugin [exec] | Memory: 147M/179M [exec] + [exec] clean:clean: [exec] clean: [exec] plugin: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/webserver/target/classes [exec] java:compile: [exec] [echo] Compiling to /home/bwalding/src/maven/src/plugins-build/webserver/target/classes [exec] [echo] No java source files to compile. [exec] java:jar-resources: [exec] [copy] Copying 1 file to /home/bwalding/src/maven/src/plugins-build/webserver/target/classes/plugin-resources [exec] [copy] Copying 4 files to /home/bwalding/src/maven/src/plugins-build/webserver/target/classes [exec] test:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/webserver/target/test-classes [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/webserver/target/test-reports [exec] test:test-resources: [exec] test:compile: [exec] [echo] No test source files to compile. [exec] test:test: [exec] [echo] No tests to run. [exec] jar:jar: [exec] [jar] Building jar: /home/bwalding/src/maven/src/plugins-build/webserver/target/maven-webserver-plugin-2.0-dev.jar [exec] [copy] Copying 1 file to /home/bwalding/.maven/repository/maven/jars [exec] + [exec] | Building Maven Wizard Plug-in [exec] | Memory: 149M/179M [exec] + [exec] clean:clean: [exec] clean: [exec] plugin: [exec] java:prepare-filesystem: [exec] [mkdir] Created dir: /home/bwalding/src/maven/src/plugins-build/wizard/target/classes [exec] java:compile: [exec
Re: Workflow for submitting a patch?
Added to the wiki http://wiki.codehaus.org/maven/SubmittingPatches Free goodwill to anyone who goes and cleans it up! Rafal Krzewski wrote: Kaus Olaf wrote: Hi "Maviacs", I am a newbie in the OpenSource-Business and I would like to support the community. I fix the Bug ISSUE: "(MAVEN-540) Property: maven.plugin.dir doesn't work", http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540 but I don't know how to submit the patch. So, how is the workflow to submit a patch to the community? First of all you need to file an issue that describes the problem, or enhancement, but I see you have done it already. Once you have your patch ready, please attach it to the issue you have filed, using 'attach file' option. Remember to use always unidiff (cvs diff -uN) format - most developers refuse to read the default diff format. If the issue in in 'Assigned' status, a developer will be notified of the patch automatically. If your issues is still 'Unassigned' it might be a good idea to approach a developer who has been active in the area affected by the patch. You can find such person by looking at the @author javadocs tags and commit logs. A short email 'Please take a look at MAVEN-x, it has a patch ready.' to a developer is approved by the netiquetted, and generaly gives a better chance of getting your patch in than posting about it to the list, or just waiting that someone notices it. If you can't tell the right person I'd recommend writing to Ben Walding - I've some good experience working with him on the few patches I've submitted (thanks Ben!) The developer who picks up the patch will review it and eiter commit it, or come back to you with additional questions / requests. It is usually done with issue comments, so make sure you have 'watch issue' option turned on on all issues you report. After the patch is successfully applied (or rejected, this also happens from time to time) the issue is closed and the process ends (lest the issue gets reopened later). Thanks for your contribution, and good luck! R. - 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]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers GenericSshDeployer.java
bwalding2003/07/18 00:37:18
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
GenericSshDeployer.java
Log:
Fix typo. passpharse -> passphrase
Revision ChangesPath
1.5 +2 -2
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/GenericSshDeployer.java
Index: GenericSshDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/GenericSshDeployer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- GenericSshDeployer.java 17 Jul 2003 11:13:17 - 1.4
+++ GenericSshDeployer.java 18 Jul 2003 07:37:17 - 1.5
@@ -154,7 +154,7 @@
{
String msg =
"Private key provided "
-+ "without passpharse for repo: "
++ "without passphrase for repo: "
+ repoInfo.getRepositoryAlias();
throw new AuthenticationException(msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Workflow for submitting a patch?
Kaus Olaf wrote: > Hi "Maviacs", > > I am a newbie in the OpenSource-Business and I would like to support the community. > I fix the Bug ISSUE: "(MAVEN-540) Property: maven.plugin.dir doesn't work", > http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540 > > but I don't know how to submit the patch. > So, how is the workflow to submit a patch to the community? First of all you need to file an issue that describes the problem, or enhancement, but I see you have done it already. Once you have your patch ready, please attach it to the issue you have filed, using 'attach file' option. Remember to use always unidiff (cvs diff -uN) format - most developers refuse to read the default diff format. If the issue in in 'Assigned' status, a developer will be notified of the patch automatically. If your issues is still 'Unassigned' it might be a good idea to approach a developer who has been active in the area affected by the patch. You can find such person by looking at the @author javadocs tags and commit logs. A short email 'Please take a look at MAVEN-x, it has a patch ready.' to a developer is approved by the netiquetted, and generaly gives a better chance of getting your patch in than posting about it to the list, or just waiting that someone notices it. If you can't tell the right person I'd recommend writing to Ben Walding - I've some good experience working with him on the few patches I've submitted (thanks Ben!) The developer who picks up the patch will review it and eiter commit it, or come back to you with additional questions / requests. It is usually done with issue comments, so make sure you have 'watch issue' option turned on on all issues you report. After the patch is successfully applied (or rejected, this also happens from time to time) the issue is closed and the process ends (lest the issue gets reopened later). Thanks for your contribution, and good luck! R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
