On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:

OK. Sounds good. "o.a.openejb" it would be.

The reasons I want to leave the tests in one single module are manifold.

1) That is how they are today.
2) To split them, it would have to be someone from openejb. I have no
idea how they are structured.
3) My top priority now is to get the testsuite framework integrated
with the G build.

That's fine.  We can do that part later.

-David


Cheers
Prasad

On 11/1/06, David Blevins <[EMAIL PROTECTED]> wrote:

On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:

> On 10/30/06, David Blevins <[EMAIL PROTECTED]> wrote:
>>
>> On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
>>
>> > Thanx. Please see comments inline -
>> >
>
>> >> Couple thoughts on the poms:
>> >>
>> >>    - the parent would lineage would be
>> org.apache.openejb:itests ->
>> >> org.apache.openejb:openejb
>> >>    - the groupId would be org.apache.openejb
>> >
>> > The groupId and the parent lineage looks good. As stated above,
>> there
>> > would be many child modules for the beans under the itests parent
>> > module
>> >
>> > groupId: o.a.openejb
>> > openejb -> itests -> itests-security-xxx
>> > openejb -> itests -> itests-cmp2-xxx
>>
>> Exactly.
>>
>
> After having built the itest beans as per our discussion above, the
> contents of the openejb directory in m2 local repo  are -
> ${settings.localRepository}/org/apache/openejb/
>
> itests-cmp2-cmrmapping
> itests-cmp2-petstore
> itests-cmp2-prefetch
> itests-cmp2-storage
> itests-itests-core
> itests-security-001
> itests-security-002
> itests-security-003
> openejb
> openejb-builder
> openejb-corba
> openejb-corba-builder
> openejb-core
> openejb-itests
> openejb-pkgen-builder
> openejb-sunorb
> openejb-yoko
>
> Does this look good ?  Or should we move the itests artifacts one
> level down to groupId "o.a.openejb.itests" ?

Let's keep it in o.a.openejb for now as that's the way it is in 3.x.

> For now, I shall put all the tests into 1 artifact module. We should
> look at breaking them and putting them with their respective bean
> modules later on.

What's the issue with doing that now?

-David




Reply via email to