aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: Aries release - the shape of repo org/apache/aries
Date Mon, 15 Mar 2010 12:43:48 GMT
Joe Bohn wrote:
> zoe slattery wrote:
>> Hi Jeremy
>>> These artifacts to have groupId:
>>> blog-0.1-incubating.jar (TODO: this isn't an 'uber' bundle so doesn't
>>> follow the pattern the blueprint 'uber' bundle has set. I'd like
>>> consistency so I propose renaming to blog-biz. So call this
>>>     artifactId:
>>> blog-api-0.1-incubating.jar (TODO: change to
>>>     artifactId:
>>> blog-datasource-0.1-incubating.jar
>>>     artifactId:
>>> blog-persistence-0.1-incubating.jar (TODO: since we now have two
>>> persistence impls we should change this to
>>> ...)
>>>     artifactId:
>>> blog-persistence-jpa-0.1-incubating.jar
>>>     artifactId:
>>> blog-servlet-0.1-incubating.jar (TODO: to be consistent with the spec
>>> names we should call this 'web' instead of 'servlet' so change this to
>>> ...)
>>>     artifactId:
>> This all sounds sensible to me, I'll fix as you suggest.
>>> These artifacts to have groupId: 
>>> org.apache.aries.samples.blueprint.helloworld:
>>> blueprint-helloworld-api-0.1-incubating.jar (TODO: change to
>>> org.apache.aries.samples.blueprint.helloworld.api...)
>>>     artifactId: org.apache.aries.samples.blueprint.helloworld.api
>>> blueprint-helloworld-client-0.1-incubating.jar (TODO: change to 
>>> ...client...)
>>>     artifactId: org.apache.aries.samples.blueprint.helloworld.client
>>> blueprint-helloworld-server-0.1-incubating.jar (TODO: change to 
>>> ...server...)
>>>     artifactId: org.apache.aries.samples.blueprint.helloworld.server
>> Same with this one.
>>> These artifacts to have groupId: 
>>> org.apache.aries.samples.blueprint.idverifier:
>>> org.apache.aries.samples.blueprint.idverifier.api-0.1-incubating.jar
>>>     artifactId: org.apache.aries.samples.blueprint.idverifier.api
>>> org.apache.aries.samples.blueprint.idverifier.client-0.1-incubating.jar
>>>     artifactId: org.apache.aries.samples.blueprint.idverifier.client
>>> org.apache.aries.samples.blueprint.idverifier.server-0.1-incubating.jar
>>>     artifactId: org.apache.aries.samples.blueprint.idverifier.server
>>> These artifacts to have groupId: org.apache.aries.samples.transaction:
>>> transaction-sample-web-0.1-incubating.jar (TODO: change to
>>> org.apache.aries.samples.transaction.web...)
>>>     artifactId: org.apache.aries.samples.transaction.web
>> A couple of general points about samples and releasing them:
>> 1) I don't think we should release samples for which there is no 
>> documentation on the Aries web pages. Sorry to be a pain about this :-)
>> 2) Sample 'assemblies'. At the moment most of the samples have a 
>> 'platform assembly' project which copies all the jars required to run 
>> the sample into a target directory and provides some minimal 
>> configuration. I think it might be a good idea to package the 
>> platforms as tar and/or zip files and make them available along with 
>> the sample jars. I think the right way to do this is probably (I'd 
>> like advice on this, I'm definitely not a Maven expert) to change the 
>> platform assembly projects to use the maven assembly plugin to create 
>> zip/tar files. I'll raise a JIRA as a sub task of 173 if you think 
>> this is the right thing to do.
> Creating the zip/tar is certainly one possible solution.  If we decide 
> to go that route then the first mechanism that comes to my mind is the 
> maven-assembly-plugin (but I'm no maven expert either).   I'm not 
> opposed to building the zip/tar of the platform assemblies - but I 
> wonder if it is really necessary.
> I suspect anyone interested in using the samples will most likely be 
> doing it for one of 2 reasons:
> 1) To use it as a developer sample on the 'platform assembly' or some 
> other Aries enabled assembly with the goal being to better understand 
> the Aries programming model.  If this is case it will be a developer 
> who will most likely want more than just a runtime.  They'll want to 
> step through code and perhaps make changes to see the results.  If 
> that is the case then it seems likely that they will grab the source 
> and will most likely need to build the sample (including the platform 
> assembly).
> 2) To try out the eba on some other aries enabled assembly (when they 
> exist) - in which case the 'platform assembly' won't be necessary.
Good points. I think there is also a third type of user though, it's the 
person who wants to know what Aries is about but doesn't want (at that 
point) to invest enough time get involved in building it. Aries is a 
loosely related set of projects, having a simple way to hook the 
projects together and show people how to use them is important. For 
people that don't have much time to investigate having a simple 'unzip 
this and run it' release artifact would provide a low entry barrier - 
which might even be a first step towards further involvement.


> Joe
>>> I appreciate this might be disruptive, but IMO it's best to have (what
>>> I think is necessary) disruption done sooner rather than later.
>>> Please do comment on this proposal - I've tried to mark the changes
>>> with 'TODO' to help.
>>> Thanks,
>>> Jeremy

View raw message