Re: Assembling a Geronimo distribution in a m2 build - first look.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. can be used to copy into a m2 repo structure. > > 2. and can be used to copy other files like > > var/config/xml which are not in any dependency artifact. > > 3. 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 > > . 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.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. can be used to copy into a m2 repo structure. > 2. and can be used to copy other files like > var/config/xml which are not in any dependency artifact. > 3. 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 > . 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.
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 <[EMAIL PROTECTED]> 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. can be used to copy into a m2 repo structure. 2. and can be used to copy other files like var/config/xml which are not in any dependency artifact. 3. 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 . 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.
Inline - On 7/1/06, Jason Dillon <[EMAIL PROTECTED]> 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. can be used to copy into a m2 repo structure. 2. and can be used to copy other files like var/config/xml which are not in any dependency artifact. 3. 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 . 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.
Inline - On 7/1/06, Jason Dillon <[EMAIL PROTECTED]> 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 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 > 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 <[EMAIL PROTECTED]> 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 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.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 false. I have not used >> it, >>> but it should work. >>> >>> Thanks >>> Anita >>> >>> --- Prasad Kashyap <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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 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.
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 <[EMAIL PROTECTED]> 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 false. I have not used it, but it should work. Thanks Anita --- Prasad Kashyap <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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 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.
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 <[EMAIL PROTECTED]> 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 false. I have not used > it, > > but it should work. > > > > Thanks > > Anita > > > > --- Prasad Kashyap <[EMAIL PROTECTED]> 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 > >> 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 <[EMAIL PROTECTED]> 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 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.
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 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 <[EMAIL PROTECTED]> 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 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.
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 false. I have not used it, but it should work. Thanks Anita --- Prasad Kashyap <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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 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.
We can exclude META-INF/maven/ from the jars by configuring the jar plugin to use false. I have not used it, but it should work. Thanks Anita --- Prasad Kashyap <[EMAIL PROTECTED]> 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 > 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 <[EMAIL PROTECTED]> 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 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.
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 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 <[EMAIL PROTECTED]> 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 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.
Inline - On 6/30/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: inline.. --- Prasad Kashyap <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > 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 > > >> > > >> > > > > > __ 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.
Jeff, THANKS! Anita --- Jeff Genender <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >>> > >>> > >>> 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 > > > >> > > > > > > __ > > 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.
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 <[EMAIL PROTECTED]> 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 >>> >>> >>> 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 >> > > > __ > 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.
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 <[EMAIL PROTECTED]> 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 > > > > > > 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 > >> > >> > > __ 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.
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.
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.
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.
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 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.
inline.. --- Prasad Kashyap <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > 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 > > >> > > >> > > > > > __ 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.
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 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 <[EMAIL PROTECTED]> 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 > > > 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 >> >>
Re: Assembling a Geronimo distribution in a m2 build - first look.
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 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
