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.
This will prevent runtime substitutability. If I have an API bundle, an impl bundle, and a client bundle then, in a running framework, I can replace the impl bundle with a bug-fixed version (e.g. 1.0.0 -> 1.0.1) without a refresh-packages affecting the client bundle. By providing everything in a big bundle, when a new version of that bundle is installed, a refresh-packages will reresolve the client bundle - which I think is to be avoided if possible. > >> >> 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 >
