You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2010/02/22 22:36:27 UTC

Re: [DISCUSSION] Aries release - common assembly

Hi Don, (hope you don't mind I've separated this discussion out)

On 19 February 2010 16:27, Donald Woods <dw...@apache.org> wrote:
> What about creating a common assembly under samples based on the current
> blog-assembly, which would allow users to drop-in the Blog, AriesTrader
> or their own wab/eba?

So are you suggesting making blog-assembly a module purely for
building the blog sample assembly - .eba file. Then to have a child
module of samples whose target dir would act as a place to run the
OSGi framework, contain the 'load' dir for samples to be dropped into?
I think it's good to separate these concerns out. So I'm +1 for this
(if it's what you meant :-)

>
>
> -Donald
>
>
> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>>
>

Re: [DISCUSSION] Aries release - common assembly

Posted by Donald Woods <dw...@apache.org>.
Yes, that's what I was looking for - one assembly that users could then
drop blog, trader, ... into instead of requiring unique assemblies for each.

-Donald


On 2/22/10 4:36 PM, Jeremy Hughes wrote:
> Hi Don, (hope you don't mind I've separated this discussion out)
> 
> On 19 February 2010 16:27, Donald Woods <dw...@apache.org> wrote:
>> What about creating a common assembly under samples based on the current
>> blog-assembly, which would allow users to drop-in the Blog, AriesTrader
>> or their own wab/eba?
> 
> So are you suggesting making blog-assembly a module purely for
> building the blog sample assembly - .eba file. Then to have a child
> module of samples whose target dir would act as a place to run the
> OSGi framework, contain the 'load' dir for samples to be dropped into?
> I think it's good to separate these concerns out. So I'm +1 for this
> (if it's what you meant :-)
> 
>>
>>
>> -Donald
>>
>>
>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
> 

Re: [DISCUSSION] Aries release - common assembly

Posted by Donald Woods <dw...@apache.org>.

On 2/22/10 4:54 PM, Joe Bohn wrote:
> I think this is a good idea.  At the moment there is some duplication
> between Blog Sample and other samples like AriesTrader (and even in
> multiple places in AriesTrader).  It would be great to have at least one
> common Equinox assembly (and perhaps a common Felix assembly as well)
> that included as much of the core components as possible with some
> default implementations (such as OpenJPA, Derby, etc...) which could be
> used to host our different samples.
> 
> We'd have to make it clear that the assembly is not a production quality
> thing and just for running samples and such so that nobody used it in an
> inappropriate way.

As long as the assembly lives under /samples, then it would be clear to
me that it was not for "production usage", but we should also include
some notice in the assembly readme that this is for testing/learning
purposes only.

> 
> Also, give that we'd like to use it for multiple samples, I think it
> should be named something more generic than "blog-assembly" - perhaps
> "samples/assemblies/equinox-assembly" ?  Of course, that gets me
> wondering again if AriesTrader should be under samples rather than a
> peer to samples if it is to exploit this same assembly (which I think it
> should).

Was wondering why it wasn't under samples... :-) In my mind, if it's not
under samples, then it should be considered another module like jpa,
blueprint, ... that can be reused by other apps.  So +1 to moving
ariestrader under assemblies before the 0.1 release.

-Donald

> 
> Joe
> 
> 
> Jeremy Hughes wrote:
>> Hi Don, (hope you don't mind I've separated this discussion out)
>>
>> On 19 February 2010 16:27, Donald Woods <dw...@apache.org> wrote:
>>> What about creating a common assembly under samples based on the current
>>> blog-assembly, which would allow users to drop-in the Blog, AriesTrader
>>> or their own wab/eba?
>>
>> So are you suggesting making blog-assembly a module purely for
>> building the blog sample assembly - .eba file. Then to have a child
>> module of samples whose target dir would act as a place to run the
>> OSGi framework, contain the 'load' dir for samples to be dropped into?
>> I think it's good to separate these concerns out. So I'm +1 for this
>> (if it's what you meant :-)
>>
>>>
>>> -Donald
>>>
>>>
>>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>> release so we can get some wider user feedback. I think we should give
>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>> Incubator.
>>>>
>>>> Then there is the question of whether to independently version the
>>>> high level modules or keep them lock-step. For now I think we should
>>>> keep them lock-step until we feel a need to change that.
>>>>
>>>> What does everyone think?
>>>>
>>>> Thanks,
>>>> Jeremy
>>>>
>>
> 
> 

Re: [DISCUSSION] Aries release - common assembly

Posted by Joe Bohn <jo...@gmail.com>.
I think this is a good idea.  At the moment there is some duplication 
between Blog Sample and other samples like AriesTrader (and even in 
multiple places in AriesTrader).  It would be great to have at least one 
common Equinox assembly (and perhaps a common Felix assembly as well) 
that included as much of the core components as possible with some 
default implementations (such as OpenJPA, Derby, etc...) which could be 
used to host our different samples.

We'd have to make it clear that the assembly is not a production quality 
thing and just for running samples and such so that nobody used it in an 
inappropriate way.

Also, give that we'd like to use it for multiple samples, I think it 
should be named something more generic than "blog-assembly" - perhaps 
"samples/assemblies/equinox-assembly" ?  Of course, that gets me 
wondering again if AriesTrader should be under samples rather than a 
peer to samples if it is to exploit this same assembly (which I think it 
should).

Joe


Jeremy Hughes wrote:
> Hi Don, (hope you don't mind I've separated this discussion out)
> 
> On 19 February 2010 16:27, Donald Woods <dw...@apache.org> wrote:
>> What about creating a common assembly under samples based on the current
>> blog-assembly, which would allow users to drop-in the Blog, AriesTrader
>> or their own wab/eba?
> 
> So are you suggesting making blog-assembly a module purely for
> building the blog sample assembly - .eba file. Then to have a child
> module of samples whose target dir would act as a place to run the
> OSGi framework, contain the 'load' dir for samples to be dropped into?
> I think it's good to separate these concerns out. So I'm +1 for this
> (if it's what you meant :-)
> 
>>
>> -Donald
>>
>>
>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>>
> 


-- 
Joe