Release jdepend-maven-plugin as 2.0

Is it possible that somebody do the new release of this plugin ? I'm waiting a JDepend release first to release my maven-dashboard-plugin because i have a snapshot dependency on it. I have made an issue in Jira (MOJO-828) to make a release. Thanks, David Vicente -- View this message in contex

Re: how we handle JIRA versions

I hesitate to comment, as I'm not a team member here, but the important thing in Scrum is the timebox, as well as the features/ issues. But if you run up against the timebox, you drop lower priority features into the next sprint. This ensures regular releasing, which ensures feedback, yadd

Re: how we handle JIRA versions

the changes report does include that, but I'm not sure how complete it is. On 02/08/2007, at 4:24 PM, [EMAIL PROTECTED] wrote: Does anyone know if there is a mvn plugin to generate release note reports for mvn site from a jira version? This would be really useful IMO. Was thinking about t

Re: What is Archiva.NEXT ?

Joakim? On 31/07/2007, at 5:12 PM, Brett Porter wrote: one separate question on this: which is the relevant JIRA issue? is it MRM-308, MRM-211, or are both now outdated and a new one needed? On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:

Re: how we handle JIRA versions

Does anyone know if there is a mvn plugin to generate release note reports for mvn site from a jira version? This would be really useful IMO. Was thinking about this for a while... Should be easy enough to impl... But does it already exist? --jason -Original Message- From: Jason van

Re: how we handle JIRA versions

On 02/08/2007, at 2:02 PM, Brian E. Fox wrote: It'd be nice to enforce it now, but I'm not prepared for that kind of pain :) If someone else who's done more jira workflowy things wants to try their hand, please do. Otherwise, I figure if we at least have a stated pattern in agreement, if we see

Re: RDF/XML For Repository Information

Okay. I see where you are coming from. If we are using multiple datasources - traditional pom object hierachy, RDF, Lucene index, XML stores - then we need a 1) common API (for application developers); 2) SPI (from Maven); 3) adapters (from framework developers). The SPI would need (at a minimum) t

Re: Announcing Mavenizer 1.0.0-alpha-1

Hi Cédric, Looks very cool. Nice work! I was wondering if you've seen the maven-shared-jar component? http:// maven.apache.org/shared/maven-shared-jar/ This seems like something you could use (and if you have some additional features, as it appears you do, you might contribute them back).

RE: how we handle JIRA versions

>It'd be nice to enforce it now, but I'm not prepared for that kind of >pain :) If someone else who's done more jira workflowy things wants >to try their hand, please do. Otherwise, I figure if we at least have >a stated pattern in agreement, if we see regular violations we should >either r

Re: how we handle JIRA versions

On 02/08/2007, at 1:52 PM, Jason van Zyl wrote: I'd encourage us sharing a good Mylyn set up and putting it on the web site to encourage this consistency, but I think it's unreasonable to mandate it. Why? It's free and it's the best way to keep some level visibility. For people submitt

Re: how we handle JIRA versions

On 1 Aug 07, at 11:37 PM 1 Aug 07, Brett Porter wrote: On 02/08/2007, at 1:22 PM, Jason van Zyl wrote: All looks good, my only comments are I think the notions in Scrum like Sprints for a release are good like the idea of fixing the set of issues and sticking with it for the Sprint. Sensi

Two week sprints on Continuum Beta releases?

Hi, How do people feel about planning betas to fit into: Aug 15, Aug 29, Sep 12, Sep 26? (for releases, votes are the monday before) If so, is the current beta-2 list achievable by Aug 15? Looks like it needs to be trimmed (and we also have 11 unscheduled to find a home for) Cheers, Brett

Re: how we handle JIRA versions

On 02/08/2007, at 1:22 PM, Jason van Zyl wrote: All looks good, my only comments are I think the notions in Scrum like Sprints for a release are good like the idea of fixing the set of issues and sticking with it for the Sprint. Sensible patterns and there's already literature on that. So

Re: how we handle JIRA versions

