On 28/02/2013 9:32 AM, Olivier Lamy wrote:
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)
I completely understand your point. That would cause duplication of
code and extra maintenance.
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 :-)
haha, fair enough. To be honest, I don't think we want to pursue that
route either. I much prefer explicit modelling of a project and avoid
scripting. Going that route just leads to pain and suffering unless
there is a really, really strong reason to do so.
Many thanks for your feedback, it is much appreciated.
Tim
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
