[ANNOUCEMENT] MyBatis 3.1.0 released

[Rafael Ponte]

Actually I've been working on a few projects and I've been using those tasks which works like some aliases for MyBatis Migrations commands.

They're making my life easier ;-)

https://github.com/rponte/mybatis-migrations-anttasks

I'll implement the real tasks for Ant asap, this way it'll be just necessary to put the jar on classpath and import/declare the tasks into your own build.xml.

On Apr 17, 2012 4:41 AM, "Riccardo" <[hidden email]> wrote:

Thanks Eduardo.
Clinton, I usually launch migrations through my ant build. With
migrations 3.0.x this worked:

<target name="migrations">
       <java classname="org.apache.ibatis.migration.Migrator" fork="true"
output="${deploy.dir}/mybatis.log">
               <classpath>
                       <pathelement path="build/lib/mybatis-migrations-3.1.0-
SNAPSHOT.jar" />
               </classpath>
               <arg value="--path=${migrate.basepath}" />
               <arg value="--env=${migrate.env}" />
               <arg value="${migrate.command}" />
               <arg value="${migrate.args}" />
       </java>
</target>

the jdbc drivers were loaded from the ${migrate.basepath}/drivers
directory, without having to explicitely add them in the classpath
element.
Since 3.1.x I have to add mybatis (which as I said is absolutely fine
with me, makes perfect sense) and the jdbc drivers, otherwise I get
NoClassDefFound, No suitable driver and such:

<classpath>
       <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar" /
>
       <pathelement path="build/lib/mybatis-3.1.0.jar" />
       <fileset dir="${migrate.basepath}/drivers/">
               <include name="**/*.jar"/>
       </fileset>
</classpath>

That seems a big change, but maybe, as you said, you moved the part
where it loaded the drivers to the shell script (which I don't use).
This is fine with me, I simply didn't expect such a change in a minor
release.

Thanks,
Riccardo
On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> What do you mean by "on the classpath"... as in the environment variable?
>  If so, that should not be the case (I don't even set a classpath
> environment variable at all).
>
> But the shell scripts that run the migrator have always added the drivers
> to the classpath.  If you're using Maven or the like, I'm not sure how
> they're added, but they do have to be on the classpath.
>
> Cheers,
> Clinton
>
>
>
>
>
>
>
> On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]> wrote:
> > Hello,
> > thanks to all Mybatis team for this release.
>
> > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > snapshot since I needed a recent patch.
> > I've noticed there has been quite a major dependencies "remix" since
> > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > classpath. I see the first dependency was included for reasons I
> > absolutely agree with, but the second one seems a big change on how
> > migrations works... is this a problem which needs to be addressed for
> > the release?
>
> > Bye,
> > Riccardo
>
> > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > Thank you Claus!

[Riccardo Cossu]

Hi Rafael,
they look good, but they depend on the script command; my approach,
although a lot more "barebone" than yours, has the advantage of being
portable across operating systems.
I strongly support the creation of the ant tasks, they would be the
ideal complement to the maven plugin and they could start from the
good parts in your work and mine; drop me a line if you need help for
that.

Bye,
Riccardo

On 18 Apr, 01:29, Rafael Ponte <[hidden email]> wrote:

