You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ross Gardler <ro...@saafe.org> on 2003/01/02 16:06:33 UTC
Re: Build Environment
I've not looked at Maven for quite some time so I will only comment on
Centipede here:
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.
> * 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.
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.
> * 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.
> * 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.
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.
>
> 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.
> * 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.
> * 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 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.
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
> Krysalis-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/krysalis-developers
RE: Build Environment
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Ross Gardler [mailto:ross@saafe.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Build Environment
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Ross Gardler [mailto:ross@saafe.org]
>
> 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).
RE: Build Environment
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Ross Gardler [mailto:ross@saafe.org]
Here is what I did:
Starting a new project
Ok, so you have some code and want to use Centipede to build. The easiest
way to start a new project is to get hold of the krysalis-project template
(this is part of the krysalis-templates CVS module, and will soon be
released as a separate package). Copy this template into your new directory
and then:
* Put the code under src/java.
* Put the required libraries under lib
* Edit the files module.xml and status.xml to make Centipede know all about
your project and community.
Go in the root dir of your project and type cent, you'll get an interactive
menu of the build options available.
That's it. To compile run cent compile, to make the jars run cent jar and to
clean the build directory run cent clean.
(from your website)
What I was greeted with was:
D:\projects\avalon>cent compile
Searching for centibuild.xml ...
Could not locate a build file!
using DOS, and
$ cent compile
C:\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32 error 6
Error: JAVA_HOME is not defined correctly.
We cannot execute java
using Cygwin.
That was fixed by adding "--path" to the two lines 71 and 73.
I then got the same problem as the DOS version.
CENTIPEDE_HOME is set to "D:\krysalis-centipede-1.0.0-beta4"
and the path has "%CENTIPEDE_HOME%\bin;%PATH%" in it.
Do you have any concept as to what might be my problem?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>