[jira] Created: (MNGECLIPSE-123) Goals in dialog are getting mixed by new selection
Goals in dialog are getting mixed by new selection -- Key: MNGECLIPSE-123 URL: http://jira.codehaus.org/browse/MNGECLIPSE-123 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Maven Launcher Versions: 0.0.7 Reporter: jeremie granat Assigned to: Eugene Kuleshov Priority: Minor Fix For: 0.0.8 Attachments: Maven2LaunchMainTab.java If you change he goal of a maven2 external tool configuration, the editor will add it to the list creating a undefined goal: before == compile:compile want to change to jar:jar after == jar:jarcompile:compile I think that when you change the goals using the chooser, the field should be overwritten by the selection. actually, there is only one line to change :) -- 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] Reopened: (MEV-391) missing pom for xerces 2.8.0
[ http://jira.codehaus.org/browse/MEV-391?page=all ] Olivier Lamy reopened MEV-391: -- I agree with this. But I don't known all informations on this artifact (specially dependencies). This need to be add by xerces team ? I have just put a simple pom as the previous version : http://www.ibiblio.org/maven2/xerces/xercesImpl/2.7.1/xercesImpl-2.7.1.pom Olivier missing pom for xerces 2.8.0 Key: MEV-391 URL: http://jira.codehaus.org/browse/MEV-391 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Olivier Lamy Assignee: Carlos Sanchez Add the simple xercesImpl-2.8.0.pom in http://www.ibiblio.org/maven2/xerces/xercesImpl/2.8.0/ project modelVersion4.0.0/modelVersion groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.0/version /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
[jira] Commented: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_65263 ] Pascal Magnard commented on MSUREFIREREP-6: --- I've got the same issue as Dirk. I added the surefire-report plugin declaration to the reporting section of my pom and each time this plugin is executed, the test phase is invoked. The expected behavior, according to the documentation, would be the surefire plugin to invoke the test phase (http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html) but not the surefire-report plugin (http://maven.apache.org/plugins/maven-surefire-report-plugin/report-mojo.html). Having the tests ran twice when invoking mvn clean install site is more than annoying for the project i'm working on because the compilation and the testing are performed twice and they unfortunatly take a big while. That would be great if you could provide a mean to prevent from having the surefire-report plugin kicking off a test phase when triggered. Some boolean like 'invokeTest' in the configuration section of the plugin would be just fine. (And btw, Brett, i've been looking for you solution but was not able to find any skip tag in either the Maven 1.1 or Maven 2 POM XML schema.) surefire-report reruns tests Key: MSUREFIREREP-6 URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 Project: Maven 2.x Surefire report Plugin Type: Bug Environment: maven 2.0 Reporter: Dirk Sturzebecher surefire-report reruns the tests. In my case this is not just annoying, but leads to a failure, as the VM (probably) is reused and leftovers from the first tests are (definitly) still present. I run maven with: clean package site -- 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] Closed: (SCM-196) scm:update doesn't reuse developerConnection when connection not defined.
[ http://jira.codehaus.org/browse/SCM-196?page=all ] Emmanuel Venisse closed SCM-196: Assign To: Emmanuel Venisse Resolution: Won't Fix You can choose the developerConnection with connectionType parameter mvn scm:update -DconnectionType=developerConnection scm:update doesn't reuse developerConnection when connection not defined. - Key: SCM-196 URL: http://jira.codehaus.org/browse/SCM-196 Project: Maven SCM Type: Improvement Components: maven-scm-provider-svn, maven-plugin Environment: mvn 2.0.4 scm: 1.0-20060505.091301-5 svn 1.3.1 Reporter: Jerome Lacoste Assignee: Emmanuel Venisse I am using mvn scm:update in a project without a connection (but with a developerConnectino) and scm:update fails: [INFO] -- [ERROR] BUILD ERROR [INFO] -- [INFO] Cannot run checkout command : Embedded error: Can't load the scm provider. You need to define a connectionUrl parameter [INFO] -- The plugin should use the developerConnection when no connection has been defined. Otherwise that forces one to copy the developerConnection into the connection one which defeats DRY and the fact that the connection represents a read-only element. Not sure if that problem is subversion dependent or not, so I selected both the plugin and the svn specific component. -- 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-2290) Generated URLs in POMs of child modules
Generated URLs in POMs of child modules
---
Key: MNG-2290
URL: http://jira.codehaus.org/browse/MNG-2290
Project: Maven 2
Type: Improvement
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Joerg Schaible
Maven has quite some elements where a URL or a path is modified automatically
for child POMs (the ones I am currently aware of):
- url
- scm/connection
- scm/developerConnection
- scm/url
- distributionManagement/site/url
While expanding this path with /${pom.artifactId} sounds reasonable, this
approach fails badly for complex projects with more hierarchy levels. Suppose
we have a directory structure like:
* project
** core
*** provider
commons
impl1
In this hierarchy all POMs for _project_, _core_ and _provider_ are of package
type _pom_, while _commons_ and _impl1_ is of type _jar_. The artifactId
approach now simply assumes that all POMs in the hierarchy are named like the
current directory. This does simply not match. Suppose those jar artifacts are
used in an enterprise or web app. Then every artifact is located in one single
directory and therefore the names have to be unique. But if you decide to take
an artifact name different to the directory name, you have to add the
definition in every POM, because the scm elements are simply wrong.
An even worse scenario are components that can be provided using different
technologies. We have a lot of such structures:
* component
** jar
** war
** ear
* *_jar_:* the core functionality
* *_war_:* the core functionality integrated and eccessible with a web
application
* *_ear_:* the complete component as enterprise app, if it makes sense to
deploy the functionality on a different app server
_component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
with the according package type. All of the three POMs use the same artifactId
though. In this case not only the scm elements break, but also the URLs for the
site, since they are all the same for all three artifacts.
All of this could have been avoided, if the expanded part is not the
artifactId, but the basename of the current directory. Especially for the scm
elements, this is IMHO the only valid assumption.
It would already help us, if this auto-expansion could be turned off to allow
the definition of a single property in each POM for a correct interpolation of
those values, but there seems no such option ^1^. So you *have to* add those
elements under all circumstances into every POM.
1) The _tagBase_ of the release plugin does no such auto-expansion, which makes
it quite easy to use a property for it, that can be set individually in every
POM without adding any plugin configuration.
--
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: (MANTLR-6) Support for grammar inheritance
Support for grammar inheritance --- Key: MANTLR-6 URL: http://jira.codehaus.org/browse/MANTLR-6 Project: Maven 2.x Antlr Plugin Type: New Feature Reporter: Piotr Kaminski maven-antlr-plugin does not support grammar inheritance (-glib argument). See http://jira.codehaus.org/browse/MPANTLR-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
[jira] Commented: (SCM-195) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/SCM-195?page=comments#action_65272 ] Emmanuel Venisse commented on SCM-195: -- Sorry, but I don't understand what is the problem. Wrong SCM info put by the release plugin for modules Key: SCM-195 URL: http://jira.codehaus.org/browse/SCM-195 Project: Maven SCM Type: Bug Versions: 1.0-beta-3 Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion SCM Reporter: Arik Kfir Fix For: 1.0 Hi, I have a project with several modules in it. The entire project is stored in one SVN repository, in the following layout: myproject | +-- module A | +-- module B | +-- . The root pom has a scm url like http://svn.myserver/.../trunk/;, and each sub module also has its own scm tag with a url such as http://svn.myserver/.../trunk/moduleA;, etc. When running release:prepare, the URL encoded back into the modules' POMs (the back-to-trunk pom, not the released one) is the same URL as the root POM, rather than the original module's SCM url. So module A's scm urls would be http://svn.myserver/.../trunk/; without the moduleA directory appended to it (as it was before releasing). Carlos has pointed out to me that the best practice for this use case is not specifying the scm tag for the modules' POMs at all. He did, however, also noted that it's still a bug - hence this JIRA ;-) Cheers. -- 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-2291) svn ignore command incorrect
svn ignore command incorrect Key: MNG-2291 URL: http://jira.codehaus.org/browse/MNG-2291 Project: Maven 2 Type: Bug Components: Documentation: Guides Versions: 2.0.4 Reporter: Jerome Lacoste Attachments: patch.txt svn propset . svn:ignore -F ~/Documents/svnignore.txt svn: Bad property name: '.' svn propset svn:ignore -F ~/Documents/svnignore.txt . property 'svn:ignore' set on '.' svn --version svn, version 1.3.1 (r19032) compiled May 6 2006, 00:19:28 -- 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] Closed: (MNG-2292) Properties have no scope
[ http://jira.codehaus.org/browse/MNG-2292?page=all ]
Joerg Schaible closed MNG-2292:
---
Resolution: Cannot Reproduce
Invalid report, I was fooled by the output of help:effective-pom that contains
the child pom as well as the parent pom.
Properties have no scope
Key: MNG-2292
URL: http://jira.codehaus.org/browse/MNG-2292
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Joerg Schaible
If a property is overwritten in a chiuld POM, the parent's property will also
change! This leeds to unexpected results for interpolation.
Example:
Have a parent POM with:
{noformat}
...
groupIdtest/groupId
artifactIdparent/parent
version1/version
url${my.url}/url
...
modules
modulechild/module
/modules
...
properties
my.urlhttp://parent/my.url
/properties
...
{noformat}
and a child POM with:
{noformat}
...
parent
groupIdtest/groupId
artifactIdparent/parent
version1/version
/parent
url${my.url}/url
...
properties
my.urlhttp://child/my.url
/properties
...
{noformat}
Look at the effective-pom for the parent, its URL is now also http://child;.
The properties should have a scope and should not be backpropagated to the
parent.
--
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] Updated: (SCM-190) Location of cvs-settings.xml should be in user.home and not in user.dir
[ http://jira.codehaus.org/browse/SCM-190?page=all ]
Emmanuel Venisse updated SCM-190:
-
Assign To: Emmanuel Venisse
Fix Version: 1.0
Location of cvs-settings.xml should be in user.home and not in user.dir
---
Key: SCM-190
URL: http://jira.codehaus.org/browse/SCM-190
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-cvs
Versions: 1.0-beta-3
Reporter: Thibaut CAZENAVE
Assignee: Emmanuel Venisse
Priority: Trivial
Fix For: 1.0
In static method getSettings() of CvsUtil class
(org.apache.maven.scm.provider.cvslib.util), we try to get the
cvs-settings.xml property file from ${user.dir}/.scm/
File scmUserDir = new File( System.getProperty( user.dir ), .scm );
File settingsFile = new File( scmUserDir, cvs-settings.xml );
The SCM documentation (http://maven.apache.org/scm/cvs.html) say this file
should be in ${user.home}/.scm/ and not {user.dir}/.scm/.
This should be easy to correct.
Thibaut
--
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: (MSITE-131) Not inheriting the site settings for distributionManagement from a super pom
Not inheriting the site settings for distributionManagement from a super pom Key: MSITE-131 URL: http://jira.codehaus.org/browse/MSITE-131 Project: Maven 2.x Site Plugin Type: Bug Reporter: Malcolm Wong Ho -- 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: (SCM-199) Parameter startDate for scm:changelog does not work for Clearcase LT
Parameter startDate for scm:changelog does not work for Clearcase LT Key: SCM-199 URL: http://jira.codehaus.org/browse/SCM-199 Project: Maven SCM Type: Improvement Components: maven-scm-provider-clearcase Environment: Clearcase LT 2003.06.14 Reporter: Mark Holster Priority: Minor Attachments: changelog-patch.txt The startDate configuration parameter for the scm:changelog goal does not pass the -since parameter to the clearcase command. According to SCM-135 this is because Clearcase LT does not support this option. As far as I can see this isn't correct. According to the Clearcase LT Documentation the -since parameter does not work when the -g- raphical parameter is used as well (which isn't the case) (mutual exclusive). I'm not familiar with svn. The included patch is a svn diff taken from /maven/scm/trunk with the subversion plugin in eclipse. The patch is tested locally with Clearcase LT 2003.06.14. -- 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-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface - Key: MNG-2293 URL: http://jira.codehaus.org/browse/MNG-2293 Project: Maven 2 Type: New Feature Components: Plugin Creation Tools Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Critical Attachments: testcase.diff MOJO-393 is about letting the user define an alternate configuration element, thus changing the way the webstart plugin works. For that the idea was to make the mojo field an interface, provide a default implementation in the plugin and let the user use plexus to instanciate a new implemenation. so for most users we would have: configuration bla /bla /configuration and for some: configuration bla implementation=combla /bla /configuration Unfortunately, today I am forced to specify the implementation in both cases. There's no way to inform the plugin to use the default implementation. The plugin.xml contains: parameter namebla/name type...BlaInterface/type !-- that will fail -- ... /parameter I tried to use /[EMAIL PROTECTED] implementation=...BlaImplementation*/ BlaInterface bla; but that fails as well. Marking critical because it doesn't allow me add new features to the plugin without breaking the config.xml. -- 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: (MSUREFIRE-108) Test-resources not on top of classpath while running tests
Test-resources not on top of classpath while running tests -- Key: MSUREFIRE-108 URL: http://jira.codehaus.org/browse/MSUREFIRE-108 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Jan Palmquist Fix of bug [MSUREFIRE-74] seem to have introduced a classpath error not loading target/test-classes before target/classes on classpath. test-classes need to be on classpath before classes in order for test/resources to have precedence over main/resources. Any resources having the same name (eg configuration files) now seem to be loaded from main/resources instead of test/resources. Debug output from build: ... [DEBUG] maven-surefire-plugin: resolved to version 2.2-SNAPSHOT from repository central [DEBUG] maven-surefire-plugin: resolved to version 2.2-20060507.223157-4 from repository central ... [DEBUG] C:\myproj\target\classes [DEBUG] C:\myproj\target\test-classes [DEBUG] C:\Documents and Settings\jan\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar [DEBUG] C:\Documents and Settings\jan\.m2\repository\relaxngDatatype\relaxngDatatype\20020414\relaxngDatatype-20020414.jar aso... -- 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: (MNG-1012) parent with only relativePath doesn't work
[ http://jira.codehaus.org/browse/MNG-1012?page=comments#action_65286 ] David Smiley commented on MNG-1012: --- I understand that it needs to be standalone. Perhaps when a POM is deployed to a repository, the groupId, artifactId, and version could be inserted (dynamically) and the relativePath would be removed. So the published POM and the POM seen by the developer of the project would be slightly different in this respect. With this compromise, we get the best of both worlds. If you need help on an XSLT to do this, contact me. parent with only relativePath doesn't work -- Key: MNG-1012 URL: http://jira.codehaus.org/browse/MNG-1012 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Reporter: Hao Chen Use the following in child pom.xml parent relativePath../pom.xml/relativePath /parent Got error: [INFO] Reason: Missing groupId element from parent element Why do we need groupId, artifactId, and version? These data are already contained in ../pom.xml. It should work the same as Maven 1.0 extends. -- 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: (CONTINUUM-678) Email notification list is duplicated at each build (and then grows exponentially)
[ http://jira.codehaus.org/browse/CONTINUUM-678?page=comments#action_65289 ] Ronald Pieterse commented on CONTINUUM-678: --- I have the same problem. Notifiers are duplicated on every build but with me the buildnumbers go up by 1. Will this be solved soon? otherwise there's really no point in using continuum if we can't get notifications (or rather get an awful lot of them) Email notification list is duplicated at each build (and then grows exponentially) --- Key: CONTINUUM-678 URL: http://jira.codehaus.org/browse/CONTINUUM-678 Project: Continuum Type: Bug Components: Mail Notifier, Core system Versions: 1.0.3 Environment: Windows XP Reporter: Carlo Bonamico I add a maven 1 project. Then, if I manually add a mail notifier in the project config page, each time I request a build, the notifier list gets duplicated, so the number of notifications grows exponentially... Besides, the build number is incremented by two and not by one. The Maven 1 project is a multi-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
[jira] Commented: (MPGENAPP-26) Problem with maven.genapp.repackage.dir and maven.genapp.repackage
[ http://jira.codehaus.org/browse/MPGENAPP-26?page=comments#action_65292 ] Charles Rathouis commented on MPGENAPP-26: -- Here is a patch which - fix this problem - add a new feature : Rename the filename which contain tag like @[EMAIL PROTECTED] Problem with maven.genapp.repackage.dir and maven.genapp.repackage -- Key: MPGENAPP-26 URL: http://jira.codehaus.org/browse/MPGENAPP-26 Project: maven-genapp-plugin Type: Bug Versions: 2.3 Environment: Test on windows Reporter: Charles Rathouis Attachments: saint-gobain.zip When you use the maven.genapp.repackage.dir properties and set it to . , the files contained in the maven.genapp.repackage directory are not moved to the new package directory, but copied in it, and steel in the base directory. Here is the template.properties file : maven.genapp.repackage.dir= maven.genapp.repackage=main/src/java,test/src/unit maven.genapp.filter=project.xml maven.genapp.default.package=com.saint-gobain.sgsi.my_application maven.genapp.filter=project.xml,main/src/webapp/WEB-INF/web.xml The content of main/src/java are not moved in main/src/java/com/saint-gobain/sgsi/my_application but copyed in it and steel in the main/src/java directory. If I put the main and test directory in a src directory, and remove the maven.genapp.repackage.dir propertie, everything works fine. You can find in attachment the template -- 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] Updated: (MPGENAPP-26) Problem with maven.genapp.repackage.dir and maven.genapp.repackage
[ http://jira.codehaus.org/browse/MPGENAPP-26?page=all ] Charles Rathouis updated MPGENAPP-26: - Attachment: jelly.diff Problem with maven.genapp.repackage.dir and maven.genapp.repackage -- Key: MPGENAPP-26 URL: http://jira.codehaus.org/browse/MPGENAPP-26 Project: maven-genapp-plugin Type: Bug Versions: 2.3 Environment: Test on windows Reporter: Charles Rathouis Attachments: jelly.diff, saint-gobain.zip When you use the maven.genapp.repackage.dir properties and set it to . , the files contained in the maven.genapp.repackage directory are not moved to the new package directory, but copied in it, and steel in the base directory. Here is the template.properties file : maven.genapp.repackage.dir= maven.genapp.repackage=main/src/java,test/src/unit maven.genapp.filter=project.xml maven.genapp.default.package=com.saint-gobain.sgsi.my_application maven.genapp.filter=project.xml,main/src/webapp/WEB-INF/web.xml The content of main/src/java are not moved in main/src/java/com/saint-gobain/sgsi/my_application but copyed in it and steel in the main/src/java directory. If I put the main and test directory in a src directory, and remove the maven.genapp.repackage.dir propertie, everything works fine. You can find in attachment the template -- 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] Reopened: (SCM-197) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/SCM-197?page=all ] Emmanuel Venisse reopened SCM-197: -- scm.url gets translated incorrectly during release -- Key: SCM-197 URL: http://jira.codehaus.org/browse/SCM-197 Project: Maven SCM Type: Bug Versions: 1.0-alpha-4 Reporter: Brian Fox Assignee: Emmanuel Venisse Testing release 2.0-beta4. My original scm urls are like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/developerConnection urlhttp://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1/url /scm after the prepare, they end up like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/developerConnection urlhttp://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/url /scm Notice the url lost the viewvc reference and ended up with a direct svn url. After a release:perform, the url ends up back to viewvc so only the tag is modified. -- 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] Moved: (MRELEASE-107) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/MRELEASE-107?page=all ] Emmanuel Venisse moved SCM-197 to MRELEASE-107: --- Version: (was: 1.0-alpha-4) 2.0-beta-4 Complexity: (was: Intermediate) Key: MRELEASE-107 (was: SCM-197) Project: Maven 2.x Release Plugin (was: Maven SCM) scm.url gets translated incorrectly during release -- Key: MRELEASE-107 URL: http://jira.codehaus.org/browse/MRELEASE-107 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Reporter: Brian Fox Assignee: Emmanuel Venisse Testing release 2.0-beta4. My original scm urls are like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/developerConnection urlhttp://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1/url /scm after the prepare, they end up like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/developerConnection urlhttp://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/url /scm Notice the url lost the viewvc reference and ended up with a direct svn url. After a release:perform, the url ends up back to viewvc so only the tag is modified. -- 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: (MRELEASE-107) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/MRELEASE-107?page=comments#action_65298 ] Emmanuel Venisse commented on MRELEASE-107: --- The url rewriting mustn't use resolveUrl method from SvnTagBranchUtils because this method is only for scm urls and the calcul is based only on tagBase. The release plugin must have this own method for rewriting the url that can be totally independant of path in svn (like viewcvs urls) scm.url gets translated incorrectly during release -- Key: MRELEASE-107 URL: http://jira.codehaus.org/browse/MRELEASE-107 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Reporter: Brian Fox Assignee: Emmanuel Venisse Testing release 2.0-beta4. My original scm urls are like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/developerConnection urlhttp://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1/url /scm after the prepare, they end up like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/developerConnection urlhttp://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/url /scm Notice the url lost the viewvc reference and ended up with a direct svn url. After a release:perform, the url ends up back to viewvc so only the tag is modified. -- 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: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_65301 ] Jerome Lacoste commented on MNG-2293: - I must have forgotten something: the plugin.xml generated for org.apache.maven.plugin.coreit.ParameterImplementationMojo doesn't contain anything related to the specified implementation for the bla field. Nothing related to MyBla in the file... maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface - Key: MNG-2293 URL: http://jira.codehaus.org/browse/MNG-2293 Project: Maven 2 Type: New Feature Components: Plugin Creation Tools Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Critical Attachments: it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff, testcase.diff MOJO-393 is about letting the user define an alternate configuration element, thus changing the way the webstart plugin works. For that the idea was to make the mojo field an interface, provide a default implementation in the plugin and let the user use plexus to instanciate a new implemenation. so for most users we would have: configuration bla /bla /configuration and for some: configuration bla implementation=combla /bla /configuration Unfortunately, today I am forced to specify the implementation in both cases. There's no way to inform the plugin to use the default implementation. The plugin.xml contains: parameter namebla/name type...BlaInterface/type !-- that will fail -- ... /parameter I tried to use /[EMAIL PROTECTED] implementation=...BlaImplementation*/ BlaInterface bla; but that fails as well. Marking critical because it doesn't allow me add new features to the plugin without breaking the config.xml. -- 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] Updated: (MPGENAPP-26) Problem with maven.genapp.repackage.dir and maven.genapp.repackage
[ http://jira.codehaus.org/browse/MPGENAPP-26?page=all ] Lukas Theussl updated MPGENAPP-26: -- Assign To: Lukas Theussl Fix Version: 2.3.1 Problem with maven.genapp.repackage.dir and maven.genapp.repackage -- Key: MPGENAPP-26 URL: http://jira.codehaus.org/browse/MPGENAPP-26 Project: maven-genapp-plugin Type: Bug Versions: 2.3 Environment: Test on windows Reporter: Charles Rathouis Assignee: Lukas Theussl Fix For: 2.3.1 Attachments: jelly.diff, saint-gobain.zip When you use the maven.genapp.repackage.dir properties and set it to . , the files contained in the maven.genapp.repackage directory are not moved to the new package directory, but copied in it, and steel in the base directory. Here is the template.properties file : maven.genapp.repackage.dir= maven.genapp.repackage=main/src/java,test/src/unit maven.genapp.filter=project.xml maven.genapp.default.package=com.saint-gobain.sgsi.my_application maven.genapp.filter=project.xml,main/src/webapp/WEB-INF/web.xml The content of main/src/java are not moved in main/src/java/com/saint-gobain/sgsi/my_application but copyed in it and steel in the main/src/java directory. If I put the main and test directory in a src directory, and remove the maven.genapp.repackage.dir propertie, everything works fine. You can find in attachment the template -- 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] Updated: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=all ] Jerome Lacoste updated MNG-2293: Attachment: it0106.tar.bz2 patch-MNG-2293-source2.tar.bz2 patch-MNG-2293.diff maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface - Key: MNG-2293 URL: http://jira.codehaus.org/browse/MNG-2293 Project: Maven 2 Type: New Feature Components: Plugin Creation Tools Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Critical Attachments: it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff, testcase.diff MOJO-393 is about letting the user define an alternate configuration element, thus changing the way the webstart plugin works. For that the idea was to make the mojo field an interface, provide a default implementation in the plugin and let the user use plexus to instanciate a new implemenation. so for most users we would have: configuration bla /bla /configuration and for some: configuration bla implementation=combla /bla /configuration Unfortunately, today I am forced to specify the implementation in both cases. There's no way to inform the plugin to use the default implementation. The plugin.xml contains: parameter namebla/name type...BlaInterface/type !-- that will fail -- ... /parameter I tried to use /[EMAIL PROTECTED] implementation=...BlaImplementation*/ BlaInterface bla; but that fails as well. Marking critical because it doesn't allow me add new features to the plugin without breaking the config.xml. -- 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] Updated: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=all ] Kenney Westerhof updated MNG-2293: -- Attachment: (was: testcase.diff) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface - Key: MNG-2293 URL: http://jira.codehaus.org/browse/MNG-2293 Project: Maven 2 Type: New Feature Components: Plugin Creation Tools Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Critical Attachments: it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff MOJO-393 is about letting the user define an alternate configuration element, thus changing the way the webstart plugin works. For that the idea was to make the mojo field an interface, provide a default implementation in the plugin and let the user use plexus to instanciate a new implemenation. so for most users we would have: configuration bla /bla /configuration and for some: configuration bla implementation=combla /bla /configuration Unfortunately, today I am forced to specify the implementation in both cases. There's no way to inform the plugin to use the default implementation. The plugin.xml contains: parameter namebla/name type...BlaInterface/type !-- that will fail -- ... /parameter I tried to use /[EMAIL PROTECTED] implementation=...BlaImplementation*/ BlaInterface bla; but that fails as well. Marking critical because it doesn't allow me add new features to the plugin without breaking the config.xml. -- 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: (CONTINUUM-695) Ability to edit Notifier from Project.
Ability to edit Notifier from Project. -- Key: CONTINUUM-695 URL: http://jira.codehaus.org/browse/CONTINUUM-695 Project: Continuum Type: Wish Components: Web interface Versions: 1.0.3 Reporter: Shinobu Kawai Priority: Minor It would be great if you could edit the Notifier added from the Project. As a workaround, I am updating the table in the database: ij update sa.ProjectNotifier set send_On_Success='N'; -- 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] Closed: (MEV-391) missing pom for xerces 2.8.0
[ http://jira.codehaus.org/browse/MEV-391?page=all ] Carlos Sanchez closed MEV-391: -- Resolution: Fixed Added pom to apache repo will take some time to get it in ibiblio missing pom for xerces 2.8.0 Key: MEV-391 URL: http://jira.codehaus.org/browse/MEV-391 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Olivier Lamy Assignee: Carlos Sanchez Add the simple xercesImpl-2.8.0.pom in http://www.ibiblio.org/maven2/xerces/xercesImpl/2.8.0/ project modelVersion4.0.0/modelVersion groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.0/version /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
[jira] Commented: (MAVEN-1691) Variable scope problem
[ http://jira.codehaus.org/browse/MAVEN-1691?page=comments#action_65313 ] Lukas Theussl commented on MAVEN-1691: -- It is indeed a bug in jelly and it has already been fixed in svn: http://svn.apache.org/viewcvs.cgi?rev=227285view=rev Unfortunately, with the current jelly 1.1-SNAPSHOT, I see a whole bunch of other test failures in our plugins, but at least your attached test case works! Variable scope problem -- Key: MAVEN-1691 URL: http://jira.codehaus.org/browse/MAVEN-1691 Project: Maven Type: Bug Components: jelly/ant integration Versions: 1.1-beta-2 Reporter: Arnaud Heritier Assignee: Arnaud Heritier Priority: Blocker Fix For: 1.1-beta-3 Attachments: plugin-test.zip There's a bug in m1.1 that doesn't exist in m1.0.X When you define a variable in a custom goal for a project, this last one is available for others projects. It cause a problem for example if you use several multiproject:goal. We have this problem in maven-plugins when we launch the goal plugins:test-all If a plugin use the multiproject with a new goal (j:set:var=goal ...), than the reactor use this goal for all plugins after it. I attached a test case for the multiproject plugin. It works with maven 1.0.2 but not with maven 1.1-beta2. -- 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: (CONTINUUM-696) Bunch of stack traces when company logo is wrong and relative
Bunch of stack traces when company logo is wrong and relative - Key: CONTINUUM-696 URL: http://jira.codehaus.org/browse/CONTINUUM-696 Project: Continuum Type: Improvement Components: Web interface Versions: 1.0.3 Reporter: Carlos Sanchez Priority: Minor When setting company logo to s continuum hits http://localhost:8080/continuum/servlet/s, causing a bunch of stack traces It'd be better to have the continuum servlet explicitly setup in the web.xml and turn of the auto mapping of servlets 14:57:22.468 WARN!! Exception for /continuum/servlet/s javax.servlet.UnavailableException: java.lang.ClassNotFoundException: s at org.mortbay.jetty.servlet.Invoker.service(Invoker.java:154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1768) at org.apache.maven.continuum.web.pipeline.valve.ContinuumViewContextPopulatorValve.populateViewContext(ContinuumViewContextPopulatorValve.java:48) at org.codehaus.plexus.summit.pipeline.valve.CreateViewContextValve.invoke(CreateViewContextValve.java:50) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) 2006-05-12 14:57:26,875 [SocketListener0-0] WARN VelocityComponent - org.apache.velocity.runtime.exception.ReferenceException: reference : template = screens/Error.vm [line 10,column 8] : $stackTrace is not a valid reference. 2006-05-12 14:57:38,875 [SocketListener0-0] INFO Action:login - Trying to log in 'carlos'. username: carlos 14:57:39.468 WARN!! Exception for /continuum/servlet/s javax.servlet.UnavailableException: java.lang.ClassNotFoundException: s at org.mortbay.jetty.servlet.Invoker.service(Invoker.java:154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at
[jira] Commented: (MAVENUPLOAD-894) Updating jmdns to 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-894?page=comments#action_65315 ] Keith R. Bennett commented on MAVENUPLOAD-894: -- By the way, I did my best with the pom.xml file. Currently it contains: project modelVersion4.0.0/modelVersion groupIdjmdns/groupId artifactIdjmdns/artifactId version1.0/version /project Feel free to improve on it. - Keith Bennett (original poster of upload) Updating jmdns to 1.0 - Key: MAVENUPLOAD-894 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-894 Project: maven-upload-requests Type: Task Reporter: Keith R. Bennett Attachments: jmdns-for-maven-repo.jar The repository's latest existing version is 0.2; this is version 1.0. I am new to Maven 2.0, and am using version 1.0 of this jar file in a project, so I'd like it to be in the repository. I hope I've done everything right, I'm sorry in advance if not. The URL above is on a private site of mine that has nothing to do with the jmdns project -- it's just a site I was able to use for the purpose of making it accessible to you. If the URL is intended to be used by users, then it will not work, as I will delete the file sometime soon. I am attaching the same file as well, in case you have any problem getting it via the URL. The URL at sourceforge for downloading this product is http://sourceforge.net/project/showfiles.php?group_id=93852package_id=99663release_id=365488. I have included only the jar file from the distribution, not the source, docs, or sample files. - Keith Bennett -- 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: (MWAR-12) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MWAR-12?page=comments#action_65316 ] Julian Wood commented on MWAR-12: - Hmm, I just installed plexus-utils-1.3-SNAPSHOT from svn, replaced my plexus-utils-1.1 in M2_HOME/core, added it as a dependency, configured the maven war plugin as per Brian Topping's message above, built maven-war-plugin 2.0-beta-3-SNAPSHOT from svn, added a build.properties file in src/main/webapp/WEB-INF/classes/build.properties and finally made a package, but no filtering happened in any xml files (no errors either). Did I miss something? This is maven 2.0.4. Thanks, J 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: John Tolentino Fix For: 2.0 Attachments: AbstractWarMojo.patch, MWAR-12-maven-war-plugin.patch, MWAR-12.patch, ResourcesMojo.patch, test.zip Original Estimate: 15 minutes Time Spent: 12 hours Remaining: 0 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
