[jira] Created: (MNG-2842) Developers and Contributors information is not being inherited
Developers and Contributors information is not being inherited -- Key: MNG-2842 URL: http://jira.codehaus.org/browse/MNG-2842 Project: Maven 2 Issue Type: Bug Components: Documentation: Guides, Inheritance and Interpolation Affects Versions: 2.0.5, 2.0.4 Environment: Linux (Fedora Core 6) JDK 1.5.0_10 Reporter: Brad Szabo The developers and contributors information is not being merged into the effective POM of child projects. According to the Project Inheritance section of the following two POM references, this info should be merged. http://maven.apache.org/guides/introduction/introduction-to-the-pom.html http://maven.apache.org/pom.html#Inheritance -- 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: (WAGON-72) Wagon.getProtocol() called from DefaultWagonManager breaks when used with wagon-webdav 1.0-beta-2
Wagon.getProtocol() called from DefaultWagonManager breaks when used with wagon-webdav 1.0-beta-2 - Key: WAGON-72 URL: http://jira.codehaus.org/browse/WAGON-72 Project: wagon Issue Type: Bug Affects Versions: 1.0 Environment: Maven 2.1-SNAPSHOT (revId: 508621); wagon 1.0-beta-3-SNAPSHOT (revId: 509353) Reporter: John Casey Priority: Blocker Attachments: output.log, wagon-webdav-extension.zip The newest snapshot of 1.0-beta-3 of the wagon-manager has DefaultWagonManager (line 414) calling Wagon.getProtocol(), which doesn't exist in the API until February 8th, 2007 (after -beta-1 and -beta-2 have been released). This means we cannot use released wagons with this manager. The fix is easy, but we need to put into place infrastructure for integration testing. I'm attaching a project that expresses this problem. Also, I'm attaching the output from `mvn clean` on this 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] Created: (MNG-2841) Ability to change plugins to 'aggregator' style on the fly
Ability to change plugins to 'aggregator' style on the fly -- Key: MNG-2841 URL: http://jira.codehaus.org/browse/MNG-2841 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.5 Environment: N/A Reporter: Franz Garsombke Priority: Minor We use a parent POM and sub-module POMs pretty heavily. It would be nice to be able to execute a plugin in the parent without having it execute in the children. Also, I do not want to create a profile for this feature. The only way I have seen to get around this problem is creating plugins as aggregator style. The plugin then only runs once at the parent level. I would like to have this feature available to all plugins. Thanks for your time. Franz -- 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: (MRRESOURCES-13) If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length
If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length Key: MRRESOURCES-13 URL: http://jira.codehaus.org/browse/MRRESOURCES-13 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Daniel Kulp Priority: Blocker Attachments: pom.xml If you run "mvn compile" with the attached pom, the resources are all 0 length. This is CRITICAL as the javadoc plugin forks a lifecycle that may re-invoke the remote-resources plugin. Thus, "mvn javadoc:jar install" sometimes results in jars without the proper resources. -- 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: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88259 ] Asgeir S. Nilsen commented on SUREFIRE-61: -- Any hope on getting this fixed and released on the maven-surefire-plugin 2.2 branch? > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Attachments: my-app.zip, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with >mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app >and lightly patched > 2. mvn test >in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties >which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- 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: (SUREFIRE-104) unable to establish my own http protocol handler for unit tests
[ http://jira.codehaus.org/browse/SUREFIRE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88258 ] Adrian commented on SUREFIRE-104: - I'm experiencing the same error trying to start up the embedded jboss container within surefire. I get java.net.MalformedURLException: unknown protocol: vfsfile at java.net.URL.(URL.java:365) at java.net.URL.(URL.java:253) at java.net.URL.(URL.java:276) . > unable to establish my own http protocol handler for unit tests > --- > > Key: SUREFIRE-104 > URL: http://jira.codehaus.org/browse/SUREFIRE-104 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: jse 5.0 (osx) >Reporter: Andy Fyfe > Fix For: 2.3 > > Attachments: protocol.zip > > > In order to establish my own http protocol handler, I set the system property > java.protocol.handler.pkgs and ensure that the tests require a fork. The > test runs fine under maven 1.0.2, but fails under maven 2.0.4. I have tried > both surefire 2.1.3 and 2.2, and both with the childDelegation option. > The test sees the system property properly set, but the test's protocol > handler is not actually used. > The attached zip file demonstrates this problem (run "maven test" and "mvn > test"). -- 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: (MCHANGELOG-54) NPE during "Developer Activity" report generation
[ http://jira.codehaus.org/browse/MCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Vicente updated MCHANGELOG-54: Attachment: changelog-patch-2.txt the first changelog-patch.txt contains only the correction for ChangeLogReport. use the changelog-patch-2.txt for the 3 classes as described above > NPE during "Developer Activity" report generation > - > > Key: MCHANGELOG-54 > URL: http://jira.codehaus.org/browse/MCHANGELOG-54 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: windows 2000, maven 2.0.4, SCM Synergy > maven-changelog-plugin:2.0-SNAPSHOT >Reporter: David Vicente > Attachments: changelog-patch-2.txt, changelog-patch.txt > > > I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a > NullPointerException during "Developer Activity" report generation. > java.lang.NullPointerException at > org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) > > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) > > I have the Synergy SCM. > it occurs when a Synergy task is completed without modified file, the > changelog.xml has an entry without file. > it occurs with the last released version. > I made the correction (see changelog-patch.txt) and it works fine -- 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-827) notification emails missing svn information
[ http://jira.codehaus.org/browse/CONTINUUM-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88252 ] Andre Ranvik commented on CONTINUUM-827: I experienced the same problem - and I believe the solution was found... At least it worked for us. This WAS our invalid authorization.conf: [groups] win-dev = OUR_DOMAIN_NAME\t22, OUR_DOMAIN_NAME\t33 [/] * = @win-dev = rw ___ This IS our VALID authorization.conf: [groups] win-dev = OUR_DOMAIN_NAME\t22, t22, OUR_DOMAIN_NAME\t33, t33 [/] * = @win-dev = rw ___ The difference is, as you can see, that we added the users without the domain name as well as with the domain name. Why this is required is beyond me... - but it works! The authorization.conf file is the file describing how Apache authorizes the user. Our Apache httpd.conf file contains this: DAV svn SVNPath "F:/svnrepos" AuthType Basic AuthName "Subversion repository" AuthUserFile "F:/svnrepos/conf/users.conf" AuthAuthoritative Off AuthName "Subversion Authentication" AuthType SSPI SSPIAuth On SSPIAuthoritative Off SSPIDomain somedome.name.org SSPIOfferBasic On AuthzSVNAccessFile "F:/svnrepos/conf/authorization.conf" Require valid-user > notification emails missing svn information > --- > > Key: CONTINUUM-827 > URL: http://jira.codehaus.org/browse/CONTINUUM-827 > Project: Continuum > Issue Type: Bug > Components: SCM >Affects Versions: 1.0.3 >Reporter: Brian Fox > Fix For: 1.1 > > Attachments: continumm-build-result-view.JPG > > > I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list > the developer or the commit message. I just get a list of changed files. I > have seen it in the past occasionally but almost always the info isn't there. > This includes times when there was only 1 commit since the last build. -- 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-200) Artifacts are uploaded to wrong directory
Artifacts are uploaded to wrong directory - Key: MRELEASE-200 URL: http://jira.codehaus.org/browse/MRELEASE-200 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: The maven repository is running Red Hat Linux Enterprise Server. The clients are PCs running Windows XP. Reporter: Chris Baumgartner Priority: Minor When doing a release:perform, the artifacts are occassionally uploaded to the wrong directory. We are using scp from the upload. Instead of uploading to the path of "/maven-repository", the files are being uploaded to "~/om/maven-repository". For some reason it is creating a subdirectory called "om" in the user's home directory and uploading the artifacts there. It doesn't happen all the time, but it does seem to be consitently putting them there when it does fail. I can work around this by manually moving the files, but it is very annoying. -- 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: (MCHANGELOG-54) NPE during "Developer Activity" report generation
[ http://jira.codehaus.org/browse/MCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88250 ] David Vicente commented on MCHANGELOG-54: - i have the same NPE in doChangedFiles method of ChangeLogReport class and also in getOrderedFileList method of FileActivityReport class. For these 3 classes, when you get the files list from a ChangeSet, you doesn't test if files list is null or not. So, the problem is , with Synergy SCM, you can complete a task without checkout files. so you can have a changelog-entry in changelog.xml without file element. I hope it will be corrected as soon as possible > NPE during "Developer Activity" report generation > - > > Key: MCHANGELOG-54 > URL: http://jira.codehaus.org/browse/MCHANGELOG-54 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: windows 2000, maven 2.0.4, SCM Synergy > maven-changelog-plugin:2.0-SNAPSHOT >Reporter: David Vicente > Attachments: changelog-patch.txt > > > I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a > NullPointerException during "Developer Activity" report generation. > java.lang.NullPointerException at > org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) > > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) > > I have the Synergy SCM. > it occurs when a Synergy task is completed without modified file, the > changelog.xml has an entry without file. > it occurs with the last released version. > I made the correction (see changelog-patch.txt) and it works fine -- 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: (SUREFIRE-289) Surefire classlaoder loads wrong class when classes are of same package/class name
[ http://jira.codehaus.org/browse/SUREFIRE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zachary Jones updated SUREFIRE-289: --- Attachment: cheesetest.zip cheese.zip Adding a test case to prove this problem. First unzip the cheese.zip into your local repo. It contains a jar file at cheese/org/cheeseburgertest-1.0.jar cheeseburgertest-1.0.jar contains a class "test/TestClass" that has a method String sayCheese() which returns "CheeseBurger!". Unizip the cheesetest.zip anywhere and run "mvn install". cheesetest is a simple project that contains a duplicate "test/TestClass" whose sayCheese method returns "Cheese!". When it runs the test "test/TestClassTest", it asserts that sayCheese returns "Cheese!". But as you will see, the test fails and the surefire report shows "CheeseBurger!" was returned instead. If you do an eclipse:eclipse and run the test in Eclipse, the test will pass as expected.. > Surefire classlaoder loads wrong class when classes are of same package/class > name > -- > > Key: SUREFIRE-289 > URL: http://jira.codehaus.org/browse/SUREFIRE-289 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.0 (2.2 plugin) > Environment: Windows, Cygwin >Reporter: Zachary Jones > Attachments: cheese.zip, cheesetest.zip > > > This is a repeat of the comment in SUREFIRE-286 > I am having a problem with surefire classloading. > I had to hack the ServiceMix class: > org.apache.servicemix.http.processors.ConsumerProcessor. > I saved the hacked version as the same class name and the same package. This > class does compile to target/classes. The ServiceMix jar that contains this > class is included in my classpath after the target/classes directory (seen > with -X) > When running mvn test, I get a test failure for the Test class that tries to > create a ConsumerProcessor. We are expecting it to create "our" version of > ConsumerProcessor, but it instead creates the ServiceMix version. > I have tried all the available usage options from the surefire plugin > documentation to no avail. Through debug in Eclipse, I see through a watch > expression (getClass().getClassLoader()) is always the IsolatedClassLoader, > no matter what options we set. > This test passes in Eclipse, so I am pretty sure it is a classloading issue > with the surefire plugin. > Thanks for your help in advance. -- 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: (MANT-25) The plugin generates bad test targets when the project.xml has include and exclude rules
[ http://jira.codehaus.org/browse/MANT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MANT-25: Testcase included: (was: yes) > The plugin generates bad test targets when the project.xml has include and > exclude rules > > > Key: MANT-25 > URL: http://jira.codehaus.org/browse/MANT-25 > Project: Maven 2.x Ant Plugin > Issue Type: Bug > Environment: maven-ant-plugin trunk using maven trunk > Last Changed Rev: 494359 >Reporter: Petteri Räty >Priority: Critical > > From commons-dbunit-2.2 project.xml: > > > org/dbunit/AllTests.java > > > **/*Test > > > The maven-build.xml created: > > > > > > > So trying to run ant test fails (mvn test works fine): > The ' characters around the executable and arguments are > not part of the command. > [junit] Running org.apache.tools.ant.taskdefs.TaskdefsTest > [junit] Testsuite: org.apache.tools.ant.taskdefs.TaskdefsTest > [junit] junit.framework.TestListener: tests to run: 1 > [junit] junit.framework.TestListener: startTest(warning) > [junit] junit.framework.TestListener: addFailure(warning, No tests found > in org.apache.tools.ant.taskdefs.TaskdefsTest) > [junit] junit.framework.TestListener: endTest(warning) > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.172 sec > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.172 sec > [junit] > [junit] Testcase: warning took 0.003 sec > [junit] FAILED > [junit] No tests found in org.apache.tools.ant.taskdefs.TaskdefsTest > [junit] > BUILD FAILED > /var/tmp/portage/dev-java/dbunit-2.2/work/dbunit-2.2/maven-build.xml:116: > Test org.apache.tools.ant.taskdefs.TaskdefsTest failed > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.actOnTestResult(JUnitTask.java:1712) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:820) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1657) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:764) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:357) > at org.apache.tools.ant.Target.performTasks(Target.java:385) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) > at org.apache.tools.ant.Project.executeTarget(Project.java:1298) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1181) > at org.apache.tools.ant.Main.runBuild(Main.java:698) > at org.apache.tools.ant.Main.startAnt(Main.java:199) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > It should be easy to add this to the maven-ant-plugin unit tests. -- 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: (MNG-2840) System scope not working properly in Maven Antlib
[ http://jira.codehaus.org/browse/MNG-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton moved MANT-21 to MNG-2840: -- Complexity: Intermediate Key: MNG-2840 (was: MANT-21) Project: Maven 2 (was: Maven 2.x Ant Plugin) > System scope not working properly in Maven Antlib > - > > Key: MNG-2840 > URL: http://jira.codehaus.org/browse/MNG-2840 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks > Environment: Mac OS X >Reporter: Greg Luck > > If I add the following > > javax.cache > jcache > not_released > system > > > /Users/gluck/work/ehcache/trunk/tools/jcache.jar > > When I so a run I get dropping > /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar > from path as it doesn't exist > [javac] net/sf/ehcache/jcache/CacheListenerAdaptor.java added as > net/sf/ehcache/jcache/CacheListenerAdaptor.class doesn't exist. > [javac] net/sf/ehcache/jcache/Entry.java added as > net/sf/ehcache/jcache/Entry.class doesn't exist. > [javac] net/sf/ehcache/jcache/JCache.java added as > net/sf/ehcache/jcache/JCache.class doesn't exist. > [javac] net/sf/ehcache/jcache/JCacheFactory.java added as > net/sf/ehcache/jcache/JCacheFactory.class doesn't exist. > [javac] net/sf/ehcache/jcache/package.html skipped - don't know how to > handle it > dropping > /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar > from path as it doesn't exist > It should not be looking for it there. > To reproduce just try and use the system scope and systemPath. -- 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-2840) System scope not working properly in Maven Antlib
[ http://jira.codehaus.org/browse/MNG-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-2840: - Component/s: Ant tasks Moved to Ant tasks > System scope not working properly in Maven Antlib > - > > Key: MNG-2840 > URL: http://jira.codehaus.org/browse/MNG-2840 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks > Environment: Mac OS X >Reporter: Greg Luck > > If I add the following > > javax.cache > jcache > not_released > system > > > /Users/gluck/work/ehcache/trunk/tools/jcache.jar > > When I so a run I get dropping > /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar > from path as it doesn't exist > [javac] net/sf/ehcache/jcache/CacheListenerAdaptor.java added as > net/sf/ehcache/jcache/CacheListenerAdaptor.class doesn't exist. > [javac] net/sf/ehcache/jcache/Entry.java added as > net/sf/ehcache/jcache/Entry.class doesn't exist. > [javac] net/sf/ehcache/jcache/JCache.java added as > net/sf/ehcache/jcache/JCache.class doesn't exist. > [javac] net/sf/ehcache/jcache/JCacheFactory.java added as > net/sf/ehcache/jcache/JCacheFactory.class doesn't exist. > [javac] net/sf/ehcache/jcache/package.html skipped - don't know how to > handle it > dropping > /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar > from path as it doesn't exist > It should not be looking for it there. > To reproduce just try and use the system scope and systemPath. -- 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-23) Make the ant plugin able to generate javadoc targets into build.xml files
[ http://jira.codehaus.org/browse/MANT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MANT-23. --- Resolution: Fixed Added javadoc task > Make the ant plugin able to generate javadoc targets into build.xml files > - > > Key: MANT-23 > URL: http://jira.codehaus.org/browse/MANT-23 > Project: Maven 2.x Ant Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-1 >Reporter: Petteri Räty > Assigned To: Vincent Siveton > Fix For: 2.0-beta-2 > > > [EMAIL PROTECTED] /mnt/checkouts/maven-ant-plugin $ grep -i javadoc -r . > ./src/it/ear-it/primary-source/.svn/text-base/pom.xml.svn-base: > maven-javadoc-plugin > ./src/it/ear-it/primary-source/pom.xml: > maven-javadoc-plugin > [EMAIL PROTECTED] /mnt/checkouts/commons-dbutils-trunk $ grep -i javadoc > maven-build.xml > [EMAIL PROTECTED] /mnt/checkouts/commons-dbutils-trunk $ > For Gentoo packaging and for me being able to include maven generated > build.xml files in source releases I need to be able to generate javadocs > using the build.xml files. The standard target layout for self written > build.xml files I have come across is: > -compile > -jar (We have this as package, would be nice to name this after the thing it > does so jar would be jar and ear would be ear but that is an another bug) > -test > -javadoc > -dist (dummy target depending on jar, test 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: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88237 ] Yossi Shmulevitch commented on MJAR-30: --- I think that this is important capability. Since some plugins are generating classes (as wsdl2java axis plugin), Sometimes there is need to omit classes from the final jar. In my case it's a bug of the tool (or wrong behavior) but I can see places it's is needed. > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- 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: (SUREFIRE-289) Surefire classlaoder loads wrong class when classes are of same package/class name
Surefire classlaoder loads wrong class when classes are of same package/class name -- Key: SUREFIRE-289 URL: http://jira.codehaus.org/browse/SUREFIRE-289 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: Windows, Cygwin Reporter: Zachary Jones This is a repeat of the comment in SUREFIRE-286 I am having a problem with surefire classloading. I had to hack the ServiceMix class: org.apache.servicemix.http.processors.ConsumerProcessor. I saved the hacked version as the same class name and the same package. This class does compile to target/classes. The ServiceMix jar that contains this class is included in my classpath after the target/classes directory (seen with -X) When running mvn test, I get a test failure for the Test class that tries to create a ConsumerProcessor. We are expecting it to create "our" version of ConsumerProcessor, but it instead creates the ServiceMix version. I have tried all the available usage options from the surefire plugin documentation to no avail. Through debug in Eclipse, I see through a watch expression (getClass().getClassLoader()) is always the IsolatedClassLoader, no matter what options we set. This test passes in Eclipse, so I am pretty sure it is a classloading issue with the surefire plugin. Thanks for your help in advance. -- 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-1384) Please upload JODConverter 2.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88235 ] Mirko Nasato commented on MAVENUPLOAD-1384: --- Even those with 'test' scope? Alright. > Please upload JODConverter 2.1.1 > > > Key: MAVENUPLOAD-1384 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1384 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato > > JODConverter (Java OpenDocument Converter) converts documents between > different office formats, leveraging OpenOffice.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1384) Please upload JODConverter 2.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Nasato closed MAVENUPLOAD-1384. - Resolution: Incomplete Closing this issue since I'll upload a newer version after fixing the dependencies. > Please upload JODConverter 2.1.1 > > > Key: MAVENUPLOAD-1384 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1384 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato > > JODConverter (Java OpenDocument Converter) converts documents between > different office formats, leveraging OpenOffice.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1390) JasperReports 1.3.1 upload
JasperReports 1.3.1 upload -- Key: MAVENUPLOAD-1390 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1390 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://rs.jaspersoft.com/maven2/jasperreports-1.3.1-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Brown updated MNG-624: --- Attachment: MNG-624-tests.tar.gz MNG-624-maven-2.0.x-r507648.patch The attached patch and 16 integration tests fixes this issue by allowing the following: * Variable expansion works in the section of pom-s for version, groupId and artifactId * The same elements are all optional. At the extreme, this means most times will work. There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories ( still works) to resolve variables and/or find inferred elements that are missing. Implementation Notes: * All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit sections. * It passes my complex 202-module project. * Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it "expansion" in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly. * When pom-s are installed and deployed, if any part of their specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than "trunk" as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code) ** The pom in the repository looses all comments and formatting from the original. ** The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture. BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV :) > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.1.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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-2839) Non-unique-version snapshots not updated
Non-unique-version snapshots not updated Key: MNG-2839 URL: http://jira.codehaus.org/browse/MNG-2839 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5 Reporter: Pavel Halas Test case: - let's have a repository with [uniqueVersion]false[/uniqueVersion]. - let your project download any snapshot dependency (with non-unique version) (like abc-1.0-SNAPSHOT.jar). - go to your local repository and change the file content. You can also remove all the metadata. - run "mvn -U" on your project - you get "[INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from YOUR-REPOSITORY" - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated. The same (I think) bug has been reported (and closed) several times before (MNG-1908 etc.) but it still appears in 2.0.5. -- 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: (MCHANGELOG-54) NPE during "Developer Activity" report generation
NPE during "Developer Activity" report generation - Key: MCHANGELOG-54 URL: http://jira.codehaus.org/browse/MCHANGELOG-54 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: windows 2000, maven 2.0.4, SCM Synergy maven-changelog-plugin:2.0-SNAPSHOT Reporter: David Vicente Attachments: changelog-patch.txt I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a NullPointerException during "Developer Activity" report generation. java.lang.NullPointerException at org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) I have the Synergy SCM. it occurs when a Synergy task is completed without modified file, the changelog.xml has an entry without file. it occurs with the last released version. I made the correction (see changelog-patch.txt) and it works fine -- 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: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88224 ] Marcel May commented on MSITE-211: -- I have the same problem (see my mail http://mail-archives.apache.org/mod_mbox/maven-users/200702.mbox/ajax/[EMAIL PROTECTED]). It seems jsch uses the active proxy from settings.xml for SSH/SCP deployment, which fails. For me it worked to disable the proxy (which is not a solution but a hack). In my opinion it is wrong that the site plugin sets the maven active proxy for jsch. The maven active proxy is for accessing repositories, right? And with the site plugin we (might) want to use a proxy for putting the generated site on some server. At least the site plugin should support to configure/override/disable the jsch proxy. Cheers, Marcel > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > --
[jira] Closed: (MRM-287) The context is not included in repository links when browsing artifacts.
[ http://jira.codehaus.org/browse/MRM-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRM-287. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Apply. Thanks. > The context is not included in repository links when browsing artifacts. > > > Key: MRM-287 > URL: http://jira.codehaus.org/browse/MRM-287 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henry S. Isidro > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > Attachments: [MRM-287]-archiva-webapp.patch > > > When browsing, searching and finding an artifact, the resulting page displays > links to navigate to the various levels of the artifact's group as well as to > the top of the tree. These links have urls which do not include the context > of the web application so if archiva is deployed in a different context, > these links will generate 404s. -- 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: (MRM-287) The context is not included in repository links when browsing artifacts.
[ http://jira.codehaus.org/browse/MRM-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated MRM-287: Attachment: [MRM-287]-archiva-webapp.patch File Attached: [MRM-287]-archiva-webapp.patch This patch adds the context to the generated urls of the navigation links when browsing an artifact. > The context is not included in repository links when browsing artifacts. > > > Key: MRM-287 > URL: http://jira.codehaus.org/browse/MRM-287 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henry S. Isidro > Attachments: [MRM-287]-archiva-webapp.patch > > > When browsing, searching and finding an artifact, the resulting page displays > links to navigate to the various levels of the artifact's group as well as to > the top of the tree. These links have urls which do not include the context > of the web application so if archiva is deployed in a different context, > these links will generate 404s. -- 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: (MRM-287) The context is not included in repository links when browsing artifacts.
The context is not included in repository links when browsing artifacts. Key: MRM-287 URL: http://jira.codehaus.org/browse/MRM-287 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro When browsing, searching and finding an artifact, the resulting page displays links to navigate to the various levels of the artifact's group as well as to the top of the tree. These links have urls which do not include the context of the web application so if archiva is deployed in a different context, these links will generate 404s. -- 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-211) Can't deploy site using site:deploy due to a ProxyHTTP error
Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker When I execute the site deployment (with version that comes with maven 2.0.5) "mvn site:deploy " I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 20 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 [INFO] Final Memory: 3M/7M [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: (MDEP-65) Copy dependencies in a Maven repository like layout
Copy dependencies in a Maven repository like layout
---
Key: MDEP-65
URL: http://jira.codehaus.org/browse/MDEP-65
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 2.0-alpha-2, 2.0
Reporter: Alexis Midon
Assigned To: Brian Fox
Attachments: repository-layout.patch
I use the dependency plugin in my Maven project at work.
But we need a tiny feature not yet implemented by your plugin.
Actually we would like to copy some dependencies in a repository like layout.
This exactly what your plugin does except for the repository part.
_example:_ I'd like to move dependencies in something like
{{outputDirectory/junit/junit/3.8.1/junit-3.8.1.jar}} and so on
To help you, I implemented this feature in the maven-dependency-plugin trunk
(as of revision 510010) and the patch is in attachment.
Here are details of the development:
- add a new optional boolean property in
org.apache.maven.plugin.dependency.AbstractFromDependenciesMojo :
useRepositoryLayout
- add a new parameter to DependencyUtil.getFormattedOutputDirectory(...)
- update all calls to this method
- update unit test and add specific tests for this new parameter
_Example POM:_
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
${project.build.directory}/alternateLocation
true
{code}
I tried to create a new issue in jira but the url failed.
I hope you will find this feature attractive, and I will be glad to answer any
of your request about 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
