Re: [DISCUSS] GEP 2.1 support for v1.1
On Apr 18, 2008, at 6:27 PM, Tim McConnell wrote: Hi Shiva, yes I think the consensus is option #3, and the removal of the v1.1 plug-ins is on my pre-release tasklist. Thanks for the reminder Did we run this past our [EMAIL PROTECTED] list? --kevan
Re: [DISCUSS] GEP 2.1 support for v1.1
Hi Kevan, I have not, but shall do so today. Thanks for the reminder.. Kevan Miller wrote: On Apr 18, 2008, at 6:27 PM, Tim McConnell wrote: Hi Shiva, yes I think the consensus is option #3, and the removal of the v1.1 plug-ins is on my pre-release tasklist. Thanks for the reminder Did we run this past our [EMAIL PROTECTED] list? --kevan -- Thanks, Tim McConnell
Re: [DISCUSS] GEP 2.1 support for v1.1
Hi Shiva, yes I think the consensus is option #3, and the removal of the v1.1 plug-ins is on my pre-release tasklist. Thanks for the reminder Shiva Kumar H R wrote: So are we finally going in for #3? If yes, we must drop v1.1 plug-ins before we release GEP 2.1.0 as most of them may not be working as expected! On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell -- Thanks, Shiva -- Thanks, Tim McConnell
Re: [DISCUSS] GEP 2.1 support for v1.1
So are we finally going in for #3? If yes, we must drop v1.1 plug-ins before we release GEP 2.1.0 as most of them may not be working as expected! On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell -- Thanks, Shiva
Re: [DISCUSS] GEP 2.1 support for v1.1
+1 for number 3 Jay Tim McConnell wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ??
Re: [DISCUSS] GEP 2.1 support for v1.1
Shiva Kumar H R wrote: On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? I too am +1 for #3 - would allow us to focus entirely on fixing critical jiras release GEP 2.1 quicker. ditto Cheers! Hernan -- Thanks, Tim McConnell -- Thanks, Shiva
Re: [DISCUSS] GEP 2.1 support for v1.1
On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? I too am +1 for #3 - would allow us to focus entirely on fixing critical jiras release GEP 2.1 quicker. -- Thanks, Tim McConnell -- Thanks, Shiva
Re: [DISCUSS] GEP 2.1 support for v1.1
Should we ask on the user list too and see what users have to say? ++Vamsi On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell
[DISCUSS] GEP 2.1 support for v1.1
Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell
Re: [DISCUSS] GEP 2.1 support for v1.1
Hi Tim, Given that we already have a release that supports 1.1, I'd be inclined to go with #3 as well. It'd make it a little clunkier to go from 2.0 to 2.1(server), though, from what I understand. Correct me if I'm wrong, but the process for that would be to port your app to 2.0 server, and then upgrade to 2.1 GEP for porting to 2.1 server? Thanks, ~Jason Warner On Sat, Mar 29, 2008 at 2:19 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell -- ~Jason Warner
Re: [DISCUSS] GEP 2.1 support for v1.1
On Sat, Mar 29, 2008 at 7:19 AM, Tim McConnell [EMAIL PROTECTED] wrote: #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) s/althogether/temporarily which means release what we've got so far and add support for G 1.1 later on as a minor release. p.s. Supporting v1.1 in GEP seems like an excellent idea for GSoC, doesn't it? Thanks Tim. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
