db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
Date Mon, 04 Apr 2011 04:16:08 GMT
On 2011-04-01, Thomas Vandahl wrote:

> On 01.04.11 06:05, Stefan Bodewig wrote:

>> OK, the way Gump works it means Turbine must be built before Torque, so
>> we must make torque-generator depend on turbine-core (and obviously
>> remove the torque dependencies from turbine-core).  We'll also need to
>> check whether any of Turbine's dependencies depend on Torque themselves.

>> I'll take care of this.

> I'm not a big fan of this solution. Such helper constructs tend to
> complicate things and some day nobody will remember what it was meant
> for in the first place. There used to be a commons-xxx-2.x dependency in
> Gump where some incompatible change had been circumvented. Couldn't we
> do the something similar here?

They only work because the "old" commons artifacts use a different mvn
groupd id from the "new" ones.

In commons land it looks as if the consensus was to change the package
name and the artifactId in the future.  I think this is because it is
pretty likely that projects end up with two different major versions of
the same commons roject via transitive dependencies.  Generally this
won't be the case for other projects.

>> Secondly this means Torque 3.x will be downloaded from Maven central and
>> put into the local repository.  Given that Torque4 seems to be known to
>> be incompatible to 3.x (I assume this is intentional) this may be a good

> It sure is. What is the general idea of Gump to handle incompatible API
> changes?

It really doesn't have a solution for that.  It's inital idea has been
that APIs never change in backwards incompatible ways and it has never
started to accept that reality is different.

So far we've dealt with it using the kind of hacks you've seen above.
Gump development is slow.

>> thing so I'd live with it (the alternative would be to use a separate
>> local repository).

> How would the local repository help here? I guess it could help me with
> fulcrum-quartz as well.

A separate local repository only means you get your own copy of local
maven artifacts.  If your project builds before one of your dependencies
you will get the version you asked for rather than the Gump built one
and it will be placed into your own local repository and not become
available for all the other projects thta want the same artifact
(they'll hopefully run later and get the Gump built one).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message