Re: [VOTE] maven-dependency-plugin 2.0-alpha-3
+1 Dan On Saturday 17 March 2007 23:31, Brian E. Fox wrote: > I'd like to release maven-dependency-plugin:2.0-alpha-3 > > Tag: > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-pl >ug in-2.0-alpha-3/ > > Staged at: > http://people.apache.org/~brianf/staging-repository > > Changes: > This release adds 2 new goals: > dependency:analyze -> this executes the maven-dependency-analyzer > shared component to look for problems with dependencies. > Dependency:analyze-dep-mgt -> this compares the resolved dependencies > with the dependencyManagement section to identify mismatches. This is > intended to help people identify potential issues before upgrading to > 2.0.6 (with the MNG-1577 patch). It will also be useful to find out > where projects are explicitly overriding dependencyManagement. > > This vote is dependent on the vote for maven-dependency-analyzer > succeeding. > > Vote is open for 72 hours. > > +1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Merge 2.1-lifecycle-refactor branch back to maven trunk
very cool. +1 Milos On 3/20/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: +1 To be able to order correctly is a big improvement. Also very cool is that we can now query and inspect what will happens before it executes. One more step of providing declarative outputs for plugins and we will know everything that could happen which will make IDE integration very awesome. Nice work. Jason. On 16 Mar 07, at 12:51 PM 16 Mar 07, John Casey wrote: > Hi everyone, > > I've performed a fairly significant refactoring of the lifecycle > executor on > the 2.1-lifecycle-refactor branch. The changes allow Maven to > construct a > build plan before execution begins in earnest, which contains all > of the > mojos and their configurations and is then rendered to a List for > iteration > and execution. > > This opens up a whole new world of possibility for controlling > builds, not > to mention build-process debugging and discovery. > > I've run the integration tests on this branch, and it seems that > everything > is working well. I'd like to merge this branch back to trunk, but > since it's > such a large refactor, I thought it appropriate to vote on it > first, in an > effort to help us maintain a stable trunk. > > I've parked binaries, javadocs (of maven-core, where the big > changes are), > and two design PNG images out here: > > http://people.apache.org/~jdcasey/maven-drops/2.1-lifecycle-refactor > > Also, if you want to see the new build plan in action, install the > lifecycle > plugin: > > http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven- > lifecycle-plugin > > and run the following command with the binaries above: > > mvn lifecycle:build-plan -Dtasks=clean,install > > If you'd like to see the configurations for the mojos, use this: > > mvn lifecycle:build-plan -Dtasks=clean,install -DextendedInfo=true > > > Please peruse and let me know what you think. I'll give it 72h; > please vote > +1/+0/-1. > > Here's my +1. > > Thanks, > > John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-enforcer-plugin
Just throwing this out there... but why not just use Jexl to allow expression like "mavenVersion == 1.2" to be evaluated? I just saw the table of range to meaning and this just popped into my head... like why do you need some extra syntax when you could just evaluate an expression? --jason On Mar 19, 2007, at 9:04 PM, Brian E. Fox wrote: There is a new plugin that I'd like to get some feedback on, particularly on non-windows os's and the unit tests. The maven-enforcer-plugin picks up where leaves off and allows control over the maven, jdk and os versions of a build. This plugin was initially conceived here: http://www.nabble.com/Control-of-maven-using-prerequisites- tf3231437s177 .html#a8979318 And here: http://www.nabble.com/Why-is-prerequisites-not-inherited-- tf3236197s177. html#a9016296 1.0-alpha-1-SNAPSHOT is deployed and the site is here: http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so give it a little bit to completely update) If all goes well and no major issues are uncovered, then I think it's ready for staging and a vote. Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-enforcer-plugin
Seems a wee bit odd that you have "enforcer:enforce" which handles maven version and java version, then "enforcer:os" which handles os stuff. I'd rather have enforcer:require-maven, enforcer:require- java, enforcer:require-os, * I'm also not keen on the version range muck... but I guess its more flexible that the 1.0+ and 1.0* stuff I was using. Still though the version range specification never really felt natural to me ;-) --jason On Mar 19, 2007, at 9:04 PM, Brian E. Fox wrote: There is a new plugin that I'd like to get some feedback on, particularly on non-windows os's and the unit tests. The maven-enforcer-plugin picks up where leaves off and allows control over the maven, jdk and os versions of a build. This plugin was initially conceived here: http://www.nabble.com/Control-of-maven-using-prerequisites- tf3231437s177 .html#a8979318 And here: http://www.nabble.com/Why-is-prerequisites-not-inherited-- tf3236197s177. html#a9016296 1.0-alpha-1-SNAPSHOT is deployed and the site is here: http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so give it a little bit to completely update) If all goes well and no major issues are uncovered, then I think it's ready for staging and a vote. Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] maven-dependency-plugin 2.0-alpha-3
Just need one more PMC -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 9:40 PM To: Maven Developers List Subject: Re: [VOTE] maven-dependency-plugin 2.0-alpha-3 This looks really nice. It gets my enthusiastic +1. :-) Thanks, john On 3/17/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > I'd like to release maven-dependency-plugin:2.0-alpha-3 > > Tag: > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug > in-2.0-alpha-3/ > > Staged at: > http://people.apache.org/~brianf/staging-repository > > Changes: > This release adds 2 new goals: > dependency:analyze -> this executes the maven-dependency-analyzer shared > component to look for problems with dependencies. > Dependency:analyze-dep-mgt -> this compares the resolved dependencies > with the dependencyManagement section to identify mismatches. This is > intended to help people identify potential issues before upgrading to > 2.0.6 (with the MNG-1577 patch). It will also be useful to find out > where projects are explicitly overriding dependencyManagement. > > This vote is dependent on the vote for maven-dependency-analyzer > succeeding. > > Vote is open for 72 hours. > > +1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-enforcer-plugin
There is a new plugin that I'd like to get some feedback on, particularly on non-windows os's and the unit tests. The maven-enforcer-plugin picks up where leaves off and allows control over the maven, jdk and os versions of a build. This plugin was initially conceived here: http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177 .html#a8979318 And here: http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177. html#a9016296 1.0-alpha-1-SNAPSHOT is deployed and the site is here: http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so give it a little bit to completely update) If all goes well and no major issues are uncovered, then I think it's ready for staging and a vote. Thanks, Brian
Re: Logging reform for 2.0.6?
On 19 Mar 07, at 10:00 PM 19 Mar 07, Jason Dillon wrote: Aight... I'm happy for it to be in 2.0.7. Not sure I have time to patch it into 2.0.6... though in many cases simply changing log.info to log.debug should work ;-) If you like I can look into the patches for inclusion into 2.0.7. Cool. That would be spiffy. Jason. --jason On Mar 19, 2007, at 6:04 PM, Jason van Zyl wrote: On 19 Mar 07, at 8:15 PM 19 Mar 07, Jason Dillon wrote: Any chance that the logging reform documented here will get into 2.0.6? http://jira.codehaus.org/browse/MNG-2823 Nope, too late. I'll schedule it for 2.0.7. I'm working on the last couple issues, and then it's out the door. Unless you patch it, it won't go in. I'm already a fews days over the 4 week window. Jason. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging reform for 2.0.6?
Aight... I'm happy for it to be in 2.0.7. Not sure I have time to patch it into 2.0.6... though in many cases simply changing log.info to log.debug should work ;-) If you like I can look into the patches for inclusion into 2.0.7. --jason On Mar 19, 2007, at 6:04 PM, Jason van Zyl wrote: On 19 Mar 07, at 8:15 PM 19 Mar 07, Jason Dillon wrote: Any chance that the logging reform documented here will get into 2.0.6? http://jira.codehaus.org/browse/MNG-2823 Nope, too late. I'll schedule it for 2.0.7. I'm working on the last couple issues, and then it's out the door. Unless you patch it, it won't go in. I'm already a fews days over the 4 week window. Jason. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.0.6 update
Hi, So just to recap where we are with 2.0.6. We have a couple issues left, I'm still converting some proprietary builds into ITs so that we can use them, I'm also using one that Jorg put together in an issue. MNG-1577 will go in, Torsten is cleaning up the Minijar plugin for us so that we can hide plexus-utils in the release and then I think we're ready to go. Probably another few days. After 2.0.6 I intend to take another pass at the ITs and do the invoking/verification decoupling in the Verifier, merge all our invoker and verification plugins/tools, enable an embedded/forking invoker (using one of the 5 we have) and wire it all back up. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-dependency-plugin 2.0-alpha-3
This looks really nice. It gets my enthusiastic +1. :-) Thanks, john On 3/17/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: I'd like to release maven-dependency-plugin:2.0-alpha-3 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug in-2.0-alpha-3/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: This release adds 2 new goals: dependency:analyze -> this executes the maven-dependency-analyzer shared component to look for problems with dependencies. Dependency:analyze-dep-mgt -> this compares the resolved dependencies with the dependencyManagement section to identify mismatches. This is intended to help people identify potential issues before upgrading to 2.0.6 (with the MNG-1577 patch). It will also be useful to find out where projects are explicitly overriding dependencyManagement. This vote is dependent on the vote for maven-dependency-analyzer succeeding. Vote is open for 72 hours. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WIKI] Archiva Roadmap & Design
Hi Joakim, I'd like to add a web application to deploy new artifacts into the repository (MRM-305). This matches #3 in http://docs.codehaus.org/display/MAVENUSER/Archiva+Requirements. It appears that no one's been doing something like this but I could be mistaken. Also, there are differences in the Design's (http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva) directory structure and the svn directory structure. Are you referring to a different directory structure in the document or is this a plan to reorganize the current grouping of the sub projects? Thanks, John On 3/20/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: Just a quick note to other Archiva Developers that the Product Roadmap and Design docs are being updated on wiki (Confluence) The Roadmap:: http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap I think we might need to split up the roadmap to 1.0-alpha, 1.0-beta, 1.0-rc, and finally 1.0. WDYT? The Design Docs:: http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva As usual, these documents are ongoing and fluid. Comments are appreciated. - Joakim
Re: [vote] Merge 2.1-lifecycle-refactor branch back to maven trunk
+1 To be able to order correctly is a big improvement. Also very cool is that we can now query and inspect what will happens before it executes. One more step of providing declarative outputs for plugins and we will know everything that could happen which will make IDE integration very awesome. Nice work. Jason. On 16 Mar 07, at 12:51 PM 16 Mar 07, John Casey wrote: Hi everyone, I've performed a fairly significant refactoring of the lifecycle executor on the 2.1-lifecycle-refactor branch. The changes allow Maven to construct a build plan before execution begins in earnest, which contains all of the mojos and their configurations and is then rendered to a List for iteration and execution. This opens up a whole new world of possibility for controlling builds, not to mention build-process debugging and discovery. I've run the integration tests on this branch, and it seems that everything is working well. I'd like to merge this branch back to trunk, but since it's such a large refactor, I thought it appropriate to vote on it first, in an effort to help us maintain a stable trunk. I've parked binaries, javadocs (of maven-core, where the big changes are), and two design PNG images out here: http://people.apache.org/~jdcasey/maven-drops/2.1-lifecycle-refactor Also, if you want to see the new build plan in action, install the lifecycle plugin: http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven- lifecycle-plugin and run the following command with the binaries above: mvn lifecycle:build-plan -Dtasks=clean,install If you'd like to see the configurations for the mojos, use this: mvn lifecycle:build-plan -Dtasks=clean,install -DextendedInfo=true Please peruse and let me know what you think. I'll give it 72h; please vote +1/+0/-1. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Merge 2.1-lifecycle-refactor branch back to maven trunk
+1. I tried this out and the output is much better than what we currently have: Summary view: Build Plan: 1. org.apache.maven.plugins:maven-clean-plugin:2.1:clean [executionId: default] 2. org.apache.maven.plugins:maven-plugin-plugin:2.2:descriptor [executionId: def ault] 3. org.apache.maven.plugins:maven-resources-plugin:2.2:resources [executionId: d efault] 4. org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile [executionId: de fault] 5. org.apache.maven.plugins:maven-resources-plugin:2.2:testResources [executionI d: default] 6. org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile [executionId : default] 7. org.apache.maven.plugins:maven-surefire-plugin:2.3:test [executionId: default ] 8. org.apache.maven.plugins:maven-jar-plugin:2.1:jar [executionId: default] 9. org.apache.maven.plugins:maven-plugin-plugin:2.2:addPluginArtifactMetada ta [e xecutionId: default] 10. org.apache.maven.plugins:maven-install-plugin:2.1:install [executionId: defa ult] Detailed view: Project: org.apache.maven.plugins:maven-lifecycle-plugin:maven-plugin:1.0-SNAPSH OT Tasks: clean,install Build Plan: 1. org.apache.maven.plugins:maven-clean-plugin:2.1:clean [executionId: default] Origin: default lifecycle Configuration: null 2. org.apache.maven.plugins:maven-plugin-plugin:2.2:descriptor [executionId: def ault] Origin: packaging: maven-plugin Configuration: null -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 12:52 PM To: Maven Developers List Subject: [vote] Merge 2.1-lifecycle-refactor branch back to maven trunk Hi everyone, I've performed a fairly significant refactoring of the lifecycle executor on the 2.1-lifecycle-refactor branch. The changes allow Maven to construct a build plan before execution begins in earnest, which contains all of the mojos and their configurations and is then rendered to a List for iteration and execution. This opens up a whole new world of possibility for controlling builds, not to mention build-process debugging and discovery. I've run the integration tests on this branch, and it seems that everything is working well. I'd like to merge this branch back to trunk, but since it's such a large refactor, I thought it appropriate to vote on it first, in an effort to help us maintain a stable trunk. I've parked binaries, javadocs (of maven-core, where the big changes are), and two design PNG images out here: http://people.apache.org/~jdcasey/maven-drops/2.1-lifecycle-refactor Also, if you want to see the new build plan in action, install the lifecycle plugin: http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-lifecy cle-plugin and run the following command with the binaries above: mvn lifecycle:build-plan -Dtasks=clean,install If you'd like to see the configurations for the mojos, use this: mvn lifecycle:build-plan -Dtasks=clean,install -DextendedInfo=true Please peruse and let me know what you think. I'll give it 72h; please vote +1/+0/-1. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging reform for 2.0.6?
On 19 Mar 07, at 8:15 PM 19 Mar 07, Jason Dillon wrote: Any chance that the logging reform documented here will get into 2.0.6? http://jira.codehaus.org/browse/MNG-2823 Nope, too late. I'll schedule it for 2.0.7. I'm working on the last couple issues, and then it's out the door. Unless you patch it, it won't go in. I'm already a fews days over the 4 week window. Jason. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failure on trunk
im not sure but i think in order to change the amount of memory the tests can use, you have to configure the surefire plugin - changing the amount of memory maven uses dont take effect on tests (i think they are ran on a separate jvm) On 3/19/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: it's set in MAVEN_OPTS env var with -Xmx and -Xms java options, but if you don't know it, you probably use the default jvm options. You can try to it to something like that: MAVEN_OPTS=-Xmx256m If you don't want to patch Continuum, you can use a prebuilt snapshot: http://maven.zones.apache.org/~continuum/builds/trunk/ Graham Leggett a écrit : > Emmanuel Venisse wrote: > >> how many memory is allocated to the build? Normally the default is >> enough. > > No idea - checked out a pristine copy of trunk as of an hour or two ago, > and did an mvn install. > > Is there somewhere where memory allocations are set, perhaps in a pom file? > > Regards, > Graham > -- -- []'s Marcelo Takeshi Fukushima
RE: [VOTE] Release maven-plugin-plugin 2.3
+1 -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 6:43 PM To: Maven Developers List Subject: [VOTE] Release maven-plugin-plugin 2.3 Hi, I'd like to release maven-plugin-plugin-2.3. There is only one issue fixed for this release, but it's an important one. It adds support for @since tags for mojo parameters. This is an important improvement to our plugin documentation: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11139 &fixfor=13114 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-plugin-plugin-2 .3/ Staged at: http://people.apache.org/~dennisl/staging-repository-plugins/ A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logging reform for 2.0.6?
Any chance that the logging reform documented here will get into 2.0.6? http://jira.codehaus.org/browse/MNG-2823 --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Archetypes] plugin proposition
Awesome! Incidentally does your plugin have the ability to evaluate the maven name element when it processes the archetype templates? There is a patch for the current archetype plugin here: http://jira.codehaus.org/browse/ARCHETYPE-55 But if yours does it already, I'm skipping the patching and just using yours :-) Thanks, - Ole Raphaël Piéroni wrote: Hi, I added it on my todo list. Raphaël 2007/3/19, Ole Ersoy <[EMAIL PROTECTED]>: Hi Raphael, Sounds like you are doing some terrific work. If you have time, could you please take a look at this bug: http://jira.codehaus.org/browse/MNG-2856 When the current archetype plugin processes png images, it changes them, and makes the unreadable. I think if we add a element (possibly contained in the container element) to the archetype.xml descriptor, which tells the plugin to just copy those resources, the issue gets fixed. Cheers, - Ole Raphaël Piéroni wrote: > Hi all, > > Here is the resent of a mail i sent on [EMAIL PROTECTED] > > I would like to introduce the work i have done so far concerning > archetypes. > I have improved the current archetype mecanism by adding > - the interactive selection of the archetype to create a project from > - the interactive configuration of the archetype to create a project from > - the interactive configuration of the archetype created from a project > > To acheive this i needed to refactor the archetype descriptor and > workflow. > I must admit having stole some code from current implementation :). > > You can checkout the sources in the mojo sandbox. Just beware when > checking out the sources in Windows, the source tree is quite deep and > breaks. > > I will be happy to have some feedback about it. > > The plugins comes with a little pack of archetypes. > The core goals are : > - generate: to generate a project from an archetype > - create: to create an archetype from a project > > This first implementation have som limitations as the archetypes are for > now mono-project. > > I copy my current todo list for starting point to discuss about : > > - package mojo: to jar the created archetype > - sample properties mojo: to provide a sample configuration file for an > archetype (which could be filled and used in batch mode) > - descriptor with attributes: refactor the current archetype > descriptor to > use attributes instead of xml elements > - generate multi project: to generate a project and its internal modules > from one archetype. > - create multi project: to create one archetype from a project with > modules > - CRUD group mojo: mojos to change the archetype groups defined in the > ~/.m2/archetypes.xml > - Documentation: Document the workfow of user interaction, explain the > internal plexus components > - integration tests and sibling: handle directories other than src/main, > src/test, src/site. a first case would be integration tests > - pom.xml sibling: handle templates in the main directory. some use case > would be readme files > - translator: create a tool to translate current archetypes into this new > way > - archetype group metadata: create a new group metadata for archetypes > (same > way as plugins metadata) therefore we could have a archetype packaging. > - velocity tools in templates: provide the official velocity tools to be > used by archetype creators > > > The plugin don't have backward compatibility yet. > > Regards, > > Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failure on trunk
it's set in MAVEN_OPTS env var with -Xmx and -Xms java options, but if you don't know it, you probably use the default jvm options. You can try to it to something like that: MAVEN_OPTS=-Xmx256m If you don't want to patch Continuum, you can use a prebuilt snapshot: http://maven.zones.apache.org/~continuum/builds/trunk/ Graham Leggett a écrit : Emmanuel Venisse wrote: how many memory is allocated to the build? Normally the default is enough. No idea - checked out a pristine copy of trunk as of an hour or two ago, and did an mvn install. Is there somewhere where memory allocations are set, perhaps in a pom file? Regards, Graham --
Re: Test failure on trunk
Emmanuel Venisse wrote: how many memory is allocated to the build? Normally the default is enough. No idea - checked out a pristine copy of trunk as of an hour or two ago, and did an mvn install. Is there somewhere where memory allocations are set, perhaps in a pom file? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Test failure on trunk
how many memory is allocated to the build? Normally the default is enough. Graham Leggett a écrit : Emmanuel Venisse wrote: jdk version? Latest MacOSX version, jdk v1.5.0_07-164. Regards, Graham --
Re: Test failure on trunk
Emmanuel Venisse wrote: jdk version? Latest MacOSX version, jdk v1.5.0_07-164. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
[VOTE] Release maven-plugin-plugin 2.3
Hi, I'd like to release maven-plugin-plugin-2.3. There is only one issue fixed for this release, but it's an important one. It adds support for @since tags for mojo parameters. This is an important improvement to our plugin documentation: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11139&fixfor=13114 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-plugin-plugin-2.3/ Staged at: http://people.apache.org/~dennisl/staging-repository-plugins/ A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failure on trunk
jdk version? Graham Leggett a écrit : Hi all, While trying to build trunk of continuum, I am getting the following test failure on MacosX v10.4: --- Test set: org.apache.maven.continuum.buildcontroller.DefaultBuildControllerTest --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 255.852 sec <<< FAILURE! testWithDependencyChanges(org.apache.maven.continuum.buildcontroller.DefaultBuil dControllerTest) Time elapsed: 79.372 sec <<< ERROR! java.lang.OutOfMemoryError: Java heap space Not sure exactly where the JVM should be given more memory, is this a maven problem or a continuum problem? Regards, Graham --
Test failure on trunk
Hi all, While trying to build trunk of continuum, I am getting the following test failure on MacosX v10.4: --- Test set: org.apache.maven.continuum.buildcontroller.DefaultBuildControllerTest --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 255.852 sec <<< FAILURE! testWithDependencyChanges(org.apache.maven.continuum.buildcontroller.DefaultBuil dControllerTest) Time elapsed: 79.372 sec <<< ERROR! java.lang.OutOfMemoryError: Java heap space Not sure exactly where the JVM should be given more memory, is this a maven problem or a continuum problem? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [Archetypes] plugin proposition
Hi, I added it on my todo list. Raphaël 2007/3/19, Ole Ersoy <[EMAIL PROTECTED]>: Hi Raphael, Sounds like you are doing some terrific work. If you have time, could you please take a look at this bug: http://jira.codehaus.org/browse/MNG-2856 When the current archetype plugin processes png images, it changes them, and makes the unreadable. I think if we add a element (possibly contained in the container element) to the archetype.xml descriptor, which tells the plugin to just copy those resources, the issue gets fixed. Cheers, - Ole Raphaël Piéroni wrote: > Hi all, > > Here is the resent of a mail i sent on [EMAIL PROTECTED] > > I would like to introduce the work i have done so far concerning > archetypes. > I have improved the current archetype mecanism by adding > - the interactive selection of the archetype to create a project from > - the interactive configuration of the archetype to create a project from > - the interactive configuration of the archetype created from a project > > To acheive this i needed to refactor the archetype descriptor and > workflow. > I must admit having stole some code from current implementation :). > > You can checkout the sources in the mojo sandbox. Just beware when > checking out the sources in Windows, the source tree is quite deep and > breaks. > > I will be happy to have some feedback about it. > > The plugins comes with a little pack of archetypes. > The core goals are : > - generate: to generate a project from an archetype > - create: to create an archetype from a project > > This first implementation have som limitations as the archetypes are for > now mono-project. > > I copy my current todo list for starting point to discuss about : > > - package mojo: to jar the created archetype > - sample properties mojo: to provide a sample configuration file for an > archetype (which could be filled and used in batch mode) > - descriptor with attributes: refactor the current archetype > descriptor to > use attributes instead of xml elements > - generate multi project: to generate a project and its internal modules > from one archetype. > - create multi project: to create one archetype from a project with > modules > - CRUD group mojo: mojos to change the archetype groups defined in the > ~/.m2/archetypes.xml > - Documentation: Document the workfow of user interaction, explain the > internal plexus components > - integration tests and sibling: handle directories other than src/main, > src/test, src/site. a first case would be integration tests > - pom.xml sibling: handle templates in the main directory. some use case > would be readme files > - translator: create a tool to translate current archetypes into this new > way > - archetype group metadata: create a new group metadata for archetypes > (same > way as plugins metadata) therefore we could have a archetype packaging. > - velocity tools in templates: provide the official velocity tools to be > used by archetype creators > > > The plugin don't have backward compatibility yet. > > Regards, > > Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-dependency-plugin 2.0-alpha-3
+1 Emmanuel Brian E. Fox a écrit : I'd like to release maven-dependency-plugin:2.0-alpha-3 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug in-2.0-alpha-3/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: This release adds 2 new goals: dependency:analyze -> this executes the maven-dependency-analyzer shared component to look for problems with dependencies. Dependency:analyze-dep-mgt -> this compares the resolved dependencies with the dependencyManagement section to identify mismatches. This is intended to help people identify potential issues before upgrading to 2.0.6 (with the MNG-1577 patch). It will also be useful to find out where projects are explicitly overriding dependencyManagement. This vote is dependent on the vote for maven-dependency-analyzer succeeding. Vote is open for 72 hours. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release maven-dependency-analyzer 1.0-alpha-1 shared component
+1 Emmanuel Brian E. Fox a écrit : I'd like to release the alpha 1 version of this shared component. The analyzer scans through your class files and produces a list of dependencies declared but not used, dependencies used but not declared, and dependencies actually used. Maven-dependency-plugin 2.0-alpha-3 will provide a mojo to expose the analyzer. I've tested this component on my large builds without any issues and it provides very useful insight into your projects. The staging repo is here: http://people.apache.org/~brianf/staging-repository/ Since this is the initial release, there aren't any release notes in jira. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Commit privs for Ralph Goers
+1 (late, I know) -j On 3/19/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: +1 - Joakim Jason van Zyl wrote: > Hi, > > As part of the massive overhaul that was MNG-1577 I wanted to also to > ask for commit privs for Ralph. Much of my recent work has been with > Patrick on getting MNG-1577 into the codebase, but Ralph also did a > great deal of work and when looking at the last patch I committed to > the documentation it reminded me of the initial conversation I had > with Ralph at ApacheCon when he offered the first version of the > patch. Again, this was not a trivial patch and though I don't > typically ask for commit privs based on a patch this was a long drawn > out effort that required a lot of work and is exceptional. Ralph is a > committer on Cocoon and think he would make a fine committer here. > > +1 > > Thanks, > > Jason. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
War plugin and Overlays handling
Hi, Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied *last*. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays order always wins. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays *and* before the current build (if the current build is not specified of course) with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane [1] MWAR-72, MWAR-66, MWAR-78 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[WIKI] Archiva Roadmap & Design
Just a quick note to other Archiva Developers that the Product Roadmap and Design docs are being updated on wiki (Confluence) The Roadmap:: http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap I think we might need to split up the roadmap to 1.0-alpha, 1.0-beta, 1.0-rc, and finally 1.0. WDYT? The Design Docs:: http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva As usual, these documents are ongoing and fluid. Comments are appreciated. - Joakim
Re: [vote] Commit privs for Ralph Goers
+1 - Joakim Jason van Zyl wrote: > Hi, > > As part of the massive overhaul that was MNG-1577 I wanted to also to > ask for commit privs for Ralph. Much of my recent work has been with > Patrick on getting MNG-1577 into the codebase, but Ralph also did a > great deal of work and when looking at the last patch I committed to > the documentation it reminded me of the initial conversation I had > with Ralph at ApacheCon when he offered the first version of the > patch. Again, this was not a trivial patch and though I don't > typically ask for commit privs based on a patch this was a long drawn > out effort that required a lot of work and is exceptional. Ralph is a > committer on Cocoon and think he would make a fine committer here. > > +1 > > Thanks, > > Jason. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
for what my opinion matters, I'm in favor of the bi-weekly schedule. On 3/19/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: ok, I am changing my tune on the remaining 11 issues, I want this thing released asap so we have something concrete to get moving on. The 11 issues are functionally no real different then a lot of the ones in the -2 jira so I am thinking we just push that forward and get going on this. so, I haven't actually pulled a release on something like this at apache, from what I understand we can put this someplace for downloading that doesn't have to get mirrored all over the place. more information please brett... Should we vote on this? I think we have an implict consent based on just this thread from committers but should this alpha cycle take a vote each push, or can we vote on a biweekly release schedule for alphas for the next month or two? if we get this decided I'll arrange the dependencies and get this thing alpha release dealio running asap. jesse On 3/15/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: > yes, you are also correct on that, great point > > On 3/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote: > > Of the unresolved issues for 1.1-alpha-any, 108 of them are against some > > version of continuum 1.0 and might not apply to continuum-1.1, but someone > > is going to have to verify that. > > > > On 3/13/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > > > > On 12/03/2007, at 7:35 AM, Jesse McConnell wrote: > > > > > > On 13/03/2007, at 10:31 AM, Carlos Sanchez wrote: > > > > These are the numbers I see in jira right now > > > > 1.1-alpha-1 11 > > > > 1.1-alpha-2 72 > > > > 1.1-alpha-# 156 > > > > > > > > > > > -- > jesse mcconnell > [EMAIL PROTECTED] > -- jesse mcconnell [EMAIL PROTECTED]
Re: Adding default OSGi information to JARs
On Monday 19 March 2007 16:12, Carlos Sanchez wrote: > afaik they passed the vote to graduate Oh yea. Forgot about that and google still brings up their incubator page as the first hit (which still says it's undergoing incubation). Guess they need to upgrade the incubator sites to let people know they're graduating. Dan > On 3/19/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > One more thing to take into consideration: > > > > Felix is in incubation. Thus, as of right now, the plugin cannot > > go to central. Feel free to complain about that on > > [EMAIL PROTECTED]:-) > > > > > > Dan > > > > On Monday 19 March 2007 16:03, Carlos Sanchez wrote: > > > I'm still waiting for a big patch to be applied > > > https://issues.apache.org/jira/browse/FELIX-199 > > > > > > And they need to make a release also. > > > > > > I'll take a look at the performance > > > > > > On 3/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > This is mostly directed at Carlos, > > > > > > > > Just following up on the discussion we have at EclipseCon. Have > > > > you check the performance of the Felix plugin? If it doesn't add > > > > any significant overhead to people building their JARs due to > > > > the analysis performed by BND, and it is entirely non-invasive > > > > then I think it would be fine to add to the default lifecycle. > > > > Just so you can prepare I would like to know if any significant > > > > amount of time is added to a build to add the bundle > > > > information. If it is insignificant it's not a problem, if it > > > > doesn't something like add 20% to users build times then I think > > > > we'll have a problem. > > > > > > > > Thanks, > > > > > > > > Jason. > > > > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding default OSGi information to JARs
afaik they passed the vote to graduate On 3/19/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: One more thing to take into consideration: Felix is in incubation. Thus, as of right now, the plugin cannot go to central. Feel free to complain about that on [EMAIL PROTECTED]:-) Dan On Monday 19 March 2007 16:03, Carlos Sanchez wrote: > I'm still waiting for a big patch to be applied > https://issues.apache.org/jira/browse/FELIX-199 > > And they need to make a release also. > > I'll take a look at the performance > > On 3/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > This is mostly directed at Carlos, > > > > Just following up on the discussion we have at EclipseCon. Have you > > check the performance of the Felix plugin? If it doesn't add any > > significant overhead to people building their JARs due to the > > analysis performed by BND, and it is entirely non-invasive then I > > think it would be fine to add to the default lifecycle. Just so you > > can prepare I would like to know if any significant amount of time > > is added to a build to add the bundle information. If it is > > insignificant it's not a problem, if it doesn't something like add > > 20% to users build times then I think we'll have a problem. > > > > Thanks, > > > > Jason. > > > > > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding default OSGi information to JARs
One more thing to take into consideration: Felix is in incubation. Thus, as of right now, the plugin cannot go to central. Feel free to complain about that on [EMAIL PROTECTED]:-) Dan On Monday 19 March 2007 16:03, Carlos Sanchez wrote: > I'm still waiting for a big patch to be applied > https://issues.apache.org/jira/browse/FELIX-199 > > And they need to make a release also. > > I'll take a look at the performance > > On 3/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > This is mostly directed at Carlos, > > > > Just following up on the discussion we have at EclipseCon. Have you > > check the performance of the Felix plugin? If it doesn't add any > > significant overhead to people building their JARs due to the > > analysis performed by BND, and it is entirely non-invasive then I > > think it would be fine to add to the default lifecycle. Just so you > > can prepare I would like to know if any significant amount of time > > is added to a build to add the bundle information. If it is > > insignificant it's not a problem, if it doesn't something like add > > 20% to users build times then I think we'll have a problem. > > > > Thanks, > > > > Jason. > > > > > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding default OSGi information to JARs
I'm still waiting for a big patch to be applied https://issues.apache.org/jira/browse/FELIX-199 And they need to make a release also. I'll take a look at the performance On 3/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: This is mostly directed at Carlos, Just following up on the discussion we have at EclipseCon. Have you check the performance of the Felix plugin? If it doesn't add any significant overhead to people building their JARs due to the analysis performed by BND, and it is entirely non-invasive then I think it would be fine to add to the default lifecycle. Just so you can prepare I would like to know if any significant amount of time is added to a build to add the bundle information. If it is insignificant it's not a problem, if it doesn't something like add 20% to users build times then I think we'll have a problem. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
ok, I am changing my tune on the remaining 11 issues, I want this thing released asap so we have something concrete to get moving on. The 11 issues are functionally no real different then a lot of the ones in the -2 jira so I am thinking we just push that forward and get going on this. so, I haven't actually pulled a release on something like this at apache, from what I understand we can put this someplace for downloading that doesn't have to get mirrored all over the place. more information please brett... Should we vote on this? I think we have an implict consent based on just this thread from committers but should this alpha cycle take a vote each push, or can we vote on a biweekly release schedule for alphas for the next month or two? if we get this decided I'll arrange the dependencies and get this thing alpha release dealio running asap. jesse On 3/15/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: yes, you are also correct on that, great point On 3/15/07, Thierry Lach <[EMAIL PROTECTED]> wrote: > Of the unresolved issues for 1.1-alpha-any, 108 of them are against some > version of continuum 1.0 and might not apply to continuum-1.1, but someone > is going to have to verify that. > > On 3/13/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > On 12/03/2007, at 7:35 AM, Jesse McConnell wrote: > > > > On 13/03/2007, at 10:31 AM, Carlos Sanchez wrote: > > > These are the numbers I see in jira right now > > > 1.1-alpha-1 11 > > > 1.1-alpha-2 72 > > > 1.1-alpha-# 156 > > > > > -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Adding default OSGi information to JARs
This is mostly directed at Carlos, Just following up on the discussion we have at EclipseCon. Have you check the performance of the Felix plugin? If it doesn't add any significant overhead to people building their JARs due to the analysis performed by BND, and it is entirely non-invasive then I think it would be fine to add to the default lifecycle. Just so you can prepare I would like to know if any significant amount of time is added to a build to add the bundle information. If it is insignificant it's not a problem, if it doesn't something like add 20% to users build times then I think we'll have a problem. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lifecycle Goal for Injecting POM Parameters?
Hi, I posted this on maven users, but did not get a reply, so I hope that it's ok that I ask here. I created a mojo and gave it a lifecycle for a specific packaging. After I did this, the mojo stops receiving pom parameters. I'm assuming there is a specific goal that I have to run per the lifecycle to get maven to inject the parameters? Anyone know if this is correct and would you happen to know the artifactId and goal that I need to run? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse PDE questions/suggestions
Hi Markus,
I need to play with the PDE feature of the eclipse plugin more,
but I did write an archetype for generating baseline eclipse
documentation plugins
that you can see here:
https://svn.apache.org/repos/asf/directory/sandbox/oersoy/documentation.checklist.parent
It's actually a checklist / recipe documentation generator, but if you
run the archetype it will generate a baseline eclipse project with
${groupId}.${artifactId} in plugin.xml
So one way you could get things going is to just modify the archetype,
add a few templates
maybe, and just use the archetype plugin to generate the baseline for
your project.
Cheers,
- Ole
Markus Wiederkehr wrote:
I have a two questions regarding the Maven Eclipse plugin and
especially its PDE mode...
1) I would like to use ${groupId}.${artifactId} instead of the
artifact ID alone as project name in .project and (more importantly)
as Bundle-SymbolicName in META-INF/MANIFEST.MF. Is this possible?
2) In PDE mode the plugin creates in the .project
file.. At this point it uses the absolute path of the jar file for the
element. I think a better solution would be to define a
path variable (similar to M2_REPO) under
"Preferences/General/Workspace/Linked Resources" and make the location
relative to that path variable. "mvn eclipse:add-maven-repo" should
also add this variable to the workspace.
The absolute path should be removed from source attachments in
.classpath too. One way to accomplish this would be to create another
link in .project and use it as sourcepath in .classpath.
Here's an example that seems to work:
.project:
ognl-2.6.9.jar
1
M2/ognl/ognl/2.6.9/ognl-2.6.9.jar
ognl-2.6.9-sources.jar
1
M2/ognl/ognl/2.6.9/ognl-2.6.9-sources.jar
.classpath:
where M2 is a path variable defined under
"Preferences/General/Workspace/Linked Resources" or in
~/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs
respectively.
Thanks
Markus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse PDE questions/suggestions
I have a two questions regarding the Maven Eclipse plugin and
especially its PDE mode...
1) I would like to use ${groupId}.${artifactId} instead of the
artifact ID alone as project name in .project and (more importantly)
as Bundle-SymbolicName in META-INF/MANIFEST.MF. Is this possible?
2) In PDE mode the plugin creates in the .project
file.. At this point it uses the absolute path of the jar file for the
element. I think a better solution would be to define a
path variable (similar to M2_REPO) under
"Preferences/General/Workspace/Linked Resources" and make the location
relative to that path variable. "mvn eclipse:add-maven-repo" should
also add this variable to the workspace.
The absolute path should be removed from source attachments in
.classpath too. One way to accomplish this would be to create another
link in .project and use it as sourcepath in .classpath.
Here's an example that seems to work:
.project:
ognl-2.6.9.jar
1
M2/ognl/ognl/2.6.9/ognl-2.6.9.jar
ognl-2.6.9-sources.jar
1
M2/ognl/ognl/2.6.9/ognl-2.6.9-sources.jar
.classpath:
where M2 is a path variable defined under
"Preferences/General/Workspace/Linked Resources" or in
~/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs
respectively.
Thanks
Markus
--
Always remember you're unique. Just like everyone else.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] maven-dependency-plugin 2.0-alpha-3
Hi Brian, Brian E. Fox wrote on Monday, March 19, 2007 1:25 PM: > The analyze goal has already been merged into the plugin and > is the same here... it does the class level analysis. There > is also analyze-dep-mgt to do the 1577 check. Analyze will do > both so there's no clash here. Take a look at the site: > http://maven.apache.org/plugins/maven-dependency-plugin/ OK, thanks for clarification, I'll shut up :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r519796 - in /maven/doxia/trunk/doxia-core/src: main/java/org/apache/maven/doxia/validation/ test/java/org/apache/maven/doxia/validation/
On Sunday 18 March 2007 23:23, [EMAIL PROTECTED] wrote: > Author: jvanzyl > Date: Sun Mar 18 19:23:13 2007 > New Revision: 519796 > > URL: http://svn.apache.org/viewvc?view=rev&rev=519796 > Log: > o removing dead code that i put in with the twiki code > > > Removed: > > maven/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/validatio >n/ > maven/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/validatio >n/ The validation packages was not dead code "per se"... No class inside doxia was using it, but in my case, the AdvicedSink turned into a useful class to debug and test parsers in a development environment. pgpIxblPNSZaw.pgp Description: PGP signature
Re: MNG-2433
On 19 Mar 07, at 7:03 AM 19 Mar 07, Kenney Westerhof wrote: I know that legacy repositories keep getting pinged on each build, even if they're just updated. Is there also no network traffic when legacy repo's are in the repo list? For that I'm not sure, there was no mention of legacy repositories. I'll check. http://jira.codehaus.org/browse/MNG-2883 Jason. -- Kenney Brett Porter wrote: On 19/03/2007, at 11:36 AM, Jason van Zyl wrote: Yah, I saw the logging which is why I used the network monitors so the only thing I could think of is a plugin grabbing the WagonManager and turning it back online which I consider someone else's problem. I think from the test below it's clear that's not happening though. So I'd say move the issue to later as a minor issue because of the misleading logging. Jason. I just did mvn -o -X clean install on archiva, and see this: --->8--- [INFO] snapshot org.codehaus.plexus:plexus-appserver-maven- plugin:2.0-alpha-8-SNAPSHOT: checking for updates from apache.snapshots [DEBUG] System is offline. Cannot resolve metadata: Repository Metadata -- GroupId: org.codehaus.plexus ArtifactId: plexus-appserver-maven-plugin Metadata Type: org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepos itoryMetadata --->8--- The info line is misleading when you don't have debug mode on. It doesn't actually go to the network. you can reproduce by doing this first: touch -t '20070101' ~/.m2/repository/org/codehaus/plexus/ plexus-appserver-maven-plugin/2.0-alpha-8-SNAPSHOT/maven- metadata-apache.snapshots.xml On 19/03/2007, at 11:07 AM, Jason van Zyl wrote: Hi, Just seeing if anyone can reproduce this: http://jira.codehaus.org/browse/MNG-2433 I can't so I want to close it. I've used truss, TPIMon, and ktrace on the Linux, Window, and OS X and I see no network traffic on a simple project but I'm wondering if it's some plugin turning on the Wagon Manager or something. Jason. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] maven-dependency-plugin 2.0-alpha-3
The analyze goal has already been merged into the plugin and is the same here... it does the class level analysis. There is also analyze-dep-mgt to do the 1577 check. Analyze will do both so there's no clash here. Take a look at the site: http://maven.apache.org/plugins/maven-dependency-plugin/ -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 8:10 AM To: Maven Developers List Subject: RE: [VOTE] maven-dependency-plugin 2.0-alpha-3 Max Bowsher wrote on Monday, March 19, 2007 12:00 PM: > Jörg Schaible wrote: >> It is very unfortunate, that you took the same goal that was >> introduces by the maven-dependency-analyzer-plugion, that is >> currently merged in the sandbox in a branch. > > TTBOMK, ?? > it is not possible for one plugin to implement > foobar:alpha and > another to implement foobar:beta - the prefix must map to a single > plugin, no? > > So, it would be impossible for one plugin to take the goal of another. No, the maven-dependency-analyzer-plugin has been merged into the maven-dependency-plugin in the sandbox and obviouskly no plugin can support two different tasks with the same goal. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] maven-dependency-plugin 2.0-alpha-3
Max Bowsher wrote on Monday, March 19, 2007 12:00 PM: > Jörg Schaible wrote: >> It is very unfortunate, that you took the same goal that was >> introduces by the maven-dependency-analyzer-plugion, that is >> currently merged in the sandbox in a branch. > > TTBOMK, ?? > it is not possible for one plugin to implement > foobar:alpha and > another to implement foobar:beta - the prefix must map to a single > plugin, no? > > So, it would be impossible for one plugin to take the goal of another. No, the maven-dependency-analyzer-plugin has been merged into the maven-dependency-plugin in the sandbox and obviouskly no plugin can support two different tasks with the same goal. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MNG-2433
I know that legacy repositories keep getting pinged on each build, even if they're just updated. Is there also no network traffic when legacy repo's are in the repo list? -- Kenney Brett Porter wrote: On 19/03/2007, at 11:36 AM, Jason van Zyl wrote: Yah, I saw the logging which is why I used the network monitors so the only thing I could think of is a plugin grabbing the WagonManager and turning it back online which I consider someone else's problem. I think from the test below it's clear that's not happening though. So I'd say move the issue to later as a minor issue because of the misleading logging. Jason. I just did mvn -o -X clean install on archiva, and see this: --->8--- [INFO] snapshot org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8-SNAPSHOT: checking for updates from apache.snapshots [DEBUG] System is offline. Cannot resolve metadata: Repository Metadata -- GroupId: org.codehaus.plexus ArtifactId: plexus-appserver-maven-plugin Metadata Type: org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata --->8--- The info line is misleading when you don't have debug mode on. It doesn't actually go to the network. you can reproduce by doing this first: touch -t '20070101' ~/.m2/repository/org/codehaus/plexus/plexus-appserver-maven-plugin/2.0-alpha-8-SNAPSHOT/maven-metadata-apache.snapshots.xml On 19/03/2007, at 11:07 AM, Jason van Zyl wrote: Hi, Just seeing if anyone can reproduce this: http://jira.codehaus.org/browse/MNG-2433 I can't so I want to close it. I've used truss, TPIMon, and ktrace on the Linux, Window, and OS X and I see no network traffic on a simple project but I'm wondering if it's some plugin turning on the Wagon Manager or something. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-dependency-plugin 2.0-alpha-3
Jörg Schaible wrote: > It is very unfortunate, that you took the same goal that was introduces > by the maven-dependency-analyzer-plugion, that is currently merged in > the sandbox in a branch. TTBOMK, it is not possible for one plugin to implement foobar:alpha and another to implement foobar:beta - the prefix must map to a single plugin, no? So, it would be impossible for one plugin to take the goal of another. In any case: r512017 | joehni | 2007-02-26 21:20:54 + (Mon, 26 Feb 2007) | 1 line Changed paths: D /maven/sandbox/trunk/plugins/maven-dependency-analyzer-plugin Remove maven-dependency-analyzer-plugin, was merged into maven-dependency-plugin. r512015 | joehni | 2007-02-26 21:17:19 + (Mon, 26 Feb 2007) | 1 line Changed paths: M /maven/sandbox/trunk/plugins/maven-dependency-plugin/pom.xml A /maven/sandbox/trunk/plugins/maven-dependency-plugin/src/main/java/org/apache/maven/plugin/dependency/AnalyzeMojo.java Merge maven-dependency-analyer-plugin into maven-dependency-plugin. Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
