Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F3407F83 for ; Sat, 8 Oct 2011 06:26:05 +0000 (UTC) Received: (qmail 80171 invoked by uid 500); 8 Oct 2011 06:26:05 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 80053 invoked by uid 500); 8 Oct 2011 06:26:02 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 80046 invoked by uid 99); 8 Oct 2011 06:26:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Oct 2011 06:26:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of xhhsld@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Oct 2011 06:25:56 +0000 Received: by wwe3 with SMTP id 3so6504270wwe.31 for ; Fri, 07 Oct 2011 23:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uw4CRuPT5wWztebwrCpsCPGb/9hmWW8VqMqr9owofr8=; b=mw6JusSi+FtRo6Reiba3lMySQd4AKSapXRp6NXT8AJ30WDP+eYYPxMv3uxjk9sLgzO k0c2XI7EcR8bfGPLxmt18QIsr0nKGcgLT6T7ikPtYqzT/1Cdl/0rCNgU136vz+AZXuSN JM6PcVnTP/QFP1LTx44P5kZ7yfDiVZj38FZtE= MIME-Version: 1.0 Received: by 10.216.230.142 with SMTP id j14mr3432048weq.50.1318055135243; Fri, 07 Oct 2011 23:25:35 -0700 (PDT) Received: by 10.216.24.196 with HTTP; Fri, 7 Oct 2011 23:25:35 -0700 (PDT) In-Reply-To: <4E8F5166.30905@cait.org> References: <4E8A0A2F.2020404@cait.org> <4E8DD71B.5040803@cait.org> <4E8F5166.30905@cait.org> Date: Sat, 8 Oct 2011 14:25:35 +0800 Message-ID: Subject: Re: Use version suffix for deployment plan file names From: Ivan To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=0016e64805e6216e0704aec3a03f --0016e64805e6216e0704aec3a03f Content-Type: text/plain; charset=ISO-8859-1 2011/10/8 Russell E Glaue > > > On 10/06/2011 10:31 PM, Ivan wrote: > > > > 2011/10/7 Russell E Glaue > > > > > 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. > > Yes, I understand that it is optional. Sorry I was not clear. I was meaning > if > the developer wants to use the optional geronimo-web_3.0.0.xml file, do > they > have to rename it to geronimo-web_3.0.1.xml when they upgrade G3 from 3.0.0 > to > 3.0.1? And you answered that below, in the next block, which is we could > read > them all in. > > Which one has precedence? geronimo-web.xml or geronimo-web_3.0.1.xml > So I mean, if some feature is declared in both, but configured differently > among > both, which one is the final accepted configuration? I would assume that > the > version-suffix deployment plan holds the final configuration - is this your > suggestion? > > > > > > 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 ? > > We could search for all files matching the name /geronimo-web.*\.xml/, sort > them, and read the content in accordingly, overlaying the structure on top > of > each other as we ascend from geronimo-web.xml to geronimo-web_X.X.X.xml. > Firstly, if there are multiple files in the directory, it looks to me that only one will be used, as merging multiple files may introduce some odd issues. For the precedence order, my rough idea is : a. strict version matches b. backward searching all the files belong to the same major and minor version. If the running server is 3.0.21, the deployer could search 3.0.20 -> 3.0.0 c. default file, e.g. geronimo-web.xml > > > > > > > > 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. > > If a user wants to deploy in both Geronimo versions, this will certainly > require > them to be pragmatic about it. But I think it is a good idea. A developer > can > maintain a web application for an older version, while at the same time > testing > it with a newer version using the suffix-versioned deployment plan. I know, > in > real life, our developers with my employer would benefit every time I > upgrade > versions and the schema changes. We have ran into hiccups in this migration > process, which your suggestion would help alleviate. > > But my previous question: > Do we add schema for new features in maintenance releases? > Say between G3.0.0 and G3.0.21? > Or do we restrict adding schema for new features to minor releases? > Say between G3.0.0 and G3.1.0? > I think that it depends on, and so far I did not see there is a related rule in the community. Please figure it out if I missed it :-) Mostly, schema files will not change usually, and we even do not update the schema versions if we only add the new elements (this is actually what we always do), which will not break the compatibility, those old files could be validated successfully with the new schema. The recent big changes in the schema is incoming Geronimo 3.0 beta. due to the OSGi integration, and it only add new elements. > > I ask because I was considering it would be less confusing and more easily > manageable if the version-suffix deployment plans we maintained at the > minor > version, rather than the maintenance version - this is as long as we are > restricting schema changes to minor releases - we probably would not want > to do > this as I suggest if we allow schema changes in maintenance releases. > > > Yes, any new feature should not bring confusion to the users, or it is not a good feature :-) In my expectation, the users only need to add a new version-suffix deployment plan files id they have to take advantage of those new features, and usually, they just need to leave the files there. e.g. If the application has to support both geronimo-2.1/2.2/3.0, and a new file is required for 3.0, he could just create a default file geronimo-web.xml for 2.1 and 2.2, and one new file geronimo-web-3.0.0.xml for 3.0. In the future, if a new feature is imported in 3.0.12, they could just create a file named geronimo-web-3.0.12 there. > > > > > > > > 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 > > > >> > > > > > > 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 > > > -RG > > -- Ivan --0016e64805e6216e0704aec3a03f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/10/8 Russell E Glaue <rglaue@cait.org>


