[jira] Closed: (MNG-3833) POM interpolation fails to fully interpolate chain of dependent properties
[
http://jira.codehaus.org/browse/MNG-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-3833.
-
Assignee: Shane Isbell
Resolution: Fixed
Fix Version/s: 3.0-alpha-1
New implementation does multiple interpolation iterations, until it detects
that there is no longer a change in the list.
> POM interpolation fails to fully interpolate chain of dependent properties
> --
>
> Key: MNG-3833
> URL: http://jira.codehaus.org/browse/MNG-3833
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-1
>
>
> For instance, for this POM snippet, only eight properties will be fully
> interpolated to "PASSED", the others remain at some intermediate expressions:
> {code:xml}
>
> ${property18}
> ${property16}
> ${property14}
> ${property12}
> ${property10}
> ${property08}
> ${property06}
> ${property04}
> ${property02}
> ${property00}
> PASSED
> ${property01}
> ${property03}
> ${property05}
> ${property09}
> ${property11}
> ${property07}
> ${property13}
> ${property15}
> ${property17}
>
> {code}
> i.e. {{help:effective-pom}} delivers
> {code:xml}
>
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> ${property01}
> ${property01}
> ${property03}
> ${property03}
> ${property05}
> ${property05}
> ${property07}
> ${property07}
> ${property09}
> ${property09}
> ${property11}
>
> {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-1977) Global dependency exclusions
[ http://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153862#action_153862 ] Holger Hoffstätte commented on MNG-1977: This just became a total showstopper with SpringSource effectively cloning the entire maven dependency set in their "enterprise" repo. :-( I know that's not maven's fault, but both global exclusions (e.g. as protections again known bad poms) and aliasing (to always substitute slf4j for clogging) would really fix a lot of problems that this has caused. > Global dependency exclusions > > > Key: MNG-1977 > URL: http://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.0 > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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-3818) Unable to download the artifact from any repository
[ http://jira.codehaus.org/browse/MNG-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3818. -- Assignee: Benjamin Bentmann Resolution: Not A Bug Please use the [Maven User List|http://maven.apache.org/mail-lists.html] for questions about configuring Maven. > Unable to download the artifact from any repository > --- > > Key: MNG-3818 > URL: http://jira.codehaus.org/browse/MNG-3818 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.9 > Environment: Windows XP >Reporter: Prince >Assignee: Benjamin Bentmann > > Hello All, > I get the following error when I run "C:\Documents and Settings\sowrinai>mvn > clean install" > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [clean, install] > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.pom > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.plugins > ArtifactId: maven-clean-plugin > Version: 2.2 > Reason: Unable to download the artifact from any repository > org.apache.maven.plugins:maven-clean-plugin:pom:2.2 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Nov 05 11:08:47 GMT+05:30 2008 > [INFO] Final Memory: 1M/2M > [INFO] > > I am not able to configure Maven properly on my machine. Any expert who can > help me in successfully configuring maven. > Thanks for your time. -- 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: (MNG-3503) Shade MX* classes from plexus-utils
[
http://jira.codehaus.org/browse/MNG-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3503:
---
Fix Version/s: 3.0-alpha-1
> Shade MX* classes from plexus-utils
> ---
>
> Key: MNG-3503
> URL: http://jira.codehaus.org/browse/MNG-3503
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 2.0.10, 2.1.0-M2, 3.0-alpha-1
>
> Attachments: shade-mx-classes-addon.patch, shade-mx-classes.patch
>
>
> The Maven uber JAR currently ships with unshaded {{MXParser}} and
> {{MXSerializer}}, preventing plugins from using their recent implementations
> from plexus-utils. My initial question on the [dev
> list|http://www.nabble.com/Shade-MX*-classes-from-plexus-utils--tc16080800s177.html]
> showed now immediate objections and the core ITs also smile so here we go
> with the proposed patch.
--
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: (MNG-3834) Improve error message when dependency with classifier is missing version
[
http://jira.codehaus.org/browse/MNG-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MNG-3834:
---
Attachment: MNG-3834-maven-project.patch
Attaching patch that uses the dependencyManagementKey
(groupId:artifactId:type:classifier), instead of just the artifactId and
groupId in the error message.
> Improve error message when dependency with classifier is missing version
>
>
> Key: MNG-3834
> URL: http://jira.codehaus.org/browse/MNG-3834
> Project: Maven 2
> Issue Type: Improvement
> Components: Errors
>Reporter: Paul Gier
> Attachments: MNG-3834-maven-project.patch, pom.xml
>
>
> Currently, if I have two dependencies on the same groupId:artifactId, one
> with a classifier and one without, the missing version error message does not
> distinguish which dependency is missing a version. For example, the
> following pom is missing a version number for one of the dependencies.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> org.apache.maven
> missing-version-error
> jar
> Missing version error
> 1.0.0-SNAPSHOT
>
>
>
> org.apache.maven
> myartifact1
> 1.0-SNAPSHOT
>
>
> org.apache.maven
> myartifact1
> test
>
>
>
> {code}
> The error message prints the following:
> {code}
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> org.apache.maven:myartifact1
> {code}
> The error message should include information about the dependency's
> classifier.
--
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-3834) Improve error message when dependency with classifier is missing version
[
http://jira.codehaus.org/browse/MNG-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153854#action_153854
]
pgier edited comment on MNG-3834 at 11/11/08 3:55 PM:
--
Attaching patch for 2.0.x that uses the dependencyManagementKey
(groupId:artifactId:type:classifier), instead of just the artifactId and
groupId in the error message.
The new error message looks like this:
{code}
Validation Messages:
[0] 'dependencies.dependency.version' is missing for
org.apache.maven:myartifact1:jar:test
{code}
was (Author: pgier):
Attaching patch for 2.0.x that uses the dependencyManagementKey
(groupId:artifactId:type:classifier), instead of just the artifactId and
groupId in the error message.
> Improve error message when dependency with classifier is missing version
>
>
> Key: MNG-3834
> URL: http://jira.codehaus.org/browse/MNG-3834
> Project: Maven 2
> Issue Type: Improvement
> Components: Errors
>Reporter: Paul Gier
> Attachments: MNG-3834-maven-project.patch, pom.xml
>
>
> Currently, if I have two dependencies on the same groupId:artifactId, one
> with a classifier and one without, the missing version error message does not
> distinguish which dependency is missing a version. For example, the
> following pom is missing a version number for one of the dependencies.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> org.apache.maven
> missing-version-error
> jar
> Missing version error
> 1.0.0-SNAPSHOT
>
>
>
> org.apache.maven
> myartifact1
> 1.0-SNAPSHOT
>
>
> org.apache.maven
> myartifact1
> test
>
>
>
> {code}
> The error message prints the following:
> {code}
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> org.apache.maven:myartifact1
> {code}
> The error message should include information about the dependency's
> classifier.
--
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-3834) Improve error message when dependency with classifier is missing version
[
http://jira.codehaus.org/browse/MNG-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153854#action_153854
]
pgier edited comment on MNG-3834 at 11/11/08 3:54 PM:
--
Attaching patch for 2.0.x that uses the dependencyManagementKey
(groupId:artifactId:type:classifier), instead of just the artifactId and
groupId in the error message.
was (Author: pgier):
Attaching patch that uses the dependencyManagementKey
(groupId:artifactId:type:classifier), instead of just the artifactId and
groupId in the error message.
> Improve error message when dependency with classifier is missing version
>
>
> Key: MNG-3834
> URL: http://jira.codehaus.org/browse/MNG-3834
> Project: Maven 2
> Issue Type: Improvement
> Components: Errors
>Reporter: Paul Gier
> Attachments: MNG-3834-maven-project.patch, pom.xml
>
>
> Currently, if I have two dependencies on the same groupId:artifactId, one
> with a classifier and one without, the missing version error message does not
> distinguish which dependency is missing a version. For example, the
> following pom is missing a version number for one of the dependencies.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> org.apache.maven
> missing-version-error
> jar
> Missing version error
> 1.0.0-SNAPSHOT
>
>
>
> org.apache.maven
> myartifact1
> 1.0-SNAPSHOT
>
>
> org.apache.maven
> myartifact1
> test
>
>
>
> {code}
> The error message prints the following:
> {code}
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> org.apache.maven:myartifact1
> {code}
> The error message should include information about the dependency's
> classifier.
--
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-3834) Improve error message when dependency with classifier is missing version
Improve error message when dependency with classifier is missing version
Key: MNG-3834
URL: http://jira.codehaus.org/browse/MNG-3834
Project: Maven 2
Issue Type: Improvement
Components: Errors
Reporter: Paul Gier
Attachments: pom.xml
Currently, if I have two dependencies on the same groupId:artifactId, one with
a classifier and one without, the missing version error message does not
distinguish which dependency is missing a version. For example, the following
pom is missing a version number for one of the dependencies.
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
org.apache.maven
missing-version-error
jar
Missing version error
1.0.0-SNAPSHOT
org.apache.maven
myartifact1
1.0-SNAPSHOT
org.apache.maven
myartifact1
test
{code}
The error message prints the following:
{code}
Validation Messages:
[0] 'dependencies.dependency.version' is missing for
org.apache.maven:myartifact1
{code}
The error message should include information about the dependency's classifier.
--
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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153844#action_153844 ] Gin-Ting Chen commented on MNG-3139: Please reopen this. This should be an easy fix on the plugin. Sry I haven't been involved enough since Maven 2 beta days to do this myself as a patch. When I find a free second I'll be more than willing to submit one myself but it doesn't even sound like from Brett's comments that one is necessary. > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: Brett Porter > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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-3833) POM interpolation fails to fully interpolate chain of dependent properties
POM interpolation fails to fully interpolate chain of dependent properties
--
Key: MNG-3833
URL: http://jira.codehaus.org/browse/MNG-3833
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
For instance, for this POM snippet, only eight properties will be fully
interpolated to "PASSED", the others remain at some intermediate expressions:
{code:xml}
${property18}
${property16}
${property14}
${property12}
${property10}
${property08}
${property06}
${property04}
${property02}
${property00}
PASSED
${property01}
${property03}
${property05}
${property09}
${property11}
${property07}
${property13}
${property15}
${property17}
{code}
i.e. {{help:effective-pom}} delivers
{code:xml}
PASSED
PASSED
PASSED
PASSED
PASSED
PASSED
PASSED
PASSED
PASSED
${property01}
${property01}
${property03}
${property03}
${property05}
${property05}
${property07}
${property07}
${property09}
${property09}
${property11}
{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: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3259: -- Fix Version/s: 2.0.9 > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153836#action_153836
]
Kalle Korhonen commented on SCM-406:
Upgrading to svn 1.5.4 fixes the issue
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3259: -- Affects Version/s: 2.0.7 2.0.8 Fix Version/s: (was: 2.0.9) > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Blocker > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- 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: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3259: -- Affects Version/s: (was: 2.0.8) (was: 2.0.7) 3.0-alpha-1 > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- 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: (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-tabpanel&focusedCommentId=153826#action_153826 ] Frederic commented on ARCHETYPE-191: I discovered that it works fine with command line. But it does not work when I try it using maven integration plugin for eclipse. I have open a ticket on their side: http://jira.codehaus.org/browse/MNGECLIPSE-1054 > 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 > > > 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] Created: (MSHADE-43) spring.schemas and spring.handlers support
spring.schemas and spring.handlers support -- Key: MSHADE-43 URL: http://jira.codehaus.org/browse/MSHADE-43 Project: Maven 2.x Shade Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Erik Post Attachments: maven-shade-plugin-spring-support.patch The attached patch adds support for merging the spring.schemas and spring.handlers files when shading a project that has multiple spring dependencies. The spring.schemas and spring.handlers files contain configuration data that is used by the Spring Framework when parsing context configuration XML files. The patch adds two resource transformers (SpringHandlersResourceTransformer and SpringSchemasResourceTransformer) that merge the contents of all encountered spring.handlers and spring.schemas files, and puts the merged files in the shaded jar. I based the code on the ComponentXmlResourceTransfomer. Unit tests are included. -- 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-3443) boolean values in the POM specified as expressions are not interpolated, result in value == false
[ http://jira.codehaus.org/browse/MNG-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153819#action_153819 ] Benjamin Bentmann commented on MNG-3443: This duplicates MNG-1995 (its IT has been enriched with the test proposed here, just in case). > boolean values in the POM specified as expressions are not interpolated, > result in value == false > - > > Key: MNG-3443 > URL: http://jira.codehaus.org/browse/MNG-3443 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.8, 2.0.9, 3.0-alpha-1 >Reporter: John Casey > Fix For: 2.0.x > > Attachments: interpolate-boolean-expression.zip > > > The problem is the ModelReader generated by Modello uses something akin to > Boolean.valueOf( element.getValue() ) to set boolean model values. If the > value in XML is actually an expression, it is resolved to false and never > interpolated. > To correct this, we should consider revising Modelllo's generated reader > architecture to use a two-stage approach: > 1. Construct a raw structure of String: String and String: Collection > associations (basically something like a perlish hash, IIRC) > 2. Pass an arbitrary number of transformers over the raw structure to > interpolate it (this includes path translation, etc. and should include a > notion of transformation context to allow transformations to collaborate) > 3. Construct the Model instance based on the transformed raw structure. > This will incur a little extra transient overhead for model construction, but > its effects should be mitigated through the caching strategies we employ for > models and projects. -- 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-3831) Expressions without project/pom prefix are no longer interpolated with model values
[
http://jira.codehaus.org/browse/MNG-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3831.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-1
Fixed in [r713052|http://svn.eu.apache.org/viewvc?view=rev&revision=713052].
> Expressions without project/pom prefix are no longer interpolated with model
> values
> ---
>
> Key: MNG-3831
> URL: http://jira.codehaus.org/browse/MNG-3831
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-1
>
>
> Maven 2.x interpolates an expression like {{${name}}} to the value of
> {{${project.name}}}. While this aliasing is a questionable design, it was
> opted to retain it in Maven 3.x (c.f. [commit comment on
> r704423|http://www.nabble.com/RE%3A-svn-commit%3A-r704423maven-components-trunk-maven-project-src-main-java-org-apache-maven-project-builder-PomClassicTransformer.java-p19975207.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] Created: (MNG-3832) Allow wildcards in dependency exclusions
Allow wildcards in dependency exclusions
Key: MNG-3832
URL: http://jira.codehaus.org/browse/MNG-3832
Project: Maven 2
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
I would like to be able to exclude all transitive dependencies from a certain
dependencies. This is especially useful when depending on an artifact with a
classifier that may not have the same dependencies as the main artifact.
Currently the only way to do this is by excluding each dependency individually
which requires significant effort and is prone to becoming out of date. The
following syntax is one possibility.
Exclude all transitive dependencies
{code}
*
{code}
Exclude transitive dependencies with the groupId "org.company"
{code}
org.company
*
{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] Created: (MNG-3831) Expressions without project/pom prefix are no longer interpolated with model values
Expressions without project/pom prefix are no longer interpolated with model
values
---
Key: MNG-3831
URL: http://jira.codehaus.org/browse/MNG-3831
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Maven 2.x interpolates an expression like {{${name}}} to the value of
{{${project.name}}}. While this aliasing is a questionable design, it was opted
to retain it in Maven 3.x (c.f. [commit comment on
r704423|http://www.nabble.com/RE%3A-svn-commit%3A-r704423maven-components-trunk-maven-project-src-main-java-org-apache-maven-project-builder-PomClassicTransformer.java-p19975207.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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153813#action_153813
]
Matthias Weßendorf commented on SCM-406:
for the problem above I had to do this:
http://svn.apache.org/viewvc?view=rev&revision=713040
now a "mvn release:prepare -DprepareRelease=true -Dresume" does the trick:
However, still some clean ups, to be consistent:
http://svn.apache.org/viewvc?view=rev&revision=713043
http://svn.apache.org/viewvc?view=rev&revision=713044
:-)
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153812#action_153812
]
Matthias Weßendorf commented on SCM-406:
even wores, if your trunk is not named trunk... (b/c it is sometimes that case
to have two trunks (to work on different "JSR specs")) but "trunk12_x"
Anyway, so I run the plugin like :
mvn release:prepare -DprepareRelease=true -Dresume
-Dtag=http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.10
now... I get this:
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Server sent unexpected return value (403 Forbidden) in response to
MKACTIVITY request for
'/repos/asf/!svn/act/32a097b1-8097-af46-a3c1-55150b6042bd'
[INFO]
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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-3281) Revisit backwards compat of extensions (IT 0114)
[ http://jira.codehaus.org/browse/MNG-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153795#action_153795 ] Benjamin Bentmann commented on MNG-3281: Just to avoid suprises: it0114 has been renamed to match its corresonding issue MNG-2749. > Revisit backwards compat of extensions (IT 0114) > > > Key: MNG-3281 > URL: http://jira.codehaus.org/browse/MNG-3281 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Brett Porter > Fix For: 3.0-alpha-2 > > > currently, it 0114 doesn't pass due to the removal of extension support > we need to either: > - restore some form of backwards compat by loading the extension into the > expected place > - provide a graceful failure 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: (MAVENUPLOAD-2268) Upload Barcode4J 2.0
Upload Barcode4J 2.0 Key: MAVENUPLOAD-2268 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2268 Project: Maven Upload Requests Issue Type: Task Reporter: Joerg Schaible http://www.people.apache.org/~joehni/barcode4j-fop-ext-2.0-bundle.jar http://www.people.apache.org/~joehni/barcode4j-fop-ext-complete-2.0-bundle.jar http://www.people.apache.org/~joehni/barcode4j-fop-ext-0.20.5-2.0-bundle.jar http://www.people.apache.org/~joehni/barcode4j-fop-ext-0.20.5-complete-2.0-bundle.jar http://www.people.apache.org/~joehni/barcode4j-light-2.0-bundle.jar Note, there are already org.krysalis:barcode*:1.0beta1 artifacts. However, those artifacts originate from the officially closed SF project http://krysalis.sourceforge.net/ and the project has been moved to the SF project barcode4j. Therefore the groupId in the new bundles is net.sf.barcode4j. Regards, Jörg -- 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: (MANTRUN-98) multiple input tasks leads to exception
[
http://jira.codehaus.org/browse/MANTRUN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153789#action_153789
]
Martin Buechler commented on MANTRUN-98:
mvn <=2.0.8: the behavior reported here, seems to be mvn <=2.0.8 specific,. at
least in my environment:
Maven version: 2.0.7
Java version: 1.5.0_15
OS name: "linux" version: "2.6.24-21-generic" arch: "i386"
With mvn 2.0.9 I cannot reproduce the bug reported here.
P.S.: we have to switch now between mvn versions, depending on what ant tasks
we use. This is getting ridiculous...
> multiple input tasks leads to exception
> ---
>
> Key: MANTRUN-98
> URL: http://jira.codehaus.org/browse/MANTRUN-98
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: 32-bit Linux, Sun JDK 1.6.0_07, Maven 2.0.9
>Reporter: Andy Schlaikjer
>
> Running more than one task within Antrun plugin causes exception:
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> Please enter test-value-01 [123]
> Please enter test-value-02 [456]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An Ant BuildException has occured: Failed to read input from Console.
> Stream closed
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException
> has occured: Failed to read input from Console.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant
> BuildException has occured: Failed to read input from Console.
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 16 more
> Caused by: Failed to read input from Console.
> at
> org.apache.tools.ant.input.DefaultInputHandler.handleInput(DefaultInputHandler.java:59)
> at org.apache.tools.ant.taskdefs.Input.execute(Input.java:231)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
> ... 19 more
> Caused by: java.io.IOException: Stream closed
> at
> java.io.BufferedInputStream.getBufIfOpen(Buffe
[jira] Updated: (MNG-3826) Add profile activation when project version matches a regex
[ http://jira.codehaus.org/browse/MNG-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MNG-3826: - Summary: Add profile activation when project version matches a regex (was: Add profile's activation when artifact version is not snapshot) Updated issue from just matching snapshot versions to matching a regex on the version. This would allow profiles to be activated for different stages of a project's iteration, e.g. major, minor, bug fix, etc. Very handy for running clirr against a project when API changes are not allowed, for example. > Add profile activation when project version matches a regex > --- > > Key: MNG-3826 > URL: http://jira.codehaus.org/browse/MNG-3826 > Project: Maven 2 > Issue Type: New Feature > Components: Profiles >Affects Versions: 2.0.9 >Reporter: Dan Tran > > Here is the related discussion > by Dan Tran Nov 06, 2008; 01:07pm :: Rate this Message: - Use ratings to > moderate (?) > Activate a profile when project.version is not SNAPSHOT > is it possible? > -D > by Stephen Connolly-2 Nov 06, 2008; 01:35pm :: Rate this Message: - Use > ratings to moderate (?) > AFAIK, No... the core does not support it and plugins cannot activate > profiles as the active profiles have been decided before the validate phase > by Dan Tran Nov 06, 2008; 01:39pm :: Rate this Message: - Use ratings to > moderate (?) > sounds like a new feature to request for maven-profile component > by mihobson Nov 07, 2008; 01:26am :: Rate this Message: - Use ratings to > moderate (?) > I've been wanting this for a while but figured it'd be solved by > custom profile activators, currently sitting in trunk: > http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators > Perhaps a new snapshot profile activator would be best for the > short-term. Have you raised an issue I could watch? > Cheers, > Mark -- 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: (MRELEASE-381) url syntax not good enough for the git scm provider
[
http://jira.codehaus.org/browse/MRELEASE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153771#action_153771
]
olamy edited comment on MRELEASE-381 at 11/11/08 3:18 AM:
-
Fixed with scm changes and upgrade to scm 1.1.1.
Tested with the very famous project :
http://github.com/olamy/scm-git-test-one-module/.
Torsten can you test it too ? (All necessary SNAPSHOTS deployed)
Thanks.
was (Author: olamy):
Fixed with scm changes and upgrade to scm 1.1.1.
Tested with the very famous project :
http://github.com/olamy/scm-git-test-one-module/.
Torsten can you test it too ?
Thanks.
> url syntax not good enough for the git scm provider
> ---
>
> Key: MRELEASE-381
> URL: http://jira.codehaus.org/browse/MRELEASE-381
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Torsten Curdt
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.0-beta-9
>
>
> The problem is that git supports 2 different URL schemes. For the normal RFC
> 2396 standard and ssh style. So in theory all these styles should work:
> normal anonymous absolute:
> {code}git clone git://github.com/olamy/scm-git-test-one-module.git{code}
> normal anonymous relative:
> {code}git clone git://github.com:olamy/scm-git-test-one-module.git{code}
> normal developer absolute:
> {code}git clone ssh://[EMAIL
> PROTECTED]/olamy/scm-git-test-one-module.git{code}
> normal developer relative:
> {code}git clone ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module{code}
> ssh developer absolute:
> {code}git clone [EMAIL PROTECTED]/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> {code}git clone [EMAIL PROTECTED]:olamy/scm-git-test-one-module{code}
> In reality the ssh:// URL is not always supported. (For example github does
> not). In fact they suggest to use
> normal anonymous absolute:
> {code}git://github.com/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> [EMAIL PROTECTED]:olamy/scm-git-test-one-module.git{code}
> For the initial checkout the developer will use the command line and set
> "[EMAIL PROTECTED]:olamy/scm-git-test-one-module.git" as the remote address.
> So subsequent commits and tags (from the plugin) can work just fine as the
> URL does not need to be specified anymore. But when the release plugin checks
> out the code it will fail if the proper developer url "ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module" (normal developer relative) is
> set. (As the maven pom seems to expect that format).
> There are 3 ways to fix or work around this:
> 1) Use the normal anonymous URLs for both connections (developer and
> anonymous) inside the pom. This will confused developers though as the
> generated site tells the new developers to use the anonymous URL to checkout
> the code. They will not be able to push if they do.
> 2) Have the scm/release plugin ignore the developer URL and use the anonymous
> URL for the checkout. Again this will be confusing on the generated site as
> the normal developer rel/abs URLs might not be supported.
> 3) Somehow store the URL in the format "[EMAIL
> PROTECTED]:olamy/scm-git-test-one-module" in the pom. The problem is that the
> POM expects the normal (RFC 2396) format AFAIU.
--
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: (MCHECKSTYLE-107) Possibility to check classes, chosen with datetime filter
Possibility to check classes, chosen with datetime filter - Key: MCHECKSTYLE-107 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-107 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Reporter: Sergey Petrovskiy The goal is to check not all classes of project, but only last commited. If I start checkstyle with ant, I can define datetime: I could not find this possibility for maven pmd plugin. BTW: the same possibility required in PMD 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
[jira] Created: (MPMD-90) Possibility to check classes, chosen with datetime filter
Possibility to check classes, chosen with datetime filter - Key: MPMD-90 URL: http://jira.codehaus.org/browse/MPMD-90 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: PMD Reporter: Sergey Petrovskiy The goal is to check not all classes of project, but only last commited. If I start pmd with ant, I can define datetime: rulesets/basic.xml rulesets/unusedcode.xml rulesets/codesize.xml rulesets/imports.xml I could not find this possibility for maven pmd plugin. BTW: the same possibility required in checkstyle 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
[jira] Commented: (MRELEASE-381) url syntax not good enough for the git scm provider
[
http://jira.codehaus.org/browse/MRELEASE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153771#action_153771
]
Olivier Lamy commented on MRELEASE-381:
---
Fixed with scm changes and upgrade to scm 1.1.1.
Tested with the very famous project :
http://github.com/olamy/scm-git-test-one-module/.
Torsten can you test it too ?
Thanks.
> url syntax not good enough for the git scm provider
> ---
>
> Key: MRELEASE-381
> URL: http://jira.codehaus.org/browse/MRELEASE-381
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Torsten Curdt
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.0-beta-9
>
>
> The problem is that git supports 2 different URL schemes. For the normal RFC
> 2396 standard and ssh style. So in theory all these styles should work:
> normal anonymous absolute:
> {code}git clone git://github.com/olamy/scm-git-test-one-module.git{code}
> normal anonymous relative:
> {code}git clone git://github.com:olamy/scm-git-test-one-module.git{code}
> normal developer absolute:
> {code}git clone ssh://[EMAIL
> PROTECTED]/olamy/scm-git-test-one-module.git{code}
> normal developer relative:
> {code}git clone ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module{code}
> ssh developer absolute:
> {code}git clone [EMAIL PROTECTED]/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> {code}git clone [EMAIL PROTECTED]:olamy/scm-git-test-one-module{code}
> In reality the ssh:// URL is not always supported. (For example github does
> not). In fact they suggest to use
> normal anonymous absolute:
> {code}git://github.com/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> [EMAIL PROTECTED]:olamy/scm-git-test-one-module.git{code}
> For the initial checkout the developer will use the command line and set
> "[EMAIL PROTECTED]:olamy/scm-git-test-one-module.git" as the remote address.
> So subsequent commits and tags (from the plugin) can work just fine as the
> URL does not need to be specified anymore. But when the release plugin checks
> out the code it will fail if the proper developer url "ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module" (normal developer relative) is
> set. (As the maven pom seems to expect that format).
> There are 3 ways to fix or work around this:
> 1) Use the normal anonymous URLs for both connections (developer and
> anonymous) inside the pom. This will confused developers though as the
> generated site tells the new developers to use the anonymous URL to checkout
> the code. They will not be able to push if they do.
> 2) Have the scm/release plugin ignore the developer URL and use the anonymous
> URL for the checkout. Again this will be confusing on the generated site as
> the normal developer rel/abs URLs might not be supported.
> 3) Somehow store the URL in the format "[EMAIL
> PROTECTED]:olamy/scm-git-test-one-module" in the pom. The problem is that the
> POM expects the normal (RFC 2396) format AFAIU.
--
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
