On 31.07.2010 02:53, David Blevins wrote:
We have some wonderful contributors that have been active for a while we should
consider converting into committers.
Andy: You've been a constant source of ActiveMQ and resource adapter
goodness since January. It's always great to have users who are willing to
give back.
Thiago: You've been active since April. First implementing the reentrant
calls for @Stateful beans, then moving on to EJB 3.1 features like
@AccessTimeout support and partial @StatefulTimeout support and helping flush
out @DependsOn bugs.
Ivan: You've been doing fantastic work since May. First with the
MemoryTimerStore fixes, then some great EJB 3.1 features like
SessionSynchronization annotations and most recently @Schedule support.
As we say, it takes a village http://s.apache.org/It-takes-a-village
And in that spirit...
Andy, Thiago, Ivan: You have any feedback for us? Anything you think helped
you get into the project that we should keep doing? Any ideas for things we
could add as good habits for encouraging/helping new contributors?
All, same questions on the reverse. Anythings that Andy, Thiago, Ivan did that
you think all contributors should do? Any ideas for things they could add as
good habits?
-David
Hey All,
Sorry for not getting back sooner - was back in Blighty with the family,
and then straight back onto work.
I found OpenEJB about a year ago during research for a new client/server
project. I knew I wanted to use an EJB model, so looked into Glassfish,
JBoss and OpenEJB. It was quite easy to opt for OpenEJB over the others
- It's easy to configure, quick, lightweight and very very 'open'! I
have found the dev and user groups to be a great bunch of people who are
always ready to help out and answer questions - what more could anyone
want from an open source community!
I am using OpenEJB in both embedded mode on the client (as a local cache
backed by Derby) and as the core non-clustered standalone server (backed
by PostgreSQL). The only real OpenEJB specific development of the
application has been a custom deployer bean, which dynamically builds
and deploys template based application jars and data-sources.
The toughest part for me of getting into OpenEJB development has
actually been getting into Maven and the project structure. I had never
used it before, so had a few headaches getting builds to work - My
biggest tip on a persistent build error is to physically delete 'all'
target directories, as a clean build does not always really clean them
(very much a Maven issue). RTFM could be suggested here, but I think a
few pointers to the main pom requirements would help new users get
started. I use IntelliJ for our actual project, but have found Netbeans
to be much more useful when delving into OpenEJB code (IntelliJ dies
painfully on large Maven projects because it tries to open everything).
Top of my list (in no particular order) for OpenEJB would be: ...(and
please no finger wagging, these are just based on 'my' requirements - I
know we all have our own wish lists)
1. Place more weight on getting poms absolutely right before committing,
i.e no warnings or 'things' that make you go 'ooh' - I am as guilty as
anyone.
2. Trunk poms should be kept at the cutting/leading edge, i.e. all deps
using most up to date stable versions available (version numbers should
all be defined as properties in the top pom and then used as
<version>${blah-version}</version> etc. in child poms).
2a. When any jar version is updated nudge everyone to remove the old one
- See the "delete 'all' target directories" tip above ;-)
3. Forget Java 1.5, at least on the trunk - It feels more like 1.4 every
day, and 1.7 is just around the corner, so 1.6 should become the
minimum. This may be naive, but I doubt anyone will use 1.5 in a new
development.
4. All use Maven 3 on the trunk - It is only a beta in the same sense
that OpenEJB trunk is, we all know how stable it is.
5. Datasource deployment API for addition and removal of dynamic
data-sources during runtime - I often need to connect to and perform ops
on 'unknown' databases, and currently abuse the Assembler.class.
6. Strict UTF8 use on 'everything'.
7. Windows service integration - I already have this at my end, and
could introduce it quite quickly.
8. There's maybe more.... but I feel fingers wagging already ;-)
To sum up - I am not suggesting breaking backward compatibility (at
least not completely), but there should be a line drawn somewhere... and
trunk is usually a good place to start.
I'm sure I'll be using OpenEJB way into the future, and will continue to
tinker, fix and suggest improvements as I find them.
Best regards,
Andy.
