Re: Archiva 1.1 Roadmap
I have some additions :) I also think we need to keep reviewing the types of problems people have and helping them diagnose them. It seems that figuring out repo whitelists and blacklists and the cause of proxy problems is still difficult - so maybe a UI configuration for the logging might be a good idea? Or a way to request it from a browser and get additional information (ie, 404 screen could capture all the logging even if it's not logged). Also, I'd like to finish the work of replacing the plexus runtime with a standalone jetty bundle that runs the war as is :) On 07/02/2008, at 12:16 AM, Brett Porter wrote: These all sound good to me. Really enjoying the discussion :) Some comments and additions: On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote: From the thread so far, these are the things to choose from for the 1.1roadmap: 1. Reduce memory consumption 2. Preemptive artifact synchronisation 3. Eliminate client side blocking when artifacts are being downloaded from remote repositories. 4. Ability to take repositories (both managed and remote) offline 5. Communication with remote repositories should be done asynchronously 6. Web UI for deploying artifacts 7. Plugin subsystem. We already have this for consumers but we really should have features like search, dependency graphing and browsing as plugins so we can turn bad behaving features and also give a way for users to create their own functionality. 8. Separation between managed repositories used for publishing and those used for caching artifacts from remote repositories. This separation would allow us to have: * Provide indexing, browsing and search only for publishing * RSS feeds for new artifacts in published repositories. I think this is something that is configurable, and set nicely by default. I don't think we should completely separate proxy cache managed repos from deployed repos, but having a default configuration that does and recommending it is the way to go. 9. Review synchronization of the configuration object 10. Improve the tests where databases are being set-up (use mock objects instead) 11. Statistical reports 12. Repository grouping Any more suggestions or comments for this? :) I'd just add 13. architectural simplification - we talked about some technology changes and while I don't think we need to rush into any, it would be worth having them in mind if we can either gradually move to them or if it becomes simpler to do than make a change in the current set up. For instance, doing (10) might be better at a time when we make changes to the database layer itself. Along these lines, architecturally I think we need to add: 14. separate the subsystems better. In my view - the base system being the tools (scanning, consumers, etc - with or without the database), then the addition of the proxy/webdav on that (possibly without the database), then the web application/visualisation on top of that (this requires the databases and all other pieces of functionality). We might later add web services as an option with or without the webapp. These different deployment options would make it much more flexible. Again I don't think this all needs to be done in one go - but designing the target architecture and moving towards it would be a good goal for 1.1 and beyond. Some of the above may actually be plugins too, so we should consider the impact of that. Would be great to update the wiki with this list split into 1.1 and beyond sections :) Btw, what does everyone think of having the end of March as the target release date of 1.1? Great! We should probably aim to be feature complete a few weeks before that then. This probably means only picking a few of the above (there is a lot there!), and moving the rest to 1.2. Also need to pick some important issues from the JIRA pool - as well as cutting down the 60+ in there now :) We can keep working on critical stuff in the 1.0.x line. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: MRM-684 - Solving Archiva Blocking
Hey Brett, On Thu, 2008-02-07 at 15:20 +1100, Brett Porter wrote: I don't have any objection to using commons-vfs, since I think it covers much of what Wagon does anyway - as long as it does have all the features needed. Looks like we only use Http/Https, ssh and file Wagon's in archiva - commons-vfs so far looks like it hits the spot. That said - I don't really see any reason this is difficult in Wagon - and do believe Wagon should be usable outside Maven. I think streaming is a perfectly sensible thing to add... I have a copy of Wagon checked out at the moment that works purely with streams but I ran into a few of issues: * Wagon's transfer even model relies on being able to pass the File object that is being transfered to the listener - if its a streaming the transfer events don't make any sense seeing that the consumer of Wagon would be doing all the reading/writing * There are about three different ssh/scp Wagon implementations that can only deal with files. For example, there is a Wagon provider that will use the systems scp executable to upload/download files I really don't see the value in having to ditch Wagon implementations. Regardless, I certainly don't want to see *another* transport layer, or lose something like remote file:// repositories :) I understand your concern - I don't want to add yet another framework to Archiva. All we need is a simple module to allow us to get files from remote locations (http and ssh) and from the local file system. Does that make sense? Perfectly :) James
Re: MRM-684 - Solving Archiva Blocking
On 08/02/2008, at 2:21 PM, James William Dumay wrote: Looks like we only use Http/Https, ssh and file Wagon's in archiva - commons-vfs so far looks like it hits the spot. Sounds like it's worth an evaluation regardless. I have a copy of Wagon checked out at the moment that works purely with streams but I ran into a few of issues: * Wagon's transfer even model relies on being able to pass the File object that is being transfered to the listener - if its a streaming the transfer events don't make any sense seeing that the consumer of Wagon would be doing all the reading/writing * There are about three different ssh/scp Wagon implementations that can only deal with files. For example, there is a Wagon provider that will use the systems scp executable to upload/download files I really don't see the value in having to ditch Wagon implementations. So if we do stick to this, sounds like it's not a convenience File method, but two implementations, and the stream one is only supported by some implementations and just throws an error on the others? (Those don't make sense for Archiva anyway). As far as the transfer events go - not sure I understand - isn't the wagon consuming from an InputStream and pushing to an OutputStream and can trace the byte count along the way? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
snipped 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. My motivations behind this were: # leverage Java 5 language and other library features, and enable Continuum to do the same. # Encourage more contributions by using tools/libraries that have a good user base. snipped 3) Builders Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. This is way to detailed to be on a roadmap. Yep, way too detailed for the roadmap but that was just a random thought, please ignore it at this stage ;-) snipped 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm not sure what you're trying to say here. The current way to installing Continuum (unpack, run bin/plexus.sh) is still giving me wow when doing demos. I was just hinting if Continuum dist could be leaner, but again may be too early at this point in time What I would like to see is talk about the different ways of doing remoting and tool integration (IDEs in particular, but also desktop widgets). +1 Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. +1 If someone is going down the plugin path, it is essential to me that these plugins can be written in vi inside an existing installation and copied around. This implies to me that we have to support a plugin language like jython, jruby or groovy. I agree with the possibility supporting multiple plugin languages in the long run but just having support for Java based plugins for starters. I am not yet sure what all is involved in supporting plugins in other languages. Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Here's my list: 1) Peformance improvements. 2) A slicker User Interface. Ability to let the user work in an offline mode (Google Gears!) and sync periodically. 3) Good user and developer documentation. 4) Better public APIs (rework Store and Continuum) Rahul Napoleon Esmundo C. Ramirez wrote: Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. Again, just my thoughts. Cheers! Nap On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED] wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
1. +1 on distributed builds, along with examples on the 2 main use cases I see for distributed builds: a. building on many platforms for native builds that need multiple distributions. b. distribute the build across many machines to decrease the latency of building everything. 2. +1 on the docs comment below. 3. As to slicker UI, I'm not sure it's as necessary, and there's nothing stopping 1.x from getting a better UI. The bigger issues for me are: a) better co-ordination of reports/dashboards b) integrations with various other systems and dashboards and monitors (mylyn, jira, etc.) 4. Full configuration of the bootstrapping/staging of the build environment. I'm still experimenting with the current mechanisms, but I think it still needs work. 5. Apart from distributed builds, I think we need parallel building of mutually independent projects. I care less about the underlying technologies because most people won't be adding osgi or plexus or picocontainer components willy- nilly. I would replace plexus if it is deficient, but unless there's a compelling reason to switch, I wouldn't work at it too hard. For example, if it was based on Tapestry (not a plug, just an example), then moving to tapestry-ioc would make sense because t5 comes with it, it's based on that model, and it cleanly integrates with spring for extension. In that case, however, it's a change for convenience. I'd be even happier if such a switch of any given subsystem was because of a solid decision of either defect in the current approach, or improvement in the new one. Spring makes me a bit woodgy because while it's an IoC container, it's not really (in my experience) a great plug-in system. An infrastructure around a plugin lifecycle would need to be built on or (3rd party) added to spring to make it really useable that way. Christian. On 7-Feb-08, at 21:56 , Rahul Thakur wrote: Here's my list: 1) Peformance improvements. 2) A slicker User Interface. Ability to let the user work in an offline mode (Google Gears!) and sync periodically. 3) Good user and developer documentation. 4) Better public APIs (rework Store and Continuum) Rahul Napoleon Esmundo C. Ramirez wrote: Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. Again, just my thoughts. Cheers! Nap On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED] wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
groupID for SUN web service developer pack Jars ?
Hello, I need some jars from archived SUN WSDP ( http://java.sun.com/webservices/downloads/1.5/index.html) What is the recommended groupId for such jars ? For example, xmlsec.jar is a sun-repackaged apache xml-security. - com.sun.xmlsec ? - com.sun.org.apache.xmlsec (repository allready contains com/sun/org/apache/jaxp-ri/) - ?? Nico
Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
+0 I'm concerned about the omission on ARCHETYPE-116 and -117 as they are changes to existing behaviour (so, for example, the getting started guide in the docs will be wrong). However, they are only minor inconveniences so I think as long as alpha-2 is kept to the current small set of issues I think it's fine to proceed. I'll do some additional testing on docs that refer to archetypes when I get a chance. Aside from that, looks great - nice work Raphaël :) Cheers, Brett On 02/02/2008, at 11:25 AM, Raphaël Piéroni wrote: Hi, Here comes the time for calling the first release of the Maven Archetype plugin version 2.0-alpha-1. Staging repo: http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/ Staging site: No staging site now, the new documentation is not yet written. Its is planed for version 2.0-alpha-2. Vote open for 96 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mirroring question
Classification: UNCLASSIFIED Good afternoon I have a requirement to provide a mirror of http://repo1.maven.rg/maven2/ on our secure internal site. A couple of basic questions; can we receive permission to do this and if so what is the easiest way to accomplish this. ( I am new at this). What else do you require from us? Our internal site as mentioned is a secure site with no connection whatsover to the internet. Appreciate your earliest response. Cheers, Lisa Lisa Tiffney www.cse-cst.gc.ca Communications Security Establishment (CSE) Ottawa, On [EMAIL PROTECTED] 613-991-7854 613-668-2469(cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r619216 - /maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt
I don't understand this change. Aren't these two configuration parameters mutually exclusive? archive/manifestFile Says to use this manifest file useDefaultManifestFile Says to use a manifest file from the default location [EMAIL PROTECTED] wrote: Author: olamy Date: Wed Feb 6 15:15:16 2008 New Revision: 619216 URL: http://svn.apache.org/viewvc?rev=619216view=rev Log: fix documentation Modified: maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt Modified: maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt URL: http://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt?rev=619216r1=619215r2=619216view=diff == --- maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt (original) +++ maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt Wed Feb 6 15:15:16 2008 @@ -48,6 +48,7 @@ artifactIdmaven-jar-plugin/artifactId ... configuration + useDefaultManifestFiletrue/useDefaultManifestFile archive manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile /archive -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring question
http://maven.apache.org/guides/mini/guide-mirror-settings.html On Feb 7, 2008 10:39 AM, Tiffney, Lisa S. [EMAIL PROTECTED] wrote: Classification: UNCLASSIFIED Good afternoon I have a requirement to provide a mirror of http://repo1.maven.rg/maven2/ on our secure internal site. A couple of basic questions; can we receive permission to do this and if so what is the easiest way to accomplish this. ( I am new at this). What else do you require from us? Our internal site as mentioned is a secure site with no connection whatsover to the internet. Appreciate your earliest response. Cheers, Lisa Lisa Tiffney www.cse-cst.gc.ca Communications Security Establishment (CSE) Ottawa, On [EMAIL PROTECTED] 613-991-7854 613-668-2469(cell) - 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: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
Sorry Raphael, I meant to vote, but lost the mail thread. I'm +1 for an alpha release. Thanks for the hard work! -john On Feb 6, 2008, at 1:40 PM, Raphaël Piéroni wrote: Hi, To sum up the vote for now: Binding (PMC) : Arnaud Non Binding (Committer) : Mauro (still not on the list), Milos, Raphaël Non Binding (User) : checked against the list in http://svn.apache.org/repos/asf/maven/pom/trunk/maven/pom.xml I am unsure the vote as passed. According to http://www.apache.org/foundation/voting.html there is 4 +1 votes, but only one from a PMC, and if I have correctly understood the other are indicative. Which mean I two PMC votes more to release. Is there any other PMC member interested to test and vote? Regards, Raphaël --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: groupID for SUN web service developer pack Jars ?
maybe com.sun.org.apache.xmlsec but doesnt really matter that much On Feb 7, 2008 2:36 AM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I need some jars from archived SUN WSDP ( http://java.sun.com/webservices/downloads/1.5/index.html) What is the recommended groupId for such jars ? For example, xmlsec.jar is a sun-repackaged apache xml-security. - com.sun.xmlsec ? - com.sun.org.apache.xmlsec (repository allready contains com/sun/org/apache/jaxp-ri/) - ?? Nico -- 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: @aggregator mojo annotation
We know that the documentation, specially the javadoc, is not perfect, present or uptodate. Well, I feared that ;-) My primary goal was to stress that it would be worth the pain to maintain the javadoc right from the beginning (instead of fixing bugs afterwards). From my personal experience, writing doc in parallel as one writes code is less painful than having to write it all at once for an entire API. If the API is not stable but frequently changes during development, fine, update the javadoc, too, such that others always know what it does right now. In the end, it's just a matter of good habits. Do you have special ideas to improve the doc? As I said, some javadocs for those classes that plugin developers tend to use would be nice. I writed in the past some Plugins Cookbook. Maybe we could add more. More doc is always good but I think there are two different kinds of documentation to keep in mind. A cookbook is usually something that answers questions like How do I...? whereas the other part of questions starts like What does Maven...?. At the end of the day, when a plugin developer starts his IDE to go coding, he will appreciate a proper javadoc attachment for all his dependencies such that he can properly fulfill his part of the contract with the Maven APIs. Of couse, one needs as well a description of the big picture (where cookbooks can help) but javadocs are the basis to build upon (a picture without details is quite uninteresting). agree and patches are always welcome :) I think I got it ;-) Nevertheless, I still believe that there are code parts that are best documented by the responsible developers because what kind of documentation could I contribute by just looking at the source for say MavenProject.getArtifact() without having an in-depth understanding of Maven's guts? Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r619216 - /maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt
Oups my bad you're right. I will revert this. Thanks, -- Olivier 2008/2/7, Dennis Lundberg [EMAIL PROTECTED]: I don't understand this change. Aren't these two configuration parameters mutually exclusive? archive/manifestFile Says to use this manifest file useDefaultManifestFile Says to use a manifest file from the default location [EMAIL PROTECTED] wrote: Author: olamy Date: Wed Feb 6 15:15:16 2008 New Revision: 619216 URL: http://svn.apache.org/viewvc?rev=619216view=rev Log: fix documentation Modified: maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt Modified: maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt URL: http://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt?rev=619216r1=619215r2=619216view=diff == --- maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt (original) +++ maven/shared/trunk/maven-archiver/src/site/apt/examples/manifestFile.apt Wed Feb 6 15:15:16 2008 @@ -48,6 +48,7 @@ artifactIdmaven-jar-plugin/artifactId ... configuration + useDefaultManifestFiletrue/useDefaultManifestFile archive manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile /archive -- 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]
Re: @aggregator mojo annotation
Vincent Siveton wrote: Yep see for instance MJAVADOC-171 Based on some simple experiments on my machine, the fix for this is simply to drop @aggregator; it's broken... (at least for reporting plugins that fork lifecycles like javadoc, jxr and surefire), and its effect can be easily simulated in normal plugin-level code. I've posted these remarks in the comments to MJAVADOC-171 and MJAVADOC-137 (which has 13 votes). build due to the @aggregator stuff. In MJAVADOC-137, Benjamin proposed to create an AggregatorJavadoc. IMHO he is on the right way. WDYT? I like John Allen's strategy, recommended here: http://jira.codehaus.org/browse/SUREFIRE-348 He suggests a separate mojo (blah:aggregate) that aggregates *data* that can be run at various levels of the hierarchy. Then the reporting plugins can/should remain ignorant about aggregation. This seems like the right choice for test results, but maybe not a good idea for sources. At any rate, the aggregate option does 99% of what's needed right now AFAIK. For now, reporting plugins that need forked lifecycles should just drop @aggregator and simulate its effect with an aggregate parameter; then the first line of your executeReport method should be: if (aggregate !project.isExecutionRoot()) return;. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (29 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
