On Mon, May 13, 2002 at 11:23:19AM +1000, [EMAIL PROTECTED] wrote:
>
> Jeff writes:
>
> | Having some minimal plugin versioning scheme from the beginning would be
> | good. Avoids having to retrofit them ala Centipede. Perhaps with a
> | well-defined <major>.<minor>.<micro> revision system, so plugins can be
> | automatically updated in the future by a 'maven:download-plugin' task.
> Yep. My take is that plug-ins MUST be versioned in the filename, i.e.
> maven-j2ee-1.0.0.jar.
Cool. Preferably also in a property too, so that unjarred plugins don't
lose the info.
> | One question: say I've written a documentation plugin, which needs to be
> | run whenever the user types 'ant maven:docs'. Or say I write a code
> | beautifier task, which needs to be run before the javadocs target. How
> | can this be done?
> This is something I've thought about over the weekend. Dependencies between
> plug-ins. And 'injecting' plug-ins into the standard processes (compile,
> test, docs etc).
>
> I think dependencies are pretty easily handled when you merge the
> delegators, as maven:war can declare it depends on maven:jar at the target
> level.
>
> 'Injecting' is a bit more complex, but I think as part of the merge
> process, plug-ins could declare that they be part of a 'standard' target,
> as a pre or post req.
That works, if they're 'injected' between two *standard* targets. What
happens if one is another plugin target? Gets confusing.. anyway, as
long as you've considered the problems :)
> | Essentially, the problem is that execution paths are currently
> | hardcoded, and adding plugins implies that they must become dynamic.
> | That sounds like quite a big architectural change. Perhaps plugins could
> | register themselves with the POM, which could then determine the correct
> | plugin target execution order, and generate a build.xml appropriately?
> | As you can see, I'm hazy as to exactly how Maven works, but leveraging
> | the POM could be a key to implementing plugins properly.
> My take is the POM is the *project* model, not the *build* model. Maven
> doesn't really have a 'build' model, and to some extent, that's what this
> discussion is about... I think we need a 'build model', even if it's just
> in code.
Exactly! That's been confusing me for ages.. I used to think Maven
worked like this:
- Read project.xml and build a BOM (build object model)
- 'Serialize' the BOM into a build.xml, utilizing snippets of Ant
script liberally sprinkled with ${variables} (really dvsl templates)
- Invoke the dynamically generated build.xml
With that model, the generated build.xml can be really simple, because
all the dynamic stuff is done in the 'BOM'. In particular, the linkages
between targets (depends attributes) are determined at runtime, which
means that plugins (and callbacks) can naturally slot in. Using a BOM
would also allow the Ant snippets (build-*.xml files) to be a lot
cleaner. No duplicate 'verify-project' targets, no 'if'/'unless'
attributes on targets, etc.
Hmm..
Question: what would the relation between the POM and a 'BOM' be? If
you've got a BOM, do you still need a POM?
--Jeff
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
