There are some cases where people need/want to have repos only for plugins,
hence the need for some form of choice.
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 09, 2008 8:03 PM
To: Maven Developers List
Subject: Re: plugin repositories (wa
On Thu, 10 Jan 2008 11:56:34 Brian E. Fox wrote:
> >there is no need for a change...
>
> I disagree. The current 2.0.x method of having separate config is just a
> major pita. Most people have them mixed (including us-Maven) and it means
> you almost always have to duplicate all your repos in both
I had a chat on #maven with someone trying to delete a folder external
to his source tree. This works fine when running the child directly, but
in a reactor build it doesn't work. I peeked at the code and was
surprised to find this:
try
{
getLog().info( "Delet
>there is no need for a change...
I disagree. The current 2.0.x method of having separate config is just a major
pita. Most people have them mixed (including us-Maven) and it means you almost
always have to duplicate all your repos in both lists. This provides a simple
way to minimize the conf
On Thu, 10 Jan 2008 04:21:32 John Casey wrote:
> After talking this over some more with Brian Fox, I'm convinced that
> this approach of segregating plugin and project repositories will
> result in a large amount of duplication of effort for ~90% of
> projects, since so many project-dependency repo
2008/1/9, Tom Huybrechts <[EMAIL PROTECTED]>:
> Are you proposing to add the zip packaging to the core ?
Yep
> Won't this break (or at least change) builds that have defined their
> own zip packaging ?
Right, I have to check before if an extensions declaration wins or not
on "native" maven packa
2008/1/9, Brian E. Fox <[EMAIL PROTECTED]>:
> How was it resolved in 2.1? If there is a new zip plugin, will that
> conflict with the 2.1 solution? (we'll end up supporting it forever).
> And why not just a new goal to the assembly plugin?
It's marked as solved in trunk but not sure it's really fi
Are you proposing to add the zip packaging to the core ?
Won't this break (or at least change) builds that have defined their
own zip packaging ?
Tom
On Jan 9, 2008 10:06 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> Hi,
> I have just read a thread [1] on the user mailing list.
> Is there any obj
How was it resolved in 2.1? If there is a new zip plugin, will that
conflict with the 2.1 solution? (we'll end up supporting it forever).
And why not just a new goal to the assembly plugin?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Olivier Lamy
Sent:
Hi,
I have just read a thread [1] on the user mailing list.
Is there any objections if I reopen the issue [2] and fix it in the
2.0.x branch ?
A new plugin (maven-zip-plugin) will be added too.
Thoughts ?
Thanks,
--
Olivier
[1]
http://www.nabble.com/Existance-of-ZIP-Archetype--%7C-How-to-distri
+1
On Jan 8, 2008, at 5:58 PM, Raphaël Piéroni wrote:
Hello,
I would like to prepare the alpha-1 release of the archetypeng stuff.
Preparing that release will need to do these things:
1. move the current archetype code
(svn.apache.org/repos/asf/maven/archetype/trunk) to a branch
(.../branche
After talking this over some more with Brian Fox, I'm convinced that
this approach of segregating plugin and project repositories will
result in a large amount of duplication of effort for ~90% of
projects, since so many project-dependency repositories also host
plugins. This is especially
+1
Raphaël Piéroni wrote:
Hello,
I would like to prepare the alpha-1 release of the archetypeng stuff.
Preparing that release will need to do these things:
1. move the current archetype code
(svn.apache.org/repos/asf/maven/archetype/trunk) to a branch
(.../branches/archetype-1.0.x)
2. move the
On Jan 9, 2008 9:23 AM, Jorg Heymans <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 11:02 PM, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
>
> Take a look at the developer cookbook (
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook )
>
>
> It would make sense to create a link from
>
There are discrepancies with version ranges between Maven and OSGi.
Not much to do as i don't think anybody will go through all Eclipse
plugins and update the poms manually.
At least for now you can use exclusions, or force the versions you
want in dependencyManagement
On Dec 29, 2007 9:48 AM, Fel
On Jan 9, 2008, at 9:46 AM, [EMAIL PROTECTED] wrote:
Author: vmassol
Date: Wed Jan 9 00:46:45 2008
New Revision: 610306
URL: http://svn.apache.org/viewvc?rev=610306&view=rev
Log:
DOXIA-199: Add a Sink for XWiki
* First working implementation. Still missing some more serious
tests to verify
+1
--
Olivier
2008/1/8, Raphaël Piéroni <[EMAIL PROTECTED]>:
> Hello,
>
> I would like to prepare the alpha-1 release of the archetypeng stuff.
>
> Preparing that release will need to do these things:
> 1. move the current archetype code
> (svn.apache.org/repos/asf/maven/archetype/trunk) to a bran
On Jan 8, 2008 11:02 PM, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
Take a look at the developer cookbook (
> http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook )
It would make sense to create a link from
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html to
+1000, thanks Raphaël !
Jorg
On Jan 8, 2008 11:58 PM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like to prepare the alpha-1 release of the archetypeng stuff.
>
> Preparing that release will need to do these things:
> 1. move the current archetype code
> (svn.apache.org/repo
19 matches
Mail list logo
