[jira] Created: (MECLIPSE-364) incorrect dependencies with different projectNameTemplates in submodules
incorrect dependencies with different projectNameTemplates in submodules - Key: MECLIPSE-364 URL: http://jira.codehaus.org/browse/MECLIPSE-364 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Dependencies resolution and build path, Multi-projects Affects Versions: 2.4 Environment: MacOSX, mvn 2.0.6 Reporter: Frank Stolle Attachments: patch.txt If you have a project with different submodules and you use different projectNameTemplate-Settings in some modules, the resulting .project and .classpath -Files contains wrong project-names, because the wrong template-name will be applied. Example: A +---B (with projectNameTemplate b-[artifactId]) +---C (with projectNameTemplate c-[artifactId]) And C depends on B. In C the dependency will result in project c-B and not b-B, as suspected. A testcase is currently not submitted, because I don't know how to check files in sub-projects. Only the expected-directory of the main-project will be checked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-128) Support ability to specify multiple includeScope parameters
Support ability to specify multiple includeScope parameters - Key: MDEP-128 URL: http://jira.codehaus.org/browse/MDEP-128 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.0-alpha-4 Reporter: Bryan Stopp Assignee: Brian Fox You can only configure the plugin with either one includeScope or one excludeScope. When executing the plugin to copy dependencies with the following configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idcopy-dependencies/id phasevalidate/phase goals goalcopy-dependencies/goal /goals /execution /executions configuration outputDirectory/src/main/webapp/WEB-INF/lib/outputDirectory overWriteReleasesfalse/overWriteReleases overWriteIfNewertrue/overWriteIfNewer overWriteSnapshotstrue/overWriteSnapshots excludeScopeprovided/excludeScope /configuration /plugin It does exclude the provided scope, but it includes the test scope [easymock, dbunit, and junit appear in the output directory]. I tried to correct this problem by replacing the excludeScope parameter with two includeScope parameters, one for compile one for runtime, but only the first parameter was actually used. I also tried to exclude test but got an error, something like, Can't exclude tests as that would exclude everything!. The goal is to be able to recreate the default copy functionality that is accomplished when executing a mvn package command, but be able to specify a maven-dependency-plugin configuration. When specifying this configuration, it overrides the default settings throughout the entire build life-cycle (as it should). But it is impossible to configure the plugin in the exact same was as the default settings. This is needed to support copying dependencies into the WEB-INF/lib folder within Eclipse workspaces, to support embedded application-server deployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-362) update command ignores date parameter
update command ignores date parameter - Key: SCM-362 URL: http://jira.codehaus.org/browse/SCM-362 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.0 Reporter: Andrew Williams Priority: Blocker The api (and thus all providers) have no support for calling update using the date parameter that the api advertises. This is ignored and a simple update with no date / version parameters is called instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3042) Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project.
[ http://jira.codehaus.org/browse/MNG-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118272 ] Petar Tahchiev commented on MNG-3042: - I have the same problem - I want to extend the surefire plugin and every time I run it, I get a null-pointer exception, because the instant variables are null. According to maven-inherit plugin I have to propagate the fields using reflection. Well, propagation in my case does not work, because the fields in the surefire plugin are all private :-(, and I get a: can not access a member of class org.apache.maven.plugin.surefire.SurefirePlugin with modifiers private exception. Any other suggestions? Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project. - Key: MNG-3042 URL: http://jira.codehaus.org/browse/MNG-3042 Project: Maven 2 Issue Type: Bug Components: Plugin API Reporter: Leopoldo Agdeppa III Fix For: Reviewed Pending Version Assignment I have an Existing maven-plugin-a and I want to extend its functionality and put it in maven-plugin-b, so what i did is I put the the maven-plugin-a as a dependecy in maven-plugin-b and extended the mojo class from A, the issue on this is that paramter fields from A is not set, when I used plugin-B, I think this disables reusing and extending of mojos -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-128) Support ability to specify multiple includeScope parameters
[ http://jira.codehaus.org/browse/MDEP-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118277 ] Brian Fox commented on MDEP-128: You shouldn't ever need to include or exclude two scopes at the same time because they are comprised of each other. The default is to include test scope, which includes everything. If you don't want any test dependencies or provided dependencies, then include runtime and exclude provided. The scopes being interpreted are the scopes as maven sees them, not as specified in the pom. So the test scope includes everything, runtime includes compile but not provided etc. Support ability to specify multiple includeScope parameters - Key: MDEP-128 URL: http://jira.codehaus.org/browse/MDEP-128 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.0-alpha-4 Reporter: Bryan Stopp Assignee: Brian Fox You can only configure the plugin with either one includeScope or one excludeScope. When executing the plugin to copy dependencies with the following configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idcopy-dependencies/id phasevalidate/phase goals goalcopy-dependencies/goal /goals /execution /executions configuration outputDirectory/src/main/webapp/WEB-INF/lib/outputDirectory overWriteReleasesfalse/overWriteReleases overWriteIfNewertrue/overWriteIfNewer overWriteSnapshotstrue/overWriteSnapshots excludeScopeprovided/excludeScope /configuration /plugin It does exclude the provided scope, but it includes the test scope [easymock, dbunit, and junit appear in the output directory]. I tried to correct this problem by replacing the excludeScope parameter with two includeScope parameters, one for compile one for runtime, but only the first parameter was actually used. I also tried to exclude test but got an error, something like, Can't exclude tests as that would exclude everything!. The goal is to be able to recreate the default copy functionality that is accomplished when executing a mvn package command, but be able to specify a maven-dependency-plugin configuration. When specifying this configuration, it overrides the default settings throughout the entire build life-cycle (as it should). But it is impossible to configure the plugin in the exact same was as the default settings. This is needed to support copying dependencies into the WEB-INF/lib folder within Eclipse workspaces, to support embedded application-server deployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3343) Add new lifecylce mapping maven-skin
Add new lifecylce mapping maven-skin -- Key: MNG-3343 URL: http://jira.codehaus.org/browse/MNG-3343 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.8 Reporter: Benjamin Bentmann Priority: Minor Attachments: new-lifecycle-mappings.patch Currently, creating a custom skin for Maven is done by a project with packaging jar. The attached patch intents to introduce an individual lifecycle mapping named maven-skin for this purpose. Why that? I consider the re-usage of the jar packaging an abuse for the case of building a Maven skin. On the one hand, the jar packaging does too much. Skins usually do not get compiled or unit-tested, do they? Since any unused plugin invocation is an unnecessary risk of a build failure (sorry to say), I would appreciate a lifecycle mapping that is not overdressed. On the other hand, I could image that skins required some additional processing some day like a check whether all required images are present in the skin or whether the CSS references unknown IDs/names. Having a distinct lifecylcle mapping in the Maven Core would allow for a central definition of the build steps instead of requiring all users to extend the jar packaging. Especially for the first reason, i.e. having a packaging that does not more than required, the patch also defines a resources packaging. Such a packaging is intended for JARs that just contain resources one wants to share with other projects like rulesets for PMD, Checkstyle, etc. The lifecylcle mappings resources and maven-skin are identiical (now) but I consider it a bad practice to merge different use-cases just because they happen to be equal by coindicence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118289
]
John Allen commented on MNG-3244:
-
remember that the site distro URL and the project URL are related. If you add
the documented but missing feature of being '/' aware for one of them (i.e. as
you have with this patch and its handling of site distro url) you will need to
add the same feature to the project url assembly.
We have had to declare explicit project.url and distroManagement.site.url
elements in EVERY pom of our multi-module proejcts because we also use real
identifying information in these URLS, namely the
${project.groupId}/${project.artifactId}/${project.version}
inherited site url not properly handling parameters
---
Key: MNG-3244
URL: http://jira.codehaus.org/browse/MNG-3244
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, Sites Reporting
Affects Versions: 2.0.7
Reporter: Jacob Robertson
Assignee: Brian Fox
Fix For: 2.0.9
Attachments: fix-inherited-site-url.patch, guide-site.patch
Here is the test case to reroduce this problem. Take the following two
pom.xml files
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdfoo/artifactId
namefoo/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
distributionManagement
site
idfoo-site/id
urlfile://C:/Documents and
Settings/foo/.m2/site/${project.artifactId}/url
/site
/distributionManagement
/project
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdbaz/artifactId
namebaz/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
parent
artifactIdfoo/artifactId
groupIdorg.bar/groupId
version1.0-SNAPSHOT/version
/parent
/project
And run the site-deploy goal on each. What you get under the site directory
is this
- site
/- foo
---/site docs
/- baz
---/- baz (extra directory)
--- ---/site docs
This is the simplest test case. In the case where I have a grandparent
pom, the site directory uses the grandparent/parent as the path to the site,
and doesn't use the actual artifactId of the artifact I'm creating the site
for.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-279) Inheritance of elements from site descriptor quite broken
[ http://jira.codehaus.org/browse/MSITE-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MSITE-279: Attachment: site-directory.patch Here is a fix. Inheritance of elements from site descriptor quite broken - Key: MSITE-279 URL: http://jira.codehaus.org/browse/MSITE-279 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-6 Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP Reporter: Benjamin Bentmann Priority: Critical Attachments: project.zip, site-directory.patch After updating to 2.0-beta-6, I never get proper site output for multi module projects. I attached a simple dummy project that shall help to reproduce the problem. When I perform a reactor build of the site (i.e. project-parent mvn site), the pages of the sub module project-module-1 properly inherit most of the decorator elements, except for the custom overview menu. That is, the site of the sub module contains the menu configured for the parent project despite the sub module specifying its own menu.- In contrast, when I only build the site of the sub module (i.e. project-module-1 mvn site), many decoration elements are not inherited from the parent's site.xml like version, bannerRight, skin, links. However, now the sub module's site properly outputs its own menu items (i.e. Module-Item instead of Parent-Item for the attached projects). This issues might be a duplicate/relative of MSITE-256 but as I cannot safely judge from its description, I opened a new issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NMAVEN-101) DotnetTestMojo should fail the build if NUnit assembly not found
DotnetTestMojo should fail the build if NUnit assembly not found Key: NMAVEN-101 URL: http://jira.codehaus.org/browse/NMAVEN-101 Project: NMaven Issue Type: Bug Affects Versions: 0.15 Reporter: Shane Isbell Attachments: log.txt If the NUnit assembly is not found, then the DotnetTestMojo still passes the tests. This can be verified by looking at the log file of IT0007. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-284) getRelativePath fails on non-normalized inputs
getRelativePath fails on non-normalized inputs -- Key: MSITE-284 URL: http://jira.codehaus.org/browse/MSITE-284 Project: Maven 2.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 2.0-beta-6 Reporter: Benjamin Bentmann Priority: Minor Attachments: normalized-paths.patch The algo in AbstractSiteMojo.getRelativePath() assumes that its input paths are both normalized and produces wrong output if it gets something like dir/../dir. Attached is a simple unit test and a fix for the method itself. FYI, non-normalized path are easily created by Maven if one has a non-Maven-like directory layout with project/ project-parent/ project-module-1/ where simple string/path concatenation produces a path like project/project-module-1/../project-parent when referencing the parent POM from the module POM. Path/URL transformations like normalization/relativization/resolution are quite ubiquitous in Maven. Isn't there a nice util class around that prevents each and every plugin developer to reimplement those error-prone methods? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-97) dependency:tree not consistent with maven core's dependency tree
[
http://jira.codehaus.org/browse/MDEP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118306
]
Brian Fox commented on MDEP-97:
---
Kenney: is this still an issue?
dependency:tree not consistent with maven core's dependency tree
Key: MDEP-97
URL: http://jira.codehaus.org/browse/MDEP-97
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 2.0-alpha-4
Reporter: Kenney Westerhof
This plugin applies dependencyManagement to transitive dependencies (which is
really what I want),
but maven itself does not.
For instance, mvn help:dependencies on sandbox/maven-plug-it-plugin lists:
{noformat}
[INFO] org.apache.maven.plugins:maven-plug-it-plugin:maven-plugin:1.0-SNAPSHOT
[INFO]junit:junit:jar:3.8.1:test
[INFO]org.apache.maven.shared:file-management:jar:1.1:compile
[INFO] org.apache.maven.shared:maven-shared-io:jar:1.0:compile
[INFO]org.apache.maven:maven-settings:jar:2.0:compile
[INFO]org.apache.maven:maven-plugin-api:jar:2.0.4:compile
[INFO]
org.apache.maven.shared:maven-test-tools:jar:1.0-20061102.004837-1:test
[INFO] easymock:easymock:jar:1.2_Java1.3:test
[INFO]org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
[INFO]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
[INFO] commons-collections:commons-collections:jar:2.0:compile
[INFO] velocity:velocity:jar:1.4:compile
[INFO] velocity:velocity-dep:jar:1.4:runtime
[INFO]
org.apache.maven.shared:maven-plugin-testing-tools:jar:1.0-alpha-2-20061221.044609-6:compile
[INFO] org.apache.maven:maven-model:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-repository-builder:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact-manager:jar:2.0:compile
[INFO] org.apache.maven:maven-project:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-common-artifact-filters:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact:jar:2.0:compile
[INFO] org.apache.maven.shared:maven-invoker:jar:2.0.5:compile
[INFO] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
[INFO] org.apache.maven:maven-monitor:jar:2.0:compile
{noformat}
Adding 'dependencyManagement' for plexus-utils to force it to 1.1 (which
doesn't work in m2 itself), it lists:
{noformat}
[INFO] org.apache.maven.plugins:maven-plug-it-plugin:maven-plugin:1.0-SNAPSHOT
[INFO]junit:junit:jar:3.8.1:test
[INFO]org.apache.maven.shared:file-management:jar:1.1:compile
[INFO] org.codehaus.plexus:plexus-utils:jar:1.1:compile
[INFO] org.apache.maven.shared:maven-shared-io:jar:1.0:compile
[INFO]org.apache.maven:maven-settings:jar:2.0:compile
[INFO]org.apache.maven:maven-plugin-api:jar:2.0.4:compile
[INFO]
org.apache.maven.shared:maven-test-tools:jar:1.0-20061102.004837-1:test
[INFO] easymock:easymock:jar:1.2_Java1.3:test
[INFO]org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
[INFO]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
[INFO] commons-collections:commons-collections:jar:2.0:compile
[INFO] velocity:velocity:jar:1.4:compile
[INFO] velocity:velocity-dep:jar:1.4:runtime
[INFO]
org.apache.maven.shared:maven-plugin-testing-tools:jar:1.0-alpha-2-20061221.044609-6:compile
[INFO] org.apache.maven:maven-model:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-repository-builder:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact-manager:jar:2.0:compile
[INFO] org.apache.maven:maven-project:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-common-artifact-filters:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact:jar:2.0:compile
[INFO] org.apache.maven.shared:maven-invoker:jar:2.0.5:compile
[INFO] org.apache.maven:maven-monitor:jar:2.0:compile
{noformat}
Either we say this is the desired behavior (+1), or MNG-1577 should be fixed.
The problem here is that if MNG-1577 is going for the
if-pom-version-is-this-then-do-that-otherwise-do-that,
this plugin should exhibit the same behaviour.
I'd like both maven core and this plugin to use the same dependency
resolution code, or drop
the dependency-tree code and use maven's internal dependency graph (which
doesn't exist yet).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-117.
--
Resolution: Won't Fix
includeClassifiers does not work
Key: MDEP-117
URL: http://jira.codehaus.org/browse/MDEP-117
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Environment: windows xp
Reporter: srikanth madarapu
Assignee: Brian Fox
This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
2.0-alpha-04, not sure which one i am using.
This is how my execution looks like...
execution
idunpack-lang-translations/id
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${webapp.deploy.dir}/WEB-INF/outputDirectory
includeGroupIdscom.workscape/includeGroupIds
includeArtifactIdscaps-translations/includeArtifactIds
includeTypeszip/includeTypes
includeClassifiersapp/includeClassifiers
stripVersiontrue/stripVersion
/configuration
/execution
I have another zip in that folder with classifier 'flex' but that is getting
unzipped too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-118) Resolving dependencies with the same JDK specified by the Compiler plugin
[ http://jira.codehaus.org/browse/MDEP-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-118. -- Resolution: Cannot Reproduce Need a sample project to figure out what is being asked. Resolving dependencies with the same JDK specified by the Compiler plugin - Key: MDEP-118 URL: http://jira.codehaus.org/browse/MDEP-118 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: resolve Affects Versions: 2.0-alpha-4 Reporter: Claudio Di Vita Assignee: Brian Fox The dependencies have to be resolved with the same JDK specified by the Compiler plugin, not with the version used by Maven scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-94) ignoreFailures flag is ignored
[ http://jira.codehaus.org/browse/WAGON-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-94: -- Attachment: (was: WAGON-91-94.diff) ignoreFailures flag is ignored -- Key: WAGON-94 URL: http://jira.codehaus.org/browse/WAGON-94 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: xp,solaris,linux Reporter: Dan Tran Attachments: WAGON-91-94.diff The current AbstractJschWagon.java has an option ignore error found in stderr stream, how ever this option is not checked. For my case, I wouild like to setup that option so what wagon would not throw exception and have me to handle error myself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-94) ignoreFailures flag is ignored
[ http://jira.codehaus.org/browse/WAGON-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-94: -- Attachment: WAGON-91-94.diff replace the patch, i was incorrectly submitted ignoreFailures flag is ignored -- Key: WAGON-94 URL: http://jira.codehaus.org/browse/WAGON-94 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: xp,solaris,linux Reporter: Dan Tran Attachments: WAGON-91-94.diff The current AbstractJschWagon.java has an option ignore error found in stderr stream, how ever this option is not checked. For my case, I wouild like to setup that option so what wagon would not throw exception and have me to handle error myself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-94) ignoreFailures flag is ignored
[ http://jira.codehaus.org/browse/WAGON-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed WAGON-94. - Assignee: Dan Tran Resolution: Fixed Fix Version/s: 1.0 fixed at rev 607799 ignoreFailures flag is ignored -- Key: WAGON-94 URL: http://jira.codehaus.org/browse/WAGON-94 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: xp,solaris,linux Reporter: Dan Tran Assignee: Dan Tran Fix For: 1.0 Attachments: WAGON-91-94.diff The current AbstractJschWagon.java has an option ignore error found in stderr stream, how ever this option is not checked. For my case, I wouild like to setup that option so what wagon would not throw exception and have me to handle error myself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-91) NPE when known host file is empty
[ http://jira.codehaus.org/browse/WAGON-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed WAGON-91. - Assignee: Dan Tran Resolution: Fixed Fix Version/s: 1.0 fixed at rev 607799. NPE when known host file is empty - Key: WAGON-91 URL: http://jira.codehaus.org/browse/WAGON-91 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: xp, linux Reporter: Dan Tran Assignee: Dan Tran Fix For: 1.0 Attachments: WAGON-91.diff There is an issue where HostKeyRepository hkr = sch.getHostKeyRepository(); return null due to empty known host file or when using NullKnownHostProvider. AbstractJschWagon should check for null which means no host key to process -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
