cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Ant/Maven/Centipede discussion
Date Mon, 29 Sep 2003 16:36:09 GMT

On Monday, Sep 29, 2003, at 15:38 Europe/Rome, 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.
>
> 1) Dependency resolution.  Let's face it, blocks will depend on other 
> blocks.

you bet.

>    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?

???? dependencies are the block URIs, the block librarian will provide 
all the info about the various URIs, either for human consumption and 
for the block deployer consumption (metadata)

I don't see how maven helps with this.

> 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.

sorry, I don't get it. <copy> and <zip> can do everything we need. The 
block metadata files will have to be human edited anyway.

[besides, you don't need to install ant tasks on your box, they can be 
picked up from anywhere, and we already do this and nobody ever 
objected]

> 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.

jar in repository is one concern, dependencies are another.

the first is solvable with a few <get> tasks. piece of cake. we can 
reuse the ibiblo maven repositories if we want, no problem with that.

for dependencies, see below.

> 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 are polymorphic. does Maven support this?

> 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.

Look at the CVS history file for our build files: they haven't been 
touched in months.

> 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?

you are coming up with "supposed needs" and I have the impression you 
have no idea of the complexity that the new block system will require, 
a complexity that not even maven is designed to handle.

how do we resolve these needs? I don't know, but we need to have the 
needs emerge.

Moreover, less dependencies gives us more freedom to innovate without 
fighting with other communities on what they think is good or not.

--
Stefano.


Mime
View raw message