> Actually I've been working on a few projects and I've been using those
> tasks which works like some aliases for MyBatis Migrations commands.
>
> They're making my life easier ;-)
>
> https://github.com/rponte/mybatis-migrations-anttasks
>
> I'll implement the real tasks for Ant asap, this way it'll be just
> necessary to put the jar on classpath and import/declare the tasks into
> your own build.xml.
> On Apr 17, 2012 4:41 AM, "Riccardo" <[hidden email]> wrote:
>
>
>
>
>
>
>
> > Thanks Eduardo.
> > Clinton, I usually launch migrations through my ant build. With
> > migrations 3.0.x this worked:
>
> > <target name="migrations">
> >        <java classname="org.apache.ibatis.migration.Migrator" fork="true"
> > output="${deploy.dir}/mybatis.log">
> >                <classpath>
> >                        <pathelement
> > path="build/lib/mybatis-migrations-3.1.0-
> > SNAPSHOT.jar" />
> >                </classpath>
> >                <arg value="--path=${migrate.basepath}" />
> >                <arg value="--env=${migrate.env}" />
> >                <arg value="${migrate.command}" />
> >                <arg value="${migrate.args}" />
> >        </java>
> > </target>
>
> > the jdbc drivers were loaded from the ${migrate.basepath}/drivers
> > directory, without having to explicitely add them in the classpath
> > element.
> > Since 3.1.x I have to add mybatis (which as I said is absolutely fine
> > with me, makes perfect sense) and the jdbc drivers, otherwise I get
> > NoClassDefFound, No suitable driver and such:
>
> > <classpath>
> >        <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar"
> > /
>
> >        <pathelement path="build/lib/mybatis-3.1.0.jar" />
> >        <fileset dir="${migrate.basepath}/drivers/">
> >                <include name="**/*.jar"/>
> >        </fileset>
> > </classpath>
>
> > That seems a big change, but maybe, as you said, you moved the part
> > where it loaded the drivers to the shell script (which I don't use).
> > This is fine with me, I simply didn't expect such a change in a minor
> > release.
>
> > Thanks,
> > Riccardo
> > On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> > > What do you mean by "on the classpath"... as in the environment variable?
> > >  If so, that should not be the case (I don't even set a classpath
> > > environment variable at all).
>
> > > But the shell scripts that run the migrator have always added the drivers
> > > to the classpath.  If you're using Maven or the like, I'm not sure how
> > > they're added, but they do have to be on the classpath.
>
> > > Cheers,
> > > Clinton
>
> > > On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]>
> > wrote:
> > > > Hello,
> > > > thanks to all Mybatis team for this release.
>
> > > > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > > > snapshot since I needed a recent patch.
> > > > I've noticed there has been quite a major dependencies "remix" since
> > > > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > > > classpath. I see the first dependency was included for reasons I
> > > > absolutely agree with, but the second one seems a big change on how
> > > > migrations works... is this a problem which needs to be addressed for
> > > > the release?
>
> > > > Bye,
> > > > Riccardo
>
> > > > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > > > Thank you Claus!

[Rafael Ponte]

Hi Riccardo,

I didn't get your point about "has the advantage of being portable across operating systems". I mean that an Ant script is portable across OS already, or at least it should be.

On Apr 18, 2012 7:21 AM, "Riccardo" <[hidden email]> wrote:

Hi Rafael,
they look good, but they depend on the script command; my approach,
although a lot more "barebone" than yours, has the advantage of being
portable across operating systems.
I strongly support the creation of the ant tasks, they would be the
ideal complement to the maven plugin and they could start from the
good parts in your work and mine; drop me a line if you need help for
that.

Bye,
Riccardo

