Maven quickstart archetype

[Kristof Jozsa]

Hi all,

I'm a newcomer to Salve, but currently I'm working on a maven
quickstart archetype integrating Salve, Guice and warp-persist using
EclipseLink as the JPA provider on embedded Derby, for saving the
bootstrap time for people using or evaluating these technologies.

The package features a couple of sample JPA entities with bi 1-n, n-n,
subclass, enum and embeddable value object mappings, a transactional
junit4 baseclass with sample tests for the entity mappings and uses a
DDD approach with the active record pattern. I'm trying to keep things
as easy and as minimal as I can, currently it's 6 java files + the
entities.

Do you think this could make a valuable contribution for the Salve
group? I'd be happy to share to get people rolling..

cheers,
Kristof Jozsa

[Igor Vaynberg]

i think something like this would be great to have, especially if it
also has an example project built up on top of it showcasing what you
can do with salve...

have you seen this? http://code.google.com/p/gluw/ its a somewhat similar stack.

feel free to show us what you have already and we can discuss more.

-igor

[Kristof Jozsa]

I've seen Gluw getting mentioned on the wicket-users list (being also
a wicket-fan myself), but checking the current gluw code, they seem to
aim at a slightly different target. I try to focus on an instantly
usable transactional JPA DI-stack and planned no web-integration in
the scope of the project. I compared our code but we don't even have
common parts: I'm not into writing base Repository implementations
(real-world repos has surprisingly few common points, even findAlls()
tend to be different with default entity order properties), and they
don't seem to care much about adding a DDD-enabled Entity base class
or a base test class dealing with transaction management.

Granted, a complete example project might appear more rounded, but it
takes more work, needs a cute theme (eg. the cheese shop) and then
future users need time to rip the features to get the project skeleton
I'm trying to provide them.

Igor, a tgz snapshot of my code is 11Kb (you can instantly do mvn test
on it with zero previous setup) but currently I'm unable to upload it
to any public locations. I can send it to you privately to have a
quick look if you're interested (I assume you usually dont attach such
to group lists).

Kristof

[Igor Vaynberg]

sure, im interested. feel free to email it to my gmail addr. you can
also attach it to the group if you want others to have a look. a
complete example might be more work but ive been meaning to build
something using salve anyways...so maybe i can take care of that.

-igor

[Kristof Jozsa]

ok, I uploaded the tgz to the group. Sure it needs some more love,
javadoc, better names for classes, etc, but as a proof of concept, it
mainly works. Just unpack it and either run 'mvn eclipse:eclipse' or
start running the tests directly with maven.

One of the problems I just realized is that 'mvn test' makes one test
fail while both tests run correctly standalone (mvn test
-Dtest=BasicMappingsTest and mvn test -Dtest=ComplexMappingsTest
succeeds). This is with the uploaded version fetched from my Hg repo,
my original working doesn't do that.. strange :)

K

[Igor Vaynberg]

