[jira] Reopened: (MIDEA-74) Plugin doesn't handle correctly WebModule dependency scope
[ http://jira.codehaus.org/browse/MIDEA-74?page=all ] Remy Coqueugniot reopened MIDEA-74: --- Indeed, this issue is a duplicated one, Xcuse me for that :-' But, the bug is not correctly fixed in the last SVN version: 1- only Artifact.SCOPE_PROVIDED is tested. When a dependency with a "test" scope is included for a webmofule, this should not be packaged. A best way is to define a list a acceptable scope to be include in the packaging process. 2- Only the methodAttribute is changed. When the dependency is choosed to be excluded in the package, 2 XML attributes should be added : methodAttribute.addAttribute( "value", "0" ); uriAttribute.addAttribute( "value", "" ); Thanks for your answer/support. RC > Plugin doesn't handle correctly WebModule dependency scope > -- > > Key: MIDEA-74 > URL: http://jira.codehaus.org/browse/MIDEA-74 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Reporter: Remy Coqueugniot > Attachments: IdeaModuleMojo.java > > > If a pom.xml include a dependency with a "provided" or "test" scope, it > shouldn't be packaged with the webapp. > Ex: > [pom.xml] > > (...) > > > javax.servlet > servlet-api > 2.4 > provided > > > junit > junit > 3.8.1 > test > > > > This two depndency shouldn't be included in the webapp/WEB-INF/lib. Indeed, > some webcontainer (tomcat for example) may crash (or ignore them) if > libraries are already provided (servlet-api, jsp-api, ...) > I've done some really basic tests and fix the IdeaModuleMojo class. > Hope you will find some utility. -- 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: (MJAVADOC-82) 'sourcepath' should not be mandatory when using 'subpackages' configuration
[ http://jira.codehaus.org/browse/MJAVADOC-82?page=comments#action_77721 ]
Damien Lecan commented on MJAVADOC-82:
--
I have found why I doesn't work.
My pom declares two uses of maven-javadoc-plugin :
- 1 in section
- 1 in section
The first one was empty (no configuration) :
...
maven-javadoc-plugin
...
maven-javadoc-plugin
2.1
my.package:my.package2
...
It seems to be related to MNG-1857 or MNG-1931.
I'm sorry, I think you can fix and close this issue
> 'sourcepath' should not be mandatory when using 'subpackages' configuration
> ---
>
> Key: MJAVADOC-82
> URL: http://jira.codehaus.org/browse/MJAVADOC-82
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Damien Lecan
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
> Attachments: MJAVADOC-82.rar
>
>
> It is impossible to use 'subpackages' configuration without specifying
> 'sourcepath' directory.
> This works :
> maven-javadoc-plugin
>
> ${basedir}/src/main/java
>
> my.package:my.package2
>
>
>
> but this one doesn't works (without sourcepath with sources default path)
>
> maven-javadoc-plugin
>
>
> my.package:my.package2
>
>
>
--
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: (WAGONFTP-7) site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support directory copying
[ http://jira.codehaus.org/browse/WAGONFTP-7?page=comments#action_77725 ] Frank Cornelis commented on WAGONFTP-7: --- I still receive [INFO] Wagon protocol 'ftp' doesn't support directory copying when doing a release:perform, even after putting wagon-ftp-1.0-beta-1.jar in the $MAVEN_HOME/lib directory. In my pom.xml I have to following project/distributionManagement/site/url value: ftp://www.frankcornelis.be/dcontract/ When will this issue be fixed? > site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support > directory copying > > > Key: WAGONFTP-7 > URL: http://jira.codehaus.org/browse/WAGONFTP-7 > Project: wagon-ftp > Issue Type: Improvement >Affects Versions: 1.0-alpha-4 > Environment: windows >Reporter: pinghe > > Wagon protocol 'ftp' doesn't support directory copying -- 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-175) trimStackTrace=true trims "caused by:" sections complelely away
trimStackTrace=true trims "caused by:" sections complelely away --- Key: MSUREFIRE-175 URL: http://jira.codehaus.org/browse/MSUREFIRE-175 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Tuomas Kiviaho Priority: Minor Description of the parameter 'trimStackTrace' states "trim the stack trace in the reports to just the lines within the test" which it does nicely on the stacktrace, but there may be additional information in the initial cause that doesn't fall to the category "not within the test". Without trimming these "caused by:" lines of course show up, but so does the overly long test framework part of the stacktrace. -- 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: (MJAVADOC-82) 'sourcepath' should not be mandatory when using 'subpackages' configuration
[ http://jira.codehaus.org/browse/MJAVADOC-82?page=all ]
Vincent Siveton closed MJAVADOC-82.
---
Resolution: Fixed
Closed as suggested.
Thanks.
> 'sourcepath' should not be mandatory when using 'subpackages' configuration
> ---
>
> Key: MJAVADOC-82
> URL: http://jira.codehaus.org/browse/MJAVADOC-82
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Damien Lecan
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
> Attachments: MJAVADOC-82.rar
>
>
> It is impossible to use 'subpackages' configuration without specifying
> 'sourcepath' directory.
> This works :
> maven-javadoc-plugin
>
> ${basedir}/src/main/java
>
> my.package:my.package2
>
>
>
> but this one doesn't works (without sourcepath with sources default path)
>
> maven-javadoc-plugin
>
>
> my.package:my.package2
>
>
>
--
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: (MANT-15) Review plugin documentation
[ http://jira.codehaus.org/browse/MANT-15?page=all ] Vincent Siveton closed MANT-15. --- Assignee: Vincent Siveton Resolution: Fixed done > Review plugin documentation > --- > > Key: MANT-15 > URL: http://jira.codehaus.org/browse/MANT-15 > Project: Maven 2.x Ant Plugin > Issue Type: Task >Reporter: Vincent Siveton > Assigned To: Vincent Siveton > Fix For: 2.0-beta-2 > > > See http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- 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: (CONTINUUM-959) typo of variable name projectGroupId on buildDefinitionGroupSummaryComponent.jsp
[ http://jira.codehaus.org/browse/CONTINUUM-959?page=all ] Jesse McConnell closed CONTINUUM-959. - Assignee: Jesse McConnell Resolution: Fixed fixed, thanks for noticing that again :) > typo of variable name projectGroupId on > buildDefinitionGroupSummaryComponent.jsp > > > Key: CONTINUUM-959 > URL: http://jira.codehaus.org/browse/CONTINUUM-959 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Christian Gruber > Assigned To: Jesse McConnell >Priority: Critical > Attachments: projectGroupIdTypo.diff > > > projectGroupId in the buildDefinitionGroupSummaryComponent.jsp is once-again > mis-typed as projectGroupid, which causes the "add build definition" action > to throw an exception on an invalid groupId (since no groupId is seen to be > passed. > Patch added. Note: This was fixed earlier, adn is probably just a casualty > of the rbac merge. -- 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-959) typo of variable name projectGroupId on buildDefinitionGroupSummaryComponent.jsp
[ http://jira.codehaus.org/browse/CONTINUUM-959?page=all ] Jesse McConnell updated CONTINUUM-959: -- Fix Version/s: 1.1 > typo of variable name projectGroupId on > buildDefinitionGroupSummaryComponent.jsp > > > Key: CONTINUUM-959 > URL: http://jira.codehaus.org/browse/CONTINUUM-959 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Christian Gruber > Assigned To: Jesse McConnell >Priority: Critical > Fix For: 1.1 > > Attachments: projectGroupIdTypo.diff > > > projectGroupId in the buildDefinitionGroupSummaryComponent.jsp is once-again > mis-typed as projectGroupid, which causes the "add build definition" action > to throw an exception on an invalid groupId (since no groupId is seen to be > passed. > Patch added. Note: This was fixed earlier, adn is probably just a casualty > of the rbac merge. -- 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: (MANT-19) Handle more packaging projects (jar, ear, war...)
Handle more packaging projects (jar, ear, war...) - Key: MANT-19 URL: http://jira.codehaus.org/browse/MANT-19 Project: Maven 2.x Ant Plugin Issue Type: Improvement Affects Versions: 2.0-beta-2 Reporter: Vincent Siveton Assigned To: Vincent Siveton Fix For: 2.0-beta-2 A todo already exists in AntBuildWriter class: // TODO: what if type is not JAR? -- 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-1177) Upload ant-contrib 1.0b2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1177?page=all ] Tomislav Stojcevich updated MAVENUPLOAD-1177: - Attachment: ant-contrib-1.0b2-bundle.jar Updated pom with missing info. > Upload ant-contrib 1.0b2 > > > Key: MAVENUPLOAD-1177 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1177 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: ant-contrib-1.0b2-bundle.jar, > ant-contrib-1.0b2-bundle.jar > > > Upload with sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-454) testng-spring has a invalid dependency on testng.
testng-spring has a invalid dependency on testng. - Key: MEV-454 URL: http://jira.codehaus.org/browse/MEV-454 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Alexandre Poitras The following dependency is found in the pom : org.testng testng 4.7 But testng requires a classifier value specifying either to use the jdk 1.4 or 1.5. I have absolutely no idea how to fix this. -- 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-526) Add AOL Notifier
[ http://jira.codehaus.org/browse/CONTINUUM-526?page=all ] Jesse McConnell updated CONTINUUM-526: -- Fix Version/s: 1.2 > Add AOL Notifier > > > Key: CONTINUUM-526 > URL: http://jira.codehaus.org/browse/CONTINUUM-526 > Project: Continuum > Issue Type: New Feature > Components: AOL Notifier >Reporter: Emmanuel Venisse > Fix For: 1.2 > > > http://sourceforge.net/projects/joustim/ > BSD license. -- 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: (CONTINUUM-694) Add proxy configuration support for notifiers
[ http://jira.codehaus.org/browse/CONTINUUM-694?page=all ]
Jesse McConnell closed CONTINUUM-694.
-
Resolution: Incomplete
think this should have been addressed by emm's comment, but if it is still a
problem then by all means get us some feedback and we'll see what we can do.
> Add proxy configuration support for notifiers
> -
>
> Key: CONTINUUM-694
> URL: http://jira.codehaus.org/browse/CONTINUUM-694
> Project: Continuum
> Issue Type: Improvement
> Components: Mail Notifier, IRC Notifier, Jabber Notifier, MSN
> Notifier, AOL Notifier
>Affects 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: (MRELEASE-171) Parameter -Darguments only allow one argument
Parameter -Darguments only allow one argument - Key: MRELEASE-171 URL: http://jira.codehaus.org/browse/MRELEASE-171 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Ubuntu 6.10 maven 2.0.4 j2sdk1.4.2 Reporter: Nick Stolwijk I try to give some arguments when preparing a release to surefire, which is called when the mvn integration-test is being run. My commandline: mvn release:prepare -DdryRun=true -Darguments="-Dautoportaal.environment=continuum -Dmaven.test.failure.ignore=true" When I run this I see in the log: [INFO] Executing: mvn clean integration-test --no-plugin-updates -Dautoportaal.environment=continuum When I try: mvn release:prepare -DdryRun=true -Darguments="-Dautoportaal.environment=continuum" -Darugments="-Dmaven.test.failure.ignore=true" I see: [INFO] Executing: mvn clean integration-test --no-plugin-updates -Dmaven.test.failure.ignore=true It seems only one argument is passed on with the -Darguments argument. -- 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-786) Failing to build project in right order or failing to recognize a svn change in the right order
[ http://jira.codehaus.org/browse/CONTINUUM-786?page=all ] Jesse McConnell updated CONTINUUM-786: -- Fix Version/s: 1.1 > Failing to build project in right order or failing to recognize a svn change > in the right order > --- > > Key: CONTINUUM-786 > URL: http://jira.codehaus.org/browse/CONTINUUM-786 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.0.3 >Reporter: Vincent Massol >Priority: Critical > Fix For: 1.1 > > Attachments: Continuum after Cargo commit rev1152.jpg, This is what > happened after a build all.jpg > > > Here's what happened. > * Today (26th of July) around 15:35GMT+1, I made a big commit in Cargo > touching several modules. > * At 16:04GMT+1 I received 2 emails from C (C = Continuum) showing > compilation errors in the following 2 modules (see > http://ci.codehaus.org:8001/continuum/servlet/continuum/target/Summary.vm/fid/continuumProject): > ** "Cargo Core Geronimo Container" > ** "Cargo Core Jetty Container" > * Note that the build is working fine locally here > The > [error|http://ci.codehaus.org:8001/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=47541&id=151] > is because it's finding a class that's been renamed in the "Cargo Core > Container API" module. Note that this module is defined to be built before > the two modules in error above. > What's also strange is that C shows a lot of modules in error (the red > crosses) but if you look in the build results these modules are building > fine. I'm attaching a screenshot to this issue. > What can I do more to help debu this? This makes C unusable for me as I > consider these 2 emails as false positives. Is there something I don't > understand? > Thanks -- 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-692) Add specific continuum values as variables on build parameters input
[ http://jira.codehaus.org/browse/CONTINUUM-692?page=all ]
Jesse McConnell updated CONTINUUM-692:
--
Fix Version/s: 1.2
> Add specific continuum values as variables on build parameters input
>
>
> Key: CONTINUUM-692
> URL: http://jira.codehaus.org/browse/CONTINUUM-692
> Project: Continuum
> Issue Type: New Feature
> Components: Core system, Web interface
>Affects Versions: 1.0.3
>Reporter: Christian Gruber
>Priority: Critical
> Fix For: 1.2
>
>
> The idea is to add certain key continuum values as variables that can be
> passed into the parameters of a build. The main one at question is a build
> #. This would allow someone to do something like:
> (mvn) clean source:jar javadoc:jar deploy scm:tag
> -Dtag=DAILY_BUILD_${continuum.build.number}
> This way, if the thing deployed successfully, it would be tagged.
> Other examples of variables that might be substituted include build timestamp
> (on server), and continuum group.
> This would also be highly useful in ant builds, I suspect.
--
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-692) Add specific continuum values as variables on build parameters input
[ http://jira.codehaus.org/browse/CONTINUUM-692?page=comments#action_77757
]
Jesse McConnell commented on CONTINUUM-692:
---
I think this can be addressed nicely with the build profiles which should be
targetted for 1.2, perhaps these variables can be generated on a per profile
basis
> Add specific continuum values as variables on build parameters input
>
>
> Key: CONTINUUM-692
> URL: http://jira.codehaus.org/browse/CONTINUUM-692
> Project: Continuum
> Issue Type: New Feature
> Components: Core system, Web interface
>Affects Versions: 1.0.3
>Reporter: Christian Gruber
>Priority: Critical
> Fix For: 1.2
>
>
> The idea is to add certain key continuum values as variables that can be
> passed into the parameters of a build. The main one at question is a build
> #. This would allow someone to do something like:
> (mvn) clean source:jar javadoc:jar deploy scm:tag
> -Dtag=DAILY_BUILD_${continuum.build.number}
> This way, if the thing deployed successfully, it would be tagged.
> Other examples of variables that might be substituted include build timestamp
> (on server), and continuum group.
> This would also be highly useful in ant builds, I suspect.
--
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-2509) M2/ANT : Weird ClassCastException in in macrodef when calling Beanshell scripting.
[ http://jira.codehaus.org/browse/MNG-2509?page=comments#action_77758 ]
Davy Toch commented on MNG-2509:
The problem seems to be fixed since ANT 1.7.0beta3.
> M2/ANT : Weird ClassCastException in in macrodef when calling
> Beanshell scripting.
> --
>
> Key: MNG-2509
> URL: http://jira.codehaus.org/browse/MNG-2509
> Project: Maven 2
> Issue Type: Bug
> Components: Ant tasks
>Affects Versions: 2.0.4
> Environment: - ANT 1.6.5 (with bsh-2.0b4.jar in ANT_HOME/lib)
> - JDK 1.5
>Reporter: Davy Toch
> Attachments: build.xml, pom.xml
>
>
> Hi,
> In ANT, sometimes more than one artifact is generated from the same
> build file (e.g. myapp.jar, myapp-client.jar, myapp-with-deps.jar).
> If using the M2 plugin for ANT (currently 2.0.4), this would mean
> we would need three POM's for the above 3 artifacts. However, in the
> above case the 3 POM's would be almost identical.
> So I have taken the following approach in order to have only one generic
> POM:
> pom.xml (with ANT tokens _TOKEN_...):
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> be.steria.test
> _TOKEN_ARTIFACTID_
> _TOKEN_PACKAGING_
> 1.5-SNAPSHOT
> Test artifact
>
>
> log4j
> log4j
> 1.2.9
> compile
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
>
> repo_dev
> scp://localhost/m2demo/repo_dev
>
>
>
> build.xml:
>xmlns:m="antlib:org.apache.maven.artifact.ant">
>
>
>
>
>
>
>toFile="[EMAIL PROTECTED]">
>
>
>to="@{artifactId}"/>
>to="@{packaging}"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
> artifactId="myapp-with-deps"/>
>
>
>
>
>
>
>pomRefId="M2POM_MYAPP"/>
>pomRefId="M2POM_MYAPP_CLIENT"/>
>pomRefId="M2POM_MYAPP_WITH_DEPS"/>
>
>
>pomRefId="M2POM_MYAPP"/>
>pomRefId="M2POM_MYAPP_CLIENT"/>
>pomRefId="M2POM_MYAPP_WITH_DEPS"/>
>
>
> Now if I execute the above, everything works fine, but if I add
[jira] Updated: (CONTINUUM-348) allow push build by scm path
[ http://jira.codehaus.org/browse/CONTINUUM-348?page=all ] Jesse McConnell updated CONTINUUM-348: -- Fix Version/s: (was: 1.1) 1.2 setting to 1.2 for adding this feature, I can see this being addressed by whatever mechanism resolves the scheduled build for project group profiles > allow push build by scm path > > > Key: CONTINUUM-348 > URL: http://jira.codehaus.org/browse/CONTINUUM-348 > Project: Continuum > Issue Type: Improvement > Components: Core system, SCM >Reporter: Brett Porter > Fix For: 1.2 > > > need to be able to take an scm path (perhaps repo and path are the 2 > parameters, with additional branch tag for CVS if applicable), and figure out > the right project to trigger a build for. -- 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: (CONTINUUM-520) Finner grained Group Management
[ http://jira.codehaus.org/browse/CONTINUUM-520?page=all ] Jesse McConnell closed CONTINUUM-520. - Assignee: Jesse McConnell Resolution: Fixed the functionality for this exists now with the new security setup, a group lvl developer and user role is created for each project group. if your interested in other features like making a build visible or not based on role existance than that is something we need to discuss. I think we'll probably try for a 1.1 best case defaults release for all these things and expand on the options in later releases. > Finner grained Group Management > --- > > Key: CONTINUUM-520 > URL: http://jira.codehaus.org/browse/CONTINUUM-520 > Project: Continuum > Issue Type: New Feature > Components: Core system >Affects Versions: 1.0.2 >Reporter: Alex Mayorga Adame > Assigned To: Jesse McConnell > Fix For: 1.1 > > > There should be group level access for project or group of projects. Not just > activities as it is now. > Example: Users in group A can build and see only especific projects and not > all of them. -- 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: (MPEAR-47) Building Apache-hosted plugins with empty repo fails
Building Apache-hosted plugins with empty repo fails Key: MPEAR-47 URL: http://jira.codehaus.org/browse/MPEAR-47 Project: maven-ear-plugin Issue Type: Bug Reporter: Brian Topping Many of the Apache-hosted plugins depend on POM versions that don't exist in HEAD and were never deployed. For instance, maven-ear-plugin depends on parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying these compiled plugins then requires deploying the parent POM, which doesn't really exist any more. Presumably this is happening because developers haven't cleared their repo and built in a while. :-) -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=all ] Carlos Sanchez moved MPEAR-47 to MEAR-45: - Workflow: Maven New (was: jira) Key: MEAR-45 (was: MPEAR-47) Project: Maven 2.x Ear Plugin (was: maven-ear-plugin) > Building Apache-hosted plugins with empty repo fails > > > Key: MEAR-45 > URL: http://jira.codehaus.org/browse/MEAR-45 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Brian Topping > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Many of the Apache-hosted plugins depend on POM versions that don't exist in > HEAD and were never deployed. For instance, maven-ear-plugin depends on > parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying > these compiled plugins then requires deploying the parent POM, which doesn't > really exist any more. > Presumably this is happening because developers haven't cleared their repo > and built in a while. :-) -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=comments#action_77767 ] Carlos Sanchez commented on MEAR-45: I think it's just a matter of updating the parent pom to version to or latest released > Building Apache-hosted plugins with empty repo fails > > > Key: MEAR-45 > URL: http://jira.codehaus.org/browse/MEAR-45 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Brian Topping > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Many of the Apache-hosted plugins depend on POM versions that don't exist in > HEAD and were never deployed. For instance, maven-ear-plugin depends on > parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying > these compiled plugins then requires deploying the parent POM, which doesn't > really exist any more. > Presumably this is happening because developers haven't cleared their repo > and built in a while. :-) -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=comments#action_2 ] Brian Topping commented on MEAR-45: --- If the child POMs were using release versions for parents, Maven could always resolve them against the central repo, regardless of how old they were. When snapshot versions are used, the snapshot repo needs to be configured, which is not obvious to some. Or, as you point out, the sources could be changed, but that feels a bit dirty and creates problems when the snapshot of a plugin is deployed to a corporate repository, since it isn't an accurate snapshot of the SCM source for the plugin when it was built. This seems like it would be easy to update tho, easier than applying patches. Am I missing something? > Building Apache-hosted plugins with empty repo fails > > > Key: MEAR-45 > URL: http://jira.codehaus.org/browse/MEAR-45 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Brian Topping > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Many of the Apache-hosted plugins depend on POM versions that don't exist in > HEAD and were never deployed. For instance, maven-ear-plugin depends on > parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying > these compiled plugins then requires deploying the parent POM, which doesn't > really exist any more. > Presumably this is happening because developers haven't cleared their repo > and built in a while. :-) -- 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: (MDEPLOY-41) Deploying to alternate repo specified by -DrepositoryId=
Deploying to alternate repo specified by -DrepositoryId= Key: MDEPLOY-41 URL: http://jira.codehaus.org/browse/MDEPLOY-41 Project: Maven 2.x Deploy Plugin Issue Type: Wish Reporter: Brian Topping It's useful to be able to build an artifact (such as a snapshot of a plugin) and deploy it to a local repository (such as on a corporate intranet). A good way to do this seems to be putting the corporate repo into settings.xml and using -DrepositoryId=xxx on the command line, but this doesn't work. -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=comments#action_5 ]
Brian Topping commented on MEAR-45:
---
The other option would be to add the following to every POM (since the parent
is unresolvable, it can't be put in the parent just once...)
{code:xml}
apache
Apache Snapshot Repo
http://people.apache.org/maven-snapshot-repository/
true
{code}
> Building Apache-hosted plugins with empty repo fails
>
>
> Key: MEAR-45
> URL: http://jira.codehaus.org/browse/MEAR-45
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Reporter: Brian Topping
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> Many of the Apache-hosted plugins depend on POM versions that don't exist in
> HEAD and were never deployed. For instance, maven-ear-plugin depends on
> parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying
> these compiled plugins then requires deploying the parent POM, which doesn't
> really exist any more.
> Presumably this is happening because developers haven't cleared their repo
> and built in a while. :-)
--
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: (MDEP-42) Unit tests fail on Linux
Unit tests fail on Linux Key: MDEP-42 URL: http://jira.codehaus.org/browse/MDEP-42 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Environment: i386-Linux Reporter: Richard van der Hoff Priority: Minor Attachments: timestamps.patch Under Linux, file modification timestamps only have a resolution of one second. This causes several of the unit tests to fail. The attached patch fixes them (hopefully without breaking them on other platforms...) -- 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: (MDEP-43) includeClassifiers configuration parameter
includeClassifiers configuration parameter -- Key: MDEP-43 URL: http://jira.codehaus.org/browse/MDEP-43 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Affects Versions: 2.0-alpha-1 Reporter: Richard van der Hoff Priority: Minor Attachments: patch Would it be possible to add an "includeClassifiers" parameter to AbstractDependencyFilterMojo? The attached patch implements this; I've factored the code which would be common to the TypeFilter and ClassifierFilter into a common base class. -- 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-1180) upload vraptor 2.2.2
upload vraptor 2.2.2 Key: MAVENUPLOAD-1180 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1180 Project: maven-upload-requests Issue Type: Task Reporter: Nico Steppat VRaptor 2.2.2 framework update with many improvements and loads of new docs. VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that configuration should be minimal and conventions should be maximized. -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=all ] Carlos Sanchez closed MEAR-45. -- Assignee: Carlos Sanchez Resolution: Won't Fix ear plugin extends 4-SNAPSHOT which is fine. You need to checkout from the parent folder if you want to build without problems or install parent manually. We don't want to add the snapshot repo to all poms. > Building Apache-hosted plugins with empty repo fails > > > Key: MEAR-45 > URL: http://jira.codehaus.org/browse/MEAR-45 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Brian Topping > Assigned To: Carlos Sanchez > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Many of the Apache-hosted plugins depend on POM versions that don't exist in > HEAD and were never deployed. For instance, maven-ear-plugin depends on > parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying > these compiled plugins then requires deploying the parent POM, which doesn't > really exist any more. > Presumably this is happening because developers haven't cleared their repo > and built in a while. :-) -- 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: (MDEP-44) unpacking/copying of attached artifacts from reactor projects doesn't work
unpacking/copying of attached artifacts from reactor projects doesn't work -- Key: MDEP-44 URL: http://jira.codehaus.org/browse/MDEP-44 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Reporter: Richard van der Hoff Attachments: dependency-issue.zip I have a parent project, which has two modules - "one" and "two". "one" uses assembly:single to attach an assembly to its build. "two" depends upon that assembly, and uses "dependency:unpack-dependencies" to unpack it. This works fine if the projects are built separately - and the assembly is installed in the local repository. However, when using the reactor to build both projects at once, the dependency plugin still looks in the local repository for the assembly, rather than using the artifact which was just built. This either fails, or produces the wrong version of the assembly. I suspect this may be a bug with the reactor mechanism - but I don't really understand how all that works... The attachment demonstrates the problem. -- 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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=comments#action_77782 ]
Brian Topping commented on MEAR-45:
---
ear plugin pom:
{code:xml}
maven-plugins
org.apache.maven.plugins
2-SNAPSHOT
{code}
I can make it build, but it's not clean. Whatever.
> Building Apache-hosted plugins with empty repo fails
>
>
> Key: MEAR-45
> URL: http://jira.codehaus.org/browse/MEAR-45
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Reporter: Brian Topping
> Assigned To: Carlos Sanchez
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> Many of the Apache-hosted plugins depend on POM versions that don't exist in
> HEAD and were never deployed. For instance, maven-ear-plugin depends on
> parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying
> these compiled plugins then requires deploying the parent POM, which doesn't
> really exist any more.
> Presumably this is happening because developers haven't cleared their repo
> and built in a while. :-)
--
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: (MEAR-45) Building Apache-hosted plugins with empty repo fails
[ http://jira.codehaus.org/browse/MEAR-45?page=comments#action_77783 ] Brian Topping commented on MEAR-45: --- oic, source tree changed recently. ok > Building Apache-hosted plugins with empty repo fails > > > Key: MEAR-45 > URL: http://jira.codehaus.org/browse/MEAR-45 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Brian Topping > Assigned To: Carlos Sanchez > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Many of the Apache-hosted plugins depend on POM versions that don't exist in > HEAD and were never deployed. For instance, maven-ear-plugin depends on > parent POM version 2-SNAPSHOT. It wouldn't be an issue except that deploying > these compiled plugins then requires deploying the parent POM, which doesn't > really exist any more. > Presumably this is happening because developers haven't cleared their repo > and built in a while. :-) -- 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: (MPXDOC-200) [m1.1-RC1 Oct06] maven-xdoc-plugin-1.10.1-SNAPSHOT fails under JDK 6
[ http://jira.codehaus.org/browse/MPXDOC-200?page=comments#action_77793 ] Lukas Theussl commented on MPXDOC-200: -- I can reproduce this with jdk 1.6.0-beta2 on Linux, but not with java 5, so I guess it's a VM issue, maybe related to [1] but I'm not sure. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6468404 > [m1.1-RC1 Oct06] maven-xdoc-plugin-1.10.1-SNAPSHOT fails under JDK 6 > > > Key: MPXDOC-200 > URL: http://jira.codehaus.org/browse/MPXDOC-200 > Project: maven-xdoc-plugin > Issue Type: Bug > Environment: java version "1.6.0-beta2" > Java(TM) SE Runtime Environment (build 1.6.0-beta2-b86) > Java HotSpot(TM) Client VM (build 1.6.0-beta2-b86, mixed mode, sharing) > Win 2K > Maven 1.1 RC 1 from Oct 2006 >Reporter: Benoit Xhenseval >Priority: Critical > Fix For: 1.10.1 > > > Hi > Issue discussed on > http://www.nabble.com/-m1.1-rc1--javadoc-does-not-generate-anything...-tf2220969.html > Here is the log: > xdoc:init: > [echo] Generates the directory structure required for xdocs > xdoc:i18n-validation: > [echo] Validation of the locale entries > BUILD FAILED > File.. file:/C:/Documents and > Settings/xhensevb/.maven/cache/maven-xdoc-plugin-1.10.1-SNAPSHOT/plugin.jelly > Element... j:arg > Line.. 666 > Column 70 > [Ljava.lang.Object; > Total time : 1 minutes 9 seconds > Finished at : 12 October 2006 13:54:00 BST > --- > I though that the issue may be related to generics and calling this > invokeStatic on java.util.Arrays > but this seems to work when I try at home with JDK 1.5.08 however, I'm having > trouble with JDK 6-b2 > May be the interface has changed or one cannot use the following jelly code: > var="availableLocales"/> > var="availableLocalesAsList"> > > > I have checked the API for JDK6 and it seems to be the same... > A simple maven site or maven multiproject:site under JDK 6 should confirm the > issue, works fine under 1.5 > Definitely something around this "asList" call... > 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] Created: (MPMD-43) Add results output to pmd:check
Add results output to pmd:check --- Key: MPMD-43 URL: http://jira.codehaus.org/browse/MPMD-43 Project: Maven 2.x Pmd Plugin Issue Type: New Feature Affects Versions: 2.1 Reporter: Brian Fox Assigned To: Brian Fox We need the ability to have the results printed to the build output when the pmd:check fails the build. This should be an optional flag defaulted to false. This should be something similar to the checkstyle output. The main reason is simplicity for a developer to see why a build failed, but also so we can see the problem in continuum build failures without having to go find the pmd.xml file. -- 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-1169) please upload this bundle to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1169?page=comments#action_77820 ] geoff hendrey commented on MAVENUPLOAD-1169: changed group-id to net.sf.shadesdb (since this appears to be the proper convention, based on all the other net.sf.XXX I see on ibiblio). http://osdn.dl.sourceforge.net/sourceforge/shadesdb/shades-0.0.5-bundle.jar > please upload this bundle to ibiblio > > > Key: MAVENUPLOAD-1169 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1169 > Project: maven-upload-requests > Issue Type: Task >Reporter: geoff hendrey > > shades database framework -- 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-1181) Please upload xml string parser
Please upload xml string parser --- Key: MAVENUPLOAD-1181 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1181 Project: maven-upload-requests Issue Type: Task Reporter: Donavon Buss -- 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
