[jira] Commented: (MEAR-113) The default contextRoot should match the default bundleFileName
[ http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234990#action_234990 ] Stephane Nicoll commented on MEAR-113: -- probably not :) since the patch apparently breaks something. I'll have a look but there's no easy way to this. Using the finalName is no good because this option is never honored in a deployment so doing that here would break that concept. > The default contextRoot should match the default bundleFileName > --- > > Key: MEAR-113 > URL: http://jira.codehaus.org/browse/MEAR-113 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Michael Semb Wever > Fix For: 2.5 > > Attachments: MEAR-113.patch, MEAR-113.patch > > > In a webModule the contextRoot defaults to > "/" + a.getArtifactId() > There is no way AFAIK to have a contextRoot that honours the webModule > artifact's finalName, necessary if it was dynamically set via profiles. > (The only way i see here is to duplicate all the profile information and put > the maven-ear-plugin configuration into each profile, just to insert the > various contextRoot values). > By making the contextRoot instead default to > "/" + getBundleFileName() > this scenario is solved. > The webModule's contextRoot defaults to the build name of the artifact if it > were customised. If that artifact's finalName was not customised then it > defaults back to the artifactId therefore maintaining today's behavior and > not breaking any compatibility. > Patch attached. -- 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: (MEAR-113) The default contextRoot should match the default bundleFileName
[ http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234994#action_234994 ] Michael Semb Wever commented on MEAR-113: - "This patch breakes today's behavior..." Is there a way to check finalName has been declared? And if not to use the existing getArtifactId() approach. That would fix both today's breakage (finalName not being honoured) and the patch's shortcomings (version & classifier being used). > The default contextRoot should match the default bundleFileName > --- > > Key: MEAR-113 > URL: http://jira.codehaus.org/browse/MEAR-113 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Michael Semb Wever > Fix For: 2.5 > > Attachments: MEAR-113.patch, MEAR-113.patch > > > In a webModule the contextRoot defaults to > "/" + a.getArtifactId() > There is no way AFAIK to have a contextRoot that honours the webModule > artifact's finalName, necessary if it was dynamically set via profiles. > (The only way i see here is to duplicate all the profile information and put > the maven-ear-plugin configuration into each profile, just to insert the > various contextRoot values). > By making the contextRoot instead default to > "/" + getBundleFileName() > this scenario is solved. > The webModule's contextRoot defaults to the build name of the artifact if it > were customised. If that artifact's finalName was not customised then it > defaults back to the artifactId therefore maintaining today's behavior and > not breaking any compatibility. > Patch attached. -- 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: (ARCHETYPE-325) order versions when selecting archetype
[
http://jira.codehaus.org/browse/ARCHETYPE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-325.
---
Resolution: Fixed
done in r996275
> order versions when selecting archetype
> ---
>
> Key: ARCHETYPE-325
> URL: http://jira.codehaus.org/browse/ARCHETYPE-325
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 2.0-alpha-5
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.0-alpha-6
>
>
> {noformat}$ mvn archetype:generate
> ...
> [INFO] [archetype:generate {execution: default-cli}]
> [INFO] Generating project in Interactive mode
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> ...
> 79: remote -> maven-archetype-quickstart (An archetype which contains a
> sample Maven project.)
> ...
> Choose a number: 79:
> Choose version:
> 1: 1.0
> 2: 1.0-alpha-1
> 3: 1.0-alpha-2
> 4: 1.0-alpha-3
> 5: 1.0-alpha-4
> 6: 1.1
> 7: 1.1
> Choose a number: : {noformat}
> there is a duplicate, and alpha is before release.
> should be:
> {noformat}Choose version:
> 1: 1.0-alpha-1
> 2: 1.0-alpha-2
> 3: 1.0-alpha-3
> 4: 1.0-alpha-4
> 5: 1.0
> 6: 1.1
> Choose a number: : {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] Updated: (ARCHETYPE-239) Cannot find mojo descriptor for: 'archetype:create' - Treating as non-aggregator (mvn 3.x issue)
[
http://jira.codehaus.org/browse/ARCHETYPE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-239:
Description:
Download http://www.webtide.com/hightide/archetypes/maven-archetype-Spring.zip
cd to unzipped directory.
type mvn install (installs the archetype).
Next, use the archetype like this
{noformat}mvn archetype:create-DarchetypeGroupId=com.webtide
\
-DarchetypeArtifactId=maven-archetype-Spring
\
-DarchetypeVersion=1.0\
-DgroupId=com.bo.oo \
-DartifactId=wex{noformat}
The following error is returned >
{noformat}
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] Attempting to resolve a version for plugin:
org.apache.maven.plugins:maven-archetype-plugin using meta-version: LATEST
[ERROR]
Cannot find mojo descriptor for: 'archetype:create' - Treating as
non-aggregator.
{noformat}
thanks !
was:
Download http://www.webtide.com/hightide/archetypes/maven-archetype-Spring.zip
cd to unzipped directory.
type mvn install (installs the archetype).
Next, use the archetype like this
mvn archetype:create-DarchetypeGroupId=com.webtide
\
-DarchetypeArtifactId=maven-archetype-Spring
\
-DarchetypeVersion=1.0\
-DgroupId=com.bo.oo \
-DartifactId=wex
The following error is returned >
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] Attempting to resolve a version for plugin:
org.apache.maven.plugins:maven-archetype-plugin using meta-version: LATEST
[ERROR]
Cannot find mojo descriptor for: 'archetype:create' - Treating as
non-aggregator.
thanks !
> Cannot find mojo descriptor for: 'archetype:create' - Treating as
> non-aggregator (mvn 3.x issue)
> --
>
> Key: ARCHETYPE-239
> URL: http://jira.codehaus.org/browse/ARCHETYPE-239
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
> Environment: windows. maven-3.0-alpha-2
> works ok in mvn 2.1.
>Reporter: chris bedford
>
> Download
> http://www.webtide.com/hightide/archetypes/maven-archetype-Spring.zip
> cd to unzipped directory.
> type mvn install (installs the archetype).
> Next, use the archetype like this
> {noformat}mvn archetype:create-DarchetypeGroupId=com.webtide
> \
> -DarchetypeArtifactId=maven-archetype-Spring
> \
> -DarchetypeVersion=1.0\
> -DgroupId=com.bo.oo \
> -DartifactId=wex{noformat}
> The following error is returned >
> {noformat}
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO] Attempting to resolve a version for plugin:
> org.apache.maven.plugins:maven-archetype-plugin using meta-version: LATEST
> [ERROR]
> Cannot find mojo descriptor for: 'archetype:create' - Treating as
> non-aggregator.
> {noformat}
> thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-306) archetypes downloaded are not downloaded with their poms
[ http://jira.codehaus.org/browse/ARCHETYPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-306: Fix Version/s: 2.0-alpha-6 > archetypes downloaded are not downloaded with their poms > > > Key: ARCHETYPE-306 > URL: http://jira.codehaus.org/browse/ARCHETYPE-306 > Project: Maven Archetype > Issue Type: Bug >Reporter: Milos Kleint > Fix For: 2.0-alpha-6 > > > the archetype artifacts in local repository that are downloaded by the plugin > don't contain the archetype's pom file. > that becomes a problem when one attempts to index the local repository (using > maven-repository-indexer). For teh archetypes one doesn't get the name and > description indexed (as these are taken from the pom). -- 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-239) Cannot find mojo descriptor for: 'archetype:create' - Treating as non-aggregator (mvn 3.x issue)
[
http://jira.codehaus.org/browse/ARCHETYPE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-239:
Fix Version/s: 2.0-alpha-6
> Cannot find mojo descriptor for: 'archetype:create' - Treating as
> non-aggregator (mvn 3.x issue)
> --
>
> Key: ARCHETYPE-239
> URL: http://jira.codehaus.org/browse/ARCHETYPE-239
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
> Environment: windows. maven-3.0-alpha-2
> works ok in mvn 2.1.
>Reporter: chris bedford
> Fix For: 2.0-alpha-6
>
>
> Download
> http://www.webtide.com/hightide/archetypes/maven-archetype-Spring.zip
> cd to unzipped directory.
> type mvn install (installs the archetype).
> Next, use the archetype like this
> {noformat}mvn archetype:create-DarchetypeGroupId=com.webtide
> \
> -DarchetypeArtifactId=maven-archetype-Spring
> \
> -DarchetypeVersion=1.0\
> -DgroupId=com.bo.oo \
> -DartifactId=wex{noformat}
> The following error is returned >
> {noformat}
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO] Attempting to resolve a version for plugin:
> org.apache.maven.plugins:maven-archetype-plugin using meta-version: LATEST
> [ERROR]
> Cannot find mojo descriptor for: 'archetype:create' - Treating as
> non-aggregator.
> {noformat}
> thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-206) Document how to generate a project from archetype with authenticated repository
[
http://jira.codehaus.org/browse/ARCHETYPE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-206:
Fix Version/s: 2.0-alpha-6
> Document how to generate a project from archetype with authenticated
> repository
> ---
>
> Key: ARCHETYPE-206
> URL: http://jira.codehaus.org/browse/ARCHETYPE-206
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 2.0-alpha-4
>Reporter: Javier Diaz
> Fix For: 2.0-alpha-6
>
>
> When the archetypes are in a password protected repository you can't download
> the archetype unless repository authentication information is specified in
> the settings.xml file, as follows:
> {code:xml}
> -repo
> myuser
> XX
> 664
> 775
>
> {code}
> And the command should be invoked with the archetypeRepository option as
> follows:
> {noformat}mvn archetype:generate -DarchetypeGroupId=mygroup \
> -DarchetypeArtifactId= \
> -DarchetypeVersion=X -DgroupId=com.abc \
> -DartifactId=dummy \
> -Dversion=1.0.0-SNAPSHOT \
> -DarchetypeRepository=http://www.abc.com/maven2{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] Updated: (ARCHETYPE-282) When reading the archetype-metadata.xml file, would be helpful to know if the XML was badly formed
[ http://jira.codehaus.org/browse/ARCHETYPE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-282: Fix Version/s: 2.0-alpha-6 > When reading the archetype-metadata.xml file, would be helpful to know if the > XML was badly formed > -- > > Key: ARCHETYPE-282 > URL: http://jira.codehaus.org/browse/ARCHETYPE-282 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 2.0-alpha-4 > Environment: Windows, but affects all envs >Reporter: Chris Melikian >Priority: Minor > Fix For: 2.0-alpha-6 > > Attachments: DefaultArchetypeArtifactManager.java.patch > > > If archetype-metadata.xml is malformed, say with a module element which is > unclosed (missing slash), there is no error message displayed in the log > output, even with the debug(-X) parameter set. > The DefaultArchetypeArtifactManager class contains methods which catch > exceptions but do not log the problem. The problem is just silently ignored. > I've created a patch file to log the problem at WARN level so that anyone who > has a problem can see why it occured. -- 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-4788) [regression] Appassembler Maven Plugin doesn't work like as it should
[
http://jira.codehaus.org/browse/MNG-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235006#action_235006
]
Dennis Lundberg commented on MNG-4788:
--
I just wanted to confirm that this has been fixed in trunk. I tried it on my
own project and it works as expected now using a freshly built Maven
3.0-SNAPSHOT.
> [regression] Appassembler Maven Plugin doesn't work like as it should
> -
>
> Key: MNG-4788
> URL: http://jira.codehaus.org/browse/MNG-4788
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
> Environment: The 3.0-beta-3 that is staged for release.
>Reporter: Dennis Lundberg
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-4
>
> Attachments: MNG-4788.zip
>
>
> Comparing the results between beta-2 and beta-3 I see a difference in my
> builds for the Appassembler Maven Plugin (@mojo.codehaus.org). In beta-2 the
> plugin (correctly) assembles the dependencies in a flat structure in my
> configured "lib" directory. Whereas beta-3 puts the dependencies in my
> configured "lib" directory using a Maven repository layout structure.
> Example in beta 2:
> {noformat}
> [INFO] Installing C:\Documents and
> Settings\dlg01\.m2\repository\commons-dbutils\commons-dbutils\1.1\commons-dbutils-1.1.jar
> to
> C:\Program\apache-continuum\data\working-directory\15\dennislundberg-beansprout\target\appassembler\lib\commons-dbutils-1.1.jar
> {noformat}
> Example in beta 3:
> {noformat}
> [INFO] Installing C:\Documents and
> Settings\dlg01\.m2\repository\commons-dbutils\commons-dbutils\1.1\commons-dbutils-1.1.jar
> to
> C:\Program\apache-continuum\data\working-directory\15\dennislundberg-beansprout\target\appassembler\lib\commons-dbutils\commons-dbutils\1.1\commons-dbutils-1.1.jar
> {noformat}
> The result is that the assembled apps gets an invalid classpath and won't
> start.
> Test case coming soon.
--
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: (SUREFIRE-542) JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
[
http://jira.codehaus.org/browse/SUREFIRE-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Birkner updated SUREFIRE-542:
Attachment: SUREFIRE-542.patch
This bug fix adds the method testAssumptionFailure to the JUnit4TestSetReporter
> JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
> -
>
> Key: SUREFIRE-542
> URL: http://jira.codehaus.org/browse/SUREFIRE-542
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.4.3
> Environment: 64 bit Ubuntu 8.10, OpenJDK 6
>Reporter: Karl M. Davis
>Priority: Minor
> Attachments: SUREFIRE-542.patch
>
>
> Junit 4.4 has support for ignoring tests at runtime via code like the
> following:
> {{Assume.assumeTrue(testsShouldBeRun());}}
> When running tests under Surefire that fail their assumptions, the tests are
> reported as successful-- not ignored as they ought to be. The javadoc for
> the Assume class is here: [http://junit.org/apidocs/org/junit/Assume.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] Commented: (MNG-4602) Allow pluggable authentication (using JAAS ?) so that the username and password to connect to a deployment repository can be generated by a Single Sign On-enabled client
[ http://jira.codehaus.org/browse/MNG-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235018#action_235018 ] David Boden commented on MNG-4602: -- I've done some investigation. The relevant class is in the artifact manager project and is called WagonManager. The DefaultWagonManager implementation is injected by Plexus. The WagonManager interface contains definitions for methods that I want to modify the implementation of: * addConfiguration(String repositoryId, Xpp3Dom configuration) - Change to detect a com.custom.login.CustomLoginContext tag under the definition, put there instead of username and password. The classname in the tag would implement javax.security.auth.login.LoginContext. In the case of single sign on, I can make the addConfiguration method log the user in using the LoginContext and then call the following method with the username and password: * addAuthenticationInfo(String repositoryId, String username, String password, String privateKey, String passphrase) The addAuthenicationInfo and the getAuthenticationInfo methods can probably remain as they are. So, I'm now trying to weigh up what's involved in replacing the injection of DefaultWagonManager with a subclass; SingleSignOnWagonManager. Judging by the fact that plexus.xml is already present in the MAVEN_HOME/lib/maven-2.2.1-uber.jar under META-INF/plexus and you can only have one plexus.xml I don't think it's going to be possible to customise Maven 2.2.1. Instead, it looks like I'm going to have to do a checkout of the whole Maven project, make my changes then rebuild Maven 2.2.1.x. If I'm forced to go along this route, I'll submit a patch to DefaultWagonManager rather than creating a subclass. > Allow pluggable authentication (using JAAS ?) so that the username and > password to connect to a deployment repository can be generated by a Single > Sign On-enabled client > - > > Key: MNG-4602 > URL: http://jira.codehaus.org/browse/MNG-4602 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories, Settings >Reporter: David Boden >Priority: Minor > > The username and password used to authenticate with the remote repository > during deployment are stored in the user's settings.xml under the > structure. This structure allows a username and password to be specified, or > for a .ssh private key to be specified. > It does not allow for pluggable single sign on, where a Java module (perhaps > a JAAS LoginModule) is available on the client to generate a token in place > of a password. Many corporates use this technique for other web applications, > generating an LDAP token from the user's PC and verifying it against an LDAP > server on the server side. It adds security by removing the need to pass the > user's password over the wire. > This Jira is a request for a pluggable entry point for this single sign on > module, perhaps by specifying a class name in the structure or by > setting a system property. The solution could either define a new interface > which Authentication Providers must implement or can use existing interfaces > from JAAS, (Http) Authenticator or other frameworks. > Please feel free to move this item to the "Maven Wagon" component if you feel > that's the best place to implement the feature. Alternatively, please also > feel free to move to the generic "Maven 2&3" component if you think that the > feature has wider scope than just deployment; perhaps to also authenticate > using Single Sign On with an internal company's repository when *downloading* > artifacts (as well as uploading). -- 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-275) Figuring out duplicate class definitions using the Analyze goal
[ http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235022#action_235022 ] Brian Fox commented on MDEP-275: Raymond: Any chance you can write some unit/it tests for this new code? Currently it has none, and if you look at the mdep plugin, it is currently very thoroughly tested. > Figuring out duplicate class definitions using the Analyze goal > --- > > Key: MDEP-275 > URL: http://jira.codehaus.org/browse/MDEP-275 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.1 >Reporter: Petter Måhlén >Assignee: Brian Fox > Attachments: dependency-analyzer.diff, dependency-plugin.diff > > > Hi, > I've pretty frequently run into issues where changes to the library structure > of some product (that is, changing the way that classes are grouped into > libraries) leads to the same classes being defined in more than one place. > This can lead to system-dependent problems, because different versions of the > same class are being loaded by different systems. > I was going to create a new goal for the dependency plugin to check for > duplicate classes, but when I looked a bit closer at the analyze goal, it > already had all the information needed to do that check as well, so I came up > with some changes that add this functionality. > The intended usage is something like: > mvn dependency:analyze -DcheckDuplicateClasses > I get the feeling that I might want to add the ability to exclude certain > packages (that I might be comfortable are safe to have duplicates of), so I > added this option too: > mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes="org., > net.sf.cglib, javax.xml, junit." > The output looks something like: > [WARNING] Duplicate class definitions found: > [WARNING]com.shopzilla.common.data.ObjectFactory defined in: > [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile > [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile > [WARNING]com.shopzilla.site.category.CategoryProvider defined in: > [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile > [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile > A couple of notes: > - I was unable to get configuration (setting checkDuplicateClasses, etc.) > using the pom to work, but I think that might be due to lack of understanding > on my part. > - I don't fully understand the effect of calling compileProject() during unit > tests, but I think it may be sufficient to call it only once for the > duplicateClasses project, during setUp(). That would speed up the unit tests. > - I haven't added duplicate class definition checking to the > AnalyzeReportMojo, because I wanted to get some feedback on whether this > addition was felt to be valuable before spending any time on that. > - A lot of the unit test dummy code in the attached diff files needs cleaning > up, but again I wanted to wait with that until hearing whether this might be > useful to others. > - I made an API change in the ProjectDependencyAnalyzer interface, which > might be an issue if there are other implementations than the default one. > That change was only needed to support the 'exclude package' feature, which > might not be super-important. > Cheers, > Petter -- 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-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235023#action_235023
]
Brian Fox commented on MDEP-259:
Andreas, can you provide some tests for your patch?
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: http://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
>Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> [INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory)
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
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-124) Dependency incorrectly reported as "Unused declared"
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235024#action_235024
]
Brian Fox commented on MDEP-124:
The analyzer walks all classes and collects the list of imports essentially and
then tries to mark dependencies when it finds an imported class in that
dependency. There is no processing of the annotations or constants in the
analyzer since it's looking purely at the bytecode. The best we can do here is
allow you to annotate the configuration with a list of artifacts that should be
ignored.
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: http://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
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-124) Dependency incorrectly reported as "Unused declared"
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-124:
---
Fix Version/s: 2.2
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: http://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
> Fix For: 2.2
>
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
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-166) runtime-scoped dependencies should be specially handled
[ http://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-166: --- Fix Version/s: 2.2 > runtime-scoped dependencies should be specially handled > --- > > Key: MDEP-166 > URL: http://jira.codehaus.org/browse/MDEP-166 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: Max Bowsher >Assignee: Brian Fox > Fix For: 2.2 > > > Currently the plugin warns that runtime-scope dependencies are unused. > It should understand that the correct status for a runtime-scoped dependency > is to *not* be discoverable in the bytecode. -- 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-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-265: --- Fix Version/s: 2.2 > Add classifier option for dependency:get > > > Key: MDEP-265 > URL: http://jira.codehaus.org/browse/MDEP-265 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Andreas Kohn >Assignee: Brian Fox > Fix For: 2.2 > > Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff > > > The dependency:get mojo is really helpful, but it currently seems to be > unable to get an artifact that uses a non-default classifier. > Please add a classifier configuration option for the get mojo. -- 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-286) Use System.getProperty("line.separator") for line ending terminators of generated source files
[
http://jira.codehaus.org/browse/ARCHETYPE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-286:
Fix Version/s: 2.0
Issue Type: Improvement (was: Bug)
> Use System.getProperty("line.separator") for line ending terminators of
> generated source files
> --
>
> Key: ARCHETYPE-286
> URL: http://jira.codehaus.org/browse/ARCHETYPE-286
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 2.0-alpha-4
> Environment: WindowsXP Prof 2002 SP2, JDK 1.6.0_17, Maven 2.2.1
>Reporter: Harold Shinsato
>Priority: Minor
> Fix For: 2.0
>
>
> It would be nice if it weren't necessary to translate the line endings when
> we're not on a unix/linux system.
--
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: (MSITE-486) Site navigation not generated for submodules of multimodule project when site.xml defined in the parent
[
http://jira.codehaus.org/browse/MSITE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235039#action_235039
]
Thomas Scheffler commented on MSITE-486:
The workaround described by André
{quote}
Adding an _inherit_ attribute will do it (for 2.1.1).
{{}}
{quote}
does *not* work for me with 2.1.1.
It is definitely not an option to provide a site.xml to every child pom just to
define a skin for every subproject, as it works find with 2.0.1
> Site navigation not generated for submodules of multimodule project when
> site.xml defined in the parent
> ---
>
> Key: MSITE-486
> URL: http://jira.codehaus.org/browse/MSITE-486
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.1.1
> Environment: Windows XP SP2, Sun/Oracle JDK 1.6, Maven 2.2.1
>Reporter: Grzegorz Slowikowski
> Attachments: MSITE-486.zip
>
>
> Bug that manifests itself like http://jira.codehaus.org/browse/MSITE-456 but
> in different configuration.
> If you define "src/site/site.xml" file for the root module the navigation
> left menu in submodule is completely empty. After deleting this "site.xml"
> file everything works (maybe something has recently changed in this file
> content/structure requirements).
> Everything works without problems for 2.0.1 version of Maven site 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
