[jira] Commented: (MANT-29) Allow extension for task customization
[ http://jira.codehaus.org/browse/MANT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92907 ] Carlos Sanchez commented on MANT-29: about the manifest it could either pick it up from the jar configuration option or from the classes/META-INF folder > Allow extension for task customization > -- > > Key: MANT-29 > URL: http://jira.codehaus.org/browse/MANT-29 > Project: Maven 2.x Ant Plugin > Issue Type: Improvement >Reporter: Carlos Sanchez > Fix For: 2.0 > > > For instance the Felix guys want to add a manifest and right now seems too > complex (even imposible) with all the static methods > https://issues.apache.org/jira/browse/FELIX-247 -- 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-29) Allow extension for task customization
Allow extension for task customization -- Key: MANT-29 URL: http://jira.codehaus.org/browse/MANT-29 Project: Maven 2.x Ant Plugin Issue Type: Improvement Reporter: Carlos Sanchez Fix For: 2.0 For instance the Felix guys want to add a manifest and right now seems too complex (even imposible) with all the static methods https://issues.apache.org/jira/browse/FELIX-247 -- 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-22) Make it possible to run the package target without tests
[ http://jira.codehaus.org/browse/MANT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MANT-22: --- Fix Version/s: (was: 2.0-beta-1) 2.0-beta-2 > Make it possible to run the package target without tests > > > Key: MANT-22 > URL: http://jira.codehaus.org/browse/MANT-22 > Project: Maven 2.x Ant Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-1 > Environment: Gentoo Linux >Reporter: Petteri Räty > Fix For: 2.0 > > Attachments: maven-ant-plugin-dist-target.patch > > > When packaging stuff for Gentoo linux it is our packaging policy to give the > user the choice whether he/she wants to run the unit tests or not. Nowadays > as quite a few projects only use maven as their build system we use ant:ant > to generate build.xml files and do your packaging using that (at least until > we can get maven to properly build from source and integrate repositories to > our system etc. which has proved not so easy). The problem with the generated > build.xml files is that it always forces the tests for the package target. > For this reason I wrote a patch that changes the default target to dist that > just depends on the package and test targets. -- 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-1483) Please synchronize the jDTAUS repository
Please synchronize the jDTAUS repository Key: MAVENUPLOAD-1483 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1483 Project: maven-upload-requests Issue Type: Task Reporter: Christian Schulte Attachments: org.jdtaus.sh -- 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-165) TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
[
http://jira.codehaus.org/browse/SUREFIRE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92906
]
Jesse Kuhnert commented on SUREFIRE-165:
I'd resolve this if I had the right perms but the new 2.4-SNAPSHOT version of
surefire is compatible up to version 5.5 of TestNG.
> TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
> -
>
> Key: SUREFIRE-165
> URL: http://jira.codehaus.org/browse/SUREFIRE-165
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin)
> Environment: - WinXP
> - Maven 2.0.4 (with maven-surefire-plugin 2.2)
>Reporter: Davy Toch
> Fix For: 2.4
>
> Attachments: m2-testng-example-jdk14.zip
>
>
> After a day of trying to find out why JDK1.4 JavaDoc annotated test classes
> were never run, I finally found out why:
> In
> maven-surefire\surefire-providers\surefire-testng\src\main\java\org\apache\maven\surefire\testng\TestNGExecutor.java,
> the method testng.runSuitesLocally() is called:
> static void executeTestNG( SurefireTestSuite surefireSuite, String
> testSourceDirectory, XmlSuite suite,
>ReporterManager reporterManager )
> {
> ...
> // TODO: Doesn't find testng.xml based suites when these are un-commented
> // TestNG ~also~ looks for the currentThread context classloader
> // ClassLoader oldClassLoader =
> Thread.currentThread().getContextClassLoader();
> // Thread.currentThread().setContextClassLoader(
> suite.getClass().getClassLoader() );
> testNG.runSuitesLocally();
> //Thread.currentThread().setContextClassLoader( oldClassLoader );
> ...
> }
> However, in the TestNG 5.1 source file org\testng\TestNG.java, only the
> method run() correctly loads the JDK1.4 annotations. So the above class
> should call testng.run() and not testng.runSuitesLocally().
> org\testng\TestNG.java:
> /**
>* Run TestNG.
>*/
> public void run() {
> // lazy scan sourcedirs if needed
> if(isJdk14() || JAVADOC_ANNOTATION_TYPE.equals(m_target)) {
>
> AnnotationConfiguration.getInstance().getAnnotationFinder().addSourceDirs(m_sourceDirs);
> }
> ...
> }
> The problem is also still present in the latest 2.3-SNAPSHOT version of the
> maven-surefire-plugin.
> Included a small example project to illustrate the problem (just run "maven
> 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] Commented: (SUREFIRE-307) Tests fail if in path with spaces
[
http://jira.codehaus.org/browse/SUREFIRE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92905
]
Jesse Kuhnert commented on SUREFIRE-307:
Can you tell me if this still happens with surefire 2.4-SNAPSHOT and TestNG
5.5?
> Tests fail if in path with spaces
> -
>
> Key: SUREFIRE-307
> URL: http://jira.codehaus.org/browse/SUREFIRE-307
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, TestNG support
>Affects Versions: 2.3
> Environment: Windows XP
> Maven 2.0.5
> Java 1.6.0
>Reporter: Wim Deblauwe
>
> I use TestNG with Surefire. My build fails if my project is in a path with
> spaces, because my tests fail. In my tests I have the following code:
> new File( getClass().getResource( "sample-java-utils-log.xml" ).toURI() )
> This results in the following error:
> java.net.URISyntaxException: Illegal character in path at index 18:
> file:/C:/Documents and
> Settings/wdb/.hudson/jobs/Vigilog/workspace/trunk/target/test-classes/net/sourceforge/vigilog/parse/sample-
> java-utils-log.xml
> at java.net.URI$Parser.fail(Unknown Source)
> at java.net.URI$Parser.checkChars(Unknown Source)
> at java.net.URI$Parser.parseHierarchical(Unknown Source)
> at java.net.URI$Parser.parse (Unknown Source)
> at java.net.URI.(Unknown Source)
> at java.net.URL.toURI(Unknown Source)
> at
> net.sourceforge.vigilog.parse.JavaLoggingXMLFileLogFileParserTest.testParse(JavaLoggingXMLFileLogFileParserTest.java
> :38)
> If I put my project in a path without spaces, I don't have this problem (I
> noticed this problem, because I tried Hudson build server and it checks the
> project out to my home directory)
> According to Jesse Glick from the Hudson mailing list, the problem is due to
> the following fact (full thread:
> http://www.nabble.com/Build-fails-under-hudson-due-to-TestNG-unit-tests-tf3354110.html):
> Wim Deblauwe wrote:
> > If it is any help, this is the source code of IsolatedClassLoader:
> > http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/IsolatedClassLoader.java?view=markup
> It sure does help, because this class is probably to blame for your problem:
> http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-api/src/main/java/org/apache/maven/surefire/util/UrlUtils.java
> Note the call to File.toURL(), deprecated as of JDK 6 because
> $ jrunscript
> js> println(new java.io.File("/tmp/foo and bar/baz").toURI().toURL())
> file:/tmp/foo%20and%20bar/baz
> js> println(new java.io.File("/tmp/foo and bar/baz").toURL())
> file:/tmp/foo and bar/baz
> js> println(new java.io.File("/tmp/foo and bar/baz").toURL().toURI())
> script error: sun.org.mozilla.javascript.internal.WrappedException:
> Wrapped java.net.URISyntaxException: Illegal character in path at index
> 13: file:/tmp/foo and bar/baz (#1) in at line number 1
> js>
> If you want to reproduce this, check out my open source project to a
> directory with spaces from:
> https://vigilog.svn.sourceforge.net/svnroot/vigilog/trunk
> and run '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] Commented: (SUREFIRE-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92903 ] Jesse Kuhnert commented on SUREFIRE-59: --- I'd resolve this if I had the right perms but the new 2.4-SNAPSHOT version of surefire is compatible up to version 5.5 of TestNG. > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > Fix For: 2.4 > > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > 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:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > Please, correct surefire to be compatible with new testng. -- 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-287) Regression: org.testng.xml.Praser#parse() signature changed
[ http://jira.codehaus.org/browse/SUREFIRE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92904 ] Jesse Kuhnert commented on SUREFIRE-287: I'd resolve this if I had the right perms but the new 2.4-SNAPSHOT version of surefire is compatible up to version 5.5 of TestNG. > Regression: org.testng.xml.Praser#parse() signature changed > --- > > Key: SUREFIRE-287 > URL: http://jira.codehaus.org/browse/SUREFIRE-287 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.0 (2.2 plugin), 2.3 >Reporter: Bernhard Neuhauser >Priority: Critical > Fix For: 2.4 > > > TestNG 5.3, 5.4 and 5.5 dont work with Surefire. > TestNG 5.2 runs fine. > Reference to the TestNG Issue: http://jira.opensymphony.com/browse/TESTNG-122 > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite;; > nested exception is java.lang.NoSuchMethodError: > org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; > java.lang.NoSuchMethodError: > org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:129) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) > at org.apache.maven.surefire.Surefire.run(Surefire.java:108) > 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:597) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:288) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:816) -- 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-58) Not compatible with TestNG 5.4: InstantiationException: org.testng.internal.annotations.JDK15AnnotationFinder
[ http://jira.codehaus.org/browse/SUREFIRE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92902 ] Jesse Kuhnert commented on SUREFIRE-58: --- I'd resolve this if I had the right perms but the new 2.4-SNAPSHOT version of surefire is compatible up to version 5.5 of TestNG. > Not compatible with TestNG 5.4: InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > - > > Key: SUREFIRE-58 > URL: http://jira.codehaus.org/browse/SUREFIRE-58 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.5 > Environment: JDK 1.5.0_09 > mvn 2.0.4 > surefire-api:jar:2.0 > surefire-testng:jar:2.0 > > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.4 > jdk15 > test > >Reporter: Damian Golda >Priority: Minor > Fix For: 2.4 > > > While running test using mvn and TestNG 5.4 there surefire reports exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.internal.annotations.JDK15AnnotationFinder; nes > ed exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder; nested excepti > n is org.apache.maven.surefire.testset.TestSetFailedException: > org.testng.internal.annotations.JDK15AnnotationFinder; n > sted exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > org.apache.maven.surefire.testset.TestSetFailedException: > org.testng.internal.annotations.JDK15AnnotationFinder; nested > exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > at java.lang.Class.newInstance0(Class.java:335) > at java.lang.Class.newInstance(Class.java:303) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(TestNGDirectoryTestSuite.java:86) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.apache.maven.surefire.Surefire.instantiateObject(Surefire.java:216) > at > org.apache.maven.surefire.Surefire.instantiateSuite(Surefire.java:243) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:145) > at org.apache.maven.surefire.Surefire.run(Surefire.java:108) > 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:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > I suppose that the reason is that in TestNG 5.4 (and 5.3) constructor for > JDK15AnnotationFinder has an argument: > public JDK15AnnotationFinder(IAnnotationTransformer transformer) > and there is no default constructor. > I found that there is only one implementation of IAnnotationTransformer - > DefaultAnnotationTransformer which fortunatly has default constructor. > So I it can be changed from > new JDK15AnnotationFinder() > to > new JDK15AnnotationFinder(new DefaultAnnotationTransformer()) > So instead of class.newInstance should be used: > Constructor c = Class.getConstructor(IAnnotationTransformer.class); > DefaultAnnotationTransformer daf = new DefaultAnnotationTransformer() > c.newInstance(daf); -- 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: (MAVEN-1103) improve "goal not found" reporting
[ http://jira.codehaus.org/browse/MAVEN-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1103. -- Assignee: Arnaud Heritier Resolution: Fixed Fix Version/s: 1.1-rc1 $ maven foo __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT Trying to get missing dependencies (and updated snapshots) required by Maven: - Checking for an update of maven:maven-model:3.0.2-SNAPSHOT:jar from http://people.apache.org/repo/m1-snapshot-repository/ Skipping download as local copy is up to date! --- BUILD FAILED >> Goal 'foo' does not exist in this project. --- Total time : 2 seconds Finished at : Saturday, April 14, 2007 1:59:56 AM CEST Final Memory : 2M/3M --- > improve "goal not found" reporting > -- > > Key: MAVEN-1103 > URL: http://jira.codehaus.org/browse/MAVEN-1103 > Project: Maven 1.x > Issue Type: Improvement > Components: core >Affects Versions: 1.0-rc1 >Reporter: Brett Porter >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 1.1-rc1 > > > - goal not found should be an error message, not an exception when leaving > maven > - goals that are not found should be reported before any building is done -- 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: (MAVEN-1840) java.util.ConcurrentModificationException in Goal
java.util.ConcurrentModificationException in Goal - Key: MAVEN-1840 URL: http://jira.codehaus.org/browse/MAVEN-1840 Project: Maven 1.x Issue Type: Bug Components: jelly/ant integration Affects Versions: 1.1-beta-3 Environment: build maven 1.1 RC 1 on continuum 1.0 on solaris with jdk 1.4 Reporter: Arnaud Heritier Fix For: 1.1-rc1 maven:run-touchstone: Trying to get missing dependencies (and updated snapshots) required by Touchstone: - Checking for an update of touchstone:touchstone:SNAPSHOT:jar from http://people.apache.org/repo/m1-snapshot-repository/ Skipping download as local copy is up to date! - Checking for an update of touchstone:test:SNAPSHOT:war from http://people.apache.org/repo/m1-snapshot-repository/ Skipping download as local copy is up to date! build:start: clean:clean: xdoc:clean: [delete] Deleting directory /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target clean: java:prepare-filesystem: [mkdir] Created dir: /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes java:init: java:compile: [echo] maven.dependency.classpath: /export/home/continuum/.maven/repository/ant/jars/ant-optional-1.5.1.jar /export/home/continuum/maven-1.1/lib/maven.jar /export/home/continuum/.maven/repository/maven/jars/maven-model-3.0.1.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/a.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/b.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/c-1.0-alpha-1-SNAPSHOT.jar /export/home/continuum/.maven/repository/classworlds/jars/classworlds-1.0-beta-1.jar /export/home/continuum/.maven/repository/touchstone/jars/touchstone-SNAPSHOT.jar /export/home/continuum/.maven/repository/commons-jelly/jars/commons-jelly-tags-interaction-1.0.jar [echo] Compiling to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes [javac] Compiling 1 source file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes java:jar-resources: Copying 1 file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes Copying 1 file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes/org/apache/maven/touchstone Copying 2 files to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes test:test: java:prepare-filesystem: java:init: java:compile: [echo] maven.dependency.classpath: /export/home/continuum/.maven/repository/ant/jars/ant-optional-1.5.1.jar /export/home/continuum/maven-1.1/lib/maven.jar /export/home/continuum/.maven/repository/maven/jars/maven-model-3.0.1.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/a.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/b.jar /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/c-1.0-alpha-1-SNAPSHOT.jar /export/home/continuum/.maven/repository/classworlds/jars/classworlds-1.0-beta-1.jar /export/home/continuum/.maven/repository/touchstone/jars/touchstone-SNAPSHOT.jar /export/home/continuum/.maven/repository/commons-jelly/jars/commons-jelly-tags-interaction-1.0.jar [echo] Compiling to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes [mkdir] Created dir: /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-reports test:test-resources: Copying 1 file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes/org/apache/maven/touchstone Copying 1 file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes test:compile: [javac] Compiling 1 source file to /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes jar:jar: [jar] Building jar: /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/touchstone-1.0.jar touchstone-tests: xdoc:init-i18n: [echo] Init the i18n support xdoc:init: [echo] Generates the directory struct
[jira] Closed: (MPARTIFACT-75) Allow to sign artifacts to deploy
[ http://jira.codehaus.org/browse/MPARTIFACT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MPARTIFACT-75. - Resolution: Fixed Done > Allow to sign artifacts to deploy > - > > Key: MPARTIFACT-75 > URL: http://jira.codehaus.org/browse/MPARTIFACT-75 > Project: maven-artifact-plugin > Issue Type: New Feature >Affects Versions: 1.8 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier >Priority: Critical > Fix For: 1.9 > > > It's important for us to ease the release of artifacts. -- 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: (MAVEN-1839) Add maven-modello-plugin v 1.0
Add maven-modello-plugin v 1.0 -- Key: MAVEN-1839 URL: http://jira.codehaus.org/browse/MAVEN-1839 Project: Maven 1.x Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1836) Upgrade maven-clover-plugin to v 1.11.2
[ http://jira.codehaus.org/browse/MAVEN-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1836. -- Assignee: Lukas Theussl Resolution: Fixed Released on March 29th > Upgrade maven-clover-plugin to v 1.11.2 > --- > > Key: MAVEN-1836 > URL: http://jira.codehaus.org/browse/MAVEN-1836 > Project: Maven 1.x > Issue Type: Sub-task >Affects Versions: 1.1-beta-3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPCLOVER?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1782) Upgrade maven-jdiff-plugin to v. 1.5.1
[ http://jira.codehaus.org/browse/MAVEN-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1782. -- Assignee: Lukas Theussl Resolution: Fixed Released on March 29th > Upgrade maven-jdiff-plugin to v. 1.5.1 > -- > > Key: MAVEN-1782 > URL: http://jira.codehaus.org/browse/MAVEN-1782 > Project: Maven 1.x > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPJDIFF?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1809) Upgrade maven-pdf-plugin to v 2.5.1
[ http://jira.codehaus.org/browse/MAVEN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1809. -- Resolution: Fixed Released on March 29th > Upgrade maven-pdf-plugin to v 2.5.1 > --- > > Key: MAVEN-1809 > URL: http://jira.codehaus.org/browse/MAVEN-1809 > Project: Maven 1.x > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPPDF?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1838) Upgrade maven-pmd-plugin to v 1.10
[ http://jira.codehaus.org/browse/MAVEN-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1838. -- Resolution: Fixed Released on March 29th > Upgrade maven-pmd-plugin to v 1.10 > --- > > Key: MAVEN-1838 > URL: http://jira.codehaus.org/browse/MAVEN-1838 > Project: Maven 1.x > Issue Type: Sub-task >Affects Versions: 1.1-beta-3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPPMD?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1828) Upgrade maven-scm-plugin to v 1.6.1
[ http://jira.codehaus.org/browse/MAVEN-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1828. -- Resolution: Fixed Released on Mar 29th > Upgrade maven-scm-plugin to v 1.6.1 > --- > > Key: MAVEN-1828 > URL: http://jira.codehaus.org/browse/MAVEN-1828 > Project: Maven 1.x > Issue Type: Sub-task >Affects Versions: 1.1-beta-3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPSCM?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1829) Upgrade maven-site-plugin to v 1.7.1
[ http://jira.codehaus.org/browse/MAVEN-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1829. -- Resolution: Fixed Released on Mar 29th > Upgrade maven-site-plugin to v 1.7.1 > > > Key: MAVEN-1829 > URL: http://jira.codehaus.org/browse/MAVEN-1829 > Project: Maven 1.x > Issue Type: Sub-task >Affects Versions: 1.1-beta-3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPSITE?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1777) Upgrade maven-artifact-plugin to v 1.9
[ http://jira.codehaus.org/browse/MAVEN-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MAVEN-1777: --- Summary: Upgrade maven-artifact-plugin to v 1.9 (was: Upgrade maven-artifact-plugin to v 1.8.1) > Upgrade maven-artifact-plugin to v 1.9 > -- > > Key: MAVEN-1777 > URL: http://jira.codehaus.org/browse/MAVEN-1777 > Project: Maven 1.x > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPARTIFACT?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MPARTIFACT-75) Allow to sign artifacts to deploy
Allow to sign artifacts to deploy - Key: MPARTIFACT-75 URL: http://jira.codehaus.org/browse/MPARTIFACT-75 Project: maven-artifact-plugin Issue Type: New Feature Affects Versions: 1.8 Reporter: Arnaud Heritier Assignee: Arnaud Heritier Priority: Critical Fix For: 1.9 It's important for us to ease the release of artifacts. -- 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: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MPARTIFACT-61. - Assignee: Arnaud Heritier Resolution: Won't Fix It will not be fixed for maven 1.0.x. Sorry. > scpexe is a noop > > > Key: MPARTIFACT-61 > URL: http://jira.codehaus.org/browse/MPARTIFACT-61 > Project: maven-artifact-plugin > Issue Type: Bug >Affects Versions: 1.5.2 > Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 >Reporter: Joerg Schaible >Assignee: Arnaud Heritier >Priority: Blocker > > Unfortunatel scpexe protocoll seems a noop in version 1.5.2. The executable > is not called, but Maven is reporting happily that it has deployed: > jar:deploy: > [echo] Deploying... > Using userBuildPropertiesFile: C:\Dokumente und > Einstellungen\jos\build.properties > Using projectPropertiesFile: C:\Work\Projects\commons\lang\project.properties > Using projectBuildPropertiesFile: > C:\Work\Projects\commons\lang\build.properties > Will deploy to 1 repository(ies): elsag > Deploying to repository: elsag > Uploading to elsag-commons/poms/elsag-lang-1.2-SNAPSHOT.pom: > (7K) > Uploading to elsag-commons/poms/elsag-lang-snapshot-version: > (0K) > Uploading to elsag-commons/poms/elsag-lang-1.2-20051011.091919.pom: > (7K) > Will deploy to 1 repository(ies): elsag > Deploying to repository: elsag > Uploading to elsag-commons/jars/elsag-lang-1.2-SNAPSHOT.jar: > (64K) > Uploading to elsag-commons/jars/elsag-lang-snapshot-version: > (0K) > Uploading to elsag-commons/jars/elsag-lang-1.2-20051011.091940.jar: > (64K) > attaining goal build:end > I can even remove any scp.exe and ssh.exe or set maven.repo.X.scp.executable > to any not existing file, the output of Maven is the same. Setting the > scp.executable property to a batch file that writes something into a file > proves, that the "executable" is definately not called. All this works with > 1.4.1 though delivered with the M102 installation, the artifacts are really > delpoyed. > This is a real blocker for me, since I am stuck to 1.0.2 because of extensive > entitiy usage and I wanted to use 1.5.2 to write self-contained POMs into the > repository to prepare a M2 transition at a later time. > Note, that the scp protocol does not work either for me, I always get despite > any settings for private key and passphrase: > Root cause > org.apache.maven.MavenException: Unable to deploy to any repositories > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:338) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleDeploy(DefaultArtifactDeployer.java:131) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:102) > at > org.apache.maven.artifact.deployer.DeployBean.deploy(DeployBean.java:142) > 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.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) > at > org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) > at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) > at org.apache.maven.cli.App.doMain(App.java:488) > at org.apache.maven.cli.App.main(App.java:1239) > 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 com.werken.for
[jira] Created: (MECLIPSE-256) [PATCH]Flat Maven2 Multiproject Structures and Classpath Resolution as Projects (not binaries)
[PATCH]Flat Maven2 Multiproject Structures and Classpath Resolution as Projects
(not binaries)
---
Key: MECLIPSE-256
URL: http://jira.codehaus.org/browse/MECLIPSE-256
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Components: dependency resolution, multiproject
Affects Versions: 2.3
Reporter: Kevin Ross
Fix For: 2.4
In a project structure where 'root' projects are flat/siblings with child
projects or modules, we need to resolve actual projects on the local system as
eclipse project dependencies for ease of debugging, hot deployment etc. The
following code is a hack, perhaps should be an option to be turned on/off, but
PLEASE include it. It is certainly doubtful to hurt...
In AbstractIdeSupportMojo.doDependencyResolution() towards the end of the
method and before the instantiation of the IdeDependency object please:
<<<>>>
if (new File( project.getBasedir(), "../" +
artifact.getArtifactId() ).exists()) {
getLog().info( "Adding project dependency: " +
artifact.getArtifactId() );
isReferencedProject = true;
}
<<<>>>
// for reference:
IdeDependency dep = new IdeDependency(
artifact.getGroupId(), artifact.getArtifactId(), artifact.getVersion(),
isReferencedProject, Artifact.SCOPE_TEST.equals( artifact.getScope() ),
Artifact.SCOPE_SYSTEM.equals( artifact.getScope() ),
Artifact.SCOPE_PROVIDED.equals( artifact.getScope() ),
artifact.getArtifactHandler().isAddedToClasspath(), artifact
.getFile(), artifact.getType(),
isOsgiBundle, osgiSymbolicName, dependencyDepth );
--
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: (MASSEMBLY-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-194: - Fix Version/s: (was: 2.2-beta-1) 2.2 > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.2 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MASSEMBLY-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MASSEMBLY-194: -- reopening to address Stephane's issues. > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.2 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- 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] Issue Comment Edited: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92881 ] Christian Hall edited comment on MRELEASE-6 at 4/13/07 3:10 PM: I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project. was: One issue we have here is that we have a large platform of components and forcing the parent pom to be a standalone file at the root of our components directory makes for a huge Subversion update to get the latest parent pom (since cannot update a single file). So, solutions that just solve the Eclipse problem don't fix it for us. Our directory structure is: components/ + pom.xml + component1/ + + pom.xml + component2/ + + pom.xml ... with lots of components. I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project. > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Windows XP, Eclipse Workspace >Reporter: Bernd Mau >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0-beta-5 > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92881 ] Christian Hall commented on MRELEASE-6: --- One issue we have here is that we have a large platform of components and forcing the parent pom to be a standalone file at the root of our components directory makes for a huge Subversion update to get the latest parent pom (since cannot update a single file). So, solutions that just solve the Eclipse problem don't fix it for us. Our directory structure is: components/ + pom.xml + component1/ + + pom.xml + component2/ + + pom.xml ... with lots of components. I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project. > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Windows XP, Eclipse Workspace >Reporter: Bernd Mau >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0-beta-5 > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- 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: (MANTTASKS-64) uberjar does not contain the lightweight http wagon
[ http://jira.codehaus.org/browse/MANTTASKS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92877 ] Herve Boutemy commented on MANTTASKS-64: found that jtidy and xml-apis were effectively added as a dependency of wagon-http-lightweight 1.0-beta-2 => must be excluded but I don't understand your assessment that the new uberjar does not contain the lightweight wagon: it is here and it works for me, perfectly downloads lots of artifacts what is the new declaration that is needed in your script ? I would really like the new tasks to be released, since previous ones are really so old (depend on Maven internals 2.0.2, even if named 2.0.4!) > uberjar does not contain the lightweight http wagon > --- > > Key: MANTTASKS-64 > URL: http://jira.codehaus.org/browse/MANTTASKS-64 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Brett Porter > > the new uberjar does not contain the lightweight wagon, so any use fails > unles you add a declaration to your script which was not necessary in the > previous release. > In addition, the JAR seems to be larger than before despite the omission - > was something unnecessarily included? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-39) Ability to checkout/update selective modules under root
[ http://jira.codehaus.org/browse/SCM-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92875 ] Ryan Daum commented on SCM-39: -- If I understand what is being said here correctly, some SCM systems (bazaar, mercurial) will not be able to implement this functionality -- they do not have a way of checking out only pieces of a given repository. > Ability to checkout/update selective modules under root > --- > > Key: SCM-39 > URL: http://jira.codehaus.org/browse/SCM-39 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api >Affects Versions: 1.0-alpha-1 > Environment: XP, maven 1.0.2 >Reporter: Dan Tran > Fix For: future > > > Legacy applications contain lots of unwanted source under SCM root. > Politically, it is impossible to remove them out of system. > And therefore, checkout and update operations can be very slow. > Suggest to add "includes "excludes" to checkout/update > command interfaces to only checkout/update wanted modules/directories > under SCM root. -- 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-2946) Module-by-Profile seems to break plugin dependencies
[ http://jira.codehaus.org/browse/MNG-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92869 ] Daniel Takai commented on MNG-2946: --- Ok I found it - although i'm not quite sure where the issue belongs: mvn or antrun plugin. Here it is: Using a project with multiple pom's the antrun plugin dependencies of the first plugin declaration encountered will be used for all subsequent antrun executions. If i put the dependencies needed for integration tests into the the other module's pom (that gets build first), everything works fine. > Module-by-Profile seems to break plugin dependencies > > > Key: MNG-2946 > URL: http://jira.codehaus.org/browse/MNG-2946 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: jdk1.4 >Reporter: Daniel Takai > > Using Module-by-Profile i ran into a problem with dependencies. My pom looks > like this: > > > default > > true > > > module1 > module2 > module3 > > > > integration > > module1 > module2 > module3 > integration > > > > The integration module runs the integration tests. > The integration module contain an antrun plugin. > Running the build on the integration module only works fine. > Running it from the parent project using the integration profile breaks the > build. The problem is that the plugin dependencies are not accessible to the > ant build files (and therefore, i suppose, to the plugin). -- 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: (WAGON-71) Wagon nukes the permission bits of uploaded files.
[ http://jira.codehaus.org/browse/WAGON-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92868 ] Carlos Sanchez commented on WAGON-71: - without patches it could be sitting here for long time until somebody volunteers > Wagon nukes the permission bits of uploaded files. > -- > > Key: WAGON-71 > URL: http://jira.codehaus.org/browse/WAGON-71 > Project: wagon > Issue Type: Bug >Reporter: Henning Schmiedehausen > > Uploading a site using wagon might nuke permission bits of e.g. CGI scripts > thus making these unavailable. > For Apache webserver, a CGI script can have the permission bit set and is > then executed. This is e.g. used for the "download.cgi" script on many Apache > project sites. > The wagon uploader (at least ssh and ssh-external) unconditionally change the > permissions of all files to be 664. Which kills the execution bits. Which is > bad (TM). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-193) NullPointer in local provider update when a new file is added
[ http://jira.codehaus.org/browse/SCM-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-193. Resolution: Fixed > NullPointer in local provider update when a new file is added > - > > Key: SCM-193 > URL: http://jira.codehaus.org/browse/SCM-193 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-local >Affects Versions: 1.0-beta-3 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.0-beta-4 > > > org.apache.maven.continuum.scm.ContinuumScmException: Error while update > sources. > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) > at > org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) > 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.apache.maven.scm.ScmException: Exception while executing SCM > command. > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) > at > org.apache.maven.scm.provider.local.LocalScmProvider.update(LocalScmProvider.java:191) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) > ... 5 more > Caused by: java.lang.NullPointerException > at java.util.Date.getMillisOf(Date.java:938) > at java.util.Date.after(Date.java:911) > at > org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:89) > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) > ... 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] Reopened: (SCM-193) NullPointer in local provider update when a new file is added
[ http://jira.codehaus.org/browse/SCM-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez reopened SCM-193: > NullPointer in local provider update when a new file is added > - > > Key: SCM-193 > URL: http://jira.codehaus.org/browse/SCM-193 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-local >Affects Versions: 1.0-beta-3 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.0-beta-4 > > > org.apache.maven.continuum.scm.ContinuumScmException: Error while update > sources. > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) > at > org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) > 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.apache.maven.scm.ScmException: Exception while executing SCM > command. > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) > at > org.apache.maven.scm.provider.local.LocalScmProvider.update(LocalScmProvider.java:191) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) > ... 5 more > Caused by: java.lang.NullPointerException > at java.util.Date.getMillisOf(Date.java:938) > at java.util.Date.after(Date.java:911) > at > org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:89) > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) > ... 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: (MNG-2947) Deploy 3rd party source jar
Deploy 3rd party source jar --- Key: MNG-2947 URL: http://jira.codehaus.org/browse/MNG-2947 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 2.0.6 Reporter: Daniel Siegmann Priority: Minor There is a guide to deploying 3rd party jars to a remote repository [1], using deploy:deploy-file. This guide does not mention how source jars can be deployed along with the code jar. A section should be added to the end of this guide providing a quick explanation. Here is an example of what such documentation might look like: *Deploying Source Jars* To deploy a 3rd party source jar, packaging should be set to "java-source", and generatePom should be set to false. [1] http://maven.apache.org/guides/mini/guide-deploying-3rd-party-jars.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Daum updated SCM-230: -- Attachment: scm-230-patch-1.svndiff Please find attached a patch which fixes the following issues: 1. Allow file/http/https URLs for checkout 2. Fix bug where checkout would only work while inside an existing repository(!) 3. IntelliJ IDEA project file was accidently checked in. > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-mercurial (hg) >Reporter: solo turn >Assignee: Emmanuel Venisse > Fix For: 1.0-beta-5 > > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz, > maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tar.gz, > maven-scm-provider-hg.tgz, scm-230-patch-1.svndiff, site-patch, site-patch-2 > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-292) Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names
[ http://jira.codehaus.org/browse/SCM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-292: - Fix Version/s: (was: 1.0-beta-5) 1.0 > Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in > memory clientspec names > > > Key: SCM-292 > URL: http://jira.codehaus.org/browse/SCM-292 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0-beta-4 >Reporter: Emmanuel Venisse >Assignee: Patrick Schneider >Priority: Critical > Fix For: 1.0 > > > With a Map instead of a system property, we'll can support more that one > clientspec in the jvm. It's necessary for Continuum because it access to more > than one project in Perforce. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-255) WTP Settings does not use servlet-api version defined in pom.xml
WTP Settings does not use servlet-api version defined in pom.xml Key: MECLIPSE-255 URL: http://jira.codehaus.org/browse/MECLIPSE-255 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Windows XP Pro SP2, Eclipse 3.2.1, WTP 1.5.2, Maven 2.0.4 Reporter: Joel I have this dependencu in my pom.xml: javax.servlet servlet-api 2.3 provided And I've set the plugin like this: org.apache.maven.plugins maven-eclipse-plugin 2.3 1.5 When I'm generating eclipse config file with goal eclipse:eclipse, the content of the generated file ".settings/org.eclipse.wst.common.project.facet.core.xml" is: The should be , isn't it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2784) Multiple executions of the same plugin at the same life cycle phase in a multi-module profile mixed up
[ http://jira.codehaus.org/browse/MNG-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92850 ] Maik Ebert commented on MNG-2784: - This issue still exists in Maven 2.0.6. > Multiple executions of the same plugin at the same life cycle phase in a > multi-module profile mixed up > -- > > Key: MNG-2784 > URL: http://jira.codehaus.org/browse/MNG-2784 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build, Plugins and Lifecycle, Profiles, > Reactor and workspace >Affects Versions: 2.0.4, 2.0.5 >Reporter: Maik Ebert >Priority: Critical > Attachments: MNG-2784.patch > > > I use the latest Maven 2.0.5 build found at > http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ > I have multiple executions of the same plugin at the same life cycle phase in > a multi-module parent POM. There was a bug regarding the order of this > executions. This was fixed at 2.0.5. > Now I needed to extract these plugin executions to a profile in this parent > POM. Now the executions are not ordered correctly anymore :-( > Before (works fine): > parent\pom.xml <= multiple executions of the same plugin at the same life > cycle phase in the default build element > parent \child1\pom.xml > parent \child2\pom.xml > Calling mvn install in parent works fine. > After (fails): > parent\pom.xml <= multiple executions of the same plugin at the same life > cycle phase in the build element of a profile > parent \child1\pom.xml > parent \child2\pom.xml > Calling mvn install in parent mixed up the execution order in the childs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-98) Renaming artifact to its finalName in POM before placed in /WEB-INF/lib.
[ http://jira.codehaus.org/browse/MWAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92847 ] Thomas Raehalme commented on MWAR-98: - After browsing the current source for awhile I discovered that you can manually change the naming of the included artifacts using outputFileNameMapping (available in 2.0.3). > Renaming artifact to its finalName in POM before placed in /WEB-INF/lib. > > > Key: MWAR-98 > URL: http://jira.codehaus.org/browse/MWAR-98 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Thomas Raehalme > > If you have project A with module core, it produces an artifact named > core-x.y.z.jar (or any other type). Even if build/finalName has been > specified in the POM, the file name still matches the name of the artifact > when stored in the Maven repository. This is also the name that the WAR > plug-in uses when adding the artifact to /WEB-INF/lib. If you add a module > named core in project B, there will be two core-x.y.z.jar files when creating > a WAR/EAR. > There has been discussion about storing the artifact in the repository using > the finalName value, but such implementation would make automatic downloading > of artifacts much more difficult. It was therefore suggested that each plugin > should rename the artifact itself when necessary. > http://www.nabble.com/Re%3A-Question-regarding-finalName-in-maven-assembly-plugin-p9960876s177.html > Therefore I suggest that the WAR plug-in renames the artifact to its > finalName before adding it to the web application. Unfortunately I cannot > provide a patch at the time of writing this. I will, however, try to provide > one in the near future. -- 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: (MWAR-98) Renaming artifact to its finalName in POM before placed in /WEB-INF/lib.
Renaming artifact to its finalName in POM before placed in /WEB-INF/lib. Key: MWAR-98 URL: http://jira.codehaus.org/browse/MWAR-98 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Thomas Raehalme If you have project A with module core, it produces an artifact named core-x.y.z.jar (or any other type). Even if build/finalName has been specified in the POM, the file name still matches the name of the artifact when stored in the Maven repository. This is also the name that the WAR plug-in uses when adding the artifact to /WEB-INF/lib. If you add a module named core in project B, there will be two core-x.y.z.jar files when creating a WAR/EAR. There has been discussion about storing the artifact in the repository using the finalName value, but such implementation would make automatic downloading of artifacts much more difficult. It was therefore suggested that each plugin should rename the artifact itself when necessary. http://www.nabble.com/Re%3A-Question-regarding-finalName-in-maven-assembly-plugin-p9960876s177.html Therefore I suggest that the WAR plug-in renames the artifact to its finalName before adding it to the web application. Unfortunately I cannot provide a patch at the time of writing this. I will, however, try to provide one in the near future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-297) scm:tag process child poms recursively and attempts to tag submodules
[ http://jira.codehaus.org/browse/SCM-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-297. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0-beta-5 > scm:tag process child poms recursively and attempts to tag submodules > - > > Key: SCM-297 > URL: http://jira.codehaus.org/browse/SCM-297 > Project: Maven SCM > Issue Type: Bug >Reporter: Alexander Burak >Assignee: Emmanuel Venisse > Fix For: 1.0-beta-5 > > > My project contains several submodules with own poms: > > pom.xml > > pom.xml > > pom.xml > When I execute 'clean package scm:tag -Dtag="tag1"' root folder is tagged > perfectly to (Subversion) "/tags/tag1" but scm:tag is then executed for > each submodule, i.e. it tries to tag "module1" folder to "/tags/tag1", > but "tag1" already exists and svn reports error. > I need to be able to stop recursive processing of child poms, because all > subdirectories of are already tagged -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-298) Cannot add timestamp at the beginning of tag name
[ http://jira.codehaus.org/browse/SCM-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-298. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0-beta-5 > Cannot add timestamp at the beginning of tag name > - > > Key: SCM-298 > URL: http://jira.codehaus.org/browse/SCM-298 > Project: Maven SCM > Issue Type: Improvement >Reporter: Alexander Burak >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.0-beta-5 > > > At the moment timestamp can only be added to the end of tag name, like > "tagname-MMdd", it would be nice to be able to add it to the beginning of > tag name too: "MMdd-tagname" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-230: - Component/s: maven-scm-provider-mercurial (hg) > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-mercurial (hg) >Reporter: solo turn >Assignee: Emmanuel Venisse > Fix For: 1.0-beta-5 > > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz, > maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tar.gz, > maven-scm-provider-hg.tgz, site-patch, site-patch-2 > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- 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-2946) Module-by-Profile seems to break plugin dependencies
Module-by-Profile seems to break plugin dependencies Key: MNG-2946 URL: http://jira.codehaus.org/browse/MNG-2946 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: jdk1.4 Reporter: Daniel Takai Using Module-by-Profile i ran into a problem with dependencies. My pom looks like this: default true module1 module2 module3 integration module1 module2 module3 integration The integration module runs the integration tests. The integration module contain an antrun plugin. Running the build on the integration module only works fine. Running it from the parent project using the integration profile breaks the build. The problem is that the plugin dependencies are not accessible to the ant build files (and therefore, i suppose, to the plugin). -- 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: (MSITE-143) SCP works for deploy goal, but not for site-deploy
[ http://jira.codehaus.org/browse/MSITE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wu yiding updated MSITE-143: Attachment: patch-MSITE-143.txt the current SNAPSHOT still exist bug, add few lines to fix it . MNG-2324 will change to Add a getWagon(Repository) method to the WagonManager. If can use this method in the furture,the current ugly fix can be remove. > SCP works for deploy goal, but not for site-deploy > -- > > Key: MSITE-143 > URL: http://jira.codehaus.org/browse/MSITE-143 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jacob Robertson > Attachments: patch-MSITE-143.txt > > > The linux admins did everything necessary to get the deploy goal to work, and > now I have to go back to them and try and figure out why the "site-deploy" > goal says "Auth failed". Why does deploy work just fine with scp, but not > site-deploy? My environment is such that my deploy repository and my deploy > site directories are in the same parent directory, and have the exact same > permissions. But one goal fails to upload, and the other doesn't... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-193) NullPointer in local provider update when a new file is added
[ http://jira.codehaus.org/browse/SCM-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92834 ] Marius Barbulescu commented on SCM-193: --- I get the same error in 1.0.3 when the project is scheduled to run. If I trigger a manual build it works fine. Probably is not enough information to understand the problem. Please tell me what info do you need and how to get it. Here is the log: INFO | jvm 1| 2007/04/13 10:30:00 | 2007-04-13 10:30:00,020 [defaultScheduler_Worker-11] INFO SchedulesActivator - > Executing build job (test)... INFO | jvm 1| 2007/04/13 10:30:00 | 2007-04-13 10:30:00,036 [defaultScheduler_Worker-11] INFO Continuum - Enqueuing 'NSD' (Build definition id=1). INFO | jvm 1| 2007/04/13 10:30:00 | 2007-04-13 10:30:00,036 [defaultScheduler_Worker-11] INFO Continuum - Enqueuing 'OSS_FWK' (Build definition id=11). INFO | jvm 1| 2007/04/13 10:30:00 | 2007-04-13 10:30:00,223 [Thread-2] INFO ContinuumScm - Updating project: id: '1', name 'NSD'. INFO | jvm 1| 2007/04/13 10:30:00 | 2007-04-13 10:30:00,411 [Thread-2] INFO ScmManager - Updating 'c:\installed\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1' from 'Y:\wran_cm_nsd'. INFO | jvm 1| 2007/04/13 10:31:00 | 2007-04-13 10:31:00,411 [Thread-2] INFO BuildController- The project was not built because there are no changes. INFO | jvm 1| 2007/04/13 10:31:00 | 2007-04-13 10:31:00,489 [Thread-2] INFO ContinuumScm - Updating project: id: '11', name 'OSS_FWK'. INFO | jvm 1| 2007/04/13 10:31:00 | 2007-04-13 10:31:00,521 [Thread-2] INFO ScmManager - Updating 'c:\installed\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\11' from 'Y:\ossrc_fwk'. INFO | jvm 1| 2007/04/13 10:31:09 | 2007-04-13 10:31:09,786 [Thread-2] ERROR BuildController- Error while building project. INFO | jvm 1| 2007/04/13 10:31:09 | org.apache.maven.continuum.scm.ContinuumScmException: Error while update sources. INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) INFO | jvm 1| 2007/04/13 10:31:09 | at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) INFO | jvm 1| 2007/04/13 10:31:09 | at java.lang.Thread.run(Thread.java:595) INFO | jvm 1| 2007/04/13 10:31:09 | Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command. INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.provider.local.LocalScmProvider.update(LocalScmProvider.java:191) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) INFO | jvm 1| 2007/04/13 10:31:09 | ... 5 more INFO | jvm 1| 2007/04/13 10:31:09 | Caused by: java.lang.NullPointerException INFO | jvm 1| 2007/04/13 10:31:09 | at java.util.Date.getMillisOf(Date.java:938) INFO | jvm 1| 2007/04/13 10:31:09 | at java.util.Date.after(Date.java:911) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:89) INFO | jvm 1| 2007/04/13 10:31:09 | at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) INFO | jvm 1| 2007/04/13 10:31:09 | ... 9 more > NullPointer in local provider update when a new file is added > - > > Key: SCM-193 > URL: http://jira.codehaus.org/browse/SCM-193 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-lo
[jira] Closed: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-230. Resolution: Fixed Fix Version/s: 1.0-beta-5 Applied. Thanks > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature >Reporter: solo turn >Assignee: Emmanuel Venisse > Fix For: 1.0-beta-5 > > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz, > maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tar.gz, > maven-scm-provider-hg.tgz, site-patch, site-patch-2 > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- 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: (MPASPECTJ-29) Add ability to pass extra params to AspectJ compiler
[ http://jira.codehaus.org/browse/MPASPECTJ-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartlomiej Zdanowski closed MPASPECTJ-29. - Resolution: Won't Fix I'm sorry. I've chosen wrong project. The right project should be MOJO with aspectJ component. A new issue http://jira.codehaus.org/browse/MOJO-746 > Add ability to pass extra params to AspectJ compiler > > > Key: MPASPECTJ-29 > URL: http://jira.codehaus.org/browse/MPASPECTJ-29 > Project: maven-aspectj-plugin > Issue Type: Improvement >Affects Versions: 4.0 > Environment: Any >Reporter: Bartlomiej Zdanowski > > Command line aspectj accepts many arguments, for example > -XaddSerialVersionUID > Please add ability to pass them to maven-aspectj-plugin. > If there's a way, please add also ability to set Xlint specific options to > override org/aspectj/weaver/XlintDefault.properties, similar to global > "Xlint" setting. > Or ability to pass external XlintDefault.properties. -- 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: (MPASPECTJ-29) Add ability to pass extra params to AspectJ compiler
[ http://jira.codehaus.org/browse/MPASPECTJ-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MPASPECTJ-29: --- Fix Version/s: (was: 4.0) Can't you do that with the maven.aspectj.argfiles option? > Add ability to pass extra params to AspectJ compiler > > > Key: MPASPECTJ-29 > URL: http://jira.codehaus.org/browse/MPASPECTJ-29 > Project: maven-aspectj-plugin > Issue Type: Improvement >Affects Versions: 4.0 > Environment: Any >Reporter: Bartlomiej Zdanowski > > Command line aspectj accepts many arguments, for example > -XaddSerialVersionUID > Please add ability to pass them to maven-aspectj-plugin. > If there's a way, please add also ability to set Xlint specific options to > override org/aspectj/weaver/XlintDefault.properties, similar to global > "Xlint" setting. > Or ability to pass external XlintDefault.properties. -- 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: (MPASPECTJ-29) Add ability to pass extra params to AspectJ compiler
Add ability to pass extra params to AspectJ compiler Key: MPASPECTJ-29 URL: http://jira.codehaus.org/browse/MPASPECTJ-29 Project: maven-aspectj-plugin Issue Type: Improvement Affects Versions: 4.0 Environment: Any Reporter: Bartlomiej Zdanowski Fix For: 4.0 Command line aspectj accepts many arguments, for example -XaddSerialVersionUID Please add ability to pass them to maven-aspectj-plugin. If there's a way, please add also ability to set Xlint specific options to override org/aspectj/weaver/XlintDefault.properties, similar to global "Xlint" setting. Or ability to pass external XlintDefault.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse reopened SCM-230: -- Assignee: Emmanuel Venisse (was: Joakim Erdfelt) > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature >Reporter: solo turn >Assignee: Emmanuel Venisse > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz, > maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tar.gz, > maven-scm-provider-hg.tgz, site-patch, site-patch-2 > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- 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: (MASSEMBLY-194) unnecessary dependency expansion regression
[
http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92824
]
Stephane Nicoll commented on MASSEMBLY-194:
---
Another problem. I have more stuff in my libs directory that I don't want (it's
packaged in another dir of my assembly). So I try to exclude them explicitely.
My config is like that
{code:xml}
true
libs
${artifactId}.${extension}
runtime
com.foo.samples:*
[...]
com.foo.shared.blah:*
log4j:log4j
true
samples/dependencies/libs
${artifactId}.${extension}
runtime
com.foo.shared.blah:*
log4j:log4j
{code}
The blah and log4j stuff are indeed packaged in samples/dependencies/libs *AND*
in libs.
Running Maven outputs the following:
{noformat}
[INFO] Processing DependencySet (output=libs)
[WARNING] The following patterns were never triggered in this artifact
exclusion filter:
o 'com.foo.shared.blah:*'
[INFO] Processing DependencySet (output=samples/dependencies/libs)
{noformat}
I am rolling back to 2.2-snap.
> unnecessary dependency expansion regression
> ---
>
> Key: MASSEMBLY-194
> URL: http://jira.codehaus.org/browse/MASSEMBLY-194
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.2-beta-1
>
> Attachments: assembly-test.tar.gz
>
>
> See the attached test project. It requires that you've run mvn clean install
> for continuum previously so there is a sizable dependency in the repo to play
> with.
> If you build with assembly 2.1, only the tarball is expanded and included in
> the final distribution (about 27mb)
> With 2.2-beta-1, all the transitive dependencies are also expanded and
> included (about 65mb).
> This is a functionality change, but also consumes a very large amount of
> memory and CPU.
--
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: (MASSEMBLY-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92823 ] Stephane Nicoll commented on MASSEMBLY-194: --- To be more specific. What I've encountered always with 2.2-SNAPSHOT was the following behavior: com.foo:bar:1.1 \ com.company:something:1.2 \ com.another:blah:1.3 If I have the following config, *all* the dependencies were excluded (knowing that \ means transitive deps of) com.foo:bar Now, it excludes com.foo:bar but it does not exclude its transitive deps. Am I right? Is there any way to accomplish this? > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.2-beta-1 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- 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-1482) Upload javadoc attachment for xmlbeans:xbean:jar:2.2.0
Upload javadoc attachment for xmlbeans:xbean:jar:2.2.0 -- Key: MAVENUPLOAD-1482 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1482 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/xbean-2.2.0-javadoc.jar http://xmlbeans.apache.org/ Note that this is just the javadocs. The main artifact is already on ibiblio, but it is missing 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: (MASSEMBLY-194) unnecessary dependency expansion regression
[
http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92822
]
Stephane Nicoll commented on MASSEMBLY-194:
---
This changes has broken my build apparently. I've tried to switch this
parameter on/off without success.
I have a project that builds an assembly and relies on assemblies A, B, C, D,
E. Each of those assemblies are made from a complex project so it brings extra
deps as well.
What I have is the following entry:
true
libs
${artifactId}.${extension}
runtime
com.foo.bar:*
Where com.foo.bar is the groupId of A,B,C,D,E. With beta-1,transitive
dependencies of A,B,C,D,E *are* packaged in the libs directory. With my local
2.2.-SNAPSHOT that I build before this fix, it doesn't.
I think this change introduced a regression. I am trying to reproduce with a
simple project since the one i'm using is fairly complex.
> unnecessary dependency expansion regression
> ---
>
> Key: MASSEMBLY-194
> URL: http://jira.codehaus.org/browse/MASSEMBLY-194
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.2-beta-1
>
> Attachments: assembly-test.tar.gz
>
>
> See the attached test project. It requires that you've run mvn clean install
> for continuum previously so there is a sizable dependency in the repo to play
> with.
> If you build with assembly 2.1, only the tarball is expanded and included in
> the final distribution (about 27mb)
> With 2.2-beta-1, all the transitive dependencies are also expanded and
> included (about 65mb).
> This is a functionality change, but also consumes a very large amount of
> memory and CPU.
--
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-1481) Upload com.novell.ldap:jldap:jar:4.3 to ibiblio
Upload com.novell.ldap:jldap:jar:4.3 to ibiblio --- Key: MAVENUPLOAD-1481 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1481 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/jldap-4.3-bundle.jar http://www.openldap.org/jldap/ The LDAP Class Libraries for Java (JLDAP) enable you to write applications to access, manage, update, and search for information stored in directories accessible using LDAPv3. -- 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-1480) Upload org.openspml:openspml:jar:0.5 to ibiblio
Upload org.openspml:openspml:jar:0.5 to ibiblio --- Key: MAVENUPLOAD-1480 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1480 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/openspml-0.5-bundle.jar http://www.openspml.org/ An open source client code that supports the Service Provisioning Markup Language (SPML) developed by the OASIS Provisioning Services Technical Committee (PSTC). -- 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: (MPJALOPY-12) Add a property that controls the source code encoding
[ http://jira.codehaus.org/browse/MPJALOPY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPJALOPY-12. - Assignee: Lukas Theussl Resolution: Fixed Patch applied, snapshot deployed. Thanks! > Add a property that controls the source code encoding > - > > Key: MPJALOPY-12 > URL: http://jira.codehaus.org/browse/MPJALOPY-12 > Project: maven-jalopy-plugin > Issue Type: Improvement > Environment: working on a machine with diffrent (default) encoding > then the java source code >Reporter: Joachim Bader >Assignee: Lukas Theussl > Fix For: 1.5.1 > > Attachments: patch.diff > > > from http://jalopy.sourceforge.net/existing/plugin-ant-usage.html > "encoding Sets the encoding that controls how Jalopy interprets text > files containing characters beyond the ASCII character set. Defaults to the > platform default encoding." -- 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-1479) Upload org.hibernate:hibernate:jar:3.2.3.ga to ibiblio
Upload org.hibernate:hibernate:jar:3.2.3.ga to ibiblio -- Key: MAVENUPLOAD-1479 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1479 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/hibernate-3.2.3.ga-bundle.jar http://www.hibernate.org/ Relational Persistence for Java -- 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-516) Fix file name of xml-apis 1.3.04 sources attachment
Fix file name of xml-apis 1.3.04 sources attachment --- Key: MEV-516 URL: http://jira.codehaus.org/browse/MEV-516 Project: Maven Evangelism Issue Type: Task Reporter: Matt Whitlock The sources file has the wrong file name. It is: xml-apis-1.3.04-source.jar It should be: xml-apis-1.3.04-sources.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] Created: (MAVENUPLOAD-1478) Upload fastutil:fastutil:jar:5.0.9 to ibiblio
Upload fastutil:fastutil:jar:5.0.9 to ibiblio - Key: MAVENUPLOAD-1478 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1478 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/fastutil-5.0.9-bundle.jar http://fastutil.dsi.unimi.it/ fastutil extends the Java Collections Framework by providing type-specific maps, sets, lists and queues with a small memory footprint and fast access and insertion; it also includes a fast I/O API for binary and text files. -- 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-1477) Upload c3p0:c3p0:jar:0.9.1.1 to ibiblio
Upload c3p0:c3p0:jar:0.9.1.1 to ibiblio --- Key: MAVENUPLOAD-1477 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1477 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/c3p0-0.9.1.1-bundle.jar http://c3p0.sourceforge.net/ c3p0 is an easy-to-use library for augmenting traditional (DriverManager-based) JDBC drivers with JNDI-bindable DataSources, including DataSources that implement Connection and Statement Pooling, as described by the jdbc3 spec and jdbc2 std extension. -- 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-1476) Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio
Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio -- Key: MAVENUPLOAD-1476 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1476 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/bcprov-1.36-bundle.jar http://www.bouncycastle.org/java.html The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the newly released J2ME) with the additional infrastructure to conform the algorithms to the JCE framework. -- The JDK14 version of bcprov 1.36 is already on ibiblio at /maven2/bouncycastle/bcprov-jdk14/136, but its POM file is woefully incomplete, its groupId is not in reverse domain order, and it lacks sources and javadoc attachments. I am submitting this bundle that contains the JDK14, JDK15, and JDK16 versions of bcprov 1.36 along with sources and javadoc attachments for each. The POM file in my bundle includes name, description, URL, and license information. -- 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
