Taste code committed

[Sean Owen <sr...@gmail.com>]

Hurray. There are a few more questions and tasks for me to follow up
on before this is all integrated.

0. (anyone see problems with where it is placed, style, etc? now's the
time to pick it apart)

1. For this second, I committed my own build.xml file as
taste-build.xml. Obviously that is not a long-term thing. I felt it
worth pausing to ask what I should do here, just integrate with the
normal build/test targets, and then adapt my other targets (such as
the one that builds an EJB) and copy them in? I'll probably want to
prefix the names with "taste-".

2. MySQL dependency. Funny, I realize that the only place my code
actually depends on the MySQL driver is in the test code. Not
surprising, since the main code properly accesses a DB via JDBC
abstractions. So that means that until you download and add the
mysql-connector-5.1.6 .jar file to lib/, it's just the tests that
won't compile. :) And they won't all pass until you run a MySQL
instance for it to test against. This is a bummer. I am sorely tempted
to remove the JDBC-related unit tests entirely. It's crappy to remove
good tests to appease a build system, but, here it's really tempting.
Support for this idea?

3. EJB dependency. I know there was some question about the license
status of the EJB/servlet .jar files. And while updating the pom.xml
dependencies I noted that for some reason the main Maven repo does not
have an EJB .jar. I know there was also some question about the
utility of the EJB interface, period. Seems like a waste to throw it
away, but, maybe should be placed in examples/ for whoever cares to
dust off and compile? that would be cool by me and simplify things a
little further.

4. Documentation. I will attempt to commit a revised version of my
documentation page. Any pointers on what to include and not include
and where to put it? It will be an adapted version of what is at
taste.sourceforge.net

Re: Taste code committed

[Sean Owen <sr...@gmail.com>]

I took the liberty of making this so, below, since I know the change
breaks the build right now unless you add the mysql connector .jar
file.

If it's not protocol to just commit like that, let me know.

I'm going to proceed with moving the EJB code out to examples.

I'm going to open an ISSUE about my documentation and one of two other items.

Sean

On Fri, May 9, 2008 at 10:23 PM, Sean Owen <sr...@gmail.com> wrote:
> Bah, this didn't work out. MySQL supports some syntax I need that HSQL
> does not. The hacking to get around this got gross, and went so far
> that I'm not really testing the MySQL code anymore.
>
> I think I should nix the MySQL test code -- or else relegate it to
> something like examples/ ? I take it this is where we can put code we
> want to distribute but don't want to compile as part of the core. For
> example this seems like a good place for the EJB interface, maybe web
> interface.
>
> Incidentally what are the rules on commits -- should send any changes
> around for review as an ISSUE? if it's a clear change that I'm
> confident in, like in the code I'm familiar with, OK to just go ahead?
> I don't mind the overhead of reviews and issues.

Re: Taste code committed

[Sean Owen <sr...@gmail.com>]

Bah, this didn't work out. MySQL supports some syntax I need that HSQL
does not. The hacking to get around this got gross, and went so far
that I'm not really testing the MySQL code anymore.

I think I should nix the MySQL test code -- or else relegate it to
something like examples/ ? I take it this is where we can put code we
want to distribute but don't want to compile as part of the core. For
example this seems like a good place for the EJB interface, maybe web
interface.

Incidentally what are the rules on commits -- should send any changes
around for review as an ISSUE? if it's a clear change that I'm
confident in, like in the code I'm familiar with, OK to just go ahead?
I don't mind the overhead of reviews and issues.

Sean

On Fri, May 9, 2008 at 7:38 PM, Sean Owen <sr...@gmail.com> wrote:
> Yah I suppose I had wanted to test the "MySQLJDBCDataModel" against a
> real MySQL instance but in point of fact there is virtually no
> additional benefit to a real MySQL instance versus something else. I
> will go ahead and move to HSQL, good tip.
>
> On Fri, May 9, 2008 at 7:35 PM, Ted Dunning <te...@gmail.com> wrote:
>> It is pretty common to use HSQL in-memory as a framework for testing where a
>> transient database is needed.
>

Re: Taste code committed

[Sean Owen <sr...@gmail.com>]

Yah I suppose I had wanted to test the "MySQLJDBCDataModel" against a
real MySQL instance but in point of fact there is virtually no
additional benefit to a real MySQL instance versus something else. I
will go ahead and move to HSQL, good tip.

On Fri, May 9, 2008 at 7:35 PM, Ted Dunning <te...@gmail.com> wrote:
> It is pretty common to use HSQL in-memory as a framework for testing where a
> transient database is needed.

Re: Taste code committed

[Ted Dunning <te...@gmail.com>]

It is pretty common to use HSQL in-memory as a framework for testing where a
transient database is needed.

On Fri, May 9, 2008 at 2:42 PM, Sean Owen <sr...@gmail.com> wrote:

>
> 2. MySQL dependency. Funny, I realize that the only place my code
> actually depends on the MySQL driver is in the test code. Not
> surprising, since the main code properly accesses a DB via JDBC
> abstractions. So that means that until you download and add the
> mysql-connector-5.1.6 .jar file to lib/, it's just the tests that
> won't compile. :) And they won't all pass until you run a MySQL
> instance for it to test against. This is a bummer. I am sorely tempted
> to remove the JDBC-related unit tests entirely. It's crappy to remove
> good tests to appease a build system, but, here it's really tempting.
> Support for this idea?
>
>