Configurations as Maven Artifacts?

[Jeremy Boynes <jb...@gluecode.com>]

A random thought occured to me as I was sitting watching the build that 
the assembly module, especially its maven.xml, was getting bigger and 
bigger and that we might be better splitting things up.

One of the main things it is doing is building different configurations, 
many of which are not actually related to each other. These could 
actually be treated as Maven artifacts that are produced by the 
gernonimo deployment plugin. These artifacts could be shared between 
multiple assemblies eliminating the duplication in e.g. OpenEJB, 
ActiveMQ, Axis, etc.

To make this work we would split assembly into three:
* A module that built the deployment plugin

* Modules that built each configuration using the deployment plugin

* Modules that built each assembly by creating the distribution tree,
   pre-loading its repo and installing the necessary configurations.
   Geronimo would have its, other projects could assemble the configs
   they needed.

This should also speed up the build as the configurations would be built 
in-vm by the plugin rather than forking the command-line deployer every 
time.

--
Jeremy

Re: Configurations as Maven Artifacts?

[Jeremy Boynes <jb...@gluecode.com>]

Dain Sundstrom wrote:
> On Nov 22, 2004, at 10:57 AM, Jeremy Boynes wrote:
> 
>> This should also speed up the build as the configurations would be 
>> built in-vm by the plugin rather than forking the command-line 
>> deployer every time.
> 
> 
> Do we have a plugin that can do this today?  I thought our current 
> plugin only worked with a running server, which would mean a fork.  
> Anyway, it would be very nice if we didn't need to fork.
> 

AIUI the current plugin invokes the JSR-88 code which would expect to 
work with an external server - when does that it certainly runs quicker 
than the deployments done from assembly's maven.xml.

We would probably need to tweak it a little further so that it could 
load both jar and configuration artifacts from the local Maven repo - 
basically have both the Repo and ConfigStore impls work against what was 
being output during the build process.

It might also be worth developing a new plugin to handle the assembly 
steps - creating the server's repo, installing configs, etc. - given 
that is currently duplicated in the different projects.

--
Jeremy

Re: Configurations as Maven Artifacts?

[Dain Sundstrom <ds...@gluecode.com>]

On Nov 22, 2004, at 10:57 AM, Jeremy Boynes wrote:

> A random thought occured to me as I was sitting watching the build 
> that the assembly module, especially its maven.xml, was getting bigger 
> and bigger and that we might be better splitting things up.
>
> One of the main things it is doing is building different 
> configurations, many of which are not actually related to each other. 
> These could actually be treated as Maven artifacts that are produced 
> by the gernonimo deployment plugin. These artifacts could be shared 
> between multiple assemblies eliminating the duplication in e.g. 
> OpenEJB, ActiveMQ, Axis, etc.
>
> To make this work we would split assembly into three:
> * A module that built the deployment plugin
>
> * Modules that built each configuration using the deployment plugin
>
> * Modules that built each assembly by creating the distribution tree,
>   pre-loading its repo and installing the necessary configurations.
>   Geronimo would have its, other projects could assemble the configs
>   they needed.

+1 cool idea

> This should also speed up the build as the configurations would be 
> built in-vm by the plugin rather than forking the command-line 
> deployer every time.

Do we have a plugin that can do this today?  I thought our current 
plugin only worked with a running server, which would mean a fork.  
Anyway, it would be very nice if we didn't need to fork.

-dain