maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Maven and JPA/EclipseLink Configuration...
Date Wed, 10 Jul 2013 14:52:11 GMT
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.

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 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.
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.



>
> 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 <rwheeler@artifact-software.com 
> <mailto:rwheeler@artifact-software.com>> 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: http://docs.oracle.com/javaee/6/tutorial/doc/bnaca.html*
>         *
>
>         *
>         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 <nhoj.patrick@gmail.com
>         <mailto:nhoj.patrick@gmail.com>> wrote:
>
>             On 10 Jul 2013, at 06:05, Baptiste MATHUS
>             <bmathus@batmat.net <mailto:bmathus@batmat.net>> 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 <nhoj.patrick@gmail.com
>                 <mailto:nhoj.patrick@gmail.com>>
>
>                     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;
>                     eclipselink.target-server
>                     eclipselink.target-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 - http://batmat.net
>                 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: users-unsubscribe@maven.apache.org
>             <mailto:users-unsubscribe@maven.apache.org>
>             For additional commands, e-mail:
>             users-help@maven.apache.org
>             <mailto:users-help@maven.apache.org>
>
>
>
>
>     -- 
>     Ron Wheeler
>     President
>     Artifact Software Inc
>     email: rwheeler@artifact-software.com
>     <mailto:rwheeler@artifact-software.com>
>     skype: ronaldmwheeler
>     phone: 866-970-2435, ext 102
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>     <mailto:users-unsubscribe@maven.apache.org>
>     For additional commands, e-mail: users-help@maven.apache.org
>     <mailto:users-help@maven.apache.org>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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