Perhaps I have not done a good job explaining how I'm using (abusing?) the
tomee plugin:
I have a pom only project that uses the tomee maven plugin to generate a
tomee zip, adding in the conf, replacing openjpa with hibernate adding
several other libraries, adding the setenv.(bat|sh) files with the correct
java settings, etc. We use classifiers to create one zip per environment
(dev, qa, prod, etc)
This zip file is attached to the project and published to our maven repo.
The plugin configuration is then set in our top level pom's
pluginManagement and to use it in one of our projects we just have to
include the groupId and artifactId.
in pluginManagment:
<plugin>
<groupId>org.apache.openejb.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>${tomee.version}</version>
<configuration>
<tomeeGroupId>com.example</tomeeGroupId>
<tomeeArtifactId>tomee</tomeeArtifactId>
<tomeeClassifier>dev</tomeeClassifier>
<tomeeVersion>${tomee.version}</tomeeVersion>
</configuration>
</plugin>
in a project:
<plugin>
<groupId>org.apache.openejb.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
</plugin>
Thus each app can use mvn tomee:run for dev testing, and use use the build
goal to publish a tomee zip fully bundled up and ready to deploy to a
server (we attach the zip to all of our EAR projects along with the ear)
This keeps the poms and source trees sane, previously we had to keep copies
(using svn:externals, but still ugly) of the tomee config with each ear.
It also simplifies our Arquillian tests, since we are using such a heavily
modified version of TomEE we'd have to duplicate all of the changes in the
arquillian.xml, so a custom zip solves that problem too.
Using a custom zip file I can keep up our internal tomee build and no one
else on the dev team has to worry about getting the right setup in their
checkout or pom to have it build and run correctly.
The patch was attached to the original email is inline below and
re-attached:
diff --git
a/maven/tomee-maven-plugin/src/main/java/org/apache/openejb/maven/plugin/AbstractTomEEMojo.java
b/maven/tomee-maven-plugin/src/main/java/org/apache/openejb/maven/plugin/AbstractTomEEMojo.java
index 6c8b412..86b13e8 100644
---
a/maven/tomee-maven-plugin/src/main/java/org/apache/openejb/maven/plugin/AbstractTomEEMojo.java
+++
b/maven/tomee-maven-plugin/src/main/java/org/apache/openejb/maven/plugin/AbstractTomEEMojo.java
@@ -78,6 +78,19 @@
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;
+import javax.xml.parsers.DocumentBuilder;
+import javax.xml.parsers.DocumentBuilderFactory;
+import javax.xml.transform.OutputKeys;
+import javax.xml.transform.Transformer;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMSource;
+import javax.xml.transform.stream.StreamResult;
+
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+import org.w3c.dom.NodeList;
+
+
import static org.apache.maven.artifact.Artifact.SCOPE_COMPILE;
import static
org.apache.maven.artifact.repository.ArtifactRepositoryPolicy.CHECKSUM_POLICY_WARN;
import static
org.apache.maven.artifact.repository.ArtifactRepositoryPolicy.UPDATE_POLICY_DAILY;
@@ -1330,13 +1343,28 @@
&& (
(apps != null && !apps.isEmpty())
|| (!"pom".equals(packaging) &&
!"war".equals(packaging))))) { // webapps doesn't need apps folder in tomee
- final FileWriter writer = new FileWriter(file);
- final String rootTag = container.toLowerCase(Locale.ENGLISH);
- writer.write("<?xml version=\"1.0\"?>\n" +
- "<" + rootTag + ">\n" +
- " <Deployments dir=\"apps\" />\n" +
- "</" + rootTag + ">\n");
- writer.close();
+ // check to see if there is already a Deployments tag in the
current file
+ // if there isn't one, add it to the document
+ try{
+ DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
+ Document doc = builder.parse(file);
+
+ if(doc.getElementsByTagName("Deployments").getLength() ==
0){
+ Element deploymentsElement =
doc.createElement("Deployments");
+ deploymentsElement.setAttribute("dir", "apps");
+ // get the 'tomee' or 'openejb' tag and add the
deployments element
+
doc.getElementsByTagName(container.toLowerCase(Locale.ENGLISH)).item(0).appendChild(deploymentsElement);
+
+ // now write the new xml file
+ Transformer transformer =
TransformerFactory.newInstance().newTransformer();
+ transformer.setOutputProperty(OutputKeys.INDENT,
"yes");
+ DOMSource source = new DOMSource(doc);
+ StreamResult fileOut = new StreamResult(file);
+ transformer.transform(source, fileOut);
+ }
+ }catch(Exception e){
+ getLog().error("Exception updating " + file.getName(), e);
+ }
final File appsFolder = new File(catalinaBase, "apps");
if (!appsFolder.exists() && !appsFolder.mkdirs()) {
On Tue, May 5, 2015 at 10:29 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> 2015-05-05 16:19 GMT+02:00 Adam Cornett <adam.corn...@gmail.com>:
>
> > Like I said, there are many ways to work around this issue :-)
> >
> > I was just offering a change to the plugin to be more selective in how it
> > changes the built in file to keep our build process as simple as
> possible.
> > I found it odd that the plugin was careful to honor custom changes to the
> > server.xml file and only make selected changes to it, but it will
> wholesale
> > replace the tomee.xml file if you use 'ear' or 'ejb' packaging. When it
> > does this it also wipes out the documentation comments that ship with the
> > default file. The patch I sent keeps the original file's contents and
> > simply appends the deployments tag when needed if it is not already
> > present, which is really the desired result of the method in question.
> >
> >
>
> Well server.xml is another story. We fully control tomee.xml but not
> server.xml and we try to not break tomcat update for this last one. ALso we
> update this last one once we setup everything which can mean a user can
> have overriden the file which shouldn't be the case for tomee.xml.
>
> The easiest fix for your case is surely a flag 'dontTouchMyTomeeXml' but it
> will not simplify your build. Alternative can be to support a config.jar
> but it is not simpler since you need to configure it again for all
> distributions.
>
> Also what I dont get is why using tomee-maven-plugin if you start from an
> existing tomee zip you provide. Doing it you loose the interest of tomee
> maven plugin build command which is to provide a standard layout.
>
> Just trying to see how to simplify the process without reimplementing other
> maven plugins
>
> Side note: not sure if gmail swallowed it but i didnt get any patch
>
>
> > On Tue, May 5, 2015 at 10:07 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > I see, why not executing maven dependency plugin before
> > tomee-maven-plugin
> > > and referencing the unpacked folder for the conf?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com>
> > >
> > > 2015-05-05 16:01 GMT+02:00 Adam Cornett <adam.corn...@gmail.com>:
> > >
> > > > Since the conf is loaded into the zip file when we build it we are
> not
> > > > re-supplying the conf each time we use the plugin. Since all of our
> > apps
> > > > use a common conf we wanted it in one place instead of having copies
> > > > attached to each project.
> > > >
> > > > On Tue, May 5, 2015 at 9:57 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi
> > > > >
> > > > >
> > > > > 2015-05-05 15:47 GMT+02:00 Adam Cornett <adam.corn...@gmail.com>:
> > > > >
> > > > > > We use TomEE in several applications, and to speed up builds and
> > > > > > standardize our deployments, we use the Maven plugin to create a
> > > TomEE
> > > > > zip
> > > > > > already configured with our libraries and configuration files and
> > > > publish
> > > > > > it to our internal maven repo.
> > > > > >
> > > > > > We then use the TomEE maven plugin in each project to pull in
> this
> > > > custom
> > > > > > build and deploy our application into it. However the current
> > maven
> > > > > plugin
> > > > > > will overwrite the conf/tomee.xml file that we have packaged.
> This
> > > > > happens
> > > > > > because the plugin is trying to be helpful by adding the
> > > '<Deployments
> > > > > > dir="apps" />' tag, which is not enabled in the file that ships
> > with
> > > > the
> > > > > > original zip, however it does this by writing out a whole new
> file
> > > with
> > > > > > this tag.
> > > > > >
> > > > > >
> > > > > it does it during tomee unzip phase which is before the
> > synchronization
> > > > > with conf folder so your file should override the forced one.
> > > > >
> > > > > What do I miss?
> > > > >
> > > > >
> > > > > > There are many ways to go about solving this issue, the one I
> came
> > up
> > > > > with
> > > > > > is in the attached patch, developed against 2.0. This does a
> more
> > > > > surgical
> > > > > > update of an existing tomee.xml file without touching over any
> > > existing
> > > > > > changes. If this needs further changes or refinement in order to
> > be
> > > > > > accepted into the project I'd be glad to continue to work on it
> > based
> > > > on
> > > > > > feedback.
> > > > > >
> > > > > >
> > > > > > - Adam Cornett
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Adam Cornett
> > > > adam.corn...@gmail.com
> > > > (678) 296-1150
> > > >
> > >
> >
> >
> >
> > --
> > Adam Cornett
> > adam.corn...@gmail.com
> > (678) 296-1150
> >
>
--
Adam Cornett
adam.corn...@gmail.com
(678) 296-1150
