Sounds like you're describing maven and centipede to me.
At least in terms of their dependency abilities.
Hen
On Tue, 4 Feb 2003, Joerg Pietschmann wrote:
> Hi,
>
> I think its time to get gather some "best practices" for setting up Ant
> buildfiles.
>
> Let me start with a story. I thought I'll download the Tomcat 4.1.18
> source distro and compile it, just for fun. The fun ended abruptly
> after unpacking and calling ant, The build process spwed a lot a
> unhelpful flag settings, then aborted because there was no servlet.jar
> to copy. Ok, this was to expect, get a servlet.jar and drop it into the
> lib directory.
>
> Didn't work. Ok, there is a build.properties.samples. Copied to it
> build.properties and changed the base.path property. Restarted ant.
>
> The build still bombs, now because commons-collections.jar was missing.
>
> Ok, downloaded jakarta-comons-collections-2.0-src (a sub-sub-project?)
> (yes I now there is a 2.1), unpacked and started ant there. Bombs,
> because Junit is missing. Makeing "test" the default target is a bit
> odd, but so what. Ant -projecthelp reveals there is a "build"
> target. Start "ant.sh buld". Unfortunately, this compiles the source
> but doesn't build a jar. Well, "ant.sh dist" fixed this, but seems to be
> a bit of overkill.
>
> Back to the tomcat build. The Collections jar is still not found: the
> sample properties expects it in commons-collections-2.0, the Collections
> source distro unpacks to commons-collections-2.0-src. This src suffx is
> *annoying*. Deleted it. Still no success. The jar is expected in
> ${commons-collections.home} but actually resides in
> ${commons-collections.home}/dist after the dist build. Fixed this too.
>
> Next bomb: commons-beanutils.jar is missing. Downloaded and unpacked
> commons-beanutils and started ant. Result: a slew of errors because
> collections and logging were not found. In contrast to Tomcat, beanutils
> expects collections by default in ../collections/dist, if the samples
> properties were used.
>
> At this point I decided to write this message. Note that this is
> unrelated to Stefano's rant here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104428772907971&w=2
>
> Another story with similar experiences regarding excalibur is here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102382875622031&w=2
>
> Ok so far. The question is: Why doesn't it Just Work (TM)?
>
> Let's view it from another angle. The Unix/C/Make/GNU folks have
> developed a set of rules and tools to cope with complex dependencies, to
> some extent. There are somewhat reasonable, well known defaults for
> locations of libraries and whole packages. Well, the Java world lacks
> this, thanks Sun, and instead of DLL and .so hell we got Jar hell. Ok,
> no further discussion about this part of the problem.
>
> Then there is make(1) and the associated GNU tools: autoconf, automake,
> libtool. There are default targets in makefiles with a reasonably well
> defined semantics, you can be fairly sure that "all" is default and that
> "make all" will produce executables ready to run (with a few
> exceptions), and that there are "install", "clean" and a few others
> (unfortunately, the "uninstall" target is not necessarily properly
> implemented, if at all). Also, "./configure" is quite good to adapt the
> package to the environment, and usually you'll get fairly good messages
> if mandatory packages are missing. Automake makes it reasonably easy to
> provide makefiles compatible with autoconf and adhering to the
> standards.
>
> Back to Jakarta, and Apache Java projects in general. Building an
> infrastructure of reusable libraries is a laudable goal. However, I'm
> not going to download packages piecemeal, figure out how to configure
> each package individually, and actually do this manually.
>
> Now, how should this problem be tackled? Some requirements which come
> readily to mind:
> - The default buildfile target should inform the user about missing
> mandatory configuration data (properties pointing to various stuff).
> - The buildfile should alert the user if mandatory libraries cannot be
> found through the configured properties, rather than dumping errors
> during compilation.
> - There should be verbose hints relating configuration properties to the
> packages.
>
> Gump might already help here with the dependencies. We might need an
> equivalent for autoconf. I have a huge bunch of other ideas I will
> publish later, partially because I want to hear unbiased comments
> first. If there is some resonance to this post, I'll setup a Wiki page
> (suggestions for a name? substructure?) for publishing upcoming ideas.
>
> J.Pietschmann
>
>
> ---------------------------------------------------------------------
> 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]
