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 <[EMAIL PROTECTED]> 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/[email protected]/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 <[EMAIL PROTECTED]> 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> > > > > >
