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 <[email protected]> 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 >>>> >> > >
