Re: Let's release Archiva

On 4/12/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: only the jpox plugin should be 1.1.6, jpox must be 1.1.7 Thank you. That was the last snapshot, and "mvn release:prepare -DdryRun=true" now completes successfully. It looks like there are some models which have version 1.0.0. Do you th

Re: Forcing snapshot repositories to be disabled?

This appears to be a problem only because mvn-proxy is being used. I don't see this behavior at home. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Subscription: Design & Best Practices

Issue Subscription Filter: Design & Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques htt

Re: M206 Regression: Build is broken

Piotr Tabor napisał(a): > David J. M. Karlsen napisał(a): > >> Hi - I expirience the same - but only when running a multiproject: >> >> parent >> -ejb-project (generating ejb and ejb-client) >> -client-project (using ejb-client) >> >> If I try a multibuild it fails, if I cd into client-project

Re: Remove auto-resolution of plugin versions from Maven 2.1

I couldnt agree more with the sentiments that code in *all its guises* must be explcitly managed. you don't compile arbitrary code, don't use arbitrary compilers, don't link against arbitrary libraries... arbitrary bad. Build scripts are code, christ even my shell is a dependency to be managed (mi

RE: Remove auto-resolution of plugin versions from Maven 2.1

This pretty much describes our world too. And I couldnt agree more with the sentiments that code in *all its guises* must be explcitly managed. you don't compile arbitrary code, don't use arbitrary compilers, don't link against arbitrary libraries... arbitrary bad. Build scripts are code, christ

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

+1 John Casey wrote: > > 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. >

Re: Remove auto-resolution of plugin versions from Maven 2.1

I think it's wise to limit the use of snapshots, even to the point where we say that it's not smart to publish your snapshots to a "public" location at all. This gets a little dicey with OSS projects, since the team is so widely distributed, but just saying that the snapshot repository is not supp

Re: Remove auto-resolution of plugin versions from Maven 2.1

On 4/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take

RE: Remove auto-resolution of plugin versions from Maven 2.1

I agree. I am suggesting that it's a little too easy to use SNAPSHOTs and that all that wonderful time maven was supposed to save you in preparing releases is trumped by the time it takes to just append -SNAPSHOT to a version number. Sure, it's people abusing it, but it's easy to abuse and looks

RE: Remove auto-resolution of plugin versions from Maven 2.1

Snapshots are a very good thing for internal development. It would be impossible to manage my builds without them. I think that people using snapshots of plugins are a symptom of another problem -- long release cycles. Just because people do bad things with snapshots doesn't mean snapshots should

RE: Remove auto-resolution of plugin versions from Maven 2.1

I wrote this up here: http://jira.codehaus.org/browse/MNG-2945 -Original Message- From: Nigel Magnay [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 2:42 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 > > Here's how I deal wit

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

Joerg Hohwiller wrote: > Hi there, > > I have already used SWT and GWT together with maven. Both need native system > libraries at some specific point. This causes trouble when running code (e.g. > test-cases) with maven. The latest 3.3 release of SWT includes the library files in the JAR! I have

RE: Remove auto-resolution of plugin versions from Maven 2.1

Yes I also agree this would be handy at times. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 2:53 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Sounds like a great idea for a very useful p

Re: Remove auto-resolution of plugin versions from Maven 2.1

Sounds like a great idea for a very useful plugin. I'm sure many of us have followed this same pattern when it comes time to do a release which utilizes snapshot plugins or artifacts. Wayne On 4/12/07, Nigel Magnay <[EMAIL PROTECTED]> wrote: > > Here's how I deal with instances where I need a s

Re: Remove auto-resolution of plugin versions from Maven 2.1