All looks good, my only comments are I think the notions in Scrum like Sprints for a release are good like the idea of fixing the set of issues and sticking with it for the Sprint. Sensible patterns and there's already literature on that. So in any parts you're talking about planning I thin

Re: Archiva releases (Take 2)

I'd be happy to run some tests on Tomcat post beta-1 as well. I've spent way too much time battling these things in a past life not to have learned something that might be helpful :) Anyone here deploying to something other than Tomcat? We have Jetty5 (via appserver) and 6 (via plugin) cove

Re: RDF/XML For Repository Information

On 1 Aug 07, at 4:39 PM 1 Aug 07, Shane Isbell wrote: To clarify: NMaven uses RDF for its local repository store (and has abstractions of an AssemblyResolver/ProjectDao for the API). It does not require that the remote repository contain RDF, but rather parses and stores the information fro

Re: how we handle JIRA versions

On 02/08/2007, at 5:31 AM, Dennis Lundberg wrote: Excellent stuff Brett. Let me know if I can help. Most of this is equally important for plugins and other maven sub projects. We should try to make an additional, more general, description of "versions" that is not tied to MNG. Agreed, I

M2Eclipse plugin issue.

Hi, I'm using Maven 2.0 Integration (0.0.9) plugin in my Eclipse 3.2.2. The project I'm trying to build using the plugin has prerequisites tag checking for maven version 2.0.6 or higher. I can build the maven project independently fine, but trying to build using the maven plugin in Eclipse the ch

Re: [VOTE] Release maven-docck-plugin 1.0-beta-2

+1 Vincent 2007/7/30, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi, > > I'd like to release maven-docck-plugin 1.0-beta-2. It has been 9 months > since the last release. > > Release Notes: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11361&styleName=Html&version=13021 > > Tag: > http

Re: RDF/XML For Repository Information

To clarify: NMaven uses RDF for its local repository store (and has abstractions of an AssemblyResolver/ProjectDao for the API). It does not require that the remote repository contain RDF, but rather parses and stores the information from the remote pom artifact into the RDF store. There is also a

Re: how we handle JIRA versions

Excellent stuff Brett. Let me know if I can help. Most of this is equally important for plugins and other maven sub projects. We should try to make an additional, more general, description of "versions" that is not tied to MNG. I have a couple of questions, see inline... Brett Porter wrote:

Re: RDF/XML For Repository Information

A couple more points I thought of: There is another implementation that uses JSR 170 so it would be very hard to have any level of interoperability without an API. I certainly don't want that being RDF. There are plenty of good tools that can be leveraged, for example I use Lucene because

Re: [MNG-3043] Allow 'mvn test' to work with test-jar dependencies in a reactor

Hi Jamie, Please, look at this issue: http://jira.codehaus.org/browse/MJAR-75 (Jason - please, look at this issue / patch) I think that If it is applied and you do the tests after "package" phase (run mvn package to fire the tests), the test's will use the "new" jar. Thanks, Piotr Tabor

[MNG-3043] Allow 'mvn test' to work with test-jar dependencies in a reactor

I think this bug is related to an issue I'm currently having but I'd like to confirm. >From the Getting Startedpage there's mention that when performing a multi-module build that "it is not required that you run install to successfully per

Re: RDF/XML For Repository Information

On 1 Aug 07, at 12:25 AM 1 Aug 07, Shane Isbell wrote: I would like to see if there is any general interest from the Maven community in using RDF for storing and retrieving of repository information. As the only means, and not accessed via some API shielding the underlying store then my v

how we handle JIRA versions

Hi, A while back I promised to write up what we are doing with jira versions now, and finally got around to it. In the process, I came up with a couple of tweaks we could make (see "actions"). Here it is in point form - does everyone agree this is the process we are following now? Missing

Defining a custom lifecycle

Hi all, Is it possible to develop a plugin that defines a custom type of artifact (a "test campaign" in our case), a custom lifecycle (with, for examples, phases such as "pre-start-servers", "start-servers", "post-start-servers", "pre-initialize-environment", "initialize-environment", etc...) and