maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Maven and JPA/EclipseLink Configuration...
Date Wed, 10 Jul 2013 17:30:15 GMT
I agree with a lot of the JCP description of the deployer role.
I also think that they are oriented to a small portion of the deployment 
Most of the time the person doing deployments has a third party product 
from a vendor and does not have the source code and does not even have 
any documentation other than what the vendor provides.

I agree with the separation of church and state that they advocate for 
internally developed applications.
I have always recommended that developers who are doing both roles (in 
small and medium shops), try to remember which hat they are wearing when 
working at the border of development and deployment.
The developer should deliver something that can be deployed in the 
supported environment by someone who is an expert in the operating 
environment but not a programmer and certainly not an expert is the 
middleware on which the system is built.

I will stick with my recommendation that the best way to support 
multiple deployment configurations in a commercial product, is an 
interactive installer that, at deployment time,  can tweak or select 
from a set of configuration files included in the artifacts.
These artifacts should be developed by Maven.

Creating individual Maven artifacts for each deployment combination will 
result in a set that doubles (or more) each time an option is added.


On 10/07/2013 11:45 AM, Stephen Connolly wrote:
> On 10 July 2013 15:52, Ron Wheeler < 
> <>> wrote:
>     On 10/07/2013 10:06 AM, Stephen Connolly wrote:
>>     Well if it is an interactive installer then it can do the
>>     configuration for you...
>     It needs to be interactive in some way if you want to handle a
>     variety of environments.
>     ./configure
>     make
>     install
>     (you hope that you don't end up with something this complex!!!)
>     or  questions during msi or rpm installs.
>>     But with a JavaEE application you don't know:
>>     1. What application container they have
>>     2. What database they have
>>     3. Where the application container picks up deployed apps
>>     4. How the user wants the app deployed in the application container
>>     ...
>     These are all questions that can be asked and are somewhat limited
>     by the configurations that your application supports.
>     I would think that the answer to question 1 limits the possible
>     responses to 3 and 4.
>     The application designer  usually limits the supported
>     configurations in some way so that they do not have to create and
>     distribute a lot of configuration files if they are using Maven to
>     build the final war file that has to handle the whole range of
>     deployment environments.
> Well getting back to the OP, they were saying that they are expanding 
> the supported list of platforms... so it looks like their designer is 
> getting more fast and loose with QA (because QA will only be doing 
> touchstone testing on the entire matrix of combinations)
>     As a frequent deployer and a less frequent developer, I prefer an
>     installer that encapsulates the developers supported tweaking
>     rather than a complex process that requires me to manually modify
>     configuration files based on my understanding of the developers
>     documentation.
> I am not saying you're wrong... I am saying that the JavaEE spec does 
> not share your point of view...
> The ideal Maven way is one .ear that works for everyone without 
> modification. The JavaEE spec and the way application containers are 
> implemented makes that harder to achieve for some scopes (e.g. 
> persistence.xml)
>     I generally have very little idea about the internal architecture
>     since I might have to install 50 packages to get a server set up
>     and don't have the time to learn each one and read the code and
>     configuration file documentation to find the things to change.
> Take it up with the JCP ;-)
>     I want to get something that the programmer has tested and will
>     install on the supported configuration with as few places for me 
>     to make mistakes, as possible.
> Which is why I recommended having Maven do the repacking for them... 
> just using one module for each target platform...
> Note that this may mean that they have 20 or 30 repack modules... so 
> be it!!! Following the Maven way typically results in discovering pain 
> at things which are not best practice... the need to have NxM 
> repack-ear modules highlights the pain introduced by poor application 
> server spec design
>>     I can go on.
>>     The less Windows centric world has installers that basically are
>>     non-interactive, e.g. RPM, DEB, etc
>>     This type of installer typically would be installing both the
>>     application and container... thus the question is moot.
>>     An example of this is the various ways you can install Jenkins:
>>     1. Jenkins.war (as self-executing war file)
>>     2. Jenkins.war in your container of choice
>>     3. RPM
>>     4. DEB
>>     5. PKG
>>     6. Windows installer
>>     7. Mac installer
>>     All except the .WAR based distributions make assumptions about
>>     how to deploy the application.
>>     If you want to install Jenkins on RedHat, you grab the RPM and
>>     install that... but if you don't like the way that configures
>>     Jenkins, then you can grab your container of choice, grab the
>>     .war and deploy that in your container using your container's
>>     deployment toolchain.
>>     Installers are not the solution to this problem... in fact to my
>>     mind, other than windows, they are often an anti-pattern...
>>     Though with puppet/chef what you typically do is wrap up the
>>     application you want in an installer that depends on an installer
>>     you created for your container of choice and then drops the
>>     application into the correct directory... that simplifies your
>>     puppet/chef scripts as they just interact with the platform's
>>     package management infrastructure... but you are still back to
>>     the Ops team creating the installer not the dev team
>>     On 10 July 2013 14:39, Ron Wheeler
>>     <
>>     <>> wrote:
>>         Where does an installer fit in this vision?
>>         It seems to me, having installed thousands of programs as a
>>         Windows user and Linux system administrator, that a lot of
>>         the discussion about deployment issues seem to ignore the
>>         role of installers (rpm, msi, izPack, etc.).
>>         They are specifically designed to tweak packages during
>>         deployment.
>>         They can be set up very easily to be very smart about using
>>         input from the Application Deployer and Administrator or from
>>         the environment directly, to customize the installed application.
>>         Ron
>>         On 10/07/2013 4:23 AM, Stephen Connolly wrote:
>>             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
>>             *Source:
>>   *
>>             *
>>             *
>>             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
>>             tested?
>>             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

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

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