On Mon, 21 Jun 2004, Eric Pugh <[EMAIL PROTECTED]>
wrote:
> I don't know what extent you want to push back on the projects that
> gump builds, but it seems to me that they are either doing something
> that pushes maven beyond it's limits,
Quite possible. Or maybe not.
AFAIU we are successfully
On Mon, 21 Jun 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Monday 21 June 2004 22:47, Stefan Bodewig wrote:
>
>> (1) The descriptor of commons-compress sets a property named
>> component.version and hopes to get this into the jar name, which
>> obviously doesn't work that way. Maven stil
On Mon, 21 Jun 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> To do real integration you need to be able do to something like set
> some special property so that magic or maven can take control over
> classloader definition in the knowledge that the build is a gump
> build
This is what buil
> My conclusion is that the maven scenario is very similar to the magic
> scenario. To do real integration you need to be able do to something
> like set some special property so that magic or maven can take control
> over classloader definition in the knowledge that the build is a gump
> build (i
> The question is, does Maven fully support disabling the normal 'repository
> management' allowing Gump to provide the artifacts for each project?
Theoretically yes, but I think Stefan has disproved that it isn't
leak-proof.
> Can Maven be told to ignore versions in the POMs ?
Yes.
> I have s
On Tuesday 22 June 2004 00:32, Eric Pugh wrote:
> I don't know what extent you want to push back on the projects that gump
> builds, but it seems to me that they are either doing something that pushes
> maven beyond it's limits, or the decriptor might be out of date.
>
> I checked out jakarta-commo
Stefan Bodewig wrote:
Hi all,
two notes colored by my complete lack of Maven knowledge:
(1) The descriptor of commons-compress sets a property named
component.version and hopes to get this into the jar name, which
obviously doesn't work that way. Maven still uses
/project/currentVersion from the P
Eric Pugh wrote:
I checked out jakarta-commons-sandbox/compress to investigate furthur, but I
don't see this descriptor property you are talking about.. Could you
enlightenme on this?
If you mean the gump.xml - i only added fragments of it into
gump/project/jakarta-commons-sandbox.xml in the g
ut I
don't see this descriptor property you are talking about.. Could you
enlightenme on this?
Eric
> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 21, 2004 5:30 PM
> To: Gump code and data
> Subject: Re: commons-compress
> > For things like directories for compiled classes this probably
> > is good, but it may also lead to situations where Gump doesn't manage
> > to substitute a jar from CVS with a freshly compiled one.
>
> Generally, Maven will happily download the required Jars from remote
> repositories, which
On Monday 21 June 2004 22:47, Stefan Bodewig wrote:
> (1) The descriptor of commons-compress sets a property named
> component.version and hopes to get this into the jar name, which
> obviously doesn't work that way. Maven still uses
> /project/currentVersion from the POM.
If no Maven guys are a
Hi all,
two notes colored by my complete lack of Maven knowledge:
(1) The descriptor of commons-compress sets a property named
component.version and hopes to get this into the jar name, which
obviously doesn't work that way. Maven still uses
/project/currentVersion from the POM.
I've adapted th
12 matches
Mail list logo
