On Thu, May 10, 2012 at 10:59 AM, Tim Quinn <tim.quinn_at_oracle.com> wrote:
> GlassFish supports a concept known as deployment plans. The original idea
> is that a developer could build a single, portable application and package
> it into an EAR and place the vendor-specific descriptors into a second JAR,
> the deployment plan JAR. When you deploy the app you specify the
> deployment plan along with the portable application. If GlassFish finds an
> overriding descriptor in the deployment plan, it uses that one. Otherwise
> it uses the descriptors in the portable EAR.
>
That is excellent and gets me partway there. Is that a JSR-88-specified
thing (the documentation you referred to indicates that it is; I'm not
familiar with JSR-88 yet)?
> Although originally intended to segregate portable from vendor-specific
> descriptors, I think you might be able to use the deployment plan for your
> purposes as well and override the standard descriptors as well.
>
Meaning...you think that Glassfish happens to behave this way, or is
intended to behave this way? :-)
> To map this to your use case, you could ship the EAR and perhaps also ship
> a deployment plan JAR with copies of your descriptors...or at least the
> ones you want your customers to revise. Your customers would need to
> unpack the deployment plan, make their modifications to the descriptors
> within, and then recreate the deployment plan JAR. Then they could deploy
> the original EAR with their edited deployment plan. This seems sort-of
> close to what you were describing.
>
It sure is. What I'd really like to see is this expanded even further, so
that the deployment plan might be programmatic as well. Maybe, for
example, I really DO want to store my deployment information in a database
or a file on disk or something. So wouldn't it be neat if I could pack up
my own Configurator class that could do whatever it wanted to come up with
the values that the Glassfish runtime needs? Then Glassfish could just ask
the deployment plan: I need a value for X, and if the deployment plan came
up with it, it would be used; otherwise the default behavior would happen.
I wonder: do these deployment plans persist? That is, if I use one to
deploy an .ear file, must I always re-reference it when I redeploy the .ear
file, or is it "sticky"--i.e. Glassfish stashes it away somewhere and
references it again implicitly if I don't supply one on the command line?
Anyway, now that you've pointed me in the general JSR-88 direction I'll
have a look over there to see if all these features are addressed in some
way. I was also under the impression that JSR-88 was deprecated or
otherwise on the way out? Maybe I'm thinking of the management stuff
instead; have to research that.
> To my knowledge there are no slick tools to help with this, although there
> could be and I'm just not aware of them. So as of right now there would be
> some manual steps. And because it involved unpacking and repacking the
> deployment plan maybe this is not much better than doing that to the
> original EAR.
>
No, that would be considerably less pain. The nested unzipping is the real
killer.
> The documentation discusses deployment plans far better than I just did.
> There's some treatment of deployment plans here:
>
>
> http://docs.oracle.com/cd/E26576_01/doc.312/e24929/deploying-applications.htm
>
Appreciate it.
Best,
Laird
--
http://about.me/lairdnelson