> From: Ross Gardler [mailto:[EMAIL PROTECTED]] > > I've not looked at Maven for quite some time so I will only > comment on > Centipede here:
Good. > Berin Loritsch wrote: > > -o0 Weaknesses 0o- > > > > Centipede > > --------- > > * The project descriptors are not as easily intuitive. You have > > an XML based properties file, as well as a meta-build ANT file. > > Why not just declare everything once like Maven, and take care > > of the dependencies automatically. > > A better way of handling project and build descriptors is currently > under discussion. Sounds good. > > * Centipede's default install does not automatically download and > > install missing cents. Cents are required for Centipede to do its > > work, but all the required Cents are not included for some strange > > reason. > > Centipede's default install does not include any of the cents > in order > to minimise the download size, however, all required cents should be > downloaded when you build your project. They are downloaded > to a central > repository so each cent need only be downloaded once per site. Well, the required cents should be included. Another way to minimize download time is to have two versions of the Forrest cent. If centipede discovers that Forrest is installed separately, then you only need to *use* it--not download another instance. It's only a minor gripe though. Does the current Forrest Cent use all the files the same way that Forrest does, or do you have to redeclare your settings in the XML properties file? > There is no need to manually download anything other than the default > install. If you had a different experience please report this > as a bug > and we'll deal with it (there is a known bug causing problems behind > authenticating proxies). I think this really is a user issue. Once I had Centipede installed (with CENTIPEDE_HOME in my path), I didn't know what to do. For some reason it wouldn't interact nicely on my system. One possibility was I was using Cygwin and had Centipede installed on my D: drive (mangling the path to /cygdrive/d/) which might mess up the BASH scripts. > There is a separate bundle of cents should you prefer to > download them > all and install them manually for some reason. I thought that is what you were supposed to do. I think you need some "getting started" docs. > > * In the absence of a meta-build ANT file, Centipede does > not provide > > a way to "seed" a new project like Forrest. It should be easy to > > do, and it would be better than trying to figure out what to do > > from the site documentation. > > There is a templates project in CVS which provides a number of such > "seed" projects. However, there is not currently a target for > seeding a > new project automatically in the way that Forrest does, you > can expect > one very soon though, I will tackle it today. Excellent. That will *really* help out--and maybe even push my opinion of which is the better build system towards Centipede. > > * Way too much information spit out at the user. Mountains of log > > files go by, some of the actions appear to be recursive (which > > always makes me nervous), and there is no intuitive way to lower > > the threshold of the log messages. I am not trying to debug > > Centipede--I just want to debug Avalon. Will you be tackling minimizing the log levels so the user doesn't have to look at mountains of meaningless (to him) information stream by? It also slows down the build because writing to System.out is far slower than writing to a file. Maybe logging to a file by default would be an even better idea? > > > > Centipede > > --------- > > * It looks like Centipede might be able to function like Maven to > > download dependencies on demand. I just can't seem to figure out > > how it would work. > > It does, the fact that it hasn't done so for you seems to > indicate that > you may be hitting one of our known bugs: if you are behind an > authenticating proxy the auto download. So far there is no-one > clamouring for a fix for this - if this is what stops you from using > Centipede I am sure we'll tackle it for you. Don't let it stop you from tackling you, but my problem was a user issue. Kind of a "I downloaded this thing, set the environment variable, put it in my path, so now what do I do?" problem. > > * Can I declare my build properties in a Properties file? It would > > actually be more intuitive than the XML variation, and a lot more > > dense. XML is not a panacea--it is a tool, and for this purpose > > it is overkill. It works quite well for the project descriptor, > > but not for properties. > > I'm not 100% sure, someone will correct me if I am wrong, I don't > *think* this is currently possible, but could be easily included if > necessary. The reason I prefer to use XML is because I can generate > documentation from it very easily. What documentation would you realistically create from the properties? The only thing I could think of would be just listing what the settings were that I chose. It is of dubious value, and can just as easily be accomplished by referencing the properties file via a URL, or embedding it in a <pre/> section on the site. > The location of all files in the project, not just docs, can be > configured in this way. You mentioned in your preamble that you have > been experimenting with new directory structures in order to use > Centipede. This is not necessary as you should be able to configure > Centipede to work with your current structure. We are wanting to impose a scalable directory structure for the future of Avalon, so it is not directly related to Centipede/Maven. I know that both of those tools can be altered to support what we want (within reason). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