On 18 Apr, 01:29, Rafael Ponte <[hidden email]> wrote:
> Actually I've been working on a few projects and I've been using those
> tasks which works like some aliases for MyBatis Migrations commands.
>
> They're making my life easier ;-)
>
> https://github.com/rponte/mybatis-migrations-anttasks
>
> I'll implement the real tasks for Ant asap, this way it'll be just
> necessary to put the jar on classpath and import/declare the tasks into
> your own build.xml.
> On Apr 17, 2012 4:41 AM, "Riccardo" <[hidden email]> wrote:
>
>
>
>
>
>
>
> > Thanks Eduardo.
> > Clinton, I usually launch migrations through my ant build. With
> > migrations 3.0.x this worked:
>
> > <target name="migrations">
> >        <java classname="org.apache.ibatis.migration.Migrator" fork="true"
> > output="${deploy.dir}/mybatis.log">
> >                <classpath>
> >                        <pathelement
> > path="build/lib/mybatis-migrations-3.1.0-
> > SNAPSHOT.jar" />
> >                </classpath>
> >                <arg value="--path=${migrate.basepath}" />
> >                <arg value="--env=${migrate.env}" />
> >                <arg value="${migrate.command}" />
> >                <arg value="${migrate.args}" />
> >        </java>
> > </target>
>
> > the jdbc drivers were loaded from the ${migrate.basepath}/drivers
> > directory, without having to explicitely add them in the classpath
> > element.
> > Since 3.1.x I have to add mybatis (which as I said is absolutely fine
> > with me, makes perfect sense) and the jdbc drivers, otherwise I get
> > NoClassDefFound, No suitable driver and such:
>
> > <classpath>
> >        <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar"
> > /
>
> >        <pathelement path="build/lib/mybatis-3.1.0.jar" />
> >        <fileset dir="${migrate.basepath}/drivers/">
> >                <include name="**/*.jar"/>
> >        </fileset>
> > </classpath>
>
> > That seems a big change, but maybe, as you said, you moved the part
> > where it loaded the drivers to the shell script (which I don't use).
> > This is fine with me, I simply didn't expect such a change in a minor
> > release.
>
> > Thanks,
> > Riccardo
> > On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> > > What do you mean by "on the classpath"... as in the environment variable?
> > >  If so, that should not be the case (I don't even set a classpath
> > > environment variable at all).
>
> > > But the shell scripts that run the migrator have always added the drivers
> > > to the classpath.  If you're using Maven or the like, I'm not sure how
> > > they're added, but they do have to be on the classpath.
>
> > > Cheers,
> > > Clinton
>
> > > On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]>
> > wrote:
> > > > Hello,
> > > > thanks to all Mybatis team for this release.
>
> > > > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > > > snapshot since I needed a recent patch.
> > > > I've noticed there has been quite a major dependencies "remix" since
> > > > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > > > classpath. I see the first dependency was included for reasons I
> > > > absolutely agree with, but the second one seems a big change on how
> > > > migrations works... is this a problem which needs to be addressed for
> > > > the release?
>
> > > > Bye,
> > > > Riccardo
>
> > > > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > > > Thank you Claus!

[Riccardo Cossu]

You're right Rafael, I was deceived by the presence of "migrate" file
in the git repository.
Both my approach and yours is fully portable across OS's :-)
Let me know if you need help for the ant task,
bye,
Riccardo

On 18 Apr, 15:00, Rafael Ponte <[hidden email]> wrote:

