geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Assembling geronimo in M2
Date Thu, 23 Mar 2006 08:06:26 GMT

On Mar 22, 2006, at 7:12 PM, Prasad Kashyap wrote:

> For assembling Geronimo, we used to have our own homegrown
> geronimo-assembly-plugin. As we migrate to M2, we have atleast of a
> couple of assembly plugins available from maven.
> maven-assembly-plugin:
> introduction.html
> dependency-maven-plugin:
> Issue 1:
> -----------
> In M1, we tagged the dependencies in the project.xml using
> element to indicate where we should copy the
> jars and how we should process it later. We had one list. M2 pom.xml
> format doesn't allow such a <property> element  under <dependency>.
> Apart from specifying the deps in the pom.xml, we have to list the
> jars, their final resting place and how they have to be processed
> elsewhere. This would seem like having to maintain multiple lists of
> deps.
> I hope the transitive deps feature of M2 might obviate the need to
> specify the long list of deps in pom.xml. So we may end up with only 1
> list. Not fully sure about this.

there are pretty much 3 kinds of thing dealt with by our assembly  

1. misc files such as scripts and stuff that gets unpacked into the  
geronimo server we're assembliing.  I'd imagine the m2 assembly  
plugin can be convinced to do this pretty easily.  These need to be  
specified explicity.

2. stuff that for one reason or another needs to get copied from the  
local maven repo into bin or lib.  I suspect that the m2 plugin can  
be coerced into doing this also.  These need to be specified explicitly.

3. Everything else, consisting of car files or jars from the local  
repo.  The desired action here basically consists of copying them and  
all their transitive dependencies from the local maven repo and  
installing them into the geronim repo.  In order for this to work  
some bits from 1.1 are needed, and they might need extension.  In  
particular, the 1.1 config-store is based on a repository, so  
installing the car files into the repo is sufficient.  I think the  
1.1 repo automatically unpacks car files when you install them: if  
not this needs to be added.  In particular simply copying the files  
into the appropriate location is not adequate: an "install" operation  
on the geronimo repo needs to be used.
> Issue 2:
> ------------
> The maven-assembly-plugin uses something called a descriptor xml.
> Please see the attached prototype (not yet complete).  This plugin can
> do some post-processing like unpack and set permissions but not a
> whole lot like we used to do in our geronimo-assemly-plugin.
> We have, for example, some java code in assemble:installConfig and
> assemble:installConfigToRepo that processes deps of type "car".  Such
> processing forces us to use another plugin, say maven-antrun-plugin or
> one of our own. We have 2 options.
> Option a :  all these plugins could be invoked in sequence from the
> assemblies themselves.  The geronimo-assembly-plugin doesn't take care
> of all the assembly. It may be used to partly provide some
> post-processing or may not be used at all.  But all the assemblies
> must invoke a series of plugins.
> Option b: Our geronimo-assembly-plugin does it all. For this, it needs
> to copy/inherit fom the maven-assembly-plugin and then further enhance
> it to do other post-processing we require.  I am leaning towards this
> unless some M2 developers believe their assembly plugin can handle or
> be changed to handle our requirements.

I haven't looked at the descriptor yet.  I hope that we can use the  
assembly plugin to essentially call an "install" operation on our repo.
> Issue 3:
> ------------
> Our current repository format is
> ${groupId}/jars/${groupId}-${version}.jar. This mirrors the .maven
> repository. The .m2 repository format is different. Also, the
> maven-assembly-plugin just dumps all the jars in the output directory
> (assembly's repository dir). Our runtime should change to expect jars
> in this new location.

1.1 is using a maven2-structured repository.  I'd recommend waiting  
for the 1.1>> 1.2 merge or porting this class now rather than  
struggling with an m1 structured geronimo repo.
> Comments ?

When this starts working I think we will have a challenge to trim our  
dependencies so that little-g ends up the same size it is now :-)

david jencks

> Cheers
> Prasad
> <bin.xml>

View raw message