test

[Brandon Goodin]

test

JDBC 3 Support

[Brandon Goodin]

Hey guys,

I'm reposting this because i'm not sure it got out with all the email
hiccups over the last day. I'd really like to get some feedback on
this. It will help us to move forward with adding jdbc 3 support...

We need to start supporting some jdbc 3 functionality. I was thinking
we can use the  tag and add a compatibility attribute to it.
The default would be 2 but could be configured to support 3. Then when
we add support for savepoints, generated keys, etc... we can throw a
sensible exception when someone tries to use jdbc 3 functionality in a
jdbc 2 compatibility mode.

My question is, do we want the support to be explicit with the setting
tag? or do we want to use an autodetection means?



thoughts?

Brandon

Re: JDBC 3 Support

[Brandon Goodin]

okay... sounds good.

So, we can still have the  attribute that states compatibilit
with using 2 or 3 as values (eventually 4 as well). But, if you are
not explicit we will set it by using class.forName and finding out
whether a jdbc 3 specific class exists and setting the compliance on
our own. Does that sound good?

Brandon

On 6/11/05, Larry Meadors <[EMAIL PROTECTED]> wrote:
> I agree with Sven, we can check for the existence of
> classes/interfaces/methods that are new in each release to auto-detect
> the JDBC version if the settings did not provide a value.
> 
> Larry
> 
> On 6/11/05, Sven Boden <[EMAIL PROTECTED]> wrote:
> >
> > Very personal preference auto-detection, but tag can override if
> > required.
> >
> > Regards,
> > Sven
> >
> >
> > On Sat, 11 Jun 2005 00:05:41 -0600, you wrote:
> >
> > >Hey guys,
> > >
> > >I'm reposting this because i'm not sure it got out with all the email
> > >hiccups over the last day. I'd really like to get some feedback on
> > >this. It will help us to move forward with adding jdbc 3 support...
> > >
> > >We need to start supporting some jdbc 3 functionality. I was thinking
> > >we can use the  tag and add a compatibility attribute to it.
> > >The default would be 2 but could be configured to support 3. Then when
> > >we add support for savepoints, generated keys, etc... we can throw a
> > >sensible exception when someone tries to use jdbc 3 functionality in a
> > >jdbc 2 compatibility mode.
> > >
> > >My question is, do we want the support to be explicit with the setting
> > >tag? or do we want to use an autodetection means?
> > >
> > >
> > >
> > >thoughts?
> > >
> > >Brandon
> >
> >
>

Re: [jira] Commented: (IBATIS-131) Fix use of list[]-notation in propertyattributes of dynamic tags

[Brandon Goodin]

I'll check in to this and post my findings here. I am only partially
online right now (using my neighbor's wireless bandwidth... with
permission :p). But, I will post my findings and a solution. Then one
of you guys can commit it.

Brandon

On 8/4/05, Niels Beekman (JIRA)  wrote:
> [ 
> http://issues.apache.org/jira/browse/IBATIS-131?page=comments#action_12317664 
> ]
> 
> Niels Beekman commented on IBATIS-131:
> --
> 
> I also believe it is still broken, I checked the JUnit-tests but none of them 
> is using a property containing []-syntax. If you use my example or just 
> extend the JUnit-test you'll notice the failure. I adapted the statement 
> 'dynamicIterate' in DynamicAccount.xml which is called from IterateTest.java:
> 
>parameterClass="list"
> resultClass="testdomain.Account">
> select
>   ACC_ID  as id,
>   ACC_FIRST_NAME  as firstName,
>   ACC_LAST_NAME   as lastName,
>   ACC_EMAIL   as emailAddress
> from ACCOUNT
> WHERE ACC_ID IN
> 
> 
> #[]#
> 
> 
>   
> 
>   public void testIterateInConditional() throws SQLException {
> List params = Arrays.asList(new Integer[]{new Integer(1), new Integer(2), 
> new Integer(3)});
> List list = sqlMap.queryForList("dynamicIterateInConditional", params);
> assertEquals(1, list.size());
> assertAccount1((Account) list.get(0));
>   }
> 
> This query should produce Account1, instead it crashes.
> 
> > Fix use of list[]-notation in propertyattributes of dynamic tags
> > 
> >
> >  Key: IBATIS-131
> >  URL: http://issues.apache.org/jira/browse/IBATIS-131
> >  Project: iBatis for Java
> > Type: Bug
> >   Components: SQL Maps
> >  Environment: All are affected.
> > Reporter: Niels Beekman
> > Assignee: Brandon Goodin
> >  Fix For: 2.1.5
> 
> >
> > When using an iterate-tag to loop a list, one cannot point to the current 
> > element in attributes of inner tags, for example, the following fails:
> > 
> >   
> > $myList[].anotherProperty$
> >   
> > 
> > iBATIS tries to index the property myList with an empty string, but it 
> > should use the current element (the []-notation works fine within inner 
> > tags), when an index is supplied it works just fine...
> 
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>http://www.atlassian.com/software/jira
> 
>

Maven Build

[Brandon Goodin]

Hey Guys,

I setup a maven build for the java data mapper. It can function side by
side with the ant script. I figured this would make it easier for
generating the appropriate artifacts to place on ibiblio for all of our
avid maven using friends. I was going to polish up a couple things and
check it in to subversion. Does anyone have any objectons?

Brandon

Re: Patch submission

[Brandon Goodin]

Tying up connections in the PaginatedArrayList would not be a
desireable functionality to me. I would recommend you write a version
of PaginatedArrayList for your  own personal use. If you are handling
large resultsets I would recommend against the use of
PaginatedArrayList anyways. It is meant for small result scrolling.

Brandon

On 9/13/05, Corneliu Rudeanu <[EMAIL PROTECTED]> wrote:
> 
> 
> Hi!
> 
> I made a patch for SQLMapClient which allows reusal of ResultSet's
> while iterating through a paginated query list. How can I submit the
> patch?
> 
> A more detailed description: the current implementation is re-running
> the query when user asks for some page, skipping the results
> (resultSet.next()) until the requested page is read. This is a problem
> while iterating through large results, and in my opinion that is the
> exact purpose for having paginated queries. My patch keeps the
> ResultSet cached in the PaginatedList, and invokes next()'s when user
> asks for next page. When a page "from the past" (i.e. going to a page
> with lower index than current - 1) the query runs again, with a
> behaviour similar to current implementation. Note: the optimization
> with next+previous pages being cached was kept in my patch.
> 
> I have little experience with SVN. Please send some instructions on how
> to submit the patch in order to be evaluated.
> 
> Regards,
> Corneliu Rudeanu
> 
> 
> 
> 
> __
> Yahoo! for Good
> Donate to the Hurricane Katrina relief effort.
> http://store.yahoo.com/redcross-donate3/
> 
>

Online Javadocs

[Brandon Goodin]

Hey all,

We need to make the javadocs available for online viewing. Would
anyone object if i added a link to the documentation page and uploaded
the javadocs?

Brandon

Re: Security Extension?

[Brandon Goodin]

I am not a fan of Validator whatsoever. But, apart from that and I
think a rules engine would already fit that bill. A rules engine would
rest in your service layer. By the time your objects reach your DAO
layer the assumption should be made that they are valid. If your
validation issues can't be handled in your service layer then you
should think about taking up stored procedures. Personally, I would
not be on board with this kind of functionality in iBatis.

But, we have tossed around the idea of making iBatis 3.x configs more
pluggable. Maybe you can take up the initiative then as a plugin.

Brandon

On 9/20/05, Brice Ruth <[EMAIL PROTECTED]> wrote:
> Hi guys,
>  
>  I've been involved in various "secure application" efforts in the past
> couple months and one idea that surfaced is securing database interaction
> from the application that's accessing the database. So, basically preventing
> parameters from being passed into the database that are invalid or crafted
> in such a way as to expose vulnerabilities in the underlying database.
>  
>  Obviously SQL-injection is one such vulnerability, but this is easily
> managed by using parameters. What I'm proposing is a validation framework
> for iBATIS that works similarly to Struts Validator (and uses
> Commons-Validator, as Struts does). So, in addition to having a SqlMap file,
> you might have a validation file that could be configured by id or class
> name (much like Struts allows an action path or an ActionForm to be
> specified) - and the iBATIS infrastructure would run the incoming data
> through the necessary validations, via commons-validator, before attempting
> any database access.
>  
>  Obviously this is still a pretty rough idea, but it seemed like it had some
> potential. What say ye?
> 
> -- 
> Brice Ruth
> Software Engineer, Madison WI

Re: select statement without resultmap

[Brandon Goodin]

Because it is an either/or circumstance. As far as i know you can't
require one or the other in a DTD. Also, if i remember correctly larry
had done this some time ago and wound up finding that there was a
problem. Perhaps he can expound.

Brandon

On 1/4/06, Nathan Maves <[EMAIL PROTECTED]> wrote:
> Is there any reason that either (resultMap | resultClass) are not required
> by the dtd for a sqlmap file?
>
> Nathan
>
>
> On Jan 4, 2006, at 9:18 AM, Daan de Wit wrote:
>
>
>
> Hi,
>
>
>
> Today I found myself stuck with a very weird problem. A queryForList
> returned an empty list while executing exactly the same query in the SQL
> Query Analyzer returned one result. I thought that maybe the SQL Profiler
> would be more informative about the problem, but query and the parameter
> were both the same as I used in the Query Analayzer.
>
> It turned out that I forgot to set a resultmap for the select-statement.
> Wouldn't it be better to throw an exception if no resultmap or resultclass
> is found for a select? Or maybe the xml could be changed to something like
> this:
>
> 
>
> I realize that the names I chose for the attributes are not that good, but
> they are good enough to get the idea.
>
>
>
> Regards,
>
> Daan
>
>
>

Urgent and not so urgent info

[Brandon Goodin]

2 points of observation below:

- The documentation that we link to on the ibatis.apache.org website
is not current. Actually, it is quite old. I would fix this myself,
but, I'm not aware of the process of getting it where it needs to be
and whether we are still using sourceforge to distribute the
documentation.

- Bugs are still using the [EMAIL PROTECTED] Shouldn't
they be using the [EMAIL PROTECTED]

L8r dudes...
Brandon

Re: Urgent and not so urgent info

[Brandon Goodin]

The documentation exists in SVN as an Open Office document. For some
reason it has not been converted to PDF and posted.

http://svn.apache.org/repos/asf/ibatis/trunk/java/docs/iBATIS-SqlMaps-2.sxw

Brandon

On 2/7/06, VanderArk, Richard <[EMAIL PROTECTED]> wrote:
> Is there more up to date documentation?  Are you now working on that
> (since you have "great" authoring experience..).
>
> Ric
>
>
> -Original Message-
> From: Brandon Goodin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 07, 2006 7:40 AM
> To: dev@ibatis.apache.org
> Subject: Urgent and not so urgent info
>
> 2 points of observation below:
>
> - The documentation that we link to on the ibatis.apache.org website
> is not current. Actually, it is quite old. I would fix this myself,
> but, I'm not aware of the process of getting it where it needs to be
> and whether we are still using sourceforge to distribute the
> documentation.
>
> - Bugs are still using the [EMAIL PROTECTED] Shouldn't
> they be using the [EMAIL PROTECTED]
>
> L8r dudes...
> Brandon
>

Re: Urgent and not so urgent info

[Brandon Goodin]

I made changes to the SVN documentation a while back. I added docs for
new features that have been added. I thought we released the docs with
each release of the API. Anyway, just so ya know that there have been
updates made to the SVN docs.

Brandon

On 2/7/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
> Okay,
>
>  3) I've updated the email address in JIRA.
>
>  2) I've moved all of the Java downloads to Apache.
>
>  1) No, I have not written any more docs.  ;-)
>
>  Cheers,
>  Clinton
>
>
> On 2/7/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> >
> > 1) Documentation:  Yes it's old.  I'm not sure if the OO doc in SVN is any
> newer...I don't think I've updated it.  Maybe Richard will update it for us.
> >
> > 2) Hosting:  Yes, we should move all of our downloadables to Apache.  It's
> both easier to deploy, and easier to download.
> >
> > 3) JIRA:  I'll look into changing the address to use dev@
> >
> > Cheers,
> > Clinton
> >
> >
> >
> >
> > On 2/7/06, Nathan Maves <[EMAIL PROTECTED] > wrote:
> > > On this same note...
> > >
> > > When are we going to start hosting the binaries and documentation on
> > > apache and get off the dreadful SF site?
> > >
> > > Nathan
> > >
> > > On Feb 7, 2006, at 7:40 AM, Brandon Goodin wrote:
> > >
> > > > 2 points of observation below:
> > > >
> > > > - The documentation that we link to on the ibatis.apache.org website
> > > > is not current. Actually, it is quite old. I would fix this myself,
> > > > but, I'm not aware of the process of getting it where it needs to be
> > > > and whether we are still using sourceforge to distribute the
> > > > documentation.
> > > >
> > > > - Bugs are still using the [EMAIL PROTECTED] Shouldn't
> > > > they be using the [EMAIL PROTECTED]
> > > >
> > > > L8r dudes...
> > > > Brandon
> > >
> > >
> >
> >
>
>

Re: ignore case on type aliases?

[Brandon Goodin]

I like that idea VERY MUCH. Its one of those things that I always get
annoyed at but never think to change. :)

Brandon

On 2/7/06, Nathan Maves <[EMAIL PROTECTED]> wrote:
> I was thinking about updating the TypeHandlerFactory to ignore the
> case of a type alias.  Is anyone opposed to this idea.
>
> This way both "String" and "string" would map to java.lang.String.  I
> can not think of any reason why this would be a bad idea.
>
> Nathan
>

Re: IBM's use of iBatis for Java

[Brandon Goodin]

So do we get complimentary copies of the Lotus software?

;-)

Brandon

On 2/8/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
> Hi Rob,
>
> That class wraps a Reader with an InputStream, and it's used in 3 places
> within iBATIS to deal with legacy Java APIs.
>
> The authors are not committers and therefore don't have CLAs filed.  They
> are the authors of an input stream API that uses the included Apache
> Compatible (1.x style) license.  As per their license agreement, we've left
> their copyright notice in, which is also distributed with every copy of
> iBATIS.  We are compliant with their license, and their license is
> compatible with Apache.
>
>  There's nothing wrong with an Apache project including code that uses a
> compatible license.  Similarly, there's no problem with an Apache project
> referencing or including a 3rd party framework or tool that uses a
> compatible license.
>
> If it creates a problem for Lotus, I suggest they rewrite the class, file a
> CLA and then contribute it back to iBATIS.
>
> Cheers,
> Clinton
>
>
>
>  On 2/8/06, rob yates <[EMAIL PROTECTED]> wrote:
> > Thanks to all for your help with my previous questions.  I have looked
> > at the iBatis source code and have, hopefully, one final question.
> > There is a reference to nitric.com and a copyright notice for Merlin
> > Hughes, Michael Shoffner and Derek Hammer.  I don't see those people
> > listed on the committer list.  Does anyone know who they are and how
> > their code came to be in iBatis?
> >
> > Again Many Thanks,
> >
> > Rob
> >
>
>

Re: What about a LDAP dao engine ?

[Brandon Goodin]

I think it would be very interesting to have. We have discussed this
and it is an outside goal to possibly make ibatis map beyon SQL.

Brandon

On 2/11/06, Cimballi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to know if there is already an iBatis implementation for LDAP
> ? And if there is none, should it be interesting to have ?
>
> I've already used iBatis for database access, and now I'm working with
> LDAP directories and I thought I should be able to use the same
> logical architecture like for databases.
>
> What's your opinion ?
>
> Cimballi
>

Re: What about a LDAP dao engine ?

[Brandon Goodin]

"This has been done a couple of times."

Is someone using iBatis in conjunction with LDAP? I am aware of our
previous discussions. But, where is the implementation?

Brandon

On 2/12/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
> This has been done a couple of times.  It was discussed on this list a
> while back.
>
> Cheers,
> Clinton
>
> Cimballi wrote:
>
> >Great ! It's more motivating to work when you know other people may
> >enjoy it ! ;-)
> >
> >I hope language will not block me, my english is very poor ! Well, at
> >least I understand "computer" english, and I've got a big dictionnary
> >!
> >
> >So Larry, like you said in LDAP each attribute can have multiple
> >values. This is one of the differences between LDAP and SQL. If I
> >understand you well, you also propose a kind of automatic mapping
> >between the object (JAVA) and the entry (LDAP) based on the
> >type-objectclass of that object-entry. I don't understand well your
> >reference to SQL injection, but maybe this is because I don't still
> >have a look inside the sqlmap architecture.
> >
> >Now what I thought to do. The simplest way to start should to copy the
> >way sqlmap works and adapt it to LDAP. Of course there is some
> >difference but we will discuss them later, I don't think they should
> >need a new architecture.
> >About the about to use, I've mostly work with the ldapsdk from
> >netscape-sun-mozilla, but maybe it's should be better to use JNDI
> >here. About JNDI, do you think it should be interesting to have a
> >generic JNDI dao engine, or maybe we can start with JNDI-LDAP dao
> >engine, and look for more genericity later ?
> >About mapping between JAVA and LDAP : in LDAP most of the attributes
> >can be multi valued, but in real life, company's schemas usually
> >settled if an attribute will be mono or multi valued based on their
> >model, so maybe we can provide a parameter in the mapping which will
> >say if the engine should consider the attribute as mono or multi
> >valued.
> >About transactions, although there is no transaction in LDAP for the
> >moment, we should provide the same functionnely like in sqlmap so it
> >could be easily implemented later.
> >This is what I've got in mind for now.
> >
> >I'd like to know about exchange of docs and code inside iBatis
> >community. If I'd like to submit you docs or code, what's the best way
> >? Should I post them on this list ?
> >
> >If I use some words that don't match the ones you are used to use,
> >just tell me !
> >
> >First step is made, hope it was the most difficult one ;-)
> >
> >Cimballi
> >
> >
> >On 2/12/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I think that would be very interesting. :-)
> >>
> >>I did some work with LDAP recently, and think that having something
> >>like SQL Maps for LDAP queries would be really useful. One thing I had
> >>problems with was that the attributes are all name-value pairs - like
> >>doing everything with Maps. ;-)
> >>
> >>Semantically, I think it would fit - there is no concept of a mapped
> >>statement, but SQL injection is not really an issue, so escaping may
> >>be adequate. Query results come back in a similar way (name-value
> >>pairs), so that fits. It may actually be simpler because the names of
> >>the attributes are defined by the classes of the returned objects.
> >>
> >>Sounds cool!
> >>
> >>Larry
> >>
> >>
>

Re: removeFirstPrepend doesn't remove the first prepend?

[Brandon Goodin]

The removeFirstPrepend does not work in the way you are expecting. The
rFP works to remove the first prepend that is produced by tags nested
in the body of the tag using the rFP. Als, the  tag should
automatically remove the first prepend. So, in your case you should
remove the rFP from the isNotEmpty tags. It should then work in the
manner you expect. If it does not, then we may have an issue.

Brandon

On 2/17/06, Petr Kokorev <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
> I have a simple insert query like this (I am sure that at least one of
> the properties is not empty)
>
> 
>   INSERT INTO ITEMS_TABLE
>   (
>   
>  removeFirstPrepend="true">
>   PROPERTY_ONE
> 
>  removeFirstPrepend="true">
>   PROPERTY_TWO
> 
>   
>   ,
>   VALUE
>   )
>   VALUES
>   (
>   
>  removeFirstPrepend="true">
>   #propertyOne#
> 
>  removeFirstPrepend="true">
>   #propertyTwo#
> 
>   
>   ,
>   #value:NUMERIC#
>   )
> 
>
> The generated String for the prepared statement will be like this in the
> case of when both of the properties are not empty:
>
>   INSERT INTO ITEMS_TABLE ( , PROPERTY_ONE , PROPERTY_TWO , VALUE )
> VALUES ( , ? , ? , ? )
>
> So the 1st prepend is not being removed.
> I have done a workaround for it by specifying the prepend attribute for
> the  element:
>
>   
>
> Then it worked fine:
>
>   INSERT INTO ITEMS_TABLE ( PROPERTY_ONE , PROPERTY_TWO , VALUE ) VALUES
> ( ? , ? , ? )
>
> I just wonder, is it normal?
> Because I find the 'prepend="("' thing a bit ugly, and I would like to
> have it like in my example.
>
>
>
> Thanks in advance and respect
>
> Pye
>

Re: removeFirstPrepend doesn't remove the first prepend?

[Brandon Goodin]

Drop a bug in JIRA and attach a simple example that reproduces this
behavior and i'll take a look at it.

Brandon

On 2/20/06, Petr Kokorev <[EMAIL PROTECTED]> wrote:
> Brandon Goodin wrote:
>
> >The removeFirstPrepend does not work in the way you are expecting. The
> >rFP works to remove the first prepend that is produced by tags nested
> >in the body of the tag using the rFP. Als, the  tag should
> >automatically remove the first prepend. So, in your case you should
> >remove the rFP from the isNotEmpty tags. It should then work in the
> >manner you expect. If it does not, then we may have an issue.
> >
> >Brandon
> >
> >On 2/17/06, Petr Kokorev <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hello,
> >>
> >>
> >>I have a simple insert query like this (I am sure that at least one of
> >>the properties is not empty)
> >>
> >>
> >>  INSERT INTO ITEMS_TABLE
> >>  (
> >>  
> >> >>removeFirstPrepend="true">
> >>  PROPERTY_ONE
> >>
> >> >>removeFirstPrepend="true">
> >>  PROPERTY_TWO
> >>
> >>  
> >>  ,
> >>  VALUE
> >>  )
> >>  VALUES
> >>  (
> >>  
> >> >>removeFirstPrepend="true">
> >>  #propertyOne#
> >>
> >> >>removeFirstPrepend="true">
> >>  #propertyTwo#
> >>
> >>  
> >>  ,
> >>  #value:NUMERIC#
> >>  )
> >>
> >>
> >>The generated String for the prepared statement will be like this in the
> >>case of when both of the properties are not empty:
> >>
> >>  INSERT INTO ITEMS_TABLE ( , PROPERTY_ONE , PROPERTY_TWO , VALUE )
> >>VALUES ( , ? , ? , ? )
> >>
> >>So the 1st prepend is not being removed.
> >>I have done a workaround for it by specifying the prepend attribute for
> >>the  element:
> >>
> >>  
> >>
> >>Then it worked fine:
> >>
> >>  INSERT INTO ITEMS_TABLE ( PROPERTY_ONE , PROPERTY_TWO , VALUE ) VALUES
> >>( ? , ? , ? )
> >>
> >>I just wonder, is it normal?
> >>Because I find the 'prepend="("' thing a bit ugly, and I would like to
> >>have it like in my example.
> >>
> >>
> >>
> >>Thanks in advance and respect
> >>
> >>Pye
> >>
> >>
> >>
> Hello again
>
>
> I tried what you have recomended, I removed all the rFP attributes from
>  tags - the result was absolutely the same as the last time.
> If you do not specify the 'prepend="..."' attribute in  tag,
> the first prepend is not removed.
>
>
> Cheers
>
> Pye
>

Re: [jira] Commented: (IBATIS-268) utilizing iBatis for data accessing in ANSC c++

[Brandon Goodin]

If someone wanted to fully port ibatis to C++ i wouldn't stand in
their way :). But, I'm not going to do it :D

