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 18:48:31 GMT
http://jira.codehaus.org/browse/MASSEMBLY-45 is open for requesting
the "flatten" feature.

http://jira.codehaus.org/browse/MASSEMBLY-41 can help us extract
*-builder-* for our schemas.

Cheers
Prasad

On 3/24/06, Prasad Kashyap <goyathlay.geronimo@gmail.com> wrote:
> 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