wanted to try it but couldnt get warp-core installed locally into
maven repo. wish projects like that supported maven :(

one of the things i noticed is that it could potentially be cool to
build @Transactional support for warp-persist like there exists for
spring so you can put it on any method...

-igor

[Kristof Jozsa]

These steps help:

wget http://warp-persist.googlecode.com/svn/trunk/warp-persist/dist/warp-persist-1.0.1.jar
mvn install:install-file -DgroupId=warp-persist
-DartifactId=warp-persist -Dversion=1.0.1 -Dpackaging=jar
-Dfile=./warp-persist-1.0.1.jar

Anyway, I agree it's a pity that lots of projects don't care much
about providing maven artifacts. Using mvn for their build is a
personal choice, but I think the lack of maven artifact really sets
back their popularity.

I didn't really get your comment on @Transactional.. warp-persist has
one and it works correctly at both method at class level based on the
configuration:

forAll(Matchers.any()) for method=level and
forAll(Matchers.annotatedWith(Transactional.class), Matchers.any())
for class-level @Transactional usage.

I configured the latter in the example because I prefer clean
architectural layers with objects being clearly on either side of the
transaction boundary, not being here or there based on their methods'
annotations..

K

[Igor Vaynberg]

but that would only work for objects that are retrieved from
guice....what about objects that are not?

another problem is that it only works on methods if they are entered
through the proxy, at least that is how it works with spring, so if
you have

class bean {
@transactional void a() {}
void b() { a(); }
}

and you call

bean inst=guice.get(bean.class);
inst.b();

transaction is not invoked around a() because the call to a() is not
across the proxy boundary. this only applies to proxies, if you use a
weaver i think it should work fine.

anyways, what salve's spring txn integration does is to allow
@transactional on any method of any object by directly weaving the
transactional logic into that method...

-igor

[francisco treacy]

hi there,

> wanted to try it but couldnt get warp-core installed locally into
> maven repo. wish projects like that supported maven :(

sure, me too!!! this is one of the things i wanted when i published
gluw: to have all dependencies in maven repos. despite my messages
this is still a pending issue for dhanji and robbie.
http://groups.google.com/group/warp-core/browse_thread/thread/d43fcf7fb7b56d6f/af34279f297793c7
-> no replies after that post. i am going to insist :)

kristof, i agree projects are slightly different but still i mentioned
"In a near future I will see if it's worth to support other databases
and ORMs such as JPA/Hibernate". also, if you look the original thread
on the wicket mailing list, we discussed with nino and james who
proposed integrating this into maven archetypes. see replies here:
http://www.nabble.com/wicket-like-framework-to-complement-wicket--td19079579.html

> I compared our code but we don't even have
> common parts: I'm not into writing base Repository implementations
> (real-world repos has surprisingly few common points, even findAlls()
> tend to be different with default entity order properties),

true. but you can always override findAll() if it doesn't fit your
needs. http://code.google.com/p/gluw/wiki/Repositories

> and they
> don't seem to care much about adding a DDD-enabled Entity base class
> or a base test class dealing with transaction management.

well, i'm not into providing base entity classes - i prefer to leave
that to the client and this is what i meant with "Domain model
persistence without polluting it (at all) " - *although* i said:

ps: i should re-examine the way i'm handling getById(Serializable id).
as i don't force the end user to extend any particular domain base
class, i use a "string"/reflection-style ODB query -- which can cause
trouble if the id field is not present. will have to evaluate
tradeoffs of both approaches

the lack of features (and mostly better unit testing) it's basically
because i haven't had time to update - there are tons of things yet to
be done/ changed. i think it's great to have another project like
these out there. time will say if these ever get merged with each
other or not! just be sure to check out iolite, domdrides,
wicketopia.

francisco

[Kristof Jozsa]

correct, I didn't even start to think about that. Coming with many
years of spring-background, somehow I assumed all objects forming the
transactional boundery are managed and come from the DI container.
Also, you're right with the issue with crossing the proxy boundary but
I always felt it natural, never thought this as a problem.

I'll have a closer look at your spring transaction solution and think
it over if applying something similar will bring significant
advantages in my case.

K

[Kristof Jozsa]

hi francisco,

On Mon, Oct 6, 2008 at 10:22 PM, francisco treacy
<francisc...@gmail.com> wrote:
> well, i'm not into providing base entity classes - i prefer to leave
> that to the client and this is what i meant with "Domain model
> persistence without polluting it (at all) "

so basically you leave the choice of applying either the active record
pattern or using a repository for CRD operations to the client, right?
(also, the statement about your targets being slightly different
wasn't mean as any criticism at all, just a plain observation ;))

K

[Kristof Jozsa]

Igor,

are you working on this kind of transactional support for guice?

K

[Igor Vaynberg]

no i am not. i do not use guice day to day on any projects right now.

you, or anyone else, are more then welcome to contribute it.

it would not be against guice itself though, you would have to probably write it against warp persist which has @transactional support.

-igor