2013/2/28 Timothy Astle <timothy.as...@caris.com>: > I'll chime in here :) We create the artifact that we want, but we have two. > The WAR created by the maven war plugin, and the overlay war that is > standalone. But we still need the war to package it in the standalone artifact. And all the logic to create a war is in the maven war plugin. And frankly I don't want to copy/paste all this logic to clone it in the tomcat plugin (doesn't make sense IMHO) Maybe what you can try is to use pom packaging (instead of the one you are probably currently using war packaging) and then use the war plugin to package the war which need to be included in the standalone. As it the generated war won't be an attached artifact and won't be deploy. NOTE: It's a solution I didn't test :-) > > We were hoping to only deploy the tomcat overlay war since it does > everything that the other war does, plus contain tomcat. By doing this, we > hope to avoid confusion from staff that may grab the wrong war file from our > artifact repository (Nexus) and accidentally provide it to customers. So > we're trying to be proactively safe. > > Additionally, we have a Selenium grid set up. When our Jenkins build system > makes a build, cargo to grabs the war and failsafe runs our selenium > integration tests. All tests must pass before any artifact is deployed to > Nexus. So in a sense, it feels like cheating to have the tests all pass on > the non-standalone artifact, but we ship the standalone one. I've thought > about using maven tomcat plugin as a means to possibly shore this up, but > there is still a part of me that likes the aspect of being able to deploy to > any type of container via cargo. I haven't had a chance to dig into this > yet, perhaps Rich has, but any expert advice is always much appreciated. > > Tim > > > > > > > On 27/02/2013 6:46 PM, Olivier Lamy wrote: >> >> 2013/2/27 Richard McAleer <rmcal...@caris.com>: >>> >>> Hi, >>> We're using tomcat7-maven-plugin 2.1 to build an executable war using the >>> standalone-war-only goal. The maven build still generates the normal war >>> file as well as the executable .war created by the plugin. However, >>> since >>> the standalone-war-only goal generates a war that is both executable and >>> deployable, we really don't need to generate the normal war file. >>> >>> Is there a good way of generating just the executable war's using the >>> plugin? We could probably have maven delete the original .war file and >>> rename the executable .war to the normal webapp name, but that doesn't >>> seem >>> like the best way of doing it. >> >> Currently no. As the generated executable war/jar contains this war >> (not an exploded war) so it's mandatory to have it. >> BTW what is your use case ? >>> >>> Thanks, >>> Richard >>> >>> -- >>> Richard McAleer >>> Developer >>> Web Development Team >>> >>> *CARIS* <http://www.caris.com> >>> 115 Waggoners Lane >>> Fredericton, New Brunswick >>> Canada E3B 2L4 >>> Tel: +1.506.458.8533 Fax: +1.506.459.3849 >>> www.caris.com <http://www.caris.com> >>> >>> *Connect with CARIS* >>> Twitter <http://www.twitter.com/CARIS_GIS> | LinkedIn >>> <http://www.linkedin.com/groups?mostPopular=&gid=3217878> | Facebook >>> >>> <https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878> >>> | Google+ >>> >>> <https://plus.google.com/b/114389770462919844434/114389770462919844434/posts> >>> | YouTube <http://www.youtube.com/user/CARISGIS> >>> >>> Download your free copy of CARIS Easy View today! >>> www.caris.com/easyview <http://www.caris.com/easyview> >>> >>> _________________________________________________________________________ >>> This email and any files transmitted with it are confidential and >>> intended >>> only for the addressee(s). If you are not the intended recipient(s) >>> please >>> notify us by email reply. You should not use, disclose, distribute or >>> copy >>> this communication if received in error. >>> >>> Any views or opinions expressed in this email are solely those of the >>> author >>> and do not necessarily represent those of the company. No binding >>> contract >>> will result from this email until such time as a written document is >>> signed >>> on behalf of the company. >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
-- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