> Hi Riccardo,
>
> I didn't get your point about "has the advantage of being portable across
> operating systems". I mean that an Ant script is portable across OS
> already, or at least it should be.
> On Apr 18, 2012 7:21 AM, "Riccardo" <[hidden email]> wrote:
>
>
>
>
>
>
>
> > Hi Rafael,
> > they look good, but they depend on the script command; my approach,
> > although a lot more "barebone" than yours, has the advantage of being
> > portable across operating systems.
> > I strongly support the creation of the ant tasks, they would be the
> > ideal complement to the maven plugin and they could start from the
> > good parts in your work and mine; drop me a line if you need help for
> > that.
>
> > Bye,
> > Riccardo
>
> > On 18 Apr, 01:29, Rafael Ponte <[hidden email]> wrote:
> > > Actually I've been working on a few projects and I've been using those
> > > tasks which works like some aliases for MyBatis Migrations commands.
>
> > > They're making my life easier ;-)
>
> > >https://github.com/rponte/mybatis-migrations-anttasks
>
> > > I'll implement the real tasks for Ant asap, this way it'll be just
> > > necessary to put the jar on classpath and import/declare the tasks into
> > > your own build.xml.
> > > On Apr 17, 2012 4:41 AM, "Riccardo" <[hidden email]> wrote:
>
> > > > Thanks Eduardo.
> > > > Clinton, I usually launch migrations through my ant build. With
> > > > migrations 3.0.x this worked:
>
> > > > <target name="migrations">
> > > >        <java classname="org.apache.ibatis.migration.Migrator"
> > fork="true"
> > > > output="${deploy.dir}/mybatis.log">
> > > >                <classpath>
> > > >                        <pathelement
> > > > path="build/lib/mybatis-migrations-3.1.0-
> > > > SNAPSHOT.jar" />
> > > >                </classpath>
> > > >                <arg value="--path=${migrate.basepath}" />
> > > >                <arg value="--env=${migrate.env}" />
> > > >                <arg value="${migrate.command}" />
> > > >                <arg value="${migrate.args}" />
> > > >        </java>
> > > > </target>
>
> > > > the jdbc drivers were loaded from the ${migrate.basepath}/drivers
> > > > directory, without having to explicitely add them in the classpath
> > > > element.
> > > > Since 3.1.x I have to add mybatis (which as I said is absolutely fine
> > > > with me, makes perfect sense) and the jdbc drivers, otherwise I get
> > > > NoClassDefFound, No suitable driver and such:
>
> > > > <classpath>
> > > >        <pathelement
> > path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar"
> > > > /
>
> > > >        <pathelement path="build/lib/mybatis-3.1.0.jar" />
> > > >        <fileset dir="${migrate.basepath}/drivers/">
> > > >                <include name="**/*.jar"/>
> > > >        </fileset>
> > > > </classpath>
>
> > > > That seems a big change, but maybe, as you said, you moved the part
> > > > where it loaded the drivers to the shell script (which I don't use).
> > > > This is fine with me, I simply didn't expect such a change in a minor
> > > > release.
>
> > > > Thanks,
> > > > Riccardo
> > > > On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> > > > > What do you mean by "on the classpath"... as in the environment
> > variable?
> > > > >  If so, that should not be the case (I don't even set a classpath
> > > > > environment variable at all).
>
> > > > > But the shell scripts that run the migrator have always added the
> > drivers
> > > > > to the classpath.  If you're using Maven or the like, I'm not sure
> > how
> > > > > they're added, but they do have to be on the classpath.
>
> > > > > Cheers,
> > > > > Clinton
>
> > > > > On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]>
> > > > wrote:
> > > > > > Hello,
> > > > > > thanks to all Mybatis team for this release.
>
> > > > > > When will migrations 3.1.0 be out? I'm currenlty using a self
> > packaged
> > > > > > snapshot since I needed a recent patch.
> > > > > > I've noticed there has been quite a major dependencies "remix"
> > since
> > > > > > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > > > > > classpath. I see the first dependency was included for reasons I
> > > > > > absolutely agree with, but the second one seems a big change on how
> > > > > > migrations works... is this a problem which needs to be addressed
> > for
> > > > > > the release?
>
> > > > > > Bye,
> > > > > > Riccardo
>
> > > > > > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > > > > > Thank you Claus!

[Clinton Begin]

Hmm.. I can't imagine how or what could have changed that.  Migrations depends entirely on the shell scripts to set the classpath, so I wonder if this is a coincidence?  It seems like it would have more to do with Ant or a classpath element option or something. 

On Tue, Apr 17, 2012 at 1:41 AM, Riccardo <[hidden email]> wrote:

Thanks Eduardo.
Clinton, I usually launch migrations through my ant build. With
migrations 3.0.x this worked:

<target name="migrations">
       <java classname="org.apache.ibatis.migration.Migrator" fork="true"
output="${deploy.dir}/mybatis.log">
               <classpath>
                       <pathelement path="build/lib/mybatis-migrations-3.1.0-
SNAPSHOT.jar" />
               </classpath>
               <arg value="--path=${migrate.basepath}" />
               <arg value="--env=${migrate.env}" />
               <arg value="${migrate.command}" />
               <arg value="${migrate.args}" />
       </java>
</target>

the jdbc drivers were loaded from the ${migrate.basepath}/drivers
directory, without having to explicitely add them in the classpath
element.
Since 3.1.x I have to add mybatis (which as I said is absolutely fine
with me, makes perfect sense) and the jdbc drivers, otherwise I get
NoClassDefFound, No suitable driver and such:

<classpath>
       <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar" /
>
       <pathelement path="build/lib/mybatis-3.1.0.jar" />
       <fileset dir="${migrate.basepath}/drivers/">
               <include name="**/*.jar"/>
       </fileset>
</classpath>