On 2/28/06, James, Steven <[EMAIL PROTECTED]> wrote:
> Are you talking about a complete port of ibatis?
>
> Steve..
>
> ________
>
> From: Brandon Goodin (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Tue 28/02/2006 16:23
> To: dev@ibatis.apache.org
> Subject: [jira] Commented: (IBATIS-268) utilizing iBatis for data accessing 
> in ANSC c++
>
>
>
> [ 
> http://issues.apache.org/jira/browse/IBATIS-268?page=comments#action_12368122 
> ]
>
> Brandon Goodin commented on IBATIS-268:
> ---
>
> Maybe we should move this to the wiki somewhere. C++ may not seem very 
> popular and is not something i plan to code into the forseeable future. But, 
> there may be those out there willing to take up the cause.Thoughts?
>
> > utilizing iBatis for data accessing in ANSC c++
> > ---
> >
> >  Key: IBATIS-268
> >  URL: http://issues.apache.org/jira/browse/IBATIS-268
> >  Project: iBatis for Java
> > Type: New Feature
> >  Environment: redhat linux as4
> > Reporter: david_y_johnson
>
> >
> > i want to utilize iBatis's feature and function in c++ program
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>http://www.atlassian.com/software/jira
>
>
>
>
>
> This e-mail and any attachment is for authorised use by the intended 
> recipient(s) only. It may contain proprietary material, confidential 
> information and/or be subject to legal privilege. It should not be copied, 
> disclosed to, retained or used by, any other party. If you are not an 
> intended recipient then please promptly delete this e-mail and any attachment 
> and all copies and inform the sender. Thank you.
>
>

Reporting Efforts

[Brandon Goodin]

Hey All,

Just a friendly reminder. Let's be sure that we are using JIRA to
communicate with each other. When you are working on a bug be sure to
assign it to yourself, adjust the status, and maintain this
information through the various stages of resolution. Also, it is good
to use JIRA to record questions and answers regarding the bug. This
will help us in the future as we are working through other issues. It
is best to keep the bug information as full as possible. This will
avoid us having to search development archives for information that
can more easily be found in bug comments.

Thanks!
Brandon Goodin

Re: Cannot find sqlmap in jar - new bug

[Brandon Goodin]

I place sqlmapconfig.xml in my jars without issue. Please state the
version of ibatis you are using and post the code you are using to
load your sqlmap config.

Brandon

On 6/10/06, Paul Benedict <[EMAIL PROTECTED]> wrote:

I am using version 2.1.5.582

My web application has a sqlMapConfig.xml file which is the bootstrap config 
for ibatis. But the
actual configuration files which it refers ( elements) are in a jar. 
Has anyone had this
problem?

I have verified that exploding the jar into my WEB-INF/classes directory makes 
the problem go
away, which means that IBATIS is making a wrong assumption here. Is it using a 
File object instead
of Class.getResourceAsStream() ?

-- Paul

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Cannot find sqlmap in jar - new bug

[Brandon Goodin]

oops...sorry didn't see the version in your original email. Still post
your code however.

Brandon

On 6/10/06, Brandon Goodin <[EMAIL PROTECTED]> wrote:

I place sqlmapconfig.xml in my jars without issue. Please state the
version of ibatis you are using and post the code you are using to
load your sqlmap config.

Brandon

On 6/10/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> I am using version 2.1.5.582
>
> My web application has a sqlMapConfig.xml file which is the bootstrap config 
for ibatis. But the
> actual configuration files which it refers ( elements) are in a jar. 
Has anyone had this
> problem?
>
> I have verified that exploding the jar into my WEB-INF/classes directory 
makes the problem go
> away, which means that IBATIS is making a wrong assumption here. Is it using 
a File object instead
> of Class.getResourceAsStream() ?
>
> -- Paul
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: Cannot find sqlmap in jar - new bug

[Brandon Goodin]

Paul,

All i can tell you is that i have recently created an application that
uses Spring, iBATIS and is jarred up. I have not faced the problems
that you are facing. The only difference is that i used resin instead
of Tomcat. If you feel it is related to classloading strategies then
give resin a try and see if it has the same issue. If it does wind up
being a classloading issue then i'd have to say it is a tomcat issue
rather than an iBATIS issue.

Also, it is not the iBATIS team's responsibility to create the code
and reproduce the issue you are experiencing. It is the reporting
user's responsibility to create repeatable code that can be used to
diagnose the problem. Then you can provide it to us as an issue in
JIRA. At that time it is then our responsibility to assist in
discovering the problem. But, even then, you are encouraged to assist
in the discovery of the problem.

Thanks
Brandon

On 6/11/06, Paul Benedict <[EMAIL PROTECTED]> wrote:

Clinton, it was only a conjecture that it was using the File object, but my 
follow up emails show
that I peeked into Resource.java to see what is going on.

But, afaik, all signs at the moment point to a problem in ibatis. When I pull 
the XML files out of
the jar and put them directly into WEB-INF/classes, the XML configs can be 
found. My best guess at
the moment is that it deals with the Classloader that is being passed in.

I'd like someone on the ibatis team to reproduce it. I am using tomcat 5.0.28, 
if it makes a
difference on what platform is used.

Paul

--- Clinton Begin <[EMAIL PROTECTED]> wrote:

> >> which means that IBATIS is making a wrong assumption here
>
> You're assuming iBATIS is making an assumption.  Which it is not. If you're
> using the the iBATIS Resources util, you can confirm the behavior here:
>
>
http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/src/com/ibatis/common/resources/Resources.java
>
> Cheers,
> Clinton
>
> On 6/10/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> >
> > I am using version 2.1.5.582
> >
> > My web application has a sqlMapConfig.xml file which is the bootstrap
> > config for ibatis. But the
> > actual configuration files which it refers ( elements) are in a
> > jar. Has anyone had this
> > problem?
> >
> > I have verified that exploding the jar into my WEB-INF/classes directory
> > makes the problem go
> > away, which means that IBATIS is making a wrong assumption here. Is it
> > using a File object instead
> > of Class.getResourceAsStream() ?
> >
> > -- Paul
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Cannot find sqlmap in jar - new bug

[Brandon Goodin]

I'd recommend that you place your sqlMapConfig.xml in the classes
directory and use the follwing spring config.


 
 


I would assume this issue is tied to the fact that the sqlMapConfig is
not being loaded from the classpath.

Brandon

On 6/11/06, Paul Benedict <[EMAIL PROTECTED]> wrote:

Brandon,

>>All i can tell you is that i have recently created an application that
uses Spring, iBATIS and is jarred up.

Forgive me, but based on the feedback I am getting, I am not convinced at all 
that my problem is
being understood. Can you give me some confidence it is? As I said, this is not 
a problem with the
application being jarred up --- my application is not jarred up.

My problem arises when:
(1) the sqlmapconfig.xml exists in the webapp but
(2) the actual sqlmap files belong in a LIB jar.

Do you see the difference?

Paul

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Abator..

[Brandon Goodin]

Hey guys,I have to say that I had a similar experience as Larry. I fired it up for a recent project and then deleted it. It was too much code for me.Issues I had:- The size of the sqlmaps  * "query by example" stuff is overwhelming... glad to hear it can be turned off
- The number of domain objects per table.* Blob Objects, Primary Key Objects, Example Object, Normal Domain Objects* This comes too close to tying my domain to the database. Not something I feel is a good idea.
* I have read Jeff's explanation for the Primary Key Object. I would respectfully disagree with it. This seems to be something that would be better addressed by providing constructor based initialization rather than a whole other domain object. Again tying my domain semantic to my database. 
* I've never had a need for more than one domain object to represent a simple table.In the end my feeling is that if we need code generation to be a regular part of the process then it points to a deficiency in our framework. This is a deficiency that I believe can be addressed largely without code gen. I enjoy using code gen when I have a quarter ton of boiler plate code i always have to write. This appears to be one of those cases. So, since code gen is always a step ahead of addressing the real problem... I think it will remain a need. However, I'd like to see it become a need that really has to be considered rather than a no brainer. 
Let's make code gen less compelling by fixing our framework. Then we can work on providing a tool to our iBATIS users that is more about making their use of the framework more productive rather than helping them generate a metric ton of code to make up for our deficiency. :)
I think it would be cool to see Abator move in a direction where it can read sqlmaps and provide the ability to pass in paramter objects during development and view what sql is produced. Even go as far as interaction with the database. These type of issues are what I think of when I think of productivity tools.
Jeff, thanks for all your hard work and for filling a niche with the users. Let's continue to refine Abator and iBATIS to the point that we have a tight framework and an excellent toolset.Brandon
On 6/26/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
Another thing to look at - the new version in SVN.  With the fix to nested iterate tags, the generated XML for the by example methods gets down to about 15 lines total - down from the current 20-25 lines per column in a table.  But with the new version, the example class is still complex because it can do virtually any WHERE clause you can imagine.

 
Also, there's much better documentation in SVN now too.  That should help.
 
Jeff Butler 
On 6/26/06, Larry Meadors <
[EMAIL PROTECTED]> wrote:
OK, I tried abator this weekend to see what it was like - it seems to
be generating alot of traffic, which got me wondering what I was
missing.So, I downloaded and unzipped it (no eclipse for me, thanks), andtweaked out a config file for a project I am working on and ran it ona couple of tables.It ran OK, so I popped open the code to see what I had.
I am not sure how to say this, and I do not mean to be discouraging,but I was shocked to see so much code. Like not in a good way - 7,777lines of code and xml in 10 files for 2 medium sized tables.Extrapolating that out to a system with 50-60 tables put me in the
200,000 - 250,000 line range.If I were an iBATIS beginner, it would have been so intimidating thatI'd have moved on to another tool like hibernate or db-commons withouta second look at iBATIS.
With that in mind, I re-evaluated the mail that has been coming about
it, and got started thinking about it. Obviously, people are using it,so it's not all bad, I just think we can find a better solution.While I think that Abator does address a problem with iBATIS (i.e.
creating simple sql by hand sucks), it is not a tool I'd recommend or
use in it's current state for a couple of reasons. First is the sheeramount of code it creates - 200,000 lines for 50 tables isunmanageable. Second is the amount of duplication in the generatedcode - the dao implementation was 3,000 lines long, and nearly all
repetitive.Jeff, I hope you don't read this and take it personally or getdiscouraged by it, I think you are fun guy to have on the team, and avery practical problem-solver (both great traits in a developer). I
just brought this up, because I want everyone to look at it as itgrows, and make sure that it matures into something that fits with thephilosophy of iBATIS, and improves the framework.Larry

Re: Abator..

[Brandon Goodin]

the "by example" functionality will be encapsulated in one class (the example class), and removed from the generated SQL map and DAO class.  The new example class has become a pretty complex class, but at least the complexity is well encapsulated.  The new style of SQL map and DAO objects are much simpler - more like "normal" iBATIS objects.  But if you still can't stand it, then you can always turn it off.

 
I added the "by example" functionality because, in my real life projects, it becomes an incredibly useful and reusable set of function.  I end up using the "by example" function a lot.
 
Lastly I'll mention that, to the best of my recollection, there's never been a complaint on the user's list about the complexity of the "by example" generated code.  Most questions on the "by example" code are asking for more function - which implies more complexity.

 
 
3. There are style differences related to generated domain classes.
 
Some like a flat model, some don't.  Some like constructors with parameters, some don't.  Because this is style related, it's hard to know what to do.  We could add some options to generate different styles of domain objects if we could come up with a reasonably small set of permutations.

 
 
4. Abator generates code that matches database tables, rather than a rich domain model.
 
See this for my thoughts on that subject:
 
http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/philosophy.html 

 
 
5. Useful code gen implies that something is wrong with iBATIS.
 
Maybe - but what's the alternative?  EJB 3.0?  As long as our philosphy is that humans write better SQL than ORM tools (that is our philisophy, isn't it?), I don't see much changing in that area.
 
Of course, iBATIS doesn't require a code gen - but code gen can make things easier (see the definition of the word "Abator" - it abates a nuisance).  It's a nice thought to think that there could be some future version of iBATIS that wouldn't benefit from code gen, but that's a long way off given our current pace of development. 

 
 
6. Abator should do something different than what it does (like debugging sql maps at development time).
 
This is not the purpose of Abator - but it sounds like a great idea for another tool.  You should get right on that - but not until after you finish multiple result set support :)
 
 
Please know that I REALLY appreciate the feedback.  I never meant to be a lone ranger on this, so I appreciate all ideas.  But I think the bulk of the objections come from the "by example" methods, which are entirely optional.  If you guys have other ideas for improving the tool then I'd love to work together on them!

 
BTW - I've spent a lot of time recently refining the documentation for Abator.  I'd really appreciate any feedback on what could be made clearer.  Just remember that this set of documentation references features that are not generally available yet (except in SVN).  Here's a link: 

 
http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/index.html 

 
 
 
Jeff Butler
 
 
On 6/26/06, Brandon Goodin <[EMAIL PROTECTED] 
> wrote: 

Hey guys,I have to say that I had a similar experience as Larry. I fired it up for a recent project and then deleted it. It was too much code for me.Issues I had:- The size of the sqlmaps  * "query by example" stuff is overwhelming... glad to hear it can be turned off 
- The number of domain objects per table.* Blob Objects, Primary Key Objects, Example Object, Normal Domain Objects* This comes too close to tying my domain to the database. Not something I feel is a good idea. 
* I have read Jeff's explanation for the Primary Key Object. I would respectfully disagree with it. This seems to be something that would be better addressed by providing constructor based initialization rather than a whole other domain object. Again tying my domain semantic to my database. 
* I've never had a need for more than one domain object to represent a simple table.In the end my feeling is that if we need code generation to be a regular part of the process then it points to a deficiency in our framework. This is a deficiency that I believe can be addressed largely without code gen. I enjoy using code gen when I have a quarter ton of boiler plate code i always have to write. This appears to be one of those cases. So, since code gen is always a step ahead of addressing the real problem... I think it will remain a need. However, I'd like to see it become a need that really has to be considered rather than a no brainer. 
Let's make code gen less compelling by fixing our framework. Then we can work on providing a tool to our iBATIS users that is more about making their use of the framework more productive rather than help

Re: [VOTE] New mailing list addresses (was: Any thoughts on creating a different email alias for Tools?)

[Brandon Goodin]

+1On 7/24/06, Gilles Bayon <[EMAIL PROTECTED]> wrote:
-1 [EMAIL PROTECTED] I prefer 


[EMAIL PROTECTED] ...+1 

[EMAIL PROTECTED]

Re: [VOTE] New mailing list addresses (was: Any thoughts on creating a different email alias for Tools?)

[Brandon Goodin]

Sorry, I clicked my Send too quickly...-1 on [EMAIL PROTECTED] i'd prefer to keep the languages apart+1 on [EMAIL PROTECTED]
On 7/24/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
Good call on a single request for both.  I'm all for:[EMAIL PROTECTED]
[EMAIL PROTECTED]This vote is open for 24 hours (no need to drag it out, it's not a world changing decision).
Cheers,ClintonOn 7/24/06, Jeff Butler <
[EMAIL PROTECTED]> wrote:
Wondering about the future...are there any more tools on the horizon?  Do we think there will be lots of tools?  If not, then I think 

[EMAIL PROTECTED] is OK.
 
Has the request for a Ruby list been made already?  If not, maybe we could make a joint request for two new lists.
 
Jeff Butler 
On 7/23/06, Clinton Begin <

[EMAIL PROTECTED]> wrote:

That's good news for tools.  I'm glad to see the level of interest.  I like the idea of a separate mailing list.  


[EMAIL PROTECTED]  ...or...

[EMAIL PROTECTED]
Cheers, 
Clinton


On 7/18/06, Nathan Maves <


 [EMAIL PROTECTED]> wrote:

Just seems that the ibatis list is being pounded by tools questions. Since they are two separate identities that we should have them on
different lists.Comments?Nathan
 

Re: iBATIS NOT at ApacheCon

[Brandon Goodin]

Dang, sorry to hear that Jeff. Perhaps you can still do some form of it as a Podcast and post it on the iBATIS website. I think it would be great to have that on the site.Brandon
On 9/18/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
I've just found out that my iBATIS tutorial was cancelled at ApacheCon - there were not enough enrollments to make it profitable.  iBATIS is too easy to use!  Maybe we should introduce some obfuscation so we can create a need for training :) 

 
So I'll not be going to ApacheCon after all.  I hope those of you that are going have a great time.  My only regret is that I'll not get to meet some of the other folks in our community.

 
Jeff Butler
 

Re: Little Red Hen (Was: developer guide for Data Mapper 2.2 seems to be missing section numbering)

[Brandon Goodin]

Remember that iBATIS fits well into a "Straight JDBC"/"iBATIS" hybrid. So, if you run into anything that iBATIS can't/shouldn't handle you can/should utilize JDBC. On top of that we are always here to help you.
"I really do want to make an effort to pay back in some small way"Payments can be made with Check or Visa. Make checks payable to my name ;-)Brandon Goodin
On 9/22/06, Richard Sullivan <[EMAIL PROTECTED]> wrote:
Guys I was just joking with the rant.  You've got a great product andgood documentation (even if it needs a bit of licking into shape).I've got the job at present of team leader to extend a project whichcontains thousands of lines of hard-coded JDBC.  I'm in the process of
evaluating whether  to try to use IBATIS to make the extension cleaner(at the price of extra risk due to my unfamiliarity with IBATIS) orjust creating more hand-coded brainless gunk to maintain.  Mycustomers management want NO risk but on the other hand the
development staff would be delighted to have somebody introduceIBATIS. If the code works then the management are not ever going tolook into how the new features were implemented, if it doesn't myreputation will suck.
I've just discussed the issue with the other developers and we aregoing for it !I'm praying things go smoothly and I really do want to make an effortto pay back in some small way for the effort you guys have put into
this great product.  Just I can't promise a time frame.Hope I can contribute soon.Ciao,RichardSo it is a tough call!I've done some tests with IBATIS and it was fine but the project calls
for some complex mappings so that could be risky for a newbie.  I'mleaning to going the path of least resistance for the moment(continuing the hand-coded mess)On 9/21/06, Clinton Begin <
[EMAIL PROTECTED]> wrote:> ...This story has some interesting parallels to the Open Source Software> community...>> The Story of Little Red Hen>  ==
>> Once there was a Little Red Hen who lived in a barnyard with her three> chicks and a duck, a pig and a cat.>> One day the Little Red Hen found some grains of wheat. "Look look!" she
> clucked. "Who will help me plant this wheat?">> "Not I", quaked the duck, and he waddled away.> "Not I", oinked the pig, and he trotted away.> "Not I, meowed the cat, and he padded away.
>> "Then I will plant it myself," said the Little Red Hen. And she did.>> When the wheat was tall and golden, the Little Red Hen knew it was ready to> be cut. "Who will help me cut the wheat?" she asked.
>> "Not I," said the duck.> "Not I," said the pig.> "Not I," said the cat>> "Then I will cut this wheat myself". And she did.>> "Now", said the Little Red Hen, "it is time to take the wheat to the miller
> so he can grind it into flour. Who will help me?">> "Not I," said the duck.> "Not I," said the pig.> "Not I," said the cat.>> "Then I will take the wheat to the miller myself," said the Little Red Hen.
> And she did.>> The miller ground the wheat into fine white flour and put it into a sack for> the Little Red Hen.>> When she returned to the barnyard, the Little Red Hen asked, "Who will help
> me make this flour into dough?">> "Not I," said the duck, the pig and the cat all at once.>> "Then I will make the dough myself," said the Little Red Hen. And she did.
>> When the dough was rready to go into the oven, the Little Red Hen asked,> "Who will help me bake the bread?">> "Not I," said the duck.> "Not I," said the pig.
> "Not I," said the cat.>> "Then I wll bake it myself," said the Little Red Hen. And she did.>> Soon the bread was ready. As she took it from the oven, the Little Red Hen
> asked, "Well who wil help me eat this warm, fresh bread?">> "I will," said the duck.> "I will," said the pig.> "I will," said the cat.>
> "No you won't," said the Little Red Hen. "You wouldn't help me plant the> seeds, cut the wheat, go to the miller, make the dough or bake the bread.> Now, my three chicks and I will eat this bread ourselves!"
>> And that's just what they did.>> >> Cheers,> Clinton>>>>>> On 9/21/06, Clinton Begin < 
[EMAIL PROTECTED]> wrote:> >> > Don't get us wrong Richard, we're not on your case.  Your points are all> valid, and we want to take them seriously.> >> > I want a solution that:
> >> >> > Improves the qua

Re: New iBATIS Documentation Format

[Brandon Goodin]

Open Office handles the reading and writing of docbook xml files as well. We could likely take the existing iBATIS docs and save them to docbook via Open Office, fix any oddities, and go. I'm for docbook because of it's tool support and cross platform ease of use.
BrandonOn 10/3/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
Heh, well, I am for it.I think either way (APT or docbook) we can switch later, so to me it'snot a decision that we need to really sweat over (on this project).I think with a little effort, we can create a modular main document
that includes the child documents. I could take a crack at it latertoday with the dev guide.The tutorial is on the list somewhere already.LarryOn 10/3/06, Clinton Begin <
[EMAIL PROTECTED]> wrote:> I'm sold, at least enough to give it a shot.>> I'm giving DocBook my +1.>> What does everyone else think?>> Clinton>> On 10/3/06, Jeff Butler <
[EMAIL PROTECTED]> wrote:> >> > For me the main advantage is that the source is plain XML so it's> diffable.> >> > Another advantage is that the source can be transformed into a large
> variety of formats (PDF, HTML, Word, Eclipse Help, etc.)> >> > Most publishers accept DOCBOOK markup as input.  So if anyone every wanted> to publish the developer's guide, it would be simple. (I know this is not
> really going to happen, but I think it says something that places like> O'Reilly accept DOCBOOK)> >> > Jeff Butler> >> >> >> >> >> > On 10/3/06, Clinton Begin <
[EMAIL PROTECTED] > wrote:> > >> > > I'm going to look at DocBook again.  I'll download the XMLMind editor> and the .NET guide (but I've heard that some people just use an IDE...no
> XMLMind necessary).> > >> > > But just to refresh my memorywhat are the advantages of DocBook over> OOo?> > >> > > Cheers,> > > Clinton
> > >> > >> >>>

Re: 2.2.0 GA, or 2.2.1?

[Brandon Goodin]

congrats!On 10/3/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
I'd rather just do a 2.2.1 deploy, beta, vote for GA.  It should only take a week or two to get 2.2.1 through.  We just waited longer than normal for 2.2.0 for no good reason.Well, I had a good reason, I'm now a father of two!  :-)
Cheers,ClintonOn 10/3/06, Jeff Butler <
[EMAIL PROTECTED]> wrote:
As far as I know, the only issue with 2.2.0 relates to the JDBC/ODBC bridge driver.  Is this enough to cause us to make a 2.2.1 release, or should we have a vote on making 2.2.0 GA with the caveat that there is a problem with the bridge driver?

 
Personally, I'd be OK with calling for a 2.2.0 GA vote because no one should use the horrible bridge driver anyway :)
 
I'm asking because the fact that it's labeled "beta" is causing some questions about adopting it where I'm currently placed.  IMO there's now been sufficient time for a beta test with no major issues raised.

 
Jeff Butler
 

Re: New iBATIS Documentation Format

[Brandon Goodin]

I exported a version of one of the docs to docbook from Open Office. It didn't do too bad of a job. But, I think it is someplace to start. I think we'll have to define an acceptable docbook layout that lends itself to easy trasformation using t things like xsl -> html, xsl -> fop -> pdf, etc. I've used docbook in the past for software help documentation. It takes a while to get your format sexy. But, the docbook xml is just a generic starting point. You can sex it up with the xsl.
BrandonOn 10/3/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
I'd agree - OOo on my box is total crap for docbook - like worse thanWord for HTML.LarryOn 10/3/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
> I don't think Brandon was suggesting we continue to use OOo with DocBook.  I> can attest to the poor quality of the DocBook output from OOo>> But it's a good way to start.  We can export to DocBook, then clean it up (a
> lot).  From that point on, we use XXE or a text editor...>> Cheers,> Clinton>>> On 10/3/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> > On 10/2/06, Clinton Begin <[EMAIL PROTECTED]> wrote:> > > DocBook -- currently the choice of iBATIS.NET documentation.  It excels
> at> > > "diffability" and multi-format including great PDF and HTML output.  But> it> > > fails at ease of use / familiarity and therefore participation and quick> > > changes/deployment as well.  All other criteria are met but not
> exceeded.> >> > DocBook with OpenOffice seems like a fair option.> >> > One thing to watch is whether systems like XMLMind format the> > underlying content in the same way. We'd want to avoid unnecessary
> > cruft on the checkins, so if everyone is OK with OpenOffice, that> > might make for the best default editor.> >> > The OO XML format is not the friendliest for a change log, since it
> > doesn't wrap lines, but it does seem like the lesser of evils.> >> > DocBook is also compatible with systems like Maven and Forrest, should> > that ever come up.> >
> > -Ted.> >>>

