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.
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
--
Joe
