Berin Loritsch wrote:
A better way of handling project and build descriptors is currently under discussion.-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.
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.* 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.
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).
There is a separate bundle of cents should you prefer to download them all and install them manually for some reason.
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.* 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.
Fair comment. We have however, just completed a system that automatically generates documentation for our cents (plugins) from the build files and module descriptors. With this new documentation system you can expect more rapid development of docs since developers no longer need to maintain them separately from code.* 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.Maven ----- * No way to "seed" a new project like Forrest does. I think work might be underway for it though. * Maven downloads alot of stuff to get started. If you don't have a fat internet connection, your first build takes a really long time. * Difficult to extend with project-specific modules. The machinery is there, but it has a lot of rough edges. The Forrest module is not included by default. -o0 Unclear Things 0o- Both projects have the typical Open Source failings. Documentation is sparse, and typically only covers what the developers were concentrating on. For example, both focus more attention to _converting_ an existing project than to _creating_ a new project from scratch. Between the two, Maven does have marginally better documentation.
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.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.
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.* 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.
The forrest cent has now been updated to the latest version of forrest (Forrest itself used to use src/documentation/content/xdocs/). However, the location of these files is configurable and can be changed if you already have a directory structure you want to stick with. With the new version of the forrest cent you can build your docs independently of centipede by running the forrest command, although you will not get updated cent outputs for obvious reasons.* If I use Forrest directly, I can stick my doc files in src/documentation/content/. If I use it through Centipede then I have to stick it in src/documentation/content/xdocs/. There is a mismatch.
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.
Maven
-----
* What happens if I don't have an internet connection after I do
the initial install? Will it be useless?
-o0 The Bottom Line 0o-
Neither build system is perfect. After my excersize, I have come
to the conclusion that Maven is the more mature of the two build
systems--but Centipede is catching up fast. In fact, if the current
pace of development for the two projects continue, Centipede may
very well overtake Maven in features and ease of use.
I think Maven has a lower barrier of entry to the user, but
Centipede is becoming easier to use and more developer friendly.
I am a fan of black box tools like Maven, but if I need to do
something a little out of the ordinary, I like the flexibility
of Centipede.
For Avalon, I want to depart from the hienous build system we
have now. We have stretched ANT to its limits, and have many
many JARs in our CVS. Our recursive build in Excalibur is
problematic, and there is no clean way to simply declare
dependencies--or even create a dependency graph. When you have
one project that depends on another, that depends on yet another,
you would like to know all the dependencies that are required
for your build. Also, we (or is it just me?) would like to
provide two versions of a project--A smaller JAR where the user
has to include all the other dependencies, and a larger JAR
where all Avalon code is included--making it easier for a
user to use some of the larger and more complex subprojects.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Krysalis-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/krysalis-developers
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