Re: New iBATIS Documentation Format

[Brandon Goodin]

I will echo Ted's sentiment... I used XXE in the past for docbook and I found it to be cumbersome as well. I ultimately wound up editing the docbook by hand. Granted this was over a year ago that i did this. So, I'm assuming XXE docbook support has improved. I'll dowload XXE and give it a whirl.
BrandonOn 10/4/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 10/3/06, Clinton Begin <[EMAIL PROTECTED]> wrote:> I don't think Brandon was suggesting we continue to use OOo with DocBook.  I> can attest to the poor quality of the DocBook output from OOo
>> But it's a good way to start.  We can export to DocBook, then clean it up (a> lot).  From that point on, we use XXE or a text editor...I'll try it again, but the last time I used XXE, I found it cumbersome
and distracting. OO is at least unobstrusive.Personally, I like the way the Struts 2 documentation is heading.* http://cwiki.apache.org/WW/home.html
The focus is on short guides, FAQs, and reference material that workwell in an online format. As a printed book, it would totally suck,but as an online guide, it's great. The best part is that we are ableto single-source a lot of material from the JavaDocs and sample
applications using a Confluence macro. The system clips snippets fromthe source material into the page, like a live cut and paste. All thematerial in tag guides is being sucked in from the JavaDocs.* 
http://cwiki.apache.org/WW/tag-reference.htmlThe autoexport macro is also working well for us, and some people areworking on some very attractive templates to dress up the HTML. Forthe distribution, we just bundle in a snapshot of the HTML export.
Click. Done.Realistically, any future contributions I would make will probably bevia Confluence anyway, so I'll stay out of the DocBook discussions.-Ted.

Re: New iBATIS Documentation Format

[Brandon Goodin]

personally, I would rather use my IDE which already does XML editing according to a schema and tells me when i'm doing something goofy. Also, the docbook is a base markup and not a final product. So, in the end it only servers to be transformed into something useful. So, I already have a set of tools that i use to do all that. I have an xml editor, xslt plugin, and xpath plugin. That's really all i should need. Am i missing something?
BrandonOn 10/4/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
Heheh, is this the politically correct way to say "they both suck"? ;-)IMO, the dissonance is because they are trying to accomplish two verydifferent things:XXE is an XML editor, not a word processor. It's goal is to make the
document structure correct.OO Writer is a general purpose word processor that is intended toreplace Word, and it happens to have a docbook writer bolted on.When I first used XXE, I found it to be really cumbersome, too...just
like the first time I used a real Java IDE. It tries to make sure youdon't screw stuff up (structurally), so you can't do whatever you wantwherever you want to - it forces you to play by the docbook rules.
It's a pain, but once you get used to it, it'll be like the differencebetween using an IDE and notepad for editing Java source. Withnotepad, you can put anything anywhere, right or wrong, but it's notcumbersome at all. ;-)
LarryOn 10/4/06, Ted Husted <[EMAIL PROTECTED]> wrote:> On 10/4/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> > I'll try it again, but the last time I used XXE, I found it cumbersome> > and distracting. OO is at least unobstrusive.>> I flipped back and forth between them for a while, and found each to
> be inadequate in different ways. I continued to be amazed at the lack> of  adequate tools for collaborating on technical documentation.>> -Ted.

Re: New iBATIS Documentation Format

[Brandon Goodin]

Valid points Larry and Clinton. Thanks for the feedback.BrandonOn 10/4/06, Clinton Begin <[EMAIL PROTECTED]
> wrote:The biggest thing for me is the embedded XML within the docs.  Because iBATIS has a  lot of XML of its own, it becomes a real pain when we have to start typing hundreds of <select> everywhere...
Cheers,
On 10/4/06, Larry Meadors <
[EMAIL PROTECTED]> wrote:
Nope, I think you have all you *need*, but XXE also gives you toolsfor things like inserting images and stuff that a text-based editorwon't (but after you do one, you won't need that), and is more WYSIWYGthan eclipse will be, so it may be faster to edit and see the
structure more clearly.Nothing earth-shattering, but some niceties nonetheless.I also agree that the markup should just be content, and the styleshould be applied with XSL later.IMO, that is another fundamental difference between using OO and an
XML editor: OO implies structure based on style; XML implies stylebased on structure.LarryOn 10/4/06, Brandon Goodin <
[EMAIL PROTECTED]> wrote:
> personally, I would rather use my IDE which already does XML editing> according to a schema and tells me when i'm doing something goofy. Also, the> docbook is a base markup and not a final product. So, in the end it only
> servers to be transformed into something useful. So, I already have a set of> tools that i use to do all that. I have an xml editor, xslt plugin, and> xpath plugin. That's really all i should need. Am i missing something?
>> Brandon>>> On 10/4/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
> > Heheh, is this the politically correct way to say "they both suck"? ;-)
> >> > IMO, the dissonance is because they are trying to accomplish two very> > different things:> >> > XXE is an XML editor, not a word processor. It's goal is to make the
> > document structure correct.> >> > OO Writer is a general purpose word processor that is intended to> > replace Word, and it happens to have a docbook writer bolted on.> >
> > When I first used XXE, I found it to be really cumbersome, too...just> > like the first time I used a real Java IDE. It tries to make sure you> > don't screw stuff up (structurally), so you can't do whatever you want
> > wherever you want to - it forces you to play by the docbook rules.> > It's a pain, but once you get used to it, it'll be like the difference> > between using an IDE and notepad for editing Java source. With
> > notepad, you can put anything anywhere, right or wrong, but it's not> > cumbersome at all. ;-)> >> > Larry> >> >> > On 10/4/06, Ted Husted <

[EMAIL PROTECTED]> wrote:> > > On 10/4/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> > > > I'll try it again, but the last time I used XXE, I found it cumbersome
> > > > and distracting. OO is at least unobstrusive.> > >> > > I flipped back and forth between them for a while, and found each to> > > be inadequate in different ways. I continued to be amazed at the lack
> > > of  adequate tools for collaborating on technical documentation.> > >> > > -Ted.> >>>

Re: New iBATIS Documentation Format

[Brandon Goodin]

I think the escaping is about all XXE is offering. The reason I say that is that we will likely be storing our images in a url location. I don't think we will be embedding images into docbook. That gets a little hard to manage when trying to transform to different presentation mediums. XXE will generate all the different formats. But the last time i used it... it was not as customizable as writing the xsl myself.
I think the clear thing here is that we are going to use DocBook. If people want to use XXE then fine. If they want to handcode it... then fine. Since ALL documentation solutions seems to be nasty, let's just get started with one of these and be on with whatever flavor of pain we like best. I can't believe documentation is a bigger discussion than writing code. Maybe we should just do like Ruby and put all of our documentation in the JavaDoc.
BrandonOn 10/4/06, Larry Meadors <[EMAIL PROTECTED]> wrote:
I guess that is another +1 for XXE - it escapes all that crap. Justpaste the code and you are done.LarryOn 10/4/06, Clinton Begin <[EMAIL PROTECTED]
> wrote:> The biggest thing for me is the embedded XML within the docs.  Because> iBATIS has a  lot of XML of its own, it becomes a real pain when we have to> start typing hundreds of <select> everywhere...
>> Cheers,>>> On 10/4/06, Larry Meadors <[EMAIL PROTECTED]> wrote:> > Nope, I think you have all you *need*, but XXE also gives you tools
> > for things like inserting images and stuff that a text-based editor> > won't (but after you do one, you won't need that), and is more WYSIWYG> > than eclipse will be, so it may be faster to edit and see the
> > structure more clearly.> >> > Nothing earth-shattering, but some niceties nonetheless.> >> > I also agree that the markup should just be content, and the style> > should be applied with XSL later.
> >> > IMO, that is another fundamental difference between using OO and an> > XML editor: OO implies structure based on style; XML implies style> > based on structure.> >
> > Larry> >> >> > On 10/4/06, Brandon Goodin <[EMAIL PROTECTED]> wrote:> > > personally, I would rather use my IDE which already does XML editing
> > > according to a schema and tells me when i'm doing something goofy. Also,> the> > > docbook is a base markup and not a final product. So, in the end it only> > > servers to be transformed into something useful. So, I already have a
> set of> > > tools that i use to do all that. I have an xml editor, xslt plugin, and> > > xpath plugin. That's really all i should need. Am i missing something?> > >> > > Brandon
> > >> > >> > > On 10/4/06, Larry Meadors <[EMAIL PROTECTED]> wrote:> > > > Heheh, is this the politically correct way to say "they both suck"?
> ;-)> > > >> > > > IMO, the dissonance is because they are trying to accomplish two very> > > > different things:> > > >> > > > XXE is an XML editor, not a word processor. It's goal is to make the
> > > > document structure correct.> > > >> > > > OO Writer is a general purpose word processor that is intended to> > > > replace Word, and it happens to have a docbook writer bolted on.
> > > >> > > > When I first used XXE, I found it to be really cumbersome, too...just> > > > like the first time I used a real Java IDE. It tries to make sure you> > > > don't screw stuff up (structurally), so you can't do whatever you want
> > > > wherever you want to - it forces you to play by the docbook rules.> > > > It's a pain, but once you get used to it, it'll be like the difference> > > > between using an IDE and notepad for editing Java source. With
> > > > notepad, you can put anything anywhere, right or wrong, but it's not> > > > cumbersome at all. ;-)> > > >> > > > Larry> > > >> > > >
> > > > On 10/4/06, Ted Husted < [EMAIL PROTECTED]> wrote:> > > > > On 10/4/06, Ted Husted <[EMAIL PROTECTED]
> wrote:> > > > > > I'll try it again, but the last time I used XXE, I found it> cumbersome> > > > > > and distracting. OO is at least unobstrusive.> > > > >
> > > > > I flipped back and forth between them for a while, and found each to> > > > > be inadequate in different ways. I continued to be amazed at the> lack> > > > > of  adequate tools for collaborating on technical documentation.
> > > > >> > > > > -Ted.> > > >> > >> > >> >>>

Re: Proposed Enhancement - Support Multiple Parameter Classes

[Brandon Goodin]

If your enterprise requires that you display audit data then what is it that is not part of the domain? It is domain relevant data. Just because it is shared among all database tables doesn't make it non-domain. For auditing i generally have a couple of different levels. One is "single generation" and the other "historical". When handling "single generation update/insert auditing, I add a date and user field to my POJOs (one of each for insert and update). For "historical" auditing, I place a trigger that writes to another table whenever a record is updated/deleted. This maintains a truly historical auditing trail. I would encourage you to just add the "single generation" audit fields to your POJOs and be done with it.
BrandonOn 10/10/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
Hi All,
 
We have an issue that I believe is quite common with enterprise databases.  Many (most) of the tables contain fields that are necessary for insert/update, but those fields do not really belong in our domain objects.  These fields are often related to audit tracking in the tables (update timestamp, update user, update process, etc.). 

 
In my mind, these fields are DB trash that do not belong in domain objects.  However, if we build our POJOs without the DB trash, inserts and updates become problematical.  We've tried these approaches to the problem: 

 
1. Put every field in a Map for insert/update, pass the Map as parameter object
2. Put the POJO in a Map, add the DB trash to the Map, pass the Map as a parameter object
3. Create some special subclass of the POJO that adds the DB trash, then do the get/set dance to populate the subclass and pass the subclass as a parameter object
4. Create pseudo POJOs that exactly match the table, do the get/set dance from our real POJOs to the table specific POJOs, and then fill in the DB trash columns as appropriate in the table specific POJOs
 
Each of these approaches has a particular smell - sometimes forcing the use of Maps, sometimes forcing the get/set dance, sometimes both.  I'm favoring #4 right now, but still - it's not optimal.
 
My thought is that this whole issue could be elegantly solved if we allowed multiple parameter classes like this:
 

 ...

 
and then we added special processing for supporting a List of parameter objects passed in on the SqlMapClient methods.
 
What are your thoughts?  Have I missed some different and better way of dealing with this issue?  Would this approach be too difficult to implement in iBATIS?
 
Jeff Butler
 

Re: Proposed Enhancement - Support Multiple Parameter Classes

[Brandon Goodin]

I guess I don't completely understand your issue. Do you have 10 different SqlMpas instantiated that call 10 different database and may share 1 domain object that needs to write to all of them? This souns extreme to me.
On 10/10/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
It's not for display - it's only required for update/insert.
 
Maybe I need to clarify what I mean by an "enterprise database".  In our situation, this means "separate DBA and database design group - not under our control".  So things like stored procedures, extra triggers, and table design changes aren't really options for us.  Most truly enterprise databases have many different applications hitting them and they maintain their own sets of standards.  They usually aren't open to changing things just to make it easier for one client application.

 
As to whether these fields belong in the POJOs or not, this is certainly open to debate.  An issue with it is this - one domain object could map to many more than one DB table (we have cases where a domain object maps to upwards of 10 tables).  Maintaining all the DB trash for these 10 different tables in my domain object makes the object very tightly coupled with the DB - might as well just use classes that exactly match the tables if we're going there (this is sort of what I'm doing anyway).

 
I'm intrigued with Larry's idea of accessing static ThreadLocal data in a mapped statement.  I wonder what the syntax for that would look like?
 
Jeff Butler
 
 
On 10/10/06, Brandon Goodin <[EMAIL PROTECTED]
> wrote:
If your enterprise requires that you display audit data then what is it that is not part of the domain? It is domain relevant data. Just because it is shared among all database tables doesn't make it non-domain. For auditing i generally have a couple of different levels. One is "single generation" and the other "historical". When handling "single generation update/insert auditing, I add a date and user field to my POJOs (one of each for insert and update). For "historical" auditing, I place a trigger that writes to another table whenever a record is updated/deleted. This maintains a truly historical auditing trail. I would encourage you to just add the "single generation" audit fields to your POJOs and be done with it. 
Brandon

Caching and provided result object

[Brandon Goodin]

Hey all,I'm not sure if anyone else has ran up against this. But, there is a problem when using queryForObject(id, parameterObject, resultObject) and caching. I have code that does the following:public class Monster {
private String monsterName;private Integer ferocityLevel;private Integer height;...//getters/setters...}public class MonsterService {...    public Monster getMonster (String monsterName) {
    Monster monster = new Monster(monsterName);
        return monsterDao.fetch(monster);
    }...}public class MonsterDao {...    public void fetch (Monster monster) {        queryForObject("Monster.fetch", monster, monster);    }...}The first time I call 
MonsterService.getMonster("Godzilla"), all is fine because the Monster object is not yet cached in iBATIS. The normal means of populating the supplied resultObject is employed. But as soon as the object is cached it never populates my resultObject beyond the monsterName that i provided. Basically, when getCacheKey(request, parameterObject) is called it returns the monster object appropriately. The only problem is that it never populates the supplied resultObject. It simply returns the cachedObject which would be fine if I wasn't providing a resultObject that i expected to be populated.
In other words, I'm not looking for a returned object I'm looking for my supplied object to be populated.-- CachingStatement --...public Object executeQueryForObject(RequestScope request, Transaction trans, Object parameterObject, Object resultObject)
     throws SQLException {   CacheKey cacheKey = getCacheKey(request, parameterObject);
   cacheKey.update("executeQueryForObject");   Object object = cacheModel.getObject(cacheKey);   if (object == CacheModel.NULL_OBJECT){       //    This was cached, but null       object = null;
   }else if (object == null) {       object = statement.executeQueryForObject(request, trans, parameterObject, resultObject);  cacheModel.putObject(cacheKey, object);   }    return object;}
..
--We could provide a means either in the CachedStatement class or upstream in the SqlMapExecutorDelegate to handle the translation from the cached object values into the supplied resultObject.Thoughts?
Brandon.

Re: [VOTE] Deprecate PaginatedList related interfaces, implementations and APIs.

[Brandon Goodin]

+1On 10/23/06, Clinton Begin <[EMAIL PROTECTED]> wrote:

This is the official vote to deprecate both the PaginatedList interface, the queryForPaginatedList() 

method and all PaginagedList implementations.The deprecated APIs and classes will be marked with the deprecated flag for a period of 6 months and thereafter removed completely from the API.  
For those who depende upon this functionality, we will provide a recommended upgrade path in either example form or possibly as a set of utility classes that achieve the same functionality as the PaginatedList features do today.


Please vote with your +1/-1 by responding to this email.

Cheers,
Clinton

Re: [VOTE] Deprecate DAO (Java) / DataAccess (.NET) frameworks

[Brandon Goodin]

+1On 10/23/06, Clinton Begin <[EMAIL PROTECTED]> wrote:

This is the official vote to deprecate both the iBATIS for Java DAO Framework and the 
iBATIS.NET DataAccess Framework
.

The deprecated frameworks will be removed from the primary download,
archived in the source control system ("moved"), and the documentation
archived.

The software will be made available in a final release form that will
be clearly separated from the main General Availability downloads and
marked explicitly as "Deprecated".

These frameworks will be supported on an ad hoc basis and any changes
will be at the sole discretion of the development team, and likely need
to be voted on for release separately from the mapper frameworks.  

Anyone wishing to continue development of the DAO or DataAccess
frameworks are welcome to do so within compliance of the licensing
terms of the Apache Software License 2.0.

Please vote with your +1/-1 by responding to this email.

Cheers,
Clinton

Re: Status of 2.3 Release

[Brandon Goodin]

Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some
time and contains several bug fixes over 2.1.7. I would also say that
2.2.0could be made GA. The other thought is that there is no guarantee
that
2.3 will be GA quality after we get it out there for 2 weeks, however
unlikely that may be. Thanks for getting this all together!

B

On 11/30/06, Jeff Butler <[EMAIL PROTECTED]> wrote:


Hi All,

I have everything built for 2.3, and have everything signed and
checksummed.  Unfortunately, there are permission problems in the .../dist
directories, so I'm stuck right now.  I've sent a note to infra@ and as soon
as they get the permission problems resolved, then I'll be able to publish
the release.

This will be the first iBATIS/Java release that uses the Apache mirroring
structure - I'm going to implement the new Apache release policy according
to the notice the committers received a couple of weeks ago.

My release plan looks like this:

1. Post the 2.3 and 2.1.7 builds to the mirrors.  2.3 will superceed 2.2,
so no need to post it
2. Label 2.3 as beta, 2.1.7 is still the GA release
3. Call for a vote for 2.3 GA two weeks after 2.3 is posted

I'll keep you posted - hopefully I'll get it done tomorrow.

Jeff Butler

Re: Status of 2.3 Release

[Brandon Goodin]

I'm fine with pushing 2.3. But, I had a conversation on the list with
someone who feared upgrading to 2.2 because it wasn't GA. This was,
apparently, a company policy. They need a feature that is available in
2.2but will not upgrade because it is not GA. If we do not make
2.2 GA then their company policy will continue to hold them up. I guess I
don't see a reason why we wouldn't make it GA. It has been available for
some time with fewer bugs than 2.1.7. If I were to blow off any release I'd
blow off 2.1.7 because it conatins more bugs than 2.2.

Brandon

On 12/1/06, Clinton Begin <[EMAIL PROTECTED]> wrote:



My vote is to leave it the way it is.  My conservative, pragmatic and
adventurous sides are all satisfied by having a single GA release as well as
the latest "Beta" release available for download.  2.2 is available in the
past releases if people want it.

Cheers,
Clinton

On 12/1/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
>
> I forgot about that conversation, I was thinking of this one:
>
> http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html
>
> A great example of selective memory on my part :)
>
> Anyway I'm open to a GA vote for 2.2 if we need to.  But maybe we should
> let the dust settle on 2.3 for a few days.  If it looks like it will
> fly, then we could do the 2.3 GA vote a little sooner.  The major thing
> in 2.3 was prepared statement caching and I know there's already been
> some public testing of it.  Most of the fixes I did were for esoteric
> issues.  I think 2.3 is pretty solid.
>
> Your thoughts - should I post the 2.2 build to the mirrors?  That
> wouldn't take much effort now that I know how to sign releases (it was a
> strange trip into command line hacker heaven).
>
> Jeff Butler
>
>
>
> On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> >
> > To clarify, what I suggested a week or so ago was:
> >
> > "We can vote for GA anytime, even after another release makes it to
> > GA.  The beta, alpha, GA status is always flexible.  We could vote for GA on
> > 2.2. right now actually. "
> >
> > So a little closer to what Brandon is suggesting.  However, I'm more
> > interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to
> > GA.
> >
> > Cheers,
> > Clinton
> >
> > On 12/1/06, Jeff Butler <[EMAIL PROTECTED] > wrote:
> > >
> > > We discussed this some weeks ago.  IIRC, Clinton wanted to do a new
> > > release rather than voting for GA on 2.2.
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 12/1/06, Brandon Goodin <[EMAIL PROTECTED] > wrote:
> > > >
> > > > Curious why we are superceding 2.2 wit 2.3? 2.2 has been available
> > > > for some time and contains several bug fixes over 2.1.7. I would
> > > > also say that 2.2.0 could be made GA. The other thought is that
> > > > there is no guarantee that 2.3 will be GA quality after we get it
> > > > out there for 2 weeks, however unlikely that may be. Thanks for getting 
this
> > > > all together!
> > > >
> > > > B
> > > >
> > > > On 11/30/06, Jeff Butler <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I have everything built for 2.3, and have everything signed and
> > > > > checksummed.  Unfortunately, there are permission problems in the 
.../dist
> > > > > directories, so I'm stuck right now.  I've sent a note to infra@ and 
as soon
> > > > > as they get the permission problems resolved, then I'll be able to 
publish
> > > > > the release.
> > > > >
> > > > > This will be the first iBATIS/Java release that uses the Apache
> > > > > mirroring structure - I'm going to implement the new Apache release 
policy
> > > > > according to the notice the committers received a couple of weeks ago.
> > > > >
> > > > > My release plan looks like this:
> > > > >
> > > > > 1. Post the 2.3 and 2.1.7 builds to the mirrors.  2.3 will
> > > > > superceed 2.2, so no need to post it
> > > > > 2. Label 2.3 as beta, 2.1.7 is still the GA release
> > > > > 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted
> > > > >
> > > > > I'll keep you posted - hopefully I'll get it done tomorrow.
> > > > >
> > > > > Jeff Butler
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>

Re: Status of 2.3 Release

[Brandon Goodin]

I think that would be good (of course) :D.

Brandon

On 12/1/06, Clinton Begin <[EMAIL PROTECTED]> wrote:



That's a great point.  I've had similar discussions.

How about this:  Let's do the vote for 2.2. GA right now.  Assuming it
passes (I don't see why not considering how long it's been out), we update
2.1.7 to 2.2 on the website by Monday.

Then, next Friday (7 days) we start the vote for 2.3 GA and give it 7 more
days to settle.  Within two weeks we'll have a 2.2 and a 2.3 GA.

I agree that we should probably GA 2.2 because people are already using
it, but also because it's the last DAO release...that way we have a GA'd
final DAO.

Sound good?

Clinton

