[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/ > > 4.0.0 > xerces > xercesImpl > 2.8.0 > -- 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 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 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] Closed: (SCM-197) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/SCM-197?page=all ] Emmanuel Venisse closed SCM-197: Assign To: Emmanuel Venisse Resolution: Cannot Reproduce release plugin execute this method : SvnTagBranchUtils.resolveUrl( "http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1";, "http://sv1.tus.stchome.com/viewvc/stc/products/dsms/build-tags";, SvnTagBranchUtils.SVN_TAGS, "t5" ); I guess you used http://sv1.tus.stchome.com/viewvc/stc/products/dsms/build-tags as tagBase and t5 as tag name The result is http://sv1.tus.stchome.com/viewvc/stc/products/dsms/build-tags/t5 > 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:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1 > > after the prepare, they end up like this: > > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > 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: (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 url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own 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 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 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] Commented: (SCM-195) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/SCM-195?page=comments#action_65273 ] Arik Kfir commented on SCM-195: --- emmanuel: when the release plugin writes the modified pom back into svn (with the released version, etc), it also writes a wrong scm url (under the tag). The url that's written is the one of the parent pom, without the module's name appended to the "/trunk" - *even though* it was properly specified there before the release... when the child pom has no tag, it works well. > 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 url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own 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 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 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-2292) Properties have no scope
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}
...
test
parent
1
${my.url}
...
child
...
http://parent
...
{noformat}
and a child POM with:
{noformat}
...
test
parent
1
${my.url}
...
http://child
...
{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] 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}
> ...
> test
> parent
> 1
> ${my.url}
> ...
>
> child
>
> ...
>
> http://parent
>
> ...
> {noformat}
> and a child POM with:
> {noformat}
> ...
>
> test
> parent
> 1
>
> ${my.url}
> ...
>
> http://child
>
> ...
> {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-191) Difficult to disable cvs compress mode using system property -Dmaven.scm.cvs.use_compression=false and cvs-settings.xml property file
[ http://jira.codehaus.org/browse/SCM-191?page=all ]
Emmanuel Venisse updated SCM-191:
-
Assign To: Emmanuel Venisse
Fix Version: 1.0
> Difficult to disable cvs compress mode using system property
> -Dmaven.scm.cvs.use_compression=false and cvs-settings.xml property file
> -
>
> Key: SCM-191
> URL: http://jira.codehaus.org/browse/SCM-191
> Project: Maven SCM
> Type: Bug
> Components: maven-scm-provider-cvs
> Versions: 1.0-beta-3
> Reporter: Thibaut CAZENAVE
> Assignee: Emmanuel Venisse
> Priority: Minor
> Fix For: 1.0
>
>
> 1st bug :
> The system property -Dmaven.scm.cvs.use_compression=false doesn't work if
> getSettings() method of CvsUtil class doesn't find the cvs-settings.xml file.
> In this case, this method return a new Settings() for which
> compressionLevel=3 (constructor of Settings class).
> In method getBaseCommand() of CvsCommandUtils class
> (org.apache.maven.scm.provider.cvslib.command), since
> settings.getCompressionLevel() = 3, if condition is true and then it adds
> -z3 to CommandLine cl.
> 2nd bug :
> If you set 0 in cvs-settings.xml without
> setting system property -Dmaven.scm.cvs.use_compression=false, -z3 cvs
> compression is used.
> In method getBaseCommand(), since settings.getCompressionLevel() > 0, if
> condition is false and then we go in else if condition (!System.getProperty(
> "maven.scm.cvs.use_compression", "true" ).equals( "false" )) which happens to
> be true so it adds -z3 to CommandLine cl.
> Patch proposed :
> Replace in CvsCommandUtils getBaseCommand() method :
> -
> if ( settings.getCompressionLevel() > 0 )
> {
> cl.createArgument().setValue( "-z" +
> settings.getCompressionLevel() );
> }
> else if ( !System.getProperty( "maven.scm.cvs.use_compression",
> "true" ).equals( "false" ) )
> {
> cl.createArgument().setValue( "-z3" );
> }
> -
> with :
> -
> if (settings.getCompressionLevel() > 0 &&
> System.getProperty("maven.scm.cvs.use_compression", "true").equals("true"))
> cl.createArgument().setValue("-z" + settings.getCompressionLevel());
>
> Tibo
--
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] Commented: (MNG-426) Create "maxmem" setting for all plugins to refer to
[ http://jira.codehaus.org/browse/MNG-426?page=comments#action_65279 ] David Hoffer commented on MNG-426: -- I would think there would be a centralized value that gets used as the default, but if a pom specifies a value it should be used instead. > Create "maxmem" setting for all plugins to refer to > --- > > Key: MNG-426 > URL: http://jira.codehaus.org/browse/MNG-426 > Project: Maven 2 > Type: New Feature > Reporter: Jeff Jensen > Fix For: 2.1 > > > Create a centralized setting for the max memory setting that all plugins > launching a new JVM to respect/use. Then, update the plugins to use it. > With the time spent repeatedly running, researching, and configuring some > plugins to not have "Out of Memory" errors, it now seems silly not to add > this kind of feature in the revolutionary vs evolutionary Maven 2! :-) > I would prefer a setting at the core Maven level, e.g. > maven.plugins.maxheap=1024m, that the plugins "magically" used, vs having to > repeatedly specify the same one to each plugin that needs it. -- 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: (CONTINUUM-694) Add proxy configuration support for notifiers
Add proxy configuration support for notifiers
-
Key: CONTINUUM-694
URL: http://jira.codehaus.org/browse/CONTINUUM-694
Project: Continuum
Type: Improvement
Components: MSN Notifier, Mail Notifier, Jabber Notifier, IRC Notifier, AOL
Notifier
Versions: 1.0.3
Reporter: Anatol Pomozov
I would like to use Continuum for project, but I have problem - all ports are
proxied. Not only HTTP but also mail and all others.
That is why I cant use mailnotifier. It breaks with error listed below. As I
said timeout occures due to port is closed by proxy. I check it only for mail
notifier but I beleive that it is related to all other notifiers.
{{
72414 [Thread-2] ERROR
org.apache.maven.continuum.notification.ContinuumNotificationDispatcher -
Error while trying to use the mailnotifier.
org.codehaus.plexus.notification.NotificationException: Exception while sending
message.
at
org.apache.maven.continuum.notification.mail.MailContinuumNotifier.sendMessage(MailContinuumNotifier.java:403)
at
org.apache.maven.continuum.notification.mail.MailContinuumNotifier.buildComplete(MailContinuumNotifier.java:307)
at
org.apache.maven.continuum.notification.mail.MailContinuumNotifier.sendNotification(MailContinuumNotifier.java:202)
at
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:173)
at
org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:96)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:378)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.codehaus.plexus.mailsender.MailSenderException: Error while
sending mail.
at
org.codehaus.plexus.mailsender.javamail.JavamailMailSender.send(JavamailMailSender.java:217)
at
org.apache.maven.continuum.notification.mail.MailContinuumNotifier.sendMessage(MailContinuumNotifier.java:399)
... 8 more
Caused by: javax.mail.MessagingException: Could not connect to SMTP host:
smtp.gmail.com, port: 465;
nested exception is:
java.net.ConnectException: Connection timed out: connect
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1213)
at
com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:311)
at javax.mail.Service.connect(Service.java:255)
at javax.mail.Service.connect(Service.java:134)
at javax.mail.Service.connect(Service.java:86)
at com.sun.mail.smtp.SMTPTransport.connect(SMTPTransport.java:144)
at javax.mail.Transport.send0(Transport.java:150)
at javax.mail.Transport.send(Transport.java:80)
at
org.codehaus.plexus.mailsender.javamail.JavamailMailSender.send(JavamailMailSender.java:213)
... 9 more
}}
--
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: and for some: 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: bla ...BlaInterface ... 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) with only 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. > with only 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 > > ../pom.xml > > 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 . -- 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-1931) add a reportingManagement section
[ http://jira.codehaus.org/browse/MNG-1931?page=comments#action_65287 ]
Denis Cabasson commented on MNG-1931:
-
In relation with MNG-1855:
when using a report plugin needing a dependency (
checkstyle, set as in:
http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html, ont sure
this example is working, but no time to test it, sorry.)
extra jars need to be added to classpath. It's not possible right now, cause
report part has no dependencies child.
Maybe plan to add this to reportManagement?
> add a reportingManagement section
> -
>
> Key: MNG-1931
> URL: http://jira.codehaus.org/browse/MNG-1931
> Project: Maven 2
> Type: Bug
> Components: POM, Design, Patterns & Best Practices
> Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
> Reporter: Indrajit Raychaudhuri
> Fix For: 2.1
>
>
> Consider the following POM:
> {code:xml}
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
>
>
> {code}
> {{mvn site:site}} doesn't honor the javadoc configuration specified in the
> {{}} section.
> However, {{mvn javadoc:javadoc}} honors them.
> This is true not just for javadoc but other plugins like checkstyle as well.
> I guess, the {{}} section doesn't use the {{}}
> section at all.
--
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-197) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/SCM-197?page=comments#action_65288 ] Brian Fox commented on SCM-197: --- This is my tag base http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags but isn't the supposed to be for human use and not scm? Seems like there needs to be a and then that is used to translate the url, not the tagBase. > 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:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1 > > after the prepare, they end up like this: > > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > 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] Created: (MNG-2294) If /project/parent/relativePath fails to resolve, no error is reported.
If /project/parent/relativePath fails to resolve, no error is reported. --- Key: MNG-2294 URL: http://jira.codehaus.org/browse/MNG-2294 Project: Maven 2 Type: Bug Versions: 2.0.4 Reporter: David Smiley If I have a bad /project/parent/relativePath specified, maven does not tell me. Instead the build proceeds as if there is no parent. The build should fail if the parent can't be resolved. -- 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] Créée: (MIDEA-55) Allow filtering downlo adSources and downloadJavadocs with the groupid
Allow filtering downloadSources and downloadJavadocs with the groupid - Key: MIDEA-55 URL: http://jira.codehaus.org/browse/MIDEA-55 Project: Maven 2.x Idea Plugin Type: Improvement Versions: 2.0 Reporter: Eric SULTAN Priority: Minor Attachments: idea-filter.patch It could be useful to have a filtering on the attach source and javadoc. -- 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:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1 > > after the prepare, they end up like this: > > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > 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:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1 > > after the prepare, they end up like this: > > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > 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:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1 > > http://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1 > > after the prepare, they end up like this: > > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > scm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5 > > 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: > > > > > and for some: > > > > > 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: > > bla > ...BlaInterface >... > > 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: > > > > > and for some: > > > > > 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: > > bla > ...BlaInterface >... > > 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: > > > > > and for some: > > > > > 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: > > bla > ...BlaInterface >... > > 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: (SCM-200) Problem
Problem
Key: SCM-200
URL: http://jira.codehaus.org/browse/SCM-200
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-cvs
Versions: 1.0-beta-3
Environment: Solaris, MAven 2.0.4, Continuum 1.0.3
Reporter: Alex Mayorga Adame
I've been experiencing problems on initial checkout of a Maven 2 project under
Continuum 1.0.3 when using following syntax of SCM:
{{scm:cvs:pserver:[EMAIL PROTECTED]:port:repository:module}}
Error in Continuum is as follows:
{{Provider message: The cvs command failed.}}
{{Command output:}}
{{--}}
{{port/repository: no such repository}}
{{cvs checkout: authorization failed: server host rejected access to
port/repository for user user}}
{{cvs checkout: used empty password; try "cvs login" with a real password}}
{{---}}
Looks like the provider is preppending the port to the repository and trying a
wrong CVS command.
--
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/ > > 4.0.0 > xerces > xercesImpl > 2.8.0 > -- 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=227285&view=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 ( 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 org.mortba
[jira] Created: (MAVENUPLOAD-894) Updating jmdns to 1.0
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=93852&package_id=99663&release_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: (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: 4.0.0 jmdns jmdns 1.0 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=93852&package_id=99663&release_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
[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_65318 ] Jerome Lacoste commented on MNG-2293: - In case someone takes the patch. another thing that was missing was that the serializer lacked the 2-3 lines of code required to get the element in the section of the . See maven-plugin-descriptor module. Not sure if that is sufficient to fix completely the issue. > 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: > > > > > and for some: > > > > > 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: > > bla > ...BlaInterface >... > > 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
