[jira] Closed: (ARCHETYPE-157) Ability to generate empty directories
[ http://jira.codehaus.org/browse/ARCHETYPE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed ARCHETYPE-157. - Assignee: Wendy Smoak Resolution: Duplicate Duplicate of ARCHETYPE-57 > Ability to generate empty directories > - > > Key: ARCHETYPE-157 > URL: http://jira.codehaus.org/browse/ARCHETYPE-157 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes > Environment: All Operating systems >Reporter: nambi sankaran >Assignee: Wendy Smoak > > In my archetype, I would like to generate an empty directory that macthes > with the package the user supplied > The current version does not create the directory, if it is empty. > As a workaround, I have added an empty file named ".file" to generate a > directory with the package name. -- 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: (MAVENUPLOAD-2021) DataCleaner-core 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134297#action_134297 ] Kasper Sørensen commented on MAVENUPLOAD-2021: -- OK, New JAR located at: http://www.eobjects.dk/datacleaner/DataCleaner-core-1.0-bundle.jar > DataCleaner-core 1.0 > > > Key: MAVENUPLOAD-2021 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2021 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Kasper Sørensen > > I'm the founder and main developer of DataCleaner. Please upload > PS: The website will be down a couple of hours for maintenance tomorrow, so > if you're unlucky try a bit later. -- 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: (MDEPLOY-28) Deployment should delete remote files and create new ones instead of modifying them
[ http://jira.codehaus.org/browse/MDEPLOY-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MDEPLOY-28: --- Fix Version/s: (was: 2.4) > Deployment should delete remote files and create new ones instead of > modifying them > --- > > Key: MDEPLOY-28 > URL: http://jira.codehaus.org/browse/MDEPLOY-28 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Carlos Sanchez >Priority: Critical > > Remote files usually are non group writable while the directory is to prevent > changes in the files without knowing who changed it (eg. apache repository > policy) > So deployment should delete metadata files and create new ones instead of > editing them -- 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: (MDEPLOY-34) Option to set deployed artifact read-only should be added.
[ http://jira.codehaus.org/browse/MDEPLOY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MDEPLOY-34: --- Fix Version/s: (was: 2.4) > Option to set deployed artifact read-only should be added. > -- > > Key: MDEPLOY-34 > URL: http://jira.codehaus.org/browse/MDEPLOY-34 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.2 > Environment: Not of importance. >Reporter: Davy Toch > > It would be useful for non-SNAPSHOT artifacts to have an option that allows > to set the artifact read-only on the remote repository to avoid that stable > versions are overridden by accident. -- 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-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
[
http://jira.codehaus.org/browse/MDEP-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134339#action_134339
]
Paul Gier commented on MDEP-123:
Did you already try the {{-verbose}} option? This shows all the nodes of the
tree including duplicates that have been omitted.
> dependency:tree to optionally display all instances of a transitive
> dependency, not just the first one found
>
>
> Key: MDEP-123
> URL: http://jira.codehaus.org/browse/MDEP-123
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 2.0
>Reporter: William Ferguson
>Assignee: Brian Fox
> Attachments: pom.xml
>
>
> dependency:tree is *really* useful for tracking down how a particular
> transitive dependency has been introduced, but it only lists the first
> occurrence, not all occurrences. So it can be frustrating game attempting to
> remove a dep only to find it introduced by another component. A parameter to
> dependency:tree to show all occurences of a transitive dep would be *really*
> helpful.
> Eg the attached POM has a direct dep on commons-beanutils and
> commons-digester, which both have a dep on commons-logging. But executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
> {code}
> only shows commons-logging listed as a transitive dep for commons-beanutils,
> not commons-digester, Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> but if an exclusion is added to commons-beanutils for for commons-logging,
> then the other transitive dep instance is revealed. Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> An option to show both instance would be fantastic, Eg
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {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: (MDEP-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
[
http://jira.codehaus.org/browse/MDEP-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134339#action_134339
]
pgier edited comment on MDEP-123 at 5/11/08 9:52 PM:
-
Did you already try the {{-Dverbose=true}} option? This shows all the nodes of
the tree including duplicates that have been omitted.
was (Author: pgier):
Did you already try the {{-verbose}} option? This shows all the nodes of
the tree including duplicates that have been omitted.
> dependency:tree to optionally display all instances of a transitive
> dependency, not just the first one found
>
>
> Key: MDEP-123
> URL: http://jira.codehaus.org/browse/MDEP-123
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 2.0
>Reporter: William Ferguson
>Assignee: Brian Fox
> Attachments: pom.xml
>
>
> dependency:tree is *really* useful for tracking down how a particular
> transitive dependency has been introduced, but it only lists the first
> occurrence, not all occurrences. So it can be frustrating game attempting to
> remove a dep only to find it introduced by another component. A parameter to
> dependency:tree to show all occurences of a transitive dep would be *really*
> helpful.
> Eg the attached POM has a direct dep on commons-beanutils and
> commons-digester, which both have a dep on commons-logging. But executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
> {code}
> only shows commons-logging listed as a transitive dep for commons-beanutils,
> not commons-digester, Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> but if an exclusion is added to commons-beanutils for for commons-logging,
> then the other transitive dep instance is revealed. Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> An option to show both instance would be fantastic, Eg
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {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: (ARCHETYPE-108) Use of wildcards in archetype.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134341#action_134341 ] mahesh kumar commented on ARCHETYPE-108: Hi, I have tried to use wildcard in my archetype.xml. But still it is not working. I have tried the following versions - 2.0-alpha-1, 2.0-alpha-2 and 2.0-alpha-3 > Use of wildcards in archetype.xml > - > > Key: ARCHETYPE-108 > URL: http://jira.codehaus.org/browse/ARCHETYPE-108 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes > Environment: All OS >Reporter: Felipe Lang > Fix For: 2.0-alpha-1 > > > I could be great if we could use wildcards to specify the sources, > testsources, resources and so on in the archetype.xml file. > ie: > > my-archetyp > > src/main/java/com/company/*.java > src/main/java/com/company/**.* > > > src/main/resources/*.* > > -- 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-108) Use of wildcards in archetype.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134342#action_134342 ] mahesh kumar commented on ARCHETYPE-108: I am getting the following exception. at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.proces sOldArchetype(DefaultArchetypeGenerator.java:255) ... 22 more Caused by: java.io.FileNotFoundException: D:\Temp\Install\sample\src\main\webapp \*.jsp (The filename, directory name, or volume label syntax is incorrect) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:179) at java.io.FileOutputStream.(FileOutputStream.java:131) at org.apache.maven.archetype.old.DefaultOldArchetype.processTemplate(De faultOldArchetype.java:901) ... 27 more My archetype.xml is as follows. webapp src/main/webapp/*.jsp src/main/webapp/WEB-INF/web.xml > Use of wildcards in archetype.xml > - > > Key: ARCHETYPE-108 > URL: http://jira.codehaus.org/browse/ARCHETYPE-108 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes > Environment: All OS >Reporter: Felipe Lang > Fix For: 2.0-alpha-1 > > > I could be great if we could use wildcards to specify the sources, > testsources, resources and so on in the archetype.xml file. > ie: > > my-archetyp > > src/main/java/com/company/*.java > src/main/java/com/company/**.* > > > src/main/resources/*.* > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
[
http://jira.codehaus.org/browse/MDEP-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson closed MDEP-123.
-
Resolution: Fixed
Fix Version/s: 2.0
It appears that an excellent solution for this was provide in 2.0-alpha-6.
Great stuff!
> dependency:tree to optionally display all instances of a transitive
> dependency, not just the first one found
>
>
> Key: MDEP-123
> URL: http://jira.codehaus.org/browse/MDEP-123
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 2.0
>Reporter: William Ferguson
>Assignee: Brian Fox
> Fix For: 2.0
>
> Attachments: pom.xml
>
>
> dependency:tree is *really* useful for tracking down how a particular
> transitive dependency has been introduced, but it only lists the first
> occurrence, not all occurrences. So it can be frustrating game attempting to
> remove a dep only to find it introduced by another component. A parameter to
> dependency:tree to show all occurences of a transitive dep would be *really*
> helpful.
> Eg the attached POM has a direct dep on commons-beanutils and
> commons-digester, which both have a dep on commons-logging. But executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
> {code}
> only shows commons-logging listed as a transitive dep for commons-beanutils,
> not commons-digester, Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> but if an exclusion is added to commons-beanutils for for commons-logging,
> then the other transitive dep instance is revealed. Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> An option to show both instance would be fantastic, Eg
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {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] Moved: (MSHADE-33) [shade] Support wildcarded excludes
[
http://jira.codehaus.org/browse/MSHADE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MOJO-765 to MSHADE-33:
-
Key: MSHADE-33 (was: MOJO-765)
Project: Maven 2.x Shade Plugin (was: Mojo)
> [shade] Support wildcarded excludes
> ---
>
> Key: MSHADE-33
> URL: http://jira.codehaus.org/browse/MSHADE-33
> Project: Maven 2.x Shade Plugin
> Issue Type: Improvement
>Reporter: Mark Hobson
>Priority: Minor
>
> It'd be handy to be able to specify wildcards in the excludes configuration.
> For example, to exclude all artifacts from the shaded jar:
> {noformat}
>
>
> *
>
>
> {noformat}
> We could support the following syntax:
> {noformat}
> groupId:*
> *:artifactId
> *:*
> *
> {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
