aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Date Thu, 14 Jan 2010 09:21:05 GMT
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 <zoe.slattery@googlemail.com>:
> 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 <not@apache.org>:
>>
>>>
>>> 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 <joebohn@gmail.com> 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 <joebohn@gmail.com> 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
not@apache.org

Mime
View raw message