[jira] Closed: (MAVEN-507) upload jdom b-9 to repo
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-507 Here is an overview of the issue: - Key: MAVEN-507 Summary: upload jdom b-9 to repo Type: Wish Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: dion gillard Reporter: Simon Lau Created: Thu, 19 Jun 2003 11:50 PM Updated: Mon, 23 Jun 2003 1:20 AM Description: This can be found at http://www.jdom.org/dist/binary/ - 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/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-506) upload castor xml 0.9.5 to repo
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-506 Here is an overview of the issue: - Key: MAVEN-506 Summary: upload castor xml 0.9.5 to repo Type: Wish Status: Closed Priority: Minor Resolution: FIXED Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: dion gillard Reporter: Simon Lau Created: Thu, 19 Jun 2003 11:48 PM Updated: Mon, 23 Jun 2003 1:23 AM Description: This can be found at http://castor.exolab.org/download.html - 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/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: private jar dependencies
-Original Message-
From: dion gillard [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 5:35 AM
To: [EMAIL PROTECTED]
Subject: Re: private jar dependencies
Michal Maczka wrote:
There is one more mean for realizing such scenario which was not
mentioned
here:
jar overriding mechanism (or more generally artifact overriding
mechanism).
I am personally for dropping the jar overriding mechanism.
and for replacing them with such fake remote repository as Aslak has
described.
Big, big -1 on this. I have a real need for the jar override facility.
We have maven users who run common sql through db2. they each have their
own db2 release, and MUST use the jar file that corresponds to their db2
install.
So they just override version? Not paths?
I am surly +1 for allowing overriding version.
This is also a must from the perspective of transitive dependencies
There must be some way of setting the preferred version or artifacts
Even if they are not listed as dependencies in project.xml
But we have two kinds of overrides:
maven.jar.artifactId = [path]
maven.jar.artifactId = [version]
First of all it's just heuristic guessing if user has overridden version or
path. And sometimes this guessing can fail (even ofen).
Secondly the version with [path] overriding is against maven philosophy of
forcing users to keep artifact in repositories.
Say that users have unversion artifacts inside his project (e.g in the
${basedir}/lib directory). They want to quickly switch to maven.
Maven should help them, but such help can be also resolved outside of maven
core using special fetchers.
Say you use fetcher which will during download convert paths like
/groupId/jars/artifactId-version.jar to ${basedir}/lib/artifactId.jar.
So after first run of such fetcher the local repository will be populated
with those jars. After some time when this operation was performed by all
team members the lib directory can be erased.
So -1 on first kind of overriding but +1 on second.
I also think that we should support per project repositories (they are in
practice threaten as another remote repository). This will allow easier
transition for project using e.g. ant to maven.
This will make the implementation cleaner.
And less functional.
There is a lot of places in maven where the fact that artifact was
overriden
is simply ignored.
This is a bug and should be fixed. Before 1.0
This feature probably is not used so often but surly plugins like
war, ear, eclipse are not aware of the fact that artifact can be
overriden!
and what they do is something like:
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type
=='jar' }
ant:lib
dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
ant:include name=${dep.artifact}/
/ant:lib
/j:if
So basiclly they require that artifact must be in local repository.
Any artifact thats listed as a dependency MUST be available in the local
repository.
Not really. If we use jar overriding with
maven.jar.artifactId = [path]
it can be anywhere.
[...]
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] Generated checkstyle html report
Looks good, thanks. Trygvis Vincent Massol wrote: Hi Trygve, I have applied your patch but haven't tested it. I hope it works! :-) Can you please verify it? Thanks -Vincent -Original Message- From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: 22 June 2003 19:59 To: [EMAIL PROTECTED] Subject: [patch] Generated checkstyle html report Hi Ive created a patch for the checkstyle.jsl script so that the error and line columns are aligned. It also sorts the filenames before iterating them. If someone likes it, please apply it :) Trygve - 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/artifact/deployer DefaultArtifactDeployer.java
michal 2003/06/23 02:49:38
Modified:src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
Log:
Implemented 5 file method.
Revision ChangesPath
1.6 +119 -99
maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Index: DefaultArtifactDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DefaultArtifactDeployer.java 20 Jun 2003 15:24:52 - 1.5
+++ DefaultArtifactDeployer.java 23 Jun 2003 09:49:38 - 1.6
@@ -56,9 +56,7 @@
*/
import java.io.File;
-import java.io.FileWriter;
import java.io.IOException;
-import java.io.Writer;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
@@ -89,6 +87,15 @@
/**
* @see ArtifactDeployer#deploy(String, String, Project)
+ * This is 5 files version.
+ * It deploys (example):
+ * foo-20030620.124616.jar,
+ * foo-20030620.124616.jar.md5 ,
+ * foo-SNAPSHOT.jar
+ * foo-SNAPSHOT.jar.md5
+ * foo-snapshot-version
+ *
+ *
*/
public void deploy(String artifact, String type, Project project)
throws MavenException
@@ -100,7 +107,13 @@
getRepositoryPath(type, project, project.getCurrentVersion());
String repositoryFile =
getRepositoryFile(type, project, project.getCurrentVersion());
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
+
+String[] inputFilenames =
+{ file.getAbsolutePath(), md5File.getAbsolutePath()};
+
+String[] outputFilenames = { repositoryFile, repositoryFile + .md5 };
+
+doDeploy(inputFilenames, outputFilenames, repositoryPath, project);
}
/**
@@ -109,16 +122,35 @@
public void deploySnapshot(String artifact, String type, Project project)
throws MavenException
{
+
+String snapshotVersion = getSnapshotVersion();
File file = getFileForArtifact(artifact);
File md5File = createMD5Checksum(file);
+File snapshotVersionFile =
+createSnapshotVersionFile(file, snapshotVersion, project, type);
String repositoryPath =
getRepositoryPath(type, project, MavenConstants.SNAPSHOT_SIGNIFIER);
-String repositoryFile =
+
+String[] inputFilenames = new String[5];
+inputFilenames[0] = file.getAbsolutePath();
+inputFilenames[1] = file.getAbsolutePath();
+inputFilenames[2] = md5File.getAbsolutePath();
+inputFilenames[3] = md5File.getAbsolutePath();
+inputFilenames[4] = snapshotVersionFile.getAbsolutePath();
+
+String out1 =
getRepositoryFile(type, project, MavenConstants.SNAPSHOT_SIGNIFIER);
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
+String out2 = getRepositoryFile(type, project, snapshotVersion);
-}
+String[] outputFilenames = new String[5];
+outputFilenames[0] = out1;
+outputFilenames[1] = out2;
+outputFilenames[2] = out1 + .md5;
+outputFilenames[3] = out2 + .md5;
+outputFilenames[4] = project.getArtifactId() + -snapshot-version;
+doDeploy(inputFilenames, outputFilenames, repositoryPath, project);
+
+};
/**
* @see ArtifactDeployer#install(String, String, Project)
@@ -207,11 +239,10 @@
* @param snapshot
*/
private void doDeploy(
-File file,
-File md5File,
-Project project,
-String repositoryPath,
-String repositoryFile)
+String[] inputFilenames,
+String[] outputFilenames,
+String outputPath,
+Project project)
throws MavenException
{
@@ -247,60 +278,45 @@
System.out.println(
Will deploy to + repoArray.length + repo(s): + repos);
-
-
for (int i = 0; i repoArray.length; i++)
{
String repo = repoArray[i].trim();
System.out.println(Deploying to repo: + repo);
-MavenDeployRequest deployRequest =
-new MavenDeployRequest(
-repo,
-project,
-repo,
-file.getAbsolutePath(),
-repositoryPath,
-repositoryFile);
-
-
War plugin
I am bit busy at the moment but hope to have time to work a bit on war plugin soon (hope to have it done before rc1 is out) There was a request to support bundling of TLD files in war archive. I am going to implement it. I am planning to set default directory for TLDS files accordingly to: http://developer.java.sun.com/developer/technicalArticles/javaserverpages/co de_convention/ so it will be context root/WEB-INF/tld/ and have property: maven.war.build.tld.dir which will allow to customize it I personally use following layout: context root/WEB-INF/tld/jstl/ context root/WEB-INF/tld/struts/ context root/WEB-INF/tld/foo/ for grouping certain taglibs. Such layout can be easily supported using groupId property of the dependency. Somebody else likes it? Maybe somebody knows better strategies? Any other types of artifact should be supported? Should we go down to the level of css, JavaScript files or even images (gifs, jpegs). I personally don't think so. I like the concept of web component dissussed some time ago. We can also think if we are going to have extra features like: appending tag libs dynamically to web.xml file. From the point of view of XML manipulation it is very simple. But then some extra metadata should be provided along with tlds dependency (like uri). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: War plugin
The location you've suggested is sensible, but personally I'd prefer if the tlds were delivered inside their jars. It seems more of a 'best practice' thing to do (eg it avoids problems with jars mismatching tlds) When deployed inside a JAR file, the tag library descriptor files must be in the META-INF directory, or a subdirectory of it. (JSP1.2, sec 7.3.1) Its only when the tld is deployed separately from the jar that you put it in WEB-INF. Is there a reason for distributing the TLDs separately? (I know JSP 1.1 only supported single tlds per jar, which wouldnt have worked for eg struts, but apart from that? - and is JSP1.1 a requirement?) As for manipulating web.xml - you don't need to add entries to web.xml for taglibs if the tlds follow the 1.2 spec: sec 7.3.4: The taglib map described in web.xml is extended with new entries extracted from TLD files in the Web Application. The new entries are computed as follows: Each TLD file is examined. If it has a uri element, then a new taglib element is created, with a taglib-uri subelement whose value is that of the uri elemement, and with a taglib-location subelement that refers to the TLD file. If the created taglib element has a different taglib-uri to any int he taglib map, it is added. You also dont need to list taglibs in web.xml if the [EMAIL PROTECTED] directive refers to the actual location of the taglib, eg: %@ taglib uri=/WEB-INF/tld/bingo.tld prefix=bongo % (this is in 7.3.6.3) Michal Maczka wrote: I am bit busy at the moment but hope to have time to work a bit on war plugin soon (hope to have it done before rc1 is out) There was a request to support bundling of TLD files in war archive. I am going to implement it. I am planning to set default directory for TLDS files accordingly to: http://developer.java.sun.com/developer/technicalArticles/javaserverpages/co de_convention/ so it will be context root/WEB-INF/tld/ and have property: maven.war.build.tld.dir which will allow to customize it I personally use following layout: context root/WEB-INF/tld/jstl/ context root/WEB-INF/tld/struts/ context root/WEB-INF/tld/foo/ for grouping certain taglibs. Such layout can be easily supported using groupId property of the dependency. Somebody else likes it? Maybe somebody knows better strategies? Any other types of artifact should be supported? Should we go down to the level of css, JavaScript files or even images (gifs, jpegs). I personally don't think so. I like the concept of web component dissussed some time ago. We can also think if we are going to have extra features like: appending tag libs dynamically to web.xml file. From the point of view of XML manipulation it is very simple. But then some extra metadata should be provided along with tlds dependency (like uri). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Privacy and Confidentiality Notice The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Otto von Wachter wrote: What I would like is to specify some private jar dependencies that are stored in a lib dir. Is there a quick hack that would allow me to do this? If it is, perhaps documenting it would increase the adoption of maven among users like me. If not would it be easy to add this feature? I have a private jar that I need for my other projects. When I build the private jar, I run: maven jar:install And it places the private jar in my local repository for me. From my other projects, I specify this private jar as a dependancy like any other. As the right version is already available locally, maven has no need to look for this private jar on ibiblio or anywhere else. Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: War plugin
The location you've suggested is sensible, but personally I'd prefer if the tlds were delivered inside their jars. It seems more of a 'best practice' thing to do (eg it avoids problems with jars mismatching tlds) How nice! So you are suggesting that best practice is to use tag libs only inside jars and not to bother at all! mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: War plugin
Tld bundling is supported right now by the war plugin. You can even put them wherever you want provided it's under the webapp/ source directory. I'm not sure adding a tld property helps a lot. I personally think it makes this simple plugin more complex. Person who want more flexibility (i.e. custom filters, etc) can simply override the webapp source directory and provide a preGoal. Am I missing something? Thanks -Vincent -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 23 June 2003 12:13 To: 'Maven Developers List' Subject: War plugin I am bit busy at the moment but hope to have time to work a bit on war plugin soon (hope to have it done before rc1 is out) There was a request to support bundling of TLD files in war archive. I am going to implement it. I am planning to set default directory for TLDS files accordingly to: http://developer.java.sun.com/developer/technicalArticles/javaserverpage s/ co de_convention/ so it will be context root/WEB-INF/tld/ and have property: maven.war.build.tld.dir which will allow to customize it I personally use following layout: context root/WEB-INF/tld/jstl/ context root/WEB-INF/tld/struts/ context root/WEB-INF/tld/foo/ for grouping certain taglibs. Such layout can be easily supported using groupId property of the dependency. Somebody else likes it? Maybe somebody knows better strategies? Any other types of artifact should be supported? Should we go down to the level of css, JavaScript files or even images (gifs, jpegs). I personally don't think so. I like the concept of web component dissussed some time ago. We can also think if we are going to have extra features like: appending tag libs dynamically to web.xml file. From the point of view of XML manipulation it is very simple. But then some extra metadata should be provided along with tlds dependency (like uri). Michal - 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: War plugin
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 2:18 PM
To: 'Maven Developers List'
Subject: RE: War plugin
Tld bundling is supported right now by the war plugin. You can even put
them wherever you want provided it's under the webapp/ source directory.
I meant the bundling of tag descriptor files (tlds) defined as project
dependencies
dependency
groupIdstruts/groupId
artifactIdstruts-tiles/artifactId
version1.1-rc2/type
typetld/type
/dependency
In war plugin we have:
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar' }
ant:copy todir=${webapp.build.lib}
file=${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}/
/j:if
Such bundling is not supported for tlds.
But after reading Brian's post I suppose that it should not be supported at
all.
The JSP spec defines clean and more natural way of making it.
I'm not sure adding a tld property helps a lot. I personally think it
makes this simple plugin more complex.
For the moment war plugin is indeed almost a wrapper around Ant war task.
But I don't see anything wrong in making this plugin (or any other) more
powerful or highly customizable.
For example we can add validation of web.xml file to this plugin.
But I admit that this particular idea was __stupid__
Please forget about it!
[...]
regards
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: war:war generates ${pom.artifactId}.war
A 15:47 23/06/2003 +0200, vous avez écrit :
Hi all,
can someone tell me why the war:war goal builds a WAR file named
${pom.artifactId}.war?
I expected ${maven.final.name}.war as name like jar:jar builds JAR files.
In plugin.jelly of the war-plugin there is ${maven.war.final.name}
defined. But its value equals to ${pom.artifactId}.
I guess the reason is that ${maven.final.name} contains version info and
the war built would be called something like : mywebapp-1.1.war
That would cause your web app to respond to the URL
http://www.myserver.net/mywebapp-1.1 instead of
http://www.myserver.net/mywebapp ; which obviously most people would not like.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-464) Reactor cannot find goals in plugin
The following comment has been added to this issue: Author: Brett Porter Created: Mon, 23 Jun 2003 9:18 AM Body: I don't think this belongs to maven-new? Anyway, I think I've seen this problem exhibited, but I have a sneaking suspicion that Jason's recent changes may have fixed them. If not, I still have a failing test case in touchstone to work it out, and I'll see if it can be added to RC1. - 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 Estimate: 0 minutes Project: maven Components: core Versions: maven-new-unreleased Assignee: Reporter: Charles Chan Created: Wed, 4 Jun 2003 12:44 PM Updated: Wed, 4 Jun 2003 12:45 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/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: war:war generates ${pom.artifactId}.war
Mouttet Christian wrote:
Hi all,
can someone tell me why the war:war goal builds a WAR file named
${pom.artifactId}.war? I expected ${maven.final.name}.war as name
like jar:jar builds JAR files.
Unfortunately war plugin is much unlike jar plugin... Michal is working
ATM to bring the deploy/snaphost functionality to the war plugin,
because it din't have it to date.
In plugin.jelly of the war-plugin there is ${maven.war.final.name}
defined. But its value equals to ${pom.artifactId}.
Certain developers prefer to have it versionless. I think it's a bad
idea - the artifact should be generated versioned, for the purpose
of installing it to the local repo / deploying to the remote repos.
It just does not make sense to have unversioned artifacts in the
repository.
If a plugin needs to have a war file with no version information in the
name for bundling/running/whatever it could always make a copy.
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs sun-licensing-journey.xml
jvanzyl 2003/06/23 08:18:47 Modified:xdocssun-licensing-journey.xml Log: o updating Revision ChangesPath 1.12 +8 -0 maven/xdocs/sun-licensing-journey.xml Index: sun-licensing-journey.xml === RCS file: /home/cvs/maven/xdocs/sun-licensing-journey.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- sun-licensing-journey.xml 19 Jun 2003 14:53:26 - 1.11 +++ sun-licensing-journey.xml 23 Jun 2003 15:18:47 - 1.12 @@ -70,6 +70,14 @@ [ 19 June 2003 ] I've sent a message to Tom Kincaid stating which packages we would like to access with the scraper. /li + li +[ 23 June 2003 ] Tom Kincaid wrote back and asked for details on +how the scraper would work. So just reassured him that +everything would come from the Sun sites and that the user would +still have to accept the license for the said package. The user +would just be saved from the details of locating the package +manually on a Sun site. + /li /ul /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC1
On Fri, 2003-06-20 at 14:57, Jason van Zyl wrote: I'm going to keep plugging away this weekend on some refactoring. I'm primarily interested in eliminating the massive memory leak and some efficiency problems with interpolation, plugin loading and inheritance. thanks a lot in advance I do not think it is wise to attempt a 1.0 release until these issues are resolved. any idea when you release a next version (beta10/rc1)? -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. Public Key on http://www.keyserver.net, Key-ID: 3D4027B5 Fingerprint: 1970 C78D 9A1D 99FA 5CE4 5C0D 29E6 6A95 3D40 27B5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-464) Reactor cannot find goals in plugin
The following comment has been added to this issue: Author: Charles Chan Created: Mon, 23 Jun 2003 12:06 PM Body: Yes, you're right, it's not coming from maven-new. Sorry for the confusion. - 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 Estimate: 0 minutes Project: maven Components: core Versions: maven-new-unreleased Assignee: Reporter: Charles Chan Created: Wed, 4 Jun 2003 12:44 PM Updated: Wed, 4 Jun 2003 12:45 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/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: Re: iBiblio upload request
Sounds good... I've renamed the dependency per your suggestion: dependency idbatik/id version1.5-fop-0.20-5.rc3/version /dependency As for the fop JAR, you are correct, the -rc3-alpha JAR in Ibiblio seems to be identical to the one I'm using. I have made that change to the PDF plug-in's project.xml as well. The JIRA issue has not been created. I do not have the ability to add issues to the Maven project. (Maven isn't listed on the drop-down...) Instead, I'll send you the tar file via email, presently. Andrew ---Original Message--- From: dion gillard [EMAIL PROTECTED] Sent: 06/22/03 11:31 PM To: [EMAIL PROTECTED] Subject: Re: iBiblio upload request [EMAIL PROTECTED] wrote: In preparation for the forthcoming PDF plugin update: dependency idfop/id version0.20.5rc3a/version /dependency How is this different from http://www.ibiblio.org/maven/fop/jars/fop-0.20.5-rc3-alpha.jar dependency idbatik/id version1.5nightly12nov2002/version /dependency The Batik jar included in the FOP 0.20.5rc3 release is the one that works -- I have called this, tentatively, 1.5nightly12nov2002. I could **not** get the current Batik release candidate to work. How about we give it a different name. Maybe 1.5-fop-0.20-5.rc3? or something to show where it came from? - 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/test/xdocs properties.xml
bwalding2003/06/23 16:40:02 Modified:src/plugins-build/test/xdocs properties.xml Log: Add doco about ignoring test failures Revision ChangesPath 1.5 +7 -0 maven/src/plugins-build/test/xdocs/properties.xml Index: properties.xml === RCS file: /home/cvs/maven/src/plugins-build/test/xdocs/properties.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- properties.xml26 Mar 2003 09:52:51 - 1.4 +++ properties.xml23 Jun 2003 23:40:01 - 1.5 @@ -56,6 +56,13 @@ /td /tr tr + tdmaven.test.failure.ignore/td + tdYes/td + td +Set this to any value to ignore a failure during testing. + /td +/tr +tr tdmaven.test.source/td tdYes/td td - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/test/xdocs properties.xml
bwalding2003/06/23 16:45:40 Modified:src/plugins-build/test/xdocs properties.xml Log: Add doco about ignoring test failures Revision ChangesPath 1.6 +2 -1 maven/src/plugins-build/test/xdocs/properties.xml Index: properties.xml === RCS file: /home/cvs/maven/src/plugins-build/test/xdocs/properties.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- properties.xml23 Jun 2003 23:40:01 - 1.5 +++ properties.xml23 Jun 2003 23:45:40 - 1.6 @@ -52,7 +52,7 @@ tdYes/td td Set this to 'true' to bypass unit tests entirely. Its use -is NOT RECOMMENDED, but quite convenient on occasion. +is bNOT RECOMMENDED/b, but quite convenient on occasion. /td /tr tr @@ -60,6 +60,7 @@ tdYes/td td Set this to any value to ignore a failure during testing. +Its use is bNOT RECOMMENDED/b, but quite convenient on occasion. /td /tr tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs faq.xml
bwalding2003/06/23 16:45:54 Modified:xdocsfaq.xml Log: Add doco about ignoring test failures Revision ChangesPath 1.31 +16 -0 maven/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/maven/xdocs/faq.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- faq.xml 30 Mar 2003 22:59:56 - 1.30 +++ faq.xml 23 Jun 2003 23:45:54 - 1.31 @@ -5,6 +5,7 @@ properties titleMaven FAQ/title author email=[EMAIL PROTECTED]Pete Kazmier/author +author email=[EMAIL PROTECTED]Ben Walding/author /properties body @@ -72,6 +73,11 @@ How do I get a resource uploaded to the central repository? /a /li +li + a href=#ignoring-broken-tests +How do I make my build complete even with broken tests? + /a +/li /ol p strongBuilding Maven/strong @@ -252,6 +258,16 @@ Java developers as possible so we chose Ibiblio where there is no restriction on store (L)GPL artifacts. You can find out more about Ibiblio a href=http://www.ibiblio.org/about.html;here/a. + /dd + dt +a name=ignoring-broken-tests + How do I make my build complete even with broken tests? +/a + /dt + dd +See the a href=./reference/plugins/test/properties.htmlTest Plugin Reference/a. +Most notably, codemaven.test.skip/code and codemaven.test.failure.ignore/code. +bHeed the warnings!/b /dd /dl /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Thanks for these two+ suggestions on how to work with
private jars.
While I can't contribute much on the implementation
details, I have some thoughts on the big picture.
You can tell someone that setting up an artifact repository
is the right way to do it, but regardless Maven/Ant users
will use whatever approach makes their life easier
(whatever solution is most appropriate for a given
situation).
In my case I want to use some of the features of Maven
(reports, web site, etc.) but don't need all of them. I
probably won't set up an artifact repository until the
incremental benefit of doing so outweighs the incremental
cost (complexity, time--remember setting up a repository
also involves maintaining, training, backing up, etc.) So
I don't think it should be an all-or-nothing choice.
Regards,
Otto
--- Jason van Zyl [EMAIL PROTECTED] wrote:
On Fri, 2003-06-20 at 18:55, Otto von Wachter wrote:
Hi all,
I have a question/suggestion on jar dependencies. I
think
maven is perfect for open source (large/collaborative)
projects. I would like to leverage Maven for my
internal
project at work, but not all dependencies are available
on
ibiblio (some are not open source, etc.) Also it makes
sense for us to keep these jars in CVS, to make sure
they
don't get lost, and just because it works.
What I would like is to specify some private jar
dependencies that are stored in a lib dir. Is there a
quick
hack that would allow me to do this? If it is, perhaps
documenting it would increase the adoption of maven
among
users like me. If not would it be easy to add this
feature?
I was thinking of something like this:
privateDependencies
libDirectorylib/libDirectory
/privateDependencies
or maybe
build
baseClasspath
fileset dir=lib
include name=*.jar/
/fileset
/baseClasspath
...
/build
I know this might go against the maven philosophy,
but it
would be optional, and it's one of the things that is
keeping me from using Maven instead of Ant.
Something for this will never be built into Maven. You
lose anything
Maven provides in the way of auto-downloading and
verification. I would
recommend you save yourself much grief and spend 10
minutes and make
yourself a local repository. But do what you like, here's
one way you
might do it:
project
xmlns:ant=jelly:ant
xmlns:maven=jelly:maven
preGoal name=java:compile
ant:path id=my.doublebarrel.classpath
fileset dir=${basedir}/lib
include name=**/*.jar/
/fileset
/ant:path
maven:addPath
id=maven.dependency.classpath
refid=my.doublebarrel.classpath/
/preGoal
/project
Again, I do not recommend you do this.
Otto
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a
rational
and technical order to justify his work and to be
justified in it.
-- Jacques Ellul, The Technological Society
-
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: private jar dependencies
Has anyone raised this in Jira?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Brian Ewins [EMAIL PROTECTED] wrote on 24/06/2003
01:17:09 AM:
Michal Maczka wrote:
[...]
(or something like that) - jelly should always use artifacts, not
dependencies, to construct paths. It doesnt stop you naming jars
whatever you like, if they are in the local repo. I had a look over
the
broken plugins a while back and I think there was only one case where
it
wasnt clear that the use of dependency was a bug.
Just to make myself more clear.
I wanted to say that in the most of the cases plugins don't need to
know
nothing about existence of local repository. They just can operateon
set of
file with absolute path. I think that such assumption (or rather lack
of any
assumptions) can result in simpler code.
I think we are in violent agreement...
So I simply don't agree with statement: jelly should always use
artifacts,
not dependencies, to construct paths.
But yet you say Plugin are supposed to work with artifacts in the
other post, which is basically what I am saying too.
dependencies don't know anything about their paths, and most of the
plugins[1] were guessing how to reconstruct the path to the artifact.
You're obviously agreeing that this is wrong.
When I said jelly should always use artifacts not deps to construct
paths, its precisely because these *are* the paths constructed in maven
core (artifact factory). I just hadn't spotted that I could use
getFile() as well as getPath(). You seem not to have noticed the
'include name=${lib.path}/' in my code is a jelly call to
artifact.getPath()?
Anyway, I was posting because you said Moreover there is no easy way of
determining if artifact was overriden or not (it is in maven-new, but
that's different story) - when as far as I can tell this problem is
fixable in the jelly for RC1? You don't need to know in a plugin whether
or not a jar is overridden, just the file.
I would rather prefer that jelly uses path constructed in maven core
(artifact factory) and ignore existence of such entity like local
repository.
Yup.
[1] A list from b8, posted to this list previously. All of these are
probably bugs:
brian [EMAIL PROTECTED] /c/maven/plugins
$ find . -name '*.jelly' | xargs grep pom.dependencies
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:j:forEach var=dep
items=${pom.dependencies}
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly: j:forEach
var=lib items=${pom.dependencies}
./maven-deploy-plugin-1.0/plugin.jelly: j:forEach var=dep
items=${pom.dependencies}
./maven-ear-plugin-1.0/plugin.jelly: j:forEach var=dep
items=${pom.dependencies}
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:j:forEach var=dep
items=${pom.dependencies}
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly: j:forEach var=dep
items=${pom.dependencies}
./maven-idea-plugin-1.0/plugin.jelly:j:forEach var=lib
items=${pom.dependencies}
./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly: j:forEach var=dep
items=${pom.dependencies}
./maven-jdeveloper-plugin-1.0-SNAPSHOT/plugin.jelly:
j:forEach var=dep items=${pom.dependencies}
./maven-jnlp-plugin-1.0/plugin.jelly:j:forEach
var=lib items=${pom.dependencies}
./maven-jnlp-plugin-1.0/plugin.jelly:j:forEach var=lib
items=${pom.dependencies}
./maven-release-plugin-1.0/plugin.jelly:j:forEach var=dependency
items=${pom.dependencies}
./maven-uberjar-plugin-1.0/plugin.jelly:j:forEach var=dep
items=${pom.dependencies}
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly: j:forEach var=dep
items=${pom.dependencies}
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:j:forEach var=dep
items=${pom.dependencies}
as are almost all of these (mostly related to the use above):
$ find . -name '*.jelly' | xargs grep maven.repo.local
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly: !-- know what the
user
wants for ${maven.home} and ${maven.repo.local} --
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:${maven.repo.local}
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:pathElement
location=${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}/
./maven-deploy-plugin-1.0/plugin.jelly: j:set var=mavenRepoLocal
value='${context.getVariable(maven.repo.local)}'/
./maven-ear-plugin-1.0/plugin.jelly: fileset
dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
./maven-ear-plugin-1.0/plugin.jelly: fileset
dir=${maven.repo.local}/${dep.artifactDirectory}/wars/
./maven-ear-plugin-1.0/plugin.jelly: fileset
dir=${maven.repo.local}/${dep.artifactDirectory}/ejbs/
./maven-ear-plugin-1.0/plugin.jelly:
value=${maven.repo.local}/${pom.artifactDirectory}/ears/
./maven-eclipse-plugin-1.2-SNAPSHOT/plugin.jelly:
