You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Clinton Begin <cl...@ibatis.com> on 2004/08/09 03:11:07 UTC
Incubation of iBATIS Data Mapper
iBATIS is a unique framework for mapping objects to database queries. Many agree that iBATIS is simpler and more flexible than object relational mapping tools, and is particular good with complex databases. The Java framework <http://www.ibatis.com> is freely distributed, ASF licensed, open source software that has grown significantly over the last two years. Recently a .NET version was started and is nearing a 1.0 release <http://sf.net/projects/ibatisnet>. The iBATIS team has expanded from a single developer to a team of six developers. The development team and the iBATIS community have indicated that we would like to apply to the Apache Software Foundation for incubation, to help encourage and ensure the growth of our community.
If the response to this suggestion is positive, we would like to draft a proposal on the Incubator Wiki, as other candidates have done.
-- Clinton Begin, on behalf of Team iBATIS.
Re: Incubation of iBATIS Data Mapper
Posted by Clinton Begin <cl...@ibatis.com>.
Hi Noel,
Thanks for your response.
For those who may not be familiar with iBATIS, it is a persistence tool.
More specifically, it is a Data Mapper (PoEAA, Fowler). iBATIS is not
an Object Relational Mapper, however many people find it does a better
job of isolating the object model from the data model than any ORM tool.
I sometimes refer to iBATIS as an SQL Mapper, because essentially,
that's what it does. It maps the interaction of the inputs and outputs
of an SQL statement.
Here's a simple example that automatically maps column aliases to the
object based on the JavaBean property names in the Address class:
<select id="getAddress" parameterClass="int"
resultClass="eg.Address">
select
ADR_ID as id,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
from ADDRESS
where ADR_ID = #id#
</select>
This statement can be executed (i.e. an Address can be retrieved) by
running this simple Java code:
Integer pk = new Integer(5);
Address address = (Address)sqlMap.queryForObject("getAddress", pk);
There is no complex JDBC or SQL embedded in the Java source. iBATIS has
a great deal of architecture behind it, including transaction
management, caching, resource management, lazy loading, and even
optional bytecode enhancement. Furthermore, it supports mappings for
more than just domain classes. iBATIS can map to primitives, Maps,
arrays, Collections and even XML (text or DOM). It does all of this
with a very short learning curve and a simple design.
I rarely compare iBATIS to any ORM tool such as OJB or Hibernate, as
they are simply too different. I will say though that iBATIS is much
more tolerant of complex database designs that do not easily map to an
object model. This makes iBATIS an ideal choice for enterprise
applications. Additionally, due to its simple API and short learning
curve, iBATIS is also an easy choice for small applications.
ORM tools still have some advantages when both the object model and data
model are entirely within the control of the application developer. I
typically refer to this as an "application database" (as opposed to an
enterprise database, legacy database or 3rd party database). An
application database is typically considered a part of the application,
and is rarely accessed by other code or systems. In these cases, ORM
tools can still save developers a lot of time from writing SQL.
Additionally, ORM tools by nature can more easily implement features
such as object identity, smarter caching, dirty checking and
disconnected sessions.
With regard to tools similar to iBATIS, I can only say that iBATIS seems
to be truly unique in this space. There is not a lot to compare it to.
Interestingly, one of the technologies with similarities to iBATIS is
inline SQL. Many languages support the concept of inline SQL (Forte,
Pro*C etc). Even Java has seen some level of inline SQL support through
SQLJ. One could think of iBATIS as "inline SQL for XML" (tongue in
cheek). iBATIS has many of the same benefits as inline SQL, but allows
for a more robust architecture to be built around it. It also makes for
much cleaner code than inline SQL typically does. iBATIS seems to have
inspired other projects in this space, most recently a tool called Mr.
Persister. This is a great sign that the concept has been accepted by
the community. It is exciting to see such innovation in a space where we
thought only ORM could live.
iBATIS has 2 years of production use under its belt and its user
community reaches into the thousands. There are already efforts
underway for GUI tools, IDE plugins and Ant plugins. iBATIS also has a
C# edition, which is almost ready for a 1.0 release. iBATIS will be one
of the first truly multi-language persistence solutions. Developers
will be able to leverage their iBATIS skills on both the J2EE and .Net
platforms.
iBATIS has always been free and open source. It has had a lot of
community involvement since day one. Half of our team has been using
the product since the original release and has been contributing to it
ever since.
My apologies for the extremely long post. I hope it answered at least
some questions. More information can be found at the website:
http://www.ibatis.com
JPetStore is the official example for iBATIS and should likely tag along
as part of the iBATIS code base.
Best regards,
Clinton Begin
Noel J. Bergman wrote:
> Clinton,
>
> I see that you have Ted Husted and Harish Krishnaswamy backing your
> Incubation, as well as other enthusiastic people. I see that our Jakarta
> Commons Mapper project(http://jakarta.apache.org/commons/sandbox/mapper/)
> has support for iBatis as well as other data mappers. And you might want to
> talk with our DB project and see what interest also comes from there. Are
> you familiar OJB (http://db.apache.org/ojb/)?
>
> We also had a proposal from Robert McIntosh for something called Chameleon.
> See:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=general@incubator.apache
> .org&msgId=1702588 for information on that proposal. Chameleon ran into a
> problem in that support hasn't emerged for it, but I am cc'ing Robert in
> case there are some emerging synergies.
>
> Would you compare and contrast iBatis with other similar technologies for
> people who aren't yet familiar with iBatis?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[OT] Re: Incubation of iBATIS Data Mapper
Posted by Brian McCallister <mc...@forthillcompany.com>.
Sorry for the double post, guess moderator let posting from my unsubbed
account through!
-Brian
On Aug 9, 2004, at 10:10 AM, Brian McCallister wrote:
> +1 for this incubation, either joining db or as its own TLP wearing my
> DB PMC hat =)
>
> On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
>
>> It's true that we are all database/data persistence technologies,
>> but, in my experience, there is much more to an Apache product than
>> technology. My own concern as to db.apache.org would be scope.
>>
>> * PMC Scope
>>
> <snip />
>
> There are actually more PMC members than that, the last several added
> from OJB aren't on the website list (I am one of those unlisted
> people, oops!), I realized over the weekend. Will fix it as soon as I
> get the site looking right under Maven 1.0.
>
> iBATIS seems to fit well into DB, but if they don't want that for
> personal reasons as a project, their call =) In terms of skewing the
> PMC -- skew away if need be, I am a firm believer in the "all active
> committers should be PMC members" goal =)
>
>> * Product scope
>>
> <snip />
>
> This, to me, is a good argument for TLP status. There has been much
> concern over Jakarta being HUGE and hard to oversee. For the record, I
> think that concern over size is less important than capturing the idea
> crossover that has happened in Jakarta, though. The growth of useful
> tools there has been huge, and I am firm believer it is to a large
> degree the close proximity of projects which fostered this (virtual
> PARC type atmosphere).
>
>>
>> * Community scope
>>
> <snip />
>
> All of the current DB projects (other than those in incubator) started
> in Jakarta (go momma Jakarta!) or spent some time there. Crossover in
> terms of projects being used by committers may not be there, but
> crossover in the problem domain is, I think. That is a stronger
> argument for me.
>
>> Given these concerns, we thought it might be best to start the
>> discussion here, and get some feedback from the Incubator community,
>> before making a proposal.
>>
>> Of course, at the end of the day, I believe we care more about being
>> a member of House Apache than in which room we hang our hat :)
>
> I cannot speak for the whole DB PMC, but I am pretty confident that
> the project would be quite happy to provide a hat peg and help as
> needed =) I'd love to see iBATIS join the DB project, and this seems
> the natural home for it, but if they really want a TLP, I certainly
> won't stand in the way (and would still be +1).
>
> -Brian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation of iBATIS Data Mapper
Posted by Brian McCallister <br...@apache.org>.
+1 for this incubation, either joining db or as its own TLP wearing my
DB PMC hat =)
On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
> It's true that we are all database/data persistence technologies, but,
> in my experience, there is much more to an Apache product than
> technology. My own concern as to db.apache.org would be scope.
>
> * PMC Scope
>
<snip />
There are actually more PMC members than that, the last several added
from OJB aren't on the website list (I am one of those unlisted people,
oops!), I realized over the weekend. Will fix it as soon as I get the
site looking right under Maven 1.0.
iBATIS seems to fit well into DB, but if they don't want that for
personal reasons as a project, their call =) In terms of skewing the
PMC -- skew away if need be, I am a firm believer in the "all active
committers should be PMC members" goal =)
> * Product scope
>
<snip />
This, to me, is a good argument for TLP status. There has been much
concern over Jakarta being HUGE and hard to oversee. For the record, I
think that concern over size is less important than capturing the idea
crossover that has happened in Jakarta, though. The growth of useful
tools there has been huge, and I am firm believer it is to a large
degree the close proximity of projects which fostered this (virtual
PARC type atmosphere).
>
> * Community scope
>
<snip />
All of the current DB projects (other than those in incubator) started
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in
terms of projects being used by committers may not be there, but
crossover in the problem domain is, I think. That is a stronger
argument for me.
> Given these concerns, we thought it might be best to start the
> discussion here, and get some feedback from the Incubator community,
> before making a proposal.
>
> Of course, at the end of the day, I believe we care more about being a
> member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the
project would be quite happy to provide a hat peg and help as needed =)
I'd love to see iBATIS join the DB project, and this seems the natural
home for it, but if they really want a TLP, I certainly won't stand in
the way (and would still be +1).
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubation of iBATIS Data Mapper
Posted by Ted Husted <hu...@apache.org>.
Since there does seem to be interest in reviewing a proposal from iBATIS, I've setup a draft in the Incubator wiki.
http://wiki.apache.org/incubator/IbatisProposal
Based on the discussion here, I've included a section on whether to apply as TLP or subproject.
----
The iBATIS scope is as broad as products like Ant, Struts, and Maven. iBATIS is not just a Data Mapper framework, there is also a second Data Access Object framework, as well as an implementation of the infamous Petstore application. All implemented for both Java and .NET. Other subproject to create and maintain GUI tools and a common specification are planned, and PHP implementation may also follow.
The iBATIS team believes that all active committers should be PMC members. As iBATIS continues to grow, we expect the development/management team to also grow.
While the iBATIS products would fit under the broad scope of the db.apache.org project, the iBATIS developers would not be comfortable overseeing the db.apache.org products. We simply do not have enough experience with the other products to provide PMC-grade oversight.
Accordingly, our preference would be to apply as an Apache top-level project.
----
Of course, this draft is a living document, to be amended based on feedback from interested parties.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubation of iBATIS Data Mapper
Posted by Brandon Goodin <ma...@phase.ws>.
Greetings,
I would also have to agree that I feel more comfortable being a TLP rather
than part of the DB. I don't want to sound arrogant or presumptuous; I
simply think it would be organizationally cleaner. For example, we are
looking to add IBatis Productivity Tools to our repertoire of products. The
PTs look to provide services that span across the DAO and Data Mapper
products as well as into some areas of DAO generation and bean generation. I
see IBatis needing a garden to blossom in. Apache is fertile ground for the
planting and being an Apache TLP would give it that much more room to grow
adding to the continuing reputation of successful Apache products. I hope
that we can obtain the position of TLP in order to assure the continued
growth and success of IBatis and optimally serve the user base that we bring
along with us.
Thanks for your time,
Brandon Goodin
> -----Original Message-----
> From: Clinton Begin [mailto:clinton.begin@ibatis.com]
> Sent: Monday, August 09, 2004 5:15 PM
> To: general@incubator.apache.org
> Subject: Re: Incubation of iBATIS Data Mapper
>
>
> >> I don't believe anyone has a strong inclination one way or the other.
>
> I'll jump off the fence into a yard. :-)
>
> I'd prefer to see iBATIS as a TPL for the reasons Ted has laid out. I
> don't think joining the DB project would benefit either team.
>
> >> The key question would be whether members of the DB PMC will be
> >> comfortable overseeing code for products they don't use on
> >> platforms they don't use.
>
> Another key question is whether the iBATIS team is comfortable
> overseeing the code for OJB and Torque. I can only speak for myself. I
> don't have much interest in being on the PMC for OJB or Torque. iBATIS
> is a wide enough scope as is, and it will only grow faster.
>
> iBATIS already has many subprojects and implementations. This includes:
>
> - SQL Maps (to be called Data Mapper)
> - DAO (Data Access Objects)
> - JPetStore (example application)
>
> ** We have both Java and .Net implementations for each!
>
> I have a lot of respect for the DB project, but I think it will simply
> become too big with iBATIS in there too.
>
> Cheers,
> Clinton
>
>
> Ted Husted wrote:
> > On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
> >
> >> I cannot speak for the whole DB PMC, but I am pretty confident that
> >> the project would be quite happy to provide a hat peg and help as
> >> needed =) I'd love to see iBATIS join the DB project, and this
> >> seems the natural home for it, but if they really want a TLP, I
> >> certainly won't stand in the way (and would still be +1).
> >
> >
> > I don't believe anyone has a strong inclination one way or the other.
> And if it had just been a matter of iBATIS for Java, I'd agree it would be
> no-brainer.
> >
> > The key question would be whether members of the DB PMC will be
> comfortable overseeing code for products they don't use on platforms they
> don't use. :)
> >
> > But if adding six members to the DB PMC is not an issue, and overseeing
> a DB product with non-Java implementations is not an issue, then I'm sure
> we'd be just as happy to apply through DB. The team is not jealous of
> other products. Depending on the application and the team, I know we all
> recognize that another product can be a better choice for someone.
> >
> > -Ted.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation of iBATIS Data Mapper
Posted by Clinton Begin <cl...@ibatis.com>.
>> I don't believe anyone has a strong inclination one way or the other.
I'll jump off the fence into a yard. :-)
I'd prefer to see iBATIS as a TPL for the reasons Ted has laid out. I
don't think joining the DB project would benefit either team.
>> The key question would be whether members of the DB PMC will be
>> comfortable overseeing code for products they don't use on
>> platforms they don't use.
Another key question is whether the iBATIS team is comfortable
overseeing the code for OJB and Torque. I can only speak for myself. I
don't have much interest in being on the PMC for OJB or Torque. iBATIS
is a wide enough scope as is, and it will only grow faster.
iBATIS already has many subprojects and implementations. This includes:
- SQL Maps (to be called Data Mapper)
- DAO (Data Access Objects)
- JPetStore (example application)
** We have both Java and .Net implementations for each!
I have a lot of respect for the DB project, but I think it will simply
become too big with iBATIS in there too.
Cheers,
Clinton
Ted Husted wrote:
> On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
>
>> I cannot speak for the whole DB PMC, but I am pretty confident that
>> the project would be quite happy to provide a hat peg and help as
>> needed =) I'd love to see iBATIS join the DB project, and this
>> seems the natural home for it, but if they really want a TLP, I
>> certainly won't stand in the way (and would still be +1).
>
>
> I don't believe anyone has a strong inclination one way or the other. And if it had just been a matter of iBATIS for Java, I'd agree it would be no-brainer.
>
> The key question would be whether members of the DB PMC will be comfortable overseeing code for products they don't use on platforms they don't use. :)
>
> But if adding six members to the DB PMC is not an issue, and overseeing a DB product with non-Java implementations is not an issue, then I'm sure we'd be just as happy to apply through DB. The team is not jealous of other products. Depending on the application and the team, I know we all recognize that another product can be a better choice for someone.
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation of iBATIS Data Mapper
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 9 Aug 2004, Ted Husted wrote:
> if [...] overseeing a DB product with non-Java implementations is not an
> issue
There is nothing Java specific about the Apache DB charter, indeed the DB
proposal specicially calls out a language-agnostic approach.
<http://db.apache.org/pmc/initial-proposal.txt> (Although all current
Apache DB projects happen to be Java based.)
> if adding six members to the DB PMC is not an issue
That the PMC is comprised of active committers on all sub-projects is the
convention within the DB project.
- R.
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation of iBATIS Data Mapper
Posted by Ted Husted <hu...@apache.org>.
On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
>
>�I cannot speak for the whole DB PMC, but I am pretty confident that
>�the project would be quite happy to provide a hat peg and help as
>�needed =) I'd love to see iBATIS join the DB project, and this
>�seems the natural home for it, but if they really want a TLP, I
>�certainly won't stand in the way (and would still be +1).
I don't believe anyone has a strong inclination one way or the other. And if it had just been a matter of iBATIS for Java, I'd agree it would be no-brainer.
The key question would be whether members of the DB PMC will be comfortable overseeing code for products they don't use on platforms they don't use. :)
But if adding six members to the DB PMC is not an issue, and overseeing a DB product with non-Java implementations is not an issue, then I'm sure we'd be just as happy to apply through DB. The team is not jealous of other products. Depending on the application and the team, I know we all recognize that another product can be a better choice for someone.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation of iBATIS Data Mapper
Posted by Brian McCallister <mc...@forthillcompany.com>.
+1 for this incubation, either joining db or as its own TLP wearing my
DB PMC hat =)
On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
> It's true that we are all database/data persistence technologies, but,
> in my experience, there is much more to an Apache product than
> technology. My own concern as to db.apache.org would be scope.
>
> * PMC Scope
>
<snip />
There are actually more PMC members than that, the last several added
from OJB aren't on the website list (I am one of those unlisted people,
oops!), I realized over the weekend. Will fix it as soon as I get the
site looking right under Maven 1.0.
iBATIS seems to fit well into DB, but if they don't want that for
personal reasons as a project, their call =) In terms of skewing the
PMC -- skew away if need be, I am a firm believer in the "all active
committers should be PMC members" goal =)
> * Product scope
>
<snip />
This, to me, is a good argument for TLP status. There has been much
concern over Jakarta being HUGE and hard to oversee. For the record, I
think that concern over size is less important than capturing the idea
crossover that has happened in Jakarta, though. The growth of useful
tools there has been huge, and I am firm believer it is to a large
degree the close proximity of projects which fostered this (virtual
PARC type atmosphere).
>
> * Community scope
>
<snip />
All of the current DB projects (other than those in incubator) started
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in
terms of projects being used by committers may not be there, but
crossover in the problem domain is, I think. That is a stronger
argument for me.
> Given these concerns, we thought it might be best to start the
> discussion here, and get some feedback from the Incubator community,
> before making a proposal.
>
> Of course, at the end of the day, I believe we care more about being a
> member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the
project would be quite happy to provide a hat peg and help as needed =)
I'd love to see iBATIS join the DB project, and this seems the natural
home for it, but if they really want a TLP, I certainly won't stand in
the way (and would still be +1).
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubation of iBATIS Data Mapper
Posted by Ted Husted <hu...@apache.org>.
On Mon, 09 Aug 2004 00:15:22 -0400, Noel J. Bergman wrote:
>�And you might want to talk with our DB project and see what interest also comes from there.
It's true that we are all database/data persistence technologies, but, in my experience, there is much more to an Apache product than technology. My own concern as to db.apache.org would be scope.
* PMC Scope
We have six members of Team iBATIS, working on either the Java or .NET version, or both. Our initial expectation would be that all six would become the iBATIS PMC. As it stands, there are currently five members of the DB PMC overseeing four products, with over thirty committers. So, we would either have to skew the PMC:Committer ratio or amend our expectations. :)
* Product scope
We have two iBATIS.NET implementations now, Java and .NET, and some of us considering a PHP implementation as well. We also plan to found a specification subproject to define the iBATIS baseline for each implementation. With three subprojects, and a possible fourth, it seems that the iBATIS scope is broad enough to support a top-level project.
* Community scope
The iBATIS Java community does have a lot of crossover with the Jakarta community. The implementation uses Jakarta products, and many iBATIS developers use Jakarta products in their applications too. But, I do not sense a lot of crossover with the db.apache.org community. As it stands, we probably have more crossover with the Hibernate community. Many of us have used both Hibernate and iBATIS for different products at the same time. Though, OJB and Hibernate have much in common, so if we were more closely aligned, we could see more crossover between those Java communities. Of course, aside from Java, iBATIS also has a .NET community, and may develop a PHP community as well.
Given these concerns, we thought it might be best to start the discussion here, and get some feedback from the Incubator community, before making a proposal.
Of course, at the end of the day, I believe we care more about being a member of House Apache than in which room we hang our hat :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubation of iBATIS Data Mapper
Posted by "Noel J. Bergman" <no...@devtech.com>.
Clinton,
I see that you have Ted Husted and Harish Krishnaswamy backing your
Incubation, as well as other enthusiastic people. I see that our Jakarta
Commons Mapper project(http://jakarta.apache.org/commons/sandbox/mapper/)
has support for iBatis as well as other data mappers. And you might want to
talk with our DB project and see what interest also comes from there. Are
you familiar OJB (http://db.apache.org/ojb/)?
We also had a proposal from Robert McIntosh for something called Chameleon.
See:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=general@incubator.apache
.org&msgId=1702588 for information on that proposal. Chameleon ran into a
problem in that support hasn't emerged for it, but I am cc'ing Robert in
case there are some emerging synergies.
Would you compare and contrast iBatis with other similar technologies for
people who aren't yet familiar with iBatis?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org