John, you asked me two questions... I wish I knew how to properly handle the issue of what I will call laziness wrt reading and using documentation on the part of users. It might be helpful to add a lot more things to the FAQ (including comments about web proxies with a link to the "configuring p

Re: Remove auto-resolution of plugin versions from Maven 2.1

Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take the whole thing and put it in my svn. If not, then

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

+1 On 4/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: +1 --jason On Apr 12, 2007, at 10:13 AM, Daniel Kulp wrote: > > I'd like to release version 1.0-alpha-5 of the > maven-remote-resources-plugin. This resolves one critical bug, but > also adds some new features to make it a bit more us

Re: Remove auto-resolution of plugin versions from Maven 2.1

The big problem with baking this stuff into a maven distro is the fact that a new maven release can hose your build, and make you gunshy about ever upgrading again. I suppose this is a counter-argument to my argument about how putting the parent pom + lifecycle defs on central would make the Maven

Re: Remove auto-resolution of plugin versions from Maven 2.1

I am just a Maven user with very little understanding of Maven internals, but isn't it possible to have a date/timestamp attribute affiliated with the ? Maybe like a ? Such a timestamp could be used to force a lockdown at that time so all developers share a common set of functionality. RELEAS

Re: Remove auto-resolution of plugin versions from Maven 2.1

Maven already has the concept of super-pom with defaults, it makes sense to me to add the plugin versions as part of the defaults. You'd still have the problem of 2.1.0 may have different versions then 2.1.1 but at least you don't need to ask for each plugin. Then I'd remove the -U option and mak

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

+1 --jason On Apr 12, 2007, at 10:13 AM, Daniel Kulp wrote: I'd like to release version 1.0-alpha-5 of the maven-remote-resources-plugin. This resolves one critical bug, but also adds some new features to make it a bit more usable. Release Notes - Maven 2.x Remote Resources Plugin - Vers

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

+1 On 12 Apr 07, at 1:13 PM 12 Apr 07, Daniel Kulp wrote: I'd like to release version 1.0-alpha-5 of the maven-remote-resources-plugin. This resolves one critical bug, but also adds some new features to make it a bit more usable. Release Notes - Maven 2.x Remote Resources Plugin - Version

[VOTE] maven-remote-resources-plugin 1.0-alpha-5

I'd like to release version 1.0-alpha-5 of the maven-remote-resources-plugin. This resolves one critical bug, but also adds some new features to make it a bit more usable. Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-5 ** Bug * [MRRESOURCES-18] - Error when no '

RE: Remove auto-resolution of plugin versions from Maven 2.1

Right. My point is that regardless of what the original intention may have been, the current process facilitates laziness via SNAPSHOTs. Without them, incremental builds would be necessary, which would give fixed version numbers with known binaries. If the plan is to take actions to help prevent

RE: Remove auto-resolution of plugin versions from Maven 2.1

Snapshots are not intended to be depended on outside the context of the team working on it. Nothing released can ever had snapshot dependencies (on plugins or dependencies). I think what you are seeing is a symptom of longer release cycles. People need something fixed, they take a snapshot and move

RE: Remove auto-resolution of plugin versions from Maven 2.1

A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, then. Way too many plugins and dependencies sit in a SNAPSHOT limbo, presumably because it's simpler than cutting a release. And then SNAPSHOT to SNAPSHOT may break bu

2.3.1 update - need Windows tester

Hi, Writing quickly from Singapore transit lounge :) Can someone with Windows test out SUREFIRE-297 and 310 to see if they are still an issue? I can't reproduce on the mac, and suspect they were only issues because of the plexus-utils 1.4 upgrade (that no longer exists in any released comb

Re: Remove auto-resolution of plugin versions from Maven 2.1

Sure, my only point was that without this (and the standard packaging definitions) _nothing_ will work...it's just a gut-level uneasiness, not necessarily a big problem. On a side note, I think it'd be neat to provide a maven distro that has a small internal repo with the latest releases of the p

Re: Re: Question re: StatusCommandTckTest

the directory itself and files must be listed as an addition. Ryan Daum a écrit : Question: for non-empty directories, does the test assume that the directory itself shows up as an addition? Or just the files in it? Ryan On 4/12/07, * Ryan Daum* <[EMAIL PROTECTED]

Re: Question re: StatusCommandTckTest

Ryan Daum a écrit : On 4/12/07, *Emmanuel Venisse* <[EMAIL PROTECTED] > wrote: If it ignore the addition, it doesn't generate an error, right? So the result of the add command should return true. Actually the code in addToWorkingTree expects that for thi

Re: Question re: StatusCommandTckTest

Question: for non-empty directories, does the test assume that the directory itself shows up as an addition? Or just the files in it? Ryan On 4/12/07, Ryan Daum <[EMAIL PROTECTED]> wrote: On 4/12/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > If it ignore the addition, it doesn't gener

Re: Question re: StatusCommandTckTest

On 4/12/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: If it ignore the addition, it doesn't generate an error, right? So the result of the add command should return true. Actually the code in addToWorkingTree expects that for this addition there should be one file added. Wouldn't a better

