[jira] Commented: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
[
http://jira.codehaus.org/browse/ARCHETYPE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242768#action_242768
]
Joe Littlejohn commented on ARCHETYPE-191:
--
Is this patch present in the core for Maven 2.2.1?
Also, would it work for directories as well as files? What I need is the
ability to create this kind of project:
{noformat}
XXX-Parent
\XXX-Core
\XXX-Persistence
\XXX-Web
\...
{noformat}
When I generate the archetype, I'd like the XXX to be replaced with a supplied
name. I've tried various techniques to achieve this, all without success. It
seems to be complicated by the fact that in order for resources to be put in
the right place, the structure of 'archetype-resources' must match the
structure of the project being generated. Is what I'm trying to do impossible
with the archetype plugin right now?
Ability to filter filenames (rename files) during project generation
Key: ARCHETYPE-191
URL: http://jira.codehaus.org/browse/ARCHETYPE-191
Project: Maven Archetype
Issue Type: New Feature
Components: Generator
Affects Versions: 2.0-alpha-3
Reporter: Wendy Smoak
Fix For: 2.0-alpha-4
Attachments: mytest-1.0.1.jar, mytest-1.0.1.pom,
ReplaceAnyContextPropertyEnhancement-v2.patch,
ReplaceAnyContextPropertyEnhancement.patch, ReplaceFileNameToken_RegExp.patch
When generating a new project from an archetype, I need to filter not only
values within files, but the names of the files themselves.
For example, in .NET projects, the project files (.sln, .csproj) match the
name of the solution or project rather than having a fixed name like Maven's
pom.xml does.
Another user raised a similar issue on the mailing list, the ability to
filter in the name of Java source code files.
See: http://www.nabble.com/Archetype%2C-define-file-name-ts18430983.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-482. --- Resolution: Fixed Fix Version/s: 2.7 Fixed in r1033896. Users upgrading to this version of the plugin should run mvn -Dsurefire.junit4.upgradecheck=true install at least once to verify that they don't have any tests that will be ignored by the new plugin version. Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Assignee: Kristian Rosenvold Fix For: 2.7 Attachments: JUnit4DirectoryTestSuite.java, test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-582) The HTTP protocol does not support user authentication
[ http://jira.codehaus.org/browse/SCM-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Groznykh updated SCM-582: -- Attachment: fix_auth_bug.diff Patch The HTTP protocol does not support user authentication -- Key: SCM-582 URL: http://jira.codehaus.org/browse/SCM-582 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.4 Environment: Ubuntu 10.10, Maven 3 Reporter: Nick Groznykh Attachments: fix_auth_bug.diff If the GIT repository have a url like http://user:passw...@domain.com/test.git then functions gitURL() of class GitScmProviderRepository returns url without username and password. -- 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-582) The HTTP protocol does not support user authentication
The HTTP protocol does not support user authentication -- Key: SCM-582 URL: http://jira.codehaus.org/browse/SCM-582 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.4 Environment: Ubuntu 10.10, Maven 3 Reporter: Nick Groznykh Attachments: fix_auth_bug.diff If the GIT repository have a url like http://user:passw...@domain.com/test.git then functions gitURL() of class GitScmProviderRepository returns url without username and password. -- 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-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly
[
http://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242791#action_242791
]
Brian Fox commented on MNG-4893:
I think we should stick with the x.y.z-SNAPSHOT form for both expanded and
non-expanded forms. Widening that pattern in Maven is just bound to cause
additional problems in all the ecosystem tools that need to interpret snapshot
v release
[regression] Version x.y.z.SNAPSHOT does not deploy correctly
-
Key: MNG-4893
URL: http://jira.codehaus.org/browse/MNG-4893
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Priority: Critical
Fix For: 3.0.1
When using a version that ends with .SNAPSHOT instead of the usual
-SNAPSHOT, Maven 3.0 changes the project version to the timestamped
version. So 5.2.0.SNAPSHOT becomes something like
5.2.0.20101109.215833-1. A Nexus snapshot repository will reject this
deployment because the version in the directory name does not end with
SNAPSHOT.
I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not
work in Maven 3.0. The build returns an HTTP 400 error when deploying to
Nexus.
Error from Nexus log
{noformat}
2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing
of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got
exception during processing
request PUT
http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of
item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
{noformat}
--
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-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly
[
http://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242794#action_242794
]
Jason van Zyl commented on MNG-4893:
Why exactly do you need x.y.z.SNAPSHOT instead of x.y.z-SNAPSHOT? If they are
trying have OSGi versioning then we should probably have something that means
something in OSGi which would be x.y.z.qualifier. We want to move toward OSGi
and this could be the first step. But I think you just took advantage of
something we were doing wrong. We can probably help Mark Proctor fix the Drools
build.
[regression] Version x.y.z.SNAPSHOT does not deploy correctly
-
Key: MNG-4893
URL: http://jira.codehaus.org/browse/MNG-4893
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Priority: Critical
Fix For: 3.0.1
When using a version that ends with .SNAPSHOT instead of the usual
-SNAPSHOT, Maven 3.0 changes the project version to the timestamped
version. So 5.2.0.SNAPSHOT becomes something like
5.2.0.20101109.215833-1. A Nexus snapshot repository will reject this
deployment because the version in the directory name does not end with
SNAPSHOT.
I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not
work in Maven 3.0. The build returns an HTTP 400 error when deploying to
Nexus.
Error from Nexus log
{noformat}
2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing
of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got
exception during processing
request PUT
http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of
item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
{noformat}
--
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-4894) Profile is ignored for dependencies
Profile is ignored for dependencies
---
Key: MNG-4894
URL: http://jira.codehaus.org/browse/MNG-4894
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0
Environment: Ubuntu 10.10
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_22
OS name: linux version: 2.6.35-23-generic arch: amd64 Family: unix
Reporter: Marcel
Attachments: profiles.zip
I have a war module with a dependency on a jar module.
In the jar module there are a number of dependencies defined in profiles.
When packaging the war module with one of these profiles, the dependencies for
that profile are not included in the war archive.
The attached file contains an example for this situation.
In the parent module I executed the following statements:
{code}
mvn install -N
mvn clean install -P p2
{code}
In the resulting war file I miss all the transitive dependencies defined in the
profile 'p2'.
The following jar files can be found when running the commands with Maven 3:
{code}
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/jar-1.0.jar
{code}
When running the commands with Maven 2.2.1 I get:
{code}
WEB-INF/lib/xml-apis-1.0.b2.jar
WEB-INF/lib/commons-collections-2.1.jar
WEB-INF/lib/commons-digester-1.6.jar
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-validator-1.2.0.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/commons-logging-1.0.4.jar
WEB-INF/lib/jar-1.0.jar
WEB-INF/lib/oro-2.0.8.jar
{code}
--
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: (ARCHETYPE-347) Allow fields like scm, developers, licenses, etc to be set when generating an archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] G Fernandes updated ARCHETYPE-347: -- Attachment: archertype.patch This patch allow setting in archetype.properties values for description, url. In case they are not specified, the values are being taken from the project itself. The patch also fills in values for licenses, developers, and SCM, all taken from the originating project. The patch makes it possible to close and release a staging repository that has pom validation turned on in Nexus Pro. Allow fields like scm, developers, licenses, etc to be set when generating an archetype --- Key: ARCHETYPE-347 URL: http://jira.codehaus.org/browse/ARCHETYPE-347 Project: Maven Archetype Issue Type: New Feature Components: Creator Reporter: Paul Gier Attachments: archertype.patch Currently a generated archetype only sets basic fields like the groupId, artifactId, etc. There should be options to set generated values for all POM fields. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242801#action_242801 ] Arseniy Alekseyev commented on SUREFIRE-482: Kristian, thank you for fixing this. However, I think I've found a bug that could lead to more serious consequences than we have thought of: instead of if ( suite.isAssignableFrom( value ) ) it should be if ( runner.isAssignableFrom( value ) ) or better yet if ( true ). As it is now, classes with custom runners, or even with a standard Theories runner could be ignored. Should I create a new issue with a test? Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Assignee: Kristian Rosenvold Fix For: 2.7 Attachments: JUnit4DirectoryTestSuite.java, test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242801#action_242801 ] Arseniy Alekseyev edited comment on SUREFIRE-482 at 11/11/10 9:08 AM: -- Kristian, thank you for fixing this. However, I think I've found a bug that could lead to more serious consequences than we have thought of. When checking 'value' parameter for @RunWith attribute instead of if ( suite.isAssignableFrom( value ) ) it should be if ( runner.isAssignableFrom( value ) ) or better yet if ( true ). As it is now, classes with custom runners, or even with a standard Theories runner could be ignored. Should I create a new issue with a test? was (Author: rotsor): Kristian, thank you for fixing this. However, I think I've found a bug that could lead to more serious consequences than we have thought of: instead of if ( suite.isAssignableFrom( value ) ) it should be if ( runner.isAssignableFrom( value ) ) or better yet if ( true ). As it is now, classes with custom runners, or even with a standard Theories runner could be ignored. Should I create a new issue with a test? Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Assignee: Kristian Rosenvold Fix For: 2.7 Attachments: JUnit4DirectoryTestSuite.java, test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- 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: (ARCHETYPE-350) Proposal for making (sub-)module handling more flexible with regards to folder names
Proposal for making (sub-)module handling more flexible with regards to folder
names
Key: ARCHETYPE-350
URL: http://jira.codehaus.org/browse/ARCHETYPE-350
Project: Maven Archetype
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Marc Wirth
Attachments: module_name.patch
We have a use-case where we want modules to use the artifact ID of the parent
as prefix, but the modules folder should only use the suffix to keep overall
paths short (without becoming too redundant.)
To make configuration more flexible I've changed the implementation so that the
name of a module is used to define the output folder where the module is
created and that it is run through velocity so that arbitrary properties can be
defined. Please check the attached patch file.
For example with this patch we could use a archetype-metadata definition like:
{code}
requiredProperty key=subArtifactId
...
module id=${rootArtifactId}.${subArtifactId} dir=__rootArtifactId__.sub
name=${subArtifactId}
{code}
to generate the module (from {{__rootArtifactId__.sub}} in the archetype-zip)
into a folder that only consists of the module name, but having the
rootArtifact ID plus the module name as its artifactId.
I don't have a testcase specifically for this, but at least it doesn't break
the existing fileset-archetype tests.
While looking through the relevant code I've tried to clean up a few other
oddities (artifactId is reset so log output would print a potentially wrong id,
what looked like a mixup of replacements in Strings with ${x} or __x__
delimiters to me).
Also,
http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
says The attributes name, id and dir of the module are used to determine the
directory where to generate that module's files, they also are used to
determine the artifactId of the Maven project corresponding to this module.
but actually the name attribute was never used during generation (only set
during creation, same value as the id). To distinguish the source location
within the archetype, i.e. the dir-attribute, from the destination I used the
name attribute to define the output directory name.
What do you think about that?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242807#action_242807 ] Kristian Rosenvold commented on SUREFIRE-482: - That's really good catch and a nice simplification ! r1033985 just scans for the presence of @RunWith, testcases updated. Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Assignee: Kristian Rosenvold Fix For: 2.7 Attachments: JUnit4DirectoryTestSuite.java, test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- 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: (MNG-4894) Profile is ignored for dependencies
[
http://jira.codehaus.org/browse/MNG-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4894.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
This is a duplicate of MNG-1388, profiles activated by id via settings or CLI
aren't considered for POMs of dependencies. Maven 3.0 is just consistent in
this regard when building a module within the reactor or in isolation whereas
Maven 2.x is not. I.e. with Maven 2.x, cd into the JAR module and install it,
then cd into the WAR module and run mvn clean package from there and observe
that the generated WAR also consists only of three JARs.
Profile is ignored for dependencies
---
Key: MNG-4894
URL: http://jira.codehaus.org/browse/MNG-4894
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0
Environment: Ubuntu 10.10
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_22
OS name: linux version: 2.6.35-23-generic arch: amd64 Family: unix
Reporter: Marcel
Assignee: Benjamin Bentmann
Attachments: profiles.zip
I have a war module with a dependency on a jar module.
In the jar module there are a number of dependencies defined in profiles.
When packaging the war module with one of these profiles, the dependencies
for that profile are not included in the war archive.
The attached file contains an example for this situation.
In the parent module I executed the following statements:
{code}
mvn install -N
mvn clean install -P p2
{code}
In the resulting war file I miss all the transitive dependencies defined in
the profile 'p2'.
The following jar files can be found when running the commands with Maven 3:
{code}
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/jar-1.0.jar
{code}
When running the commands with Maven 2.2.1 I get:
{code}
WEB-INF/lib/xml-apis-1.0.b2.jar
WEB-INF/lib/commons-collections-2.1.jar
WEB-INF/lib/commons-digester-1.6.jar
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-validator-1.2.0.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/commons-logging-1.0.4.jar
WEB-INF/lib/jar-1.0.jar
WEB-INF/lib/oro-2.0.8.jar
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4894) Profile is ignored for dependencies
[
http://jira.codehaus.org/browse/MNG-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242814#action_242814
]
Benjamin Bentmann edited comment on MNG-4894 at 11/11/10 11:08 AM:
---
This is a duplicate of MNG-1388, profiles activated by id via settings or CLI
aren't considered for POMs of dependencies. Maven 3.0 is just consistent in
this regard when building a module within the reactor or in isolation whereas
Maven 2.x is not. I.e. with Maven 2.x, cd into the JAR module and install it,
then cd into the WAR module and run mvn clean package -P p2 from there and
observe that the generated WAR also consists only of three JARs.
was (Author: bentmann):
This is a duplicate of MNG-1388, profiles activated by id via settings or
CLI aren't considered for POMs of dependencies. Maven 3.0 is just consistent in
this regard when building a module within the reactor or in isolation whereas
Maven 2.x is not. I.e. with Maven 2.x, cd into the JAR module and install it,
then cd into the WAR module and run mvn clean package from there and observe
that the generated WAR also consists only of three JARs.
Profile is ignored for dependencies
---
Key: MNG-4894
URL: http://jira.codehaus.org/browse/MNG-4894
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0
Environment: Ubuntu 10.10
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_22
OS name: linux version: 2.6.35-23-generic arch: amd64 Family: unix
Reporter: Marcel
Assignee: Benjamin Bentmann
Attachments: profiles.zip
I have a war module with a dependency on a jar module.
In the jar module there are a number of dependencies defined in profiles.
When packaging the war module with one of these profiles, the dependencies
for that profile are not included in the war archive.
The attached file contains an example for this situation.
In the parent module I executed the following statements:
{code}
mvn install -N
mvn clean install -P p2
{code}
In the resulting war file I miss all the transitive dependencies defined in
the profile 'p2'.
The following jar files can be found when running the commands with Maven 3:
{code}
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/jar-1.0.jar
{code}
When running the commands with Maven 2.2.1 I get:
{code}
WEB-INF/lib/xml-apis-1.0.b2.jar
WEB-INF/lib/commons-collections-2.1.jar
WEB-INF/lib/commons-digester-1.6.jar
WEB-INF/lib/postgresql-8.4-701.jdbc4.jar
WEB-INF/lib/commons-validator-1.2.0.jar
WEB-INF/lib/commons-lang-2.4.jar
WEB-INF/lib/commons-logging-1.0.4.jar
WEB-INF/lib/jar-1.0.jar
WEB-INF/lib/oro-2.0.8.jar
{code}
--
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-1388) Transitive Dependencies in a profile are not used
[ http://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242815#action_242815 ] Benjamin Bentmann commented on MNG-1388: I second Milos' concern about clashing profile ids. I think the approach outlined by Paul in MNG-4531 is more appropriate. Transitive Dependencies in a profile are not used - Key: MNG-1388 URL: http://jira.codehaus.org/browse/MNG-1388 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Environment: Windows XP using Maven 2.0. Reporter: Damian Bradicich Fix For: Issues to be reviewed for 3.x I have a jar project file that defines a dependency inside a certain profile. If I then include that project inside of another war project, the dependencies defined in the jar project's profile isn't getting transferred over to the war. Ie we have this: A depends on SQL or Oracle depending on profile B depends on A. If sql profile is active, I would expect that when I build B, it pulls the transitive dependancy on sql from A. -- 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: (MJAVADOC-302) Classpath cleared after maven-javadoc-plugin:javadoc
Classpath cleared after maven-javadoc-plugin:javadoc Key: MJAVADOC-302 URL: http://jira.codehaus.org/browse/MJAVADOC-302 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.7, 2.6.1, 2.6, 2.5 Environment: mac OSX 10.6.4 Reporter: Bryan Campbell Priority: Blocker Repro Case: - I have a war based maven configuration with the maven-javadoc-plugin as copied below. - mvn jetty:run Result: - When jetty loads, every servlet fails to load, the first is always java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener followed by null pointers and CNFE's on every servlet. When i take out the execution of the maven-javadoc-plugin everything works?! My only guess is that when the javadoc plugin runs, it does something with the classpath such that when jetty runs it doesn't have what it needs to find all the classes correctly. My javadoc configuration is as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution goals goaljavadoc/goal /goals phasegenerate-resources/phase /execution /executions /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Maven overrides up to date artifacts
I've got the following problem with maven 3.0 and artifactory 2.2.3 (2.2.1 won't let maven 3.0 deploy without legacy-mode flag -- metadata problem). Project A depends on Project B. I created a new class in Project B and installed it into my local repository so I can use the class in project A. After importing the new class I'd like to install Project A into my local repo (without -U) but it fails because the compiler cannot find the new created class in Project B. A quick look in the maven output shows that at the beginning of the build maven downloads an old, already deployed version of Project B into the local repo and overrides in the process the version of project B with the new class installed -- so build fails! Maven also reports he cannot found maven-metadata.xml in the local repo. The scenario mentioned above it's not easy to reproduce. Why is it downloading at all? and why is my up to date artifact beeing overriden by an out of date version in the repo? I guess it's an artifactory problem, please help. Greez Chris
[jira] Created: (MECLIPSE-675) downloadSources will not attach artifact-5-sources.jar to artifact-5-jar.jar
downloadSources will not attach artifact-5-sources.jar to artifact-5-jar.jar Key: MECLIPSE-675 URL: http://jira.codehaus.org/browse/MECLIPSE-675 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: Windows7_x64 Reporter: Steve Armstrong Attachments: patch.txt When depending on a project that has WAR as the default artifact, my project uses dependency groupIdgroup/groupId artifactIdartifact/artifactId version5/version classifierjar/classifier /dependency This results in no attached sources for that jar in Eclipse. m2eclipse has raised the same issue but in reverse: MNGECLIPSE-1649 It seems when building the project above, artifact-5-jar-sources.jar is produced in the target folder, but when installed to the local repo (and deployed to the remote repo), it renames the file to artifact-5-sources.jar The diff attached changes the lookup behaviour to not include the classifier unless it's tests. This will bring it in line with m2e's lookup. -- 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: (MECLIPSE-675) downloadSources will not attach artifact-5-sources.jar to artifact-5-jar.jar
[ http://jira.codehaus.org/browse/MECLIPSE-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242821#action_242821 ] Steve Armstrong commented on MECLIPSE-675: -- Sorry, here's the full link to the m2e bug: https://issues.sonatype.org/browse/MNGECLIPSE-1649 downloadSources will not attach artifact-5-sources.jar to artifact-5-jar.jar Key: MECLIPSE-675 URL: http://jira.codehaus.org/browse/MECLIPSE-675 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: Windows7_x64 Reporter: Steve Armstrong Attachments: patch.txt When depending on a project that has WAR as the default artifact, my project uses dependency groupIdgroup/groupId artifactIdartifact/artifactId version5/version classifierjar/classifier /dependency This results in no attached sources for that jar in Eclipse. m2eclipse has raised the same issue but in reverse: MNGECLIPSE-1649 It seems when building the project above, artifact-5-jar-sources.jar is produced in the target folder, but when installed to the local repo (and deployed to the remote repo), it renames the file to artifact-5-sources.jar The diff attached changes the lookup behaviour to not include the classifier unless it's tests. This will bring it in line with m2e's lookup. -- 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
