Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 10887 invoked from network); 23 Mar 2006 08:06:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Mar 2006 08:06:53 -0000 Received: (qmail 72688 invoked by uid 500); 23 Mar 2006 08:06:52 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 72084 invoked by uid 500); 23 Mar 2006 08:06:51 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 72073 invoked by uid 99); 23 Mar 2006 08:06:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Mar 2006 00:06:51 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.136.173.57] (HELO smtp013.mail.yahoo.com) (216.136.173.57) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 23 Mar 2006 00:06:50 -0800 Received: (qmail 57454 invoked from network); 23 Mar 2006 08:06:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=Kj1ZZrnG13/We8M9DCtg/DaVkZjknZpRas/vbcDfvPNWIAlKSa9Du3j/7rF23jhLsnOan5mfF2KgaWQlW0BYJrFf9HUgvp2s6d/aaxn9RPhDsAztnH7XBG5Izs9WYiiqYJ+P66tG+0xhKYc3IVvRMs8zfqKw6APQj6is0uQ9qZE= ; Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with plain) by smtp013.mail.yahoo.com with SMTP; 23 Mar 2006 08:06:29 -0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CCA2CBE-30B6-410F-A414-8A8D759503F4@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Assembling geronimo in M2 Date: Thu, 23 Mar 2006 00:06:26 -0800 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.746.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 element under . > 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 >