ot recompile or repackage anything.
>> > >
>> > > --jason
>> > >
>> > >
>> > > On Jan 29, 2007, at 6:23 PM, Brian E. Fox wrote:
>> > >
>> > > > I can think of several use cases for this. The most obvious
>> would b
use cases for this. The most obvious would
> > > be the
> > > ability for jar to determine if compile or resources actually made
any
> > > changes and decide if repackaging is needed.
> > >
> > > -Original Message-
> > > From: Wendell
endell Beckwith [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 29, 2007 4:55 PM
> > To: Maven Developers List
> > Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
> > components and plugins)
> >
> > I've read the doc and the irc and whi
If it communicated
> that somewhere, then other plugins could make decisions.
>
> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 30, 2007 10:46 AM
> To: Maven Developers List
> Subject: Re: [PROPOSAL] maven-build-context (Shared c
uesday, January 30, 2007 10:46 AM
> To: Maven Developers List
> Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
> components and plugins)
>
> One important thing to remember is that this is a build-time context,
> not a database or other type of persistent s
could make decisions.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 30, 2007 10:46 AM
To: Maven Developers List
Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
components and plugins)
One important thing to remember is that thi
, 2007 10:46 AM
To: Maven Developers List
Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
components and plugins)
One important thing to remember is that this is a build-time context,
not a database or other type of persistent storage. If you wanted to
detect farthest-progress
-Original Message-
> From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 29, 2007 4:55 PM
> To: Maven Developers List
> Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
> components and plugins)
>
> I've read the doc and the irc and w
resources actually made any
changes and decide if repackaging is needed.
-Original Message-
From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
Sent: Monday, January 29, 2007 4:55 PM
To: Maven Developers List
Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
components and
4:55 PM
To: Maven Developers List
Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven
components and plugins)
I've read the doc and the irc and while I can see the benefit to a
shared
context, I'm curious as to whether the current pressing need is coming
more
from ma
On 29 Jan 07, at 1:54 PM 29 Jan 07, Wendell Beckwith wrote:
I've read the doc and the irc and while I can see the benefit to a
shared
context, I'm curious as to whether the current pressing need is
coming more
from maven or the kepler project?
The drive for this is generally useful, but t
As for modding the build order, I'm still not sure that's possible (or
advisable, in the larger context)...currently, I've only used the
build-context concept in maven-core as mainly a read-only data structure,
after it's setup. Are you talking about the need to inject new projects to
an existing
I was actually hoping that we could limit the downside of this through some
good design discussion. I like your idea of using some sort of
expression/container-wiring to access the shared context, though I'm not
sure how a plugin could "export" something into the shared context via
container wirin
Actually, to be perfectly honest, I haven't been actively involved with
Kepler for some time now. This proposal actually comes from a year of work
I've done for a client, where the use of a build-context-like structure has
allowed me to maintain separation of concerns between several different
plu
I have heard a lot of people ask for this kind of functionality on irc
for the last year+, and I myself have desired something similar a
couple of different times in the past.
being able to have and share state between two plugins is incredibly
useful, albeit a rather dangerous door to open up to
I've read the doc and the irc and while I can see the benefit to a shared
context, I'm curious as to whether the current pressing need is coming more
from maven or the kepler project? Doesn't matter either way just looking
for the origin of the pain. This proposal looks to satisfy some of the OS
For convenience, I'm inlining the document here. If anyone comments directly
in this thread, I'll try to keep the wiki page up to date. I'll also try to
copy over feedback on the wiki page here.
-j
=
1. Background A. Shared Context in Systems of Interchangeable Components
M
Hi everyone,
I wanted to propose a new feature for Maven 2.1 (trunk). I think quite a few
people have run into something like this before, but I've come across a need
to detect some advanced build configuration using plugins and/or custom
components at the beginning of the build, and use that det
18 matches
Mail list logo