That seems a big change, but maybe, as you said, you moved the part
where it loaded the drivers to the shell script (which I don't use).
This is fine with me, I simply didn't expect such a change in a minor
release.

Thanks,
Riccardo

On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> What do you mean by "on the classpath"... as in the environment variable?
>  If so, that should not be the case (I don't even set a classpath
> environment variable at all).
>
> But the shell scripts that run the migrator have always added the drivers
> to the classpath.  If you're using Maven or the like, I'm not sure how
> they're added, but they do have to be on the classpath.
>
> Cheers,
> Clinton
>
>
>
>
>
>
>

> On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]> wrote:
> > Hello,
> > thanks to all Mybatis team for this release.
>
> > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > snapshot since I needed a recent patch.
> > I've noticed there has been quite a major dependencies "remix" since
> > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > classpath. I see the first dependency was included for reasons I
> > absolutely agree with, but the second one seems a big change on how
> > migrations works... is this a problem which needs to be addressed for
> > the release?
>
> > Bye,
> > Riccardo
>
> > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > Thank you Claus!

[Clinton Begin]

Oh, my bad... apologies.  The drivers are dynamically loaded... I was thinking of the mybatis jar itself.  

And there was a change recently, to allow for drivers to exist outside of the environment directory.  Sorry for the confusion.

I'll play around with it before the release to see if anything can be done.

Cheers,

Clinton

On Thu, Apr 19, 2012 at 12:28 PM, Clinton Begin <[hidden email]> wrote:

Hmm.. I can't imagine how or what could have changed that.  Migrations depends entirely on the shell scripts to set the classpath, so I wonder if this is a coincidence?  It seems like it would have more to do with Ant or a classpath element option or something. 

On Tue, Apr 17, 2012 at 1:41 AM, Riccardo <[hidden email]> wrote:

Thanks Eduardo.
Clinton, I usually launch migrations through my ant build. With
migrations 3.0.x this worked:

<target name="migrations">
       <java classname="org.apache.ibatis.migration.Migrator" fork="true"
output="${deploy.dir}/mybatis.log">
               <classpath>
                       <pathelement path="build/lib/mybatis-migrations-3.1.0-
SNAPSHOT.jar" />
               </classpath>
               <arg value="--path=${migrate.basepath}" />
               <arg value="--env=${migrate.env}" />
               <arg value="${migrate.command}" />
               <arg value="${migrate.args}" />
       </java>
</target>

the jdbc drivers were loaded from the ${migrate.basepath}/drivers
directory, without having to explicitely add them in the classpath
element.
Since 3.1.x I have to add mybatis (which as I said is absolutely fine
with me, makes perfect sense) and the jdbc drivers, otherwise I get
NoClassDefFound, No suitable driver and such:

<classpath>
       <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar" /
>
       <pathelement path="build/lib/mybatis-3.1.0.jar" />
       <fileset dir="${migrate.basepath}/drivers/">
               <include name="**/*.jar"/>
       </fileset>
</classpath>

That seems a big change, but maybe, as you said, you moved the part
where it loaded the drivers to the shell script (which I don't use).
This is fine with me, I simply didn't expect such a change in a minor
release.

Thanks,
Riccardo

On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> What do you mean by "on the classpath"... as in the environment variable?
>  If so, that should not be the case (I don't even set a classpath
> environment variable at all).
>
> But the shell scripts that run the migrator have always added the drivers
> to the classpath.  If you're using Maven or the like, I'm not sure how
> they're added, but they do have to be on the classpath.
>
> Cheers,
> Clinton
>
>
>
>
>
>
>

> On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]> wrote:
> > Hello,
> > thanks to all Mybatis team for this release.
>
> > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > snapshot since I needed a recent patch.
> > I've noticed there has been quite a major dependencies "remix" since
> > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > classpath. I see the first dependency was included for reasons I
> > absolutely agree with, but the second one seems a big change on how
> > migrations works... is this a problem which needs to be addressed for
> > the release?
>
> > Bye,
> > Riccardo
>
> > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > Thank you Claus!

[Riccardo Cossu]