On 10/06/2011 10:31 PM, Ivan wrote:
>
> 2011/10/7 Russell E Glaue <rglau= e@cait.org <mailto:rglaue@cait.or= g>>
>
> =A0 =A0 To make this clear, and allow me to ask a question, let's = look at an example
> =A0 =A0 case study, and tell me if this is how it will happen.
>
> =A0 =A0 A Geronimo User is running G2.2 and want to deploy a G3.0 serv= er side-by-side.
> =A0 =A0 User has a web application with the deployment plan "WEB-= INF/geronimo-web.xml"
> =A0 =A0 To be able to deploy to both servers, you are suggesting the U= ser needs a second
> =A0 =A0 deployment plan "WEB-INF/geronimo-web_3.0.0.xml". > =A0 =A0 After which, during the User's testing of G3.0.0, G3.0.1 i= s released and the
> =A0 =A0 User upgrades to G3.0.1.
>
>
> =A0 =A0 I did not mean that the users have to provide an extra file fo= r 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 t= here 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.

Yes, I understand that it is optional. Sorry I was not clear. I was m= eaning if
the developer wants to use the optional geronimo-web_3.0.0.xml file, do the= y
have to rename it to geronimo-web_3.0.1.xml when they upgrade G3 from 3.0.0= to
3.0.1? And you answered that below, in the next block, which is we could re= ad
them all in.

Which one has precedence? geronimo-web.xml or geronimo-web_3.0.1.xml
So I mean, if some feature is declared in both, but configured differently = among
both, which one is the final accepted configuration? I would assume that th= e
version-suffix deployment plan holds the final configuration - is this your=
suggestion?
=A0

>
> =A0 =A0 Are you saying the User needs to either rename "WEB-INF/g= eronimo-web_3.0.0.xml"
> =A0 =A0 to "WEB-INF/geronimo-web_3.0.1.xml", or create a new= deployment plan as
> =A0 =A0 "WEB-INF/geronimo-web_3.0.1.xml"?
>
>
> =A0 =A0 That sounds fine to me for small case scenarios like this.
>
>
> =A0 =A0 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 ?

We could search for all files matching the name /geronimo-web.*\.xml/= , sort
them, and read the content in accordingly, overlaying the structure on top = of
each other as we ascend from geronimo-web.xml to geronimo-web_X.X.X.xml.

=A0 =A0 Firstly, if there are multiple files in the = directory, it looks to me that only one will be used, as merging multiple f= iles may introduce some odd issues.
=A0 =A0 For the precedence order, my rough idea is :
=A0=A0=A0 a. strict= version matches
=A0=A0=A0 b. backward searching all the files belong to= the same major and minor version. If the running server is 3.0.21, the dep= loyer could search 3.0.20 -> 3.0.0
=A0=A0=A0 c. default file, e.g. geronimo-web.xml


>
>
> =A0 =A0 Can I ask just for the sake of asking, assuming we are not rem= oving schema
> =A0 =A0 elements of the deployment plan between maintenance revisions,= is it sufficient
> =A0 =A0 to recognize the deployment plan by minor revision instead of = by maintenance
> =A0 =A0 revision?
>
>
> =A0 =A0 We usually do NOT remove the unused elements in the schema fil= es, 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.

If a user wants to deploy in both Geronimo versions, this will certai= nly require
them to be pragmatic about it. But I think it is a good idea. A developer c= an
maintain a web application for an older version, while at the same time tes= ting
it with a newer version using the suffix-versioned deployment plan. I know,= in
real life, our developers with my employer would benefit every time I upgra= de
versions and the schema changes. We have ran into hiccups in this migration=
process, which your suggestion would help alleviate.