RE: Remove auto-resolution of plugin versions from Maven 2.1

Right I get that. That would be pretty annoying. Maybe instead of a parent POM, an import facility could be used that can grab the same centralized POM (Multiple-inheritance almost :-). To John's comment, I don't see this being a big offline challenge as this centralized POM would be a relea

Re: Question re: StatusCommandTckTest

If it ignore the addition, it doesn't generate an error, right? So the result of the add command should return true. But we can add a "isAllowToAddEmptyDirectory()" method in the AddCommand and use it in ScmTestCase Emmanuel Ryan Daum a écrit : Many revision control systems (Mercurial included

RE: Remove auto-resolution of plugin versions from Maven 2.1

John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are no different than dependencies. It's very dangerous to depend on the latest version of some jar from the repo, and likewise plugins. We don't default to grabbing the LATEST dependency, the same sho

Re: Let's release Archiva

Wendy Smoak a écrit : On 4/11/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: [INFO] Can't release project due to non released dependencies : org.codehaus.mojo:jpox-maven-plugin:maven-plugin:1.1.7-SNAPSHOT:runtime in project 'Archiva Standard Reports' (org.apache.maven.archiva:archiva-report

Re: Remove auto-resolution of plugin versions from Maven 2.1

One thing I wanted to add: To me, it's critical to view your build script (or POM, or whatever binding you have to a build infrastructure) as a piece of the project code. The build - definition, shall we say? - is responsible for modifying your source code into a binary that works the way you wou

Question re: StatusCommandTckTest

Many revision control systems (Mercurial included) ignore the addition of empty directories to a repository. But the following code in StatusCommandTckTest requires that the SCM provider "pretend" to have added the directory: // /src/test/java/org ScmTestCase.makeDirectory( getUpdat

Re: Remove auto-resolution of plugin versions from Maven 2.1

Let me see if I can address everything in the thread since the last time I looked...here goes: :-) 1. Locking down on release is dangerous IMO, because it implies that you might be making a change to the build behavior at release time. In other words, these particular versions may introduce a sub

Re: Bug: Cannot grant roles

On 4/12/07, David Goemans <[EMAIL PROTECTED]> wrote: if I want to grant a new role to a user, i can't do it. If the user has already some roles, the web-frontend doesn't show any roles to grant. If the user hasn't a role. It shows me all available roles. I think it's a bug in plexus-redback, bu

RE: Remove auto-resolution of plugin versions from Maven 2.1

Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable a

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions

The idea originally was that LATEST might refer to a snapshot release, but that RELEASE was the latest plugin release. Of course, all of this completely ignores any notion of versions that have implications for backward compatibility. In the Maven 2.0.x, all plugin releases are assumed to be minor

Re: Remove auto-resolution of plugin versions from Maven 2.1

Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote: I'd

RE: Remove auto-resolution of plugin versions from Maven 2.1

I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a proj

Re: Remove auto-resolution of plugin versions from Maven 2.1

Carlos Sanchez wrote: > > I think every maven release should use a defined set of plugin versions. > That would be reproducible and close to what it's happening now. > Sounds good. So for the compile plugin if I don't specify a version I get the default that was tested as part of the release

Re: Remove auto-resolution of plugin versions from Maven 2.1

Carlos Sanchez wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. I can't really agree with this; if maven provides a set of default plugin versions, people will continue to not specify explicit versi

Re: It's time to release maven-idea-plugin

Hi Dennis, I created a new issue (MIDEA-86, patch supplied) which prevents adding the deployment descriptor for EJB modules to the IML file if it doesn't exist. This is in accordance with JEE5 where deployment descriptors are now optional. Today, it is always added, even if it doesn't exist, whic

Re: Remove auto-resolution of plugin versions from Maven 2.1

I thought release POMs were meant to resolve the issue of reproducible builds? Theoretically, when generateReleasePoms=true, release:perform will write an auxiliary POM with resolved versions for all plugins, dependencies, etc. that Maven uses in preference to the normal transformed POM. I say t

Re: OMG... mvn -X spits out soooooo much junk

On 4/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'd really like to see the logging output in Maven have some finer controls. *most* of the time I just want debugging information from my plugins, including a brief overview of the artifact they came from, the arguments to the mojo and then the