First of all, congratulations for having been accepted at Apache :-)
Is there already a plan regarding the future package name at Apache? I guess you won't be allowed to stick to com.ibatis but are supposed to use org.apache.ibatis instead...
Will you continue developing the 2.x line for the time being, based on com.ibatis? I doubt that it would be appropriate to switch packing names in a point release, without introducing major new features... maybe for iBATIS 3.0?
One reason why I wonder is because of Spring's iBATIS SQL Maps support. If you switch package names, we'll obviously have to adapt our integration - possibly keeping the current SQL Maps 2.0 support, but dropping SQL Maps 1.3 support. (Else we'd support 3 iBATIS versions in parallel...)
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point we know we'll be changing the package name structure to Apache. Depending on how fast we move to 3.0, we may or may not change the 2.0 package structure (i'm not sure how strict this is --what do applications written in languages without namespaces do?). If we do change 2.0, I'll be sure to include a compatibility JAR that proxies to the apache package (at least for the public interfaces, and whatever Spring needs).
3.0 will be developed from the ground up with the iBATIS team, and will use the apache packae name.
We'll always keep you in mind to ensure that 3.0 is easily integrated into Spring.
Cheers,
Clinton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your efforts, Clinton :-) It's a bit of a pity in terms of timing that the 2.0 branch is so recent... If you were just about to release 2.0 final, you could switch to Apache package names for the SqlMapClient API.
BTW, do you still see widespread usage of the SQL Maps 1.3 branch? I'm wondering when to remove the SQL Maps 1.3 support from Spring; we obviously shouldn't carry it on forever. We're still gonna keep it for a while, of course...
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Clinton, Brandon, everybody,
First of all, congratulations for having been accepted at Apache :-)
Is there already a plan regarding the future package name at Apache? I guess you won't be allowed to stick to com.ibatis but are supposed to use org.apache.ibatis instead...
Will you continue developing the 2.x line for the time being, based on com.ibatis? I doubt that it would be appropriate to switch packing names in a point release, without introducing major new features... maybe for iBATIS 3.0?
One reason why I wonder is because of Spring's iBATIS SQL Maps support. If you switch package names, we'll obviously have to adapt our integration - possibly keeping the current SQL Maps 2.0 support, but dropping SQL Maps 1.3 support. (Else we'd support 3 iBATIS versions in parallel...)
Juergen
Hi Juergen,
We'll be sure to keep you in the loop!
At this point we know we'll be changing the package name structure to Apache. Depending on how fast we move to 3.0, we may or may not change the 2.0 package structure (i'm not sure how strict this is --what do applications written in languages without namespaces do?). If we do change 2.0, I'll be sure to include a compatibility JAR that proxies to the apache package (at least for the public interfaces, and whatever Spring needs).
3.0 will be developed from the ground up with the iBATIS team, and will use the apache packae name.
We'll always keep you in mind to ensure that 3.0 is easily integrated into Spring.
Cheers,
Clinton
Thanks for your efforts, Clinton :-) It's a bit of a pity in terms of timing that the 2.0 branch is so recent... If you were just about to release 2.0 final, you could switch to Apache package names for the SqlMapClient API.
BTW, do you still see widespread usage of the SQL Maps 1.3 branch? I'm wondering when to remove the SQL Maps 1.3 support from Spring; we obviously shouldn't carry it on forever. We're still gonna keep it for a while, of course...
Juergen