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 Thu, 13 Oct 2011 02:48:03 GMT
Opened a JIRA https://issues.apache.org/jira/browse/GERONIMO-6188 for this,
and will evaluate this feature in the next release.

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

> So it sounds like, that if we are to do this, we have to maintain the
> additional
> deployment plan at the maintenance release (e.g. 3.1.21 =>
> geronimo-web_3.1.21.xml) and cannot maintain it at the minor release (e.g.
> 3.1.21 => geronimo-web_3.1.xml) for the following reasons:
>  1. We might change the schema (add elements) in a maintenance release.
>  2. App Developers may need to test between two widely-gapped maintenance
> releases (e.g. 3.0.0 and 3.0.55)
>
> And we will only read in one deployment plan, and will not allow
> configuration
> overlap from multiple deployment plan files. (App Developers will have to
> practice copying to the version suffix deployment plan, and merge changes
> from
> the default deployment plan.) We will look for the first validly named
> deployment plan, but only at the maintenance release level. Such that if
> the
> current release is 3.2.4, we will look for a deployment plan in the
> following
> order (the first one found will be chosen):
> 1. geronimo-web_3.2.4.xml
> 2. geronimo-web_3.2.3.xml
> 3. geronimo-web_3.2.2.xml
> 4. geronimo-web_3.2.1.xml
> 5. geronimo-web_3.2.0.xml
> 6. geronimo-web.xml
> 7. Else: Fail -> "No Deployment Plan"
>
> During an apps deployment, Geronimo should definitely print out what
> deployment
> plan it is using. E.g.: "Using deployment plan geronimo-web_3.2.4.xml." -
> or
> perhaps this is a message that prints out on higher verbosity, or only in
> the
> server log.
>
>
> If we have a greater acceptance from the developers, I don't see any reason
> not
> to put this feature in. I will help you write the documentation.
>
> Do we want to backport this to Geronimo 2.X?
>
> -RG
>
>
>
> On 10/08/2011 01:25 AM, Ivan wrote:
> >
> >
> > 2011/10/8 Russell E Glaue <rglaue@cait.org <mailto:rglaue@cait.org>>
> >
> >
> >
> >     On 10/06/2011 10:31 PM, Ivan wrote:
> >     >
> >     > 2011/10/7 Russell E Glaue <rglaue@cait.org <mailto:rglaue@cait.org
> >
> >     <mailto:rglaue@cait.org <mailto: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.
> >
> >     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 <rglaue@cait.org <mailto:
> rglaue@cait.org>
> >     <mailto:rglaue@cait.org <mailto:rglaue@cait.org>>
> >     >     <mailto:rglaue@cait.org <mailto:rglaue@cait.org>
> >     <mailto: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
> >
> >
> >     -RG
> >
> >
> >
> >
> > --
> > Ivan
>



-- 
Ivan

Mime
View raw message