But my previous question:
Do we add schema for new features in maintenance releases?
=A0Say between G3.0.0 and G3.0.21?
Or do we restrict adding schema for new features to minor releases?
=A0Say between G3.0.0 and G3.1.0?

=A0 =A0 I think = that it depends on, and so far I did not see there is a related rule in the= community. Please figure it out if I missed it :-)
=A0=A0=A0 Mostly, sc= hema files will not change usually, and we even do not update the schema ve= rsions if we only add the new elements (this is actually what we always do)= , which will not break the compatibility, those old files could be validate= d successfully with the new schema.
=A0=A0=A0 The recent big changes in the schema is incoming Geronimo 3.0 bet= a. due to the OSGi integration, and it only add new elements.
=A0

I ask because I was considering it would be less confusing and more easily<= br> manageable if the version-suffix deployment plans we maintained at the mino= r
version, rather than the maintenance version - this is as long as we are restricting schema changes to minor releases - we probably would not want t= o do
this as I suggest if we allow schema changes in maintenance releases.


=A0=A0=A0 Yes, any new feature should not bring= confusion to the users, or it is not a good feature :-) In my expectation,= the users only need to add a new version-suffix deployment plan files id t= hey have to take advantage of those new features, and usually, they just ne= ed to leave the files there. e.g. If the application has to support both ge= ronimo-2.1/2.2/3.0, and a new file is required for 3.0, he could just creat= e a default file geronimo-web.xml for 2.1 and 2.2, and one new file geronim= o-web-3.0.0.xml for 3.0. In the future, if a new feature is imported in 3.0= .12, they could just create a file named geronimo-web-3.0.12 there.
=A0 =A0=A0
>
>
>
> =A0 =A0 So instead of "WEB-INF/geronimo-web_3.0.0.xml" and > =A0 =A0 "WEB-INF/geronimo-web_3.0.1.xml", the deployment pla= n file
> =A0 =A0 "WEB-INF/geronimo-web_3.0.xml" would suffice and cov= er both cases.
>
> =A0 =A0 -RG
>
>
> =A0 =A0 On 10/05/2011 07:59 PM, Ivan wrote:
> =A0 =A0 > I think that the number should be consistent with the run= ning Geronimo
> =A0 =A0 version,
> =A0 =A0 > and it looks to me this change is kept in the all future = versions
> =A0 =A0 >
> =A0 =A0 > 2011/10/4 Russell E Glaue <rglaue@cait.org <mailto:r= glaue@cait.org>
> =A0 =A0 <mailto:rglaue@cai= t.org <mailto:rglaue@cait.org= >>>
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 This would be a good option to support cross vers= ion compatibility.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Would the suffix remain the same for minor releas= es, or would we
> =A0 =A0 increment the
> =A0 =A0 > =A0 =A0 version number in the suffix (i.e. geronimo-web_3= .0.1.xml)?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 In what future version would this feature be depr= ecated? Or would we
> =A0 =A0 support
> =A0 =A0 > =A0 =A0 this methodology in all future versions?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 -RG
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 On 10/01/2011 02:43 AM, Ivan wrote:
> =A0 =A0 > =A0 =A0 > Hi, although we are trying to make the deplo= yment plan compatible among
> =A0 =A0 > =A0 =A0 > different versions,there are still differenc= es. e.g. some OSGi
> =A0 =A0 metadata are
> =A0 =A0 > =A0 =A0 > imported in the latest 3.0 release. So, if t= he users would hope to
> =A0 =A0 use the
> =A0 =A0 > =A0 =A0 same
> =A0 =A0 > =A0 =A0 > application package for different versions, = there may be an issue. I am
> =A0 =A0 > =A0 =A0 thinking
> =A0 =A0 > =A0 =A0 > that we could use version as suffix for the = deployment plans. For
> =A0 =A0 the web
> =A0 =A0 > =A0 =A0 > application, Geronimo will first try to find= a
> =A0 =A0 geronimo-web_3.0.0.xml in the
> =A0 =A0 > =A0 =A0 > WEB-INF directory, if not it will uses geron= imo-web.xml file. With this,
> =A0 =A0 > =A0 =A0 it may
> =A0 =A0 > =A0 =A0 > get the life easier.
> =A0 =A0 > =A0 =A0 > Thoughts ?
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > --
> =A0 =A0 > =A0 =A0 > Ivan
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > --
> =A0 =A0 > Ivan
>
>
>
>
> --
> Ivan


-RG




--
Ivan
--0016e64805e6216e0704aec3a03f--