Re: [proposal] removing non-ASF leaves from the workspace
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 greatest ASF software to make sure that ASF software doesn't introduce incompatible changes. ie Cocoon might like Gump to build Daisy as its a good integration test for cocoon. Abstractly, projects depend on having good dependees available inside the system as a measure for their own backwards compatibility. I think the ASF already has enough things to build for ourselves and gump is not a public service. The ASF is a public service in a way though :-D. I like how gump as a project and a community has tried so hard to reach out to all parts of the oss world, not just the ASF. Abstractly, requiring dependees to be ASF-internal leads to a closed ASF. No good. I personally think that it is abusive for comitters to use their access to add projects that are not required. whoah. Around here stuff like that used to be okay, encouraged even. Gump is now pushing in a somewhat different direction (which I support) so we're changing some of our ideas on this, but that doesn't make the people not quite aware of those unspoken 10-mile-high goals abusive all of a sudden. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. 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. While I appreciate the goal of being able to have a truly free java stack and how using Kaffe to build ASF projects helps towards attaining that goal, we're also doing public service towards the GNU people in this way. WTDY? If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1. cheers, -LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 about removing non-ASF projects upon which no ASF projects depend, right?. I understand this. Please have another read of what I said. By removing those non-ASF projects from Gump, you lose an indication of the downstream effects of changes in ASF projects. Let's take Barcode4J as a (random) example. It depends upon the ASF projects, xalan and avalon-framework. By removing Barcode4J from Gump, you will no longer notice when changes in Xalan and Avalon break Barcode4J. 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. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 observation, and the importance of external dependees will increase for Apache projects at a 'higher level', which don't have internal dependees. This can OTOH still be achieved by discriminately not build from the external project HEAD, and instead use release tagged snapshots. That provides IMHO the best of both for the ASF side of the equation. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 build every day. 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the official build. So, it is not completely accurate to say that the Kaffe build instance doubles CPU/disk resources. While I appreciate the goal of being able to have a truly free java stack and how using Kaffe to build ASF projects helps towards attaining that goal, we're also doing public service towards the GNU people in this way. Looking at the fact that a Kaffe developer (dalibor) has taken interest in Gump, installed his own instance and trying hard to get things going, is IMHO a good testament to the appreciation of Gump. If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1. CPU/disk is basically a financial issue. If it is constrained today, we can take temporary measures to exclude projects to make room. Some external dependee projects don't build, and is 'annoying' in the reports. We can either remove them, or choose a better snapshot from their CVS. Those are short-term issues, and I think that removal of non-fixed dependee projects are adequate in the short-term. What we should start discussing is, how do we scale Gump 'real big'? If company A, can take part of a massive Gump build, provided that they make server(s) available for a massively parallelized builds, then I think *many* would like to be part of the Gump service, and therefor ASF will have access to 'unlimited' CPU/disk resources for those builds (i.e. each participants will make available more resource than their part will consume). IMHO, this is a tangible, highly interesting and highly valuable challenge, and not beyond reach. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Kaffe instance and ant-bootstrap
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 works for me with Kaffe's CVS head. 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 export JAVAC=jikes-kaffe ## Jikes doesn't like javac.source=1.2 in build.xml, but only accepts 1.3 or 1.4 export ANT_OPTS=-Dbuild.compiler=jikes -Djavac.source=1.3 The next issue I had was a bug in GNU JAXP's lookup of SAX parsers. Thanks to gump for making it easy to spot! ;) With the issue fixed in my local kaffe tree, ant bootstraps fine and dies on ant build die to missing configuration bits: xml-apis, and xml-xalan. That's my next target ;) cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] removing non-ASF leaves from the workspace
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 is no longer maintained, then this will become key information. Sometimes I just want to build against version XX of a dependency. But this is mostly me being lazy. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 12:58 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace 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 is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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. For the record, there are 8 attempts at starting a Gump build every day. 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the official build. So, it is not completely accurate to say that the Kaffe build instance doubles CPU/disk resources. My long term (a few weeks, I hope) plan is to have a second gump instance on developer.classpath.org with the free runtimes to both take the extra load off ASF, and to give further free runtimes like gcj, IKVM, JamVM, etc. a go at building the free java software world from scratch. While I appreciate the goal of being able to have a truly free java stack and how using Kaffe to build ASF projects helps towards attaining that goal, we're also doing public service towards the GNU people in this way. Looking at the fact that a Kaffe developer (dalibor) has taken interest in Gump, installed his own instance and trying hard to get things going, is IMHO a good testament to the appreciation of Gump. I appreciate in particular the extremely helpful developers on #gump. Thanks a lot for those that helped me set myself up. I still have to pay you back with the wiki page, though ;) Seriously though, I think gump is just wonderful, and is going to help leapfrog the whole free runtimes thing quite a bit as a side effect. Today, there is a lot of great free software written in Java, not least thanks to ASF's successful projects. Unfortunately, there are often some small issues that prevent some free Java softare from running on free runtimes. Gump can help find and fix those small issues, as it did for GNU JAXP's small bug today for me. The small issues may be bugs in the free runtimes, or code that is just a little bit outside the letter of the specification, but runs fine on non-free runtimes. In particular the latter case is hard to anticipate a priori in a class library implementation. That's where having a gump can be very, very helpful: it shows what idioms other developers expect to work. Finally, I see great potential in maintaining a confidence level in a free java stack, once we're there ;) That could help quite a bit wrt to packaging efforts of free software written in Java for operating systems like GNU/Linux, *BSD, etc. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 upon. You are talking about removing non-ASF projects upon which no ASF projects depend, right?. I understand this. Please have another read of what I said. By removing those non-ASF projects from Gump, you lose an indication of the downstream effects of changes in ASF projects. Let's take Barcode4J as a (random) example. It depends upon the ASF projects, xalan and avalon-framework. By removing Barcode4J from Gump, you will no longer notice when changes in Xalan and Avalon break Barcode4J. 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. Conor, my apologies. You are right and I misunderstood your statement. Point well taken (and echoing with Leo's comment). 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 brutus runs. As a result: 1) we save some time and space 2) we obtain a more reasonable indication that the gump status *is* is a measure of the community integration Thoughts? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
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 at starting a Gump build every day. 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the official build. So, it is not completely accurate to say that the Kaffe build instance doubles CPU/disk resources. The kaffe build increased our disk usage of 7Gb (about 1/6 of our resources) and uses 56 CPU minutes and one 3 hours time slot (about 1/8 of our resources). While I appreciate the goal of being able to have a truly free java stack and how using Kaffe to build ASF projects helps towards attaining that goal, we're also doing public service towards the GNU people in this way. Looking at the fact that a Kaffe developer (dalibor) has taken interest in Gump, installed his own instance and trying hard to get things going, is IMHO a good testament to the appreciation of Gump. Not only that. The build on Kaffe is a political tool for the java community: it's the only way to show that we have a way out if Sun decided to do something weird licensing-wise with their JVM. This would be a *huge* service to the java community at large and to the ASF in the first place. If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1. CPU/disk is basically a financial issue. If it is constrained today, we can take temporary measures to exclude projects to make room. We do not have disk-space issues at the moment, but we are not able to get another build in the house. Before going financial, I would spend some time in making sure that the builds could land into another part of the disk. that would reduce disk consumption by an order of magnitude. Some external dependee projects don't build, and is 'annoying' in the reports. This is my main concern: their failures are basically cry wolf, when a real failure happens, nobody notices. We can either remove them, or choose a better snapshot from their CVS. The result would be the same. Those are short-term issues, and I think that removal of non-fixed dependee projects are adequate in the short-term. What we should start discussing is, how do we scale Gump 'real big'? Niclas, there are *tons* of things to do in gump before we even start attempting that. Please, let's fix our problems first. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
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 the issues, then lets remove them. Agreed. I wish that we tracked who the goto person was versus just mailing list for various projects. Maybe set up a more flexible approach like 'after 10 failures' we contact the goto person to remind them. After '30 failures' then we remove any leaf projects. I completely agree on the fact that pointing a problem to a single person is way more efficient. There is a way to understand who break what, but it's not easy to implement efficiently since it requires gump to know what versions of the dependencies projects depend on. Part of the complexity of Gump is that so many things can go wrong. And when things start going wrong, the rate really speeds up and then everything goes wrong. And fixing it can seem like a mountain to climb. That's why it took 3 years and several burned-out people to reach 85%. To help with the number of projects, have we thought about more aggressive use of installed packages? Yes, and the number of packages we have already worries me. In the future my goal is exactly the opposite: remove as many packages as we can. I know that goes against the current spirit of gump. But really, I don't care about the OpenSymphony dependencies I am using, I just want my ASF projects that depend on OpenSymphony code to build under gump! This is why we need explicit versioned dependencies (maven pom provides that already) so that we can be *both* a build system *and* a continous integration system. Maybe someday, when everything is rocksolid, then I'll start paring out the number of packages that I am using. 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... I think this is just awesome: the day a FOG is considered a dependency risk by people downstream is the day gump starts to make sense. Eric, solving the pain right now might just increase it later on. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
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 above for ASF projects. At least until the tree is cleaned up. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] removing non-ASF leaves from the workspace
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 Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 5:06 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace 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 above for ASF projects. At least until the tree is cleaned up. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 equally useful and gump should give you both. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
What do we do with beanutils?
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
Re: What do we do with beanutils?
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 (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils - we don't do any gump solutions, and we maintain the big mapping file in the maven gump plugin, so it can change the dependencies when converting the gump descriptor. We look to store that mapping file in gump, instead. - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. Possibly, the previous version keeps the name so that projects keep building? (others have more passionate feelings about how gump should behave in this way I think, so I'll leave that to them). Thoughts? (2) seems the best if possible on the gump end. Both (2) and (3) are easy from the maven end. Cheers, Brett On Mon, 01 Nov 2004 20:29:32 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
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 brutus runs. As a result: 1) we save some time and space 2) we obtain a more reasonable indication that the gump status *is* is a measure of the community integration +1 -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Kaffe instance and ant-bootstrap
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 export JAVAC=jikes-kaffe ## Jikes doesn't like javac.source=1.2 in build.xml, but only accepts 1.3 or 1.4 export ANT_OPTS=-Dbuild.compiler=jikes -Djavac.source=1.3 So, are you suggesting that we do the above, or are you suggesting that we should prepare to get Kaffe from CVS? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help me
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 file ,so that my tomcat works fine. If you can provide me this file then plz do so. regards, Rahul Jain Mahindra-British Telecom Ltd. Oberoi Estate Gardens, Wing-1,Off Saki Vihar Road, Next to Chandivali Studios, Andheri (E) ,Mumbai-72 Tel: +91-22-56792000 Extn : 7108 * Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. * Visit us at http://www.mahindrabt.com
