maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Maven and JPA/EclipseLink Configuration...
Date Wed, 10 Jul 2013 08:23:44 GMT
Well the first thing I would look towards is whether you can use an
application server specific deployment descriptor to tweak the effective
persistence.xml at deployment time.

I am not saying that the above is possible, but if it is, then that is
obviously "the way to go" as you then can just bundle all the application
server specific deployment descriptors into the .ear and you have one .ear
that works for everyone.

I have a constant battle with people in work who feel that application
server specific deployment descriptors are an anti-pattern... and if you
think it is ok to follow the JavaEE spec's vision of the deployment
process, then that may indeed be a valid view... but the real world does
not work that way... and hence you need the application server specific
deployment descriptors.

Ok let's take a step back, and look at where I am coming from.

The JavaEE spec lists a role of application deployer:

*# Application Deployer and Administrator
> *The application deployer and administrator is the company or person who
> configures and deploys application clients, web applications, Enterprise
> JavaBeans components, and Java EE applications, administers the computing
> and networking infrastructure where Java EE components and applications
> run, and oversees the runtime environment. Duties include setting
> transaction controls and security attributes and specifying connections to
> databases.
> During configuration, the deployer follows instructions supplied by the
> application component provider to resolve external dependencies, specify
> security settings, and assign transaction attributes. During installation,
> the deployer moves the application components to the server and generates
> the container-specific classes and interfaces.
> A deployer or system administrator performs the following tasks to install
> and configure a Java EE application or components:
> * Configures the Java EE application or components for the operational
> environment
> * Verifies that the contents of the EAR, JAR, and/or WAR files are well
> formed and comply with the Java EE specification
> * Deploys (installs) the Java EE application or components into the Java
> EE server

Now the "vision" is thus that whoever is deploying the application will
essentially "crack open" the .ear, tweak the deployment descriptors and
then seal it back up again (that is meaning of the "Configures the Java EE
application or components for the operational environment" step which comes
*before* deploying to the JavaEE server)

Of course where we hit issues is that we all view letting a human "crack
open", "tweak", and "seal up again" a .ear as error prone, plus the people
we are shipping the application to also view this as scary.

Now if I were the admin for such an app, I would use something like puppet
or chef, etc to automate the open-tweak-seal process... but the biggest
issue is tracablility.

If you have a .ear that is never the same as that shipped from the vendor
(or from the release process) how do you know that it was the one that QA

Instead of being able to do

sha1sum application.ear

you now have to open up the ear and do a diff of the contents against the
reference .ear and potentially resolve differences in files that are
permitted to have differences.

TL;DR the JavaEE spec vision is not something that you want

So then you decide that you want to release the app pre-configured for each
deployment environment and all the remaining configuration should be picked
up via JNDI or via files deployed to the classpath of the container (or
maybe system properties or environment variables)

In an ideal world you can do it all from JNDI or system properties (JNDI
being better as you do not pollute a global name space)

In the non-ideal world what you do is have your build system take on some
of the roles of application deployer.

You have a module that produces the generic .ear

And then you have modules that unpack-tweak-repack the .ear targetting each
app server/database

That is "the maven way" *but* it is not the way Maven wants you to work...
Maven wants you to only have one .ear that works for all... the app servers
are letting you down, and Maven is delivering pain for not following the
best practice way of working.

On 10 July 2013 08:33, John Patrick <> wrote:

> On 10 Jul 2013, at 06:05, Baptiste MATHUS <> wrote:
> > If those properties are specific to eclipselink, then I think it's ok and
> > simpler to just leave them in the persistence.xml even if they're
> actually
> > not used when EclipseLink isn't the provider. Then package only one ear.
> >
> > Cheers
> >
> >
> > 2013/7/9 John Patrick <>
> >
> >> I'm working on a project that uses JPA EclipseLink, everything started
> of
> >> fine with Jetty for developers development and WebLogic and Oracle
> proper
> >> ear deployments.
> >>
> >> EclipseLink has two values that need to be set in persistence.xml
> depending
> >> upon your Application Server and Database;
> >>
> >>
> >>
> >> This mean we have two profiles, Jetty and Release.
> >>
> >> Now we support WebSphere and DB2, so have gone to 5 profiles and the
> need
> >> to rebuild the ear 4 times which each profile.
> >>
> >> Profiles
> >> Jetty
> >> WLSOracle
> >> WLSDB2
> >> WASOracle
> >> WASDB2
> >>
> >> I feel I'm doing something wrong...
> >>
> >> Does someone have any suggestions on what to look at so i could
> potentially
> >> build it once and get all the 4 ears build in one command? I've thought
> >> about types or classifiers but unsure if that is just another hack...
> >>
> >> Thoughts? As we soon might also need to support MySQL and Glassfish so
> >> their is another 5 profiles and 5 more builds for a release.
> >>
> >> John
> >
> >
> >
> > --
> > Baptiste <Batmat> MATHUS -
> > Sauvez un arbre,
> > Mangez un castor !
> Mathus I think you miss understood my point. I need to build 4
> different ears currently as eclipselink auto detections fails about
> once a week and we can reproduce on demand.
> each ear has a different combination of values.
> ear 1 = WebLogic / Oracle
> ear 2 = WebLogic / DB2
> ear 3 = WebSphere / Oracle
> ear 4 = WebSphere / DB2
> I can't build one ear, say ear 1 as the value for the database setting
> would be wrong when DB2 is the backend. Also the value for the
> application server would be wrong when deployed to WebSphere.
> If eclipselink auto detect worked 100% I could create one ear but a
> few issues in production which we can't reproduce in test on demand
> mean we need to explicitly define application server and database
> server.
> From the off list replies it looks like others are having similar
> issues and doing similar things.
> cheers,
> John
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message