> From: Kev Jackson [mailto:[EMAIL PROTECTED]
>
> On 29 Sep 2005, at 06:39, Brett Porter wrote:
>
> > I'd also agree with that. We fully intended to make Maven2 plugins
> > work as Ant tasks :)
> >
> > So with a wrapper,
> > http://maven.apache.org/maven2/scm/maven-scm-plugin/
> > these goals wou
Kev Jackson wrote:
On 29 Sep 2005, at 06:39, Brett Porter wrote:
I'd also agree with that. We fully intended to make Maven2 plugins
work as Ant tasks :)
So with a wrapper,
http://maven.apache.org/maven2/scm/maven-scm-plugin/
these goals would become tasks and their parameters would match up
w
Trygve Laugstøl a écrit :
On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote:
From: Steve Loughran [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
But here we seem to be talking about a new family of generic tasks,
If this works well, we could deprecate the old tasks a
On 9/29/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> Just a worry about dependencies. If Ant has to rely on other code
> from within maven for a set of maven plugins to run, we end up with a
> horrible interdependency (Maven needs Ant <-> Ant needs some % of
> Maven) just to compile ant. Could ge
On 29 Sep 2005, at 06:39, Brett Porter wrote:
I'd also agree with that. We fully intended to make Maven2 plugins
work as Ant tasks :)
So with a wrapper,
http://maven.apache.org/maven2/scm/maven-scm-plugin/
these goals would become tasks and their parameters would match up
what's on the individ
I'd also agree with that. We fully intended to make Maven2 plugins
work as Ant tasks :)
So with a wrapper,
http://maven.apache.org/maven2/scm/maven-scm-plugin/
these goals would become tasks and their parameters would match up
what's on the individual pages.
Thoughts?
- Brett
On 9/29/05, Trygve
On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote:
> > From: Steve Loughran [mailto:[EMAIL PROTECTED]
> >
> > Jose Alberto Fernandez wrote:
> > > But here we seem to be talking about a new family of generic tasks,
> > > If this works well, we could deprecate the old tasks and eventua
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
> > But here we seem to be talking about a new family of generic tasks,
> > If this works well, we could deprecate the old tasks and eventually
in a
> > couple of versions remove them.
> >
> > Jose Alberto
>
> gene
Jose Alberto Fernandez wrote:
But here we seem to be talking about a new family of generic tasks,
If this works well, we could deprecate the old tasks and eventually in a
couple of versions remove them.
Jose Alberto
generic is good, provided
-we can have a conceptual model that is consistent
r 2005 16:57
> To: Ant Developers List
> Subject: Re: suggestion refactor SCM
>
> Hi,
>
> The standard problem with any kind of refactoring is the backward
> compatibility requirement on source code level. There are a lot of
> constructs we'd like to remove, but upto
Great news. So you'll can provide new providers.
Emmanuel
jerome lacoste a écrit :
On 9/27/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
Jose Alberto Fernandez a écrit :
I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.
The main reason f
On 9/27/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
>
>
> Jose Alberto Fernandez a écrit :
> > I think that it will be a very good idea, mostly as a stepping stone to
> > higher level functionality.
> >
> > The main reason for not having such a thing is the fact that each
> > project knows in a
Hi,
The standard problem with any kind of refactoring is the backward
compatibility requirement on source code level. There are a lot of
constructs we'd like to remove, but upto now we have always weighted
backward compatibility - even on source code level - over removing those.
Martijn
Kev
Hi,
The standard problem with any kind of refactoring is the backward
compatibility requirement on source code level. There are a lot of
constructs we'd like to remove, but upto now we have always weighted
backward compatibility - even on source code level - over removing those.
Martijn
Ke
It certainly is an interesting idea. I think the main challenge in this
endeavour is to figure out what is the common denominator between all
the SCM systems and then assess if it is encompassing enough to warrant
abstracting it out.
I wish this effort will not be limited to tasks, but will al
Jose Alberto Fernandez a écrit :
I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.
The main reason for not having such a thing is the fact that each
project knows in advance what kind of repository is being in used. So
why do we need something
I would suggest having a separate (external) "typedef" (or whatever the
appropriate Ant concept would be):
...
Referencing this value by ID would allow programmatic and build script
level references to be made to such a repository without the need to
know the exact de
I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.
The main reason for not having such a thing is the fact that each
project knows in advance what kind of repository is being in used. So
why do we need something abstract?
On the other hand, once yo
Hi,
it definitely is a good idea, and it's worth doing. SCM has become
commonplace, just like databases. I think few people would object to
lowering the barrier of moving to another SCM system and/or being more
isolated from third-party SCM system changes.
Jan Dvorak
Kev Jackson wrote (sho
On 9/27/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> d - none of the above
I know you are talking about an interface at the Ant task level, but I
should also point out that this was one of the things I was referring
to offering up Antlibs for if there was interest.
http://svn.apache.org/viewcvs.c
20 matches
Mail list logo
