Re: jdk 1.4 and 1.5 in same install?
What about carlos's suggestion? I'm sorry, but i can't include continuum profiles in 1.0.3 Emmanuel David Blevins a écrit : We have too much corba tie-in to the Sun ORB which makes it so we can't compile a few chunks of the code or test it on anything other than strict 1.4 vm (no 1.5 with 1.4 flags). -David On Feb 8, 2006, at 11:08 PM, Emmanuel Venisse wrote: An other option is to set source and target argument on compiler plugin David Blevins a écrit : Sounds like a scary m1-style hack ... not going there. Second install it is -David On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote: What about compiler and test plugins options like fork, executable, ... On 2/8/06, David Blevins [EMAIL PROTECTED] wrote: So i find myself needing jdk 1.4 for 90% of what i have in the geronimo continuum install, some of those actually can't compile with 1.5 because of corba/vm ties. But alas I do need 1.5 now for at least two projects. Do i pretty much have to setup another continuum install for this? -David
[continuum build branches/continuum-1.0.x - FAILED - update] Mon Feb 20 09:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060220.093000.txt
[continuum build trunk - SUCCESS - update] Mon Feb 20 10:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060220.10.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060220.10.txt
[continuum build branches/continuum-1.0.x - FAILED - update] Mon Feb 20 10:30:01 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060220.103001.txt
[continuum build trunk - SUCCESS - update] Mon Feb 20 11:00:01 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060220.110001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060220.110001.txt
[continuum build branches/continuum-1.0.x - SUCCESS - update] Mon Feb 20 13:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060220.133000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060220.133000.txt
[continuum build branches/continuum-1.0.x - SUCCESS - update] Mon Feb 20 17:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060220.173001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060220.173001.txt
[continuum build trunk - SUCCESS - checkout] Tue Feb 21 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060221.01.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060221.01.txt
Resource Filtering for War Plugin
Hi folks,
I've been working on web resource filtering with the war plugin and
came across a consideration I'd like to ask of the group.
What do you think of the term resources in the context of a war?
To me, resources in the POM should be considered anything including
the webapp resources, not just classpath resources. I see this
because classpath resources could easily be added to $
{warSourceDirectory}/WEB-INF/classes and used from there.
In this manner, ${warSourceDirectory} could be filtered with the same
constructions people are used to with the resources plugin. This is
the way I initially expected things to work. Brett felt otherwise
when I talked to him on IRC, but he also said he doesn't do filtering
with webapp content and I ought to ask people who care a little bit
more about this subject.
OPTION 1:
resources are added to plugin configuration. Someone who wanted to
filter their webapp resources would need to add a complete
resources configuration to their POM, such as:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0-beta-3-SNAPSHOT/version
configuration
resources
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
/resource
/resources
filters
filter
filterproperties${basedir}/src/main/
webapp/WEB-INF/classes/build.properties/filterproperties
/filter
/filters
/configuration
/plugin
In this configuration, we still have overlap with the
warSourceDirectory parameter to the war plugin and extra code needs
to be added to deal with the circumstance that either/both are
specified.
OPTION 2:
Existing semantics for the resource plugin are preserved, but
interpreted slightly differently based on the packaging. When
packagingwar/packaging, we treat the resources as components of
the webapp. I think this significantly simplifies the user experience.
Opinions?
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Somebody added jpox 1.1.0-beta6 to the repo?
I created m2 poms from m1 poms for fixing some pbs with m1 poms (cyclic dependencies, test dependencies...) jpox-1.1-beta-6.pom is the parent pom jpox-core-1.1-beta-6 is the core jar Emmanuel Carlos Sanchez a écrit : I don't know where it comes from and has m2 poms, while in their sources they are still m1. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: Resource Filtering for War Plugin
Hmm, I see there's a longstanding issue with this... http://
jira.codehaus.org/browse/MWAR-12
I'd kind of like to solve this...
-b
On Feb 20, 2006, at 12:51 AM, Brian Topping wrote:
Hi folks,
I've been working on web resource filtering with the war plugin and
came across a consideration I'd like to ask of the group.
What do you think of the term resources in the context of a war?
To me, resources in the POM should be considered anything
including the webapp resources, not just classpath resources. I
see this because classpath resources could easily be added to $
{warSourceDirectory}/WEB-INF/classes and used from there.
In this manner, ${warSourceDirectory} could be filtered with the
same constructions people are used to with the resources plugin.
This is the way I initially expected things to work. Brett felt
otherwise when I talked to him on IRC, but he also said he doesn't
do filtering with webapp content and I ought to ask people who care
a little bit more about this subject.
OPTION 1:
resources are added to plugin configuration. Someone who wanted
to filter their webapp resources would need to add a complete
resources configuration to their POM, such as:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0-beta-3-SNAPSHOT/version
configuration
resources
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
/resource
/resources
filters
filter
filterproperties${basedir}/src/main/
webapp/WEB-INF/classes/build.properties/filterproperties
/filter
/filters
/configuration
/plugin
In this configuration, we still have overlap with the
warSourceDirectory parameter to the war plugin and extra code needs
to be added to deal with the circumstance that either/both are
specified.
OPTION 2:
Existing semantics for the resource plugin are preserved, but
interpreted slightly differently based on the packaging. When
packagingwar/packaging, we treat the resources as components
of the webapp. I think this significantly simplifies the user
experience.
Opinions?
Brian
-
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]
easymock ibiblio upload: classifier or artifactId?
Hi there, I about to upload easymock-1.2 to ibiblio. There are two versions: one for java1.3, one for java1.5. Do I correctly assume that this is a prime example of using classifiers, or do I have to append the variation to the artifactId? Which one wins: easymock-1.2-java1.3.jar vs. easymock-java1.3-1.2.jar Btw., the maven-install-plugins does not seem to honor the -DpomFile parameter, thus making it impossible to install an artifact using classifiers, since there isn't a -Dclassifier argument available. Is this known or shall I create a feature request? Thanks, Michael -- Giniality AG - Michael Böckling; Steinenberg 21, CH-4051 Basel P: +41 61 226 99 63 - F: +41 61 226 99 69 [EMAIL PROTECTED]; http://www.giniality.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.ja
Hi Why maven-clean-plugin-2.1 tag was added under maven/components/tags, not i maven/plugins/tags? Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Monday, February 20, 2006 5:37 AM Subject: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.java Author: jdcasey Date: Sun Feb 19 20:37:49 2006 New Revision: 379023 URL: http://svn.apache.org/viewcvs?rev=379023view=rev Log: [maven-scm] copy for tag maven-clean-plugin-2.1 Added: maven/components/tags/maven-clean-plugin-2.1/ - copied from r377744, maven/plugins/trunk/maven-clean-plugin/ maven/components/tags/maven-clean-plugin-2.1/pom.xml - copied unchanged from r379022, maven/plugins/trunk/maven-clean-plugin/pom.xml maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java - copied unchanged from r378028, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/Fileset.java - copied unchanged from r377838, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/Fileset.java -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.11/264 - Release Date: 2006-02-17 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource Filtering for War Plugin
I'm like Brett, I haven't needed filtering in the webapp source yet.
But I think we'd need more details on how the second option would
work. My initial thought is that treating classpath resources and
webapp sources as resources is going to be really confusing...
-Stephen
On 2/20/06, Brian Topping [EMAIL PROTECTED] wrote:
Hi folks,
I've been working on web resource filtering with the war plugin and
came across a consideration I'd like to ask of the group.
What do you think of the term resources in the context of a war?
To me, resources in the POM should be considered anything including
the webapp resources, not just classpath resources. I see this
because classpath resources could easily be added to $
{warSourceDirectory}/WEB-INF/classes and used from there.
In this manner, ${warSourceDirectory} could be filtered with the same
constructions people are used to with the resources plugin. This is
the way I initially expected things to work. Brett felt otherwise
when I talked to him on IRC, but he also said he doesn't do filtering
with webapp content and I ought to ask people who care a little bit
more about this subject.
OPTION 1:
resources are added to plugin configuration. Someone who wanted to
filter their webapp resources would need to add a complete
resources configuration to their POM, such as:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0-beta-3-SNAPSHOT/version
configuration
resources
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
/resource
/resources
filters
filter
filterproperties${basedir}/src/main/
webapp/WEB-INF/classes/build.properties/filterproperties
/filter
/filters
/configuration
/plugin
In this configuration, we still have overlap with the
warSourceDirectory parameter to the war plugin and extra code needs
to be added to deal with the circumstance that either/both are
specified.
OPTION 2:
Existing semantics for the resource plugin are preserved, but
interpreted slightly differently based on the packaging. When
packagingwar/packaging, we treat the resources as components of
the webapp. I think this significantly simplifies the user experience.
Opinions?
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen Duncan Jr
www.stephenduncanjr.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPJDEPEND-8) 1.6/1.6.1-SNAPSHOT not recursing/reporting all packages
1.6/1.6.1-SNAPSHOT not recursing/reporting all packages --- Key: MPJDEPEND-8 URL: http://jira.codehaus.org/browse/MPJDEPEND-8 Project: maven-jdepend-plugin Type: Bug Versions: 1.6.1, 1.6 Reporter: Jeff Jensen The introduction of the maven.jdepend.components property causes a backwards compatibility problem. Our JDepend reports stop reporting on all packages with 1.6 and 1.6.1-SNAPSHOT; 1.5.1 works great. 1.6 introduces it and defaults to pom.project. To have the same behavior as 1.5.1 in 1.6 and 1.6.1-SNAPSHOT, the components property must be empty. With the changes made by MPJDEPEND-7, the components property can be set to nothing (1.6 would crash if set to nothing). I think the best answer is to default maven.jdepend.components to nothing, so upgrades are transparent (instead of having to set the property to nothing to get it to work - and other users spending a bunch of time as I did!) and more aligns with JDepend's components setting is optional. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-748) Upload request for ldaptemplate
Upload request for ldaptemplate --- Key: MAVENUPLOAD-748 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-748 Project: maven-upload-requests Type: Task Reporter: Alexandre Poitras Attachments: ldaptemplate-1.0-rc1-bundle.jar attached http://sourceforge.net/projects/ldaptemplate/ -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SUREFIRE-31) support junit 4.0
support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Type: Improvement Reporter: John Didion Assigned to: Jason van Zyl I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-296) Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
[ http://jira.codehaus.org/browse/MEV-296?page=comments#action_58987 ]
Robert Newson commented on MEV-296:
---
A similiar issue happens with the milestone release of activemq 4.0. Having
spoken with an activemq developer it seems unlikely that they will fix this for
the 4.0 release without assistance.
I agree that the list of optional dependencies is staggering. In order to
actually use activemq 4.0, you only need four jars.
I'm attaching my local versions of the POM's that I'm successfully using to
pull a working set of amq 4 jars.
Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
---
Key: MEV-296
URL: http://jira.codehaus.org/browse/MEV-296
Project: Maven Evangelism
Type: Bug
Components: Invalid POM
Reporter: Johannes Brodwall
Assignee: Carlos Sanchez
Attachments: MEV-296-activemq.patch, activeio-2.1-local.pom,
activemq-4.0-M4-local.pom, activemq-core-3.2.1.pom
The version numbers for dependencies are wrong. For example:
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version${commons_collections_version}/version
/dependency
When I substituted values from activemq-3.2.pom I got it to work.
That being said, the number of optional dependencies that are included as
required in activemq is just staggering!
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-296) Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
[ http://jira.codehaus.org/browse/MEV-296?page=all ]
Robert Newson updated MEV-296:
--
Attachment: activemq-4.0-M4-local.pom
Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
---
Key: MEV-296
URL: http://jira.codehaus.org/browse/MEV-296
Project: Maven Evangelism
Type: Bug
Components: Invalid POM
Reporter: Johannes Brodwall
Assignee: Carlos Sanchez
Attachments: MEV-296-activemq.patch, activeio-2.1-local.pom,
activemq-4.0-M4-local.pom, activemq-core-3.2.1.pom
The version numbers for dependencies are wrong. For example:
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version${commons_collections_version}/version
/dependency
When I substituted values from activemq-3.2.pom I got it to work.
That being said, the number of optional dependencies that are included as
required in activemq is just staggering!
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-296) Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
[ http://jira.codehaus.org/browse/MEV-296?page=all ]
Robert Newson updated MEV-296:
--
Attachment: activeio-2.1-local.pom
Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
---
Key: MEV-296
URL: http://jira.codehaus.org/browse/MEV-296
Project: Maven Evangelism
Type: Bug
Components: Invalid POM
Reporter: Johannes Brodwall
Assignee: Carlos Sanchez
Attachments: MEV-296-activemq.patch, activeio-2.1-local.pom,
activemq-4.0-M4-local.pom, activemq-core-3.2.1.pom
The version numbers for dependencies are wrong. For example:
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version${commons_collections_version}/version
/dependency
When I substituted values from activemq-3.2.pom I got it to work.
That being said, the number of optional dependencies that are included as
required in activemq is just staggering!
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-340) junit-addons is missing the junit-addons-runner jar
junit-addons is missing the junit-addons-runner jar --- Key: MEV-340 URL: http://jira.codehaus.org/browse/MEV-340 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Robert Newson Declaring a test-scope dependency on junit-addons fails as the junit-addons-runner dependency does not exist. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-749) Please upload DWR-1.1-rc1 to the global Maven 2 repo
Please upload DWR-1.1-rc1 to the global Maven 2 repo Key: MAVENUPLOAD-749 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-749 Project: maven-upload-requests Type: Task Reporter: Julien Dubois This is the latest version of DWR, thank you for uploading it. In this release : - We release the sources as well as the binaries (mvn source:jar repository:bundle-create) - We greatly improved dependency management, by using the optional/ tag -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_58996 ] John Casey commented on MDEPLOY-25: --- Deployment always implies installation in Maven. How does it make you wrongly believe the remote repository is alright? I'm not sure I follow...the whole point of this plugin is to write to the remote repository. Or, are you saying that you cannot verify what you put on the remote repository without first removing the locally installed artifact manually? If so, this is always the case in Maven. It's well documented in the lifecycle documentation here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=all ] John Casey closed MDEPLOY-25: - Assign To: John Casey Resolution: Won't Fix see previous comment. this behavior is consistent with other deployment functions of Maven. deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Assignee: John Casey Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-24) Plugin lacks documentation
[ http://jira.codehaus.org/browse/MDEPLOY-24?page=comments#action_58998 ] John Casey commented on MDEPLOY-24: --- patch looks pretty good, but we need to make sure the titles are corrected. Plugin lacks documentation -- Key: MDEPLOY-24 URL: http://jira.codehaus.org/browse/MDEPLOY-24 Project: Maven 2.x Deploy Plugin Type: Improvement Versions: 2.1 Reporter: Jerome Lacoste Fix For: 2.2 Attachments: MDEPLOY24.diff Attached the doc. To apply after MDEPLOY-23 and MDEPLOY-19. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_59000 ] Jesse Kuhnert commented on MSUREFIRE-23: The testng community is feeling very sad from not having maven 2. :'( Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Fix For: 2.2 Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-595) valid cron exprssions not allowed
valid cron exprssions not allowed - Key: CONTINUUM-595 URL: http://jira.codehaus.org/browse/CONTINUUM-595 Project: Continuum Type: Bug Components: Web interface Reporter: Brett Porter Priority: Blocker Fix For: 1.0.3 I tried: 0 0 8-16 * * MON-FRI and 0 0 8-16 * * 2-6 Both should allow business hours scheduling. It appears that it is the last element (day of week) that is not accepted, even though it is allowed here: http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-341) Xpp3 pom is invalid
Xpp3 pom is invalid --- Key: MEV-341 URL: http://jira.codehaus.org/browse/MEV-341 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Wayne Fay http://www.ibiblio.org/maven2/xpp3/xpp3/1.1.3.4/ xpp3-1.1.3.4-RC3_min.jar (md5, sha1) xpp3-1.1.3.4-RC8_min.jar (md5, sha1) xpp3-1.1.3.4.pom (md5, sha1) Resolution options, from my perspective: 1. Make a new version directory named 1.1.3.4-RC3_min and copy the RC3_min files there, along with a properly named pom with proper content. Rename current version directory to 1.1.3.4-RC8_min and edit pom name and content. (I am happy to provide poms for this option if chosen.) 2. Delete -RC3_min files, rename 1.1.3.4-RC8_min files to simply 1.1.3.4. (This is easiest. Again, happy to help if requested.) Given that XPP hasn't produced a new build in a while (since August 2005), I'm not sure why the RC3_min and RC8_min etc even exist in m2 repo. The last release was xpp3-1.1.3.4.O (that's O as in Org, not 0). http://www.extreme.indiana.edu/xgws/xsoap/xpp/ is the home of XPP. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MRM-97) Allow hard-fail configuration for a remote repository
[ http://jira.codehaus.org/browse/MRM-97?page=all ] Edwin Punzalan closed MRM-97: - Resolution: Fixed Allow hard-fail configuration for a remote repository - Key: MRM-97 URL: http://jira.codehaus.org/browse/MRM-97 Project: Maven Repository Manager Type: Task Components: remote proxy Versions: 1.0-alpha-1 Reporter: Edwin Punzalan Assignee: Edwin Punzalan Original Estimate: 8 hours Remaining: 8 hours see maven-proxy configuration http://cvs.maven-proxy.codehaus.org/maven-proxy/core/src/test/resources/org/apache/maven/proxy/config/PropertyLoaderTest1.properties?rev=1.1view=markup -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Brett Porter updated MSUREFIRE-23: -- Due Date: 28/Feb/06 Fix Version: 2.2 Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Assignee: Brett Porter Fix For: 2.2 Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_59001 ] Brett Porter commented on MSUREFIRE-23: --- test project: tacos.sf.net Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Assignee: Brett Porter Fix For: 2.2 Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-596) security applies to entry pages, but not form submission
security applies to entry pages, but not form submission Key: CONTINUUM-596 URL: http://jira.codehaus.org/browse/CONTINUUM-596 Project: Continuum Type: Bug Components: Web interface Reporter: Brett Porter Fix For: 1.1 maybe already fixed by the security overhaul, but I noticed in 1.0.3 that I could add a build definition without being logged in by submitting the form, when the guest didn't have that permission. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-81) Maven2 dependencies library providing souce information when running/debugging projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-81?page=comments#action_59004 ] Tuomas Kiviaho commented on MNGECLIPSE-81: -- 1. Have Eclipse WebTools project installed 2. Create new (preferrably generic) server and attach some (web) project to it. 3. Open launch configuration from server cheat sheet that can be opened by doubleclicking the server 4. Select source tab and press add source 5. Select 'java library' and from opened dialog you can pick up 'Maven2 managed dependencies'. Here you have the possibility to select WTP 'web app libraries' as well. Doublecliking it will sometimes lead to internal eclipse error. With this configuration I anticipate that source's can be found as they do when I explicitly add each *-source.jar, but when a debug breakpoint is met path to source is still requested. The 'Configure..' button can be achieved by rightclicking the 'Maven2 managed dependencies', but it'll open just a blank dialog. Maven2 dependencies library providing souce information when running/debugging projects --- Key: MNGECLIPSE-81 URL: http://jira.codehaus.org/browse/MNGECLIPSE-81 Project: Maven 2.x Extension for Eclipse Type: Wish Reporter: Tuomas Kiviaho Assignee: Eugene Kuleshov Attachments: Launch configuration.jpg Thanks for the source attachment option. When running projects it would be great if the plugin could as well provide the same functionality. For instance WTP server lauch configuration allows me to select the dependency library, but I'm still not able to see any sources. I bet the reason is the same as with WTP Web App library that causes a nasty Eclipse jam side effect when trying to use it by double clicking. The difference between these two libraries is that WTP has a dialog behind Configure... button which I think is nullpointering because there is no reference to any project. This would be a propably be a place to implement an alternative project reference. Of course reference to some pom.xml even outside workspace (a JBoss server minimal pom.xml perhaps) would be most flexible. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-338) JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio
[ http://jira.codehaus.org/browse/MEV-338?page=comments#action_59005 ] Emmanuel Venisse commented on MEV-338: -- I created m2 poms from m1 poms for fixing some pbs with m1 poms (cyclic dependencies, test dependencies...) jpox-1.1-beta-6.pom is the parent pom jpox-core-1.1-beta-6 is the core jar JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio -- Key: MEV-338 URL: http://jira.codehaus.org/browse/MEV-338 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Carlos Sanchez http://www.ibiblio.org/maven2/jpox/jpox/1.1.0-beta-6/ -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MWAR-12) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MWAR-12?page=comments#action_59006 ] Brian Topping commented on MWAR-12: --- I started working on a solution to this, not realizing that it was already in JIRA. When I tried this a few weeks ago, my assumption was that I would add a resources block to the project POM. Since it already specified packagingwar/packaging, I just assumed that the same configuration would work here, but it doesn't. Having gone through quite a bit of the code for both plugins by now, I can attest to the complexity of the resource filtering and how it would be good to avoid duplicating that into the war plugin. So I'm +1 for linking having these work together. It seems like a lot of the code in AbstractWarMojo.java could be removed if that were the case, and it looks like the class has had a lot of authors, so it would be worth doing. Add resource filtering to war plugin Key: MWAR-12 URL: http://jira.codehaus.org/browse/MWAR-12 Project: Maven 2.x War Plugin Type: Improvement Reporter: Mark Hobson Assignee: Brett Porter Attachments: test.zip Original Estimate: 15 minutes Remaining: 15 minutes I'd like to patch the war plugin to perform resource filtering as per the resources plugin. This is a trivial patch but would duplicate the following code from the resources plugin: PropertyUtils ReflectionProperties ResourcesMojo.copyFile(File, File) These look like handy util methods that could be incorporated into plexus-utils - what do the developers think? Also not sure how resource filtering will be affected by MNG-788. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-81) Maven2 dependencies library providing souce information when running/debugging projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-81?page=all ] Tuomas Kiviaho updated MNGECLIPSE-81: - Attachment: Launch configuration.jpg Maven2 dependencies library providing souce information when running/debugging projects --- Key: MNGECLIPSE-81 URL: http://jira.codehaus.org/browse/MNGECLIPSE-81 Project: Maven 2.x Extension for Eclipse Type: Wish Reporter: Tuomas Kiviaho Assignee: Eugene Kuleshov Attachments: Launch configuration.jpg Thanks for the source attachment option. When running projects it would be great if the plugin could as well provide the same functionality. For instance WTP server lauch configuration allows me to select the dependency library, but I'm still not able to see any sources. I bet the reason is the same as with WTP Web App library that causes a nasty Eclipse jam side effect when trying to use it by double clicking. The difference between these two libraries is that WTP has a dialog behind Configure... button which I think is nullpointering because there is no reference to any project. This would be a propably be a place to implement an alternative project reference. Of course reference to some pom.xml even outside workspace (a JBoss server minimal pom.xml perhaps) would be most flexible. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CONTINUUM-595) valid cron exprssions not allowed
[ http://jira.codehaus.org/browse/CONTINUUM-595?page=all ] Emmanuel Venisse closed CONTINUUM-595: -- Resolution: Won't Fix The '?' character is allowed for the day-of-month and day-of-week fields. It is used to specify 'no specific value'. This is useful when you need to specify something in one of the two fileds, but not the other. See the examples below for clarification Correct values are: 0 0 8-16 ? * MON-FRI and 0 0 8-16 ? * 2-6 valid cron exprssions not allowed - Key: CONTINUUM-595 URL: http://jira.codehaus.org/browse/CONTINUUM-595 Project: Continuum Type: Bug Components: Web interface Reporter: Brett Porter Priority: Blocker Fix For: 1.0.3 I tried: 0 0 8-16 * * MON-FRI and 0 0 8-16 * * 2-6 Both should allow business hours scheduling. It appears that it is the last element (day of week) that is not accepted, even though it is allowed here: http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2087) NPE in PluginXdocGenerator
NPE in PluginXdocGenerator -- Key: MNG-2087 URL: http://jira.codehaus.org/browse/MNG-2087 Project: Maven 2 Type: Bug Components: Plugin Creation Tools Versions: 2.1 Reporter: Vincent Siveton Attachments: maven-plugin-tools-api.diff This patch prevents a NPE when no mojo is found. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=comments#action_59015 ] Dave Sag commented on MAVENUPLOAD-742: -- Hi Carlos well i added that as suggested and ran mvn deploy and it looked like it worked, but when i check my temporaryrepositoy there is nothing in it. mvn output was snipped [INFO] [deploy:deploy] Uploading: file://Users/davesag/temporaryrepository/net/objectlab/maven-qalab-plugin/2.0/maven-qalab-plugin-2.0.jar 27K uploaded [INFO] Retrieving previous metadata from local [INFO] Uploading project information for maven-qalab-plugin 2.0 [INFO] Retrieving previous metadata from local [INFO] Uploading repository metadata for: 'net.objectlab' [INFO] Retrieving previous metadata from local [INFO] Uploading repository metadata for: 'artifact net.objectlab:maven-qalab-plugin' [INFO] [INFO] BUILD SUCCESSFUL [INFO] but looking in there shows nothing (disco-davesag) [13:19:32] ~/temporaryrepository$ ll total 0 drwxr-xr-x2 davesag staff68 Feb 20 13:11 . drwxr-xr-x 63 davesag staff 2142 Feb 20 13:11 .. also i am confused - why do you need this mysterious document, given there is no mention of it in the instructions. Please upload maven-qalab-plugin Key: MAVENUPLOAD-742 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 Project: maven-upload-requests Type: Task Reporter: Dave Sag Attachments: maven-qalab-plugin-2.0-bundle.jar this plugin provides the basic merge and movers mojos and main and movers reports taking input from checkstyle, PMD and findbugs and reporting statistical quality data over the life of the project. it's a reworking of the maven 1 plugin for maven 2. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Dashboard Plugin Plans
I created a new library like you suggested, and modified both the checkstyle an pmd plugins to use it by adding the new library as a dependency. When I run them individually everything works fine and I see their metrics being reported, but when I try to run both in the same build, I only see the metrics of the last plugin run (in my case checkstyle). I think this has to do with classloading and the way plexus loads its components. The metrics library has a components.xml file in its jar, so I think that the registry singleton is being created by the plugin classloader. What would be the best way to ensure that the registry is a singleton for the build? Here's my components.xml: component-set components component roleorg.apache.maven.metrics.MetricRegistry/role implementationorg.apache.maven.metrics.DefaultMetricRegistry /implementation /component /components /component-set Mauro On 2/19/06, Brett Porter [EMAIL PROTECTED] wrote: It would just need to be a common dependency. reporting-api definitely is, but you could easily create a new library for it (and that probably makes more sense). The component definition goes in the same JAR as the class. - Brett Mauro Botelho wrote: Brett, in order for any plug-in to use the MetricRegistry, would it have to be declared in the reporting-api? Where would I add the component definition for it? Mauro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] java 5's apt.exe as a compiler option?
Eddie, I just looked into apt and it looks really useful in the long term. Obviously we haven't heard a lot of demand for it so far but as more and more packages start to require Java 5 (like JUnit 4) I think we will see an increasing number of packages wanting to use this infrastructure in their build. This is my +1 to move it into either codehaus mojos or maven's sandbox. -Original Message- From: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 8:39 AM To: dev@maven.apache.org Subject: [m2] java 5's apt.exe as a compiler option? All-- I'm interested in the status of Java 5 support in Maven, particularly around supporting the JDK's new tool bin/apt.exe which is Sun's extension of javac.exe. I've written an extension of plexus-compiler-javac that adds support for apt.exe so that annotation processors can be hosted at build-time to run validation, do code generation, etc. An example of configuring this in a project is below. This supports setting the APT options as well as the javac options; the code is here: http://svn.apache.org/repos/asf/beehive/sandbox/maven2/maven-apt-compile r/ There's also this patch in Codehaus: http://jira.codehaus.org/browse/MNG-1672 that adds a standalone plugin for apt.exe (not a new compiler) but does not support forked execution or the Javac options. Any thoughts on / status of support for apt.exe in M2? I'm happy to contribute the M2 + apt compiler extension if that's appropriate. Cheers, Eddie ::: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration compilerIdapt/compilerId source1.5/source target1.5/target forktrue/fork verbosetrue/verbose compilerArguments sourcepathsrc/main/java;src/test/java/sourcepath starget/srcgen/s APTweb.content.rootsrc/main/webapp/APTweb.content.root /compilerArguments /configuration /plugin ::: - 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: RE: [m2] java 5's apt.exe as a compiler option?
We have ready APT (and AspectJ) plugin prototypes. see: http://jira.codehaus.org/browse/MNG-2089 By my opinion it is better if APT plugin acts before compilation or compilation is optional. Reason is, that Java compiler can be substituted with e.g. AspectJ compiler (in this mode have AspectJ better performance (incremental build)). best regards J.B. Eddie, I just looked into apt and it looks really useful in the long term. Obviously we haven't heard a lot of demand for it so far but as more and more packages start to require Java 5 (like JUnit 4) I think we will see an increasing number of packages wanting to use this infrastructure in their build. This is my +1 to move it into either codehaus mojos or maven's sandbox. -Original Message- From: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 8:39 AM To: dev@maven.apache.org Subject: [m2] java 5's apt.exe as a compiler option? All-- I'm interested in the status of Java 5 support in Maven, particularly around supporting the JDK's new tool bin/apt.exe which is Sun's extension of javac.exe. I've written an extension of plexus-compiler-javac that adds support for apt.exe so that annotation processors can be hosted at build-time to run validation, do code generation, etc. An example of configuring this in a project is below. This supports setting the APT options as well as the javac options; the code is here: http://svn.apache.org/repos/asf/beehive/sandbox/maven2/maven-apt-compile r/ There's also this patch in Codehaus: http://jira.codehaus.org/browse/MNG-1672 that adds a standalone plugin for apt.exe (not a new compiler) but does not support forked execution or the Javac options. Any thoughts on / status of support for apt.exe in M2? I'm happy to contribute the M2 + apt compiler extension if that's appropriate. Cheers, Eddie ::: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration compilerIdapt/compilerId source1.5/source target1.5/target forktrue/fork verbosetrue/verbose compilerArguments sourcepathsrc/main/java;src/test/java/sourcepath starget/srcgen/s APTweb.content.rootsrc/main/webapp/APTweb.content.root /compilerArguments /configuration /plugin ::: - 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: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.ja
I noticed this too. I'll move the tag, as soon as I figure out how. It looks like this happened because I was using an older plugin-parent POM version (a guess?)...I'll definitely look into it, though. -john Grzegorz Słowikowski wrote: Hi Why maven-clean-plugin-2.1 tag was added under maven/components/tags, not i maven/plugins/tags? Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Monday, February 20, 2006 5:37 AM Subject: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.java Author: jdcasey Date: Sun Feb 19 20:37:49 2006 New Revision: 379023 URL: http://svn.apache.org/viewcvs?rev=379023view=rev Log: [maven-scm] copy for tag maven-clean-plugin-2.1 Added: maven/components/tags/maven-clean-plugin-2.1/ - copied from r377744, maven/plugins/trunk/maven-clean-plugin/ maven/components/tags/maven-clean-plugin-2.1/pom.xml - copied unchanged from r379022, maven/plugins/trunk/maven-clean-plugin/pom.xml maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java - copied unchanged from r378028, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/Fileset.java - copied unchanged from r377838, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/Fileset.java -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.11/264 - Release Date: 2006-02-17 - 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: [proposal] adding pre/post phases for all major lifecycle phases
Here's an idea for how to accomplish ordering: Pick a number as the number of possible goals in a phase, say 25. The value for the order would then range from 1 to that number minus 1 (1 to 24 in this case). Each standard plugin would define their place in the sequence (either in the source code as an annotation or in the components.xml file) and probably use a fixed number for consistency sake; for the sake of this example we will use 12 as the standard sequence number. In a project's POM, the user maps the goal to the phase and sequence number; numbers less than 12 (in this case) become pre-phase and numbers greater than 12 become post-phase. If we allow a user to specify the standard goal for the phase and a new sequence number, it allows the user to adjust the execution order of even the standard plugins. If we allow the user to specify a sequence number of 0 as don't run this, we allow the user to omit the standard goal without needing to do anything within the mojo. To allow for inheritance the way things are done now, as we process each parent all sequence numbers are incremented by 25 (in this example) to prevent overlaps. For an example in a project with two generations of parents, the grandparent's goals would have numbers between 1 and 24, the parent's between 26 and 49, and the project's between 51 and 74. Each project would have specified numbers in the 1 to 24 range, the numbers are adjusted internally while assembling the inheritance. How it might look in the POM (and perhaps in the components.xml): plugin sequence6/sequence plugin How it might look in the source code: /** * @sequence 6 */ Default ordering if none is specified in the project's POM would be to use the last order numbers available. In this example if a POM had three goals mapped to a phase, they would be given sequence numbers 22, 23, and 24 in the order specified in the POM. If multiple goals end up with the same number, they are executed in a random (at least to the user) sequence. I think this would allow the average user to ignore sequencing entirely, allow declared plugins to have default places (pre-phase, phase, or post-phase), provide pre-phase and post-phase capabilities for all phases, and allow the bold and daring users to reassemble the build order in any manner they deem appropriate. Comments? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, February 17, 2006 11:26 To: Maven Developers List Subject: Re: [proposal] adding pre/post phases for all major lifecycle phases I understand that this is sort of a slippery slope WRT when we stop adding new phases. While there are major categories for the phases of a build, things like the following could occur: I generate a model using Modello, and would like to use my own custom Antlr grammar to create instances of that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Mon Feb 20 18:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060220.18.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060220.18.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: easymock ibiblio upload: classifier or artifactId?
It's already there http://test.maven.codehaus.org/maven2/easymock/easymock/ On 2/20/06, Michael Böckling [EMAIL PROTECTED] wrote: Hi there, I about to upload easymock-1.2 to ibiblio. There are two versions: one for java1.3, one for java1.5. Do I correctly assume that this is a prime example of using classifiers, or do I have to append the variation to the artifactId? Which one wins: easymock-1.2-java1.3.jar vs. easymock-java1.3-1.2.jar Btw., the maven-install-plugins does not seem to honor the -DpomFile parameter, thus making it impossible to install an artifact using classifiers, since there isn't a -Dclassifier argument available. Is this known or shall I create a feature request? Thanks, Michael -- Giniality AG - Michael Böckling; Steinenberg 21, CH-4051 Basel P: +41 61 226 99 63 - F: +41 61 226 99 69 [EMAIL PROTECTED]; http://www.giniality.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2088) antcall failed
antcall failed -- Key: MNG-2088 URL: http://jira.codehaus.org/browse/MNG-2088 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.2 Environment: Suse Linux 10.0 / JDK 1.5.0_04 / ANT 1.6.5 Reporter: Marco Meschieri Priority: Blocker I am trying to develop a maven plugin using the ant way beacuse of intensive file operations. I have many filesystem operations coded inside different targets(mainly for easy manageability) A template target invokes other targets in the same build file using the antcall task, but the invocation of this task couses the following exception: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionException: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(AntScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:33) ... 18 more Caused by: /tmp/plexus-ant-component61868.build.xml:15: The following error occurred while executing this line: java.io.FileNotFoundException: /home/marco/projects/util/build.xml (No such file or directory) at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:336) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:107) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(AntScriptInvoker.java:222) ... 19 more Caused by: java.io.FileNotFoundException: /home/marco/projects/util/build.xml (No such file or directory) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:243) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:91) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:334) ... 27 more Caused by: java.io.FileNotFoundException: /home/marco/projects/util/build.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:198) ... 30 more --
[jira] Updated: (MPSCM-67) scm:prepare-release fails because project.xml has been locally modified
[ http://jira.codehaus.org/browse/MPSCM-67?page=all ] Lukas Theussl updated MPSCM-67: --- Fix Version: (was: 1.6) I'd like to release this week. scm:prepare-release fails because project.xml has been locally modified --- Key: MPSCM-67 URL: http://jira.codehaus.org/browse/MPSCM-67 Project: maven-scm-plugin Type: Bug Versions: 1.5 Environment: Windows XP, Maven 1.0.2, Sun JDK 1.4.2_08, CVSNT 2.0.51 on localhost, maven-release-plugin-1.4.1 Reporter: Dennis Lundberg Assignee: Lukas Theussl Attachments: MPSCM-67-2.patch, MPSCM-67.patch This is weird. When I try to prepare a release using maven scm:prepare-release it complains that project.xml has been locally modified. Well, it's supposed to change that's the idea of running scm:prepare-release, right? Anyway, if I manually check in the modified project.xml and run the command again it succeeds. Let me know if you need more information. Here's the output I get: -- G:\cvs\dennislundberg-codegeneration-HEADmaven scm:prepare-release __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: scm:find-connection: [echo] Using connection: scm|cvs|pserver|[EMAIL PROTECTED]|C:/Program/cvsnt/repositories|dennislundberg-codegeneration scm:parse-connection: [echo] Using SCM method: cvs [echo] Using CVSROOT: :pserver:[EMAIL PROTECTED]:C:/Program/cvsnt/repositories [echo] Using module: dennislundberg-codegeneration scm:check-deprecated-cvs-vars: scm:prepare-release: [echo] Verifying no modifications are present [INFO] Executing: cvs -f -n -q update -d [INFO] Working directory: G:\cvs\dennislundberg-codegeneration-HEAD What is the new tag name? RELEASE-2_8 What is the new version? [RELEASE-2_8] 2.8 [echo] Updating POM with version 2.8; tag RELEASE-2_8 [echo] Committing descriptors [echo] Tagging source tree [WARNING] Unknown status: '? '. [WARNING] Unknown status: '? '. Provider message: The cvs tag command failed. Command output: cvs server: project.xml is locally modified cvs [server aborted]: correct the above errors first! BUILD FAILED File.. C:\Documents and Settings\dlg01\.maven\cache\maven-scm-plugin-1.5\plugin.jelly Element... scm:tag Line.. 244 Column 189 Error! Total time: 29 seconds Finished at: Mon Sep 26 17:25:24 CEST 2005 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPA-20) create release issues for each plugin to track votes and preparedness
[ http://jira.codehaus.org/browse/MPA-20?page=all ] John Casey updated MPA-20: -- Assign To: (was: John Casey) create release issues for each plugin to track votes and preparedness - Key: MPA-20 URL: http://jira.codehaus.org/browse/MPA-20 Project: Maven Project Administration Type: Task Components: Issue Management Reporter: John Casey Priority: Blocker Fix For: 2006-q1 should be specific to one release of one plugin, and should incorporate links to all outstanding issues for that release. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1290) What is a Mojo?
[ http://jira.codehaus.org/browse/MNG-1290?page=all ] John Casey updated MNG-1290: Assign To: (was: John Casey) What is a Mojo? --- Key: MNG-1290 URL: http://jira.codehaus.org/browse/MNG-1290 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0 Reporter: Binil Thomas Fix For: documentation On http://maven.apache.org/developers/mojo-api-specification.html page titled Mojo API, I see : snip Starting with Maven 2.0, plugins can be written in Java or any of a number of scripting languages. Additionally, Maven tries to stay out of the way of the programmer with its new Mojo API. This opens up the opportunity for many Mojos to be reused outside of Maven, or bridged into Maven from external systems like Ant. /snip The first line states a fact - that Maven plugins can now be written in plain Java. The second line doesnt suggest anything to me besides the irritating name-dropping Mojo API. The third line adds further confusion by the usage many Mojos planting the supiscion that this things called Mojo might be more than an API! Two paragraph later, I see: snip As mentioned before, each Plugin - or packaged set of Mojos .. /snip Ah! so thats it - Mojo is what constitues a Maven plugin - and there might be some API to write these. It would have been much less intimidating had this fact be stated upfront. A note here - the term plugin was did not need any introduction to me - because it is a widely one used in the software scene. At this point I don't even know what a Maven plugin can do - yet I have a vague notion that a plugin might be something that enhances the out-of-the-box behaviour of Maven. The same familiarity does not apply to the term Mojo - I am guessing here, but I think the Maven team invented the term. If so, kindly desrcibe it fully instead of confusing the reader. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MDEPLOY-7) deploy plugin leaves unnecessary information in the deployed pom.xml
[ http://jira.codehaus.org/browse/MDEPLOY-7?page=all ] John Casey updated MDEPLOY-7: - Assign To: (was: John Casey) deploy plugin leaves unnecessary information in the deployed pom.xml Key: MDEPLOY-7 URL: http://jira.codehaus.org/browse/MDEPLOY-7 Project: Maven 2.x Deploy Plugin Type: Bug Reporter: Jorg Heymans ideally, during deployment, the deployed pom should be stripped of elements like build and distributionManagement IRC log : jorg Can someone enlighten me here : when i deploy an artifact (m2), why does the deployed plugin contain the build and distributionmanagement elements ? jorg s/plugin/artifact/ jorg surely these elements are only relevant to the deployer ? jesse in the pom that is in the jar? jorg no the one that is deployed alongside the jar jorg shall I jira this ? jesse hm, I think that is a bug similar to the one with stuff in the META-INF/maven file too jorg yeah that's what i figured too jesse might as well bug it jdcasey jorg: we're not cleaning up that pom at all, just sending it on...but it's a good point jorg jdcasey: you mean about the maven version ? jdcasey I mean about the build/distributionManagement stuff...or anything that makes it into the POM that's deployed jorg oh ok , yup i think the pom should be stripped of anything not dependency related jorg i'm using deploy plugin v2.0 jdcasey I think I agree that it should be stripped of the functional parts of the POM, but not the informational stuff...it will allow us to make a richer map of project info if we leave that stuff in jorg jdcasey: yes thinking of it that's what i meant .. anything build or deploy related can go jdcasey don't ask *how this got here, it just did. ;-) jorg hehe exactly -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1465) Maven not able to find setter for MavenProjectHelper property
[ http://jira.codehaus.org/browse/MNG-1465?page=all ]
John Casey updated MNG-1465:
Assign To: (was: John Casey)
Maven not able to find setter for MavenProjectHelper property
-
Key: MNG-1465
URL: http://jira.codehaus.org/browse/MNG-1465
Project: Maven 2
Type: Bug
Reporter: David Jackman
Fix For: 2.0.4
This might really be a plexus issue (I don't know enough about the code to
know for sure).
I have a Mojo class with a field of type MavenProjectHelper. For all other
field, I've followed the pattern of using a private member field with a
prefix of m_, then using the property parameter to indicate a setter method
for that field that Maven should use. This seems to work find for most of my
properties, but the one that takes a MavenProjectHelper won't work that way.
For some reason, it looks for a field of that name and not a setter method
for that property.
Here's the field definition and the setter method:
/**
* @parameter
expression=${component.org.apache.maven.project.MavenProjectHelper}
property=projectHelper
*/
private MavenProjectHelper m_projectHelper;
/**
* Sets the project helper.
*
* @param projectHelper the project helper to use.
*/
public void setProjectHelper(MavenProjectHelper projectHelper)
{
this.m_projectHelper = projectHelper;
}
And the error I get back when attempting to use the Mojo looks like this:
[INFO] Internal error in the plugin manager executing goal
'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
plugin 'no.fast.buildprocess:docextractor'
Component Composition failed. No field of name: 'projectHelper' exists in
component: role: 'null', implementation:
'no.fast.buildprocess.ConfigdocJarMojo'
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
plugin 'no.fast.buildprocess:docextractor'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the
mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
plugin 'no.fast.buildprocess:docextractor'
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
... 16 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component
'org.apache.maven.plugin.Mojono.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar',
it could not be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:436)
at
[jira] Updated: (MNG-1962) allow empty deprecation messages in plugin descriptor/annotation and document usage of deprecation in descriptor/annotation.
[ http://jira.codehaus.org/browse/MNG-1962?page=all ] John Casey updated MNG-1962: Assign To: (was: John Casey) allow empty deprecation messages in plugin descriptor/annotation and document usage of deprecation in descriptor/annotation. Key: MNG-1962 URL: http://jira.codehaus.org/browse/MNG-1962 Project: Maven 2 Type: Improvement Components: Plugin Creation Tools, Documentation: General Versions: 2.0.1 Reporter: John Casey Priority: Minor Fix For: documentation currently, the deprecation features for plugins (not the java deprecation mechanism, necessarily) require a message for the deprecation warning to be printed. This point is poorly documented. Allow an empty deprecation message (make one up when the plugin descriptor is read, if the deprecation/ element is present but empty), and then document the usage of plugin deprecations at the class and parameter level. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRELEASE-3) release:prepare should not require multimodule artifacts to be in the local repository
[ http://jira.codehaus.org/browse/MRELEASE-3?page=all ] John Casey updated MRELEASE-3: -- Assign To: (was: John Casey) release:prepare should not require multimodule artifacts to be in the local repository -- Key: MRELEASE-3 URL: http://jira.codehaus.org/browse/MRELEASE-3 Project: Maven 2.x Release Plugin Type: Bug Reporter: John Casey Fix For: 2.0-beta-5 Currently, if you try to run release:prepare on a multimodule project after removing any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare needs the multimodule artifacts installed in the local repository before it can succeed. To reproduce, comment the following line in it2002/test.sh: mvn clean install NOTE: This may have to do with the version resolution code, which is used to resolve SNAPSHOT versions. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1489) test repository connection first time (get a file at / ?) for better error reporting
[ http://jira.codehaus.org/browse/MNG-1489?page=all ] John Casey updated MNG-1489: Assign To: (was: John Casey) test repository connection first time (get a file at / ?) for better error reporting Key: MNG-1489 URL: http://jira.codehaus.org/browse/MNG-1489 Project: Maven 2 Type: Improvement Reporter: Brett Porter Fix For: 2.1 Attachments: MNG-1489-maven-artifact-manager.patch, MNG-1489-maven-artifact.patch if a particular remote repository is being used to download from for the first time, test the retrieval of a known file so that missing proxies/unreachable repo can be better diagnosed (this may be possible to do as part of the first request instead). Currently, users receive the error that a particular plugin can't be found. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRELEASE-44) release:perform doesn't work at all without release.properties
[ http://jira.codehaus.org/browse/MRELEASE-44?page=all ] John Casey updated MRELEASE-44: --- Assign To: (was: John Casey) release:perform doesn't work at all without release.properties -- Key: MRELEASE-44 URL: http://jira.codehaus.org/browse/MRELEASE-44 Project: Maven 2.x Release Plugin Type: Bug Reporter: Brett Porter Fix For: 2.0-beta-5 Original Estimate: 2 hours Remaining: 2 hours it should be able to derive this from the mojo configuration in most cases -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1982) wagons should be tolerant of incorrect configurations in server/ entries within settings.xml
[ http://jira.codehaus.org/browse/MNG-1982?page=all ] John Casey updated MNG-1982: Assign To: (was: John Casey) wagons should be tolerant of incorrect configurations in server/ entries within settings.xml -- Key: MNG-1982 URL: http://jira.codehaus.org/browse/MNG-1982 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: John Casey Fix For: 2.0.4 basically, we need to soften the reaction to invalid configuration of a wagon...make it a warning instead of an exception. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1906) properties not being replaced before being passed to plugins (specificaly the surefire plugin)
[ http://jira.codehaus.org/browse/MNG-1906?page=all ]
John Casey updated MNG-1906:
Assign To: (was: John Casey)
properties not being replaced before being passed to plugins (specificaly the
surefire plugin)
--
Key: MNG-1906
URL: http://jira.codehaus.org/browse/MNG-1906
Project: Maven 2
Type: Bug
Reporter: Bill Dudney
Attachments: foo-root.tar.gz, transcript.txt
in the attached foo-root proj run mvn package from foo-root and you will see
that ${project.build.directory} is not substituted but
${project.x.build.directory} is.
I spent a bit of time chatting with jdcasey on irc on Dec-07-2005 about this
issue if that helps.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-655) don't load extensions into the main container
[ http://jira.codehaus.org/browse/MNG-655?page=all ] John Casey updated MNG-655: --- Assign To: (was: John Casey) don't load extensions into the main container - Key: MNG-655 URL: http://jira.codehaus.org/browse/MNG-655 Project: Maven 2 Type: Improvement Components: Plugins and Lifecycle Reporter: Brett Porter Fix For: 2.1 Original Estimate: 8 hours Remaining: 8 hours this should be done on a project by project basis - currently, they are all loaded into the main container. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-868) Use uniform format for properties and other tags
[ http://jira.codehaus.org/browse/MNG-868?page=all ] John Casey updated MNG-868: --- Assign To: (was: John Casey) Use uniform format for properties and other tags -- Key: MNG-868 URL: http://jira.codehaus.org/browse/MNG-868 Project: Maven 2 Type: Bug Components: Design, Patterns Best Practices Versions: 2.0-beta-1 Reporter: Kenney Westerhof Priority: Trivial Fix For: 2.1 Original Estimate: 2 hours Remaining: 2 hours In settings.xml, the activationproperties have the format: propertyname/value//property whereas the 'user' properties below (which don't have any documentation) have the format my.property.namemy.property.value/my.property.name. They should really be uniform. My personal favourite is ofcourse: property name=/property. There are more places where duplicate classes are used (repositories,..). (Also suggest to remove the dependencies tag from dependencyManagement and make DependencyManagement extend from Dependencies (or, make it a list)., but this could prove troublesome.) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1560) Guide to accessing repository with https client authentication
[ http://jira.codehaus.org/browse/MNG-1560?page=all ] John Casey updated MNG-1560: Assign To: (was: John Casey) Guide to accessing repository with https client authentication -- Key: MNG-1560 URL: http://jira.codehaus.org/browse/MNG-1560 Project: Maven 2 Type: Improvement Components: Documentation: Guides Versions: 2.0 Reporter: Arnaud Bailly Priority: Minor Fix For: documentation Attachments: MavenRepoSSLAccess.apt, guide-repository-ssl.apt, guide-repository-ssl.apt The attachment describes a way (in APT format) to use a remote repository through HTTPS with client-side certificate authentication. This may be useful in corporate or private development settings. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1390) @requiresDependencyResolution in process-classes post compile
[ http://jira.codehaus.org/browse/MNG-1390?page=all ]
John Casey updated MNG-1390:
Assign To: (was: John Casey)
@requiresDependencyResolution in process-classes post compile
-
Key: MNG-1390
URL: http://jira.codehaus.org/browse/MNG-1390
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0
Reporter: Jesse McConnell
Fix For: 2.0.4
Original Estimate: 3 hours
Remaining: 3 hours
I was looking back into some plugins I had written a while back and ran
across an oddity.
it appears that when using a plugin in the process-classes phase, after the
compiler plugin has done its thing, the @requiresDependencyResolution javadoc
flag will toggle the presense of dependencies that are scoped to provided in
the dependencies section when calling project.getCompileClasspathElements();
(a difference of 80 vs 24 when not using the flag and then using it)
---
this are two snippits of code from the plugin
/**
* A plugin for generating * java file containing all the classes in a src
tree.
*
* @goal generate
* @requiresDependencyResolution
* @description Functions Generator plugin
* @author jesse [EMAIL PROTECTED]
*/
List classpathFiles = project.getCompileClasspathElements();
URL[] urls = new URL[classpathFiles.size() + 1];
getLog().debug( + classpathFiles.size());
for (int i = 0; i classpathFiles.size(); ++i) {
getLog().debug((String)classpathFiles.get(i));
urls[i] = new File((String)classpathFiles.get(i)).toURL();
}
urls[classpathFiles.size()] = new File( buildDirectory + /classes
).toURL();
URLClassLoader ucl = new URLClassLoader(urls,
Thread.currentThread().getContextClassLoader());
being used with the following plugin declaration:
plugin
groupIdgallup.maven/groupId
artifactIdservices-provider-maven-plugin/artifactId
version1.0.1/version
configuration
fullyQualifiedFileNamecom/g/util/ServiceProvider.java/fullyQualifiedFileName
/configuration
executions
execution
phaseprocess-classes/phase
goals
goalgenerate/goal
/goals
/execution
/executions
/plugin
analyzing the debug output when I run the plugin without the
@requiresDependencyResolution I get 80 dependencies and it builds out the
classloader correctly..
but if I add the @requiresDependencyResolution statement I go down to 24
dependencies being put into the classloader...and the discrepency corresponds
to the presense of the scopeprovided/scope statement.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-81) Maven2 dependencies library providing souce information when running/debugging projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-81?page=comments#action_59032 ] Eugene Kuleshov commented on MNGECLIPSE-81: --- Maven2 Managed Dependencies library container does not work this way and I am not sure if we can disable choosing out container from there. It only work for current project that have pom.xml. So, if you'll go to the source management and add a project that has maven library container you should see all the sources. Please verify and confirm that. As of internal Eclipse error. Can you please check .log file or Error Log view when that happens and verify that there is org.maven.ide.eclipse in the stack trace . then fill a separate report for that issue either in ours or Eclipse bug tracking system. Maven2 dependencies library providing souce information when running/debugging projects --- Key: MNGECLIPSE-81 URL: http://jira.codehaus.org/browse/MNGECLIPSE-81 Project: Maven 2.x Extension for Eclipse Type: Wish Reporter: Tuomas Kiviaho Assignee: Eugene Kuleshov Attachments: Launch configuration.jpg Thanks for the source attachment option. When running projects it would be great if the plugin could as well provide the same functionality. For instance WTP server lauch configuration allows me to select the dependency library, but I'm still not able to see any sources. I bet the reason is the same as with WTP Web App library that causes a nasty Eclipse jam side effect when trying to use it by double clicking. The difference between these two libraries is that WTP has a dialog behind Configure... button which I think is nullpointering because there is no reference to any project. This would be a propably be a place to implement an alternative project reference. Of course reference to some pom.xml even outside workspace (a JBoss server minimal pom.xml perhaps) would be most flexible. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2089) APT AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=comments#action_59034 ] Trygve Laugstol commented on MNG-2089: -- How is this plugin different from the AspectJ plugin at mojo? See http://mojo.codehaus.org/aspectj-maven-plugin/ APT AspectJ plugins - Key: MNG-2089 URL: http://jira.codehaus.org/browse/MNG-2089 Project: Maven 2 Type: Wish Components: Sandbox Versions: 2.0.3 Reporter: Juraj Burian Priority: Minor Attachments: plugins.zip We have prototypes of AspectJ APT plugins ready. Can you put it into the Sanbox? Thanx. best regards J.Burian -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_59035 ] Geoffrey De Smet commented on MDEPLOY-25: - fair enough, but could it deploy:deploy-file at least note that it's also installing it locally? deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Assignee: John Casey Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2090) Project descriptor section anchors missing
Project descriptor section anchors missing -- Key: MNG-2090 URL: http://jira.codehaus.org/browse/MNG-2090 Project: Maven 2 Type: Bug Components: Documentation: General Reporter: Brian Fox I noticed that the anchors for the project descriptor aren't working anymore. For example: http://maven.apache.org/maven-model/maven.html#class_build doesn't take you to the build section anymore. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_59036 ] Geoffrey De Smet commented on MDEPLOY-25: - (both in the documentation and in the logging output would be nice) deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Assignee: John Casey Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MEV-338) JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio
[ http://jira.codehaus.org/browse/MEV-338?page=all ] Carlos Sanchez reopened MEV-338: JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio -- Key: MEV-338 URL: http://jira.codehaus.org/browse/MEV-338 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Carlos Sanchez http://www.ibiblio.org/maven2/jpox/jpox/1.1.0-beta-6/ -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-338) JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio
[ http://jira.codehaus.org/browse/MEV-338?page=all ] Carlos Sanchez closed MEV-338: -- Resolution: Fixed Fixed, jpox renamed to jpox-parent and jpox-core to jpox JPOX 1.1.0 Beta 6 has a POM, but it's invalid and no JAR exists on ibiblio -- Key: MEV-338 URL: http://jira.codehaus.org/browse/MEV-338 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Carlos Sanchez http://www.ibiblio.org/maven2/jpox/jpox/1.1.0-beta-6/ -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2078) Fixup super pom to activate the profile only when -DperformRelease=true.
[ http://jira.codehaus.org/browse/MNG-2078?page=all ] John Casey updated MNG-2078: Fix Version: (was: 2.0.3) 2.0.4 Fixup super pom to activate the profile only when -DperformRelease=true. Key: MNG-2078 URL: http://jira.codehaus.org/browse/MNG-2078 Project: Maven 2 Type: Bug Components: POM Versions: 2.0.2 Environment: xp Reporter: Dan Tran Fix For: 2.0.4 Attachments: MNG-2078.patch Current the profile is activated by any value including empty string http://jira.codehaus.org/browse/MRELEASE-66 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1999) Reporting inheritance does not work properly
[ http://jira.codehaus.org/browse/MNG-1999?page=all ] John Casey updated MNG-1999: Fix Version: (was: 2.0.3) 2.0.4 Reporting inheritance does not work properly Key: MNG-1999 URL: http://jira.codehaus.org/browse/MNG-1999 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Environment: FC4, JDK 1.5.0_06, Maven 2.0.2 Reporter: Ersin Er Fix For: 2.0.4 I have a parent project and some subprojects. The parent project's pom has: reporting excludeDefaultstrue/excludeDefaults /reporting However, it does not get inherited to subprojects and so all default reports are generated for all subprojects. I'm not sure if this is a bug or a lack of feature but I would be good to have it. FYI, I'm speaking about here: http://svn.apache.org/viewcvs.cgi/directory/trunks/apacheds/ -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1856) legacy layout tag in a profile does not show up in child pom.
[ http://jira.codehaus.org/browse/MNG-1856?page=all ] John Casey updated MNG-1856: Fix Version: (was: 2.0.3) 2.0.4 legacy layout tag in a profile does not show up in child pom. - Key: MNG-1856 URL: http://jira.codehaus.org/browse/MNG-1856 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.1 Environment: Windows XP Reporter: Mark Donszelmann Priority: Minor Fix For: 2.0.4 the legacy layout tag in a profile does not show up in an inherited pom. Given the following pom.xml: project modelVersion4.0.0/modelVersion groupIdxxx/groupId artifactIdyyy/artifactId version1.0-SNAPSHOT/version packagingpom/packaging profiles profile idmaven-1/id activation property namemaven1/name /property /activation distributionManagement repository idmaven-1-repo/id nameMaven1 Repository/name urlsftp://.../url layoutlegacy/layout /repository /distributionManagement /profile /profiles /project gives for: mvn projecthelp:effective-pom -Dmaven1 the following result: ... distributionManagement repository idmaven-1-repo/id nameMaven1 Repository/name urlsftp://.../url layoutlegacy/layout /repository /distributionManagement /project which is CORRECT, however if I inherit from this pom with the following pom.xml: project parent groupIdxxx/groupId artifactIdyyy/artifactId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion groupIduuu/groupId artifactIdvvv/artifactId version2.0-SNAPSHOT/version /project gives for: mvn projecthelp:effective-pom -Dmaven1 the following result: ... distributionManagement repository idmaven-1-repo/id nameMaven1 Repository/name urlsftp://.../url /repository /distributionManagement /project which is INCORRECT, the layout tag is missing. This issue may be related to: http://jira.codehaus.org/browse/MNG-731 http://jira.codehaus.org/browse/MNG-1756 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1775) No property expansion in profile activation
[ http://jira.codehaus.org/browse/MNG-1775?page=all ]
John Casey updated MNG-1775:
Fix Version: (was: 2.0.3)
2.0.4
No property expansion in profile activation
---
Key: MNG-1775
URL: http://jira.codehaus.org/browse/MNG-1775
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.1, 2.0
Environment: Linux
Reporter: Eric Andresen
Fix For: 2.0.4
I have a profile specified in the pom.xml of a project. It is inteded to be
activated based on the presence or absence of a file, using the file
profile activator.
The profiles are simple:
profile
idmetis/id
activation
filemissing${basedir}/../build.properties/missing/file
/activation
build
filtersfilter${basedir}/../build.properties.metis/filter/filters
/build
/profile
profile
iddev/id
activation
fileexists${basedir}/../build.properties/exists/file
/activation
build
filtersfilter${basedir}/../build.properties/filter/filters
/build
/profile
The problem comes in with ${basedir} -- it isn't being expanded for purposes
of evaluating the file. It's trying to look for a file named
${basedir}/../build.properties, rather than
/home/joe/projectX/projY/../build.properties; as a result, the missing
directive is always true, and the dev profile is never activated. When the
filter path is evaluated, the ${basedir} property *is* evaluated, however.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1123) publish m2 component javadoc and reports
[ http://jira.codehaus.org/browse/MNG-1123?page=all ] John Casey updated MNG-1123: Fix Version: (was: 2.0.3) 2.0.4 publish m2 component javadoc and reports Key: MNG-1123 URL: http://jira.codehaus.org/browse/MNG-1123 Project: Maven 2 Type: Task Reporter: Brett Porter Priority: Minor Fix For: 2.0.4 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1181) MavenEmbedder.execute() doesn't run reactor modules
[ http://jira.codehaus.org/browse/MNG-1181?page=all ] John Casey updated MNG-1181: Fix Version: (was: 2.0.3) 2.0.4 MavenEmbedder.execute() doesn't run reactor modules --- Key: MNG-1181 URL: http://jira.codehaus.org/browse/MNG-1181 Project: Maven 2 Type: Bug Components: Embedding Reporter: Eugene Kuleshov Priority: Blocker Fix For: 2.0.4 Attachments: MNG-1181.tar.gz, MavenEmbedder2.java MavenEmbedder.execute() doesn't run reactor modules. I've been trying to run it with generate-sources goal, but it only build the root project. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=all ] John Casey updated MNG-1509: Fix Version: (was: 2.0.3) 2.0.4 Profile activation by os doesn't work - Key: MNG-1509 URL: http://jira.codehaus.org/browse/MNG-1509 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0 Environment: Ubuntu 5.10 maven 2.0 Reporter: Bernd Bohmann Fix For: 2.0.4 Attachments: DefaultProfileManagerTest.java.patch, OperatingSystemProfileActivator.java.patch, OperatingSystemProfileActivator.java.patch, components.xml.patch Profile activation by os doesn't work. OperatingSystemProfileActivator is missing in components.xml. Implementation of OperatingSystemProfileActivator.isActive is wrong. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2048) Quote args in mvn script
[ http://jira.codehaus.org/browse/MNG-2048?page=all ]
John Casey updated MNG-2048:
Fix Version: (was: 2.0.3)
2.0.4
Quote args in mvn script
Key: MNG-2048
URL: http://jira.codehaus.org/browse/MNG-2048
Project: Maven 2
Type: Bug
Components: Command Line
Versions: 2.0.2
Environment: Windows XP
Cygwin
Reporter: Dale Wyttenbach
Priority: Minor
Fix For: 2.0.4
The mvn script as distributed does not handle quoted args such as:
m2 -Dgreeting=huh bah hello:sayhi
You get the error:
Invalid task 'bah': you must specify a valid lifecycle phase, or a goal in
the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal
Here is a fix for the mvn script:
*** mvn 2006/02/07 15:58:33 1.1
--- mvn 2006/02/07 15:58:38
***
*** 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--- 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1898) Plugin classpath broken from 2.0 to 2.0.1
[ http://jira.codehaus.org/browse/MNG-1898?page=all ]
John Casey updated MNG-1898:
Fix Version: (was: 2.0.3)
2.0.4
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http://jira.codehaus.org/browse/MNG-1898
Project: Maven 2
Type: Bug
Environment: winxp
Reporter: Brian Fox
Priority: Blocker
Fix For: 2.0.4
Attachments: MNG-1898-coreit.tar.bz2, test-1.0.zip, test-case.zip
I'm working on a kodo plugin in the codehaus mojo sandbox. Using 2.0, it
works fine. In 2.1, it can't find xercesImpl, which is a transitive
dependency of the plugin. Did something change to cause new behavior (aka a
bug) related to this? Just eyeballing the info below, in 2.0, the instance of
classloader was org.codehaus.classworlds.RealmClassLoader but in 2.0.1 it is
org.codehaus.plexus.util.RealmDelegatingClassLoader
I tried specifying xercesImpl as a direct dependency and that didn't work
either so I'm not sure it's related to the transitivity.
Output from 2.0.1: (2.0 follows further below)
[DEBUG] org.codehaus.mojo:kodo-maven-plugin:maven-plugin:1.0-alpha-1-SNAPSHOT
(selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (setting version to: 3.3.3 from
range: [3.0,])
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (selected for runtime)
[DEBUG] com.solarmetric:kodo-wl81manage:jar:1.0 (selected for runtime)
[DEBUG] com.solarmetric:kodo-workbench:jar:1.0 (selected for runtime)
[DEBUG] org.hsqldb:jdbc-hsql:jar:1.7.0 (selected for runtime)
[DEBUG] sqlline:sqlline:jar:1.0 (selected for runtime)
[DEBUG] jcommon:jcommon:jar:0.9.1 (selected for runtime)
[DEBUG] javax.jdo:jdo:jar:1.0.2 (selected for runtime)
[DEBUG] xalan:xalan:jar:2.5.1 (selected for runtime)
[DEBUG] jfreechart:jfreechart:jar:0.9.16 (selected for runtime)
[DEBUG] com.solarmetric:kodo-jdo-runtime:jar:3.3.3 (selected for runtime)
[DEBUG] javax.sql:jdbc-stdext:jar:2.0 (selected for runtime)
[DEBUG] jline:jline:jar:0.9.1 (selected for runtime)
[DEBUG] mx4j:mx4j-jmx:jar:1.1.1 (selected for runtime)
[DEBUG] jta-spec:jta-spec:jar:1.0.1 (selected for runtime)
[WARNING] While downloading xml-apis:xml-apis:2.0.0
This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
[DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for runtime)
[DEBUG] xerces:xercesImpl:jar:2.5.0 (selected for runtime)
[DEBUG] jca:jca:jar:1.0.0 (selected for runtime)
[DEBUG] mx4j:mx4j-tools:jar:1.1.1 (selected for runtime)
[DEBUG] jndi:jndi:jar:1.2.1 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] log4j:log4j:jar:1.2.12 (setting version to: 1.2.12 from range:
[1.2.9,])
[DEBUG] log4j:log4j:jar:1.2.12 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0 (selected for runtime)
[DEBUG] Configuring mojo
'org.codehaus.mojo:kodo-maven-plugin:1.0-alpha-1-SNAPSHOT:enhance' --
[DEBUG] (f) classDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] (f) searchDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] -- end configuration --
[INFO] [kodo:enhance {execution: kodo-enhance}]
[info] Found
file:E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes\com\stchome\application\supplementalforms\persist\persist.jdo
[info] [EMAIL PROTECTED]
[debug] Added to Classpath:
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/src/main/resources/
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/target/classes/
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
[INFO]
[DEBUG] Trace
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:93)
at serp.xml.XMLFactory.checkSAXCache(XMLFactory.java:217)
at serp.xml.XMLFactory.getSAXParser(XMLFactory.java:66)
at
com.solarmetric.meta.XMLMetaDataParser.parseNew(XMLMetaDataParser.java:354)
at com.solarmetric.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:320)
at
com.solarmetric.meta.ClassArgParser.getFromMetaData(ClassArgParser.java:182)
at
com.solarmetric.meta.ClassArgParser.parseClassNames(ClassArgParser.java:98)
at
[jira] Updated: (MNG-1797) Dependency excludes apply to every subsequent dependency, not just the one it is declared under.
[ http://jira.codehaus.org/browse/MNG-1797?page=all ] John Casey updated MNG-1797: Fix Version: (was: 2.0.3) 2.0.4 Dependency excludes apply to every subsequent dependency, not just the one it is declared under. Key: MNG-1797 URL: http://jira.codehaus.org/browse/MNG-1797 Project: Maven 2 Type: Bug Versions: 2.0.1 Reporter: David Hawkins Fix For: 2.0.4 Attachments: MNG-1797-maven-project.patch, it1019.tgz, it1020.tgz If you specify ANY dependency excludes, all dependencies after that one in the pom will also exclude what you specified. They appear to be cumulative on every dependency in that they bleed over into sibling dependencies. It's easy to test if you add an exclusion to a random dependency. This exclusion should exclude a required transitive dependency that is included by a dependency lower in the list. You will find that the dependency lower in the list no longer includes the required dependency because it is using the filter you declared in the other dependency. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2077) resolution fail after installing an artifact using an m2 build that was downloaded from a legacy repository
[ http://jira.codehaus.org/browse/MNG-2077?page=all ] John Casey updated MNG-2077: Fix Version: (was: 2.0.3) 2.0.4 resolution fail after installing an artifact using an m2 build that was downloaded from a legacy repository --- Key: MNG-2077 URL: http://jira.codehaus.org/browse/MNG-2077 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.3 Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.0.4 the solution to MNG-1908 this seems to have introduced a regression that causes resolution to fail after installing the artifact using an m2 build. Thanks to Patrick for testing every bizarre combination of uses for m1/m2 repositories :) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2081) Typing error in apt files
[ http://jira.codehaus.org/browse/MNG-2081?page=all ] John Casey updated MNG-2081: Fix Version: (was: 2.0.3) 2.0.4 Typing error in apt files - Key: MNG-2081 URL: http://jira.codehaus.org/browse/MNG-2081 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.1 Reporter: Vincent Siveton Fix For: 2.0.4 Attachments: typing_errors_apt.diff This patch corrects some typing errors in apt files. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1994) Execution order of child plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-1994?page=all ] John Casey updated MNG-1994: Fix Version: (was: 2.0.3) 2.0.4 Execution order of child plugins is arbitrary if inheritance is involved Key: MNG-1994 URL: http://jira.codehaus.org/browse/MNG-1994 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.1 Reporter: John Didion Priority: Critical Fix For: 2.0.4 Attachments: mergePluginLists.txt This is related to MNG-1499, but different, and, in my opinion, equally important. It makes sense that the order of plugin execution should be the same as it appears in the POM. For example, I have two plugins: one that generates a batch file and one that executes it. These plugins must run in order or the build will fail. However, the current implementation of ModelUtils.mergePluginLists does not respect the order of child plugins. There is also a seperate bug in that the assembledPlugins map is being checked for the presence of child plugins before adding them to the mergedPlugins list, but nothing is ever added to assembledPlugins. So if a plugin exists in a parent and a child, it will end up appearing twice in the child's plugin list. I have re-written this method to fix both these problems. See attached. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1703) pluginManagementdependencies is not propagated to child POMs
[ http://jira.codehaus.org/browse/MNG-1703?page=all ] John Casey updated MNG-1703: Fix Version: (was: 2.0.3) 2.0.4 pluginManagementdependencies is not propagated to child POMs Key: MNG-1703 URL: http://jira.codehaus.org/browse/MNG-1703 Project: Maven 2 Type: Bug Components: POM Versions: 2.0 Reporter: Yann Le Du Assignee: Edwin Punzalan Fix For: 2.0.4 Attachments: MNG-1703-maven-project.patch executions section in pluginManagement isn't propagated to child POMs (as configuration is). The workaround is to use plugins with inheritedtrue/inherited Is this on purpose ? -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJXR-3) Uses pom.build.sourceDirectory instead of maven.compile.src.set
[ http://jira.codehaus.org/browse/MPJXR-3?page=all ]
Lukas Theussl closed MPJXR-3:
-
Resolution: Fixed
Fix Version: 1.5
Uses pom.build.sourceDirectory instead of maven.compile.src.set
---
Key: MPJXR-3
URL: http://jira.codehaus.org/browse/MPJXR-3
Project: maven-jxr-plugin
Type: Bug
Reporter: Vincent Massol
Fix For: 1.5
I believe this is also true for several other plugins (javadoc, etc). This
means that if you use something like:
path id=maven.j2ee.compile.src.set
location=${pom.build.sourceDirectory}/../j2ee${cactus.j2ee.version}/
maven:addPath id=maven.compile.src.set
refid=maven.j2ee.compile.src.set/
it won't work with several plugins...
I'm starting to think that allowing multiple source directories in
project.xml wouldn't be so bad at all and that there are valid cases (I
believe Cactus is one - I'm happy to discuss that though).
Thanks
-Vincent
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [m2] java 5's apt.exe as a compiler option?
JB-- The goal of the APT compiler wasn't to replace the patch at Codehaus; rather it was to make it possible to use apt.exe in place of javac.exe during the compilation phase. Since apt.exe is just a superset of javac.exe, it seemed to make sense to have the Plexus compiler implementations reflect that relationship in order to have the most reuse / symmetry between the two. I noticed that the patch at Codehaus works during the generate-sources phase of the build lifecycle, but apt can also be used in instead of javac. So, it seems like APT should work in both places. In order to use it in the generate-sources phase, how about just re-hosting the APT compiler in a new plugin that works there. In looking at the plugin supporting Javac during the compile phase: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/ it doesn't seem like it would be difficult to do that. Then, we can support both use cases with the same APT compiler implementation. How would that sound? Mike, thanks for taking a look at apt. If there's consensus in the Maven community, I'll be happy to bundle the compiler up and attach it to a JIRA issue. Eddie On 2/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We have ready APT (and AspectJ) plugin prototypes. see: http://jira.codehaus.org/browse/MNG-2089 By my opinion it is better if APT plugin acts before compilation or compilation is optional. Reason is, that Java compiler can be substituted with e.g. AspectJ compiler (in this mode have AspectJ better performance (incremental build)). best regards J.B. Eddie, I just looked into apt and it looks really useful in the long term. Obviously we haven't heard a lot of demand for it so far but as more and more packages start to require Java 5 (like JUnit 4) I think we will see an increasing number of packages wanting to use this infrastructure in their build. This is my +1 to move it into either codehaus mojos or maven's sandbox. -Original Message- From: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 8:39 AM To: dev@maven.apache.org Subject: [m2] java 5's apt.exe as a compiler option? All-- I'm interested in the status of Java 5 support in Maven, particularly around supporting the JDK's new tool bin/apt.exe which is Sun's extension of javac.exe. I've written an extension of plexus-compiler-javac that adds support for apt.exe so that annotation processors can be hosted at build-time to run validation, do code generation, etc. An example of configuring this in a project is below. This supports setting the APT options as well as the javac options; the code is here: http://svn.apache.org/repos/asf/beehive/sandbox/maven2/maven-apt-compile r/ There's also this patch in Codehaus: http://jira.codehaus.org/browse/MNG-1672 that adds a standalone plugin for apt.exe (not a new compiler) but does not support forked execution or the Javac options. Any thoughts on / status of support for apt.exe in M2? I'm happy to contribute the M2 + apt compiler extension if that's appropriate. Cheers, Eddie ::: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration compilerIdapt/compilerId source1.5/source target1.5/target forktrue/fork verbosetrue/verbose compilerArguments sourcepathsrc/main/java;src/test/java/sourcepath starget/srcgen/s APTweb.content.rootsrc/main/webapp/APTweb.content.root /compilerArguments /configuration /plugin ::: - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rationale for which bugs make a release?
I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision.
Re: Rationale for which bugs make a release?
The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rationale for which bugs make a release?
The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: jdk 1.4 and 1.5 in same install?
We're not going enforce a forked-compiler/forked-tests hack on any projects that want to run in gbuild. That's the maven 1 way to solve problems. I'll setup another continuum install at some point and happily wait for the right feature. -David. On Feb 20, 2006, at 1:38 AM, Emmanuel Venisse wrote: What about carlos's suggestion? I'm sorry, but i can't include continuum profiles in 1.0.3 Emmanuel David Blevins a écrit : We have too much corba tie-in to the Sun ORB which makes it so we can't compile a few chunks of the code or test it on anything other than strict 1.4 vm (no 1.5 with 1.4 flags). -David On Feb 8, 2006, at 11:08 PM, Emmanuel Venisse wrote: An other option is to set source and target argument on compiler plugin David Blevins a écrit : Sounds like a scary m1-style hack ... not going there. Second install it is -David On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote: What about compiler and test plugins options like fork, executable, ... On 2/8/06, David Blevins [EMAIL PROTECTED] wrote: So i find myself needing jdk 1.4 for 90% of what i have in the geronimo continuum install, some of those actually can't compile with 1.5 because of corba/vm ties. But alas I do need 1.5 now for at least two projects. Do i pretty much have to setup another continuum install for this? -David
Re: Rationale for which bugs make a release?
Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rationale for which bugs make a release?
I tried to make it as easy as possible but maybe I could have done more. This is a complicated issue because of the classloading so it requires installation of a dependency in the repository to fully reproduce the issue. See the updated comment in the issue for the exact steps I just took to reproduce it with the original test case. Regardless of the specifics on this issue, I would have expected that if the test case was broken or someone was confused, that a comment would be added. That's the part that is frustrating: when you hear nothing on an issue and it gets bounced. I can appreciate that if it's too hard to reproduce or isn't very important, fine just say so. At least then I know why and can see what I can do to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:42 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
[maven2 build trunk - SUCCESS - update] Mon Feb 20 22:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060220.22.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060220.22.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for which bugs make a release?
Take a look at my last attachment to see how an it test should be made as simple as possible On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I tried to make it as easy as possible but maybe I could have done more. This is a complicated issue because of the classloading so it requires installation of a dependency in the repository to fully reproduce the issue. See the updated comment in the issue for the exact steps I just took to reproduce it with the original test case. Regardless of the specifics on this issue, I would have expected that if the test case was broken or someone was confused, that a comment would be added. That's the part that is frustrating: when you hear nothing on an issue and it gets bounced. I can appreciate that if it's too hard to reproduce or isn't very important, fine just say so. At least then I know why and can see what I can do to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:42 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource Filtering for War Plugin
That's probably all we need to close discussion on it then.
Brett had the idea of doing otherResources as plugin
configuration. I'd rather err on the side of too verbose than
confuse people.
-b
On Feb 20, 2006, at 3:22 AM, Stephen Duncan wrote:
I'm like Brett, I haven't needed filtering in the webapp source yet.
But I think we'd need more details on how the second option would
work. My initial thought is that treating classpath resources and
webapp sources as resources is going to be really confusing...
-Stephen
On 2/20/06, Brian Topping [EMAIL PROTECTED] wrote:
Hi folks,
I've been working on web resource filtering with the war plugin and
came across a consideration I'd like to ask of the group.
What do you think of the term resources in the context of a war?
To me, resources in the POM should be considered anything including
the webapp resources, not just classpath resources. I see this
because classpath resources could easily be added to $
{warSourceDirectory}/WEB-INF/classes and used from there.
In this manner, ${warSourceDirectory} could be filtered with the same
constructions people are used to with the resources plugin. This is
the way I initially expected things to work. Brett felt otherwise
when I talked to him on IRC, but he also said he doesn't do filtering
with webapp content and I ought to ask people who care a little bit
more about this subject.
OPTION 1:
resources are added to plugin configuration. Someone who wanted to
filter their webapp resources would need to add a complete
resources configuration to their POM, such as:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0-beta-3-SNAPSHOT/version
configuration
resources
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
/resource
/resources
filters
filter
filterproperties${basedir}/src/main/
webapp/WEB-INF/classes/build.properties/filterproperties
/filter
/filters
/configuration
/plugin
In this configuration, we still have overlap with the
warSourceDirectory parameter to the war plugin and extra code needs
to be added to deal with the circumstance that either/both are
specified.
OPTION 2:
Existing semantics for the resource plugin are preserved, but
interpreted slightly differently based on the packaging. When
packagingwar/packaging, we treat the resources as components of
the webapp. I think this significantly simplifies the user
experience.
Opinions?
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen Duncan Jr
www.stephenduncanjr.com
-
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]
[maven2 build trunk - SUCCESS - update] Mon Feb 20 23:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060220.230001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060220.230001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
ok, I fiddled around a bit today with the clean plugin as a basic test case... I really don't like the idea of putting setters on the mojo...not sure why, but it bugs me, probably because it is really only putting them there for testing purposes which is generally a no-no. 1) so I did it once with just a normal junit test class and put the setters on the mojo. Very little new code had to be added to get it working and it was trivial to take that plugin up to about 85% coverage...the remainder being some workaround for a windows jdk shortcoming. 2) then I redid it using the approach that Trygvis was doing in his deb-maven-plugin where you make the mojo a basic adapter to the implementation which is put together in a standard plexus layoutthis forced the generation of a fair bit more code and a couple of additional classes, but it certainly felt more true to the nature of what a mojo is...at least my perception of what a mojo is :) So I am curious as to what people think about that idea of having the mojo's setup in that way? It seems a bit heavywieght for the clean plugin but how important is it to not put those setters on the mojo? I have always been a bit of a fan for the correct conceptual way as opposed to the cheap and easy...though the cheap and easy can be faster :) Another thought I had on this is that with this adapter approach it is real easy to show the template for the plugin and how to use it...and it offers a real easy stepping stone to understanding how maven is built deeper in...and how much is that worth? so I am not really proposing anything with this followup mail...I'll generate a patch with my first test case setup for the clean plugin and put that in jira... I am however wondering if people generally like the plexified approach for the plugin implementation? I wouldn't be adverse to converting a couple more over to see how they lookand it does make them feel a bit more modular and useful outside of maven for a toolset like axistools, sablecc, or javacc since normal people don't have a facility for injecting those params.. jesse On 2/19/06, Jesse McConnell [EMAIL PROTECTED] wrote: after reading up on mocks from the links that vincent posted, I am going to take a stab at putting together a minor set of these to work with for a couple of the plugins...just to see how it would work out. Hopefully I can get with vincent a bit tomorrow to make sure I get it close to right the first time jesse On 2/18/06, Brett Porter [EMAIL PROTECTED] wrote: Vincent Massol wrote: I think what you're describing is a stub but not a mock. The advantage of a dynamic mock is that you don't need to code any method. It's the user of the mock which says what behavior it should have for the methods it calls on the mock. You're right, I've always referred to stubs incorrectly as mocks. I meant a stub. I think it's in our interest to produce these to make testing easier and more consistent for everyone. I'm interested to see your thoughts on the mocks eventually though - I've never really done anything with them since I was reading JiA (which I don't have any more :( - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
How to store and access plugin resources in maven 2
In Maven 1 there was a way to store resources with your plugin that you could easily access inside the plugin to copy out the resources etc. I used this for delivering templates etc. I accessed the directory via the plugin-resources parameter and it worked very well. Is there such a parameter available in Maven 2. I have a need to deliver some based java classes with my plugin and the archetype structure does not allow me the flexibility to deliver the files I need. I am looking for a way to package some files within my plugin and access those files from within the plugin. The alternative would be to understand how to make the archetype structure support complex java trees. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] [m1] plugin releases
Hi, Please vote on the release of the following m1 plugins: [] maven-artifact-plugin-1.8 [] maven-jxr-plugin-1.5 [] maven-scm-plugin-1.6 The artifact and scm releases are necessary now that the repository and release plugins are demoted, the jxr plugin was just waiting for the first JXR release, which is now available. Please check the changes and jira reports on the preliminary project pages: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-artifact-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-jxr-plugin/ http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/reference/plugins/maven-scm-plugin/ Vote closes in 72h. +1 Thanks, -Lukas maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.8-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-jxr-plugin -Dversion=1.5-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Feb 20 23:45:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060220.234502.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060220.234502.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
