Re: Default plugin execution id

Brian E. Fox wrote: > I think we've gone way off the rails here. I see there's a proposal but > haven't reviewed it yet. > > The first portion of this discussion was rather small in scope: > Currently default executions of plugins have a null id. The null is used > to indicate the default config f

Re: overriding via a profile

On Wed, Oct 29, 2008 at 4:19 PM, Nick Pellow <[EMAIL PROTECTED]> wrote: > Hi, > > If a plugin is defined in the normal build section of a pom and has defined > a specific execution, is it possible to override this execution by defining > the same plugin in a profile? > > The plugin I am working on,

Re: Apache Portable Runtime artifacts

Bojan Smojver wrote: > On Mon, 2008-11-10 at 21:35 -0600, William A. Rowe, Jr. wrote: > >> wow - you plan to build itanium 32 bit? now that's one ancient piece of >> scrap metal ;-P > > http://en.wikipedia.org/wiki/IA-32 Very interesting --- thanks for the link :) -

Re: overriding via a profile

A concrete manifestation of this problem is outlined here: http://forums.atlassian.com/thread.jspa?messageID=257293240 Ideally - could we add another sub-element to the element which decides whether or not to merge the configuration defined in the profile with that in the default definition

Re: Apache Portable Runtime artifacts

Max Bowsher wrote: > > Oops, I didn't communicate clearly. What I meant was that on a typical > system, depending on what piece of software you ask, you will get > different answers, for example, dpkg --print-architecture showing i386, > Java's os.arch showing i586 and uname -m showing i686. Hence

Re: maven-release-plugin: useReleaseProfile - how does this work to add sources and javadocs?

On Tue, Nov 11, 2008 at 1:23 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > The release profile is built into the superpom. > http://svn.eu.apache.org/viewvc/maven/components/branches/maven-2.1.x/ma > ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?vi > ew=markup Thanks. Now

RE: maven-release-plugin: useReleaseProfile - how does this work to add sources and javadocs?

The release profile is built into the superpom. http://svn.eu.apache.org/viewvc/maven/components/branches/maven-2.1.x/ma ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?vi ew=markup -Original Message- From: Barrie Treloar [mailto:[EMAIL PROTECTED] Sent: Monday, Novem

maven-release-plugin: useReleaseProfile - how does this work to add sources and javadocs?

I'm looking at the code for maven-release-plugin and I can't see how it add sources and javadocs. RunPerformGoalsPhase is about the only interesting place that isUseReleaseProfile() is used and all it does is add "-DperformRelease=true" to additionalArguments which is then passed into mavenExecuto

Re: Apache Portable Runtime artifacts