On 12/1/06, Brandon Goodin <[EMAIL PROTECTED]> wrote:
>
> I'm fine with pushing 2.3. But, I had a conversation on the list with
> someone who feared upgrading to 2.2 because it wasn't GA. This was,
> apparently, a company policy. They need a feature that is available in
> 2.2 but will not upgrade because it is not GA. If we do not make 2.2 GA
> then their company policy will continue to hold them up. I guess I don't see
> a reason why we wouldn't make it GA. It has been available for some time
> with fewer bugs than 2.1.7. If I were to blow off any release I'd blow
> off 2.1.7 because it conatins more bugs than 2.2.
>
> Brandon
>
> On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> >
> >
> > My vote is to leave it the way it is.  My conservative, pragmatic and
> > adventurous sides are all satisfied by having a single GA release as well as
> > the latest "Beta" release available for download.  2.2 is available in
> > the past releases if people want it.
> >
> > Cheers,
> > Clinton
> >
> > On 12/1/06, Jeff Butler < [EMAIL PROTECTED]> wrote:
> > >
> > > I forgot about that conversation, I was thinking of this one:
> > >
> > > http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html
> > >
> > > A great example of selective memory on my part :)
> > >
> > > Anyway I'm open to a GA vote for 2.2 if we need to.  But maybe we
> > > should let the dust settle on 2.3 for a few days.  If it looks like
> > > it will fly, then we could do the 2.3 GA vote a little sooner.  The
> > > major thing in 2.3 was prepared statement caching and I know there's
> > > already been some public testing of it.  Most of the fixes I did were for
> > > esoteric issues.  I think 2.3 is pretty solid.
> > >
> > > Your thoughts - should I post the 2.2 build to the mirrors?  That
> > > wouldn't take much effort now that I know how to sign releases (it was a
> > > strange trip into command line hacker heaven).
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> > > >
> > > > To clarify, what I suggested a week or so ago was:
> > > >
> > > > "We can vote for GA anytime, even after another release makes it
> > > > to GA.  The beta, alpha, GA status is always flexible.  We could vote 
for GA
> > > > on 2.2. right now actually. "
> > > >
> > > > So a little closer to what Brandon is suggesting.  However, I'm
> > > > more interested in leaving 2.1.7 and 2.2 in the past and getting
> > > > 2.3 to GA.
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > > > On 12/1/06, Jeff Butler <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > We discussed this some weeks ago.  IIRC, Clinton wanted to do a
> > > > > new release rather than voting for GA on 2.2.
> > > > >
> > > > > Jeff Butler
> > > > >
> > > > >
> > > > >
> > > > > On 12/1/06, Brandon Goodin <[EMAIL PROTECTED] > wrote:
> > > > > >
> > > > > > Curious why we are superceding 2.2 wit 2.3? 2.2 has been
> > > > > > available for some time and contains several bug fixes over
> > > > > > 2.1.7. I would also say that 2.2.0 could be made GA. The other
> > > > > > thought is that there is no guarantee that 2.3 will be GA
> > > > > > quality after we get it out there for 2 weeks, however unlikely 
that may be.
> > > > > > Thanks for getting this all together!
> > > > > >
> > > > > > B
> > > > > >
> > > > > > On 11/30/06, Jeff Butler <[

Re: Re: Status of 2.3 Release

[Brandon Goodin]

Is this an official vote? If so...
+1

On 12/2/06, Clinton Begin <[EMAIL PROTECTED]> wrote:

Sold.  +1


On 12/2/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
>
> I think it's a good idea too.
>
> I could sign the 2.2.0 zip and publish it to the mirrors.  I want to add
the 2.2 PDF docs to it first though.  Then everything for the last DAO
release (including docs) would be in one place.
>
> Sound like a plan?
> Jeff
>
>
>
> On 12/2/06, Brandon Goodin <[EMAIL PROTECTED] > wrote:
> > I think that would be good (of course) :D.
> >
> >
> > Brandon
> >
> >
> > On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> > >
> > > That's a great point.  I've had similar discussions.
> > >
> > > How about this:  Let's do the vote for 2.2. GA right now.  Assuming it
passes (I don't see why not considering how long it's been out), we update
2.1.7 to 2.2 on the website by Monday.
> > >
> > > Then, next Friday (7 days) we start the vote for 2.3 GA and give it 7
more days to settle.  Within two weeks we'll have a 2.2 and a 2.3 GA.
> > >
> > > I agree that we should probably GA 2.2 because people are already
using it, but also because it's the last DAO release...that way we have a
GA'd final DAO.
> > >
> > > Sound good?
> > >
> > > Clinton
> > >
> > >
> > >
> > > On 12/1/06, Brandon Goodin < [EMAIL PROTECTED] > wrote:
> > > > I'm fine with pushing 2.3. But, I had a conversation on the list
with someone who feared upgrading to 2.2 because it wasn't GA. This was,
apparently, a company policy. They need a feature that is available in 2.2
but will not upgrade because it is not GA. If we do not make 2.2 GA then
their company policy will continue to hold them up. I guess I don't see a
reason why we wouldn't make it GA. It has been available for some time with
fewer bugs than 2.1.7. If I were to blow off any release I'd blow off 2.1.7
because it conatins more bugs than 2.2.
> > > >
> > > > Brandon
> > > >
> > > >
> > > >
> > > > On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > My vote is to leave it the way it is.  My conservative, pragmatic
and adventurous sides are all satisfied by having a single GA release as
well as the latest "Beta" release available for download.  2.2 is available
in the past releases if people want it.
> > > > >
> > > > >
> > > > > Cheers,
> > > > > Clinton
> > > > >
> > > > >
> > > > > On 12/1/06, Jeff Butler < [EMAIL PROTECTED] > wrote:
> > > > > >
> > > > > > I forgot about that conversation, I was thinking of this one:
> > > > > >
> > > > > >
http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html
> > > > > >
> > > > > > A great example of selective memory on my part :)
> > > > > >
> > > > > > Anyway I'm open to a GA vote for 2.2 if we need to.  But maybe
we should let the dust settle on 2.3 for a few days.  If it looks like it
will fly, then we could do the 2.3 GA vote a little sooner.  The major thing
in 2.3 was prepared statement caching and I know there's already been some
public testing of it.  Most of the fixes I did were for esoteric issues.  I
think 2.3 is pretty solid.
> > > > > >
> > > > > > Your thoughts - should I post the 2.2 build to the mirrors?
That wouldn't take much effort now that I know how to sign releases (it was
a strange trip into command line hacker heaven).
> > > > > >
> > > > > > Jeff Butler
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 12/1/06, Clinton Begin <[EMAIL PROTECTED] > wrote:
> > > > > > > To clarify, what I suggested a week or so ago was:
> > > > > > >
> > > > > > > "We can vote for GA anytime, even after another release makes
it to GA.  The beta, alpha, GA status is always flexible.  We could vote for
GA on 2.2. right now actually. "
> > > > > > >
> > > > > > > So a little closer to what Brandon is suggesting.  However,
I'm more interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to
GA.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Clinton
> >

Re: [VOTE] iBATIS for Java 2.2.0 to GA

[Brandon Goodin]

+1

On 12/4/06, Jeff Butler <[EMAIL PROTECTED]> wrote:

Following this conversation:

http://www.mail-archive.com/dev%40ibatis.apache.org/msg02094.html

I'm calling a vote to promote 2.2 to GA status.

Known problems with 2.2:

- Doesn't work with JDBC/ODBC Bridge Driver
(http://issues.apache.org/jira/browse/IBATIS-335 )
- Doesn't work with interface inheritance hierarchies
(http://issues.apache.org/jira/browse/IBATIS-353 )

Both of these issues are rare, and there are fixes available in the 2.3 beta
if it becomes a showstopper for anyone.  Also, 2.2.0 is the last release
with the DAO framework, so it seemed good to get it to GA status.

I'm +1, but I'm not on the PMC so my vote isn't binding.

Jeff Butler

Re: iBATIS for Java 2.2.0 is Promoted to GA Status

[Brandon Goodin]

You rock Jeff

On 12/5/06, Jeff Butler <[EMAIL PROTECTED]> wrote:

The votes are in and iBATIS for Java 2.2.0 is declared to be of Apache
General Availability status.

Version 2.2.0 is the most significant upgrade of iBATIS in well over a year
and has many new features and bug fixes.  Version 2.2.0 is also the last
release of iBATIS for Java that will include the DAO framework.  JIRA
release notes for version 2.2.0 can be seen here:

http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12310720&styleName=Text&projectId=10601&Create=Create




Version 2.3.0 is also availabile, and is currently in beta status.  Version
2.3.0 has additional bug fixes, and new support for local caching of
prepared statements.  JIRA release notes for version 2.3.0 can be seen here:

http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312035&styleName=Text&projectId=10601&Create=Create



All versions of iBATIS for Java are available here:

http://ibatis.apache.org/javadownloads.cgi

Enjoy!
Jeff Butler

Re: Multiple compareValue in isEqual?

[Brandon Goodin]

This question should be posted to the user list.

It is not possible to check multiple values in one tag. However, you can
create multiple tags. This is less than ideal but, it does work. We should
be addressing these type of things as we work towards iB3. Feel free to
create a JIRA ticket for this feature ehancement.

Example of multiple tags:

... content



... identical content


Brandon

On 1/23/07, jenniferG <[EMAIL PROTECTED]> wrote:



Is it possible to add multiple compare values to the isEqual dynamic
statement?  For example I have



But I would like to check the "test" property for both "A" and "B".  How
do
I do this?
--
View this message in context:
http://www.nabble.com/Multiple-compareValue-in-isEqual--tf3065249.html#a8525246
Sent from the iBATIS - Dev mailing list archive at Nabble.com.

Re: Multiple compareValue in isEqual?

[Brandon Goodin]

I am all for it and there is discussion about it in a couple locations:

iBATIS 3.0 Whiteboard:
http://opensource.atlassian.com/confluence/oss/display/IBATIS/iBATIS+3.0+Whitebo

Improved Dynamic SQL Whiteboard:
http://opensource.atlassian.com/confluence/oss/display/IBATIS/Improved+Dynamic+SQL+Whiteboard

Brandon

On 1/23/07, Tom Duffey <[EMAIL PROTECTED]> wrote:



On Jan 23, 2007, at 11:09 AM, Brandon Goodin wrote:

This question should be posted to the user list.

It is not possible to check multiple values in one tag. However, you can
create multiple tags. This is less than ideal but, it does work. We should
be addressing these type of things as we work towards iB3. Feel free to
create a JIRA ticket for this feature ehancement.

Example of multiple tags:

... content



... identical content



Are there any plans to make the iBATIS SQL Map logic syntax more
flexible?  Often when I write a SQL map I find myself wishing for JSTL-like
syntax to write something like:


... content


Tom

On 1/23/07, jenniferG <[EMAIL PROTECTED]> wrote:
>
>
> Is it possible to add multiple compare values to the isEqual dynamic
> statement?  For example I have
>
> 
>
> But I would like to check the "test" property for both "A" and "B".  How
> do
> I do this?
> --
> View this message in context: 
http://www.nabble.com/Multiple-compareValue-in-isEqual--tf3065249.html#a8525246
>
> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>
>

Re: Direct-to-Field mappings now implemented.

[Brandon Goodin]

To avoid the unpredictability of this functionality couldn't we add some
configure options like:

* a diretoryToMappintEnabled=true/false property on the SQL Map Config. This
would set it globally. False would follow strict bean and (eventually)
constructor setting.
* To bring further clarity we should define the lookup order in our docs.
First a setter is attempted and then a property is attempted ( I would
guess)
* Perhaps you could even go as far as placing a reverseLookup=true/false
field on mappings so that the field is examined before the setter this could
be done in the inline and xml based mappings.

Just some thoughts that may provide our usual implicit/explicit options.
Layout the functionality to act in a common known way and provide the
ability to tweak it when needed.

Brandon

On 2/9/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


No, what Jeff originally described in this thread, that you already
agreed with.  ;-)

Clinton

On 2/9/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
> I searched the mail archives, but I am not privy to what Jeff originally
> described. Is it anything similar to what I've been talking about?
> Please send me a link or email :-)
>
> Thanks!
> Paul
>
> Clinton Begin wrote:
> > Okay guys.  I'm convinced.  Let's give this thread 24 hours for anyone
> > else who wants to chime in.  If nobody speaks up, we'll implement it
> > the way Jeff described it originally.
> >
> > I think it will be cool regardless.   I'm actually feeling pretty dumb
> > for not implementing this 3 years ago...it was way too easy to have
> > not done it long ago.  it was a couple of extra methods and a few line
> > changes in about 5 classes...  :-/
> >
> > Cheers,
> > Clinton
> >
> > On 2/9/07, Poitras Christian <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> I guess you have a point.
> >>
> >> Probably 90% of developpers won't want to know how the real path
used...
> >> Even if knowing it is interesting, it might disapoint people to force
> >> them
> >> to know it in advance.
> >> In other cases, getters may include code that will be skipped using
> >> direct
> >> field access.
> >>
> >> Now the point to this email is that iBATIS didn't force people to
have an
> >> idea of the implementation before writting xml files. Changing this
habit
> >> may reduce the interest of iBATIS as a simple tool for O/R mapping.
> >> Personally, I am afraid of the reactions some people will have when
> >> they'll
> >> begin mixing beans, pojos and maps (all 3 for crazy people only!, but
> >> most
> >> pojos/maps users).
> >> Another problem will arise with resultMaps that will need this
> >> notation at
> >> the same time (to know if we call a setter or a use the field).
> >>
> >> I personally think it is to late to force people to change their
iBATIS
> >> habit. But make sure that they'll know what the framework will do.
For
> >> instance calling the getter if present, if not accessing the field
> >> directly.
> >>
> >> Maybe the notation can be optionnal and will force iBATIS to try
> >> accessing
> >> the field first, then the getter if field is not present. Think this
> >> would
> >> do?
> >>
> >> Christian
> >>
> >>  
> >>  From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On
> >> Behalf Of Paul Benedict
> >> Sent: Friday, 09 February 2007 15:17
> >> To: dev@ibatis.apache.org
> >> Subject: Re: Direct-to-Field mappings now implemented.
> >>
> >>
> >> Poitras and Clinton,
> >>
> >> I agree. The refactoring argument is pretty strong. Property notation
is
> >> script-like because the actual means to get to the value (method vs.
> >> direct-field access) is totally secondary to the intention. The
developer
> >> just needs to express the path, and the framework should be
intelligent
> >> enough to get there. But we can't assume the developer always wants
> >> direct-field access, which is why the option must be turned on.
> >>
> >> PS: -1 on the brackets.
> >>
> >> Paul
> >>
> >
>

Re: Direct-to-Field mappings now implemented.

[Brandon Goodin]

Correction

* a fieldMappingEnabled=true/false...

On 2/10/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:


To avoid the unpredictability of this functionality couldn't we add some
configure options like:

* a diretoryToMappintEnabled=true/false property on the SQL Map Config.
This would set it globally. False would follow strict bean and (eventually)
constructor setting.
* To bring further clarity we should define the lookup order in our docs.
First a setter is attempted and then a property is attempted ( I would
guess)
* Perhaps you could even go as far as placing a reverseLookup=true/false
field on mappings so that the field is examined before the setter this could
be done in the inline and xml based mappings.

Just some thoughts that may provide our usual implicit/explicit options.
Layout the functionality to act in a common known way and provide the
ability to tweak it when needed.

Brandon

On 2/9/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
> No, what Jeff originally described in this thread, that you already
> agreed with.  ;-)
>
> Clinton
>
> On 2/9/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
> > I searched the mail archives, but I am not privy to what Jeff
> originally
> > described. Is it anything similar to what I've been talking about?
> > Please send me a link or email :-)
> >
> > Thanks!
> > Paul
> >
> > Clinton Begin wrote:
> > > Okay guys.  I'm convinced.  Let's give this thread 24 hours for
> anyone
> > > else who wants to chime in.  If nobody speaks up, we'll implement it
> > > the way Jeff described it originally.
> > >
> > > I think it will be cool regardless.   I'm actually feeling pretty
> dumb
> > > for not implementing this 3 years ago...it was way too easy to have
> > > not done it long ago.  it was a couple of extra methods and a few
> line
> > > changes in about 5 classes...  :-/
> > >
> > > Cheers,
> > > Clinton
> > >
> > > On 2/9/07, Poitras Christian <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >> I guess you have a point.
> > >>
> > >> Probably 90% of developpers won't want to know how the real path
> used...
> > >> Even if knowing it is interesting, it might disapoint people to
> force
> > >> them
> > >> to know it in advance.
> > >> In other cases, getters may include code that will be skipped using
> > >> direct
> > >> field access.
> > >>
> > >> Now the point to this email is that iBATIS didn't force people to
> have an
> > >> idea of the implementation before writting xml files. Changing this
> habit
> > >> may reduce the interest of iBATIS as a simple tool for O/R mapping.
>
> > >> Personally, I am afraid of the reactions some people will have when
> > >> they'll
> > >> begin mixing beans, pojos and maps (all 3 for crazy people only!,
> but
> > >> most
> > >> pojos/maps users).
> > >> Another problem will arise with resultMaps that will need this
> > >> notation at
> > >> the same time (to know if we call a setter or a use the field).
> > >>
> > >> I personally think it is to late to force people to change their
> iBATIS
> > >> habit. But make sure that they'll know what the framework will do.
> For
> > >> instance calling the getter if present, if not accessing the field
> > >> directly.
> > >>
> > >> Maybe the notation can be optionnal and will force iBATIS to try
> > >> accessing
> > >> the field first, then the getter if field is not present. Think
> this
> > >> would
> > >> do?
> > >>
> > >> Christian
> > >>
> > >>  
> > >>  From: [EMAIL PROTECTED]
> > >> [mailto:[EMAIL PROTECTED] On
> > >> Behalf Of Paul Benedict
> > >> Sent: Friday, 09 February 2007 15:17
> > >> To: dev@ibatis.apache.org
> > >> Subject: Re: Direct-to-Field mappings now implemented.
> > >>
> > >>
> > >> Poitras and Clinton,
> > >>
> > >> I agree. The refactoring argument is pretty strong. Property
> notation is
> > >> script-like because the actual means to get to the value (method
> vs.
> > >> direct-field access) is totally secondary to the intention. The
> developer
> > >> just needs to express the path, and the framework should be
> intelligent
> > >> enough to get there. But we can't assume the developer always wants
> > >> direct-field access, which is why the option must be turned on.
> > >>
> > >> PS: -1 on the brackets.
> > >>
> > >> Paul
> > >>
> > >
> >
>

Re: Direct-to-Field mappings now implemented.

[Brandon Goodin]

Just curious. Are we still honoring access privileges on fields or are we
doing an end around on them and setting regardless? I'm hoping we still
honor public, package, protected, private. Otherwise that can get
unpredictable.

Brandon

On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote:


Very well. In fact, the fallback to fields may turn out to be
advantageous. Let's see how it goes, as you said, and listen to the
feedback. Thanks Clinton!

Clinton Begin wrote:
> I think we need a stronger argument for a switch than "I might shoot
> myself in the foot".   :-)
>
> It's pretty simple to force methods to be called (write them) and to
> avoid fields from being loaded in odd cases (don't include them in the
> select clause).
>
> Let's give it some time the way it is, and if many people start
> finding unexpected results due to field mappings, then let's add a
> switch at that time.
>
> Cheers,
> Clinton

Re: Direct-to-Field mappings now implemented.

[Brandon Goodin]

Isn't that what constructors are for?

On 2/11/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


Absolutely not. :-)

Direct field mapping for the purposes of immutable classes or non-bean
types would be pointless.  So yes, we're completely ignoring private
on fields, setters, and constructors.

I don't see a problem with it...it's how it's done. We won't break
getter/setter encapsulation, because if the methods exists, we use
them.

Believe it or not, doing this allows people to build safer
applications.  JavaBeans are the real threat to encapsulation.  They
force us to have public mutators and a default constructor, both of
which can result in a class ending up in an inconsistent state.

So yes.  Our framework (like many) ignores access modifiers so that
programmers can actually USE access modifiers effectively.

How ironic.  ;-)

Clinton

On 2/10/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> Just curious. Are we still honoring access privileges on fields or are
we
> doing an end around on them and setting regardless? I'm hoping we still
> honor public, package, protected, private. Otherwise that can get
> unpredictable.
>
> Brandon
>
> On 2/10/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
> > Very well. In fact, the fallback to fields may turn out to be
> > advantageous. Let's see how it goes, as you said, and listen to the
> > feedback. Thanks Clinton!
> >
> > Clinton Begin wrote:
> > > I think we need a stronger argument for a switch than "I might shoot
> > > myself in the foot".   :-)
> > >
> > > It's pretty simple to force methods to be called (write them) and to
> > > avoid fields from being loaded in odd cases (don't include them in
the
> > > select clause).
> > >
> > > Let's give it some time the way it is, and if many people start
> > > finding unexpected results due to field mappings, then let's add a
> > > switch at that time.
> > >
> > > Cheers,
> > > Clinton
> >
>
>

Re: Direct-to-Field mappings now implemented.

[Brandon Goodin]

okay

On 2/11/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


Yes, you're absolutely right about that. Constructor injection is our
goal going forward.  It's quite a bit harder to implement than direct
field mapping, but I would like to see it.  I may look into it next
week.

Direct field is still important though, for people that don't buy into
constructor injection (why? I dunno!).  ;-)

Clinton

On 2/11/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> Isn't that what constructors are for?
>
>
> On 2/11/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> > Absolutely not. :-)
> >
> > Direct field mapping for the purposes of immutable classes or non-bean
> > types would be pointless.  So yes, we're completely ignoring private
> > on fields, setters, and constructors.
> >
> > I don't see a problem with it...it's how it's done. We won't break
> > getter/setter encapsulation, because if the methods exists, we use
> > them.
> >
> > Believe it or not, doing this allows people to build safer
> > applications.  JavaBeans are the real threat to encapsulation.  They
> > force us to have public mutators and a default constructor, both of
> > which can result in a class ending up in an inconsistent state.
> >
> > So yes.  Our framework (like many) ignores access modifiers so that
> > programmers can actually USE access modifiers effectively.
> >
> > How ironic.  ;-)
> >
> > Clinton
> >
> > On 2/10/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > > Just curious. Are we still honoring access privileges on fields or
are
> we
> > > doing an end around on them and setting regardless? I'm hoping we
still
> > > honor public, package, protected, private. Otherwise that can get
> > > unpredictable.
> > >
> > > Brandon
> > >
> > > On 2/10/07, Paul Benedict < [EMAIL PROTECTED]> wrote:
> > > > Very well. In fact, the fallback to fields may turn out to be
> > > > advantageous. Let's see how it goes, as you said, and listen to
the
> > > > feedback. Thanks Clinton!
> > > >
> > > > Clinton Begin wrote:
> > > > > I think we need a stronger argument for a switch than "I might
shoot
> > > > > myself in the foot".   :-)
> > > > >
> > > > > It's pretty simple to force methods to be called (write them)
and to
> > > > > avoid fields from being loaded in odd cases (don't include them
in
> the
> > > > > select clause).
> > > > >
> > > > > Let's give it some time the way it is, and if many people start
> > > > > finding unexpected results due to field mappings, then let's add
a
> > > > > switch at that time.
> > > > >
> > > > > Cheers,
> > > > > Clinton
> > > >
> > >
> > >
> >
>
>

Maven for Build?

[Brandon Goodin]

Hey Guys,

I wanted to throw a bone out to everyone and ask the question "Should we use
Maven for our build?". I put together a POM today that makes use of the
current iBATIS SQL Map structures. It is pretty darn simple and required
very little effort. The largest amount of my time was spent refactoring the
TestCL (Test Classloader) to use the current thread classloader as a parent
due to some incompatibilities with how Maven runs it's test. That aside, I
was surprised at how little effort it took to get the iBATIS SQLMap jar
built. Plus, Because of the dependency management of Maven I was able to
avoid having to use the oscache devsrc for oscache and avoid using the
devlib jars. I only used Maven to build the Data Mapper/SQL Map. I wasn't
familiar enough with Abator's build process to wire in Maven for it.

Benefits:

* I thought it would be good to aid in reducing the complexity of our
current build/deploy. If we want to provide our jars to the Maven crowd we
would be tasking the deploying member with taking the final jar built from
ant and running deploy:deploy-file for it. I have to say that I looked
through our release process and I really wouldn't want to add yet another
step. Seems like maven can consolidate this for us.
* We can run ant from within Maven if we so desire to continue performing
tasks that maven doesn't provide for.

Additional benefits, thoughts, or concerns?

