cvs commit: maven-plugins/eclipse/xdocs changes.xml properties.xml
epugh 2004/10/19 04:55:28
Modified:eclipse/src/plugin-resources/templates classpath.jelly
eclipse/src/plugin-test maven.xml
eclipse/xdocs changes.xml properties.xml
Log:
MPECLIPSE-50 Support for Eclipse-Plugin maven projects (or kind=con classpath)
Revision ChangesPath
1.27 +4 -0
maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly
Index: classpath.jelly
===
RCS file:
/home/cvs/maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- classpath.jelly 15 Oct 2004 18:08:29 - 1.26
+++ classpath.jelly 19 Oct 2004 11:55:28 - 1.27
@@ -92,6 +92,10 @@
ant:echoSetting compile of ${testSrcDir} to ${testOutputDir}/ant:echo
classpathentry kind=src path=${testSrcDir} output=${testOutputDir}/
+u:tokenize var=conclasspaths
delim=,${maven.eclipse.conclasspath}/u:tokenize
+j:forEach var=conclasspath items=${conclasspaths} trim=true
+ classpathentry kind=con path=${conclasspath}/
+/j:forEach
!-- Here are the rules:
If the project has maven.eclipse.junit property, add that ver of junit
1.15 +14 -1 maven-plugins/eclipse/src/plugin-test/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/maven-plugins/eclipse/src/plugin-test/maven.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- maven.xml 15 Oct 2004 13:48:11 - 1.14
+++ maven.xml 19 Oct 2004 11:55:28 - 1.15
@@ -20,7 +20,7 @@
xmlns:u=jelly:util
xmlns:x=jelly:xml
- goal name=testPlugin
prereqs=test-eclipse,test-natures,test-builders,test-natures-and-builders,test-classpath-has-generated-source,test-classpath-has-overridden-jar,test-noduplicates
+ goal name=testPlugin
prereqs=test-eclipse,test-natures,test-builders,test-natures-and-builders,test-classpath-has-generated-source,test-classpath-has-overridden-jar,test-noduplicates,test-classpath-con-entry
/goal
goal name=test-init
@@ -141,5 +141,18 @@
x:set var=countUniqueSrc
select=count($classpathDoc/classpath/classpathentry[contains(@path,'src/main')])/
assert:assertEquals expected=1
value=${countUniqueSrc.intValue().toString()} msg=Src directory should be added
only once/
/goal
+
+ goal name=test-classpath-con-entry
+ attainGoal name=test-init/
+ j:set var=maven.eclipse.conclasspath
value=org.eclipse.pde.core.requiredPlugins/
+attainGoal name=eclipse/
+
+assert:assertFileExists file=${dotClasspath} /
+
+u:file var=classpathFile name=${dotClasspath}/
+x:parse var=classpathDoc xml=${classpathFile.toURL()} /
+x:set var=countConEntries
select=count($classpathDoc/classpath/classpathentry[contains(@kind,'con')])/
+assert:assertEquals expected=2
value=${countConEntries.intValue().toString()} msg=Classpath entry kind='con'
should be added twice, once mandatory, other variable/
+ /goal
/project
1.34 +1 -0 maven-plugins/eclipse/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven-plugins/eclipse/xdocs/changes.xml,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- changes.xml 15 Oct 2004 09:45:05 - 1.33
+++ changes.xml 19 Oct 2004 11:55:28 - 1.34
@@ -25,6 +25,7 @@
/properties
body
release version=1.9 date=in cvs
+ action dev=epugh type=add issue=MPECLIPSE-50 due-to=Simon
RinguetteSupport for Eclipse-Plugin maven projects (or kind=con
classpath)./action
action dev=epugh type=fix issue=MPECLIPSE-49 due-to=Fabrizio
Giustinaduplicate build path added if resouce directory is the same as java source
dir./action
action dev=epugh type=fix issue=MPECLIPSE-48 due-to=Fabrizio
GiustinaSimple implementation of handling source artifacts./action
action dev=evenisse type=fix issue=MPECLIPSE-47Add resources
directories and test resources directories to .classpath./action
1.13 +10 -1 maven-plugins/eclipse/xdocs/properties.xml
Index: properties.xml
===
RCS file: /home/cvs/maven-plugins/eclipse/xdocs/properties.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- properties.xml15 Oct 2004 09:45:05 - 1.12
+++ properties.xml19 Oct 2004 11:55:28 - 1.13
@@ -77,8 +77,17 @@
tdmaven.eclipse.classpath.include/td
tdYes/td
td
-Comma delimited list of additional directories
[jira] Commented: (MPECLIPSE-48) handling source attachments (patch)
The following comment has been added to this issue: Author: David Eric Pugh Created: Tue, 19 Oct 2004 7:58 AM Body: I have applied and committed the patch. However, i think this introduced a bug.. the src/java directory is being added multiple times now... - View this comment: http://jira.codehaus.org/browse/MPECLIPSE-48?page=comments#action_25557 - View the issue: http://jira.codehaus.org/browse/MPECLIPSE-48 Here is an overview of the issue: - Key: MPECLIPSE-48 Summary: handling source attachments (patch) Type: Improvement Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-eclipse-plugin Versions: 1.9 Assignee: Reporter: fabrizio giustina Created: Tue, 12 Oct 2004 4:36 PM Updated: Tue, 19 Oct 2004 7:58 AM Description: Actually maven repository doesn't contain source artifacts, however it would be nice if eclipse users could have a way to handle source for jars and have them added to eclipse .classpath (needed for debug and javadocs). The attached path let users store sources in the local maven repository in the same way other artifacts are managed. Through the modification of the jar path the plugin will look for the sources file and, if existing, it will add them to the .classpath file. The position of src files is controlled by 2 plugin properties: maven.eclipse.src.dir (directory for source artifact type) and maven.eclipse.src.extension (extension for files). These are temporarely managed as eclipse plugin properties till there is a standard maven default for them. As an example, using the default values for these properties: MAVEN_REPO/eclipse/jars/eclipse-ui-3.0.0.jar will be mapped to MAVEN_REPO/eclipse/src/eclipse-ui-3.0.0.zip If the source zip is not available, it will not be added to the classpath file, so it will not cause any problem to users who don't have sources in their local repository. - 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: (MPECLIPSE-8) Support shared Eclipse launch configurations
Message: The following issue has been closed. Resolver: David Eric Pugh Date: Tue, 19 Oct 2004 8:00 AM Over a year old, time to close it! - View the issue: http://jira.codehaus.org/browse/MPECLIPSE-8 Here is an overview of the issue: - Key: MPECLIPSE-8 Summary: Support shared Eclipse launch configurations Type: New Feature Status: Closed Priority: Minor Resolution: INCOMPLETE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-eclipse-plugin Fix Fors: 1.9 Assignee: David Eric Pugh Reporter: Charlie Dobbie Created: Mon, 6 Oct 2003 7:34 AM Updated: Tue, 19 Oct 2004 8:00 AM Environment: All Description: I think it would be useful to be able to execute shared Eclipse launch configurations from Maven. An example launch configuration may look like this (Eclipse 2.1.1): ?xml version=1.0 encoding=UTF-8? launchConfiguration type=org.eclipse.jdt.launching.localJavaApplication stringAttribute key=org.eclipse.jdt.launching.MAIN_TYPE value=mypackage.MyClassName/ stringAttribute key=org.eclipse.jdt.launching.PROJECT_ATTR value=MyProjectName/ listAttribute key=org.eclipse.debug.ui.favoriteGroups listEntry value=org.eclipse.debug.ui.launchGroup.run/ /listAttribute stringAttribute key=org.eclipse.debug.ui.target_debug_perspective value=perspective_default/ stringAttribute key=org.eclipse.debug.ui.target_run_perspective value=perspective_default/ stringAttribute key=org.eclipse.debug.core.source_locator_id value=org.eclipse.jdt.debug.ui.javaSourceLocator/ /launchConfiguration I believe Eclipse locates shared launch configurations by searching the project's tree for *.launch files. (Local configurations reside in the .metadata tree, but are out of scope of this request.) I am not sure how best to expose this functionality to the Maven system. Perhaps a plugin-eclipse goal would read the class to run from a property, so it could be invoked by one of: j:set var=maven.eclipse.launchConfiguration value=com.company.Main/ j:attainGoal name=eclipse:execute-launch-configuration/ or: maven -Dmaven.eclipse.launchConfiguration=com.company.Main eclipse:execute-launch-configuration Or maybe the eclipse-plugin goal would process the launch files and add them to the project's maven.xml as java tasks, so the goal is a one-shot setup task, much like the other plugin-eclipse goals. I welcome any and all comments on this feature request - thoughts on implementation, usefulness or even whether or not it's a good idea! - 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: (MPECLIPSE-26) Add a property to dependencies to link to source
Message: The following issue has been closed. Resolver: David Eric Pugh Date: Tue, 19 Oct 2004 7:59 AM See MPECLIPSE-48 handling source attachments (patch), this has been added in a limited fashion. - View the issue: http://jira.codehaus.org/browse/MPECLIPSE-26 Here is an overview of the issue: - Key: MPECLIPSE-26 Summary: Add a property to dependencies to link to source Type: Improvement Status: Closed Priority: Major Resolution: DUPLICATE Original Estimate: 2 hours Time Spent: Unknown Remaining: 2 hours Project: maven-eclipse-plugin Fix Fors: 1.9 Assignee: David Eric Pugh Reporter: Miguel Griffa Created: Mon, 3 May 2004 8:58 PM Updated: Tue, 19 Oct 2004 7:59 AM Description: It would be nice to be able to specify where are the sources of a dependency so when in eclipse debugging is enteres, another project or directory can be used for source for the current jar file. - 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: (MPECLIPSE-45) maven.eclipse.classpath.include.output
Message: The following issue has been closed. Resolver: David Eric Pugh Date: Tue, 19 Oct 2004 8:01 AM As far as I can tell, everything works fine for webapp development. - View the issue: http://jira.codehaus.org/browse/MPECLIPSE-45 Here is an overview of the issue: - Key: MPECLIPSE-45 Summary: maven.eclipse.classpath.include.output Type: Improvement Status: Closed Priority: Major Resolution: INCOMPLETE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-eclipse-plugin Fix Fors: 1.9 Assignee: David Eric Pugh Reporter: Jose Luiz Peleteiro Created: Thu, 23 Sep 2004 3:54 PM Updated: Tue, 19 Oct 2004 8:01 AM Description: Im going to extends this plugin to suport classpath includes with diferents output dir. Its ensencial to web projects. - 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 maven.final.name deprecated?
I'll start by rounding up thoughts, with specific answer below to the
last email.
Let me sum up where I think we're at here:
- artifact separation. We've talked about this on the maven and m2-dev
lists a lot in the last 6 months and thinking through all the issues
concluded that one project = one artifact makes sense, and that we just
need to make project creation simple. I don't think we should go over
that again.
- final name properties.
* Strongly disagree with the addition of maven.jar.final.name.
* Strongly agree that maven.final.name should represent the primary
artifact output for the project
* In the instance where a secondary artifact is made (ejb-client), I
have no problem with an additional final name property for that artifact
* for the already existing properties such as maven.war.final.name, I
think we should work to deprecate them while remaining backwards compatible
* For the specific instance of the war output - it should be moved to
include the version, but keeping the deprecated backwards compat
generation of pom.artifactId only named artifact. A FAQ should be created.
* None of this affects the filename in the repository
Are there any points on which we still disagree? Is there anyone else on
the list that disagrees?
Felipe Leme wrote:
On Tue, 2004-10-19 at 02:53, Brett Porter wrote:
Context docRoot=/home/bporter/cvs/.../target/foo.war
Convenient :)
As I said, you need to update the war (ok, you could usen maven console
for that, but it's not the same). What about:
Context docRoot=/home/bporter/cvs/.../${maven.war.src
(+ a maven.xml goal that copies all the dependencies on WEB-INF/lib and
maven.compile.target=${maven.war.src}/WEB-INF/class)
That would be maven war:inplace. But we digress :)
But it -should- be true. Now the plugin has to guess whether to use
maven.jar.final.name, maven.war.final.name, etc (sometimes - as for cactus -
this is contextual, sometimes not).
No, it will use maven.jar.final.name or maven.war.final.name, depending
on that it needs the artifact for.
That's contextual, but as I think you say next, you don't always know.
Besides, maven.final.name would
suffice, as the plugin wouldn't have a reliable way (except of
maven.multiproject.type, if I'm now wrong) to know the artifact's
extension.
This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
I would like to think we could reach consensus or compromise on design issues,
not need a vote. So let's keep talking it through.
Ok, agreed. By speaking of design issues, I'm fine about pushing the
'one artifact per project Maven way', but we should allow users to make
some exceptions for that rule. For instance, in many circumstances a
project might need to build a 'primary' artifact and many 'secondary'
ones, so Maven should support it (without requiring the multi-project
hell). One such situation is where a project's main artifact is a jar,
but it also provides a war to test it and maybe another with
documentation (that would be the case for all Jakarta Taglibs, for
example).
Another war with documentation? site:war? A documentation artifact is a
valid secondary artifact, whatever the format.
I don't believe this is the right way to go for the others - it is
unneeded complexity. examples subproject, test harness subproject that
depend on the original are better.
Yes, secondary artifacts are needed but they are just that - secondary.
BTW, I have discussed this case on Jira and in the users list, but we
haven't reached any consensus yet:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=875047
http://jira.codehaus.org/browse/MPWAR-30
Your argument against what I've said is it is overkill. Making a new pom
is a piece of cake, and it nicely separates things out and they both do
one thing, and do it the same as for anything else.
Under your scenario, what happens in a multiproject build when you hit
the taglib? Does it build a jar or a war? both? what tests does it run?
So, what do you think about this situation in particular, would the
change make sense or it would be against the design issues?
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question about Jelly
I'll answer the specific questions inline, but to give you some focus - you don't need to know how Maven uses Jelly to be able to use Jelly. You are probably only interested in how Jelly is built with Maven. A Leg wrote: Hi I am looking to work on patches for JellySwt to be able to use it. T do that I try to understand how Maven and Jelly interact. Maven use jelly to process some Xml tags In a fashion, yes and Jelly use Maven to be compiled. Yes, and I think that is really all you need to be concerned with for what you are trying to do (if I understand what you are trying to do :) . I looked in Maven code (very nice). And I arrived to JellyScriptHousing.java. I saw that in fact parsing is done by a SAXParser. This is for the initial caching as it is faster. Later on, runScript is called. My question is : where script variable is used ? plugin manager It is somewhere the key to understand how jelly scripts are used by Maven. Plus I plan next to use jellySwt tags from our java project and Maven code is a very good example. I think there are plenty of examples on the jelly sites, or just in the maven plugins to get you going here. Thanks Andre - 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: (MPECLIPSE-8) Support shared Eclipse launch configurations
The following comment has been added to this issue: Author: Charlie Dobbie Created: Tue, 19 Oct 2004 9:15 AM Body: Sorry, the project I really needed that function for ended some time ago. After 11 months without any activity I rather gave up on anything being done. Basically it's a migration issue - people already developing in Eclipse who need to do any resource-generation etc as part of a build will likely have launch configurations set up to run whatever is needed. Supporting these configurations would allow such people to migrate to Maven while still using parts of the toolchain they already trust. - View this comment: http://jira.codehaus.org/browse/MPECLIPSE-8?page=comments#action_25561 - View the issue: http://jira.codehaus.org/browse/MPECLIPSE-8 Here is an overview of the issue: - Key: MPECLIPSE-8 Summary: Support shared Eclipse launch configurations Type: New Feature Status: Closed Priority: Minor Resolution: INCOMPLETE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-eclipse-plugin Fix Fors: 1.9 Assignee: David Eric Pugh Reporter: Charlie Dobbie Created: Mon, 6 Oct 2003 7:34 AM Updated: Tue, 19 Oct 2004 9:15 AM Environment: All Description: I think it would be useful to be able to execute shared Eclipse launch configurations from Maven. An example launch configuration may look like this (Eclipse 2.1.1): ?xml version=1.0 encoding=UTF-8? launchConfiguration type=org.eclipse.jdt.launching.localJavaApplication stringAttribute key=org.eclipse.jdt.launching.MAIN_TYPE value=mypackage.MyClassName/ stringAttribute key=org.eclipse.jdt.launching.PROJECT_ATTR value=MyProjectName/ listAttribute key=org.eclipse.debug.ui.favoriteGroups listEntry value=org.eclipse.debug.ui.launchGroup.run/ /listAttribute stringAttribute key=org.eclipse.debug.ui.target_debug_perspective value=perspective_default/ stringAttribute key=org.eclipse.debug.ui.target_run_perspective value=perspective_default/ stringAttribute key=org.eclipse.debug.core.source_locator_id value=org.eclipse.jdt.debug.ui.javaSourceLocator/ /launchConfiguration I believe Eclipse locates shared launch configurations by searching the project's tree for *.launch files. (Local configurations reside in the .metadata tree, but are out of scope of this request.) I am not sure how best to expose this functionality to the Maven system. Perhaps a plugin-eclipse goal would read the class to run from a property, so it could be invoked by one of: j:set var=maven.eclipse.launchConfiguration value=com.company.Main/ j:attainGoal name=eclipse:execute-launch-configuration/ or: maven -Dmaven.eclipse.launchConfiguration=com.company.Main eclipse:execute-launch-configuration Or maybe the eclipse-plugin goal would process the launch files and add them to the project's maven.xml as java tasks, so the goal is a one-shot setup task, much like the other plugin-eclipse goals. I welcome any and all comments on this feature request - thoughts on implementation, usefulness or even whether or not it's a good idea! - 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]
[Fwd: Re: Is maven.final.name deprecated?]
Message meant for the list, Brett your reply-to points to you :-)
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---BeginMessage---
On Tue, 2004-10-19 at 08:32, Brett Porter wrote:
I'll start by rounding up thoughts, with specific answer below to the
last email.
Let me sum up where I think we're at here:
- artifact separation. We've talked about this on the maven and m2-dev
lists a lot in the last 6 months and thinking through all the issues
concluded that one project = one artifact makes sense, and that we just
need to make project creation simple. I don't think we should go over
that again.
- final name properties.
* Strongly disagree with the addition of maven.jar.final.name.
* Strongly agree that maven.final.name should represent the primary
artifact output for the project
* In the instance where a secondary artifact is made (ejb-client), I
have no problem with an additional final name property for that artifact
* for the already existing properties such as maven.war.final.name, I
think we should work to deprecate them while remaining backwards compatible
* For the specific instance of the war output - it should be moved to
include the version, but keeping the deprecated backwards compat
generation of pom.artifactId only named artifact. A FAQ should be created.
* None of this affects the filename in the repository
Are there any points on which we still disagree? Is there anyone else on
the list that disagrees?
That sounds good. As long as the artifact goes into the repository in
standard maven form it's all good. If the copy with a different name
locally provides convenience that's great.
Has the WAR always gone into the repository in the standard maven form?
If so then this certainly isn't a dire situation. The small nit being
the superfluous use of properties other than maven.final.name.
Felipe Leme wrote:
On Tue, 2004-10-19 at 02:53, Brett Porter wrote:
Context docRoot=/home/bporter/cvs/.../target/foo.war
Convenient :)
As I said, you need to update the war (ok, you could usen maven console
for that, but it's not the same). What about:
Context docRoot=/home/bporter/cvs/.../${maven.war.src
(+ a maven.xml goal that copies all the dependencies on WEB-INF/lib and
maven.compile.target=${maven.war.src}/WEB-INF/class)
That would be maven war:inplace. But we digress :)
But it -should- be true. Now the plugin has to guess whether to use
maven.jar.final.name, maven.war.final.name, etc (sometimes - as for cactus -
this is contextual, sometimes not).
No, it will use maven.jar.final.name or maven.war.final.name, depending
on that it needs the artifact for.
That's contextual, but as I think you say next, you don't always know.
Besides, maven.final.name would
suffice, as the plugin wouldn't have a reliable way (except of
maven.multiproject.type, if I'm now wrong) to know the artifact's
extension.
This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
I would like to think we could reach consensus or compromise on design issues,
not need a vote. So let's keep talking it through.
Ok, agreed. By speaking of design issues, I'm fine about pushing the
'one artifact per project Maven way', but we should allow users to make
some exceptions for that rule. For instance, in many circumstances a
project might need to build a 'primary' artifact and many 'secondary'
ones, so Maven should support it (without requiring the multi-project
hell). One such situation is where a project's main artifact is a jar,
but it also provides a war to test it and maybe another with
documentation (that would be the case for all Jakarta Taglibs, for
example).
Another war with documentation? site:war? A documentation artifact is a
valid secondary artifact, whatever the format.
I don't believe this is the right way to go for the others - it is
unneeded complexity. examples subproject, test harness subproject that
depend on the original are better.
Yes, secondary artifacts are needed but they are just that - secondary.
BTW, I have discussed this case on Jira and in the users list, but we
haven't reached any consensus yet:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=875047
http://jira.codehaus.org/browse/MPWAR-30
Your argument against what I've said is it is overkill. Making a new pom
is a piece of cake, and it nicely separates things out and they both do
one thing, and do it the same as for anything else.
Under your scenario, what happens in a multiproject build when you hit
the taglib? Does it build a jar or a war? both? what tests does it run?
So, what do
Re: [Fwd: Re: Is maven.final.name deprecated?]
It was sending both the list reply-to and one for me. I've changed a
config - let's see if this helps...
Jason van Zyl wrote:
Message meant for the list, Brett your reply-to points to you :-)
Subject:
Re: Is maven.final.name deprecated?
From:
Jason van Zyl [EMAIL PROTECTED]
Date:
19 Oct 2004 09:24:03 -0400
To:
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
On Tue, 2004-10-19 at 08:32, Brett Porter wrote:
I'll start by rounding up thoughts, with specific answer below to the
last email.
Let me sum up where I think we're at here:
- artifact separation. We've talked about this on the maven and m2-dev
lists a lot in the last 6 months and thinking through all the issues
concluded that one project = one artifact makes sense, and that we just
need to make project creation simple. I don't think we should go over
that again.
- final name properties.
* Strongly disagree with the addition of maven.jar.final.name.
* Strongly agree that maven.final.name should represent the primary
artifact output for the project
* In the instance where a secondary artifact is made (ejb-client), I
have no problem with an additional final name property for that artifact
* for the already existing properties such as maven.war.final.name, I
think we should work to deprecate them while remaining backwards compatible
* For the specific instance of the war output - it should be moved to
include the version, but keeping the deprecated backwards compat
generation of pom.artifactId only named artifact. A FAQ should be created.
* None of this affects the filename in the repository
Are there any points on which we still disagree? Is there anyone else on
the list that disagrees?
That sounds good. As long as the artifact goes into the repository in
standard maven form it's all good. If the copy with a different name
locally provides convenience that's great.
Has the WAR always gone into the repository in the standard maven form?
If so then this certainly isn't a dire situation. The small nit being
the superfluous use of properties other than maven.final.name.
Felipe Leme wrote:
On Tue, 2004-10-19 at 02:53, Brett Porter wrote:
Context docRoot=/home/bporter/cvs/.../target/foo.war
Convenient :)
As I said, you need to update the war (ok, you could usen maven console
for that, but it's not the same). What about:
Context docRoot=/home/bporter/cvs/.../${maven.war.src
(+ a maven.xml goal that copies all the dependencies on WEB-INF/lib and
maven.compile.target=${maven.war.src}/WEB-INF/class)
That would be maven war:inplace. But we digress :)
But it -should- be true. Now the plugin has to guess whether to use
maven.jar.final.name, maven.war.final.name, etc (sometimes - as for cactus -
this is contextual, sometimes not).
No, it will use maven.jar.final.name or maven.war.final.name, depending
on that it needs the artifact for.
That's contextual, but as I think you say next, you don't always know.
Besides, maven.final.name would
suffice, as the plugin wouldn't have a reliable way (except of
maven.multiproject.type, if I'm now wrong) to know the artifact's
extension.
This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
I would like to think we could reach consensus or compromise on design issues,
not need a vote. So let's keep talking it through.
Ok, agreed. By speaking of design issues, I'm fine about pushing the
'one artifact per project Maven way', but we should allow users to make
some exceptions for that rule. For instance, in many circumstances a
project might need to build a 'primary' artifact and many 'secondary'
ones, so Maven should support it (without requiring the multi-project
hell). One such situation is where a project's main artifact is a jar,
but it also provides a war to test it and maybe another with
documentation (that would be the case for all Jakarta Taglibs, for
example).
Another war with documentation? site:war? A documentation artifact is a
valid secondary artifact, whatever the format.
I don't believe this is the right way to go for the others - it is
unneeded complexity. examples subproject, test harness subproject that
depend on the original are better.
Yes, secondary artifacts are needed but they are just that - secondary.
BTW, I have discussed this case on Jira and in the users list, but we
haven't reached any consensus yet:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=875047
http://jira.codehaus.org/browse/MPWAR-30
Your argument against what I've said is it is overkill. Making a new pom
is a piece of cake, and it nicely separates things out and they both do
one thing, and do it the same as for anything else.
Under your scenario, what happens in a multiproject build when you hit
the taglib? Does it build a jar or a war? both?
cvs commit: maven-plugins/eclipse/xdocs changes.xml
epugh 2004/10/19 07:13:04
Modified:eclipse plugin.properties plugin.jelly
eclipse/src/plugin-resources/templates classpath.jelly
eclipse/src/plugin-test maven.xml
eclipse/xdocs changes.xml
Log:
Turn off the inclusion of pom build resources by default.
Revision ChangesPath
1.7 +1 -0 maven-plugins/eclipse/plugin.properties
Index: plugin.properties
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.properties,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- plugin.properties 15 Oct 2004 09:45:05 - 1.6
+++ plugin.properties 19 Oct 2004 14:13:04 - 1.7
@@ -26,3 +26,4 @@
maven.eclipse.goals = plugins
maven.gen.src=${maven.build.dir}/generated-sources
maven.eclipse.src.extension = zip
+maven.eclipse.addResources=false
1.30 +1 -1 maven-plugins/eclipse/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- plugin.jelly 15 Oct 2004 18:08:28 - 1.29
+++ plugin.jelly 19 Oct 2004 14:13:04 - 1.30
@@ -31,7 +31,7 @@
define:tag name=write-classpath-entry
maven:param-check value=${groupId} fail=true message='groupId' must be
specified/
maven:param-check value=${artifactId} fail=true message='artifactId'
must be specified/
- maven:param-check value=${version} fail=true message='version' must be
specified/
+ maven:param-check value=${version} fail=false message='version' should
be specified for artifact ${groupId}.${artifactId}/
!-- relativePath is optional, used for jar override --
j:set var=relativePathCheck value=${relativePath}X /
1.28 +24 -2
maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly
Index: classpath.jelly
===
RCS file:
/home/cvs/maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- classpath.jelly 19 Oct 2004 11:55:28 - 1.27
+++ classpath.jelly 19 Oct 2004 14:13:04 - 1.28
@@ -57,14 +57,25 @@
classpathentry kind=src path=${srcDir} excluding=${excluding} /
j:if test=${!pom.build.resources.isEmpty()}
+!-- Turn off for most users this buggy code--
+j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource items=${pom.build.resources}
+j:set var=includingAsString value= /
+j:forEach var=res items=${resource.includes}
+ j:set var=includingAsString value=${includingAsString}${res}| /
+/j:forEach
+ j:set var=excludingAsString value= /
+j:forEach var=res items=${resource.excludes}
+ j:set var=excludingAsString value=${excludingAsString}${res}| /
+/j:forEach
maven:makeRelativePath var=resourceDirectory basedir=${basedir}
path=${resource.directory} separator=//
!-- don't add duplicate directories --
j:if test=${!resourceDirectory.equals(srcDir)}
- classpathentry kind=src path=${resourceDirectory}
including=${include} excluding=${exclude} /
+ classpathentry kind=src path=${resourceDirectory}
including=${includingAsString} excluding=${excludingAsString} /
/j:if
/j:forEach
/j:if
+/j:if
/j:if
!-- Add the list of additional directories for the classpath from
${maven.eclipse.classpath.include}--
@@ -127,13 +138,24 @@
j:if test=${pom.build.unitTest != null}
j:if test=${!pom.build.unitTest.resources.isEmpty()}
+ !-- Turn off for most users this buggy code--
+ j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource items=${pom.build.unitTest.resources}
+ j:set var=includingAsString value= /
+ j:forEach var=res items=${resource.includes}
+j:set var=includingAsString value=${includingAsString}${res}| /
+ /j:forEach
+ j:set var=excludingAsString value= /
+ j:forEach var=res items=${resource.excludes}
+j:set var=excludingAsString value=${excludingAsString}${res}| /
+ /j:forEach
maven:makeRelativePath var=resourceDirectory basedir=${basedir}
path=${resource.directory} separator=//
!-- don't add duplicate directories --
j:if test=${!resourceDirectory.equals(testSrcDir)}
-classpathentry kind=src path=${resourceDirectory}
output=${testOutputDir} /
+classpathentry kind=src path=${resourceDirectory}
Re: cvs commit: maven-plugins/eclipse/xdocs changes.xml
Why you do this?
Emmanuel
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 4:13 PM
Subject: cvs commit: maven-plugins/eclipse/xdocs changes.xml
epugh 2004/10/19 07:13:04
Modified:eclipse plugin.properties plugin.jelly
eclipse/src/plugin-resources/templates classpath.jelly
eclipse/src/plugin-test maven.xml
eclipse/xdocs changes.xml
Log:
Turn off the inclusion of pom build resources by default.
Revision ChangesPath
1.7 +1 -0 maven-plugins/eclipse/plugin.properties
Index: plugin.properties
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.properties,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- plugin.properties 15 Oct 2004 09:45:05 - 1.6
+++ plugin.properties 19 Oct 2004 14:13:04 - 1.7
@@ -26,3 +26,4 @@
maven.eclipse.goals = plugins
maven.gen.src=${maven.build.dir}/generated-sources
maven.eclipse.src.extension = zip
+maven.eclipse.addResources=false
1.30 +1 -1 maven-plugins/eclipse/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- plugin.jelly 15 Oct 2004 18:08:28 - 1.29
+++ plugin.jelly 19 Oct 2004 14:13:04 - 1.30
@@ -31,7 +31,7 @@
define:tag name=write-classpath-entry
maven:param-check value=${groupId} fail=true
message='groupId' must be specified/
maven:param-check value=${artifactId} fail=true
message='artifactId' must be specified/
- maven:param-check value=${version} fail=true
message='version' must be specified/
+ maven:param-check value=${version} fail=false
message='version' should be specified for artifact
${groupId}.${artifactId}/
!-- relativePath is optional, used for jar override --
j:set var=relativePathCheck value=${relativePath}X /
1.28 +24 -2
maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly
Index: classpath.jelly
===
RCS file:
/home/cvs/maven-plugins/eclipse/src/plugin-resources/templates/classpath.jel
ly,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- classpath.jelly 19 Oct 2004 11:55:28 - 1.27
+++ classpath.jelly 19 Oct 2004 14:13:04 - 1.28
@@ -57,14 +57,25 @@
classpathentry kind=src path=${srcDir}
excluding=${excluding} /
j:if test=${!pom.build.resources.isEmpty()}
+!-- Turn off for most users this buggy code--
+j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource items=${pom.build.resources}
+j:set var=includingAsString value= /
+j:forEach var=res items=${resource.includes}
+ j:set var=includingAsString
value=${includingAsString}${res}| /
+/j:forEach
+ j:set var=excludingAsString value= /
+j:forEach var=res items=${resource.excludes}
+ j:set var=excludingAsString
value=${excludingAsString}${res}| /
+/j:forEach
maven:makeRelativePath var=resourceDirectory
basedir=${basedir} path=${resource.directory} separator=//
!-- don't add duplicate directories --
j:if test=${!resourceDirectory.equals(srcDir)}
- classpathentry kind=src path=${resourceDirectory}
including=${include} excluding=${exclude} /
+ classpathentry kind=src path=${resourceDirectory}
including=${includingAsString} excluding=${excludingAsString} /
/j:if
/j:forEach
/j:if
+/j:if
/j:if
!-- Add the list of additional directories for the classpath from
${maven.eclipse.classpath.include}--
@@ -127,13 +138,24 @@
j:if test=${pom.build.unitTest != null}
j:if test=${!pom.build.unitTest.resources.isEmpty()}
+ !-- Turn off for most users this buggy code--
+ j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource
items=${pom.build.unitTest.resources}
+ j:set var=includingAsString value= /
+ j:forEach var=res items=${resource.includes}
+j:set var=includingAsString
value=${includingAsString}${res}| /
+ /j:forEach
+ j:set var=excludingAsString value= /
+ j:forEach var=res items=${resource.excludes}
+j:set var=excludingAsString
value=${excludingAsString}${res}| /
+ /j:forEach
maven:makeRelativePath var=resourceDirectory
basedir=${basedir} path=${resource.directory} separator=//
!-- don't add duplicate directories --
j:if
Re: A question about Jelly
Hi Brett Thank's it help me a lot. I also want to embedded jelly in our project. And these explanations are very usefull for me. Maven use jelly in a nice way. But may be is it a way to embedded maven to benefits of pluggins facilities ? Best regards Andre Brett Porter wrote: I'll answer the specific questions inline, but to give you some focus - you don't need to know how Maven uses Jelly to be able to use Jelly. You are probably only interested in how Jelly is built with Maven. A Leg wrote: Hi I am looking to work on patches for JellySwt to be able to use it. T do that I try to understand how Maven and Jelly interact. Maven use jelly to process some Xml tags In a fashion, yes and Jelly use Maven to be compiled. Yes, and I think that is really all you need to be concerned with for what you are trying to do (if I understand what you are trying to do :) . I looked in Maven code (very nice). And I arrived to JellyScriptHousing.java. I saw that in fact parsing is done by a SAXParser. This is for the initial caching as it is faster. Later on, runScript is called. My question is : where script variable is used ? plugin manager It is somewhere the key to understand how jelly scripts are used by Maven. Plus I plan next to use jellySwt tags from our java project and Maven code is a very good example. I think there are plenty of examples on the jelly sites, or just in the maven plugins to get you going here. Thanks Andre - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: maven-plugins/eclipse/xdocs changes.xml
See my other email (which was queued up in my outbox, ARGH!)
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 3:19 PM
To: Maven Developers List
Subject: Re: cvs commit: maven-plugins/eclipse/xdocs changes.xml
Why you do this?
Emmanuel
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 4:13 PM
Subject: cvs commit: maven-plugins/eclipse/xdocs changes.xml
epugh 2004/10/19 07:13:04
Modified:eclipse plugin.properties plugin.jelly
eclipse/src/plugin-resources/templates classpath.jelly
eclipse/src/plugin-test maven.xml
eclipse/xdocs changes.xml
Log:
Turn off the inclusion of pom build resources by default.
Revision ChangesPath
1.7 +1 -0 maven-plugins/eclipse/plugin.properties
Index: plugin.properties
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.properties,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- plugin.properties 15 Oct 2004 09:45:05 - 1.6
+++ plugin.properties 19 Oct 2004 14:13:04 - 1.7
@@ -26,3 +26,4 @@
maven.eclipse.goals = plugins
maven.gen.src=${maven.build.dir}/generated-sources
maven.eclipse.src.extension = zip
+maven.eclipse.addResources=false
1.30 +1 -1 maven-plugins/eclipse/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- plugin.jelly 15 Oct 2004 18:08:28 - 1.29
+++ plugin.jelly 19 Oct 2004 14:13:04 - 1.30
@@ -31,7 +31,7 @@
define:tag name=write-classpath-entry
maven:param-check value=${groupId} fail=true
message='groupId' must be specified/
maven:param-check value=${artifactId} fail=true
message='artifactId' must be specified/
- maven:param-check value=${version} fail=true
message='version' must be specified/
+ maven:param-check value=${version} fail=false
message='version' should be specified for artifact
${groupId}.${artifactId}/
!-- relativePath is optional, used for jar override --
j:set var=relativePathCheck value=${relativePath}X /
1.28 +24 -2
maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly
Index: classpath.jelly
===
RCS file:
/home/cvs/maven-plugins/eclipse/src/plugin-resources/templates/cla
sspath.jel
ly,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- classpath.jelly 19 Oct 2004 11:55:28 - 1.27
+++ classpath.jelly 19 Oct 2004 14:13:04 - 1.28
@@ -57,14 +57,25 @@
classpathentry kind=src path=${srcDir}
excluding=${excluding} /
j:if test=${!pom.build.resources.isEmpty()}
+!-- Turn off for most users this buggy code--
+j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource items=${pom.build.resources}
+j:set var=includingAsString value= /
+j:forEach var=res items=${resource.includes}
+ j:set var=includingAsString
value=${includingAsString}${res}| /
+/j:forEach
+ j:set var=excludingAsString value= /
+j:forEach var=res items=${resource.excludes}
+ j:set var=excludingAsString
value=${excludingAsString}${res}| /
+/j:forEach
maven:makeRelativePath var=resourceDirectory
basedir=${basedir} path=${resource.directory} separator=//
!-- don't add duplicate directories --
j:if test=${!resourceDirectory.equals(srcDir)}
- classpathentry kind=src path=${resourceDirectory}
including=${include} excluding=${exclude} /
+ classpathentry kind=src path=${resourceDirectory}
including=${includingAsString} excluding=${excludingAsString} /
/j:if
/j:forEach
/j:if
+/j:if
/j:if
!-- Add the list of additional directories for the classpath from
${maven.eclipse.classpath.include}--
@@ -127,13 +138,24 @@
j:if test=${pom.build.unitTest != null}
j:if test=${!pom.build.unitTest.resources.isEmpty()}
+ !-- Turn off for most users this buggy code--
+ j:if test=${maven.eclipse.addResources == 'true'}
j:forEach var=resource
items=${pom.build.unitTest.resources}
+ j:set var=includingAsString value= /
+ j:forEach var=res items=${resource.includes}
+j:set var=includingAsString
value=${includingAsString}${res}| /
+ /j:forEach
+ j:set
[jira] Commented: (MAVEN-156) classpath or jelly:xml issue with XSLT transformations
The following comment has been added to this issue:
Author: Sergey Tereschenko
Created: Tue, 19 Oct 2004 11:08 AM
Body:
Solution from FAQ 4.9. How do I get the XSLT tasks to work? really don`t work under
JDK 5.0.
I hack this bug in maven xml with string:
${systemScope.setProperty('javax.xml.transform.TransformerFactory','com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl')}
when call my ant task.
But i dont want use xalan transformer. I need to use saxon.
Its very ugly bug.
-
View this comment:
http://jira.codehaus.org/browse/MAVEN-156?page=comments#action_25564
-
View the issue:
http://jira.codehaus.org/browse/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
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
jelly/ant integration
Versions:
1.0-beta-7
Assignee:
Reporter: tim stephenson
Created: Thu, 21 Nov 2002 5:28 PM
Updated: Tue, 19 Oct 2004 11:08 AM
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]
Upgrade Maven
Hi, is there any documentation explaining how to upgrade from 1.0beta7 to release 1.0? Alexis
cvs commit: maven-plugins/cruisecontrol/src/plugin-test/cvs-scm maven.xml project.properties
epugh 2004/10/19 09:02:22
Modified:cruisecontrol/src/plugin-test/svn-scm project.properties
maven.xml
cruisecontrol/src/plugin-test/cvs-scm maven.xml
project.properties
Log:
Fix tests that had broken in earlier commit of making CC more flexible.
Revision ChangesPath
1.3 +1 -1
maven-plugins/cruisecontrol/src/plugin-test/svn-scm/project.properties
Index: project.properties
===
RCS file:
/home/cvs/maven-plugins/cruisecontrol/src/plugin-test/svn-scm/project.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.properties23 Jul 2004 09:05:21 - 1.2
+++ project.properties19 Oct 2004 16:02:22 - 1.3
@@ -18,6 +18,6 @@
# MUST specify these, even though they are the defaults, so we can run inside
reactor where they were already set
maven.cruisecontrol.config=${maven.build.dest}
maven.cruisecontrol.home=${maven.build.dest}
-maven.cruisecontrol.buildresults.site=http://sometest.server.com:8080
+maven.cruisecontrol.buildresults.url=http://sometest.server.com:8080
1.3 +3 -3 maven-plugins/cruisecontrol/src/plugin-test/svn-scm/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/maven-plugins/cruisecontrol/src/plugin-test/svn-scm/maven.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- maven.xml 23 Jul 2004 09:05:21 - 1.2
+++ maven.xml 19 Oct 2004 16:02:22 - 1.3
@@ -43,8 +43,8 @@
goal name=test-cruisecontrol-validate
attainGoal name=cruisecontrol:validate/
- j:set var=method value=${context.getVariable('maven.scm.method')}/
- j:if test=${empty(method)}
+ maven:get var=method plugin='maven-scm-plugin' property='maven.scm.method'
/
+ j:if test=${empty(method)}
ant:failmethod shouldn't be null/ant:fail
/j:if
/goal
@@ -62,6 +62,6 @@
goal name=test-report-link-to-cruisecontrol
attainGoal name=maven-cruisecontrol-plugin:report/
j:set var=cruiseControlURL
value=${context.getVariable('maven.cruisecontrol.buildresults.url')}/
- assert:assertEquals
expected=http://sometest.server.com:8080/buildresults/test-maven-cruisecontrol-svn-plugin;
value=${cruiseControlURL.trim()}/
+ assert:assertEquals expected=http://sometest.server.com:8080;
value=${cruiseControlURL.trim()}/
/goal
/project
1.7 +1 -1 maven-plugins/cruisecontrol/src/plugin-test/cvs-scm/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/maven-plugins/cruisecontrol/src/plugin-test/cvs-scm/maven.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- maven.xml 9 Aug 2004 15:47:57 - 1.6
+++ maven.xml 19 Oct 2004 16:02:22 - 1.7
@@ -43,7 +43,7 @@
goal name=test-cruisecontrol-validate
attainGoal name=cruisecontrol:validate/
- j:set var=method value=${context.getVariable('maven.scm.method')}/
+ maven:get var=method plugin='maven-scm-plugin' property='maven.scm.method'
/
j:if test=${empty(method)}
ant:failmethod shouldn't be null/ant:fail
/j:if
1.3 +1 -0
maven-plugins/cruisecontrol/src/plugin-test/cvs-scm/project.properties
Index: project.properties
===
RCS file:
/home/cvs/maven-plugins/cruisecontrol/src/plugin-test/cvs-scm/project.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.properties30 Jul 2004 08:21:09 - 1.2
+++ project.properties19 Oct 2004 16:02:22 - 1.3
@@ -19,5 +19,6 @@
maven.cruisecontrol.config=${maven.build.dir}/cruisecontrol.xml
maven.cruisecontrol.home=${maven.build.dest}
maven.cruisecontrol.trigger.projects=svn-scm
+maven.cruisecontrol.logs.merge=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPCRUISECONTROL-13) plugin:test complains about scm method
Message: The following issue has been closed. Resolver: David Eric Pugh Date: Tue, 19 Oct 2004 12:04 PM I changed the patch to maven:get and also fixed some other unit test errors that had been introduced. Can you verify everything builds for you as well? - View the issue: http://jira.codehaus.org/browse/MPCRUISECONTROL-13 Here is an overview of the issue: - Key: MPCRUISECONTROL-13 Summary: plugin:test complains about scm method Type: Bug Status: Closed Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-cruisecontrol-plugin Fix Fors: 1.6 Assignee: David Eric Pugh Reporter: Marcin Gurbisz Created: Fri, 15 Oct 2004 9:38 AM Updated: Tue, 19 Oct 2004 12:04 PM Description: maven.scm.method cannot be retrieved. I provide a patch. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/cruisecontrol plugin.properties
epugh 2004/10/19 09:10:44
Modified:cruisecontrol/xdocs changes.xml
cruisecontrol/src/plugin-resources cruisecontrol.jsl
cruisecontrol plugin.properties
Log:
MPCRUISECONTROL-14 More flexible configuration
Revision ChangesPath
1.18 +1 -0 maven-plugins/cruisecontrol/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven-plugins/cruisecontrol/xdocs/changes.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- changes.xml 28 Aug 2004 21:22:15 - 1.17
+++ changes.xml 19 Oct 2004 16:10:44 - 1.18
@@ -25,6 +25,7 @@
/properties
body
release version=1.6 date=in cvs
+ action dev=epugh type=add issue=MPCRUISECONTROL-14 due-to=Marcin
GurbiszAdd more configuration, especially better handling of emails./action
action dev=evenisse type=add issue=MPCRUISECONTROL-12
due-to=Alexandre VivienAdd new properties to the maven cruisecontrol plugin. Ftp
publisher, Scp publisher./action
/release
release version=1.5 date=2004-08-14
1.14 +29 -6
maven-plugins/cruisecontrol/src/plugin-resources/cruisecontrol.jsl
Index: cruisecontrol.jsl
===
RCS file:
/home/cvs/maven-plugins/cruisecontrol/src/plugin-resources/cruisecontrol.jsl,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- cruisecontrol.jsl 28 Aug 2004 21:22:15 - 1.13
+++ cruisecontrol.jsl 19 Oct 2004 16:10:44 - 1.14
@@ -67,7 +67,7 @@
j:when test=${type == 'time'}
schedule
maven
-mavenscript=${maven.home}/bin/maven
+mavenscript=${maven.cruisecontrol.mavenhome}/bin/maven
time=${maven.cruisecontrol.schedule.time}
goal=${maven.cruisecontrol.goals}
projectfile=${maven.cruisecontrol.checkout.dir}/${module}/project.xml/
@@ -76,7 +76,7 @@
j:otherwise
schedule interval=${maven.cruisecontrol.schedule.interval}
maven
-mavenscript=${maven.home}/bin/maven
+mavenscript=${maven.cruisecontrol.mavenhome}/bin/maven
goal=${maven.cruisecontrol.goals}
projectfile=${maven.cruisecontrol.checkout.dir}/${module}/project.xml/
/schedule
@@ -93,6 +93,12 @@
/log
publishers
currentbuildstatuspublisher
file=${maven.cruisecontrol.logs.dir}/${pom.artifactId}/${maven.cruisecontrol.currentbuildstatus.filename}/
+ j:set var=publishartifacts
value=${maven.cruisecontrol.artifactspublisher}/
+ j:if test=${publishartifacts == 'true'}
+ artifactspublisher
+dir=${maven.cruisecontrol.artifacts.dir}
+dest=${maven.cruisecontrol.artifacts.dest}/${pom.artifactId}/
+ /j:if
j:set var=ftpstatus
value=${maven.cruisecontrol.currentbuildstatusftppublisher}/
j:if test=${ftpstatus == 'true'}
currentbuildstatusftppublisher
@@ -125,9 +131,11 @@
defaultsuffix=${maven.cruisecontrol.mail.defaultsuffix}
mailhost=${maven.cruisecontrol.mail.host}
returnaddress=${pom.build.nagEmailAddress}
+ buildresultsurl=${maven.cruisecontrol.mail.buildresultsurl}
+ spamwhilebroken=${maven.cruisecontrol.mail.spamwhilebroken}
logdir=${maven.cruisecontrol.logs.dir}/${pom.artifactId}
- css=${maven.cruisecontrol.home}/reporting/jsp/css/cruisecontrol.css
- xsldir=${maven.cruisecontrol.home}/reporting/jsp/xsl
+ css=${maven.cruisecontrol.mail.css}
+ xsldir=${maven.cruisecontrol.mail.xlsdir}
j:set var=usemap value=${maven.cruisecontrol.mail.usemap}/
j:if test=${usemap == 'true'}
!-- need to map ids to emails here --
@@ -138,8 +146,18 @@
/j:forEach
/j:if
/j:if
-failure address=${pom.build.nagEmailAddress} /
-success address=${pom.build.nagEmailAddress} /
+j:set var=mailmaps value=${maven.cruisecontrol.mail.maps}/
+j:if test=${!empty(mailmaps)}
+
+ u:tokenize var=maps delim=,${mailmaps}/u:tokenize
+ j:forEach var=map items=${maps}
+j:set var=mapVarName
value=maven.cruisecontrol.mail.map.${map}/
+map alias=${map} address=${context.getVariable(mapVarName)}/
+ /j:forEach
+/j:if
+
+failure address=${maven.cruisecontrol.mail.failureaddress} /
+success address=${maven.cruisecontrol.mail.successaddress} /
/htmlemail
[jira] Closed: (MPCRUISECONTROL-14) More flexible configuration
Message: The following issue has been closed. Resolver: David Eric Pugh Date: Tue, 19 Oct 2004 12:12 PM Take a looksee. At somepoint this cruisecontrol.jsl file is going to be just TOO configurable. May want to add some sort of simple-cruisecontrol.jsl with minimal settings.. - View the issue: http://jira.codehaus.org/browse/MPCRUISECONTROL-14 Here is an overview of the issue: - Key: MPCRUISECONTROL-14 Summary: More flexible configuration Type: Improvement Status: Closed Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-cruisecontrol-plugin Fix Fors: 1.6 Assignee: David Eric Pugh Reporter: Marcin Gurbisz Created: Fri, 15 Oct 2004 10:11 AM Updated: Tue, 19 Oct 2004 12:12 PM Description: I use plugin to generate config file for integration machine. I don't want to manually change generated file, thus I need more flexible configuration for plugin. I've made following changes to the plugin: - added possibility to configure location of maven - added properties buildresultsurl, spamwhilebroken - added possibility to configure css and xsldir for htmlemail - added possibility to configure failure and success address - added generation of maps based on properties like this: maven.cruisecontrol.mail.maps=developers maven.cruisecontrol.mail.map.developers=dev1, dev2 - added arifact publisher I think this changes can be helpfull for others. I provide patch containing this changes. - 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: (MPPMD-14) PMD should run on unit tests
The following issue has been updated:
Updater: Sebastian Esponda (mailto:[EMAIL PROTECTED])
Date: Tue, 19 Oct 2004 12:58 PM
Comment:
We needed PMD to analyze our tests sources, so we did some changes:
Plugin.jelly:
If ${pom.build.unitTestSourceDirectory} points to a valid directory, a second fileset
is included in pmd ant task.
Plugin.jsl:
The original file always used a href=xref/... etc when linking line numbers to
sources. This failed for tests sources.
Now, if the file path starts with ${pom.build.unitTestSourceDirectory} the link will
be a href=xref-test/... etc
In the zip file Im including:
New plugin.jelly
New plugin.jsl
Patch for plugin.jelly 1.15 (Previously posted, included here for convenience)
Patch for plugin.jsl 1.4
... just in case you find it useful (hope so)
Ive just learned jsl and jelly... so this is probably with bugs... but its working
ok in our environment ;)
Regards,
Changes:
Attachment changed to pmd-tests.zip
-
For a full history of the issue, see:
http://jira.codehaus.org/browse/MPPMD-14?page=history
-
View the issue:
http://jira.codehaus.org/browse/MPPMD-14
Here is an overview of the issue:
-
Key: MPPMD-14
Summary: PMD should run on unit tests
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-pmd-plugin
Assignee:
Reporter: Kenneth Leider
Created: Thu, 30 Sep 2004 1:36 PM
Updated: Tue, 19 Oct 2004 12:58 PM
Description:
Right now the only files under pom.build.sourceDirectory are checked. It would be
nice is source under pom.build.unitTestSourceDirectory could be checked as well.
-
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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
The following comment has been added to this issue: Author: Pål Brattberg Created: Tue, 19 Oct 2004 2:17 PM Body: I may have the time to look at this at a later time, but for now, here is a work around which may or may not help you out. http://www.palbrattberg.com/index.php?p=46 - View this comment: http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=comments#action_25573 - View the issue: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 Here is an overview of the issue: - Key: MPCHECKSTYLE-20 Summary: Unable to get class information for custom exceptions Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-checkstyle-plugin Versions: 2.3 Assignee: Reporter: Ryan Sonnek Created: Sat, 27 Mar 2004 11:48 AM Updated: Tue, 19 Oct 2004 2:17 PM Environment: maven-1.0-rc2 Description: checkstyle reports an error Unable to get class information for custom exceptions within the same project. it is able to load exceptions that are listed as dependencies for the project, but not for other exceptions. one workaround is to only use throws Exception in the signiture, but that's really a hack. - 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: (MPCLOVER-26) Update to clover-ant-1.3_02.jar
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/browse/MPCLOVER-26
Here is an overview of the issue:
-
Key: MPCLOVER-26
Summary: Update to clover-ant-1.3_02.jar
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-clover-plugin
Versions:
1.6
Assignee:
Reporter: Gary Gregory
Created: Tue, 19 Oct 2004 3:17 PM
Updated: Tue, 19 Oct 2004 3:17 PM
Environment: java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.5.0
file.encoding=Cp1252
java.ext.dirs=C:\java\sun\1.5.0\jre\lib\ext
java.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0\lib\endorsed\xerces-2.4.0.jar;C:\Program Files\Apache Software Foundation\Maven
1.0\li
b\endorsed\xml-apis-1.0.b2.jar;C:\java\sun\1.5.0\jre\lib\rt.jar;C:\java\sun\1.5.0\jre\lib\i18n.jar;C:\java\sun\1.5.0\jre\lib\sunrsasign.jar;C:\java\sun\1.5.0\jr
e\lib\jsse.jar;C:\java\sun\1.5.0\jre\lib\jce.jar;C:\java\sun\1.5.0\jre\lib\charsets.jar;C:\java\sun\1.5.0\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.0
maven-announcement-plugin-1.2
maven-ant-plugin-1.8
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.1.1
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5
maven-checkstyle-plugin-2.4.1
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.4
maven-dashboard-plugin-1.3
maven-developer-activity-plugin-1.5
maven-dist-plugin-1.6
maven-docbook-plugin-1.2
maven-ear-plugin-1.5
maven-eclipse-plugin-1.7
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.1
maven-html2xdoc-plugin-1.3
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5
maven-jalopy-plugin-1.3
maven-jar-plugin-1.6
maven-java-plugin-1.4
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.6.1
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.7
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.1
maven-jnlp-plugin-1.4
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.1
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.2
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.1
maven-plugin-plugin-1.5.1
maven-pmd-plugin-1.5
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4
maven-repository-plugin-1.2
maven-scm-plugin-1.4
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.1
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Home Build properties: {jaxp.xslt.jar=C:/java/apache/xalan-2_5_D1//bin/xalan.jar,
servlet.jar=C:/java/sun/jwsdp-1.1/common/lib/servlet.jar, jaxp.jaxp.jar=C:/jav
a/apache/xalan-2_5_D1//bin/xml-apis.jar, junit.jar=C:/java/junit3.8.1/junit.jar}
Description:
I am getting an invalid license error after upgrading from maven-clover-plugin 1.5 to
1.6. The clover folks have address this or a similar bug in clover-ant-1.3_02.jar; see
http://www.cenqua.com/forums/thread.jspa?threadID=775tstart=90
[echo] Generating the Clover...
maven-clover-plugin:report:
clover:test:
clover:init:
[mkdir] Created dir:
C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\classes
[mkdir] Created dir:
C:\cvs-store\apache.org\jakarta\commons\codec\target\clover\database
[mkdir] Created dir:
C:\cvs-store\apache.org\jakarta\commons\codec\target\docs\clover
clover:on:
[echo] Setting Clover compiler
[echo] Now using primary build.compiler
[jira] Commented: (MPCLOVER-26) Update to clover-ant-1.3_02.jar
The following comment has been added to this issue:
Author: Gary Gregory
Created: Tue, 19 Oct 2004 3:23 PM
Body:
Well, it looks like there is a version 1.3.1 now; see
http://www.cenqua.com/forums/thread.jspa?threadID=985tstart=0.
-
View this comment:
http://jira.codehaus.org/browse/MPCLOVER-26?page=comments#action_25575
-
View the issue:
http://jira.codehaus.org/browse/MPCLOVER-26
Here is an overview of the issue:
-
Key: MPCLOVER-26
Summary: Update to clover-ant-1.3_02.jar
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-clover-plugin
Versions:
1.6
Assignee:
Reporter: Gary Gregory
Created: Tue, 19 Oct 2004 3:17 PM
Updated: Tue, 19 Oct 2004 3:23 PM
Environment: java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.5.0
file.encoding=Cp1252
java.ext.dirs=C:\java\sun\1.5.0\jre\lib\ext
java.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0\lib\endorsed\xerces-2.4.0.jar;C:\Program Files\Apache Software Foundation\Maven
1.0\li
b\endorsed\xml-apis-1.0.b2.jar;C:\java\sun\1.5.0\jre\lib\rt.jar;C:\java\sun\1.5.0\jre\lib\i18n.jar;C:\java\sun\1.5.0\jre\lib\sunrsasign.jar;C:\java\sun\1.5.0\jr
e\lib\jsse.jar;C:\java\sun\1.5.0\jre\lib\jce.jar;C:\java\sun\1.5.0\jre\lib\charsets.jar;C:\java\sun\1.5.0\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.0
maven-announcement-plugin-1.2
maven-ant-plugin-1.8
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.1.1
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5
maven-checkstyle-plugin-2.4.1
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.4
maven-dashboard-plugin-1.3
maven-developer-activity-plugin-1.5
maven-dist-plugin-1.6
maven-docbook-plugin-1.2
maven-ear-plugin-1.5
maven-eclipse-plugin-1.7
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.1
maven-html2xdoc-plugin-1.3
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5
maven-jalopy-plugin-1.3
maven-jar-plugin-1.6
maven-java-plugin-1.4
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.6.1
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.7
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.1
maven-jnlp-plugin-1.4
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.1
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.2
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.1
maven-plugin-plugin-1.5.1
maven-pmd-plugin-1.5
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4
maven-repository-plugin-1.2
maven-scm-plugin-1.4
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.1
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Home Build properties: {jaxp.xslt.jar=C:/java/apache/xalan-2_5_D1//bin/xalan.jar,
servlet.jar=C:/java/sun/jwsdp-1.1/common/lib/servlet.jar, jaxp.jaxp.jar=C:/jav
a/apache/xalan-2_5_D1//bin/xml-apis.jar, junit.jar=C:/java/junit3.8.1/junit.jar}
Description:
I am getting an invalid license error after upgrading from maven-clover-plugin 1.5 to
1.6. The clover folks have address this or a similar bug in clover-ant-1.3_02.jar; see
http://www.cenqua.com/forums/thread.jspa?threadID=775tstart=90
[echo] Generating the Clover...
maven-clover-plugin:report:
clover:test:
clover:init:
[mkdir]
[eclipse] Need to rethink using pom.build.resources in .classpath for Eclipse Plugin
Hi all, A while ago some patches where made that allowed the resources/ elements to be added to the Eclipse .classpath. This looked good, and I committed it. However, as I have gone on with more testing, I think this needs to be reworked. What happens is right now the resources for the regular java files and in the unitTest section are duplicated... This can lead to a situation where you import the same path twice. For example, in the below (trimmed) section, I want to copy some resources always, and a log4j.properties when running unit tests: build unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includetest.avalonconf.xml/include /includes filteringfalse/filtering /resource resource includes includelog4j.properties/include /includes filteringfalse/filtering /resource /resources /unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includehibernate.hbm.xml/include includeehcache.xml/include /includes filteringfalse/filtering /resource /resources /build However, because they both go from src/conf to /, this causes two records to be created in Eclipse. I think, what needs to done is that a map of all the possible sources needs to be made, and then we aggreagate together all the changes. However, this is a pretty big change, and I've not got the time for it right now, but I'll be happy to help. Also, we where not properly dealing with includes and excludes either.. I added that. Because this change can break things, I've added an extra check. If maven.eclipse.addResources=true in your project.properties, then the existing logic will occur. By default this is turned off so we don't start breaking everybodies builds. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [eclipse] Need to rethink using pom.build.resources in .classpath for Eclipse Plugin
There is no way the test resources should be in src/conf. It should be discouraged (although not broken :) That said, I think the current fix is correct. - Brett Eric Pugh wrote: Hi all, A while ago some patches where made that allowed the resources/ elements to be added to the Eclipse .classpath. This looked good, and I committed it. However, as I have gone on with more testing, I think this needs to be reworked. What happens is right now the resources for the regular java files and in the unitTest section are duplicated... This can lead to a situation where you import the same path twice. For example, in the below (trimmed) section, I want to copy some resources always, and a log4j.properties when running unit tests: build unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includetest.avalonconf.xml/include /includes filteringfalse/filtering /resource resource includes includelog4j.properties/include /includes filteringfalse/filtering /resource /resources /unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includehibernate.hbm.xml/include includeehcache.xml/include /includes filteringfalse/filtering /resource /resources /build However, because they both go from src/conf to /, this causes two records to be created in Eclipse. I think, what needs to done is that a map of all the possible sources needs to be made, and then we aggreagate together all the changes. However, this is a pretty big change, and I've not got the time for it right now, but I'll be happy to help. Also, we where not properly dealing with includes and excludes either.. I added that. Because this change can break things, I've added an extra check. If maven.eclipse.addResources=true in your project.properties, then the existing logic will occur. By default this is turned off so we don't start breaking everybodies builds. Eric Pugh - 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: [eclipse] Need to rethink using pom.build.resources in .classpath for Eclipse Plugin
I also think that having a single directory for both standard and test resources is pretty unusual and should be discouraged... a common project layout is usually something like: src/ main resources test test-resources said that, I would like to see the include resource property ON by default also for the following considerations: - loosing source resources will break probably more builds than having resource folders added twice for projects with such unusual directory layout: if resource directories are missed users will not be aware but they will probably not be able to run unit tests at all in eclipse. - also with your suggested fix _there is no way_ in eclipse to handle a similar situation: you can avoid adding a resource directory twice, but you will never be able to have files in the same resource directory that go into two different target directory. For example you can't have all your *.properties files in src/conf to go to target/classes and all the test*.properties files go to target/test-classes. Eclipse simply doesn't allow the same source directory to be added twice, regardless of filters and target directoryies. I would prefer having the properties enabled by default, documenting this eclipse limit in plugin site and leaving to users the choice to setting the project property off or fixing their directory layout... fabrizio On Wed, 20 Oct 2004 06:48:20 +1000, Brett Porter [EMAIL PROTECTED] wrote: There is no way the test resources should be in src/conf. It should be discouraged (although not broken :) That said, I think the current fix is correct. - Brett Eric Pugh wrote: Hi all, A while ago some patches where made that allowed the resources/ elements to be added to the Eclipse .classpath. This looked good, and I committed it. However, as I have gone on with more testing, I think this needs to be reworked. What happens is right now the resources for the regular java files and in the unitTest section are duplicated... This can lead to a situation where you import the same path twice. For example, in the below (trimmed) section, I want to copy some resources always, and a log4j.properties when running unit tests: build unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includetest.avalonconf.xml/include /includes filteringfalse/filtering /resource resource includes includelog4j.properties/include /includes filteringfalse/filtering /resource /resources /unitTest resources resource directorysrc/conf/directory targetPath//targetPath includes includehibernate.hbm.xml/include includeehcache.xml/include /includes filteringfalse/filtering /resource /resources /build However, because they both go from src/conf to /, this causes two records to be created in Eclipse. I think, what needs to done is that a map of all the possible sources needs to be made, and then we aggreagate together all the changes. However, this is a pretty big change, and I've not got the time for it right now, but I'll be happy to help. Also, we where not properly dealing with includes and excludes either.. I added that. Because this change can break things, I've added an extra check. If maven.eclipse.addResources=true in your project.properties, then the existing logic will occur. By default this is turned off so we don't start breaking everybodies builds. Eric Pugh - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPPDF-20) add author names to generated pdf
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPPDF-20 Here is an overview of the issue: - Key: MPPDF-20 Summary: add author names to generated pdf Type: New Feature Status: Open Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-pdf-plugin Versions: 2.2 Assignee: Arnaud HERITIER Reporter: David Weinkauf Created: Tue, 19 Oct 2004 5:24 PM Updated: Tue, 19 Oct 2004 5:24 PM Environment: linux Description: It would be great if, when creating a PDF, the authors, developers, or contributors to the site / documentation were listed on the cover page of the PDF. Thanks! - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
can't create an issue on jira
Dear maveners I'm logged in jira and the issue creation option is disabled (in the project maven and all the plugin I tried), is it normal ? PS : I have a patch for the issue :-) Regards Julien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPEAR-22) The ear plugin needs to have a settable manifest Class-Path like the WAR plugin
The following issue has been updated: Updater: Wiley Fuller (mailto:[EMAIL PROTECTED]) Date: Tue, 19 Oct 2004 8:11 PM Comment: This patch enables the use of the 'ear.manifest.classpath' property for dependencies. The implementation is virtually identical to the implementation in the WAR module. It's worth noting that neither of these implementations deal with the case where a JAR file is placed somewhere other than the root of the archive, for instance by using 'ear.target.path' or 'war.target.path' Changes: Attachment changed to patch.txt - For a full history of the issue, see: http://jira.codehaus.org/browse/MPEAR-22?page=history - View the issue: http://jira.codehaus.org/browse/MPEAR-22 Here is an overview of the issue: - Key: MPEAR-22 Summary: The ear plugin needs to have a settable manifest Class-Path like the WAR plugin Type: New Feature Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ear-plugin Assignee: Reporter: Wiley Fuller Created: Wed, 13 Oct 2004 7:27 PM Updated: Tue, 19 Oct 2004 8:11 PM Description: There is currently no way to add bundled dependencies to the Class-Path entry in the EAR manifest file, like in the WAR plugin. A dependency entry in the project file should look like the following... dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.8/version properties ear.bundletrue/ear.bundle ear.manifest.classpathtrue/ear.manifest.classpath /properties /dependency - 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: [jira] Updated: (MPARTIFACT-18) Need a property to specify what value should be used for a snapshot deploy.
Hi Brett, You changed the 'Fix Version' for this bug, but it's being pretty much dormant since I proposed the fix: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=877620 So, what's up? Should we continue the thread above and then finalize the bug (fixing it or marking it as invalid)? -- Felipe On Fri, 2004-10-15 at 21:34, [EMAIL PROTECTED] wrote: The following issue has been updated: Updater: Brett Porter (mailto:[EMAIL PROTECTED]) Date: Fri, 15 Oct 2004 8:33 PM Changes: Fix Version changed to 1.5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (MPARTIFACT-18) Need a property to specify what value should be used for a snapshot deploy.
Felipe, Just changed the fix for because it needs to be addressed in the next release - whether it takes on wagon or not. The resolution may well be won't fix. To be honest, I don't have the bandwidth to discuss these things at the moment. I'm flat out. - Brett Quoting Felipe Leme [EMAIL PROTECTED]: Hi Brett, You changed the 'Fix Version' for this bug, but it's being pretty much dormant since I proposed the fix: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=877620 So, what's up? Should we continue the thread above and then finalize the bug (fixing it or marking it as invalid)? -- Felipe On Fri, 2004-10-15 at 21:34, [EMAIL PROTECTED] wrote: The following issue has been updated: Updater: Brett Porter (mailto:[EMAIL PROTECTED]) Date: Fri, 15 Oct 2004 8:33 PM Changes: Fix Version changed to 1.5 - 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-plugins/ear/src/plugin-test/test01 - New directory
felipeal2004/10/19 19:26:38 maven-plugins/ear/src/plugin-test/test01 - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ear/src/plugin-test/test01/src - New directory
felipeal2004/10/19 19:27:20 maven-plugins/ear/src/plugin-test/test01/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ear/src/plugin-test/test01/src/application - New directory
felipeal2004/10/19 19:27:20 maven-plugins/ear/src/plugin-test/test01/src/application - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ear/src/plugin-test/test01/src/application/META-INF - New directory
felipeal2004/10/19 19:27:20 maven-plugins/ear/src/plugin-test/test01/src/application/META-INF - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ear/src/plugin-test/test01/src/resources - New directory
felipeal2004/10/19 19:27:20 maven-plugins/ear/src/plugin-test/test01/src/resources - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ear/src/plugin-test/test01/src/resources resource.txt
felipeal2004/10/19 19:29:56
Modified:ear/src/plugin-test maven.xml project.xml
Added: ear/src/plugin-test/test01 LICENSE.txt maven.xml
project.properties project.xml
ear/src/plugin-test/test01/src/application/META-INF
.cvsignore MANIFEST.MF
ear/src/plugin-test/test01/src/resources resource.txt
Removed: ear/src/plugin-test LICENSE.txt
ear/src/plugin-test/src/application/META-INF .cvsignore
MANIFEST.MF
ear/src/plugin-test/src/resources resource.txt
Log:
change test layout to allow multiple test-cases (one per sub-directory)
Revision ChangesPath
1.8 +3 -50 maven-plugins/ear/src/plugin-test/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/maven-plugins/ear/src/plugin-test/maven.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- maven.xml 15 Mar 2004 11:51:29 - 1.7
+++ maven.xml 20 Oct 2004 02:29:56 - 1.8
@@ -15,55 +15,8 @@
* limitations under the License.
*/
--
-project xmlns:j=jelly:core
- xmlns:u=jelly:util
- xmlns:x=jelly:xml
- xmlns:assert=assert
- xmlns:j2ee=j2ee
-
- goal name=testPlugin prereqs=test-ear
-attainGoal name=clean/
- /goal
-
- goal name=test-ear
-attainGoal name=ear/
-
-!-- tests that the ear is generated --
-assert:assertFileExists
file=${maven.build.dir}/test-maven-ear-plugin-1.0-SNAPSHOT.ear/
-
-!-- unzip the ear and look for the jars --
-j:set var=earFile
- value=${maven.build.dir}/test-maven-ear-plugin-1.0-SNAPSHOT.ear/
-j:set var=unzipDir value= ${maven.build.dir}/eartest/
-mkdir dir=${unzipDir}/
-unzip src=${earFile} dest=${unzipDir}/
-
-!-- check for commons-logging --
-assert:assertFileExists file=${unzipDir}/commons-logging-1.0.3.jar
- msg=commons logging was not bundled/
-
-!-- check for commons-collections --
-assert:assertFileExists file=${unzipDir}/commons-collections-2.1.jar
- msg=commons collections was not bundled/
-
-!-- check application.xml got a java module in it --
-u:file var=appXml name=${unzipDir}/META-INF/application.xml/
-j:new var=saxReader className=org.dom4j.io.SAXReader /
-j2ee:resolver var=resolver /
-${saxReader.setEntityResolver(resolver)}
-x:parse var=applicationDoc xml=${appXml.toURL()} SAXReader=${saxReader}
/
-x:set var=firstJavaModule
select=string($applicationDoc/application/module/java)/
-
-assert:assertEquals
- expected=commons-collections-2.1.jar
- value=${firstJavaModule}
- msg=commons collections was not the first java module/
-
-!-- check for resources --
-assert:assertFileExists file=${unzipDir}/resource.txt/
-
-!-- check for the LICENSE --
-assert:assertFileExists file=${unzipDir}/META-INF/LICENSE.txt/
-
+project xmlns:util=jelly:util xmlns:maven=jelly:maven xmlns:j=jelly:core
xmlns:assert=assert xmlns:ant=jelly:ant
+ goal name=testPlugin
+maven:reactor basedir=${basedir} includes=test*/project.xml
goals=testPlugin banner=Test ignoreFailures=false/
/goal
/project
1.11 +15 -72maven-plugins/ear/src/plugin-test/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven-plugins/ear/src/plugin-test/project.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- project.xml 15 Oct 2004 05:01:54 - 1.10
+++ project.xml 20 Oct 2004 02:29:56 - 1.11
@@ -21,79 +21,22 @@
project
pomVersion3/pomVersion
nameTest project for Maven Ear Plugin/name
- idtest-maven-ear-plugin/id
- currentVersion1.0-SNAPSHOT/currentVersion
+ groupIdmaven/groupId
+ currentVersion1.0/currentVersion
organization
-nameNettec/name
-urlhttp://www.nettec.net/url
+nameApache Software Foundation/name
+urlhttp://www.apache.org//url
+logohttp://maven.apache.org/images/apache-maven-project.png/logo
/organization
- inceptionYear2002/inceptionYear
- packagenet.nettec.marsh.begin/package
- shortDescriptionMarsh Begin TTS Maven/shortDescription
- descriptionTTS Begin/description
- url/
- issueTrackingUrlhttp://bugzilla/issueTrackingUrl
- siteAddresswww.nettec.net/siteAddress
- siteDirectory/
- distributionDirectory/
+ inceptionYear2001/inceptionYear
+ packageorg.apache.maven/package
+ logohttp://maven.apache.org/images/maven.gif/logo
+ descriptionTest for Maven Ear plugin/description
+ shortDescriptionTest for Maven Ear plugin/shortDescription
+ urlhttp://maven.apache.org/reference/plugins/ear//url
+
