On Sun, 2002-02-24 at 14:44, Peter Donald wrote: > On Mon, 25 Feb 2002 01:32, Jason van Zyl wrote: > > On Sun, 2002-02-24 at 08:24, John Morrison wrote: > > > This has been discussed - search the archives. Basically, if > > > memory serves me correctly, it was decided that this was a bad > > > idea. We can't reasonably expect projects which aren't Apache > > > to have a file in their repository solely for Apache usage. > > > > I don't think this is true. Why would it solely be for apache usage? > > Some one could install Gump locally and want to build a mass of projects > > that aren't stored locally. > > yep. That would be kool. One thing that stops me doing it now is that it is > not so easy to do that atm :)
I will make this dead simple with Maven, the configuration and setup of a reactor to perform massive builds but again it's the common project descriptor format. I'm going to try and overcome this by being able to produce the descriptor easily. > > > > I'm fairly sure this is correct... > > > > I am certain that the only way for Gump to scale is to offload the > > responsibility of descriptor correctness to the project itself. When > > there are 100,200,300 ... 500+ projects the current process of one or > > two individuals trying to keep the descriptors up-to-date is a lost > > cause IMO and not really that fun. > > Thats was precisely the problem I came across. I thought - wouldn't it be > kool if project X was gumpified ... then I thought I would be the one who had > to maintain it and that would suck :) It's just not feasible IMO, there are failures all the time simply because there is no real correlation between the project and the descriptors used by Gump. But I think this problem can be solved. > > Currently in Maven (http://jakarta.apache.org/turbine/maven/) the entire > > build is keyed off the project descriptor and this descriptor can be > > transformed into a Gump descriptor. As I just mentioned to Peter a > > couple minutes ago is that if the project builds from the descriptor > > then the generator Gump descriptor will be correct in form. No more > > disparity between the Gump descriptor and the projects actual build > > system because the information will be drawn from the same location. > > Sounds kool. WIll have to have a look at it. I actually built a similar > system but with a different tact. I used "Optional Package" specifications > (see jdk1.3 docs) as declarations of dependency. These were looked up in > library directories and if they could not be found then a map file was used > to map "Optional Package" to a way to retrieve said package. > > > In this way Gump could be fed descriptors by some known process and use > > those to build instead of trying to keep them up-to-date manually. > > Excellent - I may see if we can get avalon using this aswell. Everything uses Velocity templates and DVSL to generate the documentation. I know that you guys want to use cocoon to generate the docs and use docbook and it is easy to add different templates for your documentation system so that when a build is generated for avalon projects it comes out using cocoon. I fully understand wanting to eat your own dogfood. I would be glad to help but I'm not really expecting anyone to jump on bandwagon anytime soon if at all. Though I have used some of Berin's ideas and it is dead simple to change the build system templates so additions are easy. The prototype is in the maven repo and it's working now so that you don't even have to check in the build files, all you need is the project descriptor. > -- > Cheers, > > Pete > > ----------------------------------------------------------- > "Remember, your body is a temple; however, it's also your > dancehall and bowling alley" -- Dharma Montgomery > ----------------------------------------------------------- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
