Joe Bohn wrote:
zoe slattery wrote:
Hi Jeremy
These artifacts to have groupId: org.apache.aries.samples.blog:
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
org.apache.aries.blog.biz...)
artifactId: org.apache.aries.samples.blog.biz
blog-api-0.1-incubating.jar (TODO: change to
org.apache.aries.samples.blog.api...)
artifactId: org.apache.aries.samples.blog.api
blog-datasource-0.1-incubating.jar
artifactId: org.apache.aries.samples.blog.datasource
blog-persistence-0.1-incubating.jar (TODO: since we now have two
persistence impls we should change this to
org.apache.aries.samples.blog.persistence.jdbc ...)
artifactId: org.apache.aries.samples.blog.persistence.jdbc
blog-persistence-jpa-0.1-incubating.jar
artifactId: org.apache.aries.samples.blog.persistence.jpa
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
org.apache.aries.samples.blog.web ...)
artifactId: org.apache.aries.samples.blog.web
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.
Zoe
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
