Berin Loritsch wrote:
It appears the dust has settled, and it looks like ANT has been decided upon
as the way to go. That's OK with me. The questions I now have are in regards
to the things that I perceived Maven would help with.
I didn't think it was quite that settled, but this is a good part of the discussion either way.
1) Dependency resolution. Let's face it, blocks will depend on other blocks.
That's OK, they're supposed to. The question is for the third party block
developer. How are they going to find the dependencies that they need, or
publish them?
As I understand it, this is a matter of block librarian implementation, and isn't a build consideration. Blocks depend on other blocks only through declared component resolution and pipeline based resource exposure. So, compiling a block (and therefore its build) doesn't need these other implementations to be resolved. Only the deploy step needs them present and that's the domain of the block librarian and block deploy tool isn't it?
2) Unified packaging requirements. Again, blocks will require some consistency
in regards to packaging requirements. Things like the standard MANIFEST.MF
tags, locations of configuration files, etc. We can create an ANT task to do
all this, but then you also have to worry about getting people to install and
use it.
This is being specified in the block.xml descriptor discussion. Ultimately, it's just a file system layout and a zip/jar task isn't it? Ant isn't needed for that though it'd help. I don't see where MANIFEST.MF will need to come into it - direct access to classes within a block is forbidden and everything a block exposes is either directly or indirectly (in the case of sitemap resources like pipelines) declared in block.xml.
3) Not keeping JARs in the repository. That is the one thing that bugs me about
the Cocoon build infrastructure. There is a mountain of JAR files that are
needed in some contexts, but not others. You can't keep it straight.
I guess there is a proposal on how to do this with Ant already on the table. Personally, I feel this is a matter of personal taste though. I get frustrated with projects that have a long list of dependencies I have to retrieve at build/deploy time, even if they are automated though that certainly is much better. Now, we are going to face this by design with blocks decentralizing but that will be elective dependencies, not core dependencies which feels different to me personally.
4) Reactor builds. Being able to start a build, and having the build system
dynamically order the blocks according to their present needs is very
valuable. For example, I could create a block, and someone else use that
block. If my block includes a new dependency on another block, that third
party block needs to be able to ensure the build includes the new dependency.
Block dependencies won't a part of the build as I understand it.
5) Minimal tweaking. I can't say how much is needed to be tweaked in the
current ANT builds, but other projects required endless tweaking as the needs
of the project grew.
Are we talking about the blocks build(s) or the core build?
Again, I am not pressing for Maven, but these are the features that we get for
free with it. Since it looks like we are using ANT, how do we resolve these
needs?
I don't mind if you or anyone presses for Maven. I'm just trying to advance the discussion as I believe you are.
Geoff
