[jira] Commented: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81378 ] Damien Lecan commented on MCHANGES-58: -- ? As I see that Maven SCM project manages a lot of SCM's, may I conclude that Maven project uses CVS, Subversion, Perforce, Clearcase and VSS all together ? I understand your point of view, but I am a disappointed by a such answer. Building a patch for this feature is a huge work, especilly because many business rules could be shared between Jira and BZ implementations (many of AbstractJiraDownloader methods could be used for BZ too). It is not possible to do refactoring with patch, they are too hard to maintain. Add ability to manage Bugzilla instead of JIRA -- Key: MCHANGES-58 URL: http://jira.codehaus.org/browse/MCHANGES-58 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Damien Lecan It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MECLIPSE-199) patch for incorrect documentation
patch for incorrect documentation - Key: MECLIPSE-199 URL: http://jira.codehaus.org/browse/MECLIPSE-199 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Andreas Wuest Attachments: patch.txt patch for a documentation typo (missing / in a closing xml tag) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1022) Validaiton Email not working
Validaiton Email not working Key: CONTINUUM-1022 URL: http://jira.codehaus.org/browse/CONTINUUM-1022 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Franz Allan Valencia See The validation email sent when you register is not working. -- 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: (MCHANGES-47) Add support for multiple issue and due-to tags in changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-47?page=all ] Julien HENRY updated MCHANGES-47: - Attachment: maven-change-multiple-issue.patch This patch simply add suport for multiple issues (comma separated). Add support for multiple issue and due-to tags in changes.xml - Key: MCHANGES-47 URL: http://jira.codehaus.org/browse/MCHANGES-47 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Dennis Lundberg Attachments: maven-change-multiple-issue.patch, MCHANGES-47-maven-changes-plugin.patch This is to improve the compatibility with changes.xml files used by the Maven 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for more info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1023) The cancel button of both login and registration page does not work
The cancel button of both login and registration page does not work --- Key: CONTINUUM-1023 URL: http://jira.codehaus.org/browse/CONTINUUM-1023 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See Priority: Minor The other pages rely on the submitCancel tag of continuum, but since the login and registration are taken from plexus-security, they cannot use the submitCancel tag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=comments#action_81381 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-1022: The validation mail now uses JNDI to locate the mail service. However the codes at the trunk isn't configured yet to make jetty:run work. Validaiton Email not working Key: CONTINUUM-1022 URL: http://jira.codehaus.org/browse/CONTINUUM-1022 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Franz Allan Valencia See The validation email sent when you register is not working. -- 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: (MDOAP-5) doap plugin not in central, but listed on the plugins by category page
doap plugin not in central, but listed on the plugins by category page Key: MDOAP-5 URL: http://jira.codehaus.org/browse/MDOAP-5 Project: Maven 2.x DOAP Plugin Issue Type: Bug Environment: Maven 2 Reporter: Jan Dockx Priority: Blocker [EMAIL PROTECTED]:helloWorldmvn -N doap:generate [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'doap'. [INFO] artifact org.apache.maven.plugins:maven-doap-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-doap-plugin' does not exist or no valid version could be found [INFO] The plugin is listed on the Maven 2 Plugins by category page, but cannot be found in central -- 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-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=comments#action_81382
]
Napoleon Esmundo C. Ramirez commented on CONTINUUM-1022:
The validation mail now uses JNDI to locate the mail service. However the
codes at the trunk isn't configured yet to make jetty:run work.
To configure continuum to use the JNDI mail resource, I added the following in
continuum-webapp/src/jetty-env.xml:
New id=validation_mail class=org.mortbay.jetty.plus.naming.Resource
Argmail/Session/Arg
Arg
New class=org.mortbay.naming.factories.MailSessionReference
Set name=userusername/Set
Set name=passwordpassword/Set
Set name=properties
New class=java.util.Properties
Put name=mail.smtp.hostsmtp.host.org/Put
Put name=mail.from[EMAIL PROTECTED]/Put
Put name=mail.senderNameContinuum/Put
Put name=mail.debugtrue/Put
/New
/Set
/New
/Arg
/New
I also added the following in continuum-webapp/src/main/webapp/WEB-INF/web.xml:
resource-ref
res-ref-namemail/Session/res-ref-name
res-typejavax.mail.Session/res-type
res-authContainer/res-auth
/resource-ref
Which led me to another problem described by the following stack trace:
DEBUG: JavaMail version 1.4ea
DEBUG: java.io.FileNotFoundException:
/usr/share/jdk1.5.0_06/jre/lib/javamail.providers (No such file or directory)
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.providers
DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
DEBUG: Tables of loaded providers
DEBUG: Providers Listed By Class Name:
{com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun
Microsystems, Inc],
com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun
Microsystems, Inc],
com.sun.mail.imap.IMAPSSLStore=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun
Microsystems, Inc],
com.sun.mail.pop3.POP3SSLStore=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun
Microsystems, Inc],
com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc],
com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun
Microsystems, Inc]}
DEBUG: Providers Listed By Protocol:
{imaps=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun
Microsystems, Inc],
imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc],
smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun
Microsystems, Inc],
pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun
Microsystems, Inc],
pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun
Microsystems, Inc],
smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun
Microsystems, Inc]}
DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.address.map
DEBUG: java.io.FileNotFoundException:
/usr/share/jdk1.5.0_06/jre/lib/javamail.address.map (No such file or directory)
2006-11-29 16:26:29,745 [btpool0-4] ERROR Mailer -
Unable to generate email for template
'org/codehaus/plexus/security/ui/web/mail/template/newAccountValidationEmail.vm':
javax.mail.Session
java.lang.ClassCastException: javax.mail.Session
at
org.codehaus.plexus.mailsender.javamail.JndiJavamailMailSender.getSession(JndiJavamailMailSender.java:52)
at
org.codehaus.plexus.mailsender.javamail.AbstractJavamailMailSender.send(AbstractJavamailMailSender.java:62)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendMessage(Mailer.java:237)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendVelocityEmail(Mailer.java:165)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendAccountValidationEmail(Mailer.java:108)
at
org.codehaus.plexus.security.ui.web.action.RegisterAction.register(RegisterAction.java:183)
Any ideas about this? Or did I miss on some configuration?
Validaiton Email not working
Key: CONTINUUM-1022
URL: http://jira.codehaus.org/browse/CONTINUUM-1022
Project: Continuum
Issue Type: Bug
Components: Web interface
Reporter: Franz Allan Valencia See
The validation email sent when you register is not working.
--
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: (CONTINUUM-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=all ] Napoleon Esmundo C. Ramirez updated CONTINUUM-1022: --- Comment: was deleted Validaiton Email not working Key: CONTINUUM-1022 URL: http://jira.codehaus.org/browse/CONTINUUM-1022 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Franz Allan Valencia See The validation email sent when you register is not working. -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81385 ] Mark Hobson commented on MCHANGES-58: - There was a thread a while ago on maven-dev regarding sharing Bugzilla communication code with the Eclipse Mylar project, which would make this a lot easier. Add ability to manage Bugzilla instead of JIRA -- Key: MCHANGES-58 URL: http://jira.codehaus.org/browse/MCHANGES-58 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Damien Lecan It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81392 ] Mark Hobson commented on MCHANGES-58: - The abstract issue API to use would be Mylar's, since a lot of work has been put into that and it's various implementations - check the Mylar CVS. I seem to remember the above thread ending with requirement to build Mylar with Maven, so it's artifacts can be used by Maven components. I meant to raise an issue with Mylar as Mik suggested.. Add ability to manage Bugzilla instead of JIRA -- Key: MCHANGES-58 URL: http://jira.codehaus.org/browse/MCHANGES-58 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Damien Lecan It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81397 ] Mark Hobson commented on MCHANGES-58: - Finally got around to it ;) https://bugs.eclipse.org/bugs/show_bug.cgi?id=166203 Add ability to manage Bugzilla instead of JIRA -- Key: MCHANGES-58 URL: http://jira.codehaus.org/browse/MCHANGES-58 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Damien Lecan It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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-2344) Support for functional/integration tests is *way* too limited
[ http://jira.codehaus.org/browse/MNG-2344?page=comments#action_81402 ] David Svanberg commented on MNG-2344: - Even when offline set to true in settings.xml: [INFO] artifact org.apache.maven.plugins:maven-scm-plugin: checking for updates from central [WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-scm-plugin' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted Support for functional/integration tests is *way* too limited - Key: MNG-2344 URL: http://jira.codehaus.org/browse/MNG-2344 Project: Maven 2 Issue Type: Improvement Components: Design, Patterns Best Practices Affects Versions: 2.0.4 Reporter: Craig McClanahan Assigned To: Brett Porter I am a recent convert to Maven2 ... after listening to advice from many people I respect (including Wendy Smoak and Brett Porter) we are in the midst of migrating the build environment for the Shale Framework (part of the http://struts.apache.org community) over to Maven2. For the most part, this has been all goodness ... the dependency management, and the hierarchical dependency resolution, make for a dramatic simplification in the overall environment. That being said, there is one major area where I'm really disappointed ... and it's almost enough to tip my personal scale back towards hand crafted Ant builds. It relates to support for testing of web applications. My plan is to leverage the Maven2 archetype capability to make it very easy to build starter web applications that are already set up to use Shale. To encourage best practices, I want to set up out of the box testing for the application to be developed. As we all know, this kind of testing can be divided into at least two major categories ... unit tests of the individual server side classes, and functiona/integration tests that want to deploy the application first, then interact with it (using a framework such as HttpUnit or HtmlUnit) to verify that the rendered results match expectations. In my previous Ant-based build world, I had two different targets (test and systest) that could exercise the two different kinds of tests. Much to my surprise, it seems to be difficult-to-impossible to set up a similar sceanrio (two kinds of tests) in the same project when you're using Maven2. I could live with this (although I'd still grumble a lot) if it was just an issue of the sample apps that we ship with Shale. I can teach committers to run integration tests from a separate module before doing SVN commits. But that is *not* what I want to present to potential developers that will build webapps based on a Shale-provided archtetype. And it shouldn't be what *you* want for Maven2 users in general either ... support for both unit tests and integration tests seems like a mission critical feature that is not adequately supported at present. -- 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-2433) Maven looks for snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2433?page=comments#action_81404 ] David Svanberg commented on MNG-2433: - Does fail also when offline set to true in settings.xml (which is kind of critical for us behind firewalls...): [INFO] artifact org.apache.maven.plugins:maven-scm-plugin: checking for updates from central [WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-scm-plugin' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted Maven looks for snapshots in offline mode - Key: MNG-2433 URL: http://jira.codehaus.org/browse/MNG-2433 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Priority: Critical Fix For: 2.0.6 It seems that sometimes Maven2 is looking for snapshots in offline mode (this happens for example in the Cocoon project). here is an output that might help: :\dev\workspace\cocoon-2.2\core\cocoon-webappmvn -o -Dmaven.test.skip=true coc oon:deploy [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your loca l repository will be inaccessible. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'cocoon'. [INFO] org.apache.maven.plugins: checking for updates from snapshots [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo [INFO] org.codehaus.mojo: checking for updates from snapshots [INFO] org.codehaus.mojo: checking for updates from mortbay-repo [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from snapshots [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from mortbay-repo [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from central [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: checkin g for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from snapshots [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from mortbay-repo [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from central [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for updat es from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from mortbay-repo [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from s napshots [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from m ortbay-repo [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from c entral [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from a pache.snapshot [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from a pache-cvs [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates from a pache.snapshots -- 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-2682) Global Settings are ignored
Global Settings are ignored
---
Key: MNG-2682
URL: http://jira.codehaus.org/browse/MNG-2682
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 2.0.4
Environment: Win XP, JDK1.6rc, m2eclipse 0.0.10 (trunk), eclipse 3.2.1
Reporter: Ralf Stoffels
With the CLI both the global settings in $M2_HOME/conf/settings.xml and the
user settings in ${user.dir}/.m2/settings.xml are used.
With the Embedder used by M2Eclipse only the user settings are used.
So this issue is different from MNG-1884
I hope this is fixed in 2.0.5 (- MNG-1069).
--
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-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=comments#action_81423 ] Carlos Sanchez commented on MAVENUPLOAD-1256: - You can use org.statsvn or net.sf.statsvn, but not just statsvn Please upload the library statsvn-0.2.0 to the repo --- Key: MAVENUPLOAD-1256 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Attachments: statsvn-0.2.0-bundle.jar Hi This is a pure library (not a plugin) so I believe that this mechanism is the correct one to have it uploaded on M1 and M2 repository? We're working on an m2 repo SF for qalab and the rest but in the meantime could you upload this? Many thanks Benoit -- 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-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=comments#action_81429 ] Benoit Xhenseval commented on MAVENUPLOAD-1256: --- Ooops, thanks to you, we realised that our project.xml did not contain any groupId and it seems to be picked up from the package name somehow. This is now correctec Thanks for pointing this to us. Benoit Please upload the library statsvn-0.2.0 to the repo --- Key: MAVENUPLOAD-1256 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar Hi This is a pure library (not a plugin) so I believe that this mechanism is the correct one to have it uploaded on M1 and M2 repository? We're working on an m2 repo SF for qalab and the rest but in the meantime could you upload this? Many thanks Benoit -- 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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=all ] Benoit Xhenseval updated MAVENUPLOAD-1256: -- Attachment: statsvn-0.2.0-bundle.jar Please ignore the other one. Please upload the library statsvn-0.2.0 to the repo --- Key: MAVENUPLOAD-1256 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar Hi This is a pure library (not a plugin) so I believe that this mechanism is the correct one to have it uploaded on M1 and M2 repository? We're working on an m2 repo SF for qalab and the rest but in the meantime could you upload this? Many thanks Benoit -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81431 ] Dennis Lundberg commented on MCHANGES-58: - Damien, The purpose of my comment was to set your expectations at a reasonable level. If it came across in any other way I apologize. The knowledge of Bugzilla among the Maven devs is probably lower than it is for JIRA, so we would probably need help from the some Bugilla power-users in the community to pull this off. The comparison to Maven SCM is both a good and a bad one. Maven SCM does have the abstraction layer that is need for this to work in a smooth way, and that Mark talks about. The discussions about this on the dev-list sort of ended in, well not much. If the effort to create such an interface is pushed through I would certainly be interested in using it in this plugin. However the issue tracking system is used for reporting only in Maven, while SCM is used for releasing stuff. So it has, and should have, a higher priority. Reporting won't do you much good if you can't build or release your project. Add ability to manage Bugzilla instead of JIRA -- Key: MCHANGES-58 URL: http://jira.codehaus.org/browse/MCHANGES-58 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Damien Lecan It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=all ] Carlos Sanchez closed MAVENUPLOAD-1256. --- Assignee: Carlos Sanchez Resolution: Fixed Please upload the library statsvn-0.2.0 to the repo --- Key: MAVENUPLOAD-1256 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Assigned To: Carlos Sanchez Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar Hi This is a pure library (not a plugin) so I believe that this mechanism is the correct one to have it uploaded on M1 and M2 repository? We're working on an m2 repo SF for qalab and the rest but in the meantime could you upload this? Many thanks Benoit -- 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: (MPJDIFF-10) jdiff doclet fails with jdk 1.4
[ http://jira.codehaus.org/browse/MPJDIFF-10?page=all ]
Arnaud Heritier updated MPJDIFF-10:
---
Attachment: MPJDIFF-10.patch
add the xml-apis which is required in the jdk 1.4
jdiff doclet fails with jdk 1.4
---
Key: MPJDIFF-10
URL: http://jira.codehaus.org/browse/MPJDIFF-10
Project: maven-jdiff-plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Lukas Theussl
Fix For: 1.5.1
Attachments: MPJDIFF-10.patch
Running jdiff with jdk 1.4.2_10 gives the following exception:
{noformat}
[javadoc] JDiff: doclet started ...
[javadoc] javadoc: In doclet class jdiff.JDiff, method start has thrown
an exception java.lang.reflect.InvocationTargetException
[javadoc] java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2
{noformat}
The build succeeds but there are no files generated. Note that it only
happens with the current svn version of the plugin, it works when downgrading
to the released maven-jdiff-plugin-1.5 . It also works with java 5 since the
missing class is contained in the rt.jar. I fixed it by adding a dependency
to xml-apis, but I think that should not be necessary?
--
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: (MSUREFIRE-57) Forking documentation improvement to help with class loader constrainst issues
[ http://jira.codehaus.org/browse/MSUREFIRE-57?page=comments#action_81455 ] Tanver Afzal commented on MSUREFIRE-57: --- Hi I am still confused where to set the forking. on the server side or in Eclipse some where. I appreciate your help. Regards Tanver Forking documentation improvement to help with class loader constrainst issues -- Key: MSUREFIRE-57 URL: http://jira.codehaus.org/browse/MSUREFIRE-57 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.1.3 Environment: maven 2.0.2 Reporter: Ben Gidley Assigned To: Brett Porter Priority: Minor Fix For: 2.2 Attachments: maven-surefire-plugin-374325.patch With (for example) JAXB2 forking surefire causes a java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class This is because by default when forking an Isolated class loader is used. this can be resovled by turning child delegation on. The documentation does not mention this and should be improved. -- 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: (MAVENUPLOAD-1257) Please upload EZMorph-0.9.1
Please upload EZMorph-0.9.1 --- Key: MAVENUPLOAD-1257 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1257 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray EZMorph is simple java library for transforming an Object to another Object. This release includes a minor bugfix that is in high demand for the next release of json-lib. -- 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-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ http://jira.codehaus.org/browse/MNG-2553?page=comments#action_81460 ] Chandra Patni commented on MNG-2553: We also have a same repository for all projects. However, we don't want to specify URL in pom.xml. For instance we have some users on Apple/Linux who use file server using a different method. distributionManagement repository idmyrepository/id urlfile://X://url /repository /distributionManagement Maven Local Settings Model should allow configuration of distributions (distributionManagement) --- Key: MNG-2553 URL: http://jira.codehaus.org/browse/MNG-2553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.4 Reporter: Jimisola Laursen There is a good use case where this would be very useful. E.g. I develop a plugin in mojo-sandbox and want to test it in an environment other than the one that I developed it on (e.g. a computer at work). I check out the plugin to this, build and then want to deploy to another repository (e..g a company's internal repository). I don't want to fiddle with the pom.xml of the plugin, just refer to a profile in settings.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] Commented: (MNG-2546) Allow plugin executions in the super-init phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_81461 ] Brian Fox commented on MNG-2546: This is exactly what the dependency plugin needs to handle defacto dependencies defined in the config for copy and unpack that may be in the same reactor. Allow plugin executions in the super-init phase before reactor sorting of modules build order --- Key: MNG-2546 URL: http://jira.codehaus.org/browse/MNG-2546 Project: Maven 2 Issue Type: Improvement Components: Reactor and workspace Affects Versions: 2.0.4 Reporter: Binyan Attachments: MNG-2546-maven-core.patch As seen here, http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. I also have the need to bind my maven-pde-plugin to a phase before the reactor sorting of project build order happens. My plugin is being developed to build eclipse plugins, features, fragments, update sites and products. Right now I can build plugins and features. However the order has to constantly be managed by the user taking information from the eclipse descriptors and adding it to the pom file. For plugin projects I can bind to a phase before the compile phase and dynamically analyze the eclipse plugin descriptors and add the necessary dependencies/resources to the MavenProject instance and all is well. For feature projects, I also can dynamically analyze the eclipse feature descriptor and add the necessary resources to the MavenProject instance. However, features depend on other plugins, fragments and features. While I can dynamicaly add the plugins, fragments and features to the MavenProject as dependencies they are not taken into context as the reactor has already computed the sorting order. What would be perfect is if there was a super-init phase that plugins could bind to and be executed in before the normal declared lifecycle happened. Therefore no matter what the lifecycle was, the super-init phase would be available. Then plugins could do things like augmenting the super-pom with build #'s/identifiers, dependencies, dynamic projects, etc all before maven gets going. That would solve the problem myself and others have as well as be 100% backwards compatible. This super-init phase (please pick a better name) would e available to reactor and non-reactor builds. A more specific fix would be to allow plugins to ask the reactor to reevaluate the build order. -- 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: (MECLIPSE-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=comments#action_81468 ] Andreas Guther commented on MECLIPSE-107: - Managed dependencies need to be taken into account, but they need to be overwritten by the component pom in those cases where the component pom needs to specify the version against the definition in the parent pom. This is the behavior in Maven and must be the same in the Eclipse plugin. I have the scenario where we manage our version in a parent pom with the dependencyManagement section. Usually our components do not specify the version which then is taken as specified in the parent pom. Just today I had the situation where I needed to overwrite the version in only one component for test reasons. Getting the fix is highly appreciated. Dependency Version Incorrectly Taken from DependencyManagement -- Key: MECLIPSE-107 URL: http://jira.codehaus.org/browse/MECLIPSE-107 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: dependency resolution Affects Versions: 2.2 Reporter: Stephen Duncan Jr Priority: Critical Attachments: dmtest.zip The version used when generating .classpath is taken from dependencyManagement even though the child pom sets the dependency version, which should override what is in dependencyManagement. This is a regression from the correct behaviour in 2.1. The attached project demonstrates the problem. The .classpath file generated for the child project should specify log4j-1.2.13, but instead specifies 1.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: (MNG-2340) Incorrect dependency version downloaded
[ http://jira.codehaus.org/browse/MNG-2340?page=comments#action_81469 ]
Andreas Guther commented on MNG-2340:
-
I was not aware that this is also a problem in the mvn site generating plug-in.
Does an entry for this problem exist for the maven site plug-in as well?
Incorrect dependency version downloaded
---
Key: MNG-2340
URL: http://jira.codehaus.org/browse/MNG-2340
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 2.0.4
Reporter: Adrian
Priority: Critical
Fix For: 2.1
Attachments: MNGECLIPSE-131.zip
I have a parent pom with a dependency management section specifying the
version of an artifact to use. In the child project, I override this version.
The maven plugin ignores the overriding version and downloads the version
specified by the parent pom.
For example, in the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version1.4.3/version
/dependency
{code}
in the project pom, inheriting the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version2.0/version
/dependency
{code}
The maven eclipse plugin downloads version 1.4.3 for my 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] Updated: (CONTINUUM-1023) The cancel button of both login and registration page does not work
[ http://jira.codehaus.org/browse/CONTINUUM-1023?page=all ] Franz Allan Valencia See updated CONTINUUM-1023: Attachment: CONTINUUM-1023-continuum-webapp.patch complementary to PLX-303, CONTINUUM-1023-continuum-webapp.patch redirects the user to the project groups page (groupSummary) when cancel is pressed instead of to the login page. The cancel button of both login and registration page does not work --- Key: CONTINUUM-1023 URL: http://jira.codehaus.org/browse/CONTINUUM-1023 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See Priority: Minor Attachments: CONTINUUM-1023-continuum-webapp.patch The other pages rely on the submitCancel tag of continuum, but since the login and registration are taken from plexus-security, they cannot use the submitCancel tag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
