geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Assembling geronimo in M2
Date Fri, 24 Mar 2006 16:25:28 GMT
David,

Thanks for your comments. The maven-assembly-plugin cannot be used by
itself as-is.  Please see my posting on the maven dev list and their
response.

http://www.mail-archive.com/dev@maven.apache.org/msg56911.html

We need features like unpack to a temp location and "flatten" copy for
our schema directory.

We then need extensions to deploy our "car" files.

To complement the inadequacies of the the assembly-plugin we will have
to use a combination of plugins. The dependency-maven-plugin,
antrun-plugin and maybe our own assembly plugin can be used to
workaround this.

If we did something like this, then every assembly (5 so far) would
have to invoke these combination of plugins. Is that OK ? Is that how
we want to do this ? Or do we want to write our own plugin taking the
best of the maven-assembly-plugin, dependency-maven-plugin and our
existing geronimo-assembly-plugin ?

The best option of course would be to enhance the
maven-assembly-plugin by doing some of the following -
1. include a "flatten" flag
2. include the use of a "tempdir", the contents of which will not be archived.
3. allow the <fileset> also to unpack.
4. provide extension points for customized extensions. This won't
corrupt the generic use of the maven-assembly-plugin yet allow users
like Geronimo to extend the usability of the same.

If maven sees the value in this, we could contribute this ourselves.


Cheers
Prasad

On 3/23/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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:
> > http://maven.apache.org/plugins/maven-assembly-plugin/
> > introduction.html
> >
> > dependency-maven-plugin:
> > http://mojo.codehaus.org/dependency-maven-plugin/introduction.html
> >
> > Issue 1:
> > -----------
> > In M1, we tagged the dependencies in the project.xml using
> > dependency.properties 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
> plugin:
>
> 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 :-)
>
> thanks
> david jencks
>
> >
> > Cheers
> > Prasad
> > <bin.xml>
>
>

Mime
View raw message