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 a Geronimo distribution in a m2 build - first look.
Date Sun, 02 Jul 2006 14:39:44 GMT
Inline -

On 7/1/06, Jason Dillon <jason@planet57.com> wrote:
> Aight... well lets get it working asis for now...
>
> I think we don't need to run the assembly plugin twice to get to the
> same place, but we can fix that once something is working.

I spoke to Jesse about this problem and how we can fix this. His
suggestion was to use the 2 step execution rather than fix the m-a-p
to exclude those jars.

There is already a <includeMetataData> in the assembly descriptor
which excludes the metadata.xml files that get generated in the repo.
IMO, a similar flag to exclude the META-INF/maven would be nicer.

>
> --jason

Cheers
Prasad


>
>
> On Jul 1, 2006, at 1:23 PM, Prasad Kashyap wrote:
>
> > The m-a-p is invoked twice for the following reasons:
> >
> > When we copy some modules into a m2 repo structure format, it also
> > copies the META-INF/maven/.. directories. This unneccesary directory
> > introduces a very long path too. So in the first execution, we use the
> > <intermediaryAssembly> to skip the archive process. In the second
> > execution, we copy over the repo structure from the staging area but
> > exclude the META-INF/maven dirs into our geronimo/repository.
> >
> >
> > We are unpacking scripts in the first execution. I think it's
> > redundant. I'll remove it.
> >
> > Cheers
> > Prasad
> >
> >
> >
> > On 7/1/06, Jason Dillon <jason@planet57.com> wrote:
> >> Why do we need to invoke the assembly plugin twice?  It does not look
> >> like there is anything in the steps you listed below that actually
> >> requires that the assembly plugin be invoked twice.  Maybe I am
> >> wrong, can you shed some light on this please?
> >>
> >> --jason
> >>
> >>
> >> > Here's how we assemble our binaries
> >> >
> >> > 1. Our pom.xml first lists all and only geronimo modules,
> >> configs and
> >> > apps as dependencies. The transitive deps are taken care of by m-
> >> a-p.
> >> >
> >> > 2. We first invoke the geronimo-assembly-plugin's
> >> "installConfig" goal
> >> > to install the configs into target/archive-temp/repository. This
> >> mojo
> >> > will try to install all dependencies of type "car" when no
> >> artifact is
> >> > explicitly specified. Since we have listed all configs as deps
> >> in our
> >> > j2ee-jetty-server pom.xml, they are installed.
> >> >
> >> > 3. Then we invoke m-a-p with assembly descriptor setup.xml and
> >> > intermediaryAssembly set to true.  The intermediaryAssembly set to
> >> > true will create the staging area but skip the final archive
> >> creation.
> >> > The setup.xml will copy all deps other than the <excludes> from
> >> > localRepository to target/archive-temp/repository. We exclude the
> >> > configs here b'coz the configs are installed in step 2 above. So
> >> now
> >> > we have the modules and the configs all in the same repo.
> >> >
> >> > 4. We also use this setup.xml to unpack the scripts module into the
> >> > staging area.
> >> >
> >> > 5. Then we invoke m-a-p again with assembly descriptor bin.xml. The
> >> > plugin copies the library jars, the schema files, the jars for bin
> >> > etc. The *.bat and *.sh files that we copied into the staging
> >> area  in
> >> > step 4 are now bundled into the archive but with correct mode and
> >> > lineendings..
> >> >
> >> > That's about it.
> >> >
> >> > Cheers
> >> > Prasad
> >>
>
>

Mime
View raw message