Hi - As far as I understand it the samples are not building as part of
the regular Hudson build at the moment, they are certainly not listed as
a module in the top level pom. I hadn't added them because I was
slightly concerned about the time it would take to build and assemble
them as part of the regular build. However, I would like to have them
building regularly and used as tests somehow, adding a very big sample
to them right now doesn't seem quite the right thing to do.
I would really like to have the daytrader code in Aries and think it
would be helpful to have a fairly complex application. So, my preference
would be not to put daytrader in samples (at least to start with), it
sounds (I don't know the code) big enough to merit a separate module
then if there are problems because of its complexity we can easily
separate it out.
Zoe
+1 to putting it under samples at least for now!
Jeremy
2010/1/12 Alasdair Nottingham <[email protected]>:
I would stick with putting it under samples for now. We can always move it
later and we have not discussed releases yet, so we cannot know what
implications there are for release if it is under samples.
Alasdair
On 12 Jan 2010, at 19:17, Joe Bohn <[email protected]> wrote:
Good points Lin. Perhaps we should consider another location under Aries
trunk ... or we can check it in initially under trunk/samples and move it if
it proves to be an issue.
Regarding the itest ... sure, we should give that some consideration. I'd
personally have to understand the current itests better and the capabilities
before I could assert that daytrader could be added in for additional
testing.
Joe
Lin Sun wrote:
Hi Joe,
I think it makes sense to have the new daytrader in apache aries.
Just wondering if you want to have it under trunk/samples or have a
separate directory for daytrader so that you could release daytrader
separately like daytrader in Geronimo. Another advantage of doing
this separately is that people can easily build the samples without
building daytrader which i know sometimes we have trouble to build due
to its complexity.
Also wondering if it is possible to use the daytrader sample as part
of our itest after moving it over to apache aries.
Thanks
Lin
On Mon, Jan 11, 2010 at 2:57 PM, Joe Bohn <[email protected]> wrote:
Greetings all,
I've been working on a version of the Geronimo Daytrader performance
benchmark to leverage the enterprise OSGi application programming model.
I've been doing this work in my sandbox under Apache Geronimo
(https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn with the most
recent changes under daytrader-bp-new).
I'd like to find a more permanent location for this work and get it out
of
my sandbox.
Here is a brief description of what I have thus far in sandbox:
- A restructured Daytrader to support an enterprise OSGi application
programming model including blueprint, web container, jndi, jpa, etc...
- To further support this programming model I have also reorganized the
classes, packages, and bundles.
- Simplification and removal of content not yet available in the
enterprise
OSGi application programming model such as EJB support and removal of
Geronimo specific artifacts such as the plugins.
- Refactoring the way components gain knowledge of each other and
interact
to support blueprint concepts such as reference list and reference
listeners.
- Support for just two different persistence mechanisms - direct JDBC
and
direct JPA which are currently included in the enterprise OSGi
application
programming model.
- packaging using the Aries Application concepts.
After seeing the recently introduced Apache Aries Blog Sample and its
assembly for Equinox it encouraged me to do something similar for
Daytrader
so that I could get this running with Apache Aries. I now have a
further
subset of my sandbox work that could be added as a peer to the
blog-sample
which includes just the JDBC persistence mechanism, is hard-wired to
Derby,
and includes an Equinox assembly to run it. This is not currently in any
svn
because I did it on my local repository under aries/trunk/samples with
hopes
of checking it in there.
I think it is time to get this code to a better home and I'm currently
thinking that aries/trunk/samples is a good place to start. For now I
would
check in just the version with JDBC and the equinox assembly. However, I
would extend this with other capabilities already in my sandbox for JPA
persistence, the Aries Application packaging, etc... as these become
available in Aries.
I'm interested if others agree with this approach, if it seems like a
worthwhile endeavor, and if it is acceptable to include this code under
aries/trunk/samples.
Here are the current discussion points and concerns as I see them:
1) Duplication of code between Geronimo and Aries if I check it into
Aries.
However, the code is already split from the JavaEE Daytrader version and
I
doubt it would be possible to fully merge the code base and keep both
the
JavaEE and Aries versions working from a common code base without
cluttering
up the code with environment checks. So, even if we keep it all in
Geronimo I think we will still end up with multiple code streams.
2) The Equinox assembly version for DayTrader currently doesn't exploit
anything directly in Apache Geronimo. It depends upon the pax web
container
among other things. It is certainly my intention that this should run
on
Geronimo when Geronimo supports osgi rfc 66 among other things. However
it
seems strange to include this in Geronimo at this point in time.
3) Daytrader has always supported running in multiple web containers. I
think moving this enterprise OSGi application version of Daytrader to
Aries
further supports this goal and ensures that it won't become too tightly
coupled to Geronimo.
My apologies for the length of this description. Please let me know
your
thoughts - especially if you have any concerns with checking this
version of
Daytrader in under
https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
Thanks,
Joe
--
Joe