Thanks,
Brandon

Re: Maven for Build?

[Brandon Goodin]

I can finish the pom that i have right now so that it mirrors the
functionality of the current ant script. It won't hurt anything to have the
pom in the repo.

Brandon

On 2/13/07, Jeff Butler <[EMAIL PROTECTED]> wrote:


I'm open to maven for the iBATIS build.  It would help a certain group of
our users to get iBATIS into the Maven repository.  Also - I don't think you
have to generate the site with maven, we could just use it for the build.

I've looked at it for Abator.  Abator doesn't have much of a dependancy
issue for the build (just needs a JRE and Ant), but the test phase is a
different story.  Abator testing is difficult because the tests are not so
much an Abator itself, but on the code that Abator generates.  So the build
looks like this:

1. Build the JAR
2. Run a few tests (only three or four right now)
3. Build a test DB
4. Generate code against the DB
5. Compile the generated code and also a set of tests against the
generated code
6. Run the tests on the generated code (several hundred)

The Abater build also behaves differently if you're running wuth JSE 5 or
not - there are more tests if you are using a Java 5 JDK.

The build.xml for Abator is more complex than I'd like because of all this
- so if Maven could help, then I'd be open to using for Abator too.

Jeff Butler



On 2/13/07, Larry Meadors <[EMAIL PROTECTED]> wrote:
>
> I like the idea - it makes the checkout faster, and "mvn idea:idea" is
> worth it's weight in gold, and our current build.xml is a bugger, I
> hate it.
>
> So, I wonder if we can skin the generated site to make it not look
> like crap^H^H^H^H every other maven generated site. :-)
>
> Larry
>
>
> On 2/12/07, Brandon Goodin < [EMAIL PROTECTED]> wrote:
> > Hey Guys,
> >
> > I wanted to throw a bone out to everyone and ask the question "Should
> we use
> > Maven for our build?". I put together a POM today that makes use of
> the
> > current iBATIS SQL Map structures. It is pretty darn simple and
> required
> > very little effort. The largest amount of my time was spent
> refactoring the
> > TestCL (Test Classloader) to use the current thread classloader as a
> parent
> > due to some incompatibilities with how Maven runs it's test. That
> aside, I
> > was surprised at how little effort it took to get the iBATIS SQLMap
> jar
> > built. Plus, Because of the dependency management of Maven I was able
> to
> > avoid having to use the oscache devsrc for oscache and avoid using the
> > devlib jars. I only used Maven to build the Data Mapper/SQL Map. I
> wasn't
> > familiar enough with Abator's build process to wire in Maven for it.
> >
> > Benefits:
> >
> > * I thought it would be good to aid in reducing the complexity of our
> > current build/deploy. If we want to provide our jars to the Maven
> crowd we
> > would be tasking the deploying member with taking the final jar built
> from
> > ant and running deploy:deploy-file for it. I have to say that I looked
> > through our release process and I really wouldn't want to add yet
> another
> > step. Seems like maven can consolidate this for us.
> > * We can run ant from within Maven if we so desire to continue
> performing
> > tasks that maven doesn't provide for.
> >
> > Additional benefits, thoughts, or concerns?
> >
> > Thanks,
> > Brandon
> >
>

Re: Maven for Build?

[Brandon Goodin]

Thanks all for the feedback,

I think there is a bit of hostility here. It was probably flamed by Larry's
hate comments earlier. We can all forgive each other can't we and keep
loving?

To address some of the points:

RE: internet connectivity...
If you don't have an internet connection then you are in a sad sad sad state
and i'd like to know how you got ahold of ibatis in the first place.

RE: self contained build
I believe that self contained build are overrated as well. As long as you
have the jars (which maven will download for you). Then you are golden. It's
really quite simple.

RE: site generation
I'm fine with our current site. Are we using ant in our build to create it?
If not, then it's a non-issue cuz i'm not advocating maven being site
generator.

Anyway, let me suggest that you guys let me write the pom and we'll see if
all the unnecessary anger and hype is really worth the raise in blood
pressure.

Brandon Goodin

On 2/13/07, Larry Meadors <[EMAIL PROTECTED]> wrote:


No, you can do off-line builds with maven.

mvn -o install

Larry


On 2/13/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:
> My preference for a build to be self-contained and not to require
> to go out to run.
>
>
> Using Maven will prevent those having no Internet connection
> from building iBATIS.
>
> Regards,
>
> Slava Imeshev
> www.viewtier.com
>
>
> - Original Message -
> From: "Brandon Goodin" <[EMAIL PROTECTED]>
> To: 
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 13, 2007 9:16 AM
> Subject: Re: Maven for Build?
>
>
> > I can finish the pom that i have right now so that it mirrors the
> > functionality of the current ant script. It won't hurt anything to
have the
> > pom in the repo.
> >
> > Brandon
> >
> > On 2/13/07, Jeff Butler <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm open to maven for the iBATIS build.  It would help a certain
group of
> > > our users to get iBATIS into the Maven repository.  Also - I don't
think you
> > > have to generate the site with maven, we could just use it for the
build.
> > >
> > > I've looked at it for Abator.  Abator doesn't have much of a
dependancy
> > > issue for the build (just needs a JRE and Ant), but the test phase
is a
> > > different story.  Abator testing is difficult because the tests are
not so
> > > much an Abator itself, but on the code that Abator generates.  So
the build
> > > looks like this:
> > >
> > > 1. Build the JAR
> > > 2. Run a few tests (only three or four right now)
> > > 3. Build a test DB
> > > 4. Generate code against the DB
> > > 5. Compile the generated code and also a set of tests against the
> > > generated code
> > > 6. Run the tests on the generated code (several hundred)
> > >
> > > The Abater build also behaves differently if you're running wuth JSE
5 or
> > > not - there are more tests if you are using a Java 5 JDK.
> > >
> > > The build.xml for Abator is more complex than I'd like because of
all this
> > > - so if Maven could help, then I'd be open to using for Abator too.
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 2/13/07, Larry Meadors <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I like the idea - it makes the checkout faster, and "mvn
idea:idea" is
> > > > worth it's weight in gold, and our current build.xml is a bugger,
I
> > > > hate it.
> > > >
> > > > So, I wonder if we can skin the generated site to make it not look
> > > > like crap^H^H^H^H every other maven generated site. :-)
> > > >
> > > > Larry
> > > >
> > > >
> > > > On 2/12/07, Brandon Goodin < [EMAIL PROTECTED]> wrote:
> > > > > Hey Guys,
> > > > >
> > > > > I wanted to throw a bone out to everyone and ask the question
"Should
> > > > we use
> > > > > Maven for our build?". I put together a POM today that makes use
of
> > > > the
> > > > > current iBATIS SQL Map structures. It is pretty darn simple and
> > > > required
> > > > > very little effort. The largest amount of my time was spent
> > > > refactoring the
> > > > > TestCL (Test Classloader) to use the current thread classloader
as a
> > > > parent
> > > > > due to some incompatibilities with how Maven runs it's test.
That
> > > > aside, I
> &

Re: Maven for Build?

[Brandon Goodin]

you CAN CAN CAN CAN CAN build offline when in a car, or on a plane, when at
your home, or on a lome, when in a humjick, or on lumberjack. It is still
possible to build offline with maven.

We install programs every day that help us be more productive. Maven is just
that. Once you install it. iBATIS like many many many other projects will
build with a click.

I'm sure there are plenty of tools that you use that aren't one-click. You
are exaggerating. If you cared that much about it you wouldn't be on
Windows. ;-)

Brandon

On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


>>I think there is a bit of hostility here.

I don't sense any hostility...just strong opinions.

>>  If you don't have an internet connection then you are in a sad sad sad
state

Except for those who like to work with or on our framework while on an
airplane...or a bus or a trainlaptops are great things.
Unfortunately wireless networks are not yet ubiquitous.  Not everyone
works from home.  :-)

>> I believe that self contained build are overrated as well.

Completely disagree.  When I can't build it with one click, I generally
toss it.

>> all the unnecessary anger

There's no anger man.  Just constructive debate.  I hope we never
start to sound like those chipmunks on the Bugs Bunny show"No no
no...you're the wonderful one."  :-)

Clinton



On 2/13/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> Thanks all for the feedback,
>
> I think there is a bit of hostility here. It was probably flamed by
Larry's
> hate comments earlier. We can all forgive each other can't we and keep
> loving?
>
> To address some of the points:
>
> RE: internet connectivity...
> If you don't have an internet connection then you are in a sad sad sad
state
> and i'd like to know how you got ahold of ibatis in the first place.
>
> RE: self contained build
> I believe that self contained build are overrated as well. As long as
you
> have the jars (which maven will download for you). Then you are golden.
It's
> really quite simple.
>
> RE: site generation
> I'm fine with our current site. Are we using ant in our build to create
it?
> If not, then it's a non-issue cuz i'm not advocating maven being site
> generator.
>
> Anyway, let me suggest that you guys let me write the pom and we'll see
if
> all the unnecessary anger and hype is really worth the raise in blood
> pressure.
>
> Brandon Goodin
>
>
>  On 2/13/07, Larry Meadors <[EMAIL PROTECTED]> wrote:
> > No, you can do off-line builds with maven.
> >
> > mvn -o install
> >
> > Larry
> >
> >
> > On 2/13/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:
> > > My preference for a build to be self-contained and not to require
> > > to go out to run.
> > >
> > >
> > > Using Maven will prevent those having no Internet connection
> > > from building iBATIS.
> > >
> > > Regards,
> > >
> > > Slava Imeshev
> > > www.viewtier.com
> > >
> > >
> > > - Original Message -
> > > From: "Brandon Goodin" <[EMAIL PROTECTED]>
> > > To: < dev@ibatis.apache.org>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, February 13, 2007 9:16 AM
> > > Subject: Re: Maven for Build?
> > >
> > >
> > > > I can finish the pom that i have right now so that it mirrors the
> > > > functionality of the current ant script. It won't hurt anything to
> have the
> > > > pom in the repo.
> > > >
> > > > Brandon
> > > >
> > > > On 2/13/07, Jeff Butler < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I'm open to maven for the iBATIS build.  It would help a certain
> group of
> > > > > our users to get iBATIS into the Maven repository.  Also - I
don't
> think you
> > > > > have to generate the site with maven, we could just use it for
the
> build.
> > > > >
> > > > > I've looked at it for Abator.  Abator doesn't have much of a
> dependancy
> > > > > issue for the build (just needs a JRE and Ant), but the test
phase
> is a
> > > > > different story.  Abator testing is difficult because the tests
are
> not so
> > > > > much an Abator itself, but on the code that Abator
generates.  So
> the build
> > > > > looks like this:
> > > > >
> > > > > 1. Build the JAR
> > > > > 2. Run a few tests (only three or four right now)
> > >

Re: Maven for Build?

[Brandon Goodin]

I just have to ask if any of you have actually used maven or is this just a
"fear somethign different debate"? If you have questions about whether Maven
can do something then ask a question rather than plant assertions that are
not accurate.

Brandon

On 2/13/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:



> RE: internet connectivity...
> If you don't have an internet connection then you are in a sad sad state
> and i'd like to know how you got ahold of ibatis in the first place.

Not allowing people using iBATIS will slow its adoption.

You may work in a strict security environment that prohibits
certain connections. Fetching something from outside may
be disastrous in such environments.

> RE: self contained build
> I believe that self contained build are overrated as well. As long as
you
> have the jars (which maven will download for you). Then you are golden.

Actually, no. Basic change management requires knowing what
makes your product.


> Anyway, let me suggest that you guys let me write the pom and we'll see
if
> all the unnecessary anger and hype is really worth the raise in blood
> pressure.

Boredom shouldn't drive technology decisions, common sense should.

In any case, Viewtier will continue running Continuous Integration
for iBATIS. Just let me know if there are changes:

http://parabuild.viewtier.com:8080/parabuild/index.htm?displaygroupid=7


Regards,

Slava Imeshev
www.viewtier.com

Re: svn commit: r507187 - in /ibatis/trunk/java/mapper/mapper2: ./ tools/

[Brandon Goodin]

It's an ignore not a checkin.

On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


Ewwwso why do we have to check in our IDE project files?  Is that
a Maven requirement?  Any alternative?  Is there a Maven ant:ant?

Clinton

On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: bgoodin
> Date: Tue Feb 13 11:55:34 2007
> New Revision: 507187
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=507187
> Log:
> Added ingores for IDEA project files and mavent target directory
>
> Modified:
> ibatis/trunk/java/mapper/mapper2/   (props changed)
> ibatis/trunk/java/mapper/mapper2/tools/   (props changed)
>
> Propchange: ibatis/trunk/java/mapper/mapper2/
>
--
> --- svn:ignore (original)
> +++ svn:ignore Tue Feb 13 11:55:34 2007
> @@ -6,3 +6,8 @@
>  bin
>  classes
>  ibderby
> +target
> +*.iml
> +*.ipr
> +*.iws
> +derby.log
>
> Propchange: ibatis/trunk/java/mapper/mapper2/tools/
>
--
> --- svn:ignore (added)
> +++ svn:ignore Tue Feb 13 11:55:34 2007
> @@ -0,0 +1 @@
> +*.iml
>
>
>

Re: svn commit: r507187 - in /ibatis/trunk/java/mapper/mapper2: ./ tools/

[Brandon Goodin]

That cake is sounding really good.

On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


OOOH sorry.  My bad.  :-)

On 2/13/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> It's an ignore not a checkin.
>
>
> On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> > Ewwwso why do we have to check in our IDE project files?  Is that
> > a Maven requirement?  Any alternative?  Is there a Maven ant:ant?
> >
> > Clinton
> >
> > On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Author: bgoodin
> > > Date: Tue Feb 13 11:55:34 2007
> > > New Revision: 507187
> > >
> > > URL: http://svn.apache.org/viewvc?view=rev&rev=507187
> > > Log:
> > > Added ingores for IDEA project files and mavent target directory
> > >
> > > Modified:
> > > ibatis/trunk/java/mapper/mapper2/   (props changed)
> > > ibatis/trunk/java/mapper/mapper2/tools/   (props
> changed)
> > >
> > > Propchange: ibatis/trunk/java/mapper/mapper2/
> > >
>
--
> > > --- svn:ignore (original)
> > > +++ svn:ignore Tue Feb 13 11:55:34 2007
> > > @@ -6,3 +6,8 @@
> > >  bin
> > >  classes
> > >  ibderby
> > > +target
> > > +*.iml
> > > +*.ipr
> > > +*.iws
> > > +derby.log
> > >
> > > Propchange: ibatis/trunk/java/mapper/mapper2/tools/
> > >
>
--
> > > --- svn:ignore (added)
> > > +++ svn:ignore Tue Feb 13 11:55:34 2007
> > > @@ -0,0 +1 @@
> > > +*.iml
> > >
> > >
> > >
> >
>
>

Re: Maven for Build?

[Brandon Goodin]

Thanks for the info Ted.

Brandon

On 2/13/07, Ted Husted <[EMAIL PROTECTED]> wrote:


On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> > With the Struts releases, we also include all the JARs needed to build
> > the product, which people can install locally.
>
> That would be perfect!

Feel free to steal from what Wendy setup for us. It's mostly a
blackbox to me. I know where to put the release versions, list the
dependencies, how to run "mvn install", but that's nearly the extent
of my Maven knowledge -- and I've been the release manager of late :)

-Ted.

Parabuild failure

[Brandon Goodin]

Don't worry about the build failure. It was due to the fact that I didn't
commit all my code at one time.

Brandon

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

"Can we get the iBATIS jars to the maven repository without doing a maven
build?"

Yes

On 2/14/07, Jeff Butler <[EMAIL PROTECTED]> wrote:


In my own little perfect world, I'm -1.  The iBATIS ant build is so
simple now - I hate to see it mucked up just to supply the Maven meta-bs as
Clinton so eloquently put it.

However, I would like to see the iBATIS jars in the Maven repository - if
for no other reason than to help those who can't figure out how to set a
classpath without a tool.  If a maven build makes that possible then I guess
I'd be +2, but reluctantly.

I think that supporting both Ant and Maven is problematical - seems like
we should just pick one for simplicity going forward.

So I guess I can't give a single vote.  Can someone definitively answer
this question:  Can we get the iBATIS jars to the maven repository without
doing a maven build?  That's the key point for me.

Jeff Butler



On 2/14/07, Clinton Begin <[EMAIL PROTECTED] > wrote:
>
> Hi all,
>
> It strikes me that there was enough discussion around the Maven build
> to warrant an official vote for Maven support.
>
> +2 => Replace our Ant build entirely with a Maven build.
>
> +1  => Support Maven by including a Maven build alongside our Ant build.
>
> 0 => Don't care or I don't know enough about Maven to decide.
>
> -1 => Do not support maven.
>
> Cheers,
> Clinton
>

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

I think this is a bit premature. My intention was to show a working
comparison so that this decision could be made in an informed manner.

Brandon

On 2/14/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


Hi all,

It strikes me that there was enough discussion around the Maven build
to warrant an official vote for Maven support.

+2 => Replace our Ant build entirely with a Maven build.

+1  => Support Maven by including a Maven build alongside our Ant build.

0 => Don't care or I don't know enough about Maven to decide.

-1 => Do not support maven.

Cheers,
Clinton

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

Currently, if we want to publish the jars to the maven repo the release
manager would need to make sure the current pom.xml compiles and runs all
tests successfully with "mvn clean install". You'd run the normal ant build
as well to generate the jar we want to deploy to a maven repository. Then we
would run a "mvn deploy:deploy-file" and provide all the necessary
parameters, which would include the pom to insure our dependency information
is correct. (
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html).
This would create the needed structures/meta for the jars to function
appropriately in the maven repo.

If we are using maven for the whole build then it would require mvn
deploy:deploy .

After each of these process you would scp the results to the
people.apache.org:/x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository.
It is also possible to have both of these automatically copy to the
people.apache.org location.

Brandon

On 2/14/07, Jeff Butler <[EMAIL PROTECTED] > wrote:


Yes - I should have asked that question with more subtlety.  I guess the
bottom line is that it is *possible* to get the jars to the repository
without doing a maven build, but doing a maven build makes it much easier to
publish to the repository.  And our history shows that we are unlikely to
get the jars to the repository with the build process we are using now.
Right?

Jeff



On 2/14/07, Larry Meadors <[EMAIL PROTECTED] > wrote:
>
> IMO, that is like "Can we clean a toilet with a toothbrush?"
>
> Yes, we can, but who wants to offer up their toothbrush? Not me! :-)
>
> The question to me is:
>
> "Can we get the iBATIS jars to the maven repository without doing a
> maven build, and is it the right way to do it?"
>
> Yes we can, but no it's not.
>
> Larry
>
>
> On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > "Can we get the iBATIS jars to the maven repository without doing a
> maven
> > build?"
> >
> > Yes
> >
> >
> > On 2/14/07, Jeff Butler < [EMAIL PROTECTED]> wrote:
> > >
> > > In my own little perfect world, I'm -1.  The iBATIS ant build is so
> simple
> > now - I hate to see it mucked up just to supply the Maven meta-bs as
> Clinton
> > so eloquently put it.
> > >
> > > However, I would like to see the iBATIS jars in the Maven repository
> - if
> > for no other reason than to help those who can't figure out how to set
> a
> > classpath without a tool.  If a maven build makes that possible then I
> guess
> > I'd be +2, but reluctantly.
> > >
> > > I think that supporting both Ant and Maven is problematical - seems
> like
> > we should just pick one for simplicity going forward.
> > >
> > > So I guess I can't give a single vote.  Can someone definitively
> answer
> > this question:  Can we get the iBATIS jars to the maven repository
> without
> > doing a maven build?  That's the key point for me.
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 2/14/07, Clinton Begin < [EMAIL PROTECTED] > wrote:
> > >
> > > > Hi all,
> > > >
> > > > It strikes me that there was enough discussion around the Maven
> build
> > > > to warrant an official vote for Maven support.
> > > >
> > > > +2 => Replace our Ant build entirely with a Maven build.
> > > >
> > > > +1  => Support Maven by including a Maven build alongside our Ant
> build.
> > > >
> > > > 0 => Don't care or I don't know enough about Maven to decide.
> > > >
> > > > -1 => Do not support maven.
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > >
> > >
> >
> >
>

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

The broader purpose of this is not just to see if we can get jars into maven
but rather to see if maven can simplify our build/release process. If you
have a one liner then that is great. I'd love to see it.

Brandon

On 2/14/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:


I seriously doubt that this would require switching to Maven
build.

I cannot speak for a global catalog, but adding an item built
with Ant to a local Maven repository is a one-liner.

Regards,

Slava Imeshev

- Original Message -
From: "Jeff Butler" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Wednesday, February 14, 2007 10:09 AM
Subject: Re: [VOTE] Support for Maven (impacts Java version only)


> Yes - I should have asked that question with more subtlety.  I guess the
> bottom line is that it is *possible* to get the jars to the repository
> without doing a maven build, but doing a maven build makes it much
easier to
> publish to the repository.  And our history shows that we are unlikely
to
> get the jars to the repository with the build process we are using now.
> Right?
>
> Jeff
>
>
>
> On 2/14/07, Larry Meadors <[EMAIL PROTECTED]> wrote:
> >
> > IMO, that is like "Can we clean a toilet with a toothbrush?"
> >
> > Yes, we can, but who wants to offer up their toothbrush? Not me! :-)
> >
> > The question to me is:
> >
> > "Can we get the iBATIS jars to the maven repository without doing a
> > maven build, and is it the right way to do it?"
> >
> > Yes we can, but no it's not.
> >
> > Larry
> >
> >
> > On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > > "Can we get the iBATIS jars to the maven repository without doing a
> > maven
> > > build?"
> > >
> > > Yes
> > >
> > >
> > > On 2/14/07, Jeff Butler < [EMAIL PROTECTED]> wrote:
> > > >
> > > > In my own little perfect world, I'm -1.  The iBATIS ant build is
so
> > simple
> > > now - I hate to see it mucked up just to supply the Maven meta-bs as
> > Clinton
> > > so eloquently put it.
> > > >
> > > > However, I would like to see the iBATIS jars in the Maven
repository -
> > if
> > > for no other reason than to help those who can't figure out how to
set a
> > > classpath without a tool.  If a maven build makes that possible then
I
> > guess
> > > I'd be +2, but reluctantly.
> > > >
> > > > I think that supporting both Ant and Maven is problematical -
seems
> > like
> > > we should just pick one for simplicity going forward.
> > > >
> > > > So I guess I can't give a single vote.  Can someone definitively
> > answer
> > > this question:  Can we get the iBATIS jars to the maven repository
> > without
> > > doing a maven build?  That's the key point for me.
> > > >
> > > > Jeff Butler
> > > >
> > > >
> > > >
> > > > On 2/14/07, Clinton Begin < [EMAIL PROTECTED] > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > It strikes me that there was enough discussion around the Maven
> > build
> > > > > to warrant an official vote for Maven support.
> > > > >
> > > > > +2 => Replace our Ant build entirely with a Maven build.
> > > > >
> > > > > +1  => Support Maven by including a Maven build alongside our
Ant
> > build.
> > > > >
> > > > > 0 => Don't care or I don't know enough about Maven to decide.
> > > > >
> > > > > -1 => Do not support maven.
> > > > >
> > > > > Cheers,
> > > > > Clinton
> > > > >
> > > >
> > > >
> > >
> > >
> >
>

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

"We don't require a shell script now."

True. I used the ant script from IDEA the other day because i got tired of
fiddling around with the shell script. I didn't go too deep. But I was
having problems getting it running on the mac. Likely something i didn't
have configured right.

The nice thing about Maven is that it handles all the runtime
loading/downloading of plugins that it requires to operate based upon the
pom. So, in the end we can have shell scripts to make the builds one click
builds, but we won't have to worry about setting up classpaths for it in the
scripts.

