2015-05-05 16:19 GMT+02:00 Adam Cornett <[email protected]>:

> 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 <[email protected]
> >
> 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 <[email protected]>:
> >
> > > 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 <
> > [email protected]>
> > > wrote:
> > >
> > > > Hi
> > > >
> > > >
> > > > 2015-05-05 15:47 GMT+02:00 Adam Cornett <[email protected]>:
> > > >
> > > > > 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
> > > [email protected]
> > > (678) 296-1150
> > >
> >
>
>
>
> --
> Adam Cornett
> [email protected]
> (678) 296-1150
>

Reply via email to