[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
[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] 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] 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: (MDEP-119) build-classpath should create destination directory for the classpath file
[
http://jira.codehaus.org/browse/MDEP-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-119:
---
Fix Version/s: 2.0-alpha-5
> build-classpath should create destination directory for the classpath file
> --
>
> Key: MDEP-119
> URL: http://jira.codehaus.org/browse/MDEP-119
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: build-classpath
>Affects Versions: 2.0-alpha-4
>Reporter: Adrian Hempel, Atlassian
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.0-alpha-5
>
>
> I am binding the build-classpath goal to the generate-resources phase, as
> follows:
> {code:xml}
>
> maven-dependency-plugin
>
>
> build-classpath
> generate-resources
>
> build-classpath
>
>
>
> ${project.build.outputDirectory}/com/atlassian/bamboo/agent/classserver/Agent.classpath
>
>
>
>
> {code}
> However, it fails, because the target directory doesn't exist:
> bq. {{[INFO] Error while opening/closing classpath file
> '/Users/ahempel/workarea/private/atlassian/bamboo/trunk/bamboo-agent-classserver/target/classes/com/atlassian/bamboo/agent/classserver/Agent.classpath':
> java.io.FileNotFoundException:
> /Users/ahempel/workarea/private/atlassian/bamboo/trunk/bamboo-agent-classserver/target/classes/com/atlassian/bamboo/agent/classserver/Agent.classpath
> (No such file or directory)}}
> The build-classpath goal can be improved by creating the missing directory,
> rather than throwing a FileNotFoundException.
--
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] 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...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> 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-110) Cannot automatically resolve version for transitive dependencies
[
http://jira.codehaus.org/browse/MDEP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-110.
--
Resolution: Won't Fix
The unpack/copy goals aren't doing transitive dependency resolution; the
version of the artifact you want must be defined in the pom hierarchy. If you
want to get full transitive resolution, you can use the
copy/unpack-dependencies goals along with the includes, excludes filters to get
the ones you want.
> Cannot automatically resolve version for transitive dependencies
>
>
> Key: MDEP-110
> URL: http://jira.codehaus.org/browse/MDEP-110
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0-alpha-4
>Reporter: Daniel Siegmann
>Assignee: Brian Fox
>Priority: Minor
> Attachments: unpack-test.zip
>
>
> When using dependency:unpack it is not normally necessary to specify the
> version for dependencies - the version is determined from settings in the
> POM. However, this does not work for transitive dependencies.
> For example, consider modules A and B with a dependency tree B -> A ->
> commons-lang. In module B we have dependency:unpack try to unpack
> commons-lang, without specifying a version. This will fail with the following
> error message, even though the version of this dependency is specified in A.
> [INFO] [dependency:unpack {execution: unpack}]
> [INFO] Configured Artifact: commons-lang:commons-lang:?:jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Unable to find artifact version of commons-lang:commons-lang in either
> dependency list or in project's dependency management.
> [INFO]
>
> The attached example should demonstrate this problem (commons-lang chosen for
> no particular reason).
--
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] 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] 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] 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 , , , . > 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] 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
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> 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] 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: (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: > >org.apache.maven.plugins >maven-dependency-plugin > > > copy-dependencies > validate > > copy-dependencies > > > > > /src/main/webapp/WEB-INF/lib > false > true > true > provided > > > 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] 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] 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] 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: org.apache.maven.plugins maven-dependency-plugin copy-dependencies validate copy-dependencies /src/main/webapp/WEB-INF/lib false true true provided 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: (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
