NetBeans uses this approach for user data; the userdir. But folks on the
NB bleeding edge know that you cannot mix the userdir created with
yesterday's nightly build with bits from today's daily build safely...
So, I like this proposal for "very stable" (beta) or "final" bits...
The costs to make this "upgradability" work from daily build to daily
build could be very high. The costs to provide this on a promoted to
promoted basis will probably be almost as high.
It may also stifle some innovation or encourage poor designs...
Consider a developer who is extending domain.xml and wants to add a new
element to the dtd... We know that the element needs to be optional so
the upgrade story from release to release is smooth. But, sub-elements
of the new element are free to be "anything" (zero-or-one, zero-or-many,
required,...). This lets the developer express the true semantics of
the extension as closely as possible in the DTD of domain.xml....
Currently, if they "get it wrong", they are free to fix it and the cost
isn't very high, since they only need to be compatible with the last
release.
If the developer knew that they had to be able to read yesterday's data
with today's build, they may end up making all their new elements
optional. This means that the code for the extension will have to do
all the checking that could have been expressed in the DTD of
domain.xml. That doesn't sound like a good idea to me.
The testing burden for daily to daily or promoted to promoted
upgradability will not be trivial either.
vbk
kedar wrote:
> Folks,
>
> Need a user perspective in this case.
>
> When GlassFish is installed and set up using the setup.xml's,
> the domain (server) where your applications get deployed is
> created in install-dir/domains. This domain is named "domain1".
>
> Domain is what you own. Your applications, your configurations,
> customizations are all stored there. Does it then make more sense
> to store it in your home folder, rather than the folder where
> you install the bits?
>
> One benefit I see with storing your data in your home folder
> is protection against accidental deletion. When you upgrade
> GlassFish from build to build or from release to release, you of
> course don't want to recreate domain, redeploy apps etc. Every
> subsequent build should be able to smoothly run the applications
> that were deployed/run with previous builds.
>
> This is kinda similar to other softwares where your configuration
> (user data, if you will) is stored at one place and the bits
> are stored in some system folders (e.g. "Program Files" in case
> of Windows).
>
> Are there other benefits? Would this be something that we should
> attempt? This should help smoother upgrade experience, because every
> new build/release just "runs" your applications without any hassle.
>
> Are there any cons?
>
> Please discuss.
>
> Thanks,
> Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>