If you want you can download the latest maven 2 (
http://maven.apache.org/download.html). Follow the simple setup at the
bottom of that page. Then update to the latest ibatis and run 'mvn clean
install' from the command line of the project root. See how it goes. That
command will build the ibatis jar and run the unit tests.

Brandon

On 2/14/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


We don't require a shell script now.  The .bat and .sh files are
optional.  You're perfectly welcome to install Ant separately (like
you will have to with Maven) and just call ant from within the /build
directory.

Clinton

On 2/14/07, Nathan Maves <[EMAIL PROTECTED]> wrote:
> +1 and my vote counts!
>
> Speaking from personal experience I have wanted to move to a new build
tool
> for a while.  While most of you will pay though the nose for the latest
M$
> Vista, I run on unix machine.  The use of shell scripts for build
purposes
> is not a good xplatform solution.
>
> Just from a quick glance Maven seems to make somewhat time consuming
tasks
> in Ant easy.
>
> Lets do this.
>
> Nathan
>
>
> On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > The broader purpose of this is not just to see if we can get jars into
> maven but rather to see if maven can simplify our build/release process.
If
> you have a one liner then that is great. I'd love to see it.
> >
> > Brandon
> >
> >
> >
> > On 2/14/07, Slava Imeshev < [EMAIL PROTECTED]> wrote:
> > > I seriously doubt that this would require switching to Maven
> > > build.
> > >
> > > I cannot speak for a global catalog, but adding an item built
> > > with Ant to a local Maven repository is a one-liner.
> > >
> > > Regards,
> > >
> > > Slava Imeshev
> > >
> > > - Original Message -
> > > From: "Jeff Butler" <[EMAIL PROTECTED]>
> > > To: < dev@ibatis.apache.org>; < [EMAIL PROTECTED]>
> > > Sent: Wednesday, February 14, 2007 10:09 AM
> > > Subject: Re: [VOTE] Support for Maven (impacts Java version only)
> > >
> > >
> > > > Yes - I should have asked that question with more subtlety.  I
guess
> the
> > > > bottom line is that it is *possible* to get the jars to the
repository
> > > > without doing a maven build, but doing a maven build makes it much
> easier to
> > > > publish to the repository.  And our history shows that we are
unlikely
> to
> > > > get the jars to the repository with the build process we are using
> now.
> > > > Right?
> > > >
> > > > Jeff
> > > >
> > > >
> > > >
> > > > On 2/14/07, Larry Meadors < [EMAIL PROTECTED] > wrote:
> > > > >
> > > > > IMO, that is like "Can we clean a toilet with a toothbrush?"
> > > > >
> > > > > Yes, we can, but who wants to offer up their toothbrush? Not me!
:-)
> > > > >
> > > > > The question to me is:
> > > > >
> > > > > "Can we get the iBATIS jars to the maven repository without
doing a
> > > > > maven build, and is it the right way to do it?"
> > > > >
> > > > > Yes we can, but no it's not.
> > > > >
> > > > > Larry
> > > > >
> > > > >
> > > > > On 2/14/07, Brandon Goodin <[EMAIL PROTECTED] > wrote:
> > > > > > "Can we get the iBATIS jars to the maven repository without
doing
> a
> > > > > maven
> > > > > > build?"
> > > > > >
> > > > > > Yes
> > > > > >
> > > > > >
> > > > > > On 2/14/07, Jeff Butler < [EMAIL PROTECTED] > wrote:
> > > > > > >
> > > > > > > In my own little perfect world, I'm -1.  The iBATIS ant
build is
> so
> > > > > simple
> > 

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

I think i would echo Jeff's sentiment and hold to one or the other.

As far as integration. Both IDEA and Netbeans have excellent Maven 2
support.

IDEA has the Maven 2 Integration plugin that is installable from their
Plugins setting.
Netbeans has mevenide which allows you to open POMs as a project in the same
manner as it does ant (http://mevenide.codehaus.org/m2-site/index.html).
Altough, I'm not a fan of Netbeans (at all), I have had to use it on a
recent project and have found the Maven 2 integration works great.
Eclipse has support for Maven 2 as well (http://m2eclipse.codehaus.org/)
although i haven't used it.

Brandon

On 2/14/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


If that's the case, would it make sense to use Ant for build and Maven
for deploy?

One thing I'll miss with Maven is the tool integration.  I imagine I
could get a Maven plugin for IDEA and Eclipse, but Ant is ubiquitous
and works with a lot of other tools.

At least I know Continuum works with Maven!  Continuum* rocks.

Clinton

* We're using Parabuild strictly because the company set it up for us
and is willing to host it for us.

On 2/14/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> Maybe a one-liner to deploy the JAR to a local repository, but to
> ready the JARs for public distribution, we also need to sign them and
> such. You can do everything that's needed by hand, without Maven, but
> it can be a lot of work.
>
> Even at Struts, we don't have the complete Maven build and deploy down
> to a one-liner yet. A key bottleneck is that signing the JARs should
> not be a fully automatic process, since its not a good idea to embed a
> passphrase in a script. So, it's more like three steps: build, sign,
> deploy.  But, the same should be true of Ant, if we are being careful
> about signing.
>
> -Ted.
>
> On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > The broader purpose of this is not just to see if we can get jars into
maven
> > but rather to see if maven can simplify our build/release process. If
you
> > have a one liner then that is great. I'd love to see it.
> >
> > Brandon
> >
> >
> > On 2/14/07, Slava Imeshev <[EMAIL PROTECTED]> wrote:
> > > I seriously doubt that this would require switching to Maven
> > > build.
> > >
> > > I cannot speak for a global catalog, but adding an item built
> > > with Ant to a local Maven repository is a one-liner.
> > >
> > > Regards,
> > >
> > > Slava Imeshev
>

Re: [VOTE] Support for Maven (impacts Java version only)

[Brandon Goodin]

My original statement was that IDEA ran fine. I was just goofing something
on the Ant build.sh... not sure what. It wasn't a big deal because IDEA ran
it fine.

Brandon

On 2/15/07, Clinton Begin <[EMAIL PROTECTED]> wrote:


In IDEA, right click on the Ant build file in the Ant sidebar.  Choose
Properties.  Choose the Additional Classpath Tab.  Select Add All In
Directory, choose the devlib directory.

For command line, just dump all the devlib jars into your ant/lib folder.

That will ensure all dependencies are met for the Ant plugins (just
JUnit, Optional, and JDK tools).

Clinton

On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> "We don't require a shell script now."
>
> True. I used the ant script from IDEA the other day because i got tired
of
> fiddling around with the shell script. I didn't go too deep. But I was
> having problems getting it running on the mac. Likely something i didn't
> have configured right.
>
> The nice thing about Maven is that it handles all the runtime
> loading/downloading of plugins that it requires to operate based upon
the
> pom. So, in the end we can have shell scripts to make the builds one
click
> builds, but we won't have to worry about setting up classpaths for it in
the
> scripts.
>
> If you want you can download the latest maven 2
> (http://maven.apache.org/download.html). Follow the simple
> setup at the bottom of that page. Then update to the latest ibatis and
run
> 'mvn clean install' from the command line of the project root. See how
it
> goes. That command will build the ibatis jar and run the unit tests.
>
> Brandon
>
>
> On 2/14/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> > We don't require a shell script now.  The .bat and .sh files are
> > optional.  You're perfectly welcome to install Ant separately (like
> > you will have to with Maven) and just call ant from within the /build
> > directory.
> >
> > Clinton
> >
> > On 2/14/07, Nathan Maves <[EMAIL PROTECTED]> wrote:
> > > +1 and my vote counts!
> > >
> > > Speaking from personal experience I have wanted to move to a new
build
> tool
> > > for a while.  While most of you will pay though the nose for the
latest
> M$
> > > Vista, I run on unix machine.  The use of shell scripts for build
> purposes
> > > is not a good xplatform solution.
> > >
> > > Just from a quick glance Maven seems to make somewhat time consuming
> tasks
> > > in Ant easy.
> > >
> > > Lets do this.
> > >
> > > Nathan
> > >
> > >
> > > On 2/14/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > > > The broader purpose of this is not just to see if we can get jars
into
> > > maven but rather to see if maven can simplify our build/release
process.
> If
> > > you have a one liner then that is great. I'd love to see it.
> > > >
> > > > Brandon
> > > >
> > > >
> > > >
> > > > On 2/14/07, Slava Imeshev < [EMAIL PROTECTED]> wrote:
> > > > > I seriously doubt that this would require switching to Maven
> > > > > build.
> > > > >
> > > > > I cannot speak for a global catalog, but adding an item built
> > > > > with Ant to a local Maven repository is a one-liner.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Slava Imeshev
> > > > >
> > > > > - Original Message -
> > > > > From: "Jeff Butler" <[EMAIL PROTECTED]>
> > > > > To: < dev@ibatis.apache.org>; < [EMAIL PROTECTED]>
> > > > > Sent: Wednesday, February 14, 2007 10:09 AM
> > > > > Subject: Re: [VOTE] Support for Maven (impacts Java version
only)
> > > > >
> > > > >
> > > > > > Yes - I should have asked that question with more subtlety.  I
> guess
> > > the
> > > > > > bottom line is that it is *possible* to get the jars to the
> repository
> > > > > > without doing a maven build, but doing a maven build makes it
much
> > > easier to
> > > > > > publish to the repository.  And our history shows that we are
> unlikely
> > > to
> > > > > > get the jars to the repository with the build process we are
using
> > > now.
> > > > > > Right?
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > >
> > > > > >

Re: iBATIS for Java 2.3.0 General Availability

[Brandon Goodin]

This is very interesting and I'd like to know more about why this number is
important apart from other things like a
major.minor.revision.timestampformat. I'm not really picking up the
importance from the previous comments.
Here is my understanding, help me to clear the fog out... The serial is used
to identify a unique build. This unique build is important for tracing back
to what? If we do not have an anchor in our source code repository to
compare it to what good does it do us?

Brandon

On 2/17/07, Clinton Begin <[EMAIL PROTECTED]> wrote:



Paul,

I disagree entirely.

Open any product on your PC today, Java IDE, Visual Studio...anything.  It
will have a build number.  Not just software really, any and every product
on the planet has a serial number.  They are useful for uniquely identifying
something. The major.minor.bug release version is very subjective and we
tend to manipulate it that way.  The build number is automated and therefore
more reliable as a unique ID for the software version.

I agree about the disconnect with SVN in the past.  What we typically do
on commercial projects is have the CI server automatically create a tag for
the build in SVN. That solves the disconnect issue.  iBATIS hasn't had a CI
server until recently, so the tagging was manual.  Now we do have a CI
server and can automate the relationship one way or another (either tag SVN
with the build number or pul the rev number from SVN and tag the build with
that).

It's important to me and easy to produce.  So regardless of what build
system we use, I'd like to ensure that a build number is represented on the
deployable ZIP filename, the JAR file names the manifest file and the
release.txt.

Clinton


On 2/17/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
>
> I am responding on the dev list too :-) There's two things going on:
>
> 1) An automated build numbering -- and any build numbering for that
> matter -- isn't needed for official distributions. All you need is the
> X.Y.Z scheme where X=major,Y=minor,Z=revision versions.
>
> 2) You are actually using the build numbering to track your snapshots.
> That's what the build number is really for. When you use maven and
> attach -SNAPSHOT suffix to the version number, the libraries get
> deployed to the snapshot repository with an automated build number.
>
> So two things to remember: build numbers are for development
> distributions only. The build number will be updated for every snapshot
> distribution. Once you're ready to attempt an official release, remove
> -SNAPSHOT and then you have the next X.Y.Z version.
>
> Paul
>
> Clinton Begin wrote:
> > The build number is very important...it's the only automated serial
> > number we have.
> >
> > It doesn't matter to me where that number comes from.  SVN rev number
> is
> > an excellent suggestion.  But I don't want to downplay the importance
> of
> > an automated serial number.
> >
> > I agree with Jeff's point, that there shouldn't be two releases with
> the
> > same version but different build numbers, and we never have.
> >
> > Perhaps a new Ant/Maven task that grabs the revision from the current
> > working copy (because that's actually what you're building), but the
> > task should also check that there are no modifications...it's a bit
> > tricky to get it right actually.  The alternative would be a "fresh
> > build" task that would do a full checkout from SVN, note the rev
> number
> > and then build from there.  Which is actually decent.
> >
> > So to summarize, yes it's important and yes it could be more
> meaningful
> > by using the SVN rev number -- and it has to be automated.
> >
> > Cheers,
> > Clinton
> >
> > On 2/17/07, *Jeff Butler* <[EMAIL PROTECTED]
> > > wrote:
> >
> > I agree that the build number is useless.  Apache policy says that
> > there are not different versions of a release.  So we really
> > shouldn't have 2.3.0-638 and 2.3.0-677, we only have one 2.3.0
> > release (we've only broken that rule one time that I remember).
> >
> > I kind of like the way Derby does it.  The download is just
> > Derby10.2.2.0, and they add the SVN revision number in the
> manifest
> > Bundle-Version property (e.g. 10.2.200.485682).  I haven't
> > looked at their build to see how they get the SVN number into the
> > manifest - hopefully it's not a manual hack.
> >
> > I'd like to keep the version number on the name of the JAR file
> like
> > we're doing now (ibatis-2.3.0.jar) - just lose the build number.
> >
> > Jeff Butler
> >
> > On 2/17/07, *Larry Meadors* < [EMAIL PROTECTED]
> > > wrote:
> >
> > OK, as I am digging through this, I see that we have this
> "build
> > number" thing on the download.
> >
> > I am wondering if we should change it to make that number have
> > some more value.
> >
> > What I mean is: "What does ' ibatis-2.3.0.677.zip' really tell
> me
> >   

Re: iBATIS for Java 2.3.0 General Availability

[Brandon Goodin]

I talked to larry and he floated his idea on this. My main thought about the
build number was that it has to tie meaningfully back to the source state.
Larry's idea does that perfectly... rawk.

Thanks,
Brandon

On 2/17/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:


This is very interesting and I'd like to know more about why this number
is important apart from other things like a 
major.minor.revision.timestampformat. I'm not really picking up the importance 
from the previous comments.
Here is my understanding, help me to clear the fog out... The serial is used
to identify a unique build. This unique build is important for tracing back
to what? If we do not have an anchor in our source code repository to
compare it to what good does it do us?

Brandon

On 2/17/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
>
> Paul,
>
> I disagree entirely.
>
> Open any product on your PC today, Java IDE, Visual Studio...anything.
> It will have a build number.  Not just software really, any and every
> product on the planet has a serial number.  They are useful for uniquely
> identifying something. The major.minor.bug release version is very
> subjective and we tend to manipulate it that way.  The build number is
> automated and therefore more reliable as a unique ID for the software
> version.
>
> I agree about the disconnect with SVN in the past.  What we typically do
> on commercial projects is have the CI server automatically create a tag for
> the build in SVN. That solves the disconnect issue.  iBATIS hasn't had a CI
> server until recently, so the tagging was manual.  Now we do have a CI
> server and can automate the relationship one way or another (either tag SVN
> with the build number or pul the rev number from SVN and tag the build with
> that).
>
> It's important to me and easy to produce.  So regardless of what build
> system we use, I'd like to ensure that a build number is represented on the
> deployable ZIP filename, the JAR file names the manifest file and the
> release.txt.
>
> Clinton
>
>
> On 2/17/07, Paul Benedict < [EMAIL PROTECTED]> wrote:
> >
> > I am responding on the dev list too :-) There's two things going on:
> >
> > 1) An automated build numbering -- and any build numbering for that
> > matter -- isn't needed for official distributions. All you need is the
> >
> > X.Y.Z scheme where X=major,Y=minor,Z=revision versions.
> >
> > 2) You are actually using the build numbering to track your snapshots.
> > That's what the build number is really for. When you use maven and
> > attach -SNAPSHOT suffix to the version number, the libraries get
> > deployed to the snapshot repository with an automated build number.
> >
> > So two things to remember: build numbers are for development
> > distributions only. The build number will be updated for every
> > snapshot
> > distribution. Once you're ready to attempt an official release, remove
> >
> > -SNAPSHOT and then you have the next X.Y.Z version.
> >
> > Paul
> >
> > Clinton Begin wrote:
> > > The build number is very important...it's the only automated serial
> > > number we have.
> > >
> > > It doesn't matter to me where that number comes from.  SVN rev
> > number is
> > > an excellent suggestion.  But I don't want to downplay the
> > importance of
> > > an automated serial number.
> > >
> > > I agree with Jeff's point, that there shouldn't be two releases with
> > the
> > > same version but different build numbers, and we never have.
> > >
> > > Perhaps a new Ant/Maven task that grabs the revision from the
> > current
> > > working copy (because that's actually what you're building), but the
> >
> > > task should also check that there are no modifications...it's a bit
> > > tricky to get it right actually.  The alternative would be a "fresh
> > > build" task that would do a full checkout from SVN, note the rev
> > number
> > > and then build from there.  Which is actually decent.
> > >
> > > So to summarize, yes it's important and yes it could be more
> > meaningful
> > > by using the SVN rev number -- and it has to be automated.
> > >
> > > Cheers,
> > > Clinton
> > >
> > > On 2/17/07, *Jeff Butler* <[EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED] >> wrote:
> > >
> > > I agree that the build number is useless.  Apache policy says
> > that
> > > there are not different versions of a re

Deploying current iBATIS to ibiblio

[Brandon Goodin]

Hey Guys,

I had another request from someone on IRC asking me about getting the
current release into the public maven repos.  So, I downloaded the current
2.3.0.677 distributions and  jar from the dist and ran it through the
'deploy:deploy-file' mvn goal. It produced all the necessary information for
deploying it to ibiblio (plus md5 and sha1 files). All I need to do is copy
it to apache.people.org. It won't have the .asc file with it.  It doesn't
appear that we sign the actual jar do we? It looks like we only sign the
distribution. If you want i can sign the jar and package the asc files with
it too in the maven ibiblio repo. There is a mixture of projects who do and
do not include an asc file. Although I don't consider the absence of the asc
file to be good as a continued practice, I think we could get away with it
until the next release. Does anyone have objections with me pushing this to
the maven ibiblio rsync on people.apache.org?

The following information is what i assigned to it

groupId=org.apache.ibatis
artifactId=ibatis-sqlmap
version=2.3.0

If deployed this way it will create a jar called 'ibatis-sqlmap-2.3.0.jar'
at 'org/apache/ibatis/ibatis-sqlmap' on the ibiblio maven repo.

Brandon

iBATIS 2.3.0 in ibiblio repo

[Brandon Goodin]

I posted the ibatis-sqlmap jar to the m2 ibiblio sync and it is now
available on ibiblio for maven users.

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/ibatis/ibatis-sqlmap/2.3.0/

Brandon

Re: Site design...wow

[Brandon Goodin]

Honestly, I'm not impressed with the ActiveMQ site design enough to make a
change from what we currently have. It still looks pretty drab to me. I like
our sites color variation. If we want to make a dramatic change away from
non-typical OSS drudgery and towards something more professional, I would
use the Pentaho project as a good example http://www.pentaho.com/. I'm not
advocating their color scheme, I'm just showing it as an example of an OSS
project that put effort into their marketing presentation.

Brandon

On 3/5/07, Larry Meadors <[EMAIL PROTECTED]> wrote:


Also a type of "skate", a member of the shark family similar to a
stingray.

http://www.rijkswaterstaat.nl/nz/kinderpagina/zeebeestje/vleet.jsp

Larry


On 3/4/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
> Mind you, Batis is also a particularly ugly moth...
>
> http://www.probertencyclopaedia.com/j/Peach%20Blossom.jpg
>
> Clinton
>
>
>  On 3/4/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> > Or we could run a mascot contest.  Free signed copies of iIA for the
> winner to sell on ebay. ;-)
> >
> > I was actually thinking of suggesting a change to the logo and to the
> meaning of the name.
> >
> > Batis is a genus of bird
> http://en.wikipedia.org/wiki/Batis_(bird)
> >
> > We could use one of those cute little buggers as our mascot/logo.
> >
> > Clinton
> >
> >
> >
> > On 3/4/07, Larry Meadors <[EMAIL PROTECTED]> wrote:
> > > Hey, we need a box, too...maybe with that caveman from the Geico
> commercials.
> > >
> > > "iBATIS, so simple even a caveman can do it."
> > >
> > > ;-)
> > >
> > > OK, maybe not, but we could snag something from a template site like
> > > template monster, or oswd.org (if we're feeling cheap).
> > >
> > > Larry
> > >
> > >
> > > On 3/4/07, Clinton Begin < [EMAIL PROTECTED]> wrote:
> > > > Hi all,
> > > >
> > > > I just visited the ActiveMQ site (http://activemq.apache.org/) for
the
> first
> > > > time.  I was blown away by the site design.  Okay okayit's
simple.
>  But
> > > > I seriously didn't recognize it as an Apache project or an OSS
project
> at
> > > > allat first glance I thought it was commercial
> (good/bad...whatever).  I
> > > > really liked the professionalism of the site design.  It's just a
> wiki, but
> > > > they have some serious CSS skills there, because even that isn't
> noticable
> > > > to novice or casual business browsers.
> > > >
> > > > Should we update the iBATIS site to look more professional?  My
first
> lazy
> > > > thought is just to hijack the CSS from AMQ and change some of the
> colours...
> > > >  ;-)
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
>

Re: Site design...wow

[Brandon Goodin]

Sorry to be the naysayer here. But, why are we spending time on a logo? Is
the one we have not enough brand recognition? Do we really need a cute
little bird to give our product that extra WOW? Personally, I don't think
so. The iBATIS logo as it stands is great. If we really want to make a
visual impact towards professionalism, I think we'd do well to identify who
we are trying to market to and gear the site to address those audiences.
Seems to me that we discuss the site design every 6 months or so. I would
just caution that we avoid making the site an expression of our current
favorite design trend and more about what the market would find useful and
attractive. If we want to change the site again, then lets make it sparkle
_for the users_ and then be satisfied with it for a long while.

Should we launch a discussion on who the site for? Developers, CTOs,
Managers, etc? How do we feel these different groups would perceive iBATIS
if they visited for the first time?

Brandon

On 3/5/07, Woody, Globo.com <[EMAIL PROTECTED]> wrote:


Hi,

I liked. But I think it is too heavy, too many elements ...

What about the same image with less lines (like a draft)?

Woody



- Original Message -
From: "Joakim Erdfelt" <[EMAIL PROTECTED]>
To: 
Sent: Monday, March 05, 2007 3:28 PM
Subject: Re: Site design...wow


>I liked it too.
> So I ran with it ...
>
> http://joakim.erdfelt.com/ibatis-logo-experiment-bird/
>
> Comments? Suggestions?
>
> - Joakim
>
>
> Clinton Begin wrote:
>> Here's one of my favourite ones:
>>
>>
http://www.oiseaux.net/oiseaux/passeriformes/images/pririt.molitor.jode.1g.jpg
>>
>> Clinton
>>
>> On 3/4/07, *Clinton Begin* <[EMAIL PROTECTED]
>> > wrote:
>>
>>
>> Or we could run a mascot contest.  Free signed copies of iIA for
the
>> winner to sell on ebay. ;-)
>>
>> I was actually thinking of suggesting a change to the logo and to
>> the meaning of the name.
>>
>> Batis is a genus of bird http://en.wikipedia.org/wiki/Batis_(bird)
>> 
>>
>> We could use one of those cute little buggers as our mascot/logo.
>>
>> Clinton
>>
>>
>> On 3/4/07, *Larry Meadors* <[EMAIL PROTECTED]
>> > wrote:
>>
>> Hey, we need a box, too...maybe with that caveman from the
Geico
>> commercials.
>>
>> "iBATIS, so simple even a caveman can do it."
>>
>> ;-)
>>
>> OK, maybe not, but we could snag something from a template site
>> like
>> template monster, or oswd.org  (if we're
>> feeling cheap).
>>
>> Larry
>>
>>
>> On 3/4/07, Clinton Begin < [EMAIL PROTECTED]
>> > wrote:
>> > Hi all,
>> >
>> > I just visited the ActiveMQ site (http://activemq.apache.org/
)
>> for the first
>> > time.  I was blown away by the site design.  Okay
okayit's
>> simple.  But
>> > I seriously didn't recognize it as an Apache project or an
OSS
>> project at
>> > allat first glance I thought it was commercial
>> (good/bad...whatever).  I
>> > really liked the professionalism of the site design.  It's
just
>> a wiki, but
>> > they have some serious CSS skills there, because even that
>> isn't noticable
>> > to novice or casual business browsers.
>> >
>> > Should we update the iBATIS site to look more
professional?  My
>> first lazy
>> > thought is just to hijack the CSS from AMQ and change some of
>> the colours...
>> >  ;-)
>> >
>> > Cheers,
>> > Clinton
>> >
>> >
>> >
>> >
>> >
>>
>>
>>

