I think Ben suggested that too. That's probably a better idea, yes :)
> What about introducing an attribute on the element?
> Like "public" for example?
>
>
> [...]
>
> By default, a goal would be private.
>
> -Vincent
>
>
>
> --
wrote on 01/09/2003 04:55:41 PM:
>
>
> > -Original Message-
> > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > Sent: 01 September 2003 07:36
> > To: 'Maven Developers List'
> > Subject: RE: plugin version upgrading/downgrading
> >
> &g
ECTED]
> > Sent: 01 September 2003 05:43
> > To: 'Maven Developers List'
> > Subject: RE: plugin version upgrading/downgrading
> >
>
> [snip]
>
> > > As I have mentioned before, we need to get a bit clearer about which
> > > goals can
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 01 September 2003 07:36
> To: 'Maven Developers List'
> Subject: RE: plugin version upgrading/downgrading
>
> > What about making the goal public when it has a description
>
> So as a project builds, there should only be 1 plugin of a given id
> loaded, but there may be multiple unpacked (contrary to your
> statement).
Yep. Sorry, I was thinking that using dependencies didn't unpack it, but it
does.
What should really happen is every plugin you ever install should
Brett Porter wrote:
Is there some particular use case for allowing multiple plugins with
different versions confusing things?
Maybe if it comes installed with one version and you get a project with a
dependency on a newer one?
I think dying a horrible death is a great thing to do if more than o
> What about making the goal public when it has a description
> element defined? I had reported a bug (dunno if it had been
> fixed) where currently the "maven -g" displays "null" as the
> description for non-public goals (i.e. those that have no
> description). I believe it was implemented lik
Brett Porter <[EMAIL PROTECTED]> wrote on 01/09/2003 09:01:49 AM:
> Hi,
>
> After doing a little with the plugin manager on the weekend, I noticed
(as I
> suspected), that plugin "upgrading" (or downgrading via a dependency),
> doesn't do what you might expect.
Well, yes... it depends what u exp
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 01 September 2003 05:43
> To: 'Maven Developers List'
> Subject: RE: plugin version upgrading/downgrading
>
[snip]
> > As I have mentioned before, we need to get a bit clea
> Is there some particular use case for allowing multiple plugins with
> different versions confusing things?
Maybe if it comes installed with one version and you get a project with a
dependency on a newer one?
I think dying a horrible death is a great thing to do if more than one turn
up in the
I'd prefer that maven die an ungainly death if it encountered two
plugins with the same identifying mark.
The identifying mark being the "id" (groupId:artifactid:type) (type =
"plugin")
Is there some particular use case for allowing multiple plugins with
different versions confusing things?
A
Hi,
After doing a little with the plugin manager on the weekend, I noticed (as I
suspected), that plugin "upgrading" (or downgrading via a dependency),
doesn't do what you might expect.
It seems it will always load both plugins, and I suspect it will call the
latest, even when using a dependency
12 matches
Mail list logo
