Stefano Mazzocchi wrote:
there are a few projects that gump builds that are not ASF projects and
are not used by any ASF project.
I'm not sure which projects this is about (or what the projects you
listed are about), but I can imagine that these projects are built
against the latest and
Stefano Mazzocchi wrote:
Conor MacNeill wrote:
Stefano Mazzocchi wrote:
WTDY?
The downside of this idea is that ASF projects will lose warnings
about incompatible changes they make that break non-ASF projects.
I said: remove non-ASF project that ASF projects don't depend upon.
You are talking
On Monday 01 November 2004 17:02, Conor MacNeill wrote:
In effect, barcode4J acts as a testcase for its dependencies and you
propose to remove that test. I understand the motivation, I'm not
particularly concerned, but there is a potential downside, which I
thought was worth noting.
Very good
On Monday 01 November 2004 17:00, Leo Simons wrote:
Kaffe is very much a leaf not a dependency (I know no ASF project
that can only be built using Kaffe), yet using it for experimental
runs doubles the amount of cpu and disk space used.
For the record, there are 8 attempts at starting a Gump
On Monday 01 November 2004 19:29, Eric Pugh wrote:
Related to this, I
am starting to think about dependencies not just in a is it a good
dependency to have but in a what challenges will having this dependency
give me in Gump land, which isn't a great thing...
Hmmm... I wonder if such thought
Dalibor Topic robilad at kaffe.org writes:
I've had to solve a similart problem for bootstrapping ant with kaffe
jikes in
kaffe-extras module of kaffe's CVS. There I've patched ant's bootstrap scripts
for that [1] but of course setting env vars is more elegant ;)
And I can confirm that it
The cost of having to build each dependency in Gump drives home that I may
be using some weird dependency that no else is using, and is therefore not
already in Gump. However, as long as the code remains buildable, it won't
be an issue. In the long run, in 5 years when some libarary I am using
Niclas Hedhman niclas at hedhman.org writes:
On Monday 01 November 2004 17:00, Leo Simons wrote:
Kaffe is very much a leaf not a dependency (I know no ASF project
that can only be built using Kaffe), yet using it for experimental
runs doubles the amount of cpu and disk space used.
Conor MacNeill wrote:
Stefano Mazzocchi wrote:
Conor MacNeill wrote:
Stefano Mazzocchi wrote:
WTDY?
The downside of this idea is that ASF projects will lose warnings
about incompatible changes they make that break non-ASF projects.
I said: remove non-ASF project that ASF projects don't depend
Niclas Hedhman wrote:
On Monday 01 November 2004 17:00, Leo Simons wrote:
Kaffe is very much a leaf not a dependency (I know no ASF project
that can only be built using Kaffe), yet using it for experimental
runs doubles the amount of cpu and disk space used.
For the record, there are 8 attempts
Eric Pugh wrote:
I think it comes down to maintence. If projects have active committers who
are trying to fix them when they break, then great, lets keep them.
Regardless of where they come from. But, if projects are in the system that
don't have active committers trying to fix them/deal with
Stefano Mazzocchi wrote:
If a project:
1) is not an ASF project
2) no ASF project depend on it
3) has been broken for a while and shows no sign of activity (gump-wise)
+1 to that one. In the case of has been broken for a LONG time with no
sign of activity gump-wise I would even support the
I agree. Please see my thread about removing commons-xo [1] for an example
of one project that we can get rid of. I think other
jakarta-commons-sandbox may be removed as well if they are stagnant...
Eric
[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg51295.html
-Original
Eric Pugh wrote:
Sometimes I just want to build against version XX of a dependency. But this
is mostly me being lazy.
Well, I think gump should allow you to do that: build against the latest
dependency *and* build against the dependency you want. Those are two
different things, true, but
we call it beanutils-core and maven calls it beanutils. Should I go
ahead and unify the two or anybody has a better idea?
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Ok, we need a solution for when a project changes names. There have
been suggestions in the past, let's round them up:
- gump has a dummy project beanutils that depends just on
beanutils-core. I don't think this works with Maven though.
- projects declare any aliases in their gump descriptor
On Monday 01 November 2004 23:41, Stefano Mazzocchi wrote:
So, let me rephrase my proposal:
If a project:
1) is not an ASF project
2) no ASF project depend on it
3) has been broken for a while and shows no sign of activity (gump-wise)
we remove it from the gump.xml profile that
On Monday 01 November 2004 21:12, Dalibor Topic wrote:
Since you're
using the normal debian packages, setting a few additional env vars should
do the trick for the bootstrap with kaffe:
extras for ant bootstrap with kaffe
##
## Use jikes with kaffe's class libraries on bootclasspath
Hi,
I am trying to open
http://gump.covalent.net/jars/latest/jakarta-tomcat-connectors/tomcat-util.jar URL
since one week or so ,but i am unable to open it.
Kindly help to do so,because i am stuck .
The SSL support in jakarta-tomcat-4.1.12 is broken with JVM 1.4.x ,i want to copy this
jar
19 matches
Mail list logo
