Atlassian to bring Maven Clover plugin development in-house

View: New views
2 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Re: Atlassian to bring Maven Clover plugin development in-house

by Carlos Sanchez-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

see http://jira.codehaus.org/browse/MNG-2316

On 8/30/07, Jerome Lacoste <jerome.lacoste@...> wrote:

> On 8/30/07, Brett Porter <brett@...> wrote:
> > Yeah, we should do the same with the recently departed antlr plugin
> > too. Move trunk to /retired/* (original tags would remain in the
> > original place) would get my vote.
>
> +1 for retired
>
> On the Debian package management system (and probably in others)
> there's a way to define a package as providing another package's
> functionality, allowing superseding of information.
>
> Could there be a somewhat identical feature in maven which would
> enable it to automatically detect that the plugin has now moved
> somewhere else? I am not sure how this would fit with the current
> implementation and the implicit location of the packages on the remote
> repositories. As maven searches in the old location, there would need
> to be some sort of link from the old to the new, which somewhat
> inverts the dependency between the superseder and deprecated as used
> in the deb format.
>
> Maybe a feature to implement in the repository manager, using some sort of
> <overrides>
>   <override>
>     <groupId>...
>     <artifactId>...
>     <version>[1.0; 3.0(...
>   </override>
> in the overriding POM
>
> and some backlinks added by the repo manager when the overriding POM
> is added to the repository ?
>
> I would love maven to tell me: warning this dependency is obsolete.
>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


RE: Atlassian to bring Maven Clover plugin development in-house

by Brian E Fox :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The consensus seemed to be to move clover to /retired. This is now done.

-----Original Message-----
From: Jerome Lacoste [mailto:jerome.lacoste@...]
Sent: Thursday, August 30, 2007 11:14 AM
To: Maven Developers List
Subject: Re: Atlassian to bring Maven Clover plugin development in-house

On 8/30/07, Brett Porter <brett@...> wrote:
> Yeah, we should do the same with the recently departed antlr plugin
> too. Move trunk to /retired/* (original tags would remain in the
> original place) would get my vote.

+1 for retired

On the Debian package management system (and probably in others)
there's a way to define a package as providing another package's
functionality, allowing superseding of information.

Could there be a somewhat identical feature in maven which would
enable it to automatically detect that the plugin has now moved
somewhere else? I am not sure how this would fit with the current
implementation and the implicit location of the packages on the remote
repositories. As maven searches in the old location, there would need
to be some sort of link from the old to the new, which somewhat
inverts the dependency between the superseder and deprecated as used
in the deb format.

Maybe a feature to implement in the repository manager, using some sort
of
<overrides>
  <override>
    <groupId>...
    <artifactId>...
    <version>[1.0; 3.0(...
  </override>
in the overriding POM

and some backlinks added by the repo manager when the overriding POM
is added to the repository ?

I would love maven to tell me: warning this dependency is obsolete.

Cheers,

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

< Prev | 1 - 2 | Next >