aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [DISCUSSION] Aries release - common assembly
Date Mon, 22 Feb 2010 21:54:57 GMT
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 


Jeremy Hughes wrote:
> Hi Don, (hope you don't mind I've separated this discussion out)
> On 19 February 2010 16:27, Donald Woods <> 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


View raw message