[jira] Commented: (MDEPLOY-135) Add ability to skip deploying certain modules from command line
[ https://jira.codehaus.org/browse/MDEPLOY-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=273848#comment-273848 ] Wendy Smoak commented on MDEPLOY-135: - It's generally better to ask questions on the mailing list, and then open a JIRA issue once you've confirmed that there is a bug or feature request to be reported. JIRA doesn't work very well for discussions. Re-post this on the user list and I bet you'll get some responses. http://maven.apache.org/mail-lists.html > Add ability to skip deploying certain modules from command line > --- > > Key: MDEPLOY-135 > URL: https://jira.codehaus.org/browse/MDEPLOY-135 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.6 >Reporter: Gayathri Muralidharan >Priority: Minor > > Hi, > Currently it is possible to skip certain modules during deployment by setting > the config in the pom file. > ( true ) > Wouldn't it be nice to have the ability to mention this via command line like > -Dmaven.deploy.skip= modules-to-be-skipped or something so that frequent > changes to pom files are not required and this can be specified/modified > easily from hudson? > Please correct me if this is already supported or if i am missing something > here :) > Thanks, > Gayathri -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MDEPLOY-138) can't upload existing jar+pom as one snapshot artifact
[ https://jira.codehaus.org/browse/MDEPLOY-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak moved MNG-5132 to MDEPLOY-138: -- Complexity: (was: Intermediate) Affects Version/s: (was: 2.2.1) (was: 3.0) 2.2.1 Key: MDEPLOY-138 (was: MNG-5132) Project: Maven 2.x Deploy Plugin (was: Maven 2 & 3) > can't upload existing jar+pom as one snapshot artifact > -- > > Key: MDEPLOY-138 > URL: https://jira.codehaus.org/browse/MDEPLOY-138 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Olaf Klischat > > There seems to be no way to reliably deploy an existing JAR file plus an > accompanying, existing POM file (created w/ ivy) that contains the JAR file's > metadata and dependencies, to a maven repository. > If I run > mvn deploy:deploy-file -Dfile=mylib.jar DpomFile=mypom.pom > -DgeneratePom=false -Durl= > , Maven 3 apparently just uploads the jar and names it > -.pom (!) > (people on maven-users say that this is probably a bug -- > http://maven.40175.n5.nabble.com/uploading-existing-jar-pom-as-one-artifact-td4577118.html) > Maven 2.2 only uploads the POM -- not what was requested either. > So the problem remains -- how can I reliably deploy and existing jar and pom > as one artifact, with the same timestamp/build number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Download specific JARs from the repository
On Mon, Jun 13, 2011 at 3:14 AM, rohit12345 wrote: > Is there a way to download only specifc JARs from the repository. You have written to the issues@ list, which is meant only for automated notifications from the issue tracker. Please re-post your question to the users@ list. I see you're using Nabble, so here's a link: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html -- Wendy
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[ http://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269389#action_269389 ] Wendy Smoak commented on MCOMPILER-120: --- There's already a sample project attached. Are there some docs available on how to turn it into an integration test? > Javac compiler plugin doesn't support -Werror > - > > Key: MCOMPILER-120 > URL: http://jira.codehaus.org/browse/MCOMPILER-120 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Christopher Webster > Attachments: JavacCompiler.java, JavacCompiler.patch, trial-maven.zip > > > If I write a pom file like the following: > ... > > org.apache.maven.plugins > maven-compiler-plugin > 2.1 > > javac > 1.6 > 1.6 > > > > > > true > > > and if there are only warnings, then the build will not fail as intended by > the compiler Argument. The reason is that in compileInProcess the exit code > from javac is only considered if there are no messages. In the case of > treating warnings as errors, there will be messages but no errors so the > intention of the build failure is lost. -- 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
Re: Why the heck won't anyone respond?
You've written to issues@, which is for automated notifications from the issue tracker. If you haven't gotten a reply on your JIRA issue after a while, a [polite] nudge on dev@ is the next step. (Hint: Use a descriptive subject rather than a rant.) I see you're using Nabble, so here's a link to the dev list: http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html -- Wendy On Tue, May 31, 2011 at 3:06 PM, deusaquilus wrote: > The plexus guys made a Jira entry for a P1 critical issue regarding the maven > compilers's inability to property handle a -Werror argument; the fix is a > trivial two line code swap: > http://jira.codehaus.org/browse/MCOMPILER-120 > > I posted the diff 3 weeks ago yet nobody seems to reply! Can a commitier > please check this in? > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Why-the-heck-won-t-anyone-respond-tp4442994p4442994.html > Sent from the Maven - Issues mailing list archive at Nabble.com. >
[jira] Commented: (MNG-5104) Enforcing build order...
[
http://jira.codehaus.org/browse/MNG-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268373#action_268373
]
Wendy Smoak commented on MNG-5104:
--
It sounds like you want help enforcing your architecture. You might look at
tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using transitive dependencies
is part of the Maven magic and I'm not sure there'd be much support for turning
it off.
> Enforcing build order...
>
>
> Key: MNG-5104
> URL: http://jira.codehaus.org/browse/MNG-5104
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build, Reactor and workspace
>Affects Versions: 2.2.1
> Environment: Linux AMD64
>Reporter: Ancoron Luciferis
>
> Currently, building multi-module aka. reactor projects is working, but does
> not help the developers to ensure a certain level of isolation of their
> modules.
> E.g. imagine the following project tree:
> *
> ** Component A
> *** A.api
> *** A.jpa
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...and all things are just fine.
> Now, some developer comes in, not fully aware of the "big picture", producing
> something like this:
> *
> ** Component A
> *** A.api
> *** A.jpa (depends on B.jpa)
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api, C.ejb)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...so in an old-school build with tools like Ant this would fail to build as
> the build order is clear and strict, according to best-practices. Not so with
> Maven. In the first case Maven might (although unlikely and yet to be seen)
> come up with a clear build order like this:
> #
> # Component A
> # A.api
> # A.jpa
> # A.ejb
> # Component B
> # B.api
> # B.jpa
> # B.ejb
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> ...however, in the second case Maven will not fail to build and instead come
> up with something like this:
> #
> # Component A
> # A.api
> # Component B
> # B.jpa
> # A.jpa
> # A.ejb
> # B.api
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> # B.ejb
> All artifacts are build correctly, but it is no longer guaranteed that e.g.
> "Component A" could be used without "Component B", therefore introducing a
> requirement and eventually a lot of changes to the build-/tool-/test-chain.
> So we would like to have an option to disable the Maven "magic" here and just
> stupidly build according to the {{}} tags we've carefully written.
--
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-5104) Enforcing build order...
[
http://jira.codehaus.org/browse/MNG-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268373#action_268373
]
Wendy Smoak edited comment on MNG-5104 at 5/24/11 8:06 PM:
---
It sounds like you want help enforcing your architecture. You might look at
tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using the dependencies is part
of the Maven magic and I'm not sure there'd be much support for turning it off.
was (Author: wsmoak):
It sounds like you want help enforcing your architecture. You might look
at tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using transitive dependencies
is part of the Maven magic and I'm not sure there'd be much support for turning
it off.
> Enforcing build order...
>
>
> Key: MNG-5104
> URL: http://jira.codehaus.org/browse/MNG-5104
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build, Reactor and workspace
>Affects Versions: 2.2.1
> Environment: Linux AMD64
>Reporter: Ancoron Luciferis
>
> Currently, building multi-module aka. reactor projects is working, but does
> not help the developers to ensure a certain level of isolation of their
> modules.
> E.g. imagine the following project tree:
> *
> ** Component A
> *** A.api
> *** A.jpa
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...and all things are just fine.
> Now, some developer comes in, not fully aware of the "big picture", producing
> something like this:
> *
> ** Component A
> *** A.api
> *** A.jpa (depends on B.jpa)
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api, C.ejb)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...so in an old-school build with tools like Ant this would fail to build as
> the build order is clear and strict, according to best-practices. Not so with
> Maven. In the first case Maven might (although unlikely and yet to be seen)
> come up with a clear build order like this:
> #
> # Component A
> # A.api
> # A.jpa
> # A.ejb
> # Component B
> # B.api
> # B.jpa
> # B.ejb
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> ...however, in the second case Maven will not fail to build and instead come
> up with something like this:
> #
> # Component A
> # A.api
> # Component B
> # B.jpa
> # A.jpa
> # A.ejb
> # B.api
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> # B.ejb
> All artifacts are build correctly, but it is no longer guaranteed that e.g.
> "Component A" could be used without "Component B", therefore introducing a
> requirement and eventually a lot of changes to the build-/tool-/test-chain.
> So we would like to have an option to disable the Maven "magic" here and just
> stupidly build according to the {{}} tags we've carefully written.
--
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: (MDEPLOY-124) Deploy without build
[ http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268171#action_268171 ] Wendy Smoak commented on MDEPLOY-124: - It sounds like the release staging feature of one of the various artifact repositories would be useful here. You deploy to one place, do whatever, and then promote the release later. > Deploy without build > > > Key: MDEPLOY-124 > URL: http://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- 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: (MCOMPILER-154) Full command line should be printed in debug mode
Full command line should be printed in debug mode - Key: MCOMPILER-154 URL: http://jira.codehaus.org/browse/MCOMPILER-154 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Reporter: Wendy Smoak Priority: Minor When running with -X, the output should include the full javac command line as executed by the plugin. Currently it only contains a list of the configuration elements. Similar to MEXEC-67 -- 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-5092) project building
[ http://jira.codehaus.org/browse/MNG-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266488#action_266488 ] Wendy Smoak commented on MNG-5092: -- If you need help, please write to the users list. You can find info here: http://maven.apache.org/mail-lists.html > project building > > > Key: MNG-5092 > URL: http://jira.codehaus.org/browse/MNG-5092 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: amaresh mourya >Assignee: Benjamin Bentmann > -- 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-5088) The order of plugins within the same phase cannot be specified in Maven 3
[ http://jira.codehaus.org/browse/MNG-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266001#action_266001 ] Wendy Smoak commented on MNG-5088: -- A better way to get it some attention would be to bring it up on the mailing list, not open a bug report that you already know is going to get closed as a duplicate... > The order of plugins within the same phase cannot be specified in Maven 3 > - > > Key: MNG-5088 > URL: http://jira.codehaus.org/browse/MNG-5088 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.3 > Environment: Windows >Reporter: Graham Lea > Attachments: build.log, pom.xml > > > This report is a duplicate of MNG-2258, HOWEVER it seems no one is paying > attention to that issue as it is a Blocker Bug but it has been around for 5 > years now and is still not assigned to anyone. I realise it's poor form to > create a duplicate bug, and I apologise, but it seemed to me that adding a > comment to an issue that's been ignored for 5 years would probably not have > any effect. > The problem is simple: people need the ability to control the order in which > plugins within the same phase are executed. At the moment this appears not to > be possible, at least in Maven 3.0.3 - the latest and greatest, right? > I am attaching a simple pom which, when executed with 'mvn install', executes > the plugins in the opposite order to what is specified in the pom (on my > machine, at least). No other source files are necessary for reproducing the > problem. > Also attached is the -X output of running the build. > It's my understanding that someone submitted a patch or at least suggested a > simple solution on the older issue, MNG-2258. > I don't mind if this issue is closed as a duplicate, as long as someone is > assigned to look at MNG-2258. > 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
Re: error while deploying a project
On Thu, Apr 14, 2011 at 11:49 AM, Nilesh Mevada wrote: > I have migrated all the necessary artifcats to sonatype nexus as explained > in their docs and found no errors while rebuilding any indexes whatsoever in > the logs. The migration was successful. However, while deploying one of the > project, i get following error.. Please re-post your question to either the Maven or Nexus users list. (You've written to an address that is only used for automated notifications from the issue tracking system.) http://maven.apache.org/mail-lists.html -- Wendy
[jira] Commented: (ARCHETYPE-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
http://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259563#action_259563
]
Wendy Smoak commented on ARCHETYPE-366:
---
I don't see anything on the command line that specifies that the archetype
should be looked for in repository id 'central'. That you are supplying a url
that happens to match the one for the central repository is not enough for the
mirror to kick in.
My bet is you need to figure out what repository id is being used when you
supply an archetypeRepository url (which is why I asked for more build output
-- but it may not show up anyway) and configure a mirror for *that* id.
Haven't looked at the code though.
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: http://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
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-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
http://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259553#action_259553
]
Wendy Smoak commented on ARCHETYPE-366:
---
You have only defined a mirror for 'central'. Try changing that to
* and see if it behaves the way you expect.
I can't tell without seeing more of the build output, but I suspect when you
supply an archetypeRepository, it has some other repository id, for which you
have not defined a mirror.
(Is there an 'archetypeRepositoryId' parameter you can pass?)
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: http://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
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: (MRELEASE-612) release:branch is altering poms on the tag hierarchy
[
http://jira.codehaus.org/browse/MRELEASE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MRELEASE-612.
Resolution: Duplicate
Assignee: Wendy Smoak
> release:branch is altering poms on the tag hierarchy
>
>
> Key: MRELEASE-612
> URL: http://jira.codehaus.org/browse/MRELEASE-612
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: Frédéric Camblor
> Assignee: Wendy Smoak
>
> Currently, I execute following command line :
> mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.0:branch
> -DautoVersionSubmodules=true -DtagBase=tags/ -Dtag=1.0.0
> -DupdateBranchVersions=true -DreleaseVersion=2.0.0 -DbranchBase=branches/
> -DbranchName=2.0.0
> My goal, here, is to create a new branch called "2.0.0" from the 1.0.0 tag.
> It works great but I found something crappy : some commit were made on the
> 1.0.0 tag hierarchy.
> That is to say, the plugin is acting this way :
> - Checkout tag ${tagBase}${tag} in working directory
> - Modify pom to ${releaseVersion}-SNAPSHOT & scm
> - Commit pom (on tag 1.0.0 !!!)
> - If something is going bad during the next two lines, your tag
> hierarchy will be altered
> - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
> hierarchy
> - Re-Modify pom in working directory to ${tag}
> - Re-Commit pom on tag 1.0.0
> I would think it would act this way :
> - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
> hierarchy
> - Checkout ${branchBase}${branchName}/ in working directory
> - Modify pom to ${releaseVersion}-SNAPSHOT
> - Commit pom (on branch !) & scm
> Even by passing -DupdateWorkingCopyVersions=false, it continues to commit on
> the tag hierarchy.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-642) "String index out of range" during eclipse:eclipse for a project that works with 2.7
[
http://jira.codehaus.org/browse/MECLIPSE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241965#action_241965
]
Wendy Smoak commented on MECLIPSE-642:
--
The plugin should handle this better, but generally maven modules are intended
to be standalone. If you want to share files, do it through the repository,
(package them in a jar from one module, pull them back out in the other,) not
with relative paths outside the module.
> "String index out of range" during eclipse:eclipse for a project that works
> with 2.7
>
>
> Key: MECLIPSE-642
> URL: http://jira.codehaus.org/browse/MECLIPSE-642
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.8
> Environment: Windows XP, Maven 2.2.1, Maven 2.x Eclipse Plugin v2.8
>Reporter: Matthew McCullough
> Attachments: Eclipse Plugin 2.8 Out Of Bounds Error.txt
>
>
> We tried to upgrade to using v2.8 of the plugin, but a regression stops us
> dead in our tracks. Reverting to 2.7 allows us to continue for now.
> When running eclipse:eclipse on our projects, we get an occasional
> "String index out of range: -6"
> The stack trace indicates this is on line 111 of:
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.8/src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseSettingsWriter.java?view=markup
> I see that those lines are:
> 109{
> 110 Resource resource = (Resource) it.next();
> 111 String relativePath = resource.getDirectory().substring(
> basedir.length() ).replace( '\\', '/' );
> 112 coreSettings.put( PROP_JDT_CORE_COMPILER_ENCODING +
> relativePath, encoding );
> 113}
> I've attached a snippet of the -X output (about the last 50 lines)...
--
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-4885) Why incremental build is not supported natively by Maven?
[
http://jira.codehaus.org/browse/MNG-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241854#action_241854
]
Wendy Smoak commented on MNG-4885:
--
You might want to re-post this on the mailing list (or search the archives -- I
think it's come up before).
> Why incremental build is not supported natively by Maven?
> -
>
> Key: MNG-4885
> URL: http://jira.codehaus.org/browse/MNG-4885
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Vincenzo Mancini
>
> I have a multi-module project with two sub-modules. I compile and package it
> without mistakes. The build is complete. Then I make a change in one
> {{.java}} file in one of them. And now I'm trying to package the whole
> project again. Maven re-runs tests in both two modules, static code analysis
> in both modules, etc.
> Why so? It's a very ineffective way of building, as far as I understand.
> Maybe maven can introduce a mechanism of "dependency discovery" between
> files. Like:
> {noformat}
> foo.jar depends on:
> abc.java
> cde.java
> bar.jar depends on:
> xxx.java
> {noformat}
> When there is a change in {{cde.java}} only - maven SHOULD NOT do anything
> with {{bar.jar}}. This is how Unix {{make}} utility is working... 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] Commented: (SUREFIRE-321) Run tests in alphabetical order
[ http://jira.codehaus.org/browse/SUREFIRE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236069#action_236069 ] Wendy Smoak commented on SUREFIRE-321: -- I didn't see the commit touch the docs, is this already described? Seems like a behavior change otherwise that should be called out. > Run tests in alphabetical order > --- > > Key: SUREFIRE-321 > URL: http://jira.codehaus.org/browse/SUREFIRE-321 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Daniel Beland >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 2.7 > > Attachments: SUREFIRE-243.patch, SUREFIRE-321.patch > > > It would be nice if the tests were run in alphabetical order (with complete > package name). > So all tests in a package run in order and same things for each packages. > It just makes it easier to know where we currently are in the tests and makes > it easier to estimate how long it will take before the tests finish to run. -- 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
Re: Maven jar does not preserve file permissions
Please re-post your question on the users list -- this one is for automated notices from the issue tracking system. -Wendy On Mon, Aug 23, 2010 at 1:46 PM, usammmy wrote: > > I have some scripts under src/main/resources/scripts. These scripts are > executables. But maven jar is not preserving these file permissions. Any > suggestions? > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-jar-does-not-preserve-file-permissions-tp2645103p2645103.html > Sent from the Maven - Issues mailing list archive at Nabble.com. >
[jira] Commented: (MAVENUPLOAD-2788) Remove artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225532#action_225532 ] Wendy Smoak commented on MAVENUPLOAD-2788: -- ... and we're starting to get questions about it on the Maven Users list. As Brett said, normally things are not removed from the central repo. No idea whether the maintainers will make an exception in this case, but one way forward is to release 2.0.1 with corrected poms. > Remove artifacts > > > Key: MAVENUPLOAD-2788 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2788 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Blaine Simpson > > Simple directory removal request. > I do not want a Maven Upload, but just to wipe some artifacts that you are > already mirroring to ibiblio (so that I can fix them). I am only opening > this issue under this project because there is no other relevant "project" to > fix issues with artifacts already in place. I figure that the techs who can > work Upload tickets should know how to get to the mock-ftp staging or ibiblio > production servers and know where the maven2 artifacts reside there. > My problem is, you already picked up, by rsync, my new resources for my new > project version 2.0.0. There was a mistake in the .pom files which was > discovered after your pick-up. Not a big deal with the .pom mistake-- I > fixed that in 5 minutes. But your rsync pickup job refuses to modify > existing hosted artifacts, very likely because of the --ignore-existing > switch that you use for rsync. > If you could just get on the staging or production servers as needed and wipe > out all of the 2.0.0 subdirectories at the level > http://repo2.maven.org/maven2/org/hsqldb/*/2.0.0/ , that should be all that > is needed (there are 4 directories at the same exact level, all grandchildren > of http://repo2.maven.org/maven2/org/hsqldb/). > I have a lot of experience with rsync, and with UNIX and scripting generally, > so let me know if I can help in any way. -- 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-558) release:stage should merge metadata from repository.
[ http://jira.codehaus.org/browse/MRELEASE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221171#action_221171 ] Wendy Smoak commented on MRELEASE-558: -- I'm not sure you'll know the final release repository when the release is staged. And that repo could change in the meantime, if someone else deploys a release. (Say you are working on 2.1 and they release 3.0 after you stage and before you promote.) I think the metadata should be done when the release is promoted. > release:stage should merge metadata from repository. > > > Key: MRELEASE-558 > URL: http://jira.codehaus.org/browse/MRELEASE-558 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: stage >Affects Versions: 2.0 >Reporter: Antonio Petrelli > > Currently the release:stage goal does its job well, except when creating > metadata. > The metadata contains only the version of the released artifacts. I think > that it should: > * download the original metadata; > * merge the metadata with the new one; > * upload it in the staging repository. > This way, moving from stage repository to the release repository is a matter > of a simple copy. This is true especially at Apache. -- 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: (MCOMPILER-124) Change the default source/target settings to 1.5
[ http://jira.codehaus.org/browse/MCOMPILER-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217478#action_217478 ] Wendy Smoak commented on MCOMPILER-124: --- Marked as a duplicate of MCOMPILER-80, do you want to keep that one instead? > Change the default source/target settings to 1.5 > > > Key: MCOMPILER-124 > URL: http://jira.codehaus.org/browse/MCOMPILER-124 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > People shouldn't have to configure the compiler plugin to get > source/target=1.5 in this day and age. -- 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: (MEV-653) Invalid signatures at central
[ http://jira.codehaus.org/browse/MEV-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214259#action_214259 ] Wendy Smoak commented on MEV-653: - Thanks for volunteering to do this, Dennis. My thoughts: 3. I don't think a vote is necessary, we already voted on the artifacts and you are not changing them 5. The .asc.md5 and .asc.sha1 files can be removed, they are not necessary. If they can't easily be removed, then they'll need to be replaced so they match the new .asc file > Invalid signatures at central > - > > Key: MEV-653 > URL: http://jira.codehaus.org/browse/MEV-653 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Anders Hammar >Assignee: Dennis Lundberg > > The signatures for these poms are invalid. This causes issues when setting up > environments that verify the signatures and is not good as all Apache > artifacts is supposed to be signed as I understand it. This pom is used as a > parent by some artifacts which many Maven plugins use. Here's an example: > maven-compiler-plugin:2.1 depends on maven-toolchain:1.0 which has > maven:2.0.6 as parent. > I asked Jason van Zyl about this as it is (supposedly) he who signed and he > says he lost that key and revoked it. Hence the signature should fail. > However, the weird thing is that org.apache.maven:maven-script:2.0.6 was > signed with the same key about the same time (part of the same release?) and > that signature is reported ok. > I'd happily work with you to solve this. There are possibly more artifacts > with invalid signatures. However, I have to admit that I am no pgp expert. -- 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: (MEV-653) Invalid signatures at central
[ http://jira.codehaus.org/browse/MEV-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213662#action_213662 ] Wendy Smoak commented on MEV-653: - I can't find a JIRA issue, but I'm pretty sure this was a bug in a prior Maven version. Yes, signatures are required and this should have been discovered during the vote. Since the poms are plain text and could be compared pretty easily to the svn tag, you should be able to verify that they are okay for your use. > Invalid signatures at central > - > > Key: MEV-653 > URL: http://jira.codehaus.org/browse/MEV-653 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Anders Hammar > > The signatures for these poms are invalid. This causes issues when setting up > environments that verify the signatures and is not good as all Apache > artifacts is supposed to be signed as I understand it. This pom is used as a > parent by some artifacts which many Maven plugins use. Here's an example: > maven-compiler-plugin:2.1 depends on maven-toolchain:1.0 which has > maven:2.0.6 as parent. > I asked Jason van Zyl about this as it is (supposedly) he who signed and he > says he lost that key and revoked it. Hence the signature should fail. > However, the weird thing is that org.apache.maven:maven-script:2.0.6 was > signed with the same key about the same time (part of the same release?) and > that signature is reported ok. > I'd happily work with you to solve this. There are possibly more artifacts > with invalid signatures. However, I have to admit that I am no pgp expert. -- 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-4583) warning printed when a pom does not use an activated profile is poorly worded and also should not be printed for multi-module builds
[ http://jira.codehaus.org/browse/MNG-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213353#action_213353 ] Wendy Smoak commented on MNG-4583: -- How about 'Profile with id [X] is activated, but not defined' or '...does not exist' ? I agree that the message is confusing, there's an irc conversation somewhere in the logs when I first encountered it... > warning printed when a pom does not use an activated profile is poorly worded > and also should not be printed for multi-module builds > > > Key: MNG-4583 > URL: http://jira.codehaus.org/browse/MNG-4583 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.11, 2.2.1, 3.0-alpha-6 >Reporter: Ian Springer >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 3.0-alpha-6 > > > This is a followup to http://jira.codehaus.org/browse/MNG-3641. Refer to that > issue for the background. > The current warning message is: > "Profile with id: '" + explicitProfileId + "' has not been activated." > I think this message is misleading, because the profile actually is activated > - it's just not used at all in the pom being processed. I suggest changing > the message to something like: > "Profile with id '" + explicitProfileId + "' is activated, but this pom does > not contain any usages of the profile." > Also, I don't think it makes sense to print this warning at all in a > multi-module build. In the large multi-module project I work on, we have a > number of profiles that are only used in a handful of the 50 or so modules. -- 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-73) Don't add checksums on gpg signature files
[ http://jira.codehaus.org/browse/MDEPLOY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MDEPLOY-73: --- Patch Submitted: [Yes] > Don't add checksums on gpg signature files > -- > > Key: MDEPLOY-73 > URL: http://jira.codehaus.org/browse/MDEPLOY-73 > Project: Maven 2.x Deploy Plugin > Issue Type: Wish >Affects Versions: 2.3 > Reporter: Wendy Smoak >Priority: Minor > Attachments: DefaultWagonManager.patch > > > Similar to MINSTALL-48, don't create checksums when deploying a gpg signature > file along with the artifact. > Currently we end up with filename.asc, filename.asc.md5 and filename.asc.sha1 > in the remote repository, and only filename.asc is necessary. -- 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-3472) configuration possibilities to limit size of local repository
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209641#action_209641 ] Wendy Smoak commented on MNG-3472: -- This issue is closed, so nothing is likely to change unless someone brings it up on the mailing list for discussion. Continuum already has a local repository purge feature. Perhaps that code could be turned into a separate utility/daemon. > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: http://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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: (MWAR-121) Maven-war-plugin not installing war. Installs ".jar" and renames it to ".war"
[ http://jira.codehaus.org/browse/MWAR-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208952#action_208952 ] Wendy Smoak commented on MWAR-121: -- Rich, this issue is already closed as "Won't Fix" indicating that the developers don't consider it a valid bug. You might want to bring it up on the mailing list if you feel it should be re-opened. Otherwise, nothing is likely to happen with it. > Maven-war-plugin not installing war. Installs ".jar" and renames it to ".war" > - > > Key: MWAR-121 > URL: http://jira.codehaus.org/browse/MWAR-121 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Environment: Windows XP > Maven 2.0.7 > JDK 1.5.0_10 >Reporter: Dave Rathnow >Assignee: Stephane Nicoll > Attachments: war.zip > > > I'm trying to use the maven-war-plugin to install a war into my local > repository. "mvn clean install" runs fine and completes succesfully. If I > look under the target" directory in the project folder, there is, amoung > other things, a .jar and .war file. Both have been built properly. However, > if I look in my local repository, there is a .war file but when I open it, it > is actually the .jar file renamed to .war. > The attached zip file contains the pom for the project, the parent pom and > the output from the command "mvn clean install -X > output.log" -- 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-517) Release should have parameters to update the parent pom and then resolve dependencies appropriately
[ http://jira.codehaus.org/browse/MRELEASE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208826#action_208826 ] Wendy Smoak commented on MRELEASE-517: -- You could try using the scm plugin to commit the changes made by the versions plugin. (Probably best to discuss on the mailing list, JIRA isn't great for that sort of thing.) > Release should have parameters to update the parent pom and then resolve > dependencies appropriately > --- > > Key: MRELEASE-517 > URL: http://jira.codehaus.org/browse/MRELEASE-517 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-9 >Reporter: Kurt Zettel > > The maven-versions-plugin will update my project's parent pom version to the > latest release version. It would be nice if the release plugin would do the > same. I am currently unable to find a way to use these two plugins together > to automate a release. -- 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: (JXR-79) NPE on source XREF
[ http://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206719#action_206719 ] Wendy Smoak commented on JXR-79: Whatever the problem is, it shouldn't die with a NPE. Can you provide a simple example project that demonstrates the problem? > NPE on source XREF > -- > > Key: JXR-79 > URL: http://jira.codehaus.org/browse/JXR-79 > Project: Maven JXR > Issue Type: Bug > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_16 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family: "unix" >Reporter: Johannes Schneider > > [INFO] Generating "Source Xref" report. > [DEBUG] Scanning > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java > [DEBUG] parsing... com/cedarsoft/VersionRange.java > [DEBUG] parsing... com/cedarsoft/Version.java > [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java > [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java > [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java > [DEBUG] parsing... com/cedarsoft/VersionException.java > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html > [DEBUG] ** > [DEBUG] Starting Jakarta Velocity v1.4 > [DEBUG] RuntimeInstance initializing. > [DEBUG] Default Properties File: > org/apache/velocity/runtime/defaults/velocity.properties > [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger > [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger > [DEBUG] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [DEBUG] Resource Loader Instantiated: > org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader > [DEBUG] ClasspathResourceLoader : initialization starting. > [DEBUG] ClasspathResourceLoader : initialization complete. > [DEBUG] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [DEBUG] Default ResourceManager initialization complete. > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [DEBUG] Created: 20 parsers. > [DEBUG] Velocimacro : initialization starting. > [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [DEBUG] Velocimacro : messages on : VM system will output logging messages > [DEBUG] Velocimacro : autoload off : VM system will not automatically reload >
[jira] Created: (MPDF-34) plugin fails with AbstractMethodError
plugin fails with AbstractMethodError - Key: MPDF-34 URL: http://jira.codehaus.org/browse/MPDF-34 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Maven 2.2.1 Mac OS X Reporter: Wendy Smoak To reproduce, change the pdf plugin version from 1.0 to 1.1 in https://svn.apache.org/repos/asf/continuum/trunk/continuum-docs With 1.0 it works fine. With 1.1 it fails with: $ mvn site -X ... [FATAL ERROR] org.apache.maven.plugins.pdf.PdfMojo#execute() caused a linkage error (java.lang.AbstractMethodError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.apache.maven.plugins:maven-pdf-plugin:1.1] ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.AbstractMethodError at org.apache.maven.plugins.pdf.PdfMojo.generateMavenReport(PdfMojo.java:1211) at org.apache.maven.plugins.pdf.PdfMojo.generateMavenReports(PdfMojo.java:1072) at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:545) at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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) [INFO] [INFO] Total time: 26 seconds [INFO] Finished at: Wed Dec 16 14:25:53 MST 2009 [INFO] Final Memory: 88M/204M [INFO] -- 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-4458) checksumPolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198737#action_198737 ] Wendy Smoak commented on MNG-4458: -- ... and now I'm curious where you are configuring checksumPolicy=ignore. The docs for repositories in settings.xml say that 'fail' and 'warn' are the only options: http://maven.apache.org/ref/2.2.1/maven-settings/settings.html#class_releases > checksumPolicy always gets ignored > -- > > Key: MNG-4458 > URL: http://jira.codehaus.org/browse/MNG-4458 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.2.1 >Reporter: Michael K > > I have many checksum errors on my builds. But the builds runs successfully. > So I want to ignore the checksum errors to save time. But setting of > checksumPolicy to ignore doesn't take any effect. -- 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-4458) checksumPolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198735#action_198735 ] Wendy Smoak commented on MNG-4458: -- Were you able to find any documentation on this? It sounds like you think ignore means to ignore the checksum entirely and not do the comparison. I think ignore means to ignore any bad checksums (but it will still check them). > checksumPolicy always gets ignored > -- > > Key: MNG-4458 > URL: http://jira.codehaus.org/browse/MNG-4458 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.2.1 >Reporter: Michael K > > I have many checksum errors on my builds. But the builds runs successfully. > So I want to ignore the checksum errors to save time. But setting of > checksumPolicy to ignore doesn't take any effect. -- 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-3832) Allow wildcards in dependency exclusions
[
http://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198239#action_198239
]
Wendy Smoak commented on MNG-3832:
--
I think you'll get more attention if you post to the dev list and describe what
you've done. JIRA produces a LOT of mail and many people filter it out. This
is an issue with quite a few votes and watchers, so hopefully you'll catch the
interest of a committer who can help.
> 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
> Fix For: 2.x
>
> Attachments: MNG-3832-maven-artifact.patch
>
>
> 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] Commented: (MNG-4413) [regression] Repositories discovered in dependency POMs are not subject to mirroring
[ http://jira.codehaus.org/browse/MNG-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196344#action_196344 ] Wendy Smoak commented on MNG-4413: -- Is the ability for dependencies to add repos to the build going to be kept? It's been discussed in the past, my impression was that it should be removed. > [regression] Repositories discovered in dependency POMs are not subject to > mirroring > > > Key: MNG-4413 > URL: http://jira.codehaus.org/browse/MNG-4413 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann > > Build logs revealed that trunk does not use mirrors for those repositories > that are contributed by POMs of dependencies during transitive dependency > resolution. -- 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: (MSOURCES-52) Don't add a source jar file for packaging pom
[ http://jira.codehaus.org/browse/MSOURCES-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196146#action_196146 ] Wendy Smoak commented on MSOURCES-52: - Not sure this is correct -- a project with a packaging of 'pom' may actually contain source code. > Don't add a source jar file for packaging pom > - > > Key: MSOURCES-52 > URL: http://jira.codehaus.org/browse/MSOURCES-52 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Alexandre Navarro > > Don't add a source jar file for packaging 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] Commented: (MAVEN-1569) Per-dependency remote repository
[ http://jira.codehaus.org/browse/MAVEN-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189139#action_189139 ] Wendy Smoak commented on MAVEN-1569: See http://maven.apache.org/repository-management.html for more information on repository management. > Per-dependency remote repository > > > Key: MAVEN-1569 > URL: http://jira.codehaus.org/browse/MAVEN-1569 > Project: Maven 1 > Issue Type: Improvement > Components: model additions >Affects Versions: 1.0.2 >Reporter: baleineca >Priority: Minor > > There are times when you know a certain snapshot dependency resides only in a > particular repository. > It would be nice to be able to specify the remote repository for such > dependency so that Maven only connects to that repository to get it. > Although there is no build failure currently, this improvement would > eliminate lots of 404 http responses and shorten build time when handling > large multiproject or reactor based build. -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MNG-2258: - Fix Version/s: (was: 2.2.0) Un-setting fix version (was 2.2.0) as it was marked as a duplicate and it's not clear it was ever fixed... > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Blocker > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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] Reopened: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MNG-2258: -- Assignee: (was: John Casey) Reopening based on comments. Can someone clarify the expected behavior and point to docs/tests which explain it? > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Blocker > Fix For: 2.2.0 > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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-245) Provide reason for deprecation and suggest replacement
[ http://jira.codehaus.org/browse/ARCHETYPE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated ARCHETYPE-245: -- Priority: Minor (was: Blocker) Summary: Provide reason for deprecation and suggest replacement (was: Nothing should ever be "Deprecated." ) If *all* of the goals are showing deprecated, it's probably a bug in the help plugin. They aren't all deprecated when I run it, so I'm moving this to Archetype to - provide reason for deprecation - suggest a replacement goal to use if possible > Provide reason for deprecation and suggest replacement > -- > > Key: ARCHETYPE-245 > URL: http://jira.codehaus.org/browse/ARCHETYPE-245 > Project: Maven Archetype > Issue Type: Task > Components: Plugin >Affects Versions: 2.0-alpha-4 > Environment: Irrelevant. >Reporter: Hendrik Groeneveld >Priority: Minor > > Saying something is "Deprecated." is not acceptable. In my particular case, > I'm looking at the archetype plugin trying to create a new project but "mvn > help:describe -Dplugin=archetype" says that all of the goals are "Deprecated. > No reason given" "Deprecated, see xxx" would be perfectly acceptable but just > "Deprecated." is a major problem as I have no idea where to go next and am > totally blocked. -- 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: (ARCHETYPE-245) Nothing should ever be "Deprecated."
[ http://jira.codehaus.org/browse/ARCHETYPE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak moved MNG-4185 to ARCHETYPE-245: Affects Version/s: (was: 2.1.0) 2.0-alpha-4 Component/s: (was: Documentation: General) Plugin Complexity: (was: Intermediate) Issue Type: Task (was: Bug) Key: ARCHETYPE-245 (was: MNG-4185) Project: Maven Archetype (was: Maven 2) > Nothing should ever be "Deprecated." > - > > Key: ARCHETYPE-245 > URL: http://jira.codehaus.org/browse/ARCHETYPE-245 > Project: Maven Archetype > Issue Type: Task > Components: Plugin >Affects Versions: 2.0-alpha-4 > Environment: Irrelevant. >Reporter: Hendrik Groeneveld >Priority: Blocker > > Saying something is "Deprecated." is not acceptable. In my particular case, > I'm looking at the archetype plugin trying to create a new project but "mvn > help:describe -Dplugin=archetype" says that all of the goals are "Deprecated. > No reason given" "Deprecated, see xxx" would be perfectly acceptable but just > "Deprecated." is a major problem as I have no idea where to go next and am > totally blocked. -- 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: (MNGSITE-87) Document the build timestamp feature
Document the build timestamp feature
Key: MNGSITE-87
URL: http://jira.codehaus.org/browse/MNGSITE-87
Project: Maven 2 Project Web Site
Issue Type: Task
Reporter: Wendy Smoak
The new ${build.timestamp} feature does not appear to be documented
See http://jira.codehaus.org/browse/MNG-2562 and the maze of linked issues...
--
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-2562) expose current time as a property for POM interpolation
[
http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176331#action_176331
]
Wendy Smoak commented on MNG-2562:
--
A user asked about this on irc:
benson0: I'm lost in the maze of MNG-3718. Can someone just tell me the ${} to
access a readable build date in 2.1.0? None of the syntaxes mentioned in the
jiras seem to be right.
jason: ${build.timestamp}
I can't find it anywhere in the site, however grep does turn up a mention in
maven-project-spec.tex as well as the code/tests.
> expose current time as a property for POM interpolation
> ---
>
> Key: MNG-2562
> URL: http://jira.codehaus.org/browse/MNG-2562
> Project: Maven 2
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> it is useful to have the current time, for example to write out a manifest
> entry for the build time or to filter into another file.
> I'm not sure of the best way to make the format of the time configurable -
> perhaps another POM element/property.
> See the related issue for a current example of how this can be done, but it
> would be nice to have a built-in.
--
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-4156) Local test scope shouldn't override transitive compile scope
[ http://jira.codehaus.org/browse/MNG-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175973#action_175973 ] Wendy Smoak commented on MNG-4156: -- Related thread: http://www.nabble.com/Transitive-and-inherited-dependencies---potential-bug%2C-or-my--misunderstanding-of-the-mechanism-td23403092.html > Local test scope shouldn't override transitive compile scope > > > Key: MNG-4156 > URL: http://jira.codehaus.org/browse/MNG-4156 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.1.0 >Reporter: Stevo Slavic > Attachments: example.zip > > > Local test scoped dependencies shouldn't by default override compile scoped > transitive dependencies. If one wanted to exclude transitive compile scoped > dependency and have it available only in test scope, it would be more natural > (for me at least) to require user to specify appropriate excludes section on > a dependency that brought transitive dependency with it. In this case (local > test scoped vs transitive compile scoped dependency), requiring user to > explicitly specify excludes section would more clearly state/document the > intention, while currently build tool silently makes a wrong decision (maybe > there are times this decision is correct, but IMO it's correct in far less > cases than it is wrong). > Attached is example project where current in most cases unwanted behavior can > be reproduced. -- 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] Reopened: (MPDF-1) Ability to use pom properties in pdf.xml
[ http://jira.codehaus.org/browse/MPDF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MPDF-1: Reopening to fix use of version number property in the output filename, where it gets truncated. > Ability to use pom properties in pdf.xml > > > Key: MPDF-1 > URL: http://jira.codehaus.org/browse/MPDF-1 > Project: Maven 2.x PDF Plugin > Issue Type: Wish > Reporter: Wendy Smoak >Assignee: Vincent Siveton > > I'd like to include the project version number in the filename of the pdf, > for example, in pdf.xml: > -- 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: (MPDF-11) Improve warning message for invalid links
[ http://jira.codehaus.org/browse/MPDF-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MPDF-11: Including the problem .apt filename would be good, so the user knows where to edit. > Improve warning message for invalid links > - > > Key: MPDF-11 > URL: http://jira.codehaus.org/browse/MPDF-11 > Project: Maven 2.x PDF Plugin > Issue Type: Improvement >Affects Versions: 1.0 > Environment: 1.0-SNAPSHOT r772248 > Reporter: Wendy Smoak >Priority: Minor > > Currently I'm getting several warnings like this: > [WARNING] Modified invalid link: notification/index.html > It would be nice if the message said why this is invalid and/or what to do to > fix it (usually, prepend ./ ). -- 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: (MPDF-11) Improve warning message for invalid links
Improve warning message for invalid links - Key: MPDF-11 URL: http://jira.codehaus.org/browse/MPDF-11 Project: Maven 2.x PDF Plugin Issue Type: Improvement Affects Versions: 1.0 Environment: 1.0-SNAPSHOT r772248 Reporter: Wendy Smoak Priority: Minor Currently I'm getting several warnings like this: [WARNING] Modified invalid link: notification/index.html It would be nice if the message said why this is invalid and/or what to do to fix it (usually, prepend ./ ). -- 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: (MPDF-1) Ability to use pom properties in pdf.xml
[
http://jira.codehaus.org/browse/MPDF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175255#action_175255
]
Wendy Smoak edited comment on MPDF-1 at 5/6/09 8:41 AM:
Thanks, Vincent. To try this out I first built Doxia, then the PDF plugin.
Then I edited src/site/pdf.xml to include the version as above.
The result was only part of the version being used:
$ ls target/site/*.pdf
target/site/apache-continuum-1.4.pdf
I expected apache-continuum-1.4.0-SNAPSHOT.pdf
Can you add a test to show how it should work?
was (Author: wsmoak):
Thanks, Vincent. To try this out I first built Doxia, then the PDF plugin.
Then I edited src/site/pdf.xml to include the version as above.
The result was the first bit of the literal property being used:
$ ls target/site/*.pdf
target/site/apache-continuum-${project.pdf
Can you add a test to show how it should work?
> Ability to use pom properties in pdf.xml
>
>
> Key: MPDF-1
> URL: http://jira.codehaus.org/browse/MPDF-1
> Project: Maven 2.x PDF Plugin
> Issue Type: Wish
> Reporter: Wendy Smoak
>Assignee: Vincent Siveton
>
> I'd like to include the project version number in the filename of the pdf,
> for example, in pdf.xml:
>
--
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: (MPDF-1) Ability to use pom properties in pdf.xml
[
http://jira.codehaus.org/browse/MPDF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175255#action_175255
]
Wendy Smoak commented on MPDF-1:
Thanks, Vincent. To try this out I first built Doxia, then the PDF plugin.
Then I edited src/site/pdf.xml to include the version as above.
The result was the first bit of the literal property being used:
$ ls target/site/*.pdf
target/site/apache-continuum-${project.pdf
Can you add a test to show how it should work?
> Ability to use pom properties in pdf.xml
>
>
> Key: MPDF-1
> URL: http://jira.codehaus.org/browse/MPDF-1
> Project: Maven 2.x PDF Plugin
> Issue Type: Wish
> Reporter: Wendy Smoak
>Assignee: Vincent Siveton
>
> I'd like to include the project version number in the filename of the pdf,
> for example, in pdf.xml:
>
--
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: (MDEPLOY-102) Allow deploy:deploy-file to specify the extension of the artifact
[ http://jira.codehaus.org/browse/MDEPLOY-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=173461#action_173461 ] Wendy Smoak commented on MDEPLOY-102: - Have you tried adding -Dpackaging=zip to the command line? It seems to work for me in a quick test. > Allow deploy:deploy-file to specify the extension of the artifact > - > > Key: MDEPLOY-102 > URL: http://jira.codehaus.org/browse/MDEPLOY-102 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Affects Versions: 2.4 >Reporter: Neil Morrison >Priority: Minor > > We build a zip bundle of files to be deployed as a set. Can deploy these ok > but it always assumes a jar file extension, would like to upload as a zip > file as per Nexus Upload feature -- 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-295) Make the distributionManagement.site.url configurable from the command line
[
http://jira.codehaus.org/browse/MSITE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169907#action_169907
]
Wendy Smoak commented on MSITE-295:
---
Did you try it with the build helper plugin and ${buildNumber} in the url?
Or with another property, and then passing it in with -Dpropname=value on the
command line?
I routinely use ${project.version} in the site url to publish docs for each
version (to /docs/1.0-SNAPSHOT most of the time, then to /docs/1.0/ from the
tag, without changing anything.)
> Make the distributionManagement.site.url configurable from the command line
> ---
>
> Key: MSITE-295
> URL: http://jira.codehaus.org/browse/MSITE-295
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
> Components: site:deploy
>Affects Versions: 2.0-beta-6
>Reporter: Gabriel Falkenberg
>
> It should be possible to override the attribute
> distributionManagement.site.url from the command line like this:
> mvn site:site site:deploy
> -DdistributionManagement.site.url=file:///some/local/or/external/path/
> This would not really be necessary if site:stage worked like it should but is
> needed since it does not.
--
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-4090) Allow attribute based configuration
[
http://jira.codehaus.org/browse/MNG-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MNG-4090.
Resolution: Duplicate
Duplicate of MNG-3397
> Allow attribute based configuration
> ---
>
> Key: MNG-4090
> URL: http://jira.codehaus.org/browse/MNG-4090
> Project: Maven 2
> Issue Type: Bug
>Reporter: Gin-Ting Chen
>
> Currently we do:
> {code}
>
> junit
> junit
> 4.5
> test
>
> {code}
> It would reduce alot of verbosity in xml configurations if we could instead
> do:
> {code}
> scope="test"/>
> {code}
> I understand that we are using xstream and it didn't support attribute based
> xml but now it does so it would be nice to add this feature.
--
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-3004) Allow build lifecycle to execute tasks in parallel
[ http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168891#action_168891 ] Wendy Smoak commented on MNG-3004: -- Does the work on parallel artifact resolution in a single build (MNG-3379) help here? > Allow build lifecycle to execute tasks in parallel > -- > > Key: MNG-3004 > URL: http://jira.codehaus.org/browse/MNG-3004 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build, General, Performance >Affects Versions: 2.0.6 >Reporter: Nigel Magnay > Fix For: 2.2.0-M1 > > Attachments: parallel-builds.patch > > > One of the great advantages with maven over scripted build environments is > that it can calculate the dependencies of the build, and it could execute > items that are independent of each other in parallel. > Unfortunately it currently doesn't do this, which would be a big win over > tools such as 'ant'. It also means that multicore machines have lots of idle > capacity when running a serial build that could be utilised. > I had a quick shot at seeing what might be required. Bear in mind this is the > first time I have looked at maven internally, and I was just trying to feel > my way around and build a POC. I got some of the way there, but my build > threads don't seem to have the correct classpath - I think this is something > to do with plexus / classworlds - but I don't know enough. > It'd be great to get this feature in a future version, or a way of running my > hack (figuring out why in a thread has not the plexus stuff) in the interim. -- 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-4071) Support additional read-only local repositories
[ http://jira.codehaus.org/browse/MNG-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168266#action_168266 ] Wendy Smoak commented on MNG-4071: -- Why did you choose to make /usr/share/maven-repo a local repo? It seems like if it were in remote repo format, you wouldn't need any changes for it to work. > Support additional read-only local repositories > --- > > Key: MNG-4071 > URL: http://jira.codehaus.org/browse/MNG-4071 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-3 > Environment: Debian Linux in particular, any other environment >Reporter: Ludovic Claude >Priority: Minor > > Work is under way at Debian to support Maven as a tool for building packaged > software. > Debian uses a local Maven repository (in /usr/share/maven-repo/) which is > updated by the Debian tools (dpkg, apt-get). This repository is read-only for > the normal user. > It would be great if users could use this repository in addition to their > local repository in ~/.m2/repo, and it would simplify the Debian tooling. > In Debian, when building a package you cannot download anything from the > Internet (to allow repeatable builds), so when packaging a Maven project, the > --offline option is always used. That means that if you try to trick Maven > and use file:///usr/share/maven-repo as a new repository, then it won't work > as Maven believes that it is a remote repository. -- 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: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin
[
http://jira.codehaus.org/browse/MDEPLOY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168247#action_168247
]
Wendy Smoak commented on MDEPLOY-93:
finalName only affects the filename you see in the target directory, not the
remote repo. The naming format in the remote repo is always
$artifactId-$version-$classifier.
> Deploy plugin does not honor modification of final name by assembly plugin
> --
>
> Key: MDEPLOY-93
> URL: http://jira.codehaus.org/browse/MDEPLOY-93
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Thorsten Möller
>
> When using the Maven assembly plugin to create an assembly for a project and
> using "fileName" parameter inside the plugin to change the final name of the
> assembly this new name will not be used by the deploy plugin. The deploy
> plugin always uses the default behavior. The following excerpt from a POM
> illustrates this:
> myGoupID
> myArtifactID
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
>
> src/main/assembly/bin.xml
>
> false
> foo
> gnu
>
>
>
> minimal
> package
>
> single
>
>
>
>
>
>
> With this configuration an assembly named "foo.{tar.gz|zip}" will be created
> in the target folder of the project (note that the artifact is attached
> because the assembly plugin is attached to the package lifecycle phase).
> However, when deploying the project file to the distribution repository it
> will be named "myArtifactId.{tar.gz|zip}", which is the default behavior if
> "finalName" is not specified. Interesting is that in the local repository the
> file name always corresponds to what is specified by "fileName", just for the
> distribution repository the parameter is not honored.
> BTW, the other parameter "appendAssemblyId" is honored correctly, i.e,
> depending on the boolean value the assembly Id will be appended to the name,
> or not.
--
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: (MSANDBOX-45) Ability to use pom properties in pdf.xml
Ability to use pom properties in pdf.xml Key: MSANDBOX-45 URL: http://jira.codehaus.org/browse/MSANDBOX-45 Project: Maven 2.x Sandbox Issue Type: Wish Components: maven-pdf-plugin Reporter: Wendy Smoak I'd like to include the project version number in the filename of the pdf, for example, in pdf.xml: -- 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-3940) Interpolation of environment variables fails on Windows
[
http://jira.codehaus.org/browse/MNG-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159079#action_159079
]
Wendy Smoak commented on MNG-3940:
--
Thanks, Benjamin. :)
I was testing this by adding
${env.PATH} to a pom and then running
mvn help:effective-pom.
On Linux and OS X, the effective pom shows all the directories in the PATH
environment variable. On Windows, it remains literally ${env.PATH}.
However, ${env.M2_HOME} is expanded on all three OSs, so it's not _all_
environment variables on Windows.
> Interpolation of environment variables fails on Windows
> ---
>
> Key: MNG-3940
> URL: http://jira.codehaus.org/browse/MNG-3940
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> {noformat}
> 00:47 wsmoak I can't get ${env.PATH} to be evaluated in the pom... but only
> on Windows. Any ideas?
> 00:47 wsmoak echo %PATH% produces the right stuff. and it works fine with
> Maven 2.0.9 on OS X or linux
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3893) Maven2 is looking for updates on available final artifacts
[ http://jira.codehaus.org/browse/MNG-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157255#action_157255 ] Wendy Smoak commented on MNG-3893: -- Please post the build output that prompted you to open this issue. How did these artifacts get into the repo? (My guess is that it's looking for poms, not the jars.) Another thing to check is your repository update policies. It is possible to configure Maven to check for updates on releases, but it doesn't happen by default. > Maven2 is looking for updates on available final artifacts > -- > > Key: MNG-3893 > URL: http://jira.codehaus.org/browse/MNG-3893 > Project: Maven 2 > Issue Type: Bug > Environment: any >Reporter: Stefan Franke > > Maven2 is looking for updates on available final artifacts, which are > artifacts without a SNAPSHOT version. > If version numbers have any meaning then there must not exist different > artifacts for groupId/artifactId/version. > And if there can be only an unique artifact it is wrong to search for updates. -- 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-3882) Prevent local repository from also being the remote repository
[ http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156061#action_156061 ] Wendy Smoak commented on MNG-3882: -- What values do you want to compare? The local repo is a path, the remote repo is a url. How would Maven be able to detect this? Usually what happens is that a user takes a local repository, copies it to a server and serves it as a remote repo either with a file:// url or by using a web server in front. Less common is dropping a copy of the local repo filesystem into a repository manager -- and this is less of a problem since Archiva at least can repair the metadata. > Prevent local repository from also being the remote repository > -- > > Key: MNG-3882 > URL: http://jira.codehaus.org/browse/MNG-3882 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1 >Reporter: Paul Benedict > > User list shows that the local repository can be specified as a remote > repository. I've confirmed this is true. This is obviously a sore > misconfiguration. Let's check that the values are never equal. -- 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-371) use doxia core snapshot
[ http://jira.codehaus.org/browse/MSITE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155635#action_155635 ] Wendy Smoak commented on MSITE-371: --- Upgrading to a snapshot would block us from releasing the Site plugin, so I wouldn't want to do it unless a Doxia release was expected very soon. If you're happy using snapshots, you can change the doxiaVersion property in the site plugin pom and build the site plugin locally with the later version of Doxia. There are some notes on the wiki about patching plugins and doing an 'internal release' which would be a bit more stable. http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins If you need to embed HTML, you might consider using xdoc for that page instead of apt. > use doxia core snapshot > --- > > Key: MSITE-371 > URL: http://jira.codehaus.org/browse/MSITE-371 > Project: Maven 2.x Site Plugin > Issue Type: Wish > Components: doxia integration >Affects Versions: 2.0-beta-8 >Reporter: Alexandre Vasseur >Priority: Trivial > > When I use maven site plugin 2.0-beta-8-SNAPSHOT I can't get doxia core to > support verbatim snippet as fixed in January 2008 at > http://jira.codehaus.org/browse/DOXIA-142 > Can maven site plugin SNAPSHOT updates its dependencie to a newer doxia core > ie 1.0-beta-1-SNAPSHOT ? > the verbatim snippet support allows for html inclusion directly in apt fie > which would be great for f.e. embedding slideshare and other stuff in maven > generated site -- 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: (MDEPLOY-91) Add option to delete old snapshots from repository during deployment.
[ http://jira.codehaus.org/browse/MDEPLOY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153752#action_153752 ] Wendy Smoak commented on MDEPLOY-91: IMO it's a bit out of scope for the deploy plugin to be removing things. But I have wanted the ability to remove a release from a repo before, and the problem with just deleting stuff is that it breaks the metadata. An "undeploy" plugin maybe? > Add option to delete old snapshots from repository during deployment. > - > > Key: MDEPLOY-91 > URL: http://jira.codehaus.org/browse/MDEPLOY-91 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > > The deploy plugin should be able to delete old snapshots, maybe older than a > certain date, or retain a certain maximum number of builds in the snapshot > repository. This would prevent the need for some of the current repository > maintenance. -- 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: (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 closed MDEPLOY-34. -- Assignee: Wendy Smoak Resolution: Duplicate Closing this as a duplicate of MDEPLOY-74. Even though this is the earlier issue, there is more discussion on the other one. > 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 >Assignee: Wendy Smoak > > 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: (MNG-3762) Relocation not working for plugins
[
http://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152080#action_152080
]
Wendy Smoak commented on MNG-3762:
--
Another example on the user list:
http://www.nabble.com/trouble-relocating-a-plugin-td20195960.html
> Relocation not working for plugins
> --
>
> Key: MNG-3762
> URL: http://jira.codehaus.org/browse/MNG-3762
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix"
>Reporter: Wendy Smoak
>
> As discussed on the user list, the relocation pom for the Jetty plugin does
> not seem to work correctly.
> See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
> To reproduce, create a project from the webapp archetype, and introduce the
> Jetty plugin:
> {noformat}
>
>...
>
>
>org.mortbay.jetty
>maven-jetty-plugin
>7.0.0pre3
>
>
> {noformat}
> Attempting to build the project results in an error:
> {noformat}
> $ mvn install
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building mywebapp Maven Webapp
> [INFO]task-segment: [install]
> [INFO]
>
> Downloading:
> http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] A required plugin was not found: Plugin could not be found -
> check that the goal name is correct: Unable to download the artifact
> from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
>mvn install:install-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
>mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> 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: 1 second
> [INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
> [INFO] Final Memory: 3M/7M
> [INFO]
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3802) test scoped dependencies are being resolved even if tests are skipped
[ http://jira.codehaus.org/browse/MNG-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151926#action_151926 ] Wendy Smoak commented on MNG-3802: -- Building with -Dmaven.test.skip=true fails due to the missing test dependency, but with -Dmaven.test.skip.exec it succeeds. The Surefire docs say skipExec is deprecated and to use skipTests instead, but the behavior is not the same. http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html > test scoped dependencies are being resolved even if tests are skipped > - > > Key: MNG-3802 > URL: http://jira.codehaus.org/browse/MNG-3802 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9 >Reporter: Edwin Punzalan > > I'd think that dependencies with scope=test shouldn't be resolved if tests > are skipped. > To reproduce, try building continuum 1.3-SNAPSHOT with an empty local repo > (or just remove continuum-store:1.3-SNAPSHOT:tests; note the "tests" > classifier) with tests skipped. > When the build reaches continuum-data-management, it will fail saying the > dependency continuum-store:1.3-SNAPSHOT:tests cannot be resolved. -- 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-366) multimodule site stage doesn't work
[ http://jira.codehaus.org/browse/MSITE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151633#action_151633 ] Wendy Smoak commented on MSITE-366: --- What makes it not browseable? If it's incorrect links, is this a duplicate of MSITE-275? > multimodule site stage doesn't work > --- > > Key: MSITE-366 > URL: http://jira.codehaus.org/browse/MSITE-366 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-7 >Reporter: Martijn Dashorst > Attachments: maven.zip > > > Running > mvn site:stage -DstagingDirectory=target/stage > or > mvn site:stage -DstagingDirectory=`pwd`/target/stage > doesn't create a browsable website. See attached minimal multimodule 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: (MCOMPILER-83) add separate configuration for test compiler
[ http://jira.codehaus.org/browse/MCOMPILER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151435#action_151435 ] Wendy Smoak commented on MCOMPILER-83: -- If you bind an execution of the surefire plugin to the integration-test phase, which parameters get used? > add separate configuration for test compiler > > > Key: MCOMPILER-83 > URL: http://jira.codehaus.org/browse/MCOMPILER-83 > Project: Maven 2.x Compiler Plugin > Issue Type: New Feature >Affects Versions: 2.1 > Environment: all >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > > use case: (described in > http://www.nabble.com/compiler-plugin:-separate-test-compiler-configuration-tt20058021.html > ) > * main code is java 1.4 and should remain such for the release > * unit tests are junit 4 based > to address this use case in cli, modify compiler plugin to accept > *testSource* and *testTarget* configuration parameters -- 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: (MSITE-363) Unresolved dependencies
[ http://jira.codehaus.org/browse/MSITE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MSITE-363. - Assignee: Benjamin Bentmann Resolution: Not A Bug > Unresolved dependencies > --- > > Key: MSITE-363 > URL: http://jira.codehaus.org/browse/MSITE-363 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Windows 2003 Server >Reporter: Paul Taylor >Assignee: Benjamin Bentmann > > Hi, > I'm a first-time Maven user, and not really sure if I should be reporting > this here, or asking for support elsewhere. However, I'm trying to build an > installation of DSpace for a Windows environment, and part of the build > process is to create a site installation package with Maven. When I run the > command "mvn package" in the DSpace source directory, it produces the error > trace below. I suspect a dependency is missing on your module repository. > If you could replace the required dependency or suggest a workaround, I'd be > obliged. > Paul Taylor > * > Error Trace > * > C:\temp\DSpace\dspace-1.5.1-release\dspace>mvn package -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] DSpace Addon Modules > [INFO] DSpace XML-UI (Manakin) :: Web Application > [INFO] DSpace LNI :: Web Application > [INFO] DSpace OAI :: Web Application > [INFO] DSpace JSP-UI :: Web Application > [INFO] DSpace SWORD :: Web Application > [INFO] DSpace Assembly and Configuration > [INFO] > > [INFO] Building DSpace Addon Modules > [INFO]task-segment: [package] > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-p > lugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-p > lugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: org.apache.maven.plugins:maven-site-plugin > Reason: POM 'org.apache.maven.plugins:maven-site-plugin' not found in > repository > : Unable to download the artifact from any repository > org.apache.maven.plugins:maven-site-plugin:pom:2.0-beta-6 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > maven.dspace.org/snapshot (http://maven.dspace.org/snapshot) > for project org.apache.maven.plugins:maven-site-plugin > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build > project > for plugin 'org.apache.maven.plugins:maven-site-plugin': POM > 'org.apache.maven.p > lugins:maven-site-plugin' not found in repository: Unable to download the > artifa > ct from any repository > org.apache.maven.plugins:maven-site-plugin:pom:2.0-beta-6 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > maven.dspace.org/snapshot (http://maven.dspace.org/snapshot) > for project org.apache.maven.plugins:maven-site-plugin > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa > ultLifecycleExecutor.java:1291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor > (DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForP > ackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl > eMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:142) > at org
[jira] Issue Comment Edited: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151014#action_151014
]
wsmoak edited comment on MWAR-82 at 10/16/08 10:25 AM:
Comment edited: 2.0 does not have the feature, and I can't
reproduce the problem of getting both WEB-INF/classes and WEB-INF/lib in any
version.
With 2.0 - files in WEB-INF/classes, nothing in WEB-INF/lib
{noformat}
0 Thu Oct 16 08:11:56 MST 2008 META-INF/
221 Thu Oct 16 08:11:54 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/
52 Thu Oct 16 08:11:56 MST 2008 index.jsp
535 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/App.class
215 Thu Oct 16 08:11:56 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/mywebapp/
946 Thu Oct 16 08:11:50 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:11:56 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
With 2.0.1, 2.1-alpha-2 - jar in WEB-INF/lib, nothing in WEB-INF/classes
{noformat}
0 Thu Oct 16 08:12:48 MST 2008 META-INF/
125 Thu Oct 16 08:12:46 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/
52 Thu Oct 16 08:02:02 MST 2008 index.jsp
2208 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/mywebapp.jar
215 Thu Oct 16 08:02:02 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/mywebapp/
948 Thu Oct 16 08:12:40 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:12:46 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
was (Author: wsmoak):
I can reproduce it in 2.0 and it's fixed in 2.0.1 and later versions.
mvn clean install; jar -tvf target/mywebapp.war
With 2.0:
{noformat}
0 Thu Oct 16 08:11:56 MST 2008 META-INF/
221 Thu Oct 16 08:11:54 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/
52 Thu Oct 16 08:11:56 MST 2008 index.jsp
535 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/App.class
215 Thu Oct 16 08:11:56 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/mywebapp/
946 Thu Oct 16 08:11:50 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:11:56 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
With 2.0.1, 2.1-alpha-2:
{noformat}
0 Thu Oct 16 08:12:48 MST 2008 META-INF/
125 Thu Oct 16 08:12:46 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/
52 Thu Oct 16 08:02:02 MST 2008 index.jsp
2208 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/mywebapp.jar
215 Thu Oct 16 08:02:02 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/mywebapp/
948 Thu Oct 16 08:12:40 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:12:46 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
> setting archiveClasses to true create the jar in WEB-INF/lib but does not
> remove WEB-INF/classes
>
>
> Key: MWAR-82
> URL: http://jira.codehaus.org/browse/MWAR-82
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebastien Brunot
>Assignee: Stephane Nicoll
> Fix For: 2.0.1
>
>
> This bug has been explained on the maven users mailing list:
> Hi Sebastien
> It seems to be a bug.
> In the code [1] we have :
> if ( archiveClasses )
> {
> createJarArchive( libDirectory );
> }
> else
> {
> copyDirectoryStructureIfModified( classesDirectory,
> webappClassesDirectory );
> }
> The content of the classes directory is never removed (neither in
> createJarArchive nor somewhere else).
> Can
[jira] Updated: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak updated MWAR-82:
Affects Version/s: 2.0
Fix Version/s: 2.0.1
I can reproduce it in 2.0 and it's fixed in 2.0.1 and later versions.
mvn clean install; jar -tvf target/mywebapp.war
With 2.0:
{noformat}
0 Thu Oct 16 08:11:56 MST 2008 META-INF/
221 Thu Oct 16 08:11:54 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/
0 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/
52 Thu Oct 16 08:11:56 MST 2008 index.jsp
535 Thu Oct 16 08:11:56 MST 2008 WEB-INF/classes/net/wsmoak/App.class
215 Thu Oct 16 08:11:56 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:11:56 MST 2008 META-INF/maven/com.example/mywebapp/
946 Thu Oct 16 08:11:50 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:11:56 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
With 2.0.1, 2.1-alpha-2:
{noformat}
0 Thu Oct 16 08:12:48 MST 2008 META-INF/
125 Thu Oct 16 08:12:46 MST 2008 META-INF/MANIFEST.MF
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/
0 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/
52 Thu Oct 16 08:02:02 MST 2008 index.jsp
2208 Thu Oct 16 08:12:46 MST 2008 WEB-INF/lib/mywebapp.jar
215 Thu Oct 16 08:02:02 MST 2008 WEB-INF/web.xml
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/
0 Thu Oct 16 08:12:48 MST 2008 META-INF/maven/com.example/mywebapp/
948 Thu Oct 16 08:12:40 MST 2008 META-INF/maven/com.example/mywebapp/pom.xml
111 Thu Oct 16 08:12:46 MST 2008
META-INF/maven/com.example/mywebapp/pom.properties
{noformat}
> setting archiveClasses to true create the jar in WEB-INF/lib but does not
> remove WEB-INF/classes
>
>
> Key: MWAR-82
> URL: http://jira.codehaus.org/browse/MWAR-82
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebastien Brunot
>Assignee: Stephane Nicoll
> Fix For: 2.0.1
>
>
> This bug has been explained on the maven users mailing list:
> Hi Sebastien
> It seems to be a bug.
> In the code [1] we have :
> if ( archiveClasses )
> {
> createJarArchive( libDirectory );
> }
> else
> {
> copyDirectoryStructureIfModified( classesDirectory,
> webappClassesDirectory );
> }
> The content of the classes directory is never removed (neither in
> createJarArchive nor somewhere else).
> Can you create an issue please ?
> Thx
> Arnaud
> [1]
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624
> Sebastien Brunot wrote:
> >
> > Hi all,
> >
> > i've got a war project which pom build section contains the following
> > statements:
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> >
> >
> >
> >war
> >
> >
> >true
> >
> >
> >
> >
> >
> > As a result, all the classes and resources from my war project are
> > packaged in a jar that is copied in the WEB-INF/lib directory of the
> > war artifact.
> >
> > But i don't understand why the war artifact still contains copy of the
> > classes and resources under WEB-INF/classes... Does anybody think that
> > i've misconfigured the war plugin ?
> >
> > Thanks for your help,
> >
> > Sebastien
> >
> >
> --
> View this message in context:
> http://www.nabble.com/Configuring-war-plugin-for-using-a-jar-instead-of-WEB-INF-classes-tf2589199s177.html#a7219855
> Sent from the Maven - Users mailing list archive at Nabble.com.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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-213) upgrade site archetype for 2.0-alpha-5
[ http://jira.codehaus.org/browse/ARCHETYPE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150605#action_150605 ] Wendy Smoak commented on ARCHETYPE-213: --- In the 1.0 archetype, the project info reports were generated but not linked on the menu. Consider adding the project info reports to the menu by default. > upgrade site archetype for 2.0-alpha-5 > -- > > Key: ARCHETYPE-213 > URL: http://jira.codehaus.org/browse/ARCHETYPE-213 > Project: Maven Archetype > Issue Type: Sub-task >Reporter: Raphaël Piéroni > Fix For: 2.0-alpha-5 > > > partial archetype -- 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: (MAVEN-1334) Obfuscation plugin
[ http://jira.codehaus.org/browse/MAVEN-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149900#action_149900 ] Wendy Smoak commented on MAVEN-1334: If it's closely tied to Proguard, that project might agree to host the plugin. If that doesn't work, you could either start a separate Sourceforge project just for this plugin, or a maven2-plugins project to host any plugins whose licenses prevent them being at ASF or Codehaus. > Obfuscation plugin > -- > > Key: MAVEN-1334 > URL: http://jira.codehaus.org/browse/MAVEN-1334 > Project: Maven 1 > Issue Type: New Feature >Affects Versions: 1.1-beta-2 >Reporter: Archimedes Trajano > Attachments: obfuscator.zip > > > This is the initial release of a plugin for obfuscating and shrinking code > using jarg -- 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-3777) ActiveByDefault does not work properly
[ http://jira.codehaus.org/browse/MNG-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149450#action_149450 ] Wendy Smoak commented on MNG-3777: -- What happens if you enable the first profile with -Penv-dev instead, is env-prod still active? I would not use activeByDefault, and instead activate env-prod on the *absence* of the env property with !env > ActiveByDefault does not work properly > -- > > Key: MNG-3777 > URL: http://jira.codehaus.org/browse/MNG-3777 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.8 >Reporter: Christopher Roland B. Basmayor > > I've been working for profiles and it appears that the configuration below > does not work too well. Profile env-prod is invoked even when the property > 'env' with value 'dev' is provided. > > > env-dev > > > env > dev > > > > [...] > > > > env-prod > > true > > > [...] > > > -- 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: (MASSEMBLY-358) where should I get the 2.2-beta-3 or snapshot of the maven-assembly-plugin ?
[ http://jira.codehaus.org/browse/MASSEMBLY-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149149#action_149149 ] wsmoak edited comment on MASSEMBLY-358 at 9/26/08 8:21 PM: Please ask on the dev list if you need help using a snapshot [1] or building the plugin from source. You can find subscription info on http://maven.apache.org/mail-lists.html . [1] http://maven.apache.org/guides/development/guide-testing-development-plugins.html was (Author: wsmoak): Please ask on the dev list if you need help using a snapshot or building the plugin from source. You can find subscription info on http://maven.apache.org/mail-lists.html . > where should I get the 2.2-beta-3 or snapshot of the maven-assembly-plugin ? > > > Key: MASSEMBLY-358 > URL: http://jira.codehaus.org/browse/MASSEMBLY-358 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2-beta-2 > Environment: unix >Reporter: Michael Meng >Assignee: Wendy Smoak >Priority: Critical > > I got a error of "appxml attribute is required" while using the format "ear". > in MASSEMBLY-345, it says fixed in 2.2-beta-3 > How could I ge the 2.2-beta-3 or the snapshot ? > 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] Closed: (MASSEMBLY-358) where should I get the 2.2-beta-3 or snapshot of the maven-assembly-plugin ?
[ http://jira.codehaus.org/browse/MASSEMBLY-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MASSEMBLY-358. - Assignee: Wendy Smoak Resolution: Not A Bug Please ask on the dev list if you need help using a snapshot or building the plugin from source. You can find subscription info on http://maven.apache.org/mail-lists.html . > where should I get the 2.2-beta-3 or snapshot of the maven-assembly-plugin ? > > > Key: MASSEMBLY-358 > URL: http://jira.codehaus.org/browse/MASSEMBLY-358 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2-beta-2 > Environment: unix >Reporter: Michael Meng >Assignee: Wendy Smoak >Priority: Critical > > I got a error of "appxml attribute is required" while using the format "ear". > in MASSEMBLY-345, it says fixed in 2.2-beta-3 > How could I ge the 2.2-beta-3 or the snapshot ? > 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] Commented: (MWAR-170) NPE in WebappStructure, Line 109
[ http://jira.codehaus.org/browse/MWAR-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148901#action_148901 ] Wendy Smoak commented on MWAR-170: -- Does it happen with the 2.1-alpha-2 release? > NPE in WebappStructure, Line 109 > > > Key: MWAR-170 > URL: http://jira.codehaus.org/browse/MWAR-170 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: 2.1-beta-1-SNAPSHOT > 2.1-alpha-2-SNAPSHOT >Reporter: Corridor Software Developer > > Both of these versions (see environment) introduce a NullPointerException not > exhibited in the current release: > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > 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) > [INFO] > > NPE's are usually self-explanatory, but if you need a pom or test case > project, let me know... -- 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-203) resources file don't copy to the proper location
[ http://jira.codehaus.org/browse/ARCHETYPE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148900#action_148900 ] Wendy Smoak commented on ARCHETYPE-203: --- Possible duplicate of ARCHETYPE-65 (Restore the ability to "package" non-Java resources) I commented there to see whether it was intentional to leave the archetype:create behavior alone and only fix it in the new archetype:generate goal. > resources file don't copy to the proper location > - > > Key: ARCHETYPE-203 > URL: http://jira.codehaus.org/browse/ARCHETYPE-203 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes > Environment: Win XP > Eclipse > Version: 3.4.0 > Build id: I20080617-2000 >Reporter: Ching Yi, Chan > > I make an archetype plugin. > when I use maven in command line my resources file will locate as > package structure with archetype:generate but archetype:create will not. > I test it in eclipse with m2e plugin, files in the resources are all in > the root directory of resources. how do I make it locate as package > structure ? -- 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-65) Restore the ability to "package" non-Java resources
[ http://jira.codehaus.org/browse/ARCHETYPE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148899#action_148899 ] Wendy Smoak commented on ARCHETYPE-65: -- How was this addressed? ARCHETYPE-203 implies that it was not fixed for archetype:create, but that it does work with archetype:generate. > Restore the ability to "package" non-Java resources > --- > > Key: ARCHETYPE-65 > URL: http://jira.codehaus.org/browse/ARCHETYPE-65 > Project: Maven Archetype > Issue Type: Bug > Components: Creator >Affects Versions: 1.0-alpha-4 >Reporter: Wendy Smoak > Fix For: 2.0-alpha-1 > > Attachments: archetype-resource-package-interpolation.patch > > > Some time ago, the Archetype plugin lost the ability to "package" non-Java > resources. The change was committed in April '06, so it would have first > appeared in 1.0-alpha-4. > http://mail-archives.apache.org/mod_mbox/maven-commits/200604.mbox/[EMAIL > PROTECTED] > Prior to this change, you could put non-Java files in the element, > for example > src/main/resources/App.properties >and > mvn archetype:create ... -DgroupId=com.example >would result in > src/main/resources/com/example/App.properties > Now, you get an error saying: "Template 'App.properties' is not in directory > src/main/java." > One way to fix this is to roll back the changes from lines 682-705 in r390971: > http://svn.apache.org/viewvc/maven/archetype/trunk/maven-archetype/maven-archetype-core/src/main/java/org/apache/maven/archetype/DefaultArchetype.java?r1=390965&r2=390971&diff_format=h > However if I'm reading the changes right, that will break the ability to have > "sub packages". > Maybe we need to leave alone, and have both and > ? > There is an example project (based on the quickstart archetype) in the > sandbox. It includes App.properties as described above. > http://svn.apache.org/repos/asf/maven/sandbox/trunk/archetype/maven-archetype-quickstart/ -- 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-3762) Relocation not working for plugins
Relocation not working for plugins
--
Key: MNG-3762
URL: http://jira.codehaus.org/browse/MNG-3762
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Maven version: 2.0.9
Java version: 1.5.0_13
OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix"
Reporter: Wendy Smoak
As discussed on the user list, the relocation pom for the Jetty plugin does not
seem to work correctly.
See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
To reproduce, create a project from the webapp archetype, and introduce the
Jetty plugin:
{noformat}
...
org.mortbay.jetty
maven-jetty-plugin
7.0.0pre3
{noformat}
Attempting to build the project results in an error:
{noformat}
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building mywebapp Maven Webapp
[INFO]task-segment: [install]
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] A required plugin was not found: Plugin could not be found -
check that the goal name is correct: Unable to download the artifact
from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
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: 1 second
[INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
[INFO] Final Memory: 3M/7M
[INFO]
{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] Closed: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3738. Resolution: Not A Bug > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- 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] Reopened: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MNG-3738: -- If you're going to comment on it, you might as well fix it-- I noticed the incorrect resolution, and decided to leave it alone to avoid extra email. There is no fix-for version, so it would not have appeared in any release notes. > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- 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: (WAGON-86) add timeout to HttpUtils/wagon
[ http://jira.codehaus.org/browse/WAGON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146624#action_146624 ] Wendy Smoak commented on WAGON-86: -- >From #maven: How would I specify the connection timeout for maven artifact downloads (as per http://jira.codehaus.org/browse/WAGON-86) brett: via in the element of settings.xml, but that won't be available until Maven 2.1.0 is out > add timeout to HttpUtils/wagon > -- > > Key: WAGON-86 > URL: http://jira.codehaus.org/browse/WAGON-86 > Project: Maven Wagon > Issue Type: Improvement >Reporter: Brett Porter >Assignee: nicolas de loof >Priority: Minor > Fix For: 1.0-beta-3 > > Attachments: WAGON-86.patch, WAGON-86.patch > > > in httputils (and heavyweight http wagon), add a configurable timeout for > requests. -- 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-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3738. Assignee: Wendy Smoak Resolution: Fixed > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- 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-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146620#action_146620 ] Wendy Smoak commented on MNG-3738: -- The user list would be a better place to ask questions like this. You can find subscription info on this page: http://maven.apache.org/mail-lists.html > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- 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: (MNGSITE-65) Minor - the sidebar maven ant tasks link is incorrect
[ http://jira.codehaus.org/browse/MNGSITE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146324#action_146324 ] Wendy Smoak commented on MNGSITE-65: According to the pom, the docs are published at: http://maven.apache.org/maven-ant-tasks/ >From there, Project Reports on the left hand menu -> Javadoc > Minor - the sidebar maven ant tasks link is incorrect > - > > Key: MNGSITE-65 > URL: http://jira.codehaus.org/browse/MNGSITE-65 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Jeremy Hanna > > Currently the link to maven ant tasks is: > http://maven.apache.org/ant-tasks/index.html > which gives an error. > It should be: > http://maven.apache.org/ant-tasks.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: (MNGSITE-63) Multiple broken mirror links
[ http://jira.codehaus.org/browse/MNGSITE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146229#action_146229 ] Wendy Smoak commented on MNGSITE-63: Since we don't have any control over these, a thought is to move the list of mirrors to the wiki and let users maintain it. Then the Maven docs can concentrate on how to use a mirror without suggesting any in particular. > Multiple broken mirror links > > > Key: MNGSITE-63 > URL: http://jira.codehaus.org/browse/MNGSITE-63 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Matthew Beermann >Priority: Critical > > http://maven.apache.org/guides/mini/guide-mirror-settings.html > Several of the mirrors listed on this page no longer appear to exist, meaning > that anyone who uses the provided settings file is in for a nasty surprise. > :( Specifically... > http://ibiblio.lsu.edu/main/pub/packages/maven2 > http://maven.sateh.com/repository > http://ftp.ggi-project.org/pub/packages/maven2 -- 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: (MASSEMBLY-342) NPE when filtering fileSet
[
http://jira.codehaus.org/browse/MASSEMBLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145919#action_145919
]
Wendy Smoak commented on MASSEMBLY-342:
---
That means this fix will require a release of Maven Shared -- unless someone is
planning one soon, we might want to move this issue out to beta-4 to avoid
delaying beta-3.
> NPE when filtering fileSet
> --
>
> Key: MASSEMBLY-342
> URL: http://jira.codehaus.org/browse/MASSEMBLY-342
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Environment: Windows XP, cygwin, Java 1.5.0.9
>Reporter: Peter Verhás
>Priority: Critical
> Fix For: 2.2-beta-3
>
> Attachments: massembly-342.txt
>
>
> I get NPE when I specify filtering in an assembly descriptor. The
> {{src/assembly/bin.xml}} file (referenced by the {{pom.xml}} as an assembly
> descriptor) is the following:
> {code}
>
> bin
>
> zip
>
> false
>
>
> lib
>
>
>
>
> target
>
>
> *.jar
>
>
>
> true
>
> INSTALL*
> README*
> LICENSE*
> NOTICE*
>
>
>
>
> {code}
> This causes
> {code}
> $ mvn -e assembly:assembly
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'assembly'.
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building Unnamed - verhas.com:isoapui8583:jar:1.0.0
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> Downloading:
> http://repo1.maven.org/maven2/xmlbeans/xbean/2.3.0-trunk-patched/xbean-2.3.0-trunk-patched.pom
> Downloading:
> http://repo1.maven.org/maven2/groovy/groovy-all/1.5.2/groovy-all-1.5.2.pom
> Downloading:
> http://repo1.maven.org/maven2/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.pom
> Downloading:
> http://repo1.maven.org/maven2/cweb-extser/cweb-extser/0.1-b2-dev/cweb-extser-0.1-b2-dev.pom
> Downloading:
> http://repo1.maven.org/maven2/jPOS/jpos/1.6.2-r2626/jpos-1.6.2-r2626.pom
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\surefire-reports
> ---
> T E S T S
> ---
> Running com.verhas.soapui.jpos.TestServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec
> Running com.verhas.soapui.jpos.TestClient
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
> Running com.verhas.soapui.jpos.TestClientServer
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Running com.verhas.soapui.jpos.TestConstants
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [jar:jar]
> [INFO] Building jar:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0.jar
> [INFO] [assembly:assembly]
> [INFO] Reading assembly descriptor: src/assembly/doc.xml
> [INFO] Reading assembly descriptor: src/assembly/bin.xml
> [INFO] Reading assembly descriptor: src/assembly/src.xml
> [INFO] Building zip:
> p:\projects\BASE24-soapui\BICISO-SOAPUI\target\isoapui8583-1.0.0-doc.zip
> [INFO]
>
> [ERROR] FATAL ER
[jira] Closed: (ARCHETYPE-199) Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed ARCHETYPE-199. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 Fixed in r688437. Removed Struts, Shale and MyFaces snapshots from the Archetype catalog. Only released archetypes should be listed in the catalog so that the released plugin does not depend on unstable snapshots. > Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes > > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > Fix For: 2.0-alpha-4 > > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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-199) Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated ARCHETYPE-199: -- Summary: Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes (was: Missing archetypes for Struts2) 'mvn archetype:generate' tries to download 2.0.9-SNAPSHOT of the Struts 2 blank archetype. A released version of a Maven plugin should not have snapshot dependencies. (The Struts archetypes have not been officially released and should not be in the list the Archetype plugin presents to users.) > Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes > > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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: (MWAR-159) Filtering deployments descriptors (web.xml)
[ http://jira.codehaus.org/browse/MWAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145121#action_145121 ] Wendy Smoak commented on MWAR-159: -- I think this should be 'filterDeploymentDescriptors' not 'filtering...' (to match other params like 'archiveClasses' and 'attachClasses'). Does it need to be plural? (Is there ever more than one deployment descriptor)? I didn't see any documentation in r659214, a usage example or faq would be good if it wasn't added already. > Filtering deployments descriptors (web.xml) > --- > > Key: MWAR-159 > URL: http://jira.codehaus.org/browse/MWAR-159 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.1-alpha-1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.1-alpha-2 > > > to preserve backward compatibility this option will be off by default. -- 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-49) Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo
[ http://jira.codehaus.org/browse/MDEPLOY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MDEPLOY-49: --- Fix Version/s: (was: 2.5) unset fix-for version > Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo > - > > Key: MDEPLOY-49 > URL: http://jira.codehaus.org/browse/MDEPLOY-49 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Geoffrey De Smet >Priority: Minor > > The deploy plugin supports deploying from a local file with > deploy:deploy-file, > but it would be easier if it also supports fetching that file from another > remote repo. > Now we're using inhouse scripts to do this (which have problems). > Archiva will support proxying the remote repo, but some orginazations don't > want to automate adding artifacts to their release repo (only to their > snapshot repo). -- 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: (MASSEMBLY-32) Provide installer support like NSIS or InnoSetup
[ http://jira.codehaus.org/browse/MASSEMBLY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145114#action_145114 ] Wendy Smoak commented on MASSEMBLY-32: -- This is very old, but it has a lot of votes. Does this really belong *in* the assembly plugin? There is now a NSIS plugin in the Mojo sandbox, and I assume plugins could be written to wrap the other tools as well. > Provide installer support like NSIS or InnoSetup > > > Key: MASSEMBLY-32 > URL: http://jira.codehaus.org/browse/MASSEMBLY-32 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Vincent Siveton > Fix For: 2.3-beta-1 > > Attachments: MASSEMBLY-32.patch, maven-assembly-plugin.zip, > MNG-1643.diff, MNG-1643.diff, plexus-installer.diff > > > Add the support of installer compiler like NSIS or InnoSetup. > See the thread: > http://www.nabble.com/m2-developers-rfc%3A-The-assembly-plugin-ans-thirdparty-installation-builders-%28REPOST%29-t57.html#a1546470 -- 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-199) Missing archetypes for Struts2
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144811#action_144811 ] Wendy Smoak commented on ARCHETYPE-199: --- I'm not sure where the list in the archetype plugin is coming from, but I removed any archetype that was coming from the ASF snapshot repo from the wiki page. http://docs.codehaus.org/display/MAVENUSER/Archetypes+List > Missing archetypes for Struts2 > -- > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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-51) Prompt for username and password if not supplied
[ http://jira.codehaus.org/browse/MDEPLOY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MDEPLOY-51: --- Summary: Prompt for username and password if not supplied (was: Allow username and password to be specified on the command line) > Prompt for username and password if not supplied > > > Key: MDEPLOY-51 > URL: http://jira.codehaus.org/browse/MDEPLOY-51 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Reporter: Paul Gier > > Allow the user to supply a user name password for a remote server when the > deploy goal is called. Currently you have to add the repository username and > password to the server.xml file. It would be helpful if the user could be > prompted for a username and password on the command line. The password > should be hidden when it is entered. -- 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: (MDEPLOY-51) Allow username and password to be specified on the command line
[ http://jira.codehaus.org/browse/MDEPLOY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144765#action_144765 ] Wendy Smoak commented on MDEPLOY-51: There may be code in the gpg plugin that can be reused. It prompts for the gpg passphrase and masks the input. > Allow username and password to be specified on the command line > --- > > Key: MDEPLOY-51 > URL: http://jira.codehaus.org/browse/MDEPLOY-51 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Reporter: Paul Gier > > Allow the user to supply a user name password for a remote server when the > deploy goal is called. Currently you have to add the repository username and > password to the server.xml file. It would be helpful if the user could be > prompted for a username and password on the command line. The password > should be hidden when it is entered. -- 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: (MDEPLOY-49) Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo
[ http://jira.codehaus.org/browse/MDEPLOY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144368#action_144368 ] Wendy Smoak commented on MDEPLOY-49: The Stage plugin is intended to help with copying files from one repo to another, though right now it only supports http -> scp copies. I don't see this being added to the deploy plugin. > Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo > - > > Key: MDEPLOY-49 > URL: http://jira.codehaus.org/browse/MDEPLOY-49 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Geoffrey De Smet >Priority: Minor > > The deploy plugin supports deploying from a local file with > deploy:deploy-file, > but it would be easier if it also supports fetching that file from another > remote repo. > Now we're using inhouse scripts to do this (which have problems). > Archiva will support proxying the remote repo, but some orginazations don't > want to automate adding artifacts to their release repo (only to their > snapshot repo). -- 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-3622) upgrade to wagon 1.0-beta-4
[ http://jira.codehaus.org/browse/MNG-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MNG-3622: - Summary: upgrade to wagon 1.0-beta-4 (was: upgrade to wagon beta-3) > upgrade to wagon 1.0-beta-4 > --- > > Key: MNG-3622 > URL: http://jira.codehaus.org/browse/MNG-3622 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.0.10 > > > I am scheduling this for 2.1-alpha-1, but I will also look into the > possibility of including it in 2.0.10 after consulting the dev list -- 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-346) Allow site.xml to be optional
[ http://jira.codehaus.org/browse/MSITE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143796#action_143796 ] Wendy Smoak commented on MSITE-346: --- Seems to be related to this thread: http://www.nabble.com/Site-Plugin%3A-Only-static-content---is-it-possible--ts18747971.html I had no problems removing site.xml. Is that really the problem here? What I did find is that I needed to configure the maven-project-info-reports plugin to not generate any reports, and possibly create a new site skin that doesn't have any css or images. > Allow site.xml to be optional > - > > Key: MSITE-346 > URL: http://jira.codehaus.org/browse/MSITE-346 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Reporter: Paul Benedict > > I want to use the Maven Site Plugin to produce, package, and deploy a typical > Apache-hosted website. I do not need any content generation or skinning. > Everything that I need would reside in /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] Issue Comment Edited: (MNG-3665) The uniqueVersion property seems to have no affect
[ http://jira.codehaus.org/browse/MNG-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141886#action_141886 ] wsmoak edited comment on MNG-3665 at 7/15/08 4:40 PM: --- The uniqueVersion element only affects snapshots, meaning it will only come into play if your version number ends in -SNAPSHOT. In that case, in the remote repo you will get either myproject-2.1.0-SNAPSHOT.jar if uniqueVersion is set to false, or myproject-2.1.0-20080715.174936-1.jar if not (the default). It does not affect the local repo, which always has non-unique filenames. It's in the model for both and because if you only define , Maven will deploy both snapshots and releases there. was (Author: wsmoak): The uniqueVersion element only affects snapshots, meaning it will only come into play if your version number ends in -SNAPSHOT. In that case, in the remote repo you will get either myproject-2.1.0-SNAPSHOT.jar if uniqueVersion is set to false, or myproject-2.1.0-20080715.174936-1.jar if not (the default). It does not affect the local repo. It's in the model for both because if you only define , Maven will deploy both snapshots and releases there. > The uniqueVersion property seems to have no affect > -- > > Key: MNG-3665 > URL: http://jira.codehaus.org/browse/MNG-3665 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7, 2.0.9 > Environment: Windows, mvn 2.0.9 >Reporter: Damon Rand > > I'm trying a very basic pom.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.alfresco.crowd > alfresco-crowd-security > Maven Alfresco Crowd Security AMP > 0.2.2 > Test AMP project > > > > ai-public-releases-secure3 > > > dav:https://forge.amnesty.org/maven/repos/public-releases > > > true > > > > But as you can see the uniqueVersion is not being generated on my filenames.. > D:\workspaces\crowd\test2>mvn deploy > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Alfresco Crowd Security AMP > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] No sources to compile > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] No sources to compile > [INFO] [surefire:test] > [INFO] No tests to run. > [INFO] [jar:jar] > [WARNING] JAR will be empty - no content was marked for inclusion! > [INFO] Building jar: > D:\workspaces\crowd\test2\target\alfresco-crowd-security-0. > 2.2.jar > [INFO] [install:install] > [INFO] Installing > D:\workspaces\crowd\test2\target\alfresco-crowd-security-0.2.2 > .jar to > D:\profiles\drand\.m2\repository\org\alfresco\crowd\alfresco-crowd-secur > ity\0.2.2\alfresco-crowd-security-0.2.2.jar > [INFO] [deploy:deploy] > altDeploymentRepository = null > WAGON_VERSION: 1.0-beta-2 > Uploading: > https://forge.amnesty.org/maven/repos/public-releases/org/alfresco/cr > owd/alfresco-crowd-security/0.2.2/alfresco-crowd-security-0.2.2.jar > [INFO] Uploading project information for alfresco-crowd-security 0.2.2 > [INFO] Retrieving previous metadata from ai-public-releases-secure3 > [INFO] Uploading repository metadata for: 'artifact > org.alfresco.crowd:alfresco- > crowd-security' > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 12 seconds > [INFO] Finished at: Tue Jul 15 17:41:07 BST 2008 > [INFO] Final Memory: 9M/16M > [INFO] > > D:\workspaces\crowd\test2> -- 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-3665) The uniqueVersion property seems to have no affect
[ http://jira.codehaus.org/browse/MNG-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141886#action_141886 ] Wendy Smoak commented on MNG-3665: -- The uniqueVersion element only affects snapshots, meaning it will only come into play if your version number ends in -SNAPSHOT. In that case, in the remote repo you will get either myproject-2.1.0-SNAPSHOT.jar if uniqueVersion is set to false, or myproject-2.1.0-20080715.174936-1.jar if not (the default). It does not affect the local repo. It's in the model for both because if you only define , Maven will deploy both snapshots and releases there. > The uniqueVersion property seems to have no affect > -- > > Key: MNG-3665 > URL: http://jira.codehaus.org/browse/MNG-3665 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7, 2.0.9 > Environment: Windows, mvn 2.0.9 >Reporter: Damon Rand > > I'm trying a very basic pom.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.alfresco.crowd > alfresco-crowd-security > Maven Alfresco Crowd Security AMP > 0.2.2 > Test AMP project > > > > ai-public-releases-secure3 > > > dav:https://forge.amnesty.org/maven/repos/public-releases > > > true > > > > But as you can see the uniqueVersion is not being generated on my filenames.. > D:\workspaces\crowd\test2>mvn deploy > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Alfresco Crowd Security AMP > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] No sources to compile > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] No sources to compile > [INFO] [surefire:test] > [INFO] No tests to run. > [INFO] [jar:jar] > [WARNING] JAR will be empty - no content was marked for inclusion! > [INFO] Building jar: > D:\workspaces\crowd\test2\target\alfresco-crowd-security-0. > 2.2.jar > [INFO] [install:install] > [INFO] Installing > D:\workspaces\crowd\test2\target\alfresco-crowd-security-0.2.2 > .jar to > D:\profiles\drand\.m2\repository\org\alfresco\crowd\alfresco-crowd-secur > ity\0.2.2\alfresco-crowd-security-0.2.2.jar > [INFO] [deploy:deploy] > altDeploymentRepository = null > WAGON_VERSION: 1.0-beta-2 > Uploading: > https://forge.amnesty.org/maven/repos/public-releases/org/alfresco/cr > owd/alfresco-crowd-security/0.2.2/alfresco-crowd-security-0.2.2.jar > [INFO] Uploading project information for alfresco-crowd-security 0.2.2 > [INFO] Retrieving previous metadata from ai-public-releases-secure3 > [INFO] Uploading repository metadata for: 'artifact > org.alfresco.crowd:alfresco- > crowd-security' > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 12 seconds > [INFO] Finished at: Tue Jul 15 17:41:07 BST 2008 > [INFO] Final Memory: 9M/16M > [INFO] > > D:\workspaces\crowd\test2> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
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 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
