You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Prasad Kashyap <go...@gmail.com> on 2006/07/01 00:00:32 UTC
Re: Assembling a Geronimo distribution in a m2 build - first look.
I'm sorry. The earlier maven-assembly-plugin.patch had a whole
directory that had gone missing.
Here is the patch again.
Thanks djencks for catching it.
Cheers
Prasad
On 6/30/06, Prasad Kashyap <go...@gmail.com> wrote:
> For those of you who wish to play with the assembly of Geronimo
> distribution, here it is.
>
> 1. Check out maven-assembly-plugin src from
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin
> .
>
> 2. Apply the patch maven-assembly-plugin.patch attached to this mail
> to the source checked out above.
>
> 3. Build the maven-assembly-plugin using the command
> $> mvn install -Dmaven.test.skip=true
> Skipping test is very important to install the plugin into the repo.
> See Issue #1 below.
>
> 4. Apply the geronimo-assembly-plugin.patch attached to this mail from
> the top level geronimo directory.
>
> 5. Build the geronimo-assembly-plugin.
> $> cd geronimo/m2-plugins/geronimo-assembly-plugin
> $> mvn
>
> 6. Apply the patch j2ee-jetty-server.patch attached to this mail from
> the top level geronimo directory.
>
> 7. Build the assembly
> $> cd geronimo/assembles/j2ee-jetty-server
> $> mvn clean install
>
>
>
> Issues:
> ----------
> 1. maven-assembly-plugin has test failures with this patch. This is
> due to the way plexus archiver treats the archive contents differently
> when added as addDirectory() and addFile(). I am working with Jesse
> McConnell and John Casey to fix this. Due to the July 4th vacation, it
> may be a while before it can get fixed. Once the test failures are
> fixed, we can hope to get the maven-assembly-plugin patch applied and
> a release published.
>
> 2. I haven't had a complete assembly distribution yet. This is because
> I haven't been able to build configs completely. It has been failing
> on openejb-deployer. Those who have had luck with configs may get a
> full assembly distribution.
>
> 3. A minor thing to note that is that this geronimo-assembly-plugin
> may be renamed to match the installConfig mojo in it. Or plugin may be
> merged with the geronimo-packaging-plugin. This plugin contains only 1
> mojo whose goal is to install CAR files. This plugin is ready for
> review and a RTC vote. It's final placement can also be discussed and
> decided.
>
>
> Cheers
> Prasad
>
>
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
Inline -
On 6/30/06, anita kulshreshtha <a_...@yahoo.com> wrote:
> inline..
>
> --- Prasad Kashyap <go...@gmail.com> wrote:
>
> >
> > 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.
>
> In a perfect M2 world just using configs as dependencies should be
> enough. The modules should come as transitive dependencies. I am not
> sure if this is possible with the existing InstallConfig.
>
Your are right.. Existing "installConfig" does care of installing the
module binaries of the configs. But since I am currently handicapped
with an unsuccessful build, I don't know if all the modules are
installed as a part of the config dependencies. So if that is a
redundant step we may eliminate those modules that are installed as
config dependencies into the "repository" directory
Note that we still need to list those modules that are copied into the
lib, lib/ext, lib/ext/endorsed dirs. We should also list the modules
for schemas.
Cheers
Prasad
> Thanks
> Anita
>
>
> >
> > 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
> >
> > On 6/30/06, David Jencks <da...@yahoo.com> wrote:
> > > OK, I got further..... actually into the assembly.
> > >
> > > Prasad, can you outline what the maven assembly plugin is used for?
> > > For me it's objecting to a lot of our dependencies not having maven
> > > poms.... I removed a bunch that don't go into the server any more,
> > > but its now objecting to the jasper compiler not having poms.
> > >
> > > thanks
> > > david jencks
> > >
> > > On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
> > >
> > > > I think that the missing files got included 2 or 3 times in the
> > > > patch.... which makes compiling the result somewhat difficult :-)
> > > >
> > > > Here's a pruned patch with (I hope) only one copy of each missing
> > > > file.
> > > >
> > > > david jencks
> > > > <maven-assembly-plugin.patch>
> > > >
> > > > On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
> > > >
> > > >> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
> > > >> directory that had gone missing.
> > > >>
> > > >> Here is the patch again.
> > > >>
> > > >> Thanks djencks for catching it.
> > > >>
> > > >> Cheers
> > > >> Prasad
> > > >>
> > > >> <snip>
> > >
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
The maven-assembly-plugin throws an error when it can't find a pom,
more so a valid 4.0.0 pom.
It fails at the very first error. So I had to sift thro each error by
commenting out the artifact that depends on that pom. I got till
tranql-1.4-SNAPSHOT. I gave up sifting further because, for one,
tranql's groupId has changed to org.tranql but that is not published
yet. I hope there aren't any more bad/missing poms after tranql.
Here are the missing/invalid poms along with the geronimo artifacts
that I had to comment out in ( ) -
( geronimo-directory )
Project: directory-protocols:ldap-protocol
POM Location: C:\Documents and Settings\Administrator\.m2\repository\directory-p
rotocols\ldap-protocol\0.9.2\ldap-protocol-0.9.2.pom
Reason: Not a v4.0.0 POM.
( geronimo-tomcat )
File C:\Documents and Settings\Administrator\.m2\repository\tomcat\catalina\5.5.
15\catalina-5.5.15.pom does not exist
( geronimo-tomcat )
( geronimo-jetty )
( geronimo-jetty-builder )
File C:\Documents and Settings\Administrator\.m2\repository\tomcat\jasper-compil
er\5.5.15\jasper-compiler-5.5.15.pom does not exist
( geronimo-axis )
( geronimo-axis-builder )
File C:\Documents and Settings\Administrator\.m2\repository\commons-discovery\co
mmons-discovery\0.2-dev\commons-discovery-0.2-dev.pom does not exist
( geronimo-connector )
( geronimo-connector-builder )
Project ID: tranql:tranql
POM Location: C:\Documents and Settings\Administrator\.m2\repository\tranql\tran
ql\1.4-SNAPSHOT\tranql-1.4-SNAPSHOT.pom
Reason: Not a v4.0.0 POM.
Cheers
Prasad
On 7/4/06, Prasad Kashyap <go...@gmail.com> wrote:
> Ooops. Sorry Jason. I was trying to keep up with the emails on my
> vacation and ended up misreading your question. You do clearly ask why
> the d-m-p not be used to install car files.
>
> The geronimo-assembly-plugin (g-a-p) deploys a car artifact. I
> believe that this is a lot more than just unpacking a dependency that
> the d-m-p does. The former also takes care of all the car's
> dependencies too by reading its plan. I don't think the latter could
> have done it.
>
> Cheers
> Prasad
>
> On 7/2/06, Jason Dillon <ja...@planet57.com> wrote:
> > I was never suggesting to not use the assembly plugin, but to use the
> > dependency plugin instead of a custom car installer plugin.
> >
> > --jason
> >
> >
> > On Jul 2, 2006, at 8:25 AM, Prasad Kashyap wrote:
> >
> > > Inline -
> > >
> > > On 7/1/06, Jason Dillon <ja...@planet57.com> wrote:
> > >> >> Why can't the dependency plugin be used to install the car files?
> > >> >
> > >> > I'm not sure what you mean by the dependency plugin.
> > >>
> > >> http://mojo.codehaus.org/dependency-maven-plugin/
> > >>
> > >> It basically handles copying (or unpacking) artifacts and their
> > >> dependencies to somewhere other than the repo cache.
> > >>
> > >
> > > The depenency-maven-plugin (d-m-p) does not meet all our requirements
> > > like the m-a-p does. And for those few requirements that m-a-p
> > > doesn't, it's committers were willing to work with me to take my
> > > patches in and make it suit our requirements.
> > >
> > > The assembly descriptor in the m-a-p has the following features. You
> > > can't find an equivalent functionality in the d-m-p.
> > >
> > > 1. <repositories> can be used to copy into a m2 repo structure.
> > > 2. <fileset> and <file> can be used to copy other files like
> > > var/config/xml which are not in any dependency artifact.
> > > 3. <unpack> will have include/exclude. (my patch)
> > > 4. mapper functionality will introduce some 6 ANT built-in mappers.
> > > Custom mappers can be specified using a classname. We need this to
> > > copy schema files in a flattened structure. (my patch)
> > > 5. The final archive is created in many formats we specify.
> > > 6. Assembly descriptor is a cleaner way of specifying how and where
> > > the different jars are to be copied. (lib, ext, endorsed, repository,
> > > bin, docs etc). Then 2-3 plugin executions are all we need. With the
> > > d-a-p, we woud need a lot more plugin executions, one for each
> > > directory atleast.
> > > 7. In the d-m-p, the artifacts to be copied/processed have to be
> > > specified inside the plugin execution in the long format
> > > <group><artifact>. This will make our pom.xml a very very long one.
> > > In the assembly descriptor of m-a-p, the artifact to be copied is
> > > specified as a groupid:artifactid one liner.
> > >
> > > I'm sure there a few more.
> > >
> > > Cheers
> > > Prasad
> > >
> > >
> > >
> > >>
> > >> --jason
> > >>
> >
> >
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
Ooops. Sorry Jason. I was trying to keep up with the emails on my
vacation and ended up misreading your question. You do clearly ask why
the d-m-p not be used to install car files.
The geronimo-assembly-plugin (g-a-p) deploys a car artifact. I
believe that this is a lot more than just unpacking a dependency that
the d-m-p does. The former also takes care of all the car's
dependencies too by reading its plan. I don't think the latter could
have done it.
Cheers
Prasad
On 7/2/06, Jason Dillon <ja...@planet57.com> wrote:
> I was never suggesting to not use the assembly plugin, but to use the
> dependency plugin instead of a custom car installer plugin.
>
> --jason
>
>
> On Jul 2, 2006, at 8:25 AM, Prasad Kashyap wrote:
>
> > Inline -
> >
> > On 7/1/06, Jason Dillon <ja...@planet57.com> wrote:
> >> >> Why can't the dependency plugin be used to install the car files?
> >> >
> >> > I'm not sure what you mean by the dependency plugin.
> >>
> >> http://mojo.codehaus.org/dependency-maven-plugin/
> >>
> >> It basically handles copying (or unpacking) artifacts and their
> >> dependencies to somewhere other than the repo cache.
> >>
> >
> > The depenency-maven-plugin (d-m-p) does not meet all our requirements
> > like the m-a-p does. And for those few requirements that m-a-p
> > doesn't, it's committers were willing to work with me to take my
> > patches in and make it suit our requirements.
> >
> > The assembly descriptor in the m-a-p has the following features. You
> > can't find an equivalent functionality in the d-m-p.
> >
> > 1. <repositories> can be used to copy into a m2 repo structure.
> > 2. <fileset> and <file> can be used to copy other files like
> > var/config/xml which are not in any dependency artifact.
> > 3. <unpack> will have include/exclude. (my patch)
> > 4. mapper functionality will introduce some 6 ANT built-in mappers.
> > Custom mappers can be specified using a classname. We need this to
> > copy schema files in a flattened structure. (my patch)
> > 5. The final archive is created in many formats we specify.
> > 6. Assembly descriptor is a cleaner way of specifying how and where
> > the different jars are to be copied. (lib, ext, endorsed, repository,
> > bin, docs etc). Then 2-3 plugin executions are all we need. With the
> > d-a-p, we woud need a lot more plugin executions, one for each
> > directory atleast.
> > 7. In the d-m-p, the artifacts to be copied/processed have to be
> > specified inside the plugin execution in the long format
> > <group><artifact>. This will make our pom.xml a very very long one.
> > In the assembly descriptor of m-a-p, the artifact to be copied is
> > specified as a groupid:artifactid one liner.
> >
> > I'm sure there a few more.
> >
> > Cheers
> > Prasad
> >
> >
> >
> >>
> >> --jason
> >>
>
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
I was never suggesting to not use the assembly plugin, but to use the
dependency plugin instead of a custom car installer plugin.
--jason
On Jul 2, 2006, at 8:25 AM, Prasad Kashyap wrote:
> Inline -
>
> On 7/1/06, Jason Dillon <ja...@planet57.com> wrote:
>> >> Why can't the dependency plugin be used to install the car files?
>> >
>> > I'm not sure what you mean by the dependency plugin.
>>
>> http://mojo.codehaus.org/dependency-maven-plugin/
>>
>> It basically handles copying (or unpacking) artifacts and their
>> dependencies to somewhere other than the repo cache.
>>
>
> The depenency-maven-plugin (d-m-p) does not meet all our requirements
> like the m-a-p does. And for those few requirements that m-a-p
> doesn't, it's committers were willing to work with me to take my
> patches in and make it suit our requirements.
>
> The assembly descriptor in the m-a-p has the following features. You
> can't find an equivalent functionality in the d-m-p.
>
> 1. <repositories> can be used to copy into a m2 repo structure.
> 2. <fileset> and <file> can be used to copy other files like
> var/config/xml which are not in any dependency artifact.
> 3. <unpack> will have include/exclude. (my patch)
> 4. mapper functionality will introduce some 6 ANT built-in mappers.
> Custom mappers can be specified using a classname. We need this to
> copy schema files in a flattened structure. (my patch)
> 5. The final archive is created in many formats we specify.
> 6. Assembly descriptor is a cleaner way of specifying how and where
> the different jars are to be copied. (lib, ext, endorsed, repository,
> bin, docs etc). Then 2-3 plugin executions are all we need. With the
> d-a-p, we woud need a lot more plugin executions, one for each
> directory atleast.
> 7. In the d-m-p, the artifacts to be copied/processed have to be
> specified inside the plugin execution in the long format
> <group><artifact>. This will make our pom.xml a very very long one.
> In the assembly descriptor of m-a-p, the artifact to be copied is
> specified as a groupid:artifactid one liner.
>
> I'm sure there a few more.
>
> Cheers
> Prasad
>
>
>
>>
>> --jason
>>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
Inline -
On 7/1/06, Jason Dillon <ja...@planet57.com> wrote:
> >> Why can't the dependency plugin be used to install the car files?
> >
> > I'm not sure what you mean by the dependency plugin.
>
> http://mojo.codehaus.org/dependency-maven-plugin/
>
> It basically handles copying (or unpacking) artifacts and their
> dependencies to somewhere other than the repo cache.
>
The depenency-maven-plugin (d-m-p) does not meet all our requirements
like the m-a-p does. And for those few requirements that m-a-p
doesn't, it's committers were willing to work with me to take my
patches in and make it suit our requirements.
The assembly descriptor in the m-a-p has the following features. You
can't find an equivalent functionality in the d-m-p.
1. <repositories> can be used to copy into a m2 repo structure.
2. <fileset> and <file> can be used to copy other files like
var/config/xml which are not in any dependency artifact.
3. <unpack> will have include/exclude. (my patch)
4. mapper functionality will introduce some 6 ANT built-in mappers.
Custom mappers can be specified using a classname. We need this to
copy schema files in a flattened structure. (my patch)
5. The final archive is created in many formats we specify.
6. Assembly descriptor is a cleaner way of specifying how and where
the different jars are to be copied. (lib, ext, endorsed, repository,
bin, docs etc). Then 2-3 plugin executions are all we need. With the
d-a-p, we woud need a lot more plugin executions, one for each
directory atleast.
7. In the d-m-p, the artifacts to be copied/processed have to be
specified inside the plugin execution in the long format
<group><artifact>. This will make our pom.xml a very very long one.
In the assembly descriptor of m-a-p, the artifact to be copied is
specified as a groupid:artifactid one liner.
I'm sure there a few more.
Cheers
Prasad
>
> --jason
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
>> Why can't the dependency plugin be used to install the car files?
>
> I'm not sure what you mean by the dependency plugin.
http://mojo.codehaus.org/dependency-maven-plugin/
It basically handles copying (or unpacking) artifacts and their
dependencies to somewhere other than the repo cache.
> I haven't thought through yet whether using maven dependencies to
> determine what to copy to the repo is likely to work. The reason
> it's not obvious is that we have a different classloader structure
> than maven, and 2 ways of getting most jars onto the classpath:
> either include the jar directly or import a car that has the jar in
> its classpath. These have very different effects on how many
> copies of the jar are in use, hence on whether you will get
> surprising class cast exceptions. When we are building, first we
> built all the jars so there's no chance to use a car just to get a
> set of dependencies into the classpath as we do in runtime.
Hrm... to bad we don't use ClassWorlds and then just expose the
classworld config... oh well :-(
> I'm not completely sure how it will work out but I think it likely
> that just using the maven dependencies (if we can get them
> accurate) will supply the correct set of dependencies intalled into
> the g. repo. It's certainly worth some experimentation.
It sounds like the Maven depends should be sufficient.
--jason
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by David Jencks <da...@yahoo.com>.
On Jun 30, 2006, at 9:24 PM, Jason Dillon wrote:
> Why can't the dependency plugin be used to install the car files?
I'm not sure what you mean by the dependency plugin. If you mean the
m assembly plugin, one thing it has to do is unpack the car. I don't
know if this is possible.
I haven't thought through yet whether using maven dependencies to
determine what to copy to the repo is likely to work. The reason
it's not obvious is that we have a different classloader structure
than maven, and 2 ways of getting most jars onto the classpath:
either include the jar directly or import a car that has the jar in
its classpath. These have very different effects on how many copies
of the jar are in use, hence on whether you will get surprising class
cast exceptions. When we are building, first we built all the jars
so there's no chance to use a car just to get a set of dependencies
into the classpath as we do in runtime.
I'm not completely sure how it will work out but I think it likely
that just using the maven dependencies (if we can get them accurate)
will supply the correct set of dependencies intalled into the g.
repo. It's certainly worth some experimentation.
thanks
david jencks
>
> --jason
>
>
>>> 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.
>>
>> In a perfect M2 world just using configs as dependencies should be
>> enough. The modules should come as transitive dependencies. I am not
>> sure if this is possible with the existing InstallConfig.
>>
>> Thanks
>> Anita
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
Why can't the dependency plugin be used to install the car files?
--jason
>> 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.
>
> In a perfect M2 world just using configs as dependencies should be
> enough. The modules should come as transitive dependencies. I am not
> sure if this is possible with the existing InstallConfig.
>
> Thanks
> Anita
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by anita kulshreshtha <a_...@yahoo.com>.
inline..
--- Prasad Kashyap <go...@gmail.com> wrote:
> We use the maven-assembly-plugin (m-a-p) to assemble our binary
> distributions in zip, tar and tar.gz formats.
>
> The m-a-p reads an assembly descriptor to copy the dependencies,
> filesets, files into a work areea and then bundles them into archives
> of our chosen formats.
> -- When dependencySets are specified in the descriptor, it copies the
> transitive dependencies also.
> -- The descriptor can also be used to copy deps specified in the
> project from one repo to another repo, or parts of a repo (using
> include/exclude) to another repo. . It maintains the m2 repo
> structure.
>
> Here's the maven-assembly-plugin page
> http://maven.apache.org/plugins/maven-assembly-plugin/
>
> 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.
In a perfect M2 world just using configs as dependencies should be
enough. The modules should come as transitive dependencies. I am not
sure if this is possible with the existing InstallConfig.
Thanks
Anita
>
> 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
>
> On 6/30/06, David Jencks <da...@yahoo.com> wrote:
> > OK, I got further..... actually into the assembly.
> >
> > Prasad, can you outline what the maven assembly plugin is used for?
> > For me it's objecting to a lot of our dependencies not having maven
> > poms.... I removed a bunch that don't go into the server any more,
> > but its now objecting to the jasper compiler not having poms.
> >
> > thanks
> > david jencks
> >
> > On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
> >
> > > I think that the missing files got included 2 or 3 times in the
> > > patch.... which makes compiling the result somewhat difficult :-)
> > >
> > > Here's a pruned patch with (I hope) only one copy of each missing
> > > file.
> > >
> > > david jencks
> > > <maven-assembly-plugin.patch>
> > >
> > > On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
> > >
> > >> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
> > >> directory that had gone missing.
> > >>
> > >> Here is the patch again.
> > >>
> > >> Thanks djencks for catching it.
> > >>
> > >> Cheers
> > >> Prasad
> > >>
> > >> <snip>
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
Inline -
On 7/1/06, Jason Dillon <ja...@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 <ja...@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
> >>
>
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
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.
--jason
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 <ja...@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
>>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
Anita, I don't think we should exclude the jars from including the
META-INF/maven dirs while being created. These jars end up in the
maven repo locally and remotely. They must be there for some reason.
We must exclude them from being extracted. This is what the 2 step
execution aims to acheive.
Cheers
Prasad
On 7/2/06, Jason Dillon <ja...@planet57.com> wrote:
> Then exclude them from being extracted.
>
> --jason
>
>
> On Jul 1, 2006, at 8:13 PM, anita kulshreshtha wrote:
>
> > Here is why we had to exclude them from the wars and rars -
> > http://www.nabble.com/M2-%3A-build-on-Windows-tf1803375.html#a4914787
> >
> > Cheers
> > Anita
> >
> > --- Jason Dillon <ja...@planet57.com> wrote:
> >
> >> Um, why would we want to do that? IMO the descriptors are a good
> >> thing and I do not recommend that we turn that off as a bandaid for
> >> another problem.
> >>
> >> --jason
> >>
> >>
> >> On Jul 1, 2006, at 1:39 PM, anita kulshreshtha wrote:
> >>
> >>> We can exclude META-INF/maven/.... from the jars by configuring
> >>
> >>> the
> >>> jar plugin to use <addMavenDescriptor>false</..>. I have not used
> >> it,
> >>> but it should work.
> >>>
> >>> Thanks
> >>> Anita
> >>>
> >>> --- Prasad Kashyap <go...@gmail.com> 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 <ja...@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
> >>>>>
> >>>>
> >>>
> >>>
> >>> __________________________________________________
> >>> Do You Yahoo!?
> >>> Tired of spam? Yahoo! Mail has the best spam protection around
> >>> http://mail.yahoo.com
> >>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
Then exclude them from being extracted.
--jason
On Jul 1, 2006, at 8:13 PM, anita kulshreshtha wrote:
> Here is why we had to exclude them from the wars and rars -
> http://www.nabble.com/M2-%3A-build-on-Windows-tf1803375.html#a4914787
>
> Cheers
> Anita
>
> --- Jason Dillon <ja...@planet57.com> wrote:
>
>> Um, why would we want to do that? IMO the descriptors are a good
>> thing and I do not recommend that we turn that off as a bandaid for
>> another problem.
>>
>> --jason
>>
>>
>> On Jul 1, 2006, at 1:39 PM, anita kulshreshtha wrote:
>>
>>> We can exclude META-INF/maven/.... from the jars by configuring
>>
>>> the
>>> jar plugin to use <addMavenDescriptor>false</..>. I have not used
>> it,
>>> but it should work.
>>>
>>> Thanks
>>> Anita
>>>
>>> --- Prasad Kashyap <go...@gmail.com> 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 <ja...@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
>>>>>
>>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by anita kulshreshtha <a_...@yahoo.com>.
Here is why we had to exclude them from the wars and rars -
http://www.nabble.com/M2-%3A-build-on-Windows-tf1803375.html#a4914787
Cheers
Anita
--- Jason Dillon <ja...@planet57.com> wrote:
> Um, why would we want to do that? IMO the descriptors are a good
> thing and I do not recommend that we turn that off as a bandaid for
> another problem.
>
> --jason
>
>
> On Jul 1, 2006, at 1:39 PM, anita kulshreshtha wrote:
>
> > We can exclude META-INF/maven/.... from the jars by configuring
>
> > the
> > jar plugin to use <addMavenDescriptor>false</..>. I have not used
> it,
> > but it should work.
> >
> > Thanks
> > Anita
> >
> > --- Prasad Kashyap <go...@gmail.com> 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 <ja...@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
> >>>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
Um, why would we want to do that? IMO the descriptors are a good
thing and I do not recommend that we turn that off as a bandaid for
another problem.
--jason
On Jul 1, 2006, at 1:39 PM, anita kulshreshtha wrote:
> We can exclude META-INF/maven/.... from the jars by configuring
> the
> jar plugin to use <addMavenDescriptor>false</..>. I have not used it,
> but it should work.
>
> Thanks
> Anita
>
> --- Prasad Kashyap <go...@gmail.com> 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 <ja...@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
>>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by anita kulshreshtha <a_...@yahoo.com>.
We can exclude META-INF/maven/.... from the jars by configuring the
jar plugin to use <addMavenDescriptor>false</..>. I have not used it,
but it should work.
Thanks
Anita
--- Prasad Kashyap <go...@gmail.com> 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 <ja...@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
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
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 <ja...@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
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jason Dillon <ja...@planet57.com>.
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
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Prasad Kashyap <go...@gmail.com>.
We use the maven-assembly-plugin (m-a-p) to assemble our binary
distributions in zip, tar and tar.gz formats.
The m-a-p reads an assembly descriptor to copy the dependencies,
filesets, files into a work areea and then bundles them into archives
of our chosen formats.
-- When dependencySets are specified in the descriptor, it copies the
transitive dependencies also.
-- The descriptor can also be used to copy deps specified in the
project from one repo to another repo, or parts of a repo (using
include/exclude) to another repo. . It maintains the m2 repo
structure.
Here's the maven-assembly-plugin page
http://maven.apache.org/plugins/maven-assembly-plugin/
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
On 6/30/06, David Jencks <da...@yahoo.com> wrote:
> OK, I got further..... actually into the assembly.
>
> Prasad, can you outline what the maven assembly plugin is used for?
> For me it's objecting to a lot of our dependencies not having maven
> poms.... I removed a bunch that don't go into the server any more,
> but its now objecting to the jasper compiler not having poms.
>
> thanks
> david jencks
>
> On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
>
> > I think that the missing files got included 2 or 3 times in the
> > patch.... which makes compiling the result somewhat difficult :-)
> >
> > Here's a pruned patch with (I hope) only one copy of each missing
> > file.
> >
> > david jencks
> > <maven-assembly-plugin.patch>
> >
> > On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
> >
> >> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
> >> directory that had gone missing.
> >>
> >> Here is the patch again.
> >>
> >> Thanks djencks for catching it.
> >>
> >> Cheers
> >> Prasad
> >>
> >> <snip>
>
>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by anita kulshreshtha <a_...@yahoo.com>.
Jeff,
THANKS!
Anita
--- Jeff Genender <jg...@apache.org> wrote:
> I can probably create some basic poms for them and push em out.
>
> anita kulshreshtha wrote:
> > We do not have poms for tomcat jars. We have managed so far
> without
> > them. It appears that m. assembly pluign is refusing for work
> without
> > them. May be Jeff can help with this.
> >
> > Thanks
> > Anita
> >
> > --- David Jencks <da...@yahoo.com> wrote:
> >
> >> OK, I got further..... actually into the assembly.
> >>
> >> Prasad, can you outline what the maven assembly plugin is used
> for?
> >>
> >> For me it's objecting to a lot of our dependencies not having
> maven
> >> poms.... I removed a bunch that don't go into the server any more,
>
> >> but its now objecting to the jasper compiler not having poms.
> >>
> >> thanks
> >> david jencks
> >>
> >> On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
> >>
> >>> I think that the missing files got included 2 or 3 times in the
> >>> patch.... which makes compiling the result somewhat difficult :-)
> >>>
> >>> Here's a pruned patch with (I hope) only one copy of each missing
>
> >>> file.
> >>>
> >>> david jencks
> >>> <maven-assembly-plugin.patch>
> >>>
> >>> On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
> >>>
> >>>> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
> >>>> directory that had gone missing.
> >>>>
> >>>> Here is the patch again.
> >>>>
> >>>> Thanks djencks for catching it.
> >>>>
> >>>> Cheers
> >>>> Prasad
> >>>>
> >>>> <snip>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by Jeff Genender <jg...@apache.org>.
I can probably create some basic poms for them and push em out.
anita kulshreshtha wrote:
> We do not have poms for tomcat jars. We have managed so far without
> them. It appears that m. assembly pluign is refusing for work without
> them. May be Jeff can help with this.
>
> Thanks
> Anita
>
> --- David Jencks <da...@yahoo.com> wrote:
>
>> OK, I got further..... actually into the assembly.
>>
>> Prasad, can you outline what the maven assembly plugin is used for?
>>
>> For me it's objecting to a lot of our dependencies not having maven
>> poms.... I removed a bunch that don't go into the server any more,
>> but its now objecting to the jasper compiler not having poms.
>>
>> thanks
>> david jencks
>>
>> On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
>>
>>> I think that the missing files got included 2 or 3 times in the
>>> patch.... which makes compiling the result somewhat difficult :-)
>>>
>>> Here's a pruned patch with (I hope) only one copy of each missing
>>> file.
>>>
>>> david jencks
>>> <maven-assembly-plugin.patch>
>>>
>>> On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
>>>
>>>> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
>>>> directory that had gone missing.
>>>>
>>>> Here is the patch again.
>>>>
>>>> Thanks djencks for catching it.
>>>>
>>>> Cheers
>>>> Prasad
>>>>
>>>> <snip>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by anita kulshreshtha <a_...@yahoo.com>.
We do not have poms for tomcat jars. We have managed so far without
them. It appears that m. assembly pluign is refusing for work without
them. May be Jeff can help with this.
Thanks
Anita
--- David Jencks <da...@yahoo.com> wrote:
> OK, I got further..... actually into the assembly.
>
> Prasad, can you outline what the maven assembly plugin is used for?
>
> For me it's objecting to a lot of our dependencies not having maven
> poms.... I removed a bunch that don't go into the server any more,
> but its now objecting to the jasper compiler not having poms.
>
> thanks
> david jencks
>
> On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
>
> > I think that the missing files got included 2 or 3 times in the
> > patch.... which makes compiling the result somewhat difficult :-)
> >
> > Here's a pruned patch with (I hope) only one copy of each missing
> > file.
> >
> > david jencks
> > <maven-assembly-plugin.patch>
> >
> > On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
> >
> >> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
> >> directory that had gone missing.
> >>
> >> Here is the patch again.
> >>
> >> Thanks djencks for catching it.
> >>
> >> Cheers
> >> Prasad
> >>
> >> <snip>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by David Jencks <da...@yahoo.com>.
OK, I got further..... actually into the assembly.
Prasad, can you outline what the maven assembly plugin is used for?
For me it's objecting to a lot of our dependencies not having maven
poms.... I removed a bunch that don't go into the server any more,
but its now objecting to the jasper compiler not having poms.
thanks
david jencks
On Jun 30, 2006, at 3:33 PM, David Jencks wrote:
> I think that the missing files got included 2 or 3 times in the
> patch.... which makes compiling the result somewhat difficult :-)
>
> Here's a pruned patch with (I hope) only one copy of each missing
> file.
>
> david jencks
> <maven-assembly-plugin.patch>
>
> On Jun 30, 2006, at 3:00 PM, Prasad Kashyap wrote:
>
>> I'm sorry. The earlier maven-assembly-plugin.patch had a whole
>> directory that had gone missing.
>>
>> Here is the patch again.
>>
>> Thanks djencks for catching it.
>>
>> Cheers
>> Prasad
>>
>> <snip>
Re: Assembling a Geronimo distribution in a m2 build - first look.
Posted by David Jencks <da...@yahoo.com>.
I think that the missing files got included 2 or 3 times in the
patch.... which makes compiling the result somewhat difficult :-)
Here's a pruned patch with (I hope) only one copy of each missing file.
david jencks