Hi Clinton,
I don't know either, but I assure you that the only thing that changes
between a working configuration and a not working one in migration
version; version 3.0.x works without explicitely adding the drivers to
the classpath, version 3.1.x doesn't.
I guess it has to do with the refactoring that led to the additional
dependency on mybatis; you moved the classloading work to the script
file, but you "broke" something that worked before (launching the
Migrator class directly), maybe it just worked by mistake, or it
simply was not the correct way to do it anyway.
It is totally fine with me, I simply recommend adding this warning to
the release notes to avoid that those who upgrade loose time over this
strange behaviour; in that case migration 3.1 is not a drop in
replacement for 3.0.x, it just needs a small adjustment.

Thanks,
Riccardo

On 19 Apr, 20:28, Clinton Begin <[hidden email]> wrote:

> Hmm.. I can't imagine how or what could have changed that.  Migrations
> depends entirely on the shell scripts to set the classpath, so I wonder if
> this is a coincidence?  It seems like it would have more to do with Ant or
> a classpath element option or something.
>
>
>
>
>
>
>
> On Tue, Apr 17, 2012 at 1:41 AM, Riccardo <[hidden email]> wrote:
> > Thanks Eduardo.
> > Clinton, I usually launch migrations through my ant build. With
> > migrations 3.0.x this worked:
>
> > <target name="migrations">
> >        <java classname="org.apache.ibatis.migration.Migrator" fork="true"
> > output="${deploy.dir}/mybatis.log">
> >                <classpath>
> >                        <pathelement
> > path="build/lib/mybatis-migrations-3.1.0-
> > SNAPSHOT.jar" />
> >                </classpath>
> >                <arg value="--path=${migrate.basepath}" />
> >                <arg value="--env=${migrate.env}" />
> >                <arg value="${migrate.command}" />
> >                <arg value="${migrate.args}" />
> >        </java>
> > </target>
>
> > the jdbc drivers were loaded from the ${migrate.basepath}/drivers
> > directory, without having to explicitely add them in the classpath
> > element.
> > Since 3.1.x I have to add mybatis (which as I said is absolutely fine
> > with me, makes perfect sense) and the jdbc drivers, otherwise I get
> > NoClassDefFound, No suitable driver and such:
>
> > <classpath>
> >        <pathelement path="build/lib/mybatis-migrations-3.1.0-SNAPSHOT.jar"
> > /
>
> >        <pathelement path="build/lib/mybatis-3.1.0.jar" />
> >        <fileset dir="${migrate.basepath}/drivers/">
> >                <include name="**/*.jar"/>
> >        </fileset>
> > </classpath>
>
> > That seems a big change, but maybe, as you said, you moved the part
> > where it loaded the drivers to the shell script (which I don't use).
> > This is fine with me, I simply didn't expect such a change in a minor
> > release.
>
> > Thanks,
> > Riccardo
> > On 17 Apr, 00:08, Clinton Begin <[hidden email]> wrote:
> > > What do you mean by "on the classpath"... as in the environment variable?
> > >  If so, that should not be the case (I don't even set a classpath
> > > environment variable at all).
>
> > > But the shell scripts that run the migrator have always added the drivers
> > > to the classpath.  If you're using Maven or the like, I'm not sure how
> > > they're added, but they do have to be on the classpath.
>
> > > Cheers,
> > > Clinton
>
> > > On Fri, Apr 13, 2012 at 9:47 AM, Riccardo <[hidden email]>
> > wrote:
> > > > Hello,
> > > > thanks to all Mybatis team for this release.
>
> > > > When will migrations 3.1.0 be out? I'm currenlty using a self packaged
> > > > snapshot since I needed a recent patch.
> > > > I've noticed there has been quite a major dependencies "remix" since
> > > > 3.0.x: it now needs both mybatis and the jdbc drivers on the
> > > > classpath. I see the first dependency was included for reasons I
> > > > absolutely agree with, but the second one seems a big change on how
> > > > migrations works... is this a problem which needs to be addressed for
> > > > the release?
>
> > > > Bye,
> > > > Riccardo
>
> > > > On 18 Mar, 01:01, Eduardo <[hidden email]> wrote:
> > > > > Thank you Claus!