On Sep 24, 11:45 pm, David Pollak
wrote:
> On Thu, Sep 24, 2009 at 11:30 AM, Timothy Perrett
> wrote:
>
>
>
> > This refactoring *must* be done in a branch... we don't want to
> > inadvertently break a whole bunch of peoples projects.
>
> Actually, this should not break any existing Lift projec
On Thu, Sep 24, 2009 at 11:30 AM, Timothy Perrett
wrote:
>
> This refactoring *must* be done in a branch... we don't want to
> inadvertently break a whole bunch of peoples projects.
>
>
Actually, this should not break any existing Lift projects. It should "just
work" with existing stuff.
> Fro
This refactoring *must* be done in a branch... we don't want to
inadvertently break a whole bunch of peoples projects.
From the responses here its obvious there is a fair amount of
hesitation around this proposal - thus, lets put it up in a branch and
test it to death before even consideri
Jeppe,
> Many other build systems (Ivy, Gradle, SBT, buildr) etc. can use a Maven
> repository to resolve dependencies and hence use the POMs from the repo.
>
Ah, now I see your point ;-)
> I'm not using maven so don't know how the POM in the repo gets
> generated, but somehow thought the propo
Heiko Seeberger writes:
> Jeppe,
>
> If you are not using Maven, you certainly have to provide any
> information your build system needs. But why would you want to bother
> about the POMs then? They are Maven-specific and of no interest for
> other build systems. Or am I missing something?
Many
Jeppe,
If you are not using Maven, you certainly have to provide any
information your build system needs. But why would you want to bother
about the POMs then? They are Maven-specific and of no interest for
other build systems. Or am I missing something?
Heiko
On Thursday, September 24, 2009, J
