[jira] Created: (MINDEXER-44) NPE from DefaultSearchEngine.doSearchWithCeiling
NPE from DefaultSearchEngine.doSearchWithCeiling
Key: MINDEXER-44
URL: https://jira.codehaus.org/browse/MINDEXER-44
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.1
Reporter: Jesse Glick
Priority: Minor
http://netbeans.org/bugzilla/show_bug.cgi?id=202138 reports
http://statistics.netbeans.org/exceptions/messageslog?id=533660 which shows
{code}
java.lang.NullPointerException
at
org.apache.maven.index.DefaultSearchEngine.doSearchWithCeiling(DefaultSearchEngine.java:316)
at
org.apache.maven.index.DefaultSearchEngine.searchFlat(DefaultSearchEngine.java:169)
at
org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:102)
at
org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:77)
{code}
This comes after some index download problems like
{code}
java.io.FileNotFoundException: Resource nexus-maven-repository-index.gz does
not exist
at
org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:196)
at
org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:166)
at
org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:191)
at
org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
at
org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:861)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
{code}
It seems that the {{DefaultIndexingContext.indexSearcher}} is null, for
whatever reason, and {{searchFlatPaged}} is not verifying that it has been
passed a valid context and does not attempt to fix an invalid context, perhaps
using {{openAndWarmupReaders}}.
Probably the caller is at fault for attempting a search on a context with no
valid index, but this ought to be reported more clearly than with an NPE
several calls down the stack, and there should be some documented method for
checking that a context is somehow complete and ready for use.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-453) ArrayIndexOutOfBoundsException
[ https://jira.codehaus.org/browse/DOXIA-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated DOXIA-453: --- Attachment: DOXIA-453.patch One possible fix. > ArrayIndexOutOfBoundsException > -- > > Key: DOXIA-453 > URL: https://jira.codehaus.org/browse/DOXIA-453 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > Attachments: DOXIA-453.patch > > > If you checkout the tag for version 1.7 of the maven antrun plugin, and run > mvn site site:stage-deploy -Preporting > you will be rewarded with the below. Oddly, when I ran it a second time with > -X it went away. > [ERROR] FATAL ERROR > [INFO] > > [INFO] 1 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 1 > at > org.apache.maven.doxia.module.apt.AptParser$Table.traverseRow(AptParser.java:2618) > at > org.apache.maven.doxia.module.apt.AptParser$Table.traverse(AptParser.java:2433) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:861) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:807) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:816) > at > org.apache.maven.doxia.module.apt.AptParser.traverseBody(AptParser.java:758) > at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:228) > at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:399) > at > org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-453) ArrayIndexOutOfBoundsException
[ https://jira.codehaus.org/browse/DOXIA-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282384#comment-282384 ] Benson Margulies commented on DOXIA-453: In the Apt parser, the justification parser can disagree with the main table parser. the file that provokes this is usage.apt.vm from the antrun plugin. I attached a possible fix, but someone might prefer to fix the source of the inconsistency instead. > ArrayIndexOutOfBoundsException > -- > > Key: DOXIA-453 > URL: https://jira.codehaus.org/browse/DOXIA-453 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > Attachments: DOXIA-453.patch > > > If you checkout the tag for version 1.7 of the maven antrun plugin, and run > mvn site site:stage-deploy -Preporting > you will be rewarded with the below. Oddly, when I ran it a second time with > -X it went away. > [ERROR] FATAL ERROR > [INFO] > > [INFO] 1 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 1 > at > org.apache.maven.doxia.module.apt.AptParser$Table.traverseRow(AptParser.java:2618) > at > org.apache.maven.doxia.module.apt.AptParser$Table.traverse(AptParser.java:2433) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:861) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:807) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:816) > at > org.apache.maven.doxia.module.apt.AptParser.traverseBody(AptParser.java:758) > at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:228) > at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:399) > at > org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-453) ArrayIndexOutOfBoundsException
ArrayIndexOutOfBoundsException -- Key: DOXIA-453 URL: https://jira.codehaus.org/browse/DOXIA-453 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.2 Reporter: Benson Margulies If you checkout the tag for version 1.7 of the maven antrun plugin, and run mvn site site:stage-deploy -Preporting you will be rewarded with the below. Oddly, when I ran it a second time with -X it went away. [ERROR] FATAL ERROR [INFO] [INFO] 1 [INFO] [INFO] Trace java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.maven.doxia.module.apt.AptParser$Table.traverseRow(AptParser.java:2618) at org.apache.maven.doxia.module.apt.AptParser$Table.traverse(AptParser.java:2433) at org.apache.maven.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:861) at org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:807) at org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:816) at org.apache.maven.doxia.module.apt.AptParser.traverseBody(AptParser.java:758) at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:228) at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:399) at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-383) Use velocity expressions in descriptor properties
[
https://jira.codehaus.org/browse/ARCHETYPE-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282373#comment-282373
]
Olivier Lamy commented on ARCHETYPE-383:
maybeVelocityExpression test only contains $, I will add contains on ${
> Use velocity expressions in descriptor properties
> -
>
> Key: ARCHETYPE-383
> URL: https://jira.codehaus.org/browse/ARCHETYPE-383
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 2.1
>Reporter: Emmanuel Hugonnet
>Assignee: Olivier Lamy
> Fix For: 2.2
>
> Attachments: patch_jira_383.patch
>
>
> The descriptor can use velocity expressions for value and defaultValue, thus
> enabling the creation of velocity global properties for an archetype.
> For example :
>
>
> ${rootArtifactId.substring(0,1).toUpperCase()}${rootArtifactId.substring(1)}
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-383) Use velocity expressions in descriptor properties
[
https://jira.codehaus.org/browse/ARCHETYPE-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated ARCHETYPE-383:
---
Assignee: Olivier Lamy
> Use velocity expressions in descriptor properties
> -
>
> Key: ARCHETYPE-383
> URL: https://jira.codehaus.org/browse/ARCHETYPE-383
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 2.1
>Reporter: Emmanuel Hugonnet
>Assignee: Olivier Lamy
> Fix For: 2.2
>
> Attachments: patch_jira_383.patch
>
>
> The descriptor can use velocity expressions for value and defaultValue, thus
> enabling the creation of velocity global properties for an archetype.
> For example :
>
>
> ${rootArtifactId.substring(0,1).toUpperCase()}${rootArtifactId.substring(1)}
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-483) Update SCM Perforce Provider to use P4Java
[ https://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282372#comment-282372 ] Brian Jackson commented on SCM-483: --- It's deployed together with the artifact (aka. the URL is relative): http://repo1.maven.org/maven2/com/perforce/p4java/2011.1.297684/p4java-2011.1.297684-license.txt > Update SCM Perforce Provider to use P4Java > -- > > Key: SCM-483 > URL: https://jira.codehaus.org/browse/SCM-483 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.2 >Reporter: Tom Rodriguez > Fix For: future > > Attachments: maven-scm-perforce-p4java.jar > > > Perforce has developed a new Java Native API for access to perforce called > P4Java. You can access it here: > ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely > reworked API does not require that the p4 client be installed on the system. > The SCM Perforce Provider should be modified to use this new native java API > to eliminate the many issues involved with depending on the p4 executable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-483) Update SCM Perforce Provider to use P4Java
[ https://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282370#comment-282370 ] Olivier Lamy commented on SCM-483: -- what is the license ? the pom http://repo1.maven.org/maven2/com/perforce/p4java/2011.1.297684/p4java-2011.1.297684.pom has a strange value for the licence url. > Update SCM Perforce Provider to use P4Java > -- > > Key: SCM-483 > URL: https://jira.codehaus.org/browse/SCM-483 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.2 >Reporter: Tom Rodriguez > Fix For: future > > Attachments: maven-scm-perforce-p4java.jar > > > Perforce has developed a new Java Native API for access to perforce called > P4Java. You can access it here: > ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely > reworked API does not require that the p4 client be installed on the system. > The SCM Perforce Provider should be modified to use this new native java API > to eliminate the many issues involved with depending on the p4 executable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-388) enhance IntegrationTestMojo to be able to run verify script to do some asserts
enhance IntegrationTestMojo to be able to run verify script to do some asserts -- Key: ARCHETYPE-388 URL: https://jira.codehaus.org/browse/ARCHETYPE-388 Project: Maven Archetype Issue Type: New Feature Reporter: Olivier Lamy running some scripts "à la" invoker plugin: verify.bsh/groovy . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-387) IntegrationTestMojo has hardcoded target/test-classes/projects for resources
[ https://jira.codehaus.org/browse/ARCHETYPE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed ARCHETYPE-387. -- Resolution: Fixed fixed r1190546 > IntegrationTestMojo has hardcoded target/test-classes/projects for resources > > > Key: ARCHETYPE-387 > URL: https://jira.codehaus.org/browse/ARCHETYPE-387 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-81) Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)
[ https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282364#comment-282364 ] Nicolas Marcotte commented on MWAR-81: -- I have added a Junit test to reflect this capability and updated the documentation, I hope that this will make it in the next release, as this is too much of an useful feature to remain undocumented and untested! Thank you again Joerg Schaible > Request enhancement to pattern matching for > packagingIncludes/packagingExcludes functionality (regular expressions?) > > > Key: MWAR-81 > URL: https://jira.codehaus.org/browse/MWAR-81 > Project: Maven 2.x WAR Plugin > Issue Type: Wish > Environment: n/a >Reporter: Bryan Loofbourrow >Priority: Minor > Attachments: maven-war-plugin-2.1.1-NM-Doc-Test.patch, > maven-war-plugin-2.1.1-NM.patch > > > The Maven War Plugin currently permits choosing what files will wind up in > the .war. It does this via two parameters, warSourceIncludes, and > warSourceExcludes. The rule appears to be that the includes are computed, > and a list of matches made, then that list is run against the excludes, and > any matches taken out of the include list. > The only wildcards that appear to be supported are *, **, and ?. > That doesn't work well if you are packaging wars in ears, and therefore want > to exclude all jars from the war, except for one or two that have to be in > the war in order to run properly. "Exclude all but foo.jar and bar.jar" just > doesn't translate well to "here's your simple include template, here's your > simple exclude template" representation, at least with current wildcards. > So this is a wish specifically for something to address the "exclude all but > x, y, and z" need for war source includes/excludes, and a suggestion that it > might be best to deprecate the warSourceIncludes/warSourceExcludes approach > in favor of a single parameter that supports regular expressions instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-81) Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)
[ https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Marcotte updated MWAR-81: - Attachment: maven-war-plugin-2.1.1-NM-Doc-Test.patch documentations changes and a new Junit test named testSimpleWarPackagingExcludeWithIncludesRegEx > Request enhancement to pattern matching for > packagingIncludes/packagingExcludes functionality (regular expressions?) > > > Key: MWAR-81 > URL: https://jira.codehaus.org/browse/MWAR-81 > Project: Maven 2.x WAR Plugin > Issue Type: Wish > Environment: n/a >Reporter: Bryan Loofbourrow >Priority: Minor > Attachments: maven-war-plugin-2.1.1-NM-Doc-Test.patch, > maven-war-plugin-2.1.1-NM.patch > > > The Maven War Plugin currently permits choosing what files will wind up in > the .war. It does this via two parameters, warSourceIncludes, and > warSourceExcludes. The rule appears to be that the includes are computed, > and a list of matches made, then that list is run against the excludes, and > any matches taken out of the include list. > The only wildcards that appear to be supported are *, **, and ?. > That doesn't work well if you are packaging wars in ears, and therefore want > to exclude all jars from the war, except for one or two that have to be in > the war in order to run properly. "Exclude all but foo.jar and bar.jar" just > doesn't translate well to "here's your simple include template, here's your > simple exclude template" representation, at least with current wildcards. > So this is a wish specifically for something to address the "exclude all but > x, y, and z" need for war source includes/excludes, and a suggestion that it > might be best to deprecate the warSourceIncludes/warSourceExcludes approach > in favor of a single parameter that supports regular expressions instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-387) IntegrationTestMojo has hardcoded target/test-classes/projects for resources
IntegrationTestMojo has hardcoded target/test-classes/projects for resources Key: ARCHETYPE-387 URL: https://jira.codehaus.org/browse/ARCHETYPE-387 Project: Maven Archetype Issue Type: Improvement Components: Plugin Affects Versions: 2.1 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-387) IntegrationTestMojo has hardcoded target/test-classes/projects for resources
[ https://jira.codehaus.org/browse/ARCHETYPE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated ARCHETYPE-387: --- Fix Version/s: 2.2 Assignee: Olivier Lamy > IntegrationTestMojo has hardcoded target/test-classes/projects for resources > > > Key: ARCHETYPE-387 > URL: https://jira.codehaus.org/browse/ARCHETYPE-387 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-91) Cannot run javac from tasks
[ https://jira.codehaus.org/browse/MANTRUN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-91. --- Resolution: Not A Bug Assignee: Benson Margulies This is not a defect. tools.jar aren't in the default maven plugin classpath. If you want to run javac, add a tools.jar reference to the classpath with a dependency in the plugin declaration. > Cannot run javac from tasks > --- > > Key: MANTRUN-91 > URL: https://jira.codehaus.org/browse/MANTRUN-91 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Reporter: Thomas Diesler >Assignee: Benson Margulies > > Embedded error: The following error occurred while executing this line: > /home/tdiesler/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/scripts/antrun-wstools.xml:65: > Unable to find a javac compiler; > com.sun.tools.javac.Main is not on the classpath. > Perhaps JAVA_HOME does not point to the JDK -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-162) Update Ant 1.8.2, avoid insufficient system resources error
[
https://jira.codehaus.org/browse/MANTRUN-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-162.
Resolution: Fixed
Fix Version/s: 1.7
Done.
> Update Ant 1.8.2, avoid insufficient system resources error
> ---
>
> Key: MANTRUN-162
> URL: https://jira.codehaus.org/browse/MANTRUN-162
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Affects Versions: 1.6
> Environment: winxp, maven 3.0.3
>Reporter: Bruno Marti
>Assignee: Benson Margulies
> Fix For: 1.7
>
>
> There is a bug in ant 1.8.1 on copy files bigger than 64mb.
> Something like :
> {code}
>
>
>
>
>
>
>
>
> {code}
> wont work in antrun-plugin 1.6 if the file is bigger than 64mb.
> {color:red}
> Error:
> {color}
> {code}
> An Ant BuildException has occured: Failed to copy \\...my.zip to \\ due
> to Insufficient system resources exist to complete the requested service ->
> [Help 1]
> Caused by: java.io.IOException: Insufficient system resources exist to
> complete the requested servic
> at sun.nio.ch.FileDispatcher.write0(Native Method)
> {code}
> see also: [Ant Bug|https://issues.apache.org/bugzilla/show_bug.cgi?id=49341]
> Update dependency Ant to 1.8.2 or use this workaround for antrun 1.6:
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.apache.ant
> ant
> 1.8.2
>
>
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-162) Update Ant 1.8.2, avoid insufficient system resources error
[
https://jira.codehaus.org/browse/MANTRUN-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282359#comment-282359
]
Benson Margulies commented on MANTRUN-162:
--
the ant 1.8.2 release notes state:
* Removed ant-nodeps.jar; it is now merged into ant.jar.
So I'm updating to just use plain 'ant'.
> Update Ant 1.8.2, avoid insufficient system resources error
> ---
>
> Key: MANTRUN-162
> URL: https://jira.codehaus.org/browse/MANTRUN-162
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Affects Versions: 1.6
> Environment: winxp, maven 3.0.3
>Reporter: Bruno Marti
>
> There is a bug in ant 1.8.1 on copy files bigger than 64mb.
> Something like :
> {code}
>
>
>
>
>
>
>
>
> {code}
> wont work in antrun-plugin 1.6 if the file is bigger than 64mb.
> {color:red}
> Error:
> {color}
> {code}
> An Ant BuildException has occured: Failed to copy \\...my.zip to \\ due
> to Insufficient system resources exist to complete the requested service ->
> [Help 1]
> Caused by: java.io.IOException: Insufficient system resources exist to
> complete the requested servic
> at sun.nio.ch.FileDispatcher.write0(Native Method)
> {code}
> see also: [Ant Bug|https://issues.apache.org/bugzilla/show_bug.cgi?id=49341]
> Update dependency Ant to 1.8.2 or use this workaround for antrun 1.6:
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.apache.ant
> ant
> 1.8.2
>
>
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-130) ant task apply is wrong by PlexusConfiguration
[ https://jira.codehaus.org/browse/MANTRUN-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-130. Resolution: Incomplete Assignee: Benson Margulies I don't see what is being complained about here. Ant and plexus might well disagree. So what? > ant task apply is wrong by PlexusConfiguration > -- > > Key: MANTRUN-130 > URL: https://jira.codehaus.org/browse/MANTRUN-130 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug > Environment: maven 2.0.7 >Reporter: jiangyongyuan >Assignee: Benson Margulies > > run this ant task plugin , the pom file is : > > > test > > run > > > > > > > > > > > > > > > > than the PlexusConfiguration parse : > > > > > > > > > the goal result : file1.txt -o file1.txt > the error result : -o file1.txt file1.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-59) Taskdef/Typedef and Plugin dependencies
[ https://jira.codehaus.org/browse/MANTRUN-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-59. --- Resolution: Incomplete Assignee: Benson Margulies Without a test case I don't think that anyone can ever do anything about this. Creating a test case from this description is too much work. > Taskdef/Typedef and Plugin dependencies > --- > > Key: MANTRUN-59 > URL: https://jira.codehaus.org/browse/MANTRUN-59 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: ttest >Assignee: Benson Margulies > > I'm trying to run an ant task during a Maven run. The classes for that Ant > task are included in my Maven runtime dependencies(maven.runtime.classpath). > Here the relevant snippet from my POM: > > > > > >classname="com.bmw.most.generator.AntTask" > classpathref="maven.runtime.classpath"/> > >targetDirectory="target/generated-sources/most"/> > > This works if I don't provide depedencies in the POM for my plugin. But if I > do provide depedencies it doesn't work. I consider this to be a bug since > that should have no effect on the behaviour of "maven.runtime.classpath". My > first guess is that this is a classloading issue. Probably by providing > dependencies the classloaders get messed up and that causes the taskdef to > not load the classes from maven.runtime.classpath because echoing the value > of maven.runtime.classpath still gives the right classpath. > I have tried all variants of dereferencing maven.runtime.classpath. Didn't > work. > Also which is very interesting if I hardcode the classpath in the taskdef to > absolute pathnames it also does not work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-122) Antrun ignores different settings.xml as specified on Maven command line using -s option.
[ https://jira.codehaus.org/browse/MANTRUN-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-122. Resolution: Incomplete Fix Version/s: 1.6 Assignee: Benson Margulies This looks to be a well-known Maven 2.x problem with resolving plugin dependencies from the reactor, but there's not enough information, nor a reproducible test case, here. > Antrun ignores different settings.xml as specified on Maven command line > using -s option. > - > > Key: MANTRUN-122 > URL: https://jira.codehaus.org/browse/MANTRUN-122 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Scott Lavender >Assignee: Benson Margulies > Fix For: 1.6 > > > I have multiple build environments that each have their own > as defined in separate settings.xml files. At build time I specify which > settings file to be used using the Maven command. > For example: > mvn -s D:\prod\settings.xml clean install > mvn -X -s D:\test\settings.xml clean install > In either case, the entire build process uses the as > defined in the settings. The problem occurs when the Antrun plugin is > invoked, it is unable to resolve some of the artifacts that were just built > and published to the specified local repository. > I have determined that the Antrun plugin is ignoring the settings file being > specified, and looks to the root settings.xml in the Maven installation > instead ( apache-maven-2.0.9\conf\settings.xml). I had initially setup this > file, but no longer maintain my settings there. Instead, I have multiple > settings files, one per product build environment. > Shouldn't the Antrun plugin honor the specified settings.xml values? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-111) Error related to running XSLT - v 1.3
[
https://jira.codehaus.org/browse/MANTRUN-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-111.
Resolution: Not A Bug
Fix Version/s: 1.6
Assignee: Benson Margulies
You tried to use an ant task that is not part of the set of tasks that are
included by default in the antrun plugin. You would have needed to add more
dependencies to the plugin.
> Error related to running XSLT - v 1.3
> -
>
> Key: MANTRUN-111
> URL: https://jira.codehaus.org/browse/MANTRUN-111
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Windows XP
> Maven 2.1.0
>Reporter: Jethrik
>Assignee: Benson Margulies
> Fix For: 1.6
>
>
> The best thing for me to do is probably just try using one of the Maven XSLT
> plugins, which is what I'll do next, but I figured I'd report this. My POM
> looks like this:
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.3
>
>
> generate-custom-pom
>
> pre-integration-test
>
> run
>
>
>
>
>in="${basedir}/pom.xml" out="${basedir}/target/pom.xml"
> style="${basedir}/src/strip-pom-parent.xslt" />
>
>
>
>
>
>
> And running it generates this error:
> [INFO] [antrun:run {execution: generate-custom-pom}]
> [INFO] Executing tasks
> java.lang.ClassNotFoundException:
> org.apache.tools.ant.taskdefs.optional.TraXLia ison
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL
> oader.java:195)
> at
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:255)
> at
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:274)
> at
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.
> java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:169)
> at
> org.apache.tools.ant.taskdefs.XSLTProcess.loadClass(XSLTProcess.java: 548)
> at
> org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProces
> s.java:533)
> at
> org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java :785)
> at
> org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:30 0)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractA
> ntMojo.java:118)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:540)
> at
> org.apache.maven.lifecycle.Default
[jira] Closed: (MANTRUN-166) An Ant BuildException has occured: Problem: failed to create task or type classpath
[
https://jira.codehaus.org/browse/MANTRUN-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-166.
Resolution: Incomplete
Assignee: Benson Margulies
This looks to me to be a support request, not a bug report. I'd guess that your
build.xml uses tasks that aren't included in the standard plugin classpath, in
which case you'd need to add dependencies.
> An Ant BuildException has occured: Problem: failed to create task or type
> classpath
> ---
>
> Key: MANTRUN-166
> URL: https://jira.codehaus.org/browse/MANTRUN-166
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Windows
>Reporter: daivish shah
>Assignee: Benson Margulies
>
> Hi,
> When i use following line of code, I am getting exception.
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
> 1.5
> ${java-version}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.6
>
>
> install
> install
>
> run
>
>
>
>refid="maven.dependency.classpath"/>
>
>
>
>
>
>
>
> crimson
> crimson
> 1.1.3
>
>
>
>
>
> Exception Details.
> [INFO] Executing tasks
> main:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An Ant BuildException has occured: Problem: failed to create task or
> type classpath
> Cause: The name is undefined.
> Action: Check the spelling.
> Action: Check that any custom tasks/types have been declared.
> Action: Check that any / declarations have taken place.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Tue Aug 09 15:26:23 PDT 2011
> [INFO] Final Memory: 12M/21M
> [INFO]
>
> And if i commented out means
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
> 1.5
> ${java-version}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.6
>
>
> install
> install
>
> run
>
>
>
>
>
>
>
>
>
>
>
> crimson
> crimson
> 1.1.3
>
>
>
>
>
> I am getting following type
[jira] Closed: (MANTRUN-164) NullPointer if POM description tag is missing
[ https://jira.codehaus.org/browse/MANTRUN-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-164. Resolution: Fixed Fix Version/s: 1.7 1190514 Of all the properties called out, only description could be null, so I added the obvious if. > NullPointer if POM description tag is missing > - > > Key: MANTRUN-164 > URL: https://jira.codehaus.org/browse/MANTRUN-164 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Lee Butts >Assignee: Benson Margulies > Fix For: 1.7 > > Attachments: pom.xml > > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-antrun-plugin:1.6:run (cobertura-report) > on project all: Error executing ant tasks: null > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at > org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) > at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:126) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:73) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:287) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing > ant tasks: null > at > org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:287) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 27 more > Caused by: java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:394) > at > org.apache.tools.ant.PropertyHelper.setProperty(PropertyHelper.java:330) > at org.apache.tools.ant.Project.setProperty(Project.java:507) > at > org.apache.maven.plugin.antrun.AntRunMojo.copyProperties(AntRunMojo.java:359) > at > org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:263) > ... 29 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-49) seems ignoring classpath
[
https://jira.codehaus.org/browse/MANTRUN-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-49.
---
Resolution: Not A Bug
Fix Version/s: 1.6
Assignee: Benson Margulies
The EJB plugin requires additional dependencies on ant which are not included
in the plugin classpath by default. Add them to the plugin execution with
elements.
> seems ignoring classpath
> ---
>
> Key: MANTRUN-49
> URL: https://jira.codehaus.org/browse/MANTRUN-49
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Fedora
>Reporter: Jacek Gerbszt
>Assignee: Benson Margulies
> Fix For: 1.6
>
> Attachments: testcase.tar.gz
>
>
> I'm trying to run xdoclet in ant build file called from antrun plugin. The
> build file is very simple:
> {code:xml}
>
>
>
>
>
>
>name="commons-collections/commons-collections/3.1/commons-collections-3.1.jar"/>
>name="commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar"/>
>name="jboss/jboss-j2ee/4.0.2/jboss-j2ee-4.0.2.jar"/>
>
>name="xdoclet/xdoclet/1.2.3/xdoclet-1.2.3.jar"/>
>name="xdoclet/xdoclet-ejb-module/1.2.3/xdoclet-ejb-module-1.2.3.jar"/>
>
>
>
>
>
>
>
>
>
>classpathref="xdoclet.classpath" name="ejbdoclet"/>
>
>
>
>dir="${basedir}/src/main/java"/>
>
>
>
>
> {code}
> When executed directly from command (ant
> -Dmaven.repository=/home/javor/.m2/repository) it works fine. But fails when
> embedded in antrun:
> {code:xml}
>
> maven-antrun-plugin
> 1.2-SNAPSHOT
>
>
> generate-sources
>
> run
>
>
>
>antfile="build.xml">
>value="${settings.localRepository}"/>
>
>
>
>
>
>
> {code}
> Maven output:
> {noformat}
> ...
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
>
> run:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error executing ant tasks
>
> Embedded error: The following error occurred while executing this line:
> /home/javor/workspace/testcase/build.xml:26: Can't create a remoteinterface
> element under ejbdoclet. Make sure the jar file containing the corresponding
> subtask class is on the classpath specified in the that defined {2}.
> ...
> {noformat}
> Could you show me any workaround or put a bit of light on that problem?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-167) Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version
[
https://jira.codehaus.org/browse/MANTRUN-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-167.
Resolution: Not A Bug
Fix Version/s: 1.6
Assignee: Benson Margulies
This isn't a bug, it's a support requuest, and belongs on the user mailing list.
> Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version
>
>
> Key: MANTRUN-167
> URL: https://jira.codehaus.org/browse/MANTRUN-167
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Windows
>Reporter: daivish shah
>Assignee: Benson Margulies
> Fix For: 1.6
>
>
> Hi,
> I am using MAVEN 2.2.1 version and trying to compile my classes from ANT
> script.
> I want to compile my classes with JDK 1.4.2 version. How can i do it ?
> Following one is my entry which i am using EVEN i am setting up rt.jar and
> tools.jar with JDK 1.4.2 in my build.xml file still my Eclipse is referring
> JDK 1.5 version only.
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.6
>
>
> install
> install
>
> run
>
>
>
> ${java-version}
>
> ${java-version}
>
>antfile="WPSEjb_build.xml" />
>
>
>
>
>
>
> sun.jdk
> tools
> 1.4.2
> system
>
> ${java.home}/lib/tools.jar
>
>
>
>
> Please advice me which property is available in maven-antrun-plugin so i can
> set that and my compiler use JDK 1.4.2 version ?
> I am really stuck here. I am looking for your reply.
> Thanks,
> daivish..
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-170) Allow antrun to avoid failing the build
[ https://jira.codehaus.org/browse/MANTRUN-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-170. Resolution: Fixed Fix Version/s: 1.7 Done in 1190498. > Allow antrun to avoid failing the build > --- > > Key: MANTRUN-170 > URL: https://jira.codehaus.org/browse/MANTRUN-170 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 1.7 > > > I would like to be able to create failsafe-like executions using antrun. In > particular, the use case is to use antrun in pre-integration-test, such that > a failure would still allow post-integration-test to run. (Obviously, the > tests would need to be able to detect this situation and punt.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-76) problem with wsgen ant task from maven-antrun-plugin
[
https://jira.codehaus.org/browse/MANTRUN-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-76.
---
Resolution: Incomplete
Fix Version/s: 1.6
Assignee: Benson Margulies
There is not enough information in here to reproduce a problem.
> problem with wsgen ant task from maven-antrun-plugin
>
>
> Key: MANTRUN-76
> URL: https://jira.codehaus.org/browse/MANTRUN-76
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Reporter: Kevin
>Assignee: Benson Margulies
> Fix For: 1.6
>
>
> I am using maven 2.0.4 and am trying to generate all of the portable
> artifacts for a JAX-WS web service from a JAX-WS service endpoint
> implementation class.
> I can generate them and specify the directory where the generated sources or
> classes should come.
> However, when I use:
> sourcedestdir="${project.build.directory}/generated-sources/main/java"
> destdir="${project.build.directory}/generated-classes/main/java"
> and try to add this source directory as source directory in maven with:
>
>
> ${project.build.directory}/generated-sources/main/java
>
>
> It still doesn't add it as source directory.
> There is a plugin to add source directories: build-helper-maven-plugin
> This solves the problem for eclipse, but the generated-classes are not added
> to the jar that is created.
> How can I add these generated-classes to the jar?
> I already used wsimport several times and there I don't have any problems.
> The generated-sources directory is added as source directory and the
> generated-classes are in the jar that is created.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-147) Flag to turn on Ant debug mode(s)
[ https://jira.codehaus.org/browse/MANTRUN-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-147. Resolution: Won't Fix Fix Version/s: 1.6 Assignee: Benson Margulies Paul's workaround looks sufficient (-X) and no further comment. > Flag to turn on Ant debug mode(s) > - > > Key: MANTRUN-147 > URL: https://jira.codehaus.org/browse/MANTRUN-147 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: John Casey >Assignee: Benson Margulies > Fix For: 1.6 > > > It'd be useful in debugging antrun executions if we could turn on a flag to > indicate which debug/verbose mode to enable for the Ant execution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-37) Antrun breaks when using xdoclet plugin
[
https://jira.codehaus.org/browse/MANTRUN-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-37.
---
Resolution: Won't Fix
Fix Version/s: 1.6
Assignee: Benson Margulies
Looking at the trail here, it seems very unlikely that this is/was an antrun
problem rather than a maven issue, or even a repository with its nose out of
joint.
> Antrun breaks when using xdoclet plugin
> ---
>
> Key: MANTRUN-37
> URL: https://jira.codehaus.org/browse/MANTRUN-37
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Maven 2.0.1
>Reporter: Mike Perham
>Assignee: Benson Margulies
>Priority: Critical
> Fix For: 1.6
>
>
> I just updated to antrun v1.1 (which needs to be marked as released in jira
> BTW) and find that my multimodule build is now breaking. Running the build
> in the child module itself works fine but if I build the parent, it fails
> when it gets to the child with the antrun task. Here's part of the debug
> output. Note it says 1.1 in the dependency tree but 1.0 further down.
> {noformat}
> [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
> runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
> runtime)
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
> for runtime)
> [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
> [DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
> [DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> Component descriptor cannot be found in the component repository:
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.De
[jira] Closed: (MANTRUN-50) Attribute not supported for task from Antrun.
[
https://jira.codehaus.org/browse/MANTRUN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MANTRUN-50.
---
Resolution: Not A Bug
Fix Version/s: 1.6
The ejb task requires additional jars in the plugin classpath.
> Attribute not supported for task from Antrun.
> --
>
> Key: MANTRUN-50
> URL: https://jira.codehaus.org/browse/MANTRUN-50
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, Maven 2.0.4, Weblogic 8.1-sp2, java 1.4_2,
> 2G Ram, Ant 1.6.5
>Reporter: Michael D Johnson
> Fix For: 1.6
>
> Attachments: build.xml
>
>
> When running task using command line Ant, task executes as expected.
> When running same target using Antrun plugin, task fails with error message
> stating that "fork" is not a valid attribute of task. I'm not sure
> if this is a classpath issue with Antrun not passing all properties to Ant,
> or if this is a failure of the Plugin.
> The task in question appears as follows:
>
> fork="yes" jndiPrefix="pm/" wls81="true" noValueClasses="true"
> noImports="false">
>
>
>
> The taskdef for this task appears as follows:
>name="ejbgen"
> classname="com.bea.wls.ejbgen.ant.EJBGenAntTask"
> classpath="${common.lib}/ejbgen.jar"/>
> I have also attached the build.xml file for reference.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTRUN-131) maven-antrun-plugin with the ejbgen ant task
[ https://jira.codehaus.org/browse/MANTRUN-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MANTRUN-131. Resolution: Not A Bug Fix Version/s: 1.6 To use tasks that require additional jars in the class path, list them as dependencies of the plugin in your pom. > maven-antrun-plugin with the ejbgen ant task > - > > Key: MANTRUN-131 > URL: https://jira.codehaus.org/browse/MANTRUN-131 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: Maven version: 2.0.10 > Java version: 1.5.0_14 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: polireddy > Fix For: 1.6 > > Attachments: ejbgen-build-maven.xml, pom.xml > > > When i am calling ant build.xml from maven to run ejbgen task, getting the > following issue. > [null] Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/j > avadoc/Type > [null] at com.bea.util.jam.provider.JamServiceFactoryImpl.createSourceB > uilder(JamServiceFactoryImpl.java:205) > [null] at com.bea.util.jam.provider.JamServiceFactoryImpl.createBuilder > (JamServiceFactoryImpl.java:158) > [null] at com.bea.util.jam.provider.JamServiceFactoryImpl.createClassLo > ader(JamServiceFactoryImpl.java:137) > [null] at com.bea.util.jam.provider.JamServiceFactoryImpl.createService > (JamServiceFactoryImpl.java:78) > [null] at com.bea.sgen.loader.JClassLoaderImpl.load(JClassLoaderImpl.ja > va:107) > [null] at com.bea.sgen.SGen.run(SGen.java:190) > [null] at com.bea.wls.ejbgen.EJBGen.main(EJBGen.java:212) > [null] at com.bea.wls.ejbgen.EJBGen.main(EJBGen.java:238) > [ejbgen] Java returned: 1 > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An Ant BuildException has occured: The following error occurred while > exe > cuting this line: > C:\apps-maven\sasejb\sasejb-ear\ejbgen-build-maven.xml:32: Java returned: 1 > If i run ant build.xml from command prompt, not getting any issue. it's > working fine. > Issue is comming if i do from Maven. > Would you please me to fix this issue. it's very urgent for me -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-120) sql task does not respect onerror=continue
[ https://jira.codehaus.org/browse/MANTRUN-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282341#comment-282341 ] Benson Margulies commented on MANTRUN-120: -- This would appear to be a problem with the sql task in ant; please supply a test case (perhaps using derby?). > sql task does not respect onerror=continue > -- > > Key: MANTRUN-120 > URL: https://jira.codehaus.org/browse/MANTRUN-120 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: Maven 2.2.1, > jRockit (Java 6) >Reporter: René Zanner >Priority: Blocker > > When defining an sql task, the antrun plugin propagates it's failure although > "onerror" is set to "continue": the maven build just terminates without any > meaningful error message. > With antrun 1.2 it still works (the build continues in case of SQL error > messages), but with the current version the build fails. > Here are the last lines of my mvn output (I removed the irrelevant parts): > [sql] Executing resource: [...]\mut.database-schema.drop.sql > [sql] Failed to execute: grant select on SEQ_MUT_A to rzanner > [sql] java.sql.SQLSyntaxErrorException: ORA-01749: [...] > As you can see there is not even a "BUILD ERROR" message or something > similar... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-170) Allow antrun to avoid failing the build
Allow antrun to avoid failing the build --- Key: MANTRUN-170 URL: https://jira.codehaus.org/browse/MANTRUN-170 Project: Maven 2.x Antrun Plugin Issue Type: New Feature Affects Versions: 1.6 Reporter: Benson Margulies I would like to be able to create failsafe-like executions using antrun. In particular, the use case is to use antrun in pre-integration-test, such that a failure would still allow post-integration-test to run. (Obviously, the tests would need to be able to detect this situation and punt.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIASITETOOLS-51) site.xml parameter and template variables not documented
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282334#comment-282334 ] Robert Scholte commented on DOXIASITETOOLS-51: -- Hervé, Once DOXIA-450 is released, we can use the [ContextTool|http://velocity.apache.org/tools/releases/2.0/javadoc/org/apache/velocity/tools/generic/ContextTool.html] to display all available variables. > site.xml parameter and template variables not documented > - > > Key: DOXIASITETOOLS-51 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-51 > Project: Maven Doxia Sitetools > Issue Type: Bug >Reporter: SebbASF > > There's no proper documentation on the Maven site descriptor "custom" tag. > It's not mentioned in the main documentation [1], and is only mentioned in > passing in [2] - which in turn is not referenced from [1] > Here are the full details from [2]: > customDOM Custom configuration for use with customized > Velocity templates > The DOM reference above appears to be an instance of Xpp3Dom [3]. > Also, the Doxia code sets various context variables (in DefaultSiteRenderer > ?). > This should all be documented, along with some simple examples, and > referenced as necessary from the Maven site plugin documentation > [1] > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > [2] > http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html > [3] > http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/xml/Xpp3Dom.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-483) Update SCM Perforce Provider to use P4Java
[ https://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282331#comment-282331 ] Brian Jackson commented on SCM-483: --- Sorry for the long delay, I missed a step with releasing this. It is now available in Maven Central. > Update SCM Perforce Provider to use P4Java > -- > > Key: SCM-483 > URL: https://jira.codehaus.org/browse/SCM-483 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.2 >Reporter: Tom Rodriguez > Fix For: future > > Attachments: maven-scm-perforce-p4java.jar > > > Perforce has developed a new Java Native API for access to perforce called > P4Java. You can access it here: > ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely > reworked API does not require that the p4 client be installed on the system. > The SCM Perforce Provider should be modified to use this new native java API > to eliminate the many issues involved with depending on the p4 executable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.
[ https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282328#comment-282328 ] Tony Chemit commented on MJARSIGNER-19: --- Olivier is the Guy ;) Thanks. > Make mojo code reusable from another mojo + customize the working directory. > > > Key: MJARSIGNER-19 > URL: https://jira.codehaus.org/browse/MJARSIGNER-19 > Project: Maven 2.x Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Tony Chemit >Assignee: Olivier Lamy >Priority: Trivial > Fix For: 1.2 > > Attachments: create-jarsigner-sharedcomponent.diff, > MJARSIGNER-19.patch > > > In the webstart-maven-plugin We used the old jarsigner mojo (from the jar > plugin). > We'd like to use now this plugin as the mojo from the jar plugin is > deprecated for this one (see MWEBSTART-149) > Moreover, we want to use yet another working directory and at the moment in > the mojo this is hardcoed to project.getBasedir(). > Here is a patch which fix our needs. > Hope this patch will be apply soon, I would really like to use your mojo :) > Thanks for your work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2818) Upload LESS Engine
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juven Xu closed MAVENUPLOAD-2818. - Resolution: Won't Fix Assignee: Juven Xu > Upload LESS Engine > -- > > Key: MAVENUPLOAD-2818 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2818 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Marcel Overdijk >Assignee: Juven Xu > > LESS for Java > LESS extends CSS with: variables, mixins, operations and nested rules. Best > of all, LESS uses existing CSS syntax. The following projects enable the use > of the original less.js distribution in pure JVM environment thanks to Rhino. > LESS Engine > LESS Engine provides basic access to the core LESS functionality. It's a core > library that can be used for a variety of JVM based LESS applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2818) Upload LESS Engine
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282327#comment-282327 ] Juven Xu commented on MAVENUPLOAD-2818: --- lesscss-engine 1.2.11 is already in central: http://search.maven.org/#search%7Cga%7C1%7Clesscss-engine if you want to upload 1.1.4, please go to: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository if you are a member of the project, please use: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide this codehaus MAVENUPLOAD project is no longer active. thanks, Juven > Upload LESS Engine > -- > > Key: MAVENUPLOAD-2818 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2818 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Marcel Overdijk > > LESS for Java > LESS extends CSS with: variables, mixins, operations and nested rules. Best > of all, LESS uses existing CSS syntax. The following projects enable the use > of the original less.js distribution in pure JVM environment thanks to Rhino. > LESS Engine > LESS Engine provides basic access to the core LESS functionality. It's a core > library that can be used for a variety of JVM based LESS applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-550) site:site parameter does not work
[
https://jira.codehaus.org/browse/MSITE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSITE-550:
---
Fix Version/s: (was: 2.4)
> site:site parameter does not work
> --
>
> Key: MSITE-550
> URL: https://jira.codehaus.org/browse/MSITE-550
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: SebbASF
>Assignee: Lukas Theussl
> Fix For: 3.0
>
> Attachments: MSITE-550.zip
>
>
> The site:site goal has an optional attributes parameter:
> {quote}
> attributes:
> The template properties for rendering the site.
> * Type: java.util.Map
> * Required: No
> * Expression: ${attributes}
> {quote}
> However this does not work - no parameters are created for the template.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.
[ https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJARSIGNER-19. -- Resolution: Fixed Fix Version/s: 1.2 Assignee: Olivier Lamy so all done. Have fun :-) > Make mojo code reusable from another mojo + customize the working directory. > > > Key: MJARSIGNER-19 > URL: https://jira.codehaus.org/browse/MJARSIGNER-19 > Project: Maven 2.x Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Tony Chemit >Assignee: Olivier Lamy >Priority: Trivial > Fix For: 1.2 > > Attachments: create-jarsigner-sharedcomponent.diff, > MJARSIGNER-19.patch > > > In the webstart-maven-plugin We used the old jarsigner mojo (from the jar > plugin). > We'd like to use now this plugin as the mojo from the jar plugin is > deprecated for this one (see MWEBSTART-149) > Moreover, we want to use yet another working directory and at the moment in > the mojo this is hardcoed to project.getBasedir(). > Here is a patch which fix our needs. > Hope this patch will be apply soon, I would really like to use your mojo :) > Thanks for your work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-211) add unit tests for jar signer component (tests are only in the mojo)
add unit tests for jar signer component (tests are only in the mojo) Key: MSHARED-211 URL: https://jira.codehaus.org/browse/MSHARED-211 Project: Maven Shared Components Issue Type: Task Components: maven-jarsigner Reporter: Olivier Lamy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.
[ https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282323#comment-282323 ] Olivier Lamy commented on MJARSIGNER-19: code imported in r1190297. I leave it open as I prefer to have a real external component located in : http://svn.apache.org/repos/asf/maven/shared/trunk/ maven-jarsigner in order to have release cycle different from the plugin. > Make mojo code reusable from another mojo + customize the working directory. > > > Key: MJARSIGNER-19 > URL: https://jira.codehaus.org/browse/MJARSIGNER-19 > Project: Maven 2.x Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Tony Chemit >Priority: Trivial > Attachments: create-jarsigner-sharedcomponent.diff, > MJARSIGNER-19.patch > > > In the webstart-maven-plugin We used the old jarsigner mojo (from the jar > plugin). > We'd like to use now this plugin as the mojo from the jar plugin is > deprecated for this one (see MWEBSTART-149) > Moreover, we want to use yet another working directory and at the moment in > the mojo this is hardcoed to project.getBasedir(). > Here is a patch which fix our needs. > Hope this patch will be apply soon, I would really like to use your mojo :) > Thanks for your work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-169) Antrun does not fully expand ${setting.x} properties before passing them to ant
Antrun does not fully expand ${setting.x} properties before passing them to ant
---
Key: MANTRUN-169
URL: https://jira.codehaus.org/browse/MANTRUN-169
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: Benson Margulies
In a parent POM of the current project, includes:
${settings.localRepository}/bt/jug/bt_root
${bt.root.location}/rlp/lib/${bt.arch}
the antrun plugin passes bt.libdir to ant as:
${settings.localRepository}/bt/jug/bt_root
It does not replace settings.localRepository before passing it through. This
doesn't work very well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-331) Add to purge-local-repository goal ability to clean only snapshots
[ https://jira.codehaus.org/browse/MDEP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEP-331. - Resolution: Fixed Fix Version/s: 2.4 Assignee: Olivier Lamy (was: Brian Fox) fixed r1190290. Thanks! > Add to purge-local-repository goal ability to clean only snapshots > -- > > Key: MDEP-331 > URL: https://jira.codehaus.org/browse/MDEP-331 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: purge-local-repository >Affects Versions: 2.3 > Environment: win32,unix >Reporter: Hrabur Trndafilov >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: snapshots-only.patch > > > Hi, > In order to build a pipelined build where the downstream builds use the > upstream artifacts we need to clean the SNAPSHOT versions (the downstream > depends on) from the local repository and always download them from the > internal Maven repository. > To achieve this it would be very useful to have possibility to tell > purge-local-repositiry goal to clean only the SNAPSHOT dependencies, > something like snapshotsOnly parameter. > A patch with the fix we use locally is attached. > Thanks, > Hrabur -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-354) Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
[
https://jira.codehaus.org/browse/WAGON-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated WAGON-354:
---
Fix Version/s: 2.1
> Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
> --
>
> Key: WAGON-354
> URL: https://jira.codehaus.org/browse/WAGON-354
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0, 2.0
> Environment: Maven 3.0.3, Site-Plugin 3.0, Wagon 2.0
>Reporter: Juergen Kellerer
>Priority: Critical
> Fix For: 2.1
>
>
> I always get StringIndexOutOfBoundsException on the attempt to deploy a site
> with SFTP using Maven 3 + Site Plugin 3.
> Calling *"mvn site-deploy"* causes:
> {noformat}
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:464)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:296)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:257)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:165)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying 'c:\Projects\OS\doxia-include\target\site' to remo
> te repository:
> sftp://web.sourceforge.net/home/groups/d/do/doxia-include/htdocs/:
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:286)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:447)
> ... 24 more
> Caused by: 4:
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1713)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdir(SftpWagon.java:204)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.ftpRecursivePut(SftpWagon.java:300)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:277)
> ... 25 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 0
> at java.lang.String.charAt(String.java:686)
> at
> com.jcraft.jsch.ChannelSftp.remoteAbsolutePath(ChannelSftp.java:2367)
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1691)
> ... 28 more
> {noformat}
> *The configuration is*:
> {code:xml}
>
> doxia-include
>
>
>
> ${application.id}.shell.sourceforge.net
> ${application.id}.shell.sourceforge.net
>
> sftp://web.sourceforge.net/home/groups/d/do/${application.id}/htdocs
>
> {code}
> (Btw. I tried variuous urls, "../htdocs", "../htdocs/" and "../htdocs/." but
> the site plugin always normalizes them to "../htdocs/", which is actually the
> right thing to do.)
> *My assumption why it happens:*
> I looked at the sources of wagon (particularly to the methods mentioned in
> the stack trace), and I think the issue seems to be that:
> - Site Plugin 3 always normalizes the remote directory to end with a trailing
> slash.
> - WagonSftp.putDirectory:277 calls ScpHelper.getResourceFilename(
> destinationDirectory ) on this directory which returns an empty string.
> - WagonSfto.ftpRecursivePut:300 calls mkdir with an empty string which causes
> the exception.
> Actually it looks as if older site plugins added a trailing "/." to the path
> instead of just "/" as otherwise it would have been broken before (I did not
> verify this). Nevertheless I think the bug is in the Wagon implementation as
> it should not fail if the destination is given like this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-615) Mercurial (HG) SCM Provider not detected in 3.0, was in 3.0-beta-3
[
https://jira.codehaus.org/browse/MSITE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSITE-615.
--
Resolution: Not A Bug
Assignee: Olivier Lamy
reopen if still issue with the new configuration.
> Mercurial (HG) SCM Provider not detected in 3.0, was in 3.0-beta-3
> --
>
> Key: MSITE-615
> URL: https://jira.codehaus.org/browse/MSITE-615
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Fedora 15, Java 7u1, Maven 3.0.3 (r1075438; 2011-02-28
> 12:31:09-0500)
>Reporter: Leon Blakey
>Assignee: Olivier Lamy
>
> I deploy my maven site with mercurial. In 3.0-beta-3 and
> 3.0-beta-4-20110712.115141-32 this worked perfectly but in 3.0 it fails.
> Configuration:
> {code}
>
>
> ...
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
> org.apache.maven.scm
> maven-scm-api
> 1.5
>
>
> org.apache.maven.scm
>
> maven-scm-provider-hg
> 1.5
>
>
>
>
>
>
>
>
> MYPROJECT.googlecode.com
> scm:hg:https://site.MYPROJECT.googlecode.com/hg/
>
>
> {code}
> I also have my username and password configured in settings.xml
> With this configuration and maven-site-plugin at 3.0-beta-3, it works. With
> this exact same configuration and maven-site-plugin at 3.0, it fails with
> this when deploying
> {quote}
> Unsupported protocol: 'scm' for site deployment to
> distributionManagement.site.url=scm:hg:https://site.MYPROJECT.googlecode.com/hg/.
> Currently supported protocols are: https, file, http.
> Protocols may be added through wagon providers.
> For more information, see
> http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html
> {quote}
> Note to deploy I'm running `mvn clean site-deploy` and `mvn clean site:site
> site:deploy`
> I think this qualifies as a regression.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-615) Mercurial (HG) SCM Provider not detected in 3.0, was in 3.0-beta-3
[
https://jira.codehaus.org/browse/MSITE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282309#comment-282309
]
Olivier Lamy commented on MSITE-615:
Did you have a look at
[http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html]
?
Here you have to add the wagon scm provider:
{code}
org.apache.maven.plugins
maven-site-plugin
3.0
org.apache.maven.wagon
wagon-scm
1.0
{code}
> Mercurial (HG) SCM Provider not detected in 3.0, was in 3.0-beta-3
> --
>
> Key: MSITE-615
> URL: https://jira.codehaus.org/browse/MSITE-615
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Fedora 15, Java 7u1, Maven 3.0.3 (r1075438; 2011-02-28
> 12:31:09-0500)
>Reporter: Leon Blakey
>
> I deploy my maven site with mercurial. In 3.0-beta-3 and
> 3.0-beta-4-20110712.115141-32 this worked perfectly but in 3.0 it fails.
> Configuration:
> {code}
>
>
> ...
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
> org.apache.maven.scm
> maven-scm-api
> 1.5
>
>
> org.apache.maven.scm
>
> maven-scm-provider-hg
> 1.5
>
>
>
>
>
>
>
>
> MYPROJECT.googlecode.com
> scm:hg:https://site.MYPROJECT.googlecode.com/hg/
>
>
> {code}
> I also have my username and password configured in settings.xml
> With this configuration and maven-site-plugin at 3.0-beta-3, it works. With
> this exact same configuration and maven-site-plugin at 3.0, it fails with
> this when deploying
> {quote}
> Unsupported protocol: 'scm' for site deployment to
> distributionManagement.site.url=scm:hg:https://site.MYPROJECT.googlecode.com/hg/.
> Currently supported protocols are: https, file, http.
> Protocols may be added through wagon providers.
> For more information, see
> http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html
> {quote}
> Note to deploy I'm running `mvn clean site-deploy` and `mvn clean site:site
> site:deploy`
> I think this qualifies as a regression.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-42) WagonHelper.getWagonResourceFetcher does not support HTTPS
[
https://jira.codehaus.org/browse/MINDEXER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MINDEXER-42.
Resolution: Fixed
fixed r1190229
> WagonHelper.getWagonResourceFetcher does not support HTTPS
> --
>
> Key: MINDEXER-42
> URL: https://jira.codehaus.org/browse/MINDEXER-42
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 4.1.3
>
>
> The intent of {{WagonHelper.getWagonResourceFetcher}} is to make it easy to
> use Wagon as a transport when available. In practice, it is useless since it
> cannot handle HTTPS connections.
> The workaround is simple - construct a {{WagonFetcher}} directly with the
> desired scheme - but then the existing convenience methods should not be
> used. Recommend deprecating them, and optionally introducing a replacement
> {code:java}
> public WagonFetcher getWagonResourceFetcher( final TransferListener
> listener, final String protocol,
> final AuthenticationInfo
> authenticationInfo, final ProxyInfo proxyInfo )
> throws ComponentLookupException
> {
> return new WagonFetcher( plexusContainer.lookup( Wagon.class,
> protocol ), listener, authenticationInfo, proxyInfo );
> }
> {code}
> or
> {code:java}
> public WagonFetcher getWagonResourceFetcher( final TransferListener
> listener, final String indexUpdateUrl,
> final AuthenticationInfo
> authenticationInfo, final ProxyInfo proxyInfo )
> throws ComponentLookupException
> {
> return new WagonFetcher( plexusContainer.lookup( Wagon.class,
> URI.create( indexUpdateUrl ).getScheme() ), listener, authenticationInfo,
> proxyInfo );
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINDEXER-42) WagonHelper.getWagonResourceFetcher does not support HTTPS
[
https://jira.codehaus.org/browse/MINDEXER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MINDEXER-42:
-
Fix Version/s: 4.1.3
Assignee: Olivier Lamy
> WagonHelper.getWagonResourceFetcher does not support HTTPS
> --
>
> Key: MINDEXER-42
> URL: https://jira.codehaus.org/browse/MINDEXER-42
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 4.1.3
>
>
> The intent of {{WagonHelper.getWagonResourceFetcher}} is to make it easy to
> use Wagon as a transport when available. In practice, it is useless since it
> cannot handle HTTPS connections.
> The workaround is simple - construct a {{WagonFetcher}} directly with the
> desired scheme - but then the existing convenience methods should not be
> used. Recommend deprecating them, and optionally introducing a replacement
> {code:java}
> public WagonFetcher getWagonResourceFetcher( final TransferListener
> listener, final String protocol,
> final AuthenticationInfo
> authenticationInfo, final ProxyInfo proxyInfo )
> throws ComponentLookupException
> {
> return new WagonFetcher( plexusContainer.lookup( Wagon.class,
> protocol ), listener, authenticationInfo, proxyInfo );
> }
> {code}
> or
> {code:java}
> public WagonFetcher getWagonResourceFetcher( final TransferListener
> listener, final String indexUpdateUrl,
> final AuthenticationInfo
> authenticationInfo, final ProxyInfo proxyInfo )
> throws ComponentLookupException
> {
> return new WagonFetcher( plexusContainer.lookup( Wagon.class,
> URI.create( indexUpdateUrl ).getScheme() ), listener, authenticationInfo,
> proxyInfo );
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-43) WagonFetch.retrieve swallows root causes of problems
[
https://jira.codehaus.org/browse/MINDEXER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MINDEXER-43.
Resolution: Fixed
fixed r1190226
> WagonFetch.retrieve swallows root causes of problems
>
>
> Key: MINDEXER-43
> URL: https://jira.codehaus.org/browse/MINDEXER-43
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 4.1.3
>
>
> {{WagonFetch.retrieve}} catches {{AuthorizationException}},
> {{ResourceDoesNotExistException}}, and {{WagonException}} and rethrows as
> {{IOException}} without including the original exception as a cause. This may
> make it more difficult to diagnose errors: while
> {{TransferListener.transferError}} will receive the root exception, it may
> not be obvious that an error here is the "final" error (e.g. if a {{.gz}}
> index cannot be found but a {{.zip}} can); inspecting the final
> {{IOException}} from {{IndexUpdater.fetchAndUpdateIndex}} is more convenient.
> Fix should be easy: in {{retrieve}}, replace the three occurrences of
> {code:java}
> throw new SomeException( ... );
> {code}
> with
> {code:java}
> SomeException e2 = new SomeException( ... );
> e2.initCause( e );
> throw e2;
> {code}
> ({{IOException}} has a constructor to do this directly in JDK 6 but I guess
> you are compatible with JDK 5. Anyway {{FileNotFoundException}} still does
> not.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINDEXER-43) WagonFetch.retrieve swallows root causes of problems
[
https://jira.codehaus.org/browse/MINDEXER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MINDEXER-43:
-
Fix Version/s: 4.1.3
Assignee: Olivier Lamy
> WagonFetch.retrieve swallows root causes of problems
>
>
> Key: MINDEXER-43
> URL: https://jira.codehaus.org/browse/MINDEXER-43
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 4.1.3
>
>
> {{WagonFetch.retrieve}} catches {{AuthorizationException}},
> {{ResourceDoesNotExistException}}, and {{WagonException}} and rethrows as
> {{IOException}} without including the original exception as a cause. This may
> make it more difficult to diagnose errors: while
> {{TransferListener.transferError}} will receive the root exception, it may
> not be obvious that an error here is the "final" error (e.g. if a {{.gz}}
> index cannot be found but a {{.zip}} can); inspecting the final
> {{IOException}} from {{IndexUpdater.fetchAndUpdateIndex}} is more convenient.
> Fix should be easy: in {{retrieve}}, replace the three occurrences of
> {code:java}
> throw new SomeException( ... );
> {code}
> with
> {code:java}
> SomeException e2 = new SomeException( ... );
> e2.initCause( e );
> throw e2;
> {code}
> ({{IOException}} has a constructor to do this directly in JDK 6 but I guess
> you are compatible with JDK 5. Anyway {{FileNotFoundException}} still does
> not.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-617) Variable substitution in the site url doesn't work
[
https://jira.codehaus.org/browse/MSITE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282301#comment-282301
]
Olivier Lamy commented on MSITE-617:
can you try with something different:
{code}
scp://server/sites/${project.artifactId}/${project.version}
sites
Project Website
{code}
> Variable substitution in the site url doesn't work
> --
>
> Key: MSITE-617
> URL: https://jira.codehaus.org/browse/MSITE-617
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.3
> Environment: Windows 7 and RHEL6
>Reporter: Claus Nielsen
>
> site:deploy fails because variable substitution in the site url no longer
> works (it did in version 2.2).
> The distributionManagement section in out POM looks something like this:
>
>
> sites
> Project Website
>
> scp://server/sites/${project.artifactId}/${project.version}
>
>
> Copying the site to the above mentioned url fails with this message:
> [INFO] Error uploading site
> Embedded error: Error performing commands for file transfer
> Exit code: 1 - bash:
> /sites/${project.artifactId}/${project.version}/../../id-of-the-artifact/0.2.8-SNAPSHOT:
> bad substitution
> Ie. the substitutiuon variables have not been substituted, instead the
> property values have been appended to the url along with a few dots and
> dashes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (WAGON-355) Expose PreferredAuthentications property of jsch in some way
[ https://jira.codehaus.org/browse/WAGON-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MDEPLOY-142 to WAGON-355: Component/s: (was: deploy:deploy) wagon-ssh Affects Version/s: (was: 2.7) 2.0 Key: WAGON-355 (was: MDEPLOY-142) Project: Maven Wagon (was: Maven 2.x and 3.x Deploy Plugin) > Expose PreferredAuthentications property of jsch in some way > > > Key: WAGON-355 > URL: https://jira.codehaus.org/browse/WAGON-355 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Affects Versions: 2.0 > Environment: Any. I happened to test with Maven 2.2.1 and jdk 1.7 >Reporter: Lester Ward >Priority: Minor > > Deploy using scp. Under jdk 1.7, support for gssapi-with-mic works > differently than it did under jdk 1.6, to the point where we do not want to > use it. Ultimately, the deploy plugin uses the jsch library to deploy using > scp. This library has an property called PreferredAuthentications which > controls which authentications get used, in which order. The code in > AbstractJschWagon hard-codes > "gssapi-with-mic,publickey,password,keyboard-interactive" into this property. > I'd like a way to somehow override that, preferably in my project's pom file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