Re: Site design...wow

[Brandon Goodin]

I agree Ted. I think I would expand upon what you are saying by defining the
different stages by which someone becomes involved in the community. It
would seem to me that we would want to serve each of these stages.

Experimental User:
When someone first approaches a project they need to feel confident about
it. This can be done by providing a professional first impression that
imbues confidence. It is also important to provide quick and easy access to
binaries and documentation. If you have to get 3-4 clicks from the homepage
to get the product, that isn't good for user morale. We are currently only 2
clicks to download (that's good). We could improve this by providing more
prevalent download buttons to get to docs and binaries for the different
implementations.

Established User:
For established users it's good to have regular and meaningful releases, a
responsive user list and Issue Tracking (we have an amazing support
community)

Contributor :
For contributors it's good to have issue tracking that is intuitive and
maintained. I think we do both of those rather well.

I'm sure i'm not addressing something. But, this is a quick brain dump. What
is cool is that I think we have most of these things in the bag. The only
area I see room for improvement is to adjust to site to provide clear paths
for the different levels of involvement in iBATIS.

Brandon

On 3/5/07, Ted Husted <[EMAIL PROTECTED]> wrote:


On 3/5/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> Should we launch a discussion on who the site for? Developers, CTOs,
> Managers, etc? How do we feel these different groups would perceive
iBATIS
> if they visited for the first time?
>
> Brandon

From an ASF perspective, the site should be designed so that it meets
our own needs and the needs of other potential volunteers. Other
stakeholders (CTOs, Managers, journalists) are only important as a
means to an end. The end being attracting new volunteers to contribute
code or documentation to the project. The site, and every aspect of
our infrastructure, should be designed first to foster collaboration.
The volunteer contributors are our only true customers.

If all the world used iBATIS, or Struts, or HTTPD, but we didn't have
three volunteers to do the work, the project would be a failure.

-Ted.

Adding initialize method back to TransactionConfig

[Brandon Goodin]

Hey All,

The removal of the initialize method has broken Spring integration with the
trunk version of iBATIS. I am adding the initialized methods back in as
deprecated. I'll test and see if it creates any problems. My current plan is
to simply have the signature there and have it call setProperites.

Thanks,
Brandon

Change to fix Spring Integration and selectKey.type attribute constraints

[Brandon Goodin]

Hey Guys,

I made some changes to fix Spring integration in the trunk version of
iBATIS. Recent changes broke integration. This fix is only intended to be
temporary until Spring is updated to work with recent changes. I plan to
submit a patch to the Spring crew. Following are the change i made. I was
too lazy to retype it so i'm just pasting my SVN commit notes.

Additionally, I made a change to the dtd. The type attribute of the
selectKey was not allowing me to put a placeholder into it. So, I removed
the (pre | post) constraints in the dtd and changed it to CDATA #IMPLIED.

- added deprecated ExtendedSqlMapClient for Spring integration compatibility
- set SqlMapClient to implement ExtendedSqlMapClient for Spring integration
compatibility
- added deprecated getMaxTransactions to SqlMapExecutorDelegate for Spring
integration compat
- added deprecated public int getMaximumConcurrentTransactions(),public void
setMaximumConcurrentTransactions(int maximumConcurrentTransactions), public
void initialize(Properties props) to TransactionConfig and
 BaseTransactionConfig for Spring integration compat
- removed dtd check on selectKey type attribute to allow for placeholder to
be put into the attribute. otherwise it fails

Mbuild/version.properties
Msrc/com/ibatis/sqlmap/engine/impl/SqlMapExecutorDelegate.java
Asrc/com/ibatis/sqlmap/engine/impl/ExtendedSqlMapClient.java
Msrc/com/ibatis/sqlmap/engine/impl/SqlMapClientImpl.java
Msrc/com/ibatis/sqlmap/engine/transaction/BaseTransactionConfig.java
Msrc/com/ibatis/sqlmap/engine/transaction/TransactionConfig.java
Msrc/com/ibatis/sqlmap/engine/builder/xml/sql-map-2.dtd

Brandon

Re: Deploying Source Code

[Brandon Goodin]

I think there would be a couple issues...

The first is overcoming the stigma of deploying src alongside your compiled
code. The knee jerk reaction is going to be about security. However, what is
humorous about that is that companies regularly expose their database
structures via SQL in xml files or configuration files. Addtionally, if a
company is concerned about intellectual property being hijacked they should
get out of the database business. As soon as you sell a client your app and
install a database for them... the client can see all the database goodness
your app contains. Anyway, I think there are way bigger security risks than
source code being deployed.

The other issue is going to be for the various build tools out there that
aren't ant or maven. Even with maven it will require some deployment magic.
Heck even a standard compile in IDEA has to be tweaked to get something like
that to occur. So, the amount of effort it takes to get code deployed in
this manner may be a non-starter for many. For that reason I'm not sure *I*
would use it. It's almost as bad as a second compile.

Brandon Goodin

On 10/26/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
> You've caught me...and you're the perfect person to have done so. I am
> indeed thinking of enhanced runtime reflection.  See if Java reflection
> was
> complete, this wouldn't even be a discussion.  Certainly in C# land it is
> not.
>
> There's two reasons:  1) parameter names as you've guessed, 2) Comment
> block
> processing because Java has no multiline strings.  Again, in C# this isn't
> a
> problem because C# Attributes are much cleaner than Java annotations, they
> have multiline strings and they can introspect on parameter names (James
> Gosling, are you listening? Or farting around with NetBeans?)
>
> GWT is nice, but I hate having to "compile" or "generate"
> code.  Blech.  The
> code is written, why do I want anymore?  :-)  So if we did support
> something
> like:
>
> public native Employee getEmployee(int id) /*-{
>   SELECT * FROM EMPLOYEE WHERE ID = ${id}
> }-*/;
>
> I would not want to generate yet another artifact (probably XML) at build
> time.  I personally hate that.  So why not just deploy the source?  It's
> the
> easy and natural thing to do.  And I love the fact that it still compiles!
>
> My biggest concern is that there are some companies that are kind of
> strict
> in the sense that they believe this is a security risk, which I believe is
> totally false.  However, I could understand to some degree that developers
> of desktop apps would not want to do this if they have IP/legal issues
> with
> handing out their source code.
>
> But then again, that's why we have multiple solutions right?  ;-)
>
> Cheers,
> Clinton
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of
> Larry Meadors
> Sent: October-26-07 8:26 AM
> To: dev@ibatis.apache.org
> Subject: Re: Deploying Source Code
>
> I used to do that, but looking at it now, I am asking "What's the cost
> and what's the value?".
>
> The cost in terms of disk is negligible these days - You can't buy a
> drive <120GB these days, so what's a few hundred KB, or even a few MB
> on disk? Especially compared to the 80MB of struts or spring?
>
> I'm not sure how class loaders deal with this, I suspect if they load
> a jar, they load all of the resources, not just what's needed. That
> *could* be a bit more costly in terms of startup time, and free memory
> for the application, but again, sheesh, when you have 4-8GB of RAM in
> a server, what's a few K here and there? I suspect you'll leak more
> than that running firefox. ;-)
>
> The value seems kind of iffy. I guess if you wanted to use embedded
> comments for runtime code generation, this is the only real way to do
> that. But IMO, since we have annotations, that's not a great idea. It
> might help overcome some of Java's retarded reflection limitations
> (who needs parameter names, anyway?), but again - an annotations can
> do that, too.
>
> My gut reaction is that it's not a good idea, but I can't really
> quantify why. :-)
>
> Larry
>
>
> On 10/26/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > I mean deploying your .java files to production alongside your .class
> files
> > and having it available on the classpath at runtime.
> >
> >
> >
> > com/yourdomain/yourapp/SomeClass.java
> >
> > com/yourdomain/yourapp/SomeClass.class
> >
> >
> >
> > I hope that's

Re: Code Hierarchy and Build Process

[Brandon Goodin]

Thanks for sharing your passions. My thoughts are below...

#1...

A. one "click" has never been a problem for maven. There seems to be a lot
of insinuation that maven requires a lot of config files. I'm not sure where
you are getting this. The only thing that we might need to do is break out
the assembly config. But, that is because it is about packaging artifacts
all together and not about building the individual jars. So, if you are
saying we can't have an assembly config then gimme a break. Your request is
denied because it requires something that is not possible and is not
possible for a rational and organized reason.

B. offline build... never been an issue for maven. So long as you have the
needed jars locally. But this is true of any codebase.

C. Are you referring to the final zipe file structure or the source tree. If
you are referring to the source tree. You will be denied on that one as well
because maven doesn't have dependencies in the local source tree. If you are
talking about the final packaged output... we already demonstrated that with
the current ibatis maven build.

D. HTML Test Reports - Been possible for a long time

E. Coverage Reports - Been possible for a long time

F. Exploded Distributions - Not sure of what you are referring to here. If
you are referring to seeing the final product of the zip file before it is
zipped then that is just a matter of copying all the sources to a folder in
the assembly config. We demonstrated that with the current maven build in
ibatis.

G. Zipped Distro - No problem

H. I don't think this is necessary. We can look into adding the build number
to the META-INF. But, this should be possible.

#2 - Getting up and going in my IDE is a snap because of current IDE
integration. Less than a minute. With Ant. I always have to checkout the
project figure out what the heck people are doing in their ant script
because EVERYONE does something different. Ramp up time sucks. I always
enjoy how people will blend build artifacts with static artifacts. Can't
simply delete the output folder. You always have to make sure you use their
custom wacky ant scripts and hope you don't call the wrong task.

#3 - See #2


"I'm for simplicity over all else.  No Ant isn't the best example of a build
tool in history.  But it's simple and it works." I am too. That is why i use
maven :D I got tired of trying to figure out everyone's wacky Ant scripts.

I think you need to take your blood pressure medicine. ;-) Maven is an
acceptable build system. Instead of coming out with aggressive posturing,
give your fellow developers the benefit of the doubt. Do you think we would
use it if we thought it was a horrid pile of crap? Everything comes with
it's strengths and weaknesses. I'll take the lack of a build number on the
zip and jar any day over the amount of effort i expel trying to figure out
ant scripts.

Brandon

On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <[EMAIL PROTECTED]>
wrote:

> I currently hate Maven with a grand passion.  But, I'm open minded and am
> willing to be educated as to why people like it.  I will make the same offer
> I made before:
>
> Three requirements:
>
> #1 Create a maven build system for iBATIS that achieves the exact same
> output, which includes:
> - one "click" build -- I'm not exaggerating here, SVN checkout, run
> ant or script...done.  NOTHING else.. no config files, no nothing.

 - offline build -- no network connection required (perhaps after one
build if it needs to grab dependencies initially)

> - echo arbitrary information to the command line, such as classpath in
> use and current version being built
> - all dependencies must be versioned and organized into developer
> dependencies (/devlib) and runtime/deploy dependencies (/lib)
> - HTML test reports
> - HTML coverage reports
> - exploded distribution
> - zipped distr
> - version number stamped on ibatis JAR file(s) as well as the zip
> distro
> - all achieved by Ant today.
>
> #2 Show that it's simpler than Ant in at least one way.  For example:
> - less XML configuration
> - fewer requirements
> - smaller overall source base size
> - more/better compatibility with tools/frameworks/IDEs
> - the current Ant build is 258 lines and integrates and runs from any
> IDE
>
> #3 Show that it does something Ant doesn't.  For example:
> - Signs, MD5, and Uploads to Apache dist (with no additional
> dependencies or configuration)
> - 
>
> I don't think these are unreasonable requirements.  In fact if even one is
> missed, it would make me wonder why the hell we'd even bother.
>
> I'm for simplicity over all else.  No Ant isn't the best example of a
> build tool in history.  But it's simple and it works.
>
> Clinton
>
>
> On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <[EMAIL PROTECTED]>
> wrote:
>
> > Brandon reply below.
> >
> > I am completely for using Maven 2 and conforming our source tree to it.
> > There were three issues, i

Re: Code Hierarchy and Build Process

[Brandon Goodin]

Comments are mixed in:

On Wed, May 7, 2008 at 10:38 AM, Clinton Begin <[EMAIL PROTECTED]>
wrote:

>
> I wasn't implying that Maven COULDN'T do anything I was just laying
> out what I would want to see from a maven build.
>
> >> So, if you are saying we can't have an assembly config then gimme a
> break.
>
> What I mean is that if I can't check it out and build without having to
> perform some developer level/local config then forget it.
>

This would entirely depend on what we are doing. I don't believe iBATIS
would ever require this unless we used a key for uploading artifacts to a
location. In that case you would need to add the configuration to your
settings.xml.

There is also the initial installation of maven. But, most people will be
installing ant as well to run any ant builds that we provide.


> >> I don't think this is necessary. We can look into adding the build
> number to the META-INF. But, this should be possible.
>
> Versions are important.  The more clear we can be with our version number
> the better.  I'd like it in the filename, because it helps people, including
> us.  One of the reasons Java sucks these days is the lack of good version
> control of JAR files.  The best we can do is put the version number in the
> name of the JAR file to help people know which version they're using.  It
> also helps us on support lists... recall the days when people couldn't tell
> which version they were using because they copied it from somewhere else.
> META-INF is a good second best... but I hear this Maven thing is supposed to
> be good, so I'd expect it to be able to fill this simple requirement.
>

Fair enough. I didn't say it was impossible. I just said it wasn't necessary
to tack it onto everything.


> I'm already not impressed with the excuses.  I laid out what I think are
> fairly simple requirements that any build system should support.
>

What excuses? I'm simply getting information and asking you to clarify your
requests. On top of that I'm stating where I don't agree with your
requirements.


>
> >> Getting up and going in my IDE
>
> I honestly don't want to mix the needs of the development tool with the
> build tool.  The build is a separate entity.  Furthermore, let's not mix the
> problems of other projects (which may very well be solved by Maven).  iBATIS
> does not have the problem you describe.  It's a well structured and
> organized directory.  /devlib /lib /src /test.. there's no magic to it.
> I understand what you're saying, but iBATIS simply doesn't have the
> problem.
>

The beauty of this is that you get both. Can you say that about Ant? hint...
nope.


>
> >> I think you need to take your blood pressure medicine.
>
> Let's not get too immature about it.  I'm being open minded and fair.  I
> asked for very simple things that are achieved with a 260 line Ant file with
> 14 well described tasks.  I've yet to see:


You're just a hater :D and you left of my wink from that quote.

>
>
> 1) A major problem or flaw pointed out with the iBATIS Ant build.  I don't
> care about the general case of Maven vs. Ant and Project X -- what's wrong
> with the *iBATIS* build?


I still need to take the time to figure out the iBATIS ant build. I don't
need to do that with maven. I know what tasks to run in order to build it.


>
> 2) A major advantage to using Maven for iBATIS (other than the potentially
> easier one-time setup of the IDE -- neat, but one-time IDE config vs. daily
> build maintenance...)


Standard project layout is easy to get into and get going. A clearly defined
structure that leaves no question about where future artifacts go.
Unambiguous communication of required project structures is very important.
So, why not go with a common, well known, and documented structure?


>
> 3) Confirmation that Maven can meet some very simple requirements I laid
> out.
>
> Instead I hear excuses and borderline personal attacks (which I know
> Brandon doesn't really mean, but it's still a shitty way to debate).  Come
> on guys.   You're doing a piss poor job of making your case for Maven with
> that approach.
>

I'll be honest here, no winks. You tone here is very aggressive. If you want
to keep it civil you should put some winkies in there.


>
> Don't argue.  Look at what the current build does.  Do it with Maven
> cleanly,  and while meeting all of those simple requirements -- and you've
> won your case.
>

I'm not arguing I'm providing information. As I stated before in my initial
email. We had provided a build for maven on the current ibatis. There were
some issues t

Re: Code Hierarchy and Build Process

[Brandon Goodin]

As a follow up to all who are reading this thread. Let me be very clear. Any
aggressive comments are made in jest and fun. We are all good friends here
and enjoy the big brother banter. Please don't take this as an opportunity
to truly dig on any one of us.

Muchos Gracias,
Brandon

On Wed, May 7, 2008 at 11:13 AM, Brandon Goodin <[EMAIL PROTECTED]>
wrote:

> Comments are mixed in:
>
> On Wed, May 7, 2008 at 10:38 AM, Clinton Begin <[EMAIL PROTECTED]>
> wrote:
>
> >
> > I wasn't implying that Maven COULDN'T do anything I was just laying
> > out what I would want to see from a maven build.
> >
> > >> So, if you are saying we can't have an assembly config then gimme a
> > break.
> >
> > What I mean is that if I can't check it out and build without having to
> > perform some developer level/local config then forget it.
> >
>
> This would entirely depend on what we are doing. I don't believe iBATIS
> would ever require this unless we used a key for uploading artifacts to a
> location. In that case you would need to add the configuration to your
> settings.xml.
>
> There is also the initial installation of maven. But, most people will be
> installing ant as well to run any ant builds that we provide.
>
>
> > >> I don't think this is necessary. We can look into adding the build
> > number to the META-INF. But, this should be possible.
> >
> > Versions are important.  The more clear we can be with our version
> > number the better.  I'd like it in the filename, because it helps people,
> > including us.  One of the reasons Java sucks these days is the lack of good
> > version control of JAR files.  The best we can do is put the version number
> > in the name of the JAR file to help people know which version they're
> > using.  It also helps us on support lists... recall the days when people
> > couldn't tell which version they were using because they copied it from
> > somewhere else.   META-INF is a good second best... but I hear this Maven
> > thing is supposed to be good, so I'd expect it to be able to fill this
> > simple requirement.
> >
>
> Fair enough. I didn't say it was impossible. I just said it wasn't
> necessary to tack it onto everything.
>
>
> > I'm already not impressed with the excuses.  I laid out what I think are
> > fairly simple requirements that any build system should support.
> >
>
> What excuses? I'm simply getting information and asking you to clarify
> your requests. On top of that I'm stating where I don't agree with your
> requirements.
>
>
> >
> > >> Getting up and going in my IDE
> >
> > I honestly don't want to mix the needs of the development tool with the
> > build tool.  The build is a separate entity.  Furthermore, let's not mix the
> > problems of other projects (which may very well be solved by Maven).  iBATIS
> > does not have the problem you describe.  It's a well structured and
> > organized directory.  /devlib /lib /src /test.. there's no magic to it.
> > I understand what you're saying, but iBATIS simply doesn't have the
> > problem.
> >
>
> The beauty of this is that you get both. Can you say that about Ant?
> hint... nope.
>
>
> >
> > >> I think you need to take your blood pressure medicine.
> >
> > Let's not get too immature about it.  I'm being open minded and fair.  I
> > asked for very simple things that are achieved with a 260 line Ant file with
> > 14 well described tasks.  I've yet to see:
>
>
> You're just a hater :D and you left of my wink from that quote.
>
> >
> >
> > 1) A major problem or flaw pointed out with the iBATIS Ant build.  I
> > don't care about the general case of Maven vs. Ant and Project X -- what's
> > wrong with the *iBATIS* build?
>
>
> I still need to take the time to figure out the iBATIS ant build. I don't
> need to do that with maven. I know what tasks to run in order to build it.
>
>
> >
> > 2) A major advantage to using Maven for iBATIS (other than the
> > potentially easier one-time setup of the IDE -- neat, but one-time IDE
> > config vs. daily build maintenance...)
>
>
> Standard project layout is easy to get into and get going. A clearly
> defined structure that leaves no question about where future artifacts go.
> Unambiguous communication of required project structures is very important.
> So, why not go with a common, well known, and documented structure?
>
>
> >
&g

Re: Code Hierarchy and Build Process

[Brandon Goodin]

The other thing that can be nice about maven is for ibatis extension
development. We are making iB3 more accessible. This means that we are
likely to have more people wanting to write against ibatis. Maven makes it
nicer to create dependencies on nightly builds/snapshots.

Brandon

On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <[EMAIL PROTECTED]>
wrote:

