I'm trying to understand what the org/apache/aries maven repo space
will look like once we release our 0.1 artifacts.
AIUI, and based on release discussions so far, when we release the
artifacts they will be pushed up to Nexus by the maven release plugin.
Those artifacts in turn come from the local .m2 repo put there by mvn
install.
So I cleaned out my .m2/repository/org/apache/aries then did a mvn
clean install to see what was there. I think we need to move things
about a bit (or rather rename some artifactIds) to make our
artifactIds and groupIds consistently named. Later, after the 0.1
release, we could also improve things to make sure there is a
consistent relationship between source tree location and location of
the built artifact in the repo.
A built artifact is always given the name of the artifactId - and even
if there were a way of changing that, from an ease of understanding
point of view, we probably shouldn't as that is what anyone who uses
maven assumes.
Many of our bundle artifacts (all except the samples) follow the
<package name>-<version> naming convention which means their
artifactIds also do - this is the same as the bundle artifacts of the
Felix subprojects. So I suggest we follow the same pattern applying it
across the samples too. This has the effect of giving us uniquely
named artifactIds across the whole project (e.g. we don't have two
artifacts called "api" for example) - which means m2eclipse is happy
by default.
For now I'm just interested in the groupIds and artifactIds of the
artifacts we expect users to use. While everything in our part of the
maven repo will get released and need to be scrutinized, I think the
artifacts below are the ones we should list on our download page
(along with 'project' tar.gz files which can be used to build the
binary). I've also follwed the 'best practice' of separating APIs into
an API bundle:
These artifacts to have groupId: org.apache.aries.application:
org.apache.aries.application.api-0.1-incubating.jar
artifactId: org.apache.aries.application.api
org.apache.aries.application.converters-0.1-incubating.jar
artifactId: org.apache.aries.application.converters
org.apache.aries.application.install-0.1-incubating.jar
artifactId: org.apache.aries.application.install
org.apache.aries.application.management-0.1-incubating.jar
artifactId: org.apache.aries.application.management
org.apache.aries.application.resolver.obr-0.1-incubating.jar
artifactId: org.apache.aries.application.resolver.obr
org.apache.aries.application.runtime-0.1-incubating.jar
artifactId: org.apache.aries.application.runtime
org.apache.aries.application.utils-0.1-incubating.jar
artifactId: org.apache.aries.application.utils.
These artifacts to have groupId: org.apache.aries.blueprint
org.apache.aries.blueprint-0.1-incubating.jar (the full blueprint impl
bundle which actually also contains the API because the spec
erroneously requires it)
artifactId: org.apache.aries.blueprint
org.apache.aries.blueprint.api-0.1-incubating.jar
artifactId: org.apache.aries.blueprint.api
These artifacts to have groupId: org.apache.aries
eba-maven-plugin-0.1-incubating.jar
artifactId: eba-maven-plugin
(TODO: why is this not called maven-eba-plugin which would follow the
convention set by the maven-bundle-plugin and the maven-zip-plugin. I
propose changing it to maven-eba-plugin)
These artifacts to have groupId: org.apache.aries.jmx:
org.apache.aries.jmx-0.1-incubating.jar (like Blueprint, the api is
also included in here - we should look at changing this if possible)
artifactId: org.apache.aries.jmx
org.apache.aries.jmx.api-0.1-incubating.jar
artifactId: org.apache.aries.jmx.api
org.apache.aries.jmx.blueprint-0.1-incubating.jar (like Blueprint, the
api is also included in here)
artifactId: org.apache.aries.jmx.blueprint
org.apache.aries.jmx.blueprint.api-0.1-incubating.jar
artifactId: org.apache.aries.jmx.blueprint.api
These artifacts to have groupId: org.apache.aries.jndi:
org.apache.aries.jndi-0.1-incubating.jar (there is no API to this)
artifactId: org.apache.aries.jndi
These artifacts to have groupId: org.apache.aries.jpa:
org.apache.aries.jpa.api-0.1-incubating.jar
artifactId: org.apache.aries.jpa.api
org.apache.aries.jpa.blueprint.aries-0.1-incubating.jar
artifactId: org.apache.aries.jpa.blueprint
org.apache.aries.jpa.container-0.1-incubating.jar
artifactId: org.apache.aries.jpa.container
org.apache.aries.jpa.container.context-0.1-incubating.jar
artifactId: org.apache.aries.jpa.container.context
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
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
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
These artifacts to have groupId: org.apache.aries.transaction:
org.apache.aries.transaction.blueprint-0.1-incubating.jar
artifactId: org.apache.aries.transaction.blueprint
org.apache.aries.transaction.manager-0.1-incubating.jar
artifactId: org.apache.aries.transaction.manager
These artifacts to have groupId: org.apache.aries.util:
org.apache.aries.util-0.1-incubating.jar (TODO: there should be an API
bundle to the impl if we are to follow our pattern of separating out
the API)
artifactId: org.apache.aries.util
These artifacts to have groupId: org.apache.aries.web:
org.apache.aries.web.urlhandler-0.1-incubating.jar (TODO:
WarToWabConverter is an API and should be in its own api bundle)
artifactId: org.apache.aries.web.urlhandler
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