Alan D. Cabrera wrote: > On Nov 9, 2008, at 6:43 AM, Max Bowsher wrote: >> Alan D. Cabrera wrote: >>> On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote: >> (There's also the question of what architecture/processor naming scheme >> to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg >> --pr

Re: overriding via a profile

Hi Brian, Even changing the executions to something else doesn't appear to work. Is there anything my plugin can do, to prevent the executions in the default plugin definition being merged with those defined in a profile? Cheers, Nick On 30/10/2008, at 12:49 AM, Brian Fox wrote: You can't

Re: new plugin proposal: maven-setup-plugin

On Tue, Nov 11, 2008 at 5:26 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > This sounds useful to try. > > There are two things I'd do if you're building this: > - be cautious about letting it get too complicated (trying to be everything > to everyone) > - break the parts out into components that ca

Re: Default plugin execution id

I don't see that these things can be separated. An execution is tied to one and only one phase. If a plugin invokes multiple goals in different phases (and given that two of our most prominent plugins do just that) it does not make sense to have one execution that spans two or more phases. So yo

Re: Default plugin execution id

Sorry the mail got sent too early 2008/11/10 Stephen Connolly <[EMAIL PROTECTED]> > What if I do > > > maven-compiler-plugin > > > default-lifecycle:testCompile > pre-integration-test > > Now when we get emails on the list asking why no tests are run during the test

Re: new plugin proposal: maven-setup-plugin

This sounds useful to try. There are two things I'd do if you're building this: - be cautious about letting it get too complicated (trying to be everything to everyone) - break the parts out into components that can be reused (eg, IDE integration). These could perhaps be brought back into Mav

Re: svn commit: r712848 - in /maven/mercury/trunk/mercury-maven/mercury-compare-plugin: ./ src/main/java/org/sonatype/maven/plugins/crypto/ src/main/java/org/sonatype/maven/plugins/mercury/ src/main/j

Why not package : org.apache.maven ? 2008/11/10 <[EMAIL PROTECTED]>: > Author: ogusakov > Date: Mon Nov 10 14:02:55 2008 > New Revision: 712848 > > URL: http://svn.apache.org/viewvc?rev=712848&view=rev > Log: > refactor > > Added: > > maven/mercury/trunk/mercury-maven/mercury-compare-plugin/s

RE: Default plugin execution id

Well now you've crossed over to http://jira.codehaus.org/browse/MNG-3203 which is a separate issue imo. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 4:41 PM To: Maven Developers List Subject: Re: Default plugin execution id We need t

Re: Default plugin execution id

What if I do maven-compiler-plugin default-lifecycle:testCompile pre-integration-test 2008/11/10 Brian E. Fox <[EMAIL PROTECTED]> > Again, why? It's not possible now so it's obviously working for most > cases today. > > -Original Message- > From: Stephen Conn

Re: Default plugin execution id

We need to split out the different executions somehow. If we use a sequence number: 1. How do I deterministically know what sequence number to use? 2. What happens when a newer version of the lifecycle introduces an earlier execution? On my count, that leaves a sequence number nearly dead If we

RE: Default plugin execution id

Again, why? It's not possible now so it's obviously working for most cases today. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 4:27 PM To: Maven Developers List Cc: Maven Developers List Subject: Re: Default plugin execution id well

Re: Default plugin execution id

well you need to separate out the executions by phase in case somebody decided to change the phase specified in the execution Sent from my iPod On 10 Nov 2008, at 21:29, "Brian E. Fox" <[EMAIL PROTECTED]> wrote: I don't see how phase is really needed. It applies to only two plugins that I

RE: Default plugin execution id

I don't see how phase is really needed. It applies to only two plugins that I can think of, compiler and resources, and this is a bigger problem for a 3.x timeframe. I think that something simple can cover 90% of the cases and be doable in 2.x -Original Message- From: Paul Gier [mailto:[E

Re: Default plugin execution id

-1 Handling one offs from the command line is not what we want. Executions embedded into the lifecycle are meant to be just that a way to include many things you need in the lifecycle. If you need something different on a per situation basis it should be a plugin configuration that you ne

Re: Default plugin execution id

2008/11/10 Paul Gier <[EMAIL PROTECTED]> > Yes, you're right, I think this is getting more complicated that it needs > to be. > Either of these is fine with me: > default-lifecycle:goal -1 > or > default-lifecycle:phase +1 > > Either of them should be pretty easy to implement, and pretty u

Re: Default plugin execution id

Yes, you're right, I think this is getting more complicated that it needs to be. Either of these is fine with me: default-lifecycle:goal or default-lifecycle:phase Either of them should be pretty easy to implement, and pretty unlikely to cause any new problems. If we just use default by itself,

Re: Default plugin execution id

2008/11/10 Paul Gier <[EMAIL PROTECTED]> > > Adding the phase to the ID doesn't prevent name conflicts, since you can > have the same goal twice in the same phase. I would guess it's actually be > more common to have a goal twice in the same phase vs. in different phases. > So I think the goal n

Re: Default plugin execution id

I still think that the id has to include the phase that the execution is bound to. I'm not tied to specification of the packaging, but I do think that the phase (given that an execution is associated with one and only one phase) has to be part of the id for *lifecycle introduced* executions. -Ste

Re: Default plugin execution id

2008/11/10 Paul Gier <[EMAIL PROTECTED]> > Stephen Connolly wrote: > >> 2008/11/10 Paul Gier <[EMAIL PROTECTED]> >> >> Plus sequence number is non-deterministic. Also, you are forgetting... >> this >> is not the id of executions *defined within the pom* but it's the id of >> executions *defined b

RE: Default plugin execution id

I think we've gone way off the rails here. I see there's a proposal but haven't reviewed it yet. The first portion of this discussion was rather small in scope: Currently default executions of plugins have a null id. The null is used to indicate the default config for a plugin across all execution

Re: Default plugin execution id

I've updated the page to include my counter-proposal 2008/11/10 Paul Gier <[EMAIL PROTECTED]> > I created a user proposal to hopefully clarify the issue and my proposed > solution: > http://docs.codehaus.org/display/MAVENUSER/Default+Plugin+Execution+IDs > >

Re: Default plugin execution id

Stephen Connolly wrote: 2008/11/10 Paul Gier <[EMAIL PROTECTED]> What about adding new syntax to the goal string? So that from the command line you could write something like this to refer to specific execution configs: mvn eclipse:eclipse{execution-1} or mvn eclipse:eclipse{execution-2} H

Re: Default plugin execution id

2008/11/10 Paul Gier <[EMAIL PROTECTED]> > Stephen Connolly wrote: > >> 2008/11/10 Paul Gier <[EMAIL PROTECTED]> >> >> What about adding new syntax to the goal string? So that from the >>> command >>> line you could write something like this to refer to specific execution >>> configs: >>> >>> mv

RE: Notes from Build Tools BOF at ApacheCon US 2008

>There's still a lot of confusion and skepticism about things related >to 3.0, such as: >- how does work on 2.[0|1].x get migrated over there given the code is >becoming so different >- what work is actually happening on it, is there a roadmap >- is it every going to be released. Not so much q

Mercury status and roadmap

It has been a while since I started working on Mercury, and I think it's time to update the community on where it is and where it is going. Short history: mercury was conceived as a green field implementation of Artifact resolver plus Jetty based transactional transport. Those two goals natura

Re: Default plugin execution id

Stephen Connolly wrote: 2008/11/10 Paul Gier <[EMAIL PROTECTED]> What about adding new syntax to the goal string? So that from the command line you could write something like this to refer to specific execution configs: mvn eclipse:eclipse{execution-1} or mvn eclipse:eclipse{execution-2} H

Re: Default plugin execution id

2008/11/10 Paul Gier <[EMAIL PROTECTED]> > What about adding new syntax to the goal string? So that from the command > line you could write something like this to refer to specific execution > configs: > > mvn eclipse:eclipse{execution-1} > or > mvn eclipse:eclipse{execution-2} > How would that

Re: Default plugin execution id

I created a user proposal to hopefully clarify the issue and my proposed solution: http://docs.codehaus.org/display/MAVENUSER/Default+Plugin+Execution+IDs Paul Gier wrote: Ok thanks, I attached a patch which is just a one line change to set the execution id to "default" if nothing is specified.

Re: Default plugin execution id

Christian Schulte wrote: Stephen Connolly wrote: AFAIK, The execution id refers only to a specific plugin, and each execution can only match a specific phase... so I don't see the need to tie the execution to a goal name, neither to the plugin name... What I see as bind important is if the plu

Re: Apache Portable Runtime artifacts

I suggest you look at Mark's NAR work: http://java.freehep.org/freehep-nar-plugin/intro.html I'm talking with Mark to try and make the NAR the standard way to work with native code so I highly recommend you follow the way he has named binaries as part of his work in creating/maintaining the

Problem with MavenEmbedder

Hello, I'm having a problem with MavenEmbedder and was hoping someone could help me out. I'm trying to execute the following command: "mvn help:describe-Dplugin=help -Dfull". To do this, I use MavenEmbedder and C

Re: compiler plugin: separate test compiler configuration

It did not work for me, and this might have been the reason. Anyway, I changed the compiler plugin and you can now use testSource and testTarget withing the same execution, if you'd like to. Thank you for the update, Oleg � wrote: Oleg Gusakov wrote: Such contriction will not work. The p

Re: Default plugin execution id

2008/11/10 Christian Schulte <[EMAIL PROTECTED]> > Stephen Connolly wrote: > > So, how did we get here: the use case that triggered all of this is > > specifying a different configuration for the maven-compiler-plugin when > > executed during the test-compile phase (to allow unit tests to be > com

Re: Default plugin execution id

Stephen Connolly wrote: > Christian, > > Please do not take offense, but I think that you do not understand what is > being discussed/proposed. > > Here is my understanding: > > Maven has the concept of a lifecycle. Each lifecycle consists of a sequence > of phases. When you invoke Maven with a

RE: compiler plugin: separate test compiler configuration

Oleg Gusakov wrote: > Such contriction will not work. The problem is in the way compiler > plugin is instantiated: compiler environment is created, and them the > same instance is reused for test-compiler, sticking to the existing > plugin configuration. Execution does not get a new instance of as

Re: Default plugin execution id

2008/11/10 Stephen Connolly <[EMAIL PROTECTED]> > > > 2008/11/10 Christian Schulte <[EMAIL PROTECTED]> > > Stephen Connolly wrote: >> > AFAIK, >> > >> > The execution id refers only to a specific plugin, and each execution >> can >> > only match a specific phase... so I don't see the need to tie t

Re: Default plugin execution id

2008/11/10 Christian Schulte <[EMAIL PROTECTED]> > Stephen Connolly wrote: > > AFAIK, > > > > The execution id refers only to a specific plugin, and each execution can > > only match a specific phase... so I don't see the need to tie the > execution > > to a goal name, neither to the plugin name..