[jira] Commented: (MEV-353) I need to have these 4 pom's posted to reference some bea 3rd party artifacts to support the weblogic plugin
[ http://jira.codehaus.org/browse/MEV-353?page=comments#action_59865 ] Joerg Schaible commented on MEV-353: No, BEA is using weblogic.* (at least in 8.x) for its own classes (although especially the weblogic-x.y.jar is a monster of 40MB containing *a lot* of other stuff also e.g. Rhino, several javax.* and classes from other 3rd party libs). I need to have these 4 pom's posted to reference some bea 3rd party artifacts to support the weblogic plugin Key: MEV-353 URL: http://jira.codehaus.org/browse/MEV-353 Project: Maven Evangelism Type: Task Components: Missing POM Reporter: Scott Ryan Attachments: weblogic-8.1.pom, weblogic-9.0.pom, webservices-8.1.pom, webservices-9.0.pom I am attaching 4 pom files to support the weblogic plugin. These will allow local installation of the 3rd party jars and still support clean builds with the weblogic plugin. Please feel free to correct me or ask any additional questions needed to get this done. thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1577) dependencyManagent does not work for transient dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_59636 ] Joerg Schaible commented on MNG-1577: - This depends. Think of jBoss with its unified classloader and an ear with two integrated wars. If each war has a dependency with a different version, both dependend jars will be in the classpath. It is pure coincidence which one is taken. This issue is therefore our showstopper in M102 to M2 migration. dependencyManagent does not work for transient dependencies --- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.0.4 The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59319 ] Joerg Schaible commented on MEV-346: You cannot find such a version anyways on xpp3's home. Use 1.1.3.4.O and either xpp3 or xpp3_min as artifactId. Both are available at ibiblio. xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-745) xpp3 pull parser
[ http://jira.codehaus.org/browse/MAVENUPLOAD-745?page=comments#action_58902 ] Joerg Schaible commented on MAVENUPLOAD-745: Michael, just wanna say thank you for doing this. I wanted to do the same for ages and never found time. I always wondered what obscure versions were addressed in ibiblio with those -1.1.3.4-RCx releases. xpp3 pull parser Key: MAVENUPLOAD-745 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-745 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: xpp3-1.1.3.4.O-bundle.jar, xpp3-min-1.1.3.4.O-bundle.jar, xpp3-xpath-1.1.3.4.O-bundle.jar Latest release of all 3 versions of the xpp3 pull parser. Files grabbed from http://www.extreme.indiana.edu/dist/java-repository/xpp3/jars/. The current state of the xpp3 versioning is a big mess. Sometimes, the variation (min, xpath) is added to the version, sometimes used as classifier, even though the jars have huge differences. I believe the big differences justify different artifactIds, classifiers are for similar jars that were built differently (e.g. signed vs. unsigned). Upload bundles were assembled manually, theres no way I can reproduce that Ant build (ever). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-730) Backport-util-concurrent-2.1
Backport-util-concurrent-2.1 Key: MAVENUPLOAD-730 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-730 Project: maven-upload-requests Type: Sub-task Reporter: Joerg Schaible Superseeds MAVENUPLOAD-728, POM there misses information (license, packaging). This bundle contains also source 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-730) Backport-util-concurrent-2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-730?page=comments#action_58320 ] Joerg Schaible commented on MAVENUPLOAD-730: OK, done, bundle is updated. The -sources.jar also contains the javadocs, should that be a separate -javadoc(s).jar ? If yes, I'll update the bundle again ... Backport-util-concurrent-2.1 Key: MAVENUPLOAD-730 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-730 Project: maven-upload-requests Type: Sub-task Reporter: Joerg Schaible Superseeds MAVENUPLOAD-728, POM there misses information (license, packaging). This bundle contains also source 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-730) Backport-util-concurrent-2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-730?page=comments#action_58322 ] Joerg Schaible commented on MAVENUPLOAD-730: OK. Bundle updated again. You can continue. Thanks. Backport-util-concurrent-2.1 Key: MAVENUPLOAD-730 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-730 Project: maven-upload-requests Type: Sub-task Reporter: Joerg Schaible Superseeds MAVENUPLOAD-728, POM there misses information (license, packaging). This bundle contains also source 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=comments#action_54010 ] Joerg Schaible commented on MNG-1683: - Hi Oliver, seems to be a usefiul addition. We have some webapps, where we use the same javascript framework. Currently it is stored multiple times ... once for each webapp :-/ This addition would eliminate that need. type zip for packaging ? Key: MNG-1683 URL: http://jira.codehaus.org/browse/MNG-1683 Project: Maven 2 Type: Improvement Environment: not significant Reporter: Olivier Lamy Attachments: MNG-1683.tar.gz, maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz Hi, I don't know if the artifact type zip exists (I think not after few test). But I want to separate the html content and the webapp content (classes, configuration files and so on). The use case is to separate this different works (html designer and java developpement) and production installation (one is to an http server and the other is on an app server) in two artifacts with separate versionning. But the packagingzip/packaging is not recognized. Then I would like to use it as an artifact with maven's features (snapshot, pom, version, goals : install, deploy release and all others). Add it to the webapp dependencies (needed only for developpment or unit tests). With this type of dependency the zip content could be unpacked to a directory in the exploded webapp. (certainly need hack on the maven-war-plugin). I have certainly the workaround to declare this as jar and using the assembly plugin to generate a zip. But I can't use install release deploy or something else to manage the generated zip which is not an artifact. Thanks for help or workaround. - Olivier -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_53697 ] Joerg Schaible commented on MPARTIFACT-61: -- @Arnaud: My key looks exactly the same and was generated with Cygwin's ss-keygen. The file has Unix line endings though ... @Lukas: scpexe works for me with M2 despite the fact that it insists on a key even if an agent is running (WAGON-27). scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible Priority: Blocker Fix For: 1.5.3 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.forehead.Forehead.run(Forehead.java:551) at
[jira] Commented: (MEV-254) easymock 1.1 invalid scope for junit
[ http://jira.codehaus.org/browse/MEV-254?page=comments#action_53138 ] Joerg Schaible commented on MEV-254: Doesn't easymock extend JUnit ? Then the scope is perfect with compile. If *you* use easymock to test your app code, you must put easymock with scope test into your dependencies. This should change the scope for the transitive dep to junit also. easymock 1.1 invalid scope for junit Key: MEV-254 URL: http://jira.codehaus.org/browse/MEV-254 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Jean-Laurent de Morlhon easymock 1.1 provides a default compile scope for JUnit but it should be scopetest/scope http://www.ibiblio.org/maven2/easymock/easymock/1.1/easymock-1.1.pom workaround: add scopetest/scope to the JUnit dependencies in your local repository -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_52862 ] Joerg Schaible commented on MPARTIFACT-61: -- Well, as already said, exec for Linux Windows is quite different. For scp I have always an AuthenticationException for my privatekey and passphrase. I can use ssh -i id_file without problems though ... = % jar:deploy: [echo] Deploying... Using userBuildPropertiesFile: C:\Dokumente und Einstellungen\jos\build.properties Using projectPropertiesFile: C:\Work\Projects\commons\test\project.properties Using projectBuildPropertiesFile: C:\Work\Projects\commons\test\build.properties Will deploy to 1 repository(ies): elsag Deploying to repository: elsag Failed to deploy to: elsag Reason: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:164) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:123) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:90) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deployFiles(DefaultArtifactDeployer.java:376) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:324) 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.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: com.jcraft.jsch.JSchException: Auth fail at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:158) ... 31 more scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible Priority: Blocker Fix For: 1.5.3 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):
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_52621 ] Joerg Schaible commented on MPARTIFACT-61: -- Unfortunately we are stuck to M102 and I would really appreciate another compatible version 1.5.3... scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible 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.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_52497 ] Joerg Schaible commented on MPARTIFACT-61: -- According to Brett 1.5.2 is the last version to be usable with M102. No, I cannot use M11 since we use XML entities quite extensivly. Therefore I need an artifact-plugin, that is able to write resolved POMs to prepare the transition to M2. scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible 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.forehead.Forehead.run(Forehead.java:551) at
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_52498 ] Joerg Schaible commented on MPARTIFACT-61: -- BTW: The exec mechanism may be quite different in Linux. scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible 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.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (MEV-237) Sun artifactId naming mess
[ http://jira.codehaus.org/browse/MEV-237?page=comments#action_51977 ] Joerg Schaible commented on MEV-237: Needed some time to find it also: http://java.sun.com/webservices/archive.html See the versions.txt in the root of the installation (and compare with the manifest entries) ;-) I also downloaded jwsdp-1.6 now and the situation is quite the same (although different versions again, see docs/index.html) - the jars are all signed and have different names compared to the standalone packages downloadable form Sun. The artifactId should be the name of the jar This does not even apply for the standalone packages from Sun. E.g. SAAJ (http://java.sun.com/xml/downloads/saaj.html) is called saaj-1_2-fr-api.jar in the package and we have it as saaj-1.2.pom. Sun artifactId naming mess -- Key: MEV-237 URL: http://jira.codehaus.org/browse/MEV-237 Project: Maven Evangelism Type: Bug Reporter: Joerg Schaible Looking at the current javax.xml poms in the repo, there is a mess in the naming of the artifact. I have an jwsdp-1.4 installed and if I look into the included packages, most of them are divided into an package-api and package-impl. If I look now into the repository some of them are also divided, but some have dropped the -api part: jwsdp-1.4 M2 repo --- jaxb-api --- jaxb-api jaxb-impl --- jaxb-impl jaxp-api --- jaxp jaxr-api --- jaxr (?) jaxr-impl --- N/A jaxrpc-api --- jaxrpc-api jaxrpc-impl --- jaxrpc (?) saaj-api --- saaj (?) saaj-impl --- saaj-impl (proposed in MEV-236) This mess makes it quite difficult to provide other poms, e.g. I currently don't know how to provide poms for jaxrpc-api/impl-1.1.2. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1674) configure test-jar to include only special classes of the test source
configure test-jar to include only special classes of the test source - Key: MNG-1674 URL: http://jira.codehaus.org/browse/MNG-1674 Project: Maven 2 Type: Improvement Components: maven-jar-plugin Reporter: Joerg Schaible Priority: Minor The test-jar currently contains all test classes, but often you just want to share only some parts of it, e.g. a specialized abstract TestCase or a test toolkit or some mock classes, but not the complete unit test for an asrtifact. The plugin configuration shoulds contain a section with an includes/excludes pattern set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-235) saaj-1.2.1
saaj-1.2.1 -- Key: MEV-235 URL: http://jira.codehaus.org/browse/MEV-235 Project: Maven Evangelism Type: Task Components: Missing POM Reporter: Joerg Schaible Artifact part of jwsdp-1.4 as saaj/lib/saaj-api.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-235) saaj-1.2.1
[ http://jira.codehaus.org/browse/MEV-235?page=all ] Joerg Schaible updated MEV-235: --- Attachment: saaj-1.2.1.pom The missing POM. BTW: The Manifest of this jar claims the spec to be 1.2, but the jar is signed despite to the saaj-1_2-fr-api.jar available from http://java.sun.com/xml/downloads/saaj.html, the jwsdp package claims to include saaj 1.2.1 and the manifest of the contained saaj-impl uses spec 1.2.1 ... what a mess! saaj-1.2.1 -- Key: MEV-235 URL: http://jira.codehaus.org/browse/MEV-235 Project: Maven Evangelism Type: Task Components: Missing POM Reporter: Joerg Schaible Attachments: saaj-1.2.1.pom Artifact part of jwsdp-1.4 as saaj/lib/saaj-api.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-236) saaj-impl-1.2.1
[ http://jira.codehaus.org/browse/MEV-236?page=all ] Joerg Schaible updated MEV-236: --- Attachment: saaj-impl-1.2.1.pom The POM to the saaj-impl.jar saaj-impl-1.2.1 --- Key: MEV-236 URL: http://jira.codehaus.org/browse/MEV-236 Project: Maven Evangelism Type: Task Reporter: Joerg Schaible Attachments: saaj-impl-1.2.1.pom Artifact contained in jwsdp-1.4 in saaj/lib/saaj-impl.jar. See MEV-235 for futher comment. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-236) saaj-impl-1.2.1
saaj-impl-1.2.1 --- Key: MEV-236 URL: http://jira.codehaus.org/browse/MEV-236 Project: Maven Evangelism Type: Task Reporter: Joerg Schaible Attachments: saaj-impl-1.2.1.pom Artifact contained in jwsdp-1.4 in saaj/lib/saaj-impl.jar. See MEV-235 for futher comment. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-237) Sun artifactId naming mess
Sun artifactId naming mess -- Key: MEV-237 URL: http://jira.codehaus.org/browse/MEV-237 Project: Maven Evangelism Type: Bug Reporter: Joerg Schaible Looking at the current javax.xml poms in the repo, there is a mess in the naming of the artifact. I have an jwsdp-1.4 installed and if I look into the included packages, most of them are divided into an package-api and package-impl. If I look now into the repository some of them are also divided, but some have dropped the -api part: jwsdp-1.4 M2 repo --- jaxb-api --- jaxb-api jaxb-impl --- jaxb-impl jaxp-api --- jaxp jaxr-api --- jaxr (?) jaxr-impl --- N/A jaxrpc-api --- jaxrpc-api jaxrpc-impl --- jaxrpc (?) saaj-api --- saaj (?) saaj-impl --- saaj-impl (proposed in MEV-236) This mess makes it quite difficult to provide other poms, e.g. I currently don't know how to provide poms for jaxrpc-api/impl-1.1.2. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1674) configure test-jar to include only special classes of the test source
[ http://jira.codehaus.org/browse/MNG-1674?page=comments#action_51972 ] Joerg Schaible commented on MNG-1674: - Well, regarding the 1-source-1-artifact rule, the complete concept of the subtypes is flawed ... but they're a pragmatic solution for special cases. Normally I agree, but in this case you have that circular dependency and you cannot avoid it. The standard way seems something like (see the build section): http://svn.picocontainer.codehaus.org/java/picocontainer/trunk/tck/pom.xml?rev=2755view=markup With test-jar you already have 2/3 of the solution, why not complete it ? configure test-jar to include only special classes of the test source - Key: MNG-1674 URL: http://jira.codehaus.org/browse/MNG-1674 Project: Maven 2 Type: Improvement Components: maven-jar-plugin Reporter: Joerg Schaible Priority: Minor The test-jar currently contains all test classes, but often you just want to share only some parts of it, e.g. a specialized abstract TestCase or a test toolkit or some mock classes, but not the complete unit test for an asrtifact. The plugin configuration shoulds contain a section with an includes/excludes pattern set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1674) configure test-jar to include only special classes of the test source
[ http://jira.codehaus.org/browse/MNG-1674?page=comments#action_51973 ] Joerg Schaible commented on MNG-1674: - Related issue: MNG-1330 (BTW: why can a user not create real JIRA links between issues ??) configure test-jar to include only special classes of the test source - Key: MNG-1674 URL: http://jira.codehaus.org/browse/MNG-1674 Project: Maven 2 Type: Improvement Components: maven-jar-plugin Reporter: Joerg Schaible Priority: Minor The test-jar currently contains all test classes, but often you just want to share only some parts of it, e.g. a specialized abstract TestCase or a test toolkit or some mock classes, but not the complete unit test for an asrtifact. The plugin configuration shoulds contain a section with an includes/excludes pattern set. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1664) Write mojos w/Groovy
[ http://jira.codehaus.org/browse/MNG-1664?page=comments#action_51749 ] Joerg Schaible commented on MNG-1664: - Hi Jason, is this somehow related to the effort done by Éric Burghard, that announced something similar at the Coocoon list? Might be interesting for a joined work. http://thread.gmane.org/gmane.text.xml.cocoon.devel/58463 - Jörg Write mojos w/Groovy Key: MNG-1664 URL: http://jira.codehaus.org/browse/MNG-1664 Project: Maven 2 Type: New Feature Components: Plugin Creation Tools Versions: 2.0 Reporter: Jason Dillon Attachments: maven2-groovy-mojo-support.tar.gz Attached is an archive containing 3 modules: * plexus-groovy-factory * maven-plugin-tools-groovy * groovytest-maven-plugin plexus-groovy-factory is a plexus component factory, which allows Groovy objects to be used as components inside of Plexus. I started with the existing module of the same name in the plexus project, but most of it changed, so I just included the entire module instead of providing a patch. Tests included. maven-plugin-tools-groovy provides the ability to extract MojoDescriptors from one or more .groovy sources. This is based off of the beanshell extractor.sh... its kinda hacky, but functions _well enough_ for now. groovytest-maven-plugin is used to test. groovytest-maven-plugin is just a simple maven plugin that uses the new groovy script support. It shows that a .groovy can use other .groovy sources inside of the plugin, and shows that the descriptor extractor functions. Its basically useful for integration testing. * * * Someone should check update the version details for the parent pom of these modules. I just used whatever I had on my local system to get it working. This plugin depends on Groovy 1.0 JSR 05, but 04 will sorta work, but will not function with included classes in the same jar. Since 04 was just releases yesterday, these modules depend on 05 SNAPSHOT, which should be available on the codehaus ci repo. When 1.0 is released this dep should be updated to that version. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1577) dependencyManagent does not work for transient dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_51498 ] Joerg Schaible commented on MNG-1577: - Well, with M1 we used entities to ensure global version consistency among different projects. For M2 the dependencyManagement was presented as solution for this. If it is not DM, what can we use else? dependencyManagent does not work for transient dependencies --- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.0.1 The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1609) Force update of files in the repo if checksum has been updated
Force update of files in the repo if checksum has been updated -- Key: MNG-1609 URL: http://jira.codehaus.org/browse/MNG-1609 Project: Maven 2 Type: Improvement Components: maven-core Versions: 2.0 Reporter: Joerg Schaible Maven should support an option -ccu, --check-checksum-update that looks in the remote repositories for updated checksums and redownloads the corresponding file (artifact, pom, ...). Especially pom updates are currently really cumbersome, since every user has to clean them in his local repo. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1615) LICENSE.txt no longer saved in META-INF
LICENSE.txt no longer saved in META-INF --- Key: MNG-1615 URL: http://jira.codehaus.org/browse/MNG-1615 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Joerg Schaible Priority: Minor The M1 jar plugin copied the LICENSE.txt file into the MTEA-INF folder of the resulting artifact. The jar plugin for M2 does this no longer. It should be at least configurable. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1586) activeByDefault is ignored
activeByDefault is ignored -- Key: MNG-1586 URL: http://jira.codehaus.org/browse/MNG-1586 Project: Maven 2 Type: Bug Components: maven-project Versions: 2.0 Reporter: Joerg Schaible Priority: Minor The activation of a profile by the activeByDefault element in settings.xml is ignored. The profile does not get active automatically. As workaround it must be explicitly listed in the activeProfiles section. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-208) logger impls should be optional for commons-logging
logger impls should be optional for commons-logging --- Key: MEV-208 URL: http://jira.codehaus.org/browse/MEV-208 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Joerg Schaible POMs of commons-logging should define logger implementations as optional dependencies (as it already is for 1.0.4). Patch for 1.0.[123]. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-208) logger impls should be optional for commons-logging
[ http://jira.codehaus.org/browse/MEV-208?page=all ] Joerg Schaible updated MEV-208: --- Attachment: commons-logging.patch logger impls should be optional for commons-logging --- Key: MEV-208 URL: http://jira.codehaus.org/browse/MEV-208 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Joerg Schaible Attachments: commons-logging.patch POMs of commons-logging should define logger implementations as optional dependencies (as it already is for 1.0.4). Patch for 1.0.[123]. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-206) commons-io: missing dep to junit and wrong scope
commons-io: missing dep to junit and wrong scope Key: MEV-206 URL: http://jira.codehaus.org/browse/MEV-206 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Joerg Schaible The poms of commons-io-1.0 and -1.1 have either no dep to junit at all or the dep has compile time scope instead of 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-206) commons-io: missing dep to junit and wrong scope
[ http://jira.codehaus.org/browse/MEV-206?page=all ] Joerg Schaible updated MEV-206: --- Attachment: commons-io.patch commons-io: missing dep to junit and wrong scope Key: MEV-206 URL: http://jira.codehaus.org/browse/MEV-206 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Joerg Schaible Attachments: commons-io.patch The poms of commons-io-1.0 and -1.1 have either no dep to junit at all or the dep has compile time scope instead of 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1571) Wrong calculation of transient dependecies if artifact is referenced from different scopes
Wrong calculation of transient dependecies if artifact is referenced from different scopes -- Key: MNG-1571 URL: http://jira.codehaus.org/browse/MNG-1571 Project: Maven 2 Type: Bug Components: maven-core Reporter: Joerg Schaible I have an artifact A (elsag-test below), that is used by other projects only for the tests. A has a dependency to commons-logging. Artifact B has a compile-time dependency to an artifact, that also has a dependency on commons-logging. Nevertheless, the resulting scope for commons-logging is wrongly calculated as test and the compilation fails. = % [DEBUG] Retrieving parent-POM from the repository for project: com.elsagsolutions.commons:super-project:pom:1.1-SNAPSHOT [DEBUG] meta: using locally installed snapshot [DEBUG] com.elsagsolutions.commons:elsag-test:jar:1.2-SNAPSHOT (selected for test) [DEBUG] cglib:cglib-nodep:jar:2.1_3 (selected for test) [DEBUG] commons-logging:commons-logging:jar:1.0.4 (selected for test) [DEBUG] jmock:jmock-cglib:jar:1.0.1 (selected for test) [DEBUG] jmock:jmock:jar:1.0.1 (selected for test) [DEBUG] junit:junit:jar:3.8.1 (selected for test) [DEBUG] commons-httpclient:commons-httpclient:jar:2.0.2 (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0.4 (setting scope to: compile) [DEBUG] commons-logging:commons-logging:jar:1.0.3 (removed - nearer found: 1.0.4) [DEBUG] commons-logging:commons-logging:jar:1.0.3 (selected for compile) [DEBUG] commons-io:commons-io:jar:1.0 (selected for compile) [DEBUG] junit:junit:jar:3.8.1 (selected for compile) = % [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Work\Projects\commons\lang\src\java\com\elsagsolutions\lang\net\AbstractSocketStreamServer.java:[14,34] package org.apache.commons.logging does not exist = % If I add commons-logging as direct dependency of B it works: = % [DEBUG] Retrieving parent-POM from the repository for project: com.elsagsolutions.commons:super-project:pom:1.1-SNAPSHOT [DEBUG] meta: using locally installed snapshot [DEBUG] com.elsagsolutions.commons:elsag-test:jar:1.2-SNAPSHOT (selected for test) [DEBUG] cglib:cglib-nodep:jar:2.1_3 (selected for test) [DEBUG] commons-logging:commons-logging:jar:1.0.4 (selected for test) [DEBUG] jmock:jmock-cglib:jar:1.0.1 (selected for test) [DEBUG] jmock:jmock:jar:1.0.1 (selected for test) [DEBUG] junit:junit:jar:3.8.1 (selected for test) [DEBUG] commons-logging:commons-logging:jar:1.0.4 (selected for compile) [DEBUG] commons-httpclient:commons-httpclient:jar:2.0.2 (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0.3 (removed - nearer found: 1.0.4) [DEBUG] commons-logging:commons-logging:jar:1.0.3 (selected for compile) = % Unfortunately this introduces a dependency for commons-logging, therefore I wanted to set the dep at least optional, but then commons-logging is again not available at compile time. Might be related to MNG-1378. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1573) No debug output for optional dependencies
No debug output for optional dependencies - Key: MNG-1573 URL: http://jira.codehaus.org/browse/MNG-1573 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Joerg Schaible Running maven with -X is currently the only way to see, what dependencies are triggered. Unfortunately all optional dependencies do not appear in the debug output, neither where the (transitive) dependencies are printed nor in the output of the resulting classpath used to compile the source. Compilation is fine though, the classes are found. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1577) dependencyManagent does not work for transient dependencies
dependencyManagent does not work for transient dependencies --- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Joerg Schaible The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1050) [2.0,) should not select 3.0 and above by default
[ http://jira.codehaus.org/browse/MNG-1050?page=comments#action_50879 ] Joerg Schaible commented on MNG-1050: - IMHO [2.0,) is perfect for any new version. It depends on the version naming policy of the depending artifact's project, if a new release is compatible. E.g. a lot of Jakarta common jars are not even compatible for minor version upgrades, while e.g. CGLIB 2.x is backward compatible to 1.x. Additionally it depends on the current artifact's usega of the dependency. If only API is used that is part of the official API (e.g. avalon-framework-api) or also classes that are supposed to be internal (avalon-framework-impl). So the author of an artifact may define the compatible version range for a dependency depending on the usage e.g. [2.0,3.0) if he really cares. A compatible-since would help tremendously though ;-) Also it should be possible to make a hint, if the (major?) versions of a library can coexist, e.g. webwork 1.x and webwork 2.x. This is interesting for library authors, that want to support both versions in their project (as e.g. nanocontainer-nanowar does for webwork). ASM 1.x and 2.x is an example, where this is not possible. [2.0,) should not select 3.0 and above by default - Key: MNG-1050 URL: http://jira.codehaus.org/browse/MNG-1050 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Fix For: 2.1 I think that we need to assume major versions are incompatible as it is easier to later state compatibility than fix it when broken. This might just be a default compatibility scheme, but a project can define its own (eg, compatible-since 2.1). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1570) Testing from a parent POM fails, since current work directory is no longer the basedir of the subproject
Testing from a parent POM fails, since current work directory is no longer the
basedir of the subproject
Key: MNG-1570
URL: http://jira.codehaus.org/browse/MNG-1570
Project: Maven 2
Type: Bug
Components: maven-surefire-plugin
Versions: 2.0
Reporter: Joerg Schaible
When testing from the parent POM dir, all paths are relative to it. This causes
major trouble in unit tests, that access the file system. All tests work if the
test is started from the subproject directly. In M1 the current work directory
was always ${basedir}. Might be related to MNG-1471.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1493) Support in multiproject environment modules with different named POMs
Support in multiproject environment modules with different named POMs - Key: MNG-1493 URL: http://jira.codehaus.org/browse/MNG-1493 Project: Maven 2 Type: Improvement Components: maven-model Versions: 2.0 Reporter: Joerg Schaible Priority: Minor Command line version of Maven 2 supports POMs with a different name using the -f option. Unfortunately such POMs cannot be used as modules, since the value of the module tag is defined as a directory to another pom.xml instead of a pathname to another POM. Only if the value is not already an existing file the value should be treated as directory with a present pom.xml file. Similar situation applies to the relativePath element of the parent tag. This makes the generation of different artifacts from the same sources (with some modifications) much more easy. Currently you will have to put the POMs in separate directories and modify the sourec location into another module. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1478) Wrong tags in reference guide to pom.xml and settings.xml
Wrong tags in reference guide to pom.xml and settings.xml - Key: MNG-1478 URL: http://jira.codehaus.org/browse/MNG-1478 Project: Maven 2 Type: Bug Components: documentation - guides Reporter: Joerg Schaible The reference guides describe tags, that are not in the schema. They all have in common, that they are missing a trailing 's' in their name: Reference Guides: http://maven.apache.org/maven-model/maven.html http://maven.apache.org/maven-settings/settings.html Affected tags (as far as I recognized them): /settings/profiles/profile/activation/os /settings/profiles/profile/repositories/repository/releases /settings/profiles/profile/repositories/repository/snapshots /settings/profiles/profile/pluginRepositories/pluginRepository/releases /settings/profiles/profile/pluginRepositories/pluginRepository/snapshots /project/profiles/profile/activation/os /project/profiles/profile/repositories/repository/releases /project/profiles/profile/repositories/repository/snapshots /project/profiles/profile/pluginRepositories/pluginRepository/releases /project/profiles/profile/pluginRepositories/pluginRepository/snapshots /project/repositories/repository/releases /project/repositories/repository/snapshots /project/pluginRepositories/pluginRepository/releases /project/pluginRepositories/pluginRepository/snapshots -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVENUPLOAD-580) Upload wsdl4j 1.5.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-580?page=all ] Joerg Schaible reopened MAVENUPLOAD-580: Hi Carlos, you forgot the second bundle. I remember, that I saw a comment of you to add additional bundles in the same JIRA issue instead of opening a new one ... Upload wsdl4j 1.5.1 --- Key: MAVENUPLOAD-580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-580 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible Assignee: Carlos Sanchez WSDL 1.5.1 from http://sourceforge.net/project/showfiles.php?group_id=128811package_id=141069 published under Common Public License 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-582) wsdl4j-qname
wsdl4j-qname Key: MAVENUPLOAD-582 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-582 Project: maven-upload-requests Type: Sub-task Reporter: Joerg Schaible Found the create sub-task functionality now ... :) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-580) Upload wsdl4j 1.5.1
Upload wsdl4j 1.5.1 --- Key: MAVENUPLOAD-580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-580 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible WSDL 1.5.1 from http://sourceforge.net/project/showfiles.php?group_id=128811package_id=141069 published under Common Public License 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-580) Upload wsdl4j 1.5.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-580?page=comments#action_50201 ] Joerg Schaible commented on MAVENUPLOAD-580: http://www.schaible.info/maven/wsdl4j-qname-1.5.1-bundle.jar Upload wsdl4j 1.5.1 --- Key: MAVENUPLOAD-580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-580 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible WSDL 1.5.1 from http://sourceforge.net/project/showfiles.php?group_id=128811package_id=141069 published under Common Public License 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-179) Axis 1.2.1 WSDL4J dependency points to wrong place
[ http://jira.codehaus.org/browse/MEV-179?page=comments#action_50202 ] Joerg Schaible commented on MEV-179: The original POM is right. It references wsdl4j, which has not be uploaded to ibiblio yet: http://sourceforge.net/project/showfiles.php?group_id=128811package_id=141069 Axis had for some time an own version of this jar, since they had dependencies on features of 1.5, when it was not yet released. See MAVENUPLOAD-580 Axis 1.2.1 WSDL4J dependency points to wrong place -- Key: MEV-179 URL: http://jira.codehaus.org/browse/MEV-179 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Paul Russell Attachments: axis-1.2.1.pom.patch This project has a dependency on WSDL4J, but WSDL4J appears to have been brought under the axis umbrella. The new artifact is groupId=axis artifactId=axis-wsdl4j version=1.2.1. I'm attaching a patch to axis-1.2.1.pom, the patch was created /inside/ the axis/axis/1.2.1/ folder of the repository. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1247) Remove carriage returns and tabs from field values in the manifest file
[ http://jira.codehaus.org/browse/MNG-1247?page=comments#action_48905 ] Joerg Schaible commented on MNG-1247: - No. I cannot speak for tabs or CR/LF but the line wrap itself moving the l from model into col 1 of the next line is according the spec concerning the valid length of a line. Remove carriage returns and tabs from field values in the manifest file --- Key: MNG-1247 URL: http://jira.codehaus.org/browse/MNG-1247 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0 Environment: Windows XP, Java 5 Reporter: Adrian The code that generates manifest files needs to remove tabs and carriage returns from the text values. I discovered the bug when my description in the pom.xml spaned several lines with tabs and carriage returns - this caused the following exception.. java.io.IOException: invalid header field By removing the tabs and carriage returns in the pom.xml I have temporarily fixed the issue. The manifest generated should look like .. - Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: apill Build-Jdk: 1.5.0_02 Extension-Name: pics-model Specification-Title: The core inventory model project defines the mode l for cental storage for core inventory. Specification-Vendor: Dolby Laboratories, Inc Implementation-Vendor: Dolby Laboratories, Inc Implementation-Title: pics-model Implementation-Version: 0.1-SNAPSHOT - NOT LIKE - Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: apill Build-Jdk: 1.5.0_02 Extension-Name: pics-model Specification-Title: The core inventory model project defines the mode l for cental storage for core inventory. Specification-Vendor: Dolby Laboratories, Inc Implementation-Vendor: Dolby Laboratories, Inc Implementation-Title: pics-model Implementation-Version: 0.1-SNAPSHOT --- -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPARTIFACT-61) scpexe is a noop
scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible 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.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-9) jmock-cglib should depend on cglib
[ http://jira.codehaus.org/browse/MEV-9?page=comments#action_48022 ] Joerg Schaible commented on MEV-9: -- The attached POM will break applications using ASM 2.0 (like Groovy). Please use this dependency instead: dependency groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_2/version scopetest/scope /dependency jmock-cglib should depend on cglib -- Key: MEV-9 URL: http://jira.codehaus.org/browse/MEV-9 Project: Maven Evangelism Type: Task Components: Invalid POM Reporter: Mark Hobson Assignee: Edwin Punzalan Attachments: jmock-cglib-1.0.1.pom jmock-cglib requires cglib but doesn't state so in it's dependencies. Needs the following block: dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.1/version scopetest/scope /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-3) Broken dependencies for nanocontainer
[ http://jira.codehaus.org/browse/MEV-3?page=comments#action_47848 ]
Joerg Schaible commented on MEV-3:
--
Well, see the linkesd issue (and the linked issues of this).
Broken dependencies for nanocontainer
-
Key: MEV-3
URL: http://jira.codehaus.org/browse/MEV-3
Project: Maven Evangelism
Type: Task
Reporter: Mark Hobson
Broken dependencies for:
http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-beta-4/nanocontainer-1.0-beta-4.pom
Dependencies use jelly variables ${picocontainer.version} and
${pom.currentVersion}.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-80) Support global theme
[ http://jira.codehaus.org/browse/MPXDOC-80?page=comments#action_46163 ]
Joerg Schaible commented on MPXDOC-80:
--
Hi Lukas,
thanks for working on it. Your patch basically does, what we need, allthough I
would prefer to keep the base of file name instead of customCSS.css (a
corporate identity thingy). Regarding maven.multiproject.basedir it depends,
how it is defined. We always use something like ${basedir}/.., so we have an
absolute path here and the copy task works fine then.
Regards,
Jörg
Support global theme
Key: MPXDOC-80
URL: http://jira.codehaus.org/browse/MPXDOC-80
Project: maven-xdoc-plugin
Type: Improvement
Reporter: Joerg Schaible
Assignee: Lukas Theussl
Fix For: 1.10
Attachments: MPXDOC-80.patch, plugin.jelly.diff, properties.xml.diff,
xdoc-theme.diff
Original Estimate: 10 minutes
Remaining: 10 minutes
While it is possible to set an URL for an own theme using the new property
maven.xdoc.theme.url, you cannot tell the xdoc plugin which local file you
are using. The current approach enforces every project to have its own copy
of the theme. This is extremly nasty in combination with multiproject.
Proposal: Support a new property maven.xdoc.theme.file, that defines the
local location of the theme file. This file is copied into the
${maven.docs.dest}/style directory.
Please have a look at jakarta-commons, they suffer from this problem also:
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/index.html#35557
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-85) theme.url is not relative
[ http://jira.codehaus.org/browse/MPXDOC-85?page=comments#action_45816 ] Joerg Schaible commented on MPXDOC-85: -- OK, I use the solution of MPXDOC-80 anyway. theme.url is not relative - Key: MPXDOC-85 URL: http://jira.codehaus.org/browse/MPXDOC-85 Project: maven-xdoc-plugin Type: Bug Reporter: Joerg Schaible Priority: Minor Attachments: site.jsl.diff If you set maven.xdoc.theme.url to something like style/mytheme.css you'll have to notice, that this woprks only for pages in the root directory. For all pages in a sudirectory the theme is not available, since in site.jsl the relative path is not prepended. You can see the effect easily if you define an own theme and generate statcvs report. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-65) jmock velocity cglib dependencies
[ http://jira.codehaus.org/browse/MEV-65?page=comments#action_45540 ] Joerg Schaible commented on MEV-65: --- jmock Added dependency to cglib-full-2.0, which is the one jmock actually uses http://cvs.jmock.org/viewrep/jmock/jmock/lib Uaaah. cglib-full includes unknown version of some classes from asm-1.x without using a private package. Either make dependend on cglib-2.0.2 and asm-1.5.3 or cglib-nodep-2.1_2. jmock velocity cglib dependencies - Key: MEV-65 URL: http://jira.codehaus.org/browse/MEV-65 Project: Maven Evangelism Type: Bug Reporter: Gilles Scokart Assignee: Carlos Sanchez Attachments: jmock-cglib-1.0.1.pom, velocity-1.4.pom I'm not sure where to put it, I already tried : http://jira.codehaus.org/browse/JMOCK-78 (without success) The file jmock-cglib-1.0.1.pom stored on ibiblio, used by maven don't contains a dependency with cglib, but it should. Because of that, the users of maven2 are still forced to place the dependency themself, with the risk of taking a wrong version. I also found that velocity doesn't have a dependency to velocity-dep. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-65) dependencies not set inside ibiblio repository.
[ http://jira.codehaus.org/browse/MEV-65?page=comments#action_45459 ] Joerg Schaible commented on MEV-65: --- CAUTION: This POM for jmock-cglib will have version issues. It references CGLIB 2.1 which has a transitive dependency to ASM 1.x ... which in turn is incompatible to any project already using ASM 2.x. Therefore it should reference groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_2/version Despite the newer (bug fixed) version of CGLIB, this artifact contains also a private copy of the necessary ASM 1.x classes. - Jörg dependencies not set inside ibiblio repository. --- Key: MEV-65 URL: http://jira.codehaus.org/browse/MEV-65 Project: Maven Evangelism Type: Bug Reporter: Gilles Scokart Attachments: jmock-cglib-1.0.1.pom, velocity-1.4.pom I'm not sure where to put it, I already tried : http://jira.codehaus.org/browse/JMOCK-78 (without success) The file jmock-cglib-1.0.1.pom stored on ibiblio, used by maven don't contains a dependency with cglib, but it should. Because of that, the users of maven2 are still forced to place the dependency themself, with the risk of taking a wrong version. I also found that velocity doesn't have a dependency to velocity-dep. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-66) cglib 2.1_2 should depend on asm 1.5.3, not 2.0
[ http://jira.codehaus.org/browse/MEV-66?page=comments#action_45393 ] Joerg Schaible commented on MEV-66: --- So I advice any of those cglib team members at least to try to use cglib-2.1_2 with asm-2.0. If *I* do I get always a lot of NoClassDefFoundError exceptions. They do not happen if you run it with asm-1.x and another indication is, that cglib-nodeps-2.1_2 contain the asm-1.x sources with a different package name! cglib 2.1_2 should depend on asm 1.5.3, not 2.0 --- Key: MEV-66 URL: http://jira.codehaus.org/browse/MEV-66 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Ralph Poellath cglib 2.1_2 has a dependency on asm 2.0, with which it is incompatible. A mailing list discussion on the subject starts at http://marc.theaimsgroup.com/?l=turbine-maven-userm=112498159906141w=2 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-66) cglib 2.1_2 should depend on asm 1.5.3, not 2.0
[ http://jira.codehaus.org/browse/MEV-66?page=comments#action_45398 ]
Joerg Schaible commented on MEV-66:
---
public void testCGLib() throws Exception {
assertNotNull(new Enhancer());
}
throws with cglib-2.1_2 and asm-2.0:
%
java.lang.NoClassDefFoundError: org/objectweb/asm/CodeVisitor
at
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:165)
at
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:215)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:117)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.clinit(Enhancer.java:69)
at demo.CGLibTest.testCGLib(CGLibTest.java:33)
Exception in thread main
%
Works with cglib-2.1_2 and asm-1.5.3 or with cglib-nodeps-2.1_2 alone. There is
no org.objectweb.asm.CodeVisitor anymore in asm-2.0:
http://asm.objectweb.org/current/doc/javadoc/user/index.html
cglib 2.1_2 should depend on asm 1.5.3, not 2.0
---
Key: MEV-66
URL: http://jira.codehaus.org/browse/MEV-66
Project: Maven Evangelism
Type: Bug
Components: Dependencies
Reporter: Ralph Poellath
cglib 2.1_2 has a dependency on asm 2.0, with which it is incompatible.
A mailing list discussion on the subject starts at
http://marc.theaimsgroup.com/?l=turbine-maven-userm=112498159906141w=2
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=all ]
Joerg Schaible closed MPXDOC-108:
-
Resolution: Fixed
Fix Version: 1.8
Works for urls with explicit file:// protocol.
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
Fix For: 1.8
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
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.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
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.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_45018 ]
Joerg Schaible commented on MPXDOC-108:
---
I suggest, that you have a closer look at the exception. The absolut portion of
the path *is always prepended*. So any of your suggestions do not help.
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
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.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
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.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_45019 ]
Joerg Schaible commented on MPXDOC-108:
---
Hi Ignacio,
I want to apologize for my harsh tone, but you were right. Prepending file:///
works. I wonder why though, becasue I looked into the jelly code of the plugin
and I could not identify any different handling for absolute URLs (with
protocol). There seems only code if the property is empty.
- Jörg
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
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.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
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.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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
[jira] Commented: (MNG-769) m2 eclipse:eclipse - duplicate ressources
[ http://jira.codehaus.org/browse/MNG-769?page=comments#action_44892 ] Joerg Schaible commented on MNG-769: Just as a side note: Eclipse can inculde/exclude! An extract from one of my used .classpath files: classpathentry excluding=ejb/XLocal.java|ejb/XRemote.java|ejb/X.java|ejb/XHome.java|ejb/XHomeLocal.java|ejb/XLocal.java kind=src path=src/java/ I am just not sure, when Eclipse started to support it. m2 eclipse:eclipse - duplicate ressources - Key: MNG-769 URL: http://jira.codehaus.org/browse/MNG-769 Project: Maven 2 Type: Bug Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor When we have a pom.xml that contains 2 ressources with the same directory (but with different includes), the eclipse plugin generate a .classpath that contains two time the same classpath entry. Such a project can not be opened in eclipse. It' normal to not have exactely the same behavior (eclipse doesn't suport patterns for inclusion/exclusion), but it would be better to have only one classpath entries genereted if two ressources are linked to the same directory. The semantic stay the same as the current one, but there is no errors anymore in the .classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_44923 ]
Joerg Schaible commented on MPXDOC-108:
---
No. I don't have an adjusted site.jsl for every subproject, I have one adjusted
site.jsl for all.
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
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.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
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.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
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 com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
[jira] Commented: (MPECLIPSE-80) Generate .wtpmodules files
[ http://jira.codehaus.org/browse/MPECLIPSE-80?page=comments#action_44670 ] Joerg Schaible commented on MPECLIPSE-80: - Can you make this optional? I.e. generate .wtpmodules only with an excplicit maven.eclipse.support.wtp=true for war types. Hint: Other people are using JBoss-IDE or MyEclipse ... and this syntax leaves room to support other extensions also. Generate .wtpmodules files -- Key: MPECLIPSE-80 URL: http://jira.codehaus.org/browse/MPECLIPSE-80 Project: maven-eclipse-plugin Type: New Feature Reporter: fabrizio giustina Fix For: 1.10 Attachments: MPECLIPSE-63-78-79-80.diff, MPECLIPSE-wtpmodules.patch Generates a .wtpmodules file for eclipse wtp when the org.eclipse.wst.common.modulecore.ModuleCoreNature is set, see http://www.eclipse.org/webtools/jst/components/j2ee/scenarios/MavenEclipseIntegration.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-472) backport-util-concurrent 2.0_01_pd
backport-util-concurrent 2.0_01_pd -- Key: MAVENUPLOAD-472 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-472 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible New version of the JSR 166 backport of David Kurzyniec: http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/ Public domain. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-49) canonical list of m1 poms failing repoclean
[ http://jira.codehaus.org/browse/MEV-49?page=comments#action_43717 ] Joerg Schaible commented on MEV-49: --- Sure? Attached list stops suspiciously after M canonical list of m1 poms failing repoclean --- Key: MEV-49 URL: http://jira.codehaus.org/browse/MEV-49 Project: Maven Evangelism Type: Task Components: Invalid POM Reporter: Brett Porter Attachments: repository.report.full.txt these are all the failures not filed elsewhere, up to date as of 1/8/05 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-427) xtiff-jai-beta-0.3
xtiff-jai-beta-0.3 -- Key: MAVENUPLOAD-427 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-427 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible Replacement for the TIFF codec of JAI. See http://sf.net/projects/xtiff-jai. JAVA ADVANCED IMAGING SAMPLE INPUT-OUTPUT CODECS AND WIDGET HANDLING SOURCE CODE License Version 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-377) tiffrenderer-0.9
tiffrenderer-0.9 Key: MAVENUPLOAD-377 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-377 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible FOP extension for TIFFs. Mozilla 1.0 license. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-378) tiffrenderer-0.9-min
tiffrenderer-0.9-min Key: MAVENUPLOAD-378 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-378 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible FOP extension for TIFFs. Uses limited TIFF codecs included in Batik. Mozilla 1.0 lic. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPECLIPSE-60) Downloading source zips
[ http://jira.codehaus.org/browse/MPECLIPSE-60?page=comments#action_38718 ]
Joerg Schaible commented on MPECLIPSE-60:
-
Its not just IDEs. Think about the javadoc URL. That can be used by eclipse
plugin, but also by the javadoc plugin, that has nothing to do with IDEs. At
our location, we have people working with different IDEs for the same project.
So it seems quite silly to add the same information twice.
Downloading source zips
---
Key: MPECLIPSE-60
URL: http://jira.codehaus.org/browse/MPECLIPSE-60
Project: maven-eclipse-plugin
Type: New Feature
Versions: 1.9
Reporter: Krystian Nowak
Fix For: 1.9
Attachments: plugin.jelly.patch
Original Estimate: 30 minutes
Remaining: 30 minutes
I've attached plugin.jelly for maven-eclipse-plugin downloading sources from
${repo}/${groupId}/src/${artifactId}-${version}.zip and installing it as
${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip.
It does it for all jar dependencies having eclipse.source property set to
true. Example project.xml:
(...)
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
urlhttp://www.junit.org//url
properties
eclipse.sourcetrue/eclipse.source
/properties
/dependency
/dependencies
(...)
What you have to do now is to call maven eclipse and refresh your project
in Eclipse.
And here is the code of plugin.jelly - a patch made in Eclipse:
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.31
diff -u -r1.31 plugin.jelly
--- plugin.jelly 16 Nov 2004 10:48:15 - 1.31
+++ plugin.jelly 6 Dec 2004 08:10:33 -
@@ -78,7 +78,8 @@
!-- Generate Eclipse .classpath file--
!--==--
goal name=eclipse:generate-classpath
-description=Generate Eclipse .classpath file
+description=Generate Eclipse .classpath file
+prereqs=eclipse:sources:download
ant:echoCreating ${basedir}/.classpath .../ant:echo
j:file name=${basedir}/.classpath prettyPrint=true outputMode=xml
xmlns=dummy
@@ -263,5 +264,73 @@
ant:echoCleaned up eclipse generated files/ant:echo
/goal
+
+
+
+ !--==--
+ !-- Download project dependency sources
--
+ !--==--
+
+ goal name=eclipse:sources:download
+ j:forEach var=depItem items=${pom.getDependencies()}
+ j:if
test=${depItem.getType().equalsIgnoreCase('jar')}
+ j:if
test=${depItem.getProperty('eclipse.source') == 'true'}
+ j:set var=groupId
value=${depItem.getGroupId()}/
+ j:set var=artifactId
value=${depItem.getArtifactId()}/
+ j:set var=version
value=${depItem.getVersion()}/
+ attainGoal
name=eclipse:source:download/
+ j:remove var=groupId/
+ j:remove var=artifactId/
+ j:remove var=version/
+ /j:if
+ /j:if
+ /j:forEach
+ /goal
+
+
+ !--==--
+ !-- Download single source --
+ !--==--
+
+ goal name=eclipse:source:download
+ !--
+ param: groupId
+ param: artifactId
+ param: version
+ --
+ echoChecking sources for ${groupId}:${artifactId}
ver.${version}/echo
+ util:file var=localSrcFile
name=${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip /
+j:if test=${!localSrcFile.exists()}
+ mkdir dir=${maven.repo.local}/${groupId}/src /
+ j:set var=repoList${maven.repo.remote}/j:set
+ util:tokenize var=repos
delim=,${repoList.trim()}/util:tokenize
+ j:forEach var=repo items=${repos}
+ echorepo is '${repo}'/echo
+ j:set var=remoteFile
value=${repo}/${groupId}/src/${artifactId}-${version}.zip /
+ echotrying to download ${remoteFile}/echo
+ j:catch var=ex
+
[jira] Commented: (MPECLIPSE-60) Downloading source zips
[ http://jira.codehaus.org/browse/MPECLIPSE-60?page=comments#action_38644 ]
Joerg Schaible commented on MPECLIPSE-60:
-
Just wonder, if the property should really be named eclipse.source, since
IDEA has the same functionality. sourceCode or IDE.source might be more
appropriate.
Downloading source zips
---
Key: MPECLIPSE-60
URL: http://jira.codehaus.org/browse/MPECLIPSE-60
Project: maven-eclipse-plugin
Type: New Feature
Versions: 1.9
Reporter: Krystian Nowak
Fix For: 1.9
Attachments: plugin.jelly.patch
Original Estimate: 30 minutes
Remaining: 30 minutes
I've attached plugin.jelly for maven-eclipse-plugin downloading sources from
${repo}/${groupId}/src/${artifactId}-${version}.zip and installing it as
${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip.
It does it for all jar dependencies having eclipse.source property set to
true. Example project.xml:
(...)
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
urlhttp://www.junit.org//url
properties
eclipse.sourcetrue/eclipse.source
/properties
/dependency
/dependencies
(...)
What you have to do now is to call maven eclipse and refresh your project
in Eclipse.
And here is the code of plugin.jelly - a patch made in Eclipse:
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.31
diff -u -r1.31 plugin.jelly
--- plugin.jelly 16 Nov 2004 10:48:15 - 1.31
+++ plugin.jelly 6 Dec 2004 08:10:33 -
@@ -78,7 +78,8 @@
!-- Generate Eclipse .classpath file--
!--==--
goal name=eclipse:generate-classpath
-description=Generate Eclipse .classpath file
+description=Generate Eclipse .classpath file
+prereqs=eclipse:sources:download
ant:echoCreating ${basedir}/.classpath .../ant:echo
j:file name=${basedir}/.classpath prettyPrint=true outputMode=xml
xmlns=dummy
@@ -263,5 +264,73 @@
ant:echoCleaned up eclipse generated files/ant:echo
/goal
+
+
+
+ !--==--
+ !-- Download project dependency sources
--
+ !--==--
+
+ goal name=eclipse:sources:download
+ j:forEach var=depItem items=${pom.getDependencies()}
+ j:if
test=${depItem.getType().equalsIgnoreCase('jar')}
+ j:if
test=${depItem.getProperty('eclipse.source') == 'true'}
+ j:set var=groupId
value=${depItem.getGroupId()}/
+ j:set var=artifactId
value=${depItem.getArtifactId()}/
+ j:set var=version
value=${depItem.getVersion()}/
+ attainGoal
name=eclipse:source:download/
+ j:remove var=groupId/
+ j:remove var=artifactId/
+ j:remove var=version/
+ /j:if
+ /j:if
+ /j:forEach
+ /goal
+
+
+ !--==--
+ !-- Download single source --
+ !--==--
+
+ goal name=eclipse:source:download
+ !--
+ param: groupId
+ param: artifactId
+ param: version
+ --
+ echoChecking sources for ${groupId}:${artifactId}
ver.${version}/echo
+ util:file var=localSrcFile
name=${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip /
+j:if test=${!localSrcFile.exists()}
+ mkdir dir=${maven.repo.local}/${groupId}/src /
+ j:set var=repoList${maven.repo.remote}/j:set
+ util:tokenize var=repos
delim=,${repoList.trim()}/util:tokenize
+ j:forEach var=repo items=${repos}
+ echorepo is '${repo}'/echo
+ j:set var=remoteFile
value=${repo}/${groupId}/src/${artifactId}-${version}.zip /
+ echotrying to download ${remoteFile}/echo
+ j:catch var=ex
+ j:invokeStatic var=dummy method=getFile
className=org.apache.maven.util.HttpUtils
+ j:arg type=java.lang.String
[jira] Commented: (MAVENUPLOAD-373) Upload jmimemagic-0.0.4a
[ http://jira.codehaus.org/browse/MAVENUPLOAD-373?page=comments#action_38582 ] Joerg Schaible commented on MAVENUPLOAD-373: Fixed. Was cp error anyway :) Upload jmimemagic-0.0.4a Key: MAVENUPLOAD-373 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-373 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible Assignee: Carlos Sanchez jMimeMagic is a Java library for determining the MIME type of files or streams. LPGL, hosted on SF. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-373) Upload jmimemagic-0.0.4a
Upload jmimemagic-0.0.4a Key: MAVENUPLOAD-373 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-373 Project: maven-upload-requests Type: Task Reporter: Joerg Schaible jMimeMagic is a Java library for determining the MIME type of files or streams. LPGL, hosted on SF. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPREPO-9) create-upload-bundle deficiencies
[ http://jira.codehaus.org/browse/MPREPO-9?page=comments#action_31836 ] Joerg Schaible commented on MPREPO-9: - Unfortunately normal users cannot create links anymore. so the references here in the text must be enough: MAVEN-1390 MPPOM-4 MNG-271 create-upload-bundle deficiencies - Key: MPREPO-9 URL: http://jira.codehaus.org/browse/MPREPO-9 Project: maven-repository-plugin Type: Bug Versions: 1.2 Reporter: Andy Jefferson Assignee: dion gillard Fix For: 1.2 Using maven 1.0.1 and the 1.2 version of the repository plugin. I have a project that has a top level that contains the LICENSE.txt, and project.xml with the currentVersion,groupId. This has subprojects that reference the toplevel project.xml (and so have the same version and groupId). When I call maven create-upload-bundle in the subproject there are 2 issues 1. It cant find LICENSE.txt. This is not specifiable via a property either. 2. When it overcomes the first issue (by manual copying of the LICENSE) it creates the bundle jar but this just contains the project.xml from that subproject (which doesnt have the groupId, currentVersion). Would be great if we can get this plugin usable in such a multiproject situation. Let me know if you need any more info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-271) exported pom.xml should contain full pom information
[ http://jira.codehaus.org/browse/MNG-271?page=comments#action_31721 ] Joerg Schaible commented on MNG-271: Just for reference: MAVEN-1390 MPPOM-4 exported pom.xml should contain full pom information Key: MNG-271 URL: http://jira.codehaus.org/browse/MNG-271 Project: m2 Type: Wish Versions: 2.0-alpha-1 Reporter: Vincent Massol When you install a module in the local repo the pom.xml file is copied (it's also included in jars). That's very good. However if my project is a module (i.e it depends on some parent(s)), the pom.xml that is dumped only contains partial information (it does not contain inherited information). Thus it can be used standalone and does not offer all the information there is about the module. As the pom is fully constructed in memory, it would be nice to dump it from memory instead of copying the pom.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-331) Backport of JSR 166
Backport of JSR 166 --- Key: MAVENUPLOAD-331 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-331 Project: maven-upload-requests Type: New Feature Reporter: Joerg Schaible Backport of JSR 166 (java.util.concurrent) from Dawid Kurzyniec. Recommended by Doug Lea as successor of concurrent-1.3.4. Public domain. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
