Avoiding duplicate packages in different modules

There are a number of packages that are spread in different jars. As best practice and to play well with OSGi the same package shouldn't be in two modules We should copy classes to a new package, make old ones extend them and deprecate to retain compatibility. I filed it as MNG-2943 Let me know

Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: This release fixes just one critical issue: Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2 ** Bug * [MENFORCER-1] - plugin fails on jdk < 1.5 The deployments are staged here: http://people.apache.org/~brianf/staging-repo

Re: Let's release Archiva

I have my archiva deployed and running, so I can wait for a merge for any further enhancements. I allready had to adapt MRM153 patch for the "/proxy" to "/repository" URI changes. I'll follow changes made on trunk to update my snapshot, and propose patches when required. Just for my info, as I mi

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

Brian E. Fox schrieb: "This is a MUCH bigger problem than we seem to recognize. Who wants to send the email to the users@ list to tell them that, oh, yeah, they need to specify versions for all of their plugins in the POM? I'm not wild about it, but I think that's the only way out...and I'm will

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

+1 I've been using 2.2-SNAP for some time now as well, but mainly only with small test projects. On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: +1 Thought I voted but I guess not. I've been running a snapshot for a long time now anyway. A release can only help to get feedback about what

[VOTE] Release maven-dependency-tree

This release adds iterator methods that simplify the tree navigation Right now is set to 1.0-alpha-3 but has been stable for months so I'd go for 1.0-beta-1 or 1.0 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree 527390 Note that it depends on the release of the maven-p

[VOTE] Release maven-plugin-testing-harness

It adds some stub method implementations from previous releases Right now it's 1.0-beta-2 but has been pretty stable during last year, so i'd suggest releasing 1.0 and whatever is added in the future go to 1.1, 1.2, ... https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing-har

RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

+1 Thought I voted but I guess not. I've been running a snapshot for a long time now anyway. A release can only help to get feedback about what to fix. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 10:55 AM To: Maven Developers List Subject:

State of the Archiva (April 2007)

State of the Archiva (April 2007) :: PRESENT :: Work is continuing on the archiva-jpox-database branch. Many many improvements exist currently in that branch. The core / base / database changes have settled down, now the work in webapp continues to take advantage of the changes made in ar

[VOTE] maven-enforcer-plugin:1.0-alpha-2

This release fixes just one critical issue: Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2 ** Bug * [MENFORCER-1] - plugin fails on jdk < 1.5 The deployments are staged here: http://people.apache.org/~brianf/staging-repository

Re: dependency on system library (java.library.path)

Hi Joerg, our test nar goal (which we call integration test nar, since it checks tests against the jar and the native libs, will put any native libs on the java.library.parth which are (transitive) dependencies. For libs that are dependencies but that we do not build, we just wrap them in a nar

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

On 10 Apr 07, at 12:42 PM 10 Apr 07, Brian E. Fox wrote: "This is a MUCH bigger problem than we seem to recognize. Who wants to send the email to the users@ list to tell them that, oh, yeah, they need to specify versions for all of their plugins in the POM? I'm not wild about it, but I thi

RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

"So maybe we should publish far and wide the best practice of pegging the plugin version, and require it in 2.1...then write a plugin to list the available versions for a plugin, so users can check periodically. That would make life a little easier for users." +1 ---

Re: [jira] Created: (MASSEMBLY-196) use of repository assembly is no longer working

looks good, I'll take a look at it. Thanks, Brett. -john On 4/10/07, Brett Porter (JIRA) <[EMAIL PROTECTED]> wrote: use of repository assembly is no longer working --- Key: MASSEMBLY-196 URL: http://jira.codehaus.o

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

So maybe we should publish far and wide the best practice of pegging the plugin version, and require it in 2.1...then write a plugin to list the available versions for a plugin, so users can check periodically. That would make life a little easier for users. -j On 4/10/07, Jason van Zyl <[EMAIL

RE: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

"This is a MUCH bigger problem than we seem to recognize. Who wants to send the email to the users@ list to tell them that, oh, yeah, they need to specify versions for all of their plugins in the POM? I'm not wild about it, but I think that's the only way out...and I'm willing to send that email."

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

#1 gets us back into the realm of trying to decipher whether the behavior of version 2.1 has this as a *feature* or a *bug*. It's along the same lines as MASSEMBLY-194, IMO. I understand the ramifications here: Maven (at times) will automatically select the version of a plugin to use by resolving

Re: Doxia Site rendering broken

Jason van Zyl <[EMAIL PROTECTED]> writes: >talking about at the best of times so you have to help me out. >> [... cut ...] >> >> You can not load resources with the Velocity Template >> language instructions <<<#parse>>> and <<<#include>>>! >> >Again without a full explanation, or context I

Re: Let your Mojo's be Groovy baby!

very cool! Stéphane On 4/5/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Hi folks, I've just finished up the first draft of support to use Groovy for Maven plugin development, including Javadoc-based Mojo descriptor extraction. I have yet to update the site docs to cover the Mojo impl bits, but

Re: [VOTE] Release jxr 2.1

+1 (very late). Thanks a lot Dennis! Stéphane On 3/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi, I'd like to release jxr 2.1. For this release the maven-jxr library and the maven-jxr-plugin has been put together in svn, similar to what has been done with release and surefire. They wi

Re: Common base directory for staging releases

Sounds good. Stéphane On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, I wanted to setup a common base directory for staging releases so that each person doesn't have to change their setting each time they stage, or use a -D parameter. I would just like to have a commons base directory

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

+1 Brett, I think (1) is a feature. If (2) does not work, let's address it to a beta-2 please. We really need to release this, get feedback and prepare beta-2. Thanks, Stéphane On 4/8/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: +1 Dan On Friday 06 April 2007 10:55, John Casey wrote: > Hi eve

Re: dependency on system library (java.library.path)

Hello, For system libraries however the name cares when it is loaded from something that I can not control (foo-1.0.jar loads foo.dll and it can not be named foo-1.0.dll). Is there a way to put various artifacts with different versions but the same file-name into a maven repository? In other wor