> >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> >> additional dependencies or configuration)" - how's this going to work,
> >> via telepathy? :-D
>
> Trusted hosts (or same host) and a continuous integration server with a
> manually invoked distribution target.  CI server runs as the "deploy" user
> which is a trusted signatory of the Apache distribution system.
>
> Clinton
>
>
> On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > <[EMAIL PROTECTED]> wrote:
> > > As a follow up to all who are reading this thread. Let me be very
> > clear. Any
> > > aggressive comments are made in jest and fun. We are all good friends
> > here
> > > and enjoy the big brother banter. Please don't take this as an
> > opportunity
> > > to truly dig on any one of us.
> >
> > ...well, except for Brandon. He really is a butthead. ;-)
> >
> > Funny how everyone gets so worked up about how we'll implement
> > build.sh, isn't it? :-)
> >
> > Since everyone has an opinion on this, here's mine: I think we should
> > use Maven.
> >
> > I agree with Clinton that there aren't *problems* with the current
> > iBATIS build, but at the same time, it would simplify how we do
> > releases, because as we are seeing, there are more requests (even from
> > us) for maven artifacts by our users, and mavenizing our build will
> > make meeting our needs easier.
> >
> > IMO, the things that Clinton is asking for are not unreasonable, but
> > they are not uber-critical either.
> >
> > Let's be really honest here: How critical is it that we are able to
> > "echo arbitrary information to the command line, such as classpath in
> > use and current version being built"? Seriously? :-/
> >
> > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > additional dependencies or configuration)" - how's this going to work,
> > via telepathy? :-D
> >
> > It's going to be different if we use a different tool. Neither tool is
> > perfect, so yes, it'll suck. But ant sucks, too - just in a different
> > way.
> >
> > My vote is we arrange the source tree to fit what maven expects.
> > Clinton: I don't care if you don't have to do that with ant. :-P Then,
> > lets see how close we can get to all of the current ant script. If we
> > can't get 100%, I'm OK with that, if we can get close and work towards
> > that goal.
> >
> > At the end of the day, which ever one makes it easier for me to use
> > iBATIS (I really don't care about anyone else, sorry) is the one I
> > want. For me, that means Maven is the better choice. This is a one
> > time task, so maintenance is not that big of a deal, and it'll output
> > the jar (like ant does) and the maven artifacts (like ant does not).
> > It does more, and is a one time investment, let's just get it done and
> > move on.
> >
> > Larry
> >
>
>

Re: Code Hierarchy and Build Process

[Brandon Goodin]

Sorry for the spotty emails. just stuff coming to my mind. Another point
would be the whole deploying to the maven repository can be made easier. We
want to be able to provide users with source artifacts and jar artifacts all
properly packaged with maven. I can do this manually. But, i'd rather not.
So, if we can accomplish all that the ant tool does and get the artifacts
out to the maven repo, it would be all that much better.

Brandon

On Wed, May 7, 2008 at 12:03 PM, Brandon Goodin <[EMAIL PROTECTED]>
wrote:

> The other thing that can be nice about maven is for ibatis extension
> development. We are making iB3 more accessible. This means that we are
> likely to have more people wanting to write against ibatis. Maven makes it
> nicer to create dependencies on nightly builds/snapshots.
>
> Brandon
>
>
> On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <[EMAIL PROTECTED]>
> wrote:
>
> > >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > >> additional dependencies or configuration)" - how's this going to
> > work,
> > >> via telepathy? :-D
> >
> > Trusted hosts (or same host) and a continuous integration server with a
> > manually invoked distribution target.  CI server runs as the "deploy" user
> > which is a trusted signatory of the Apache distribution system.
> >
> > Clinton
> >
> >
> > On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > > <[EMAIL PROTECTED]> wrote:
> > > > As a follow up to all who are reading this thread. Let me be very
> > > clear. Any
> > > > aggressive comments are made in jest and fun. We are all good
> > > friends here
> > > > and enjoy the big brother banter. Please don't take this as an
> > > opportunity
> > > > to truly dig on any one of us.
> > >
> > > ...well, except for Brandon. He really is a butthead. ;-)
> > >
> > > Funny how everyone gets so worked up about how we'll implement
> > > build.sh, isn't it? :-)
> > >
> > > Since everyone has an opinion on this, here's mine: I think we should
> > > use Maven.
> > >
> > > I agree with Clinton that there aren't *problems* with the current
> > > iBATIS build, but at the same time, it would simplify how we do
> > > releases, because as we are seeing, there are more requests (even from
> > > us) for maven artifacts by our users, and mavenizing our build will
> > > make meeting our needs easier.
> > >
> > > IMO, the things that Clinton is asking for are not unreasonable, but
> > > they are not uber-critical either.
> > >
> > > Let's be really honest here: How critical is it that we are able to
> > > "echo arbitrary information to the command line, such as classpath in
> > > use and current version being built"? Seriously? :-/
> > >
> > > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > additional dependencies or configuration)" - how's this going to work,
> > > via telepathy? :-D
> > >
> > > It's going to be different if we use a different tool. Neither tool is
> > > perfect, so yes, it'll suck. But ant sucks, too - just in a different
> > > way.
> > >
> > > My vote is we arrange the source tree to fit what maven expects.
> > > Clinton: I don't care if you don't have to do that with ant. :-P Then,
> > > lets see how close we can get to all of the current ant script. If we
> > > can't get 100%, I'm OK with that, if we can get close and work towards
> > > that goal.
> > >
> > > At the end of the day, which ever one makes it easier for me to use
> > > iBATIS (I really don't care about anyone else, sorry) is the one I
> > > want. For me, that means Maven is the better choice. This is a one
> > > time task, so maintenance is not that big of a deal, and it'll output
> > > the jar (like ant does) and the maven artifacts (like ant does not).
> > > It does more, and is a one time investment, let's just get it done and
> > > move on.
> > >
> > > Larry
> > >
> >
> >
>

Re: Code Hierarchy and Build Process

[Brandon Goodin]

Geez I'm really sorry to fire off yet another...

Yet another point. Ant integration has become quite nice with maven. So, it
is possible we can augment maven insufficiencies with Ant.

Shutting up,
Brandon

On Wed, May 7, 2008 at 12:05 PM, Brandon Goodin <[EMAIL PROTECTED]>
wrote:

> Sorry for the spotty emails. just stuff coming to my mind. Another point
> would be the whole deploying to the maven repository can be made easier. We
> want to be able to provide users with source artifacts and jar artifacts all
> properly packaged with maven. I can do this manually. But, i'd rather not.
> So, if we can accomplish all that the ant tool does and get the artifacts
> out to the maven repo, it would be all that much better.
>
> Brandon
>
>
> On Wed, May 7, 2008 at 12:03 PM, Brandon Goodin <[EMAIL PROTECTED]>
> wrote:
>
> > The other thing that can be nice about maven is for ibatis extension
> > development. We are making iB3 more accessible. This means that we are
> > likely to have more people wanting to write against ibatis. Maven makes it
> > nicer to create dependencies on nightly builds/snapshots.
> >
> > Brandon
> >
> >
> > On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <[EMAIL PROTECTED]>
> > wrote:
> >
> > > >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > >> additional dependencies or configuration)" - how's this going to
> > > work,
> > > >> via telepathy? :-D
> > >
> > > Trusted hosts (or same host) and a continuous integration server with
> > > a manually invoked distribution target.  CI server runs as the "deploy" 
> > > user
> > > which is a trusted signatory of the Apache distribution system.
> > >
> > > Clinton
> > >
> > >
> > > On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > As a follow up to all who are reading this thread. Let me be very
> > > > clear. Any
> > > > > aggressive comments are made in jest and fun. We are all good
> > > > friends here
> > > > > and enjoy the big brother banter. Please don't take this as an
> > > > opportunity
> > > > > to truly dig on any one of us.
> > > >
> > > > ...well, except for Brandon. He really is a butthead. ;-)
> > > >
> > > > Funny how everyone gets so worked up about how we'll implement
> > > > build.sh, isn't it? :-)
> > > >
> > > > Since everyone has an opinion on this, here's mine: I think we
> > > > should use Maven.
> > > >
> > > > I agree with Clinton that there aren't *problems* with the current
> > > > iBATIS build, but at the same time, it would simplify how we do
> > > > releases, because as we are seeing, there are more requests (even
> > > > from
> > > > us) for maven artifacts by our users, and mavenizing our build will
> > > > make meeting our needs easier.
> > > >
> > > > IMO, the things that Clinton is asking for are not unreasonable, but
> > > > they are not uber-critical either.
> > > >
> > > > Let's be really honest here: How critical is it that we are able to
> > > > "echo arbitrary information to the command line, such as classpath
> > > > in
> > > > use and current version being built"? Seriously? :-/
> > > >
> > > > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > > additional dependencies or configuration)" - how's this going to
> > > > work,
> > > > via telepathy? :-D
> > > >
> > > > It's going to be different if we use a different tool. Neither tool
> > > > is
> > > > perfect, so yes, it'll suck. But ant sucks, too - just in a
> > > > different
> > > > way.
> > > >
> > > > My vote is we arrange the source tree to fit what maven expects.
> > > > Clinton: I don't care if you don't have to do that with ant. :-P
> > > > Then,
> > > > lets see how close we can get to all of the current ant script. If
> > > > we
> > > > can't get 100%, I'm OK with that, if we can get close and work
> > > > towards
> > > > that goal.
> > > >
> > > > At the end of the day, which ever one makes it easier for me to use
> > > > iBATIS (I really don't care about anyone else, sorry) is the one I
> > > > want. For me, that means Maven is the better choice. This is a one
> > > > time task, so maintenance is not that big of a deal, and it'll
> > > > output
> > > > the jar (like ant does) and the maven artifacts (like ant does not).
> > > > It does more, and is a one time investment, let's just get it done
> > > > and
> > > > move on.
> > > >
> > > > Larry
> > > >
> > >
> > >
> >
>

Re: [VOTE] Use Maven 2 as iBATIS 3 build system.

[Brandon Goodin]

Brandon Goodin's vote:
+1

On Wed, May 7, 2008 at 12:11 PM, Clinton Begin <[EMAIL PROTECTED]>
wrote:

> My Vote:
>
> [0] Doesn't matter.  As long as it builds as well as it currently does.
>
> Clinton
>
>
> On Wed, May 7, 2008 at 11:09 AM, Clinton Begin <[EMAIL PROTECTED]>
> wrote:
>
> >
> > This is a vote to switch our build system from Ant to Maven 2.
> >
> > Binding votes will be accepted from committers of the iBATIS for Java
> > project.  All other votes will be taken as opinion, but non-binding.
> >
> > This does not imply that we will use Maven for our website, but we could
> > indeed consider that separately.  This is specifically for building the
> > iBATIS 3 library.
> >
> > -1 Not in favor, stick with Ant, it rules.
> >
> > 0 Doesn't matter.  As long as it builds as well as it currently does.
> >
> > +1 Totally in favor, use Maven 2, it offers great benefits and is the
> > way of the future.
> >
> >
> > Cheers,
> > Clinton
> >
>
>

Re: [VOTE] Promote iBATIS 2.3.2 to General Availability -- Java 5 Required...

[Brandon Goodin]

+1

As a side note there are tools that can backport java 5 code to java 1.4.
Tools like Retrotranslator (http://retrotranslator.sourceforge.net/).

Brandon Goodin

On Thu, Jun 26, 2008 at 1:23 PM, Clinton Begin <[EMAIL PROTECTED]>
wrote:

> This is a vote to promote iBATIS 2.3.2 to General Availability.
>
> One consequence of 2.3.2 is that it now requires Java 5.  We've added
> support for Enums and therefore we cannot compile it under 1.4.  It's
> possible to make a 1.4 compatible branch of the framework, but that can be a
> separate issue.  If you've voting to promote this, then you're also voting
> to drop support for JDK 1.4 in the release.
>
> I like this approach, because it also prepares people for iBATIS
> 3.0...which will be Java 5 only.
>
> Clinton
>

iBATIS 3 Maven Project Layout Discussion

[Brandon Goodin]

Hey All,

There was a private discussion regarding the project layout and maven
default conventions. I wanted to put the discussion out in front of
everyone else, purely to get feedback and thoughts.

At the moment the src directory contains source *and* resources. Maven
has been configured to recognize the src/main/java as the resources
and java directory. The reason for this is that it can get tedious to
move between the java and resources directory rather than just edit a
resource in the same package as the java class.

The approach of using the java directory as a dual purpose directory
is a departure from Maven's default directory structure. The concern
of departing from that structure is that it may cause additional
difficulties as we make heavier use of maven for coverage and
reporting. If we experience difficulties in the future with Maven
(because we all know it can be temperamental) it may be that we start
having to separate all the resource files out of the java directory in
order to eliminate it as a cause.

So in summary...

Current reasons for dual purpose java directory:
* iBATIS 3 will make use of convention configuration and the visual
proximity of resources to java is more visually correct
* All around less directory clutter


Concerns and counterpoints to making the java directory dual purpose:
* Most IDEs can merge the resource and java directories in a package view.
* We run the risk of avoiding potential maven headaches with plugins
that don't handle the combined java/resources approach.


In the end the question would be... Is it better to have coding
convenience or follow the maven default approach of separating java
and resource? Any experiences and comments are welcome.

Brandon

POM Changes

[Brandon Goodin]

I made the following changes to the pom.xml. I had to use 1.0.1B of
JTA because it was available on the Sun repo. Hopefully that won't
cause an issue.

- set exclude on *.java in resource definitions for core and compat
- added java.net repository definition and set jta to 1.0.1B. Not the
latest but it compiles and passes all tests
- added sources plugin to core and compat so that they now produce
sources jars during the verify phase.

B

Re: iBATIS 3 Maven Project Layout Discussion

[Brandon Goodin]

That's good to hear. I'm too lazy to go confirm much of this :). So,
thanks for doing some foot work to find examples where this is being
used without problem. I know Maven provides for this feature. But, I
have run across other features that were provided for and wound up
causing headaches. Anyway, this is all good feedback.

B

On Fri, Aug 8, 2008 at 10:14 AM, Clinton Begin <[EMAIL PROTECTED]> wrote:
> Great Summary Brandon.
>
> Given that Maven allows one to specify the resources folder (and even filter
> out certain files, like we will for .java files eventually), and considering
> that it does not cast a warning or error upon setting the resource directory
> to the source directory, I would consider it a feature supported by Maven.
> If we do encounter issues, I won't be shy about filing a bug report with
> either Maven or any plug-ins that have a problem with this configuration.
>
> iBATIS is not the only project to use this sort of setup.  Hibernate also
> has classpath resources that sit directly beside the class files.  While
> some may choose to separate them out for a very good reason, I believe most
> keep them in the exact same directory structure.  So I would bet that this
> is quite a common practice.
>
> Cheers,
> Clinton
>
> On Fri, Aug 8, 2008 at 8:35 AM, Brandon Goodin <[EMAIL PROTECTED]>
> wrote:
>>
>> Hey All,
>>
>> There was a private discussion regarding the project layout and maven
>> default conventions. I wanted to put the discussion out in front of
>> everyone else, purely to get feedback and thoughts.
>>
>> At the moment the src directory contains source *and* resources. Maven
>> has been configured to recognize the src/main/java as the resources
>> and java directory. The reason for this is that it can get tedious to
>> move between the java and resources directory rather than just edit a
>> resource in the same package as the java class.
>>
>> The approach of using the java directory as a dual purpose directory
>> is a departure from Maven's default directory structure. The concern
>> of departing from that structure is that it may cause additional
>> difficulties as we make heavier use of maven for coverage and
>> reporting. If we experience difficulties in the future with Maven
>> (because we all know it can be temperamental) it may be that we start
>> having to separate all the resource files out of the java directory in
>> order to eliminate it as a cause.
>>
>> So in summary...
>>
>> Current reasons for dual purpose java directory:
>> * iBATIS 3 will make use of convention configuration and the visual
>> proximity of resources to java is more visually correct
>> * All around less directory clutter
>>
>>
>> Concerns and counterpoints to making the java directory dual purpose:
>> * Most IDEs can merge the resource and java directories in a package view.
>> * We run the risk of avoiding potential maven headaches with plugins
>> that don't handle the combined java/resources approach.
>>
>>
>> In the end the question would be... Is it better to have coding
>> convenience or follow the maven default approach of separating java
>> and resource? Any experiences and comments are welcome.
>>
>> Brandon
>
>

Re: POM Changes

[Brandon Goodin]

Yeah the nice thing about it now is that nobody has to manually
download a sun jar. I'm glad this will work.

B

On Fri, Aug 8, 2008 at 10:28 AM, Clinton Begin <[EMAIL PROTECTED]> wrote:
> I wonder what is up with JTA?  The pom in the maven.org repo also only
> references 1.01b  and the Sun distro of 1.1.1 isn't even properly packaged,
> almost as if it were just a PoC or something...
>
> I'm happy to use 1.0.1b... both seem to compile and at the end of the day
> they're just a bunch of interfaces.
>
> Cheers,
> Clinton
>
> On Fri, Aug 8, 2008 at 9:21 AM, Brandon Goodin <[EMAIL PROTECTED]>
> wrote:
>>
>> I made the following changes to the pom.xml. I had to use 1.0.1B of
>> JTA because it was available on the Sun repo. Hopefully that won't
>> cause an issue.
>>
>> - set exclude on *.java in resource definitions for core and compat
>> - added java.net repository definition and set jta to 1.0.1B. Not the
>> latest but it compiles and passes all tests
>> - added sources plugin to core and compat so that they now produce
>> sources jars during the verify phase.
>>
>> B
>
>

Re: EL for iB3 Dynamic SQL tags

[Brandon Goodin]

OGNL is  a great option. I think many people will be satisfied with
that (including myself). It's a good powerful EL.

Brandon

On Sun, Aug 10, 2008 at 11:00 PM, Clinton Begin <[EMAIL PROTECTED]> wrote:
> I spent last evening comparing EL options for the iB3 dynamic (and otherwise
> actually) SQL tags.  I've decided to go with a repackaged version of OGNL
> 2.6.9 (org.apache.ibatis.ognl).  My reasoning is as follows:
>
>   * It uses an Apache like license that allows the flexibility for us to
> repackage it so that we can avoid dependency issues (JAR hell).
>   * It has the nicest syntax, the simplest API and surprising performance
> (it runs its own 500+ unit tests in 0.5 seconds).
>   * It's exactly what we need.
>
> The runner up is MVEL, which is also excellent and uses the Apache 2.0
> license.  In the end the difference is only that OGNL is older, more proven
> and better known.
>
> Ones I tried and decided against...
>
>   * Commons EL -- really disappointing.
>   * OGNL 2.6.9++ -- are OpenSymphony, which has a friendly license, but I'm
> not sure about repackaging the way we'd like.
>   * EL-API/RI -- No.  Just no.
>   * JEXL -- Velocity, meh.
>
> Comments welcome.
>
> Clinton
>

Re: iBATIS 3 XML SQL Map Decisions...

[Brandon Goodin]

The only thing that i would note would be that the dynamic sql should
also contain an  or a  .

B

On Wed, Aug 13, 2008 at 12:50 AM, Clinton Begin <[EMAIL PROTECTED]> wrote:
> Hey all,
>
> I'd like to get some feedback on the things you like and dislike about the
> current XML, and also show you some of the new XML.  Without too much
> talk... here's what I've started out with for the new iBATIS 3 mappings
>
> Note that while this XML may look similarly verbose, realize that a lot of
> it will be less necessary with 3.0.  Overall, I hope the XML experience is
> quite a bit simpler.  The interface bindings will make a lot of the typing
> unecessary.
>
> 
> 
>
>   
>   
>
>   
>   
> 
>   
>   
> 
> 
> 
>   
>   
>   
>   
>  
>   
> 
> 
> 
>   
> 
>   
>
>   
>   
> 
> 
> 
>  parameterType="" resultType="" resultMap="">
>   select * from PERSON order by
> ${opts.order,javaType="",jdbcType="",typeHandler="",mode="",scale="",resultMap=""}
> 
>  flushCache="" parameterType="" resultType="" resultMap="">
>   
>scale="" resultMap="" />
>scale="" resultMap="" />
>   select * from PERSON
>   where PERSON_ID = #param.id
>   
>   
>   
> and DEPT_ID =
> #{param.deptId,javaType="",jdbcType="",typeHandler="",mode="",scale="",resultMap=""}
>   
> 
>   
>
> 
>
> Thoughts welcome.
>
> Clinton
>

Re: New iBATIS builds on Maven central repository

[Brandon Goodin]

hey guys... i'll move 2.3.3 out to maven now sorry for the
delay... things have been crazy busy

Brandon

On Thu, Sep 4, 2008 at 9:19 AM, Clinton Begin <[EMAIL PROTECTED]> wrote:
> I've asked one of our Maven experts to take care of it.  We have 3 of them,
> all busy, but one should be able to get to it soon.
>
> The delay was intentional, but we're past the point of prooving 2.3.3 is
> stable.  So now is the time.
>
> Cheers,
> Clinton
>
> On Thu, Sep 4, 2008 at 7:41 AM, Jeff Butler <[EMAIL PROTECTED]> wrote:
>>
>> I think you'll notice, from the lack of response to your many other posts
>> about this, that publishing iBATIS2 into the central Maven repository is not
>> a prioirity for any committer.  This will change with iBATIS3 when we use
>> Maven to do the iBATIS build, but likely won't change for iBATIS2.
>>
>> For now, I suggest that you find a way to build your project with a local
>> download of iBATIS2.  Surely Maven is capable of doing that - isn't it?
>>
>> Jeff Butler
>>
>>
>> On Thu, Sep 4, 2008 at 8:29 AM, Zhubin Salehi <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi all,
>>>
>>> Could someone please upload iBATIS 2.3.3 to Maven central repo?
>>>
>>> Thanks,
>>> Zhubin
>>> --
>>> View this message in context:
>>> http://www.nabble.com/New-iBATIS-builds-on-Maven-central-repository-tp19309009p19309009.html
>>> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>>>
>>
>
>

Re: New iBATIS builds on Maven central repository

[Brandon Goodin]

FYI I pushed the jar and sources to the Apache m2-ibiblio-rsync-repository.
It takes a little time for it to be pushed over to ibiblio.

You can see the release is queued up on the rsync repo here:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ibatis/ibatis-sqlmap/

I added documentation to the wiki for releasing:

http://opensource.atlassian.com/confluence/oss/display/IBATIS/iBATIS+Release+Process#iBATISReleaseProcess-deployingtoibiblio

Hopefully it all works and we don't have to listen to people whine about
iBATIS not being on ibiblio again ;-)

Brandon

On Tue, Sep 9, 2008 at 9:52 AM, Kai Grabfelder <[EMAIL PROTECTED]> wrote:
> @Brandon: thanks: Could you also deploy a -sources.jar? I really like when
> projects are including this as it makes live so much easier...
>
> Regards
>
> Kai
>
> --- Original Nachricht ---
> Absender: Clinton Begin
> Datum: 09.09.2008 16:45
>>
>> WAIT!!
>>
>> Guys, I'll need to make a 2.3.4 build remember the async
autoresultmap
>> bug?
>>
>> I'll roll it now.  BG get on GTalk if you can, we'll coordinate.
>>
>> Clinton
>>
>> On Tue, Sep 9, 2008 at 8:42 AM, Brandon Goodin
>> <[EMAIL PROTECTED]>wrote:
>>
>>> hey guys... i'll move 2.3.3 out to maven now sorry for the
>>> delay... things have been crazy busy
>>>
>>> Brandon
>>>
>>> On Thu, Sep 4, 2008 at 9:19 AM, Clinton Begin <[EMAIL PROTECTED]>
>>> wrote:
>>> > I've asked one of our Maven experts to take care of it.  We have 3 of
>>> them,
>>> > all busy, but one should be able to get to it soon.
>>> >
>>> > The delay was intentional, but we're past the point of prooving 2.3.3
>>> > is
>>> > stable.  So now is the time.
>>> >
>>> > Cheers,
>>> > Clinton
>>> >
>>> > On Thu, Sep 4, 2008 at 7:41 AM, Jeff Butler <[EMAIL PROTECTED]>
>>> wrote:
>>> >>
>>> >> I think you'll notice, from the lack of response to your many other
>>> posts
>>> >> about this, that publishing iBATIS2 into the central Maven repository
>>> >> is
>>> not
>>> >> a prioirity for any committer.  This will change with iBATIS3 when we
>>> use
>>> >> Maven to do the iBATIS build, but likely won't change for iBATIS2.
>>> >>
>>> >> For now, I suggest that you find a way to build your project with a
>>> local
>>> >> download of iBATIS2.  Surely Maven is capable of doing that - isn't
>>> >> it?
>>> >>
>>> >> Jeff Butler
>>> >>
>>> >>
>>> >> On Thu, Sep 4, 2008 at 8:29 AM, Zhubin Salehi <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> Could someone please upload iBATIS 2.3.3 to Maven central repo?
>>> >>>
>>> >>> Thanks,
>>> >>> Zhubin
>>> >>> --
>>> >>> View this message in context:
>>> >>>
>>>
>>>
http://www.nabble.com/New-iBATIS-builds-on-Maven-central-repository-tp19309009p19309009.html
>>> >>> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>
>
>

Re: proposal: announce 2.3.4 as GA

[Brandon Goodin]

The way i see it, if we consider something stable we push it out as GA. If
for some reason it fails to uphold to the quality standards of GA we can
always downgrade it to beta, fix it, and push it out a new release as GA.
The whole GA thing has more to do with terminology than anything. So as far
as I'm concerned GA is implicit when we release something. Am I wrong?

B

On Thu, Sep 18, 2008 at 1:04 AM, Kai Grabfelder <[EMAIL PROTECTED]> wrote:

> Hi there,
>
> is there anything that speak against promoting 2.3.4 (or possibly at least
> 2.3.3) as GA? 2.3.4 is already in
> the maven repos.
>
> Regards
>
> Kai
>
>

Re: proposal: announce 2.3.4 as GA

[Brandon Goodin]

Also, here is our policy:

http://opensource.atlassian.com/confluence/oss/display/IBATIS/iBATIS+Release+Process

Did we vote on 3.4? If not, we should probably do that so that we can
consider it GA.

B

On Thu, Sep 18, 2008 at 10:31 AM, Brandon Goodin
<[EMAIL PROTECTED]>wrote:

> The way i see it, if we consider something stable we push it out as GA. If
> for some reason it fails to uphold to the quality standards of GA we can
> always downgrade it to beta, fix it, and push it out a new release as GA.
> The whole GA thing has more to do with terminology than anything. So as far
> as I'm concerned GA is implicit when we release something. Am I wrong?
>
> B
>
>
> On Thu, Sep 18, 2008 at 1:04 AM, Kai Grabfelder <[EMAIL PROTECTED]> wrote:
>
>> Hi there,
>>
>> is there anything that speak against promoting 2.3.4 (or possibly at least
>> 2.3.3) as GA? 2.3.4 is already in
>> the maven repos.
>>
>> Regards
>>
>> Kai
>>
>>
>

[VOTE] Promote iBATIS 2.3.4 to General Availability

[Brandon Goodin]

This is a vote to promote iBATIS 2.3.4 to General Availability.

Brandon