geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Use version suffix for deployment plan file names
Date Fri, 07 Oct 2011 03:31:02 GMT
2011/10/7 Russell E Glaue <rglaue@cait.org>

> To make this clear, and allow me to ask a question, let's look at an
> example
> case study, and tell me if this is how it will happen.
>
> A Geronimo User is running G2.2 and want to deploy a G3.0 server
> side-by-side.
> User has a web application with the deployment plan
> "WEB-INF/geronimo-web.xml"
> To be able to deploy to both servers, you are suggesting the User needs a
> second
> deployment plan "WEB-INF/geronimo-web_3.0.0.xml".
> After which, during the User's testing of G3.0.0, G3.0.1 is released and
> the
> User upgrades to G3.0.1.
>

    I did not mean that the users have to provide an extra file for 3.0.0
server. It is only required when some incompatible features are used. e.g.
import-package. For the server deployer, it will first check whether there
is a specific plan file for the current version, say geronimo-web_3.0.1.xml,
if it exists, use that file, or it will check the geronimo-web.xml file.

 Are you saying the User needs to either rename
> "WEB-INF/geronimo-web_3.0.0.xml"
> to "WEB-INF/geronimo-web_3.0.1.xml", or create a new deployment plan as
> "WEB-INF/geronimo-web_3.0.1.xml"?
>

> That sounds fine to me for small case scenarios like this.
>

    For the minor version, maybe we could make the algorithm more elegant,
the deployer will also check the file for 3.0.0 exists if current version is
3.0.1 ?

>
> Can I ask just for the sake of asking, assuming we are not removing schema
> elements of the deployment plan between maintenance revisions, is it
> sufficient
> to recognize the deployment plan by minor revision instead of by
> maintenance
> revision?
>

    We usually do NOT remove the unused elements in the schema files, and
with this, it is possible to keep forward-compatibility, which means those
old deployment plan files could still be used without no change in the new
server, and deployer will print some warning message to notify the users
those unused elements are deprecated. The problem here is that, how to make
the back-compatibility, and how to make the deployment plan with new added
elements could be used in a previous server.


>
> So instead of "WEB-INF/geronimo-web_3.0.0.xml" and
> "WEB-INF/geronimo-web_3.0.1.xml", the deployment plan file
> "WEB-INF/geronimo-web_3.0.xml" would suffice and cover both cases.
>
> -RG
>
>
> On 10/05/2011 07:59 PM, Ivan wrote:
> > I think that the number should be consistent with the running Geronimo
> version,
> > and it looks to me this change is kept in the all future versions
> >
> > 2011/10/4 Russell E Glaue <rglaue@cait.org <mailto:rglaue@cait.org>>
> >
> >     This would be a good option to support cross version compatibility.
> >
> >     Would the suffix remain the same for minor releases, or would we
> increment the
> >     version number in the suffix (i.e. geronimo-web_3.0.1.xml)?
> >
> >     In what future version would this feature be deprecated? Or would we
> support
> >     this methodology in all future versions?
> >
> >     -RG
> >
> >
> >     On 10/01/2011 02:43 AM, Ivan wrote:
> >     > Hi, although we are trying to make the deployment plan compatible
> among
> >     > different versions,there are still differences. e.g. some OSGi
> metadata are
> >     > imported in the latest 3.0 release. So, if the users would hope to
> use the
> >     same
> >     > application package for different versions, there may be an issue.
> I am
> >     thinking
> >     > that we could use version as suffix for the deployment plans. For
> the web
> >     > application, Geronimo will first try to find a
> geronimo-web_3.0.0.xml in the
> >     > WEB-INF directory, if not it will uses geronimo-web.xml file. With
> this,
> >     it may
> >     > get the life easier.
> >     > Thoughts ?
> >     >
> >     > --
> >     > Ivan
> >
> >
> >
> >
> > --
> > Ivan
>



-- 
Ivan

Mime
View raw message