On 8 March 2010 14:13, Guillaume Nodet <[email protected]> wrote: > On Mon, Mar 8, 2010 at 14:56, Jeremy Hughes <[email protected]> wrote: >> 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: > > This is not a good practice in OSGi imho. > Actually it does not help in any way and just cause more problems for the > user. > The reason is that OSGi can substitute an API for another package, so > we just need > to make sure our big bundles do import the API package along with exporting > it. > People can obtain the API alone if they want to or need it to > repackage it differently, > but the basic distribution should be a standalone bundle if possible. >
I think there are two separate concerns here: 1. Substitutability - a bundle that provides an API it doesn't own the definition for should import and export it. This allow multiple potential providers to be installed whilst ensuring that only a single provider is eventually used. 2. Implementation Upgrade - the ability to upgrade an implementation (service) without having to refresh the clients. IIUC, this only works if you have separate bundles providing the API and implementation. The client only depends on the API and therefore does not need to be refreshed (package-wise) when the implementation is replaced. >> >> 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 > > See above, I don't think we should separate those. > >> >> 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 > > Same comment. > >> >> 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 >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
