I think you should add the samples into the top level pom to ensure they are built. We can worry about build time later.
Alasdair 2010/1/14 zoe slattery <[email protected]>: > 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 >>>> >> >> > > -- Alasdair Nottingham [email protected]
