You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2010/03/08 14:56:40 UTC
Aries release - the shape of repo org/apache/aries
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
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 9 March 2010 14:14, Graham Charters <gc...@googlemail.com> wrote:
> On 8 March 2010 22:00, Jeremy Hughes <hu...@apache.org> wrote:
>> On 8 March 2010 15:27, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Mon, Mar 8, 2010 at 15:31, Graham Charters <gc...@googlemail.com> wrote:
>>>> On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>
>>>>>> 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.
>>>
>>> Agreed.
>>>
>>>> 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.
>>>
>>>
>>> I do understand potential problems and limitations, but then there's
>>> no point in having a single bundle.
>>> The main driver was easy of consumption. If users have to download
>>> and install multiple bundles, then
>>> we should not ship it at all.
>>
>> I agree we should ship a single bundle for ease of consumption. I'd
>> also like to ship API because there are scenarios where that's useful.
>>
>
> At first I thought this was the right answer, but I now don't believe
> it solves the upgrade problem. There is no way, other than ordering,
> which is bad in a dynamic environment. to ensure the API bundle is the
> provider of the APIs. The resolver could just as easily chose the
> ones from the single implementation bundle, in which case there was no
> point installing the API bundle and the upgrade strategy is broken.
So to get ease of consumption we'll release an 'uber' bundle with api
and impl in it.
For people who want to implement the api themselves (!) we'll make the
api bundle available.
For people who want to make use of being able to hot-replace the
implementation at runtime (and granted this may not be applicable to
all modules) we should release api and separate 'impl-only' bundles.
Unless you see another possibility.
>
>
>>>
>>> In addition, even if what you say is conceptually a good idea, it does
>>> not really work for blueprint.
>>> The effect of upgrading the blueprint implementation will be far more
>>> disruptive than having to refresh
>>> the bundles that use the blueprint API: in that case, all blueprint
>>> context will be shut down and restarted,
>>> so I don't really think this point is really valid.
>>
>> OK, that's true for Blueprint. Not necessarily the case for others
>> though. One of the promises of Blueprint is to facilitate dynamicity
>> of services. One way those services can come and go is if the provider
>> of those services is hot-updated when, say, a bug fix update is
>> available. If, where possible, we demonstrate this by way of
>> separating API & impl bundles then we can demonstrate this model.
>>
>>>
>>> Additionally, we could go further down the path and say that you may
>>> want to refresh the CM support without
>>> refreshing all the blueprint implementations, so we should not tie
>>> them together.
>>>
>>> I think at the end, it's really a tradeoff between micro-management of
>>> bundles and ease of use. If you want
>>> to be able to minimize changes for each bundle, use smaller bundles.
>>
>> Agreed, if we give users the choice of taking an 'uber' bundle or a
>> set of bundles then they have the flexibility to choose what to do
>> themselves.
>>
>>> If you want to manage your bundles
>>> more easily and don't worry too much about refreshing, your more
>>> coarse grain bundles.
>>>
>>> We already have small bundles.
>>>
>>> Last, the spec actually mandate the implementation exports the api.
>>> It may even be problematic to export it.
>>> The reason is to support multiple blueprint implementation. The
>>> additional requirement IIRC is that each
>>> blueprint bundle should import the org.osgi.service.blueprint package.
>>
>> +1
>>
>>> I think we should comply to that, because we have users who will want
>>> to use migrate their existing spring applications
>>> at a slower rate and we should be able to support both running in the same vm.
>>> Maybe a good idea would be to add a non mandatory attribute on the
>>> org.osgi.service.blueprint package to allow
>>> blueprint bundles to make sure they are extended by the aries
>>> blueprint implementation.
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>> Cheers,
>> Jeremy
>>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Graham Charters <gc...@googlemail.com>.
On 8 March 2010 22:00, Jeremy Hughes <hu...@apache.org> wrote:
> On 8 March 2010 15:27, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Mon, Mar 8, 2010 at 15:31, Graham Charters <gc...@googlemail.com> wrote:
>>> On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>
>>>>> 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.
>>
>> Agreed.
>>
>>> 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.
>>
>>
>> I do understand potential problems and limitations, but then there's
>> no point in having a single bundle.
>> The main driver was easy of consumption. If users have to download
>> and install multiple bundles, then
>> we should not ship it at all.
>
> I agree we should ship a single bundle for ease of consumption. I'd
> also like to ship API because there are scenarios where that's useful.
>
At first I thought this was the right answer, but I now don't believe
it solves the upgrade problem. There is no way, other than ordering,
which is bad in a dynamic environment. to ensure the API bundle is the
provider of the APIs. The resolver could just as easily chose the
ones from the single implementation bundle, in which case there was no
point installing the API bundle and the upgrade strategy is broken.
>>
>> In addition, even if what you say is conceptually a good idea, it does
>> not really work for blueprint.
>> The effect of upgrading the blueprint implementation will be far more
>> disruptive than having to refresh
>> the bundles that use the blueprint API: in that case, all blueprint
>> context will be shut down and restarted,
>> so I don't really think this point is really valid.
>
> OK, that's true for Blueprint. Not necessarily the case for others
> though. One of the promises of Blueprint is to facilitate dynamicity
> of services. One way those services can come and go is if the provider
> of those services is hot-updated when, say, a bug fix update is
> available. If, where possible, we demonstrate this by way of
> separating API & impl bundles then we can demonstrate this model.
>
>>
>> Additionally, we could go further down the path and say that you may
>> want to refresh the CM support without
>> refreshing all the blueprint implementations, so we should not tie
>> them together.
>>
>> I think at the end, it's really a tradeoff between micro-management of
>> bundles and ease of use. If you want
>> to be able to minimize changes for each bundle, use smaller bundles.
>
> Agreed, if we give users the choice of taking an 'uber' bundle or a
> set of bundles then they have the flexibility to choose what to do
> themselves.
>
>> If you want to manage your bundles
>> more easily and don't worry too much about refreshing, your more
>> coarse grain bundles.
>>
>> We already have small bundles.
>>
>> Last, the spec actually mandate the implementation exports the api.
>> It may even be problematic to export it.
>> The reason is to support multiple blueprint implementation. The
>> additional requirement IIRC is that each
>> blueprint bundle should import the org.osgi.service.blueprint package.
>
> +1
>
>> I think we should comply to that, because we have users who will want
>> to use migrate their existing spring applications
>> at a slower rate and we should be able to support both running in the same vm.
>> Maybe a good idea would be to add a non mandatory attribute on the
>> org.osgi.service.blueprint package to allow
>> blueprint bundles to make sure they are extended by the aries
>> blueprint implementation.
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
> Cheers,
> Jeremy
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 8 March 2010 15:27, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 15:31, Graham Charters <gc...@googlemail.com> wrote:
>> On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>
>>>> 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.
>
> Agreed.
>
>> 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.
>
>
> I do understand potential problems and limitations, but then there's
> no point in having a single bundle.
> The main driver was easy of consumption. If users have to download
> and install multiple bundles, then
> we should not ship it at all.
I agree we should ship a single bundle for ease of consumption. I'd
also like to ship API because there are scenarios where that's useful.
>
> In addition, even if what you say is conceptually a good idea, it does
> not really work for blueprint.
> The effect of upgrading the blueprint implementation will be far more
> disruptive than having to refresh
> the bundles that use the blueprint API: in that case, all blueprint
> context will be shut down and restarted,
> so I don't really think this point is really valid.
OK, that's true for Blueprint. Not necessarily the case for others
though. One of the promises of Blueprint is to facilitate dynamicity
of services. One way those services can come and go is if the provider
of those services is hot-updated when, say, a bug fix update is
available. If, where possible, we demonstrate this by way of
separating API & impl bundles then we can demonstrate this model.
>
> Additionally, we could go further down the path and say that you may
> want to refresh the CM support without
> refreshing all the blueprint implementations, so we should not tie
> them together.
>
> I think at the end, it's really a tradeoff between micro-management of
> bundles and ease of use. If you want
> to be able to minimize changes for each bundle, use smaller bundles.
Agreed, if we give users the choice of taking an 'uber' bundle or a
set of bundles then they have the flexibility to choose what to do
themselves.
> If you want to manage your bundles
> more easily and don't worry too much about refreshing, your more
> coarse grain bundles.
>
> We already have small bundles.
>
> Last, the spec actually mandate the implementation exports the api.
> It may even be problematic to export it.
> The reason is to support multiple blueprint implementation. The
> additional requirement IIRC is that each
> blueprint bundle should import the org.osgi.service.blueprint package.
+1
> I think we should comply to that, because we have users who will want
> to use migrate their existing spring applications
> at a slower rate and we should be able to support both running in the same vm.
> Maybe a good idea would be to add a non mandatory attribute on the
> org.osgi.service.blueprint package to allow
> blueprint bundles to make sure they are extended by the aries
> blueprint implementation.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Cheers,
Jeremy
Re: Aries release - the shape of repo org/apache/aries
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 8, 2010 at 15:31, Graham Charters <gc...@googlemail.com> wrote:
> On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>> 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.
Agreed.
> 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.
I do understand potential problems and limitations, but then there's
no point in having a single bundle.
The main driver was easy of consumption. If users have to download
and install multiple bundles, then
we should not ship it at all.
In addition, even if what you say is conceptually a good idea, it does
not really work for blueprint.
The effect of upgrading the blueprint implementation will be far more
disruptive than having to refresh
the bundles that use the blueprint API: in that case, all blueprint
context will be shut down and restarted,
so I don't really think this point is really valid.
Additionally, we could go further down the path and say that you may
want to refresh the CM support without
refreshing all the blueprint implementations, so we should not tie
them together.
I think at the end, it's really a tradeoff between micro-management of
bundles and ease of use. If you want
to be able to minimize changes for each bundle, use smaller bundles.
If you want to manage your bundles
more easily and don't worry too much about refreshing, your more
coarse grain bundles.
We already have small bundles.
Last, the spec actually mandate the implementation exports the api.
It may even be problematic to export it.
The reason is to support multiple blueprint implementation. The
additional requirement IIRC is that each
blueprint bundle should import the org.osgi.service.blueprint package.
I think we should comply to that, because we have users who will want
to use migrate their existing spring applications
at a slower rate and we should be able to support both running in the same vm.
Maybe a good idea would be to add a non mandatory attribute on the
org.osgi.service.blueprint package to allow
blueprint bundles to make sure they are extended by the aries
blueprint implementation.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Aries release - the shape of repo org/apache/aries
Posted by Graham Charters <gc...@googlemail.com>.
On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 14:56, Jeremy Hughes <hu...@apache.org> 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
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 8 March 2010 14:13, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 14:56, Jeremy Hughes <hu...@apache.org> 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
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 8, 2010 at 14:56, Jeremy Hughes <hu...@apache.org> 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.
>
> 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
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
That doesn't affect the name of the jar that goes into the maven repo,
so the assemblies we build would have clashing jar's.
Alasdair
On 9 Mar 2010, at 19:19, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Mar 9, 2010 at 11:06 AM, Alasdair Nottingham
> <no...@apache.org> wrote:
>> Maven insists on naming the jar artifactid-version.jar since we
>> wanted our
>> jars to follow the bundle_symolicname-version.jar convention it
>> forces
>> duplication in the artifact id.
>>
>> This is why I was asking if we could get the jar name to be
>> generated from
>> the group and artifact id on IRC last week.
>>
>> Alasdair
>>
>> On 9 Mar 2010, at 18:49, Kevan Miller <ke...@gmail.com> wrote:
>>
>
> Have you tried specifying/forcing a given filename in the pom like the
> example below ?
>
> <build>
> <finalName>something</finalName>
> </build>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: Aries release - the shape of repo org/apache/aries
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Mar 9, 2010 at 11:06 AM, Alasdair Nottingham <no...@apache.org> wrote:
> Maven insists on naming the jar artifactid-version.jar since we wanted our
> jars to follow the bundle_symolicname-version.jar convention it forces
> duplication in the artifact id.
>
> This is why I was asking if we could get the jar name to be generated from
> the group and artifact id on IRC last week.
>
> Alasdair
>
> On 9 Mar 2010, at 18:49, Kevan Miller <ke...@gmail.com> wrote:
>
Have you tried specifying/forcing a given filename in the pom like the
example below ?
<build>
<finalName>something</finalName>
</build>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <jp...@gmail.com>.
On 9 March 2010 20:57, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Mar 9, 2010, at 12:43 PM, David Jencks wrote:
>
>>
>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>
>>> I think the reason is that the bundle symbolic name is the unique id
>>> of the bundle. It has to be globally unique.
>>> When you use a non OSGi environment, you don't care about the jar
>>> name, you can simply rename it and it won't hurt anyone.
>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>> name does. A good practice is to have the jar be named
>>> symbolicname-version.jar which ease the identification. But the
>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>> hence for the artifact.
>>>
>>> Makes sense ?
>>
>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>> if you think this then you will do it, but you've just asserted that doing
>> this is a good idea without any support.
>>
>> It seems to me that the question kinda boils down to who wins, maven or
>> eclipse.
>
> Seems like a good practice to me because I can, at a glance, have a good
> idea as to what's inside the bundle/jar.
>
> OT: what is irritating to me is how we duplicate the sub-project name, e.g.
> jmx/jmx-core. I use shells often and when I traverse directories it's
> irritating.
I don't see the need for that either, and I noticed Karaf has done
away with that. I guess there could be an issue if an IDE imported all
the modules it finds as top level projects, then there would more
likely be duplicates (e.g. core, api). The only maven elipse plugin
I've been using is m2eclipse which uses the artifact id anyway. So I'd
be happy to remove the <parent>- prefix to child modules.
>
> Regards,
> Alan
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
I hear you, although I would prefer the artifact id matches the
directory name, but that really is an eclipse thing.
Alasdair
On 9 March 2010 20:57, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Mar 9, 2010, at 12:43 PM, David Jencks wrote:
>
>>
>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>
>>> I think the reason is that the bundle symbolic name is the unique id
>>> of the bundle. It has to be globally unique.
>>> When you use a non OSGi environment, you don't care about the jar
>>> name, you can simply rename it and it won't hurt anyone.
>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>> name does. A good practice is to have the jar be named
>>> symbolicname-version.jar which ease the identification. But the
>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>> hence for the artifact.
>>>
>>> Makes sense ?
>>
>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>> if you think this then you will do it, but you've just asserted that doing
>> this is a good idea without any support.
>>
>> It seems to me that the question kinda boils down to who wins, maven or
>> eclipse.
>
> Seems like a good practice to me because I can, at a glance, have a good
> idea as to what's inside the bundle/jar.
>
> OT: what is irritating to me is how we duplicate the sub-project name, e.g.
> jmx/jmx-core. I use shells often and when I traverse directories it's
> irritating.
>
> Regards,
> Alan
>
>
--
Alasdair Nottingham
not@apache.org
Re: Aries release - the shape of repo org/apache/aries
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Mar 9, 2010, at 12:43 PM, David Jencks wrote:
>
> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>
>> I think the reason is that the bundle symbolic name is the unique id
>> of the bundle. It has to be globally unique.
>> When you use a non OSGi environment, you don't care about the jar
>> name, you can simply rename it and it won't hurt anyone.
>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>> name does. A good practice is to have the jar be named
>> symbolicname-version.jar which ease the identification. But the
>> constraint of uniqueness on the symbolic name kinda forces the use of
>> the org.apache.aries.xxx naming convention for the symbolic name,
>> hence for the artifact.
>>
>> Makes sense ?
>
> Why is naming the jar symbolicname-version.jar good practice?
> Obviously if you think this then you will do it, but you've just
> asserted that doing this is a good idea without any support.
>
> It seems to me that the question kinda boils down to who wins, maven
> or eclipse.
Seems like a good practice to me because I can, at a glance, have a
good idea as to what's inside the bundle/jar.
OT: what is irritating to me is how we duplicate the sub-project name,
e.g. jmx/jmx-core. I use shells often and when I traverse directories
it's irritating.
Regards,
Alan
RE: Aries release - the shape of repo org/apache/aries
Posted by Timothy Ward <ti...@apache.org>.
I'm +1 for option 1
> Date: Wed, 10 Mar 2010 16:18:20 +0000
> Subject: Re: Aries release - the shape of repo org/apache/aries
> From: not@apache.org
> To: aries-dev@incubator.apache.org
>
> I agree, option 1 is best.
>
> Alasdair
>
> On 10 March 2010 14:45, Lin Sun <li...@gmail.com> wrote:
> > I'd vote for option no. 1 below, as there is nothing wrong with it and
> > this is what we currently have. It is also the format used by many
> > felix jars in maven central and many osgi jars in osgi alliance repo.
> >
> > No. 2 looked wrong to me, and I certainly don't know how to set up that format.
> >
> > Lin
> >
> > On Wed, Mar 10, 2010 at 6:07 AM, Jeremy Hughes <hu...@apache.org> wrote:
> >> On 9 March 2010 23:21, David Jencks <da...@yahoo.com> wrote:
> >>>
> >>> On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
> >>>
> >>>> I don't think it is fair to claim it is maven or eclipse winning.
> >>>> Eclipse is not the only group that use this convention. It is also
> >>>> used by felix, and I have been using the convention since I first
> >>>> worked on OSGi 5 years ago. It is pretty common.
> >>>>
> >>>> It is good practice because it makes it quick and easy to identify the
> >>>> identity of the bundle from the jar name, in a structure where you
> >>>> have multiple bundles in a directory it ensures you do not end up
> >>>> replacing one bundle with another which could happen if the jar name
> >>>> is not unique enough.
> >>>>
> >>>> It is my understanding that it is good practice to have the artifact
> >>>> id in maven unique in any case so people who gather jars together in
> >>>> assemblies do not end up replacing jars by mistake. That is what this
> >>>> achieves.
> >>>>
> >>>
> >>> So to be a little more verbose about what I meant....
> >>>
> >>> Maven has the idea that if you have a few million jars, you might not want
> >>> them all in the same directory. So it has a coordinate system that makes
> >>> it easy for an organization to have short jar names and assure everyone that
> >>> it's artifacts can be distinguished from everyone elses, by using the
> >>> groupId but not necessarily requiring unique artifact ids.
> >>>
> >>> Other systems, AFAIK including eclipse, have the idea that you only have a
> >>> few jars, maybe 1000, and putting them all in the same directory is fine. In
> >>> this situation you need to assure the jar name is unique, and the usual
> >>> method seems to be to form something resembling
> >>> <groupId>.<aritifactId>-<version>.jar from a minimal artifactId. In order
> >>> to get maven to name the jars in this style, you need to include the groupId
> >>> as a prefix in the artifactId, which is obviously redundant for maven.
> >>>
> >>> My personal opinion is that the non-maven approach is pretty ridiculous, but
> >>> this seems to be a rather unpopular opinion in the osgi world at this time.
> >>>
> >>> For the "assembly" scenario you mention, I'd just include a
> >>> mini-maven-repository with the desired jars, thus preventing any possible
> >>> confusion about what a jar is, even with non-unique artifactIds.
> >>>
> >>
> >> If we take the starting point of the bundle jars being called <bundle
> >> symbolic name>-<version>.jar then what are the possible groupId /
> >> artifactId schemes? Then once we have that we can choose the best one.
> >>
> >> 1. "BSN artifactId"
> >> The artifactId is the string used for the BSN (Bundle Symbolic Name).
> >> It would seem sensible, although not mandatory, for groupId to be an
> >> appropriate first part of the artifactId string. This is what we
> >> largely have today, and what Felix does - e.g. groupId:
> >> org.apache.felix artifactId: org.apache.felix.bundlerepository. This
> >> requires the Bundle Symbolic Name (BSN) to be explicitly set to
> >> ${artifactId} in the maven-bundle-plugin config in the pom because the
> >> maven-bundle-plugin defaults to something else [1].
> >>
> >> So in the maven repo we have artifacts with paths like this:
> >>
> >> ./org/apache/aries/blueprint/org.apache.aries.blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
> >> (groupId = org.apache.aries.blueprint, artifactId = org.apache.aries.blueprint)
> >> ./org/apache/aries/blueprint/org.apache.aries.blueprint.api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
> >> (groupId = org.apache.aries.blueprint, artifactId =
> >> org.apache.aries.blueprint.api)
> >>
> >> 2. "Minimal artifactId"
> >> In this scheme, the artifactId string doesn't overlap with groupId.
> >> The benefit of this would be less duplication in the path in the maven
> >> repo. We would have artifacts with paths like this:
> >>
> >> ./org/apache/aries/blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
> >> (groupId = org.apache.aries, artifactId = blueprint)
> >> ./org/apache/aries/blueprint/api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
> >> (groupId = org.apache.aries.blueprint, artifactId = api)
> >>
> >> (btw: I struggled a bit with the naming of the groupId and artifactId
> >> here to cope with the fact that we're having an 'uber' bundle and
> >> separate 'api' bundle)
> >>
> >> But, this would require a way of renaming the jar artifact from
> >> <artifactId>-<version>.jar to be the effective BSN that either the
> >> maven-bundle-plugin creates by default [1] or the BSN that is
> >> explicitly configured in the maven-bundle-plugin config elements. It
> >> may be possible to do this (I suspect it'll need some coding rather
> >> than just some config of available plugins). But even if this were
> >> done, do we really want our artifacts to *not* start with the
> >> artifactId? Several times on this list, that has been described as a
> >> bad thing
> >>
> >> For now I don't see any other options. Do you have one?
> >>
> >> [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-DefaultBehavior
> >>
> >> Cheers,
> >> Jeremy
> >>
> >>> thanks
> >>> david jencks
> >>>
> >>>
> >>>
> >>>> Alasdair
> >>>>
> >>>> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
> >>>>>
> >>>>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
> >>>>>
> >>>>>> I think the reason is that the bundle symbolic name is the unique id
> >>>>>> of the bundle. It has to be globally unique.
> >>>>>> When you use a non OSGi environment, you don't care about the jar
> >>>>>> name, you can simply rename it and it won't hurt anyone.
> >>>>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
> >>>>>> name does. A good practice is to have the jar be named
> >>>>>> symbolicname-version.jar which ease the identification. But the
> >>>>>> constraint of uniqueness on the symbolic name kinda forces the use of
> >>>>>> the org.apache.aries.xxx naming convention for the symbolic name,
> >>>>>> hence for the artifact.
> >>>>>>
> >>>>>> Makes sense ?
> >>>>>
> >>>>> Why is naming the jar symbolicname-version.jar good practice? Obviously
> >>>>> if
> >>>>> you think this then you will do it, but you've just asserted that doing
> >>>>> this
> >>>>> is a good idea without any support.
> >>>>>
> >>>>> It seems to me that the question kinda boils down to who wins, maven or
> >>>>> eclipse.
> >>>>>
> >>>>> david jencks
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
> >>>>>>>
> >>>>>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
> >>>>>>>> our jars to follow the bundle_symolicname-version.jar convention it
> >>>>>>>> forces
> >>>>>>>> duplication in the artifact id.
> >>>>>>>>
> >>>>>>>> This is why I was asking if we could get the jar name to be generated
> >>>>>>>> from the group and artifact id on IRC last week.
> >>>>>>>
> >>>>>>> That's not really answering my question. artifactid is essentially the
> >>>>>>> jar file name and trying to get maven to act otherwise, is just going
> >>>>>>> to
> >>>>>>> have a bad ending... So, to rephrase in your terms, why does the jar
> >>>>>>> file
> >>>>>>> name need to follow the current naming convention?
> >>>>>>>
> >>>>>>> --kevan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers,
> >>>>>> Guillaume Nodet
> >>>>>> ------------------------
> >>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>> ------------------------
> >>>>>> Open Source SOA
> >>>>>> http://fusesource.com
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Alasdair Nottingham
> >>>> not@apache.org
> >>>
> >>>
> >>
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
_________________________________________________________________
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
I agree, option 1 is best.
Alasdair
On 10 March 2010 14:45, Lin Sun <li...@gmail.com> wrote:
> I'd vote for option no. 1 below, as there is nothing wrong with it and
> this is what we currently have. It is also the format used by many
> felix jars in maven central and many osgi jars in osgi alliance repo.
>
> No. 2 looked wrong to me, and I certainly don't know how to set up that format.
>
> Lin
>
> On Wed, Mar 10, 2010 at 6:07 AM, Jeremy Hughes <hu...@apache.org> wrote:
>> On 9 March 2010 23:21, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
>>>
>>>> I don't think it is fair to claim it is maven or eclipse winning.
>>>> Eclipse is not the only group that use this convention. It is also
>>>> used by felix, and I have been using the convention since I first
>>>> worked on OSGi 5 years ago. It is pretty common.
>>>>
>>>> It is good practice because it makes it quick and easy to identify the
>>>> identity of the bundle from the jar name, in a structure where you
>>>> have multiple bundles in a directory it ensures you do not end up
>>>> replacing one bundle with another which could happen if the jar name
>>>> is not unique enough.
>>>>
>>>> It is my understanding that it is good practice to have the artifact
>>>> id in maven unique in any case so people who gather jars together in
>>>> assemblies do not end up replacing jars by mistake. That is what this
>>>> achieves.
>>>>
>>>
>>> So to be a little more verbose about what I meant....
>>>
>>> Maven has the idea that if you have a few million jars, you might not want
>>> them all in the same directory. So it has a coordinate system that makes
>>> it easy for an organization to have short jar names and assure everyone that
>>> it's artifacts can be distinguished from everyone elses, by using the
>>> groupId but not necessarily requiring unique artifact ids.
>>>
>>> Other systems, AFAIK including eclipse, have the idea that you only have a
>>> few jars, maybe 1000, and putting them all in the same directory is fine. In
>>> this situation you need to assure the jar name is unique, and the usual
>>> method seems to be to form something resembling
>>> <groupId>.<aritifactId>-<version>.jar from a minimal artifactId. In order
>>> to get maven to name the jars in this style, you need to include the groupId
>>> as a prefix in the artifactId, which is obviously redundant for maven.
>>>
>>> My personal opinion is that the non-maven approach is pretty ridiculous, but
>>> this seems to be a rather unpopular opinion in the osgi world at this time.
>>>
>>> For the "assembly" scenario you mention, I'd just include a
>>> mini-maven-repository with the desired jars, thus preventing any possible
>>> confusion about what a jar is, even with non-unique artifactIds.
>>>
>>
>> If we take the starting point of the bundle jars being called <bundle
>> symbolic name>-<version>.jar then what are the possible groupId /
>> artifactId schemes? Then once we have that we can choose the best one.
>>
>> 1. "BSN artifactId"
>> The artifactId is the string used for the BSN (Bundle Symbolic Name).
>> It would seem sensible, although not mandatory, for groupId to be an
>> appropriate first part of the artifactId string. This is what we
>> largely have today, and what Felix does - e.g. groupId:
>> org.apache.felix artifactId: org.apache.felix.bundlerepository. This
>> requires the Bundle Symbolic Name (BSN) to be explicitly set to
>> ${artifactId} in the maven-bundle-plugin config in the pom because the
>> maven-bundle-plugin defaults to something else [1].
>>
>> So in the maven repo we have artifacts with paths like this:
>>
>> ./org/apache/aries/blueprint/org.apache.aries.blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
>> (groupId = org.apache.aries.blueprint, artifactId = org.apache.aries.blueprint)
>> ./org/apache/aries/blueprint/org.apache.aries.blueprint.api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
>> (groupId = org.apache.aries.blueprint, artifactId =
>> org.apache.aries.blueprint.api)
>>
>> 2. "Minimal artifactId"
>> In this scheme, the artifactId string doesn't overlap with groupId.
>> The benefit of this would be less duplication in the path in the maven
>> repo. We would have artifacts with paths like this:
>>
>> ./org/apache/aries/blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
>> (groupId = org.apache.aries, artifactId = blueprint)
>> ./org/apache/aries/blueprint/api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
>> (groupId = org.apache.aries.blueprint, artifactId = api)
>>
>> (btw: I struggled a bit with the naming of the groupId and artifactId
>> here to cope with the fact that we're having an 'uber' bundle and
>> separate 'api' bundle)
>>
>> But, this would require a way of renaming the jar artifact from
>> <artifactId>-<version>.jar to be the effective BSN that either the
>> maven-bundle-plugin creates by default [1] or the BSN that is
>> explicitly configured in the maven-bundle-plugin config elements. It
>> may be possible to do this (I suspect it'll need some coding rather
>> than just some config of available plugins). But even if this were
>> done, do we really want our artifacts to *not* start with the
>> artifactId? Several times on this list, that has been described as a
>> bad thing
>>
>> For now I don't see any other options. Do you have one?
>>
>> [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-DefaultBehavior
>>
>> Cheers,
>> Jeremy
>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>> Alasdair
>>>>
>>>> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>>>>>
>>>>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>>>>
>>>>>> I think the reason is that the bundle symbolic name is the unique id
>>>>>> of the bundle. It has to be globally unique.
>>>>>> When you use a non OSGi environment, you don't care about the jar
>>>>>> name, you can simply rename it and it won't hurt anyone.
>>>>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>>>>> name does. A good practice is to have the jar be named
>>>>>> symbolicname-version.jar which ease the identification. But the
>>>>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>>>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>>>>> hence for the artifact.
>>>>>>
>>>>>> Makes sense ?
>>>>>
>>>>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>>>>> if
>>>>> you think this then you will do it, but you've just asserted that doing
>>>>> this
>>>>> is a good idea without any support.
>>>>>
>>>>> It seems to me that the question kinda boils down to who wins, maven or
>>>>> eclipse.
>>>>>
>>>>> david jencks
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>>>>>
>>>>>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
>>>>>>>> our jars to follow the bundle_symolicname-version.jar convention it
>>>>>>>> forces
>>>>>>>> duplication in the artifact id.
>>>>>>>>
>>>>>>>> This is why I was asking if we could get the jar name to be generated
>>>>>>>> from the group and artifact id on IRC last week.
>>>>>>>
>>>>>>> That's not really answering my question. artifactid is essentially the
>>>>>>> jar file name and trying to get maven to act otherwise, is just going
>>>>>>> to
>>>>>>> have a bad ending... So, to rephrase in your terms, why does the jar
>>>>>>> file
>>>>>>> name need to follow the current naming convention?
>>>>>>>
>>>>>>> --kevan
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alasdair Nottingham
>>>> not@apache.org
>>>
>>>
>>
>
--
Alasdair Nottingham
not@apache.org
Re: Aries release - the shape of repo org/apache/aries
Posted by Lin Sun <li...@gmail.com>.
I'd vote for option no. 1 below, as there is nothing wrong with it and
this is what we currently have. It is also the format used by many
felix jars in maven central and many osgi jars in osgi alliance repo.
No. 2 looked wrong to me, and I certainly don't know how to set up that format.
Lin
On Wed, Mar 10, 2010 at 6:07 AM, Jeremy Hughes <hu...@apache.org> wrote:
> On 9 March 2010 23:21, David Jencks <da...@yahoo.com> wrote:
>>
>> On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
>>
>>> I don't think it is fair to claim it is maven or eclipse winning.
>>> Eclipse is not the only group that use this convention. It is also
>>> used by felix, and I have been using the convention since I first
>>> worked on OSGi 5 years ago. It is pretty common.
>>>
>>> It is good practice because it makes it quick and easy to identify the
>>> identity of the bundle from the jar name, in a structure where you
>>> have multiple bundles in a directory it ensures you do not end up
>>> replacing one bundle with another which could happen if the jar name
>>> is not unique enough.
>>>
>>> It is my understanding that it is good practice to have the artifact
>>> id in maven unique in any case so people who gather jars together in
>>> assemblies do not end up replacing jars by mistake. That is what this
>>> achieves.
>>>
>>
>> So to be a little more verbose about what I meant....
>>
>> Maven has the idea that if you have a few million jars, you might not want
>> them all in the same directory. So it has a coordinate system that makes
>> it easy for an organization to have short jar names and assure everyone that
>> it's artifacts can be distinguished from everyone elses, by using the
>> groupId but not necessarily requiring unique artifact ids.
>>
>> Other systems, AFAIK including eclipse, have the idea that you only have a
>> few jars, maybe 1000, and putting them all in the same directory is fine. In
>> this situation you need to assure the jar name is unique, and the usual
>> method seems to be to form something resembling
>> <groupId>.<aritifactId>-<version>.jar from a minimal artifactId. In order
>> to get maven to name the jars in this style, you need to include the groupId
>> as a prefix in the artifactId, which is obviously redundant for maven.
>>
>> My personal opinion is that the non-maven approach is pretty ridiculous, but
>> this seems to be a rather unpopular opinion in the osgi world at this time.
>>
>> For the "assembly" scenario you mention, I'd just include a
>> mini-maven-repository with the desired jars, thus preventing any possible
>> confusion about what a jar is, even with non-unique artifactIds.
>>
>
> If we take the starting point of the bundle jars being called <bundle
> symbolic name>-<version>.jar then what are the possible groupId /
> artifactId schemes? Then once we have that we can choose the best one.
>
> 1. "BSN artifactId"
> The artifactId is the string used for the BSN (Bundle Symbolic Name).
> It would seem sensible, although not mandatory, for groupId to be an
> appropriate first part of the artifactId string. This is what we
> largely have today, and what Felix does - e.g. groupId:
> org.apache.felix artifactId: org.apache.felix.bundlerepository. This
> requires the Bundle Symbolic Name (BSN) to be explicitly set to
> ${artifactId} in the maven-bundle-plugin config in the pom because the
> maven-bundle-plugin defaults to something else [1].
>
> So in the maven repo we have artifacts with paths like this:
>
> ./org/apache/aries/blueprint/org.apache.aries.blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
> (groupId = org.apache.aries.blueprint, artifactId = org.apache.aries.blueprint)
> ./org/apache/aries/blueprint/org.apache.aries.blueprint.api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
> (groupId = org.apache.aries.blueprint, artifactId =
> org.apache.aries.blueprint.api)
>
> 2. "Minimal artifactId"
> In this scheme, the artifactId string doesn't overlap with groupId.
> The benefit of this would be less duplication in the path in the maven
> repo. We would have artifacts with paths like this:
>
> ./org/apache/aries/blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
> (groupId = org.apache.aries, artifactId = blueprint)
> ./org/apache/aries/blueprint/api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
> (groupId = org.apache.aries.blueprint, artifactId = api)
>
> (btw: I struggled a bit with the naming of the groupId and artifactId
> here to cope with the fact that we're having an 'uber' bundle and
> separate 'api' bundle)
>
> But, this would require a way of renaming the jar artifact from
> <artifactId>-<version>.jar to be the effective BSN that either the
> maven-bundle-plugin creates by default [1] or the BSN that is
> explicitly configured in the maven-bundle-plugin config elements. It
> may be possible to do this (I suspect it'll need some coding rather
> than just some config of available plugins). But even if this were
> done, do we really want our artifacts to *not* start with the
> artifactId? Several times on this list, that has been described as a
> bad thing
>
> For now I don't see any other options. Do you have one?
>
> [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-DefaultBehavior
>
> Cheers,
> Jeremy
>
>> thanks
>> david jencks
>>
>>
>>
>>> Alasdair
>>>
>>> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>>>
>>>>> I think the reason is that the bundle symbolic name is the unique id
>>>>> of the bundle. It has to be globally unique.
>>>>> When you use a non OSGi environment, you don't care about the jar
>>>>> name, you can simply rename it and it won't hurt anyone.
>>>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>>>> name does. A good practice is to have the jar be named
>>>>> symbolicname-version.jar which ease the identification. But the
>>>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>>>> hence for the artifact.
>>>>>
>>>>> Makes sense ?
>>>>
>>>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>>>> if
>>>> you think this then you will do it, but you've just asserted that doing
>>>> this
>>>> is a good idea without any support.
>>>>
>>>> It seems to me that the question kinda boils down to who wins, maven or
>>>> eclipse.
>>>>
>>>> david jencks
>>>>
>>>>
>>>>>
>>>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>>>>
>>>>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
>>>>>>> our jars to follow the bundle_symolicname-version.jar convention it
>>>>>>> forces
>>>>>>> duplication in the artifact id.
>>>>>>>
>>>>>>> This is why I was asking if we could get the jar name to be generated
>>>>>>> from the group and artifact id on IRC last week.
>>>>>>
>>>>>> That's not really answering my question. artifactid is essentially the
>>>>>> jar file name and trying to get maven to act otherwise, is just going
>>>>>> to
>>>>>> have a bad ending... So, to rephrase in your terms, why does the jar
>>>>>> file
>>>>>> name need to follow the current naming convention?
>>>>>>
>>>>>> --kevan
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>
>>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 9 March 2010 23:21, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
>
>> I don't think it is fair to claim it is maven or eclipse winning.
>> Eclipse is not the only group that use this convention. It is also
>> used by felix, and I have been using the convention since I first
>> worked on OSGi 5 years ago. It is pretty common.
>>
>> It is good practice because it makes it quick and easy to identify the
>> identity of the bundle from the jar name, in a structure where you
>> have multiple bundles in a directory it ensures you do not end up
>> replacing one bundle with another which could happen if the jar name
>> is not unique enough.
>>
>> It is my understanding that it is good practice to have the artifact
>> id in maven unique in any case so people who gather jars together in
>> assemblies do not end up replacing jars by mistake. That is what this
>> achieves.
>>
>
> So to be a little more verbose about what I meant....
>
> Maven has the idea that if you have a few million jars, you might not want
> them all in the same directory. So it has a coordinate system that makes
> it easy for an organization to have short jar names and assure everyone that
> it's artifacts can be distinguished from everyone elses, by using the
> groupId but not necessarily requiring unique artifact ids.
>
> Other systems, AFAIK including eclipse, have the idea that you only have a
> few jars, maybe 1000, and putting them all in the same directory is fine. In
> this situation you need to assure the jar name is unique, and the usual
> method seems to be to form something resembling
> <groupId>.<aritifactId>-<version>.jar from a minimal artifactId. In order
> to get maven to name the jars in this style, you need to include the groupId
> as a prefix in the artifactId, which is obviously redundant for maven.
>
> My personal opinion is that the non-maven approach is pretty ridiculous, but
> this seems to be a rather unpopular opinion in the osgi world at this time.
>
> For the "assembly" scenario you mention, I'd just include a
> mini-maven-repository with the desired jars, thus preventing any possible
> confusion about what a jar is, even with non-unique artifactIds.
>
If we take the starting point of the bundle jars being called <bundle
symbolic name>-<version>.jar then what are the possible groupId /
artifactId schemes? Then once we have that we can choose the best one.
1. "BSN artifactId"
The artifactId is the string used for the BSN (Bundle Symbolic Name).
It would seem sensible, although not mandatory, for groupId to be an
appropriate first part of the artifactId string. This is what we
largely have today, and what Felix does - e.g. groupId:
org.apache.felix artifactId: org.apache.felix.bundlerepository. This
requires the Bundle Symbolic Name (BSN) to be explicitly set to
${artifactId} in the maven-bundle-plugin config in the pom because the
maven-bundle-plugin defaults to something else [1].
So in the maven repo we have artifacts with paths like this:
./org/apache/aries/blueprint/org.apache.aries.blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
(groupId = org.apache.aries.blueprint, artifactId = org.apache.aries.blueprint)
./org/apache/aries/blueprint/org.apache.aries.blueprint.api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
(groupId = org.apache.aries.blueprint, artifactId =
org.apache.aries.blueprint.api)
2. "Minimal artifactId"
In this scheme, the artifactId string doesn't overlap with groupId.
The benefit of this would be less duplication in the path in the maven
repo. We would have artifacts with paths like this:
./org/apache/aries/blueprint/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint-0.1-incubating-SNAPSHOT.jar
(groupId = org.apache.aries, artifactId = blueprint)
./org/apache/aries/blueprint/api/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.api-0.1-incubating-SNAPSHOT.jar
(groupId = org.apache.aries.blueprint, artifactId = api)
(btw: I struggled a bit with the naming of the groupId and artifactId
here to cope with the fact that we're having an 'uber' bundle and
separate 'api' bundle)
But, this would require a way of renaming the jar artifact from
<artifactId>-<version>.jar to be the effective BSN that either the
maven-bundle-plugin creates by default [1] or the BSN that is
explicitly configured in the maven-bundle-plugin config elements. It
may be possible to do this (I suspect it'll need some coding rather
than just some config of available plugins). But even if this were
done, do we really want our artifacts to *not* start with the
artifactId? Several times on this list, that has been described as a
bad thing
For now I don't see any other options. Do you have one?
[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-DefaultBehavior
Cheers,
Jeremy
> thanks
> david jencks
>
>
>
>> Alasdair
>>
>> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>>
>>>> I think the reason is that the bundle symbolic name is the unique id
>>>> of the bundle. It has to be globally unique.
>>>> When you use a non OSGi environment, you don't care about the jar
>>>> name, you can simply rename it and it won't hurt anyone.
>>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>>> name does. A good practice is to have the jar be named
>>>> symbolicname-version.jar which ease the identification. But the
>>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>>> hence for the artifact.
>>>>
>>>> Makes sense ?
>>>
>>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>>> if
>>> you think this then you will do it, but you've just asserted that doing
>>> this
>>> is a good idea without any support.
>>>
>>> It seems to me that the question kinda boils down to who wins, maven or
>>> eclipse.
>>>
>>> david jencks
>>>
>>>
>>>>
>>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>>>
>>>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
>>>>>> our jars to follow the bundle_symolicname-version.jar convention it
>>>>>> forces
>>>>>> duplication in the artifact id.
>>>>>>
>>>>>> This is why I was asking if we could get the jar name to be generated
>>>>>> from the group and artifact id on IRC last week.
>>>>>
>>>>> That's not really answering my question. artifactid is essentially the
>>>>> jar file name and trying to get maven to act otherwise, is just going
>>>>> to
>>>>> have a bad ending... So, to rephrase in your terms, why does the jar
>>>>> file
>>>>> name need to follow the current naming convention?
>>>>>
>>>>> --kevan
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
You are again mischaracterising eclipse. It does not require all
bundles to be installed in a flat directory, it also support a
"coordinate" type system for storing the bundles, so typically the
eclipse provided bundles go in one directory and products based on
eclipse have their bundles in a different directory.
In any any case I think Guillaume summarized why we do this very well
when he said:
A good practice is to have the jar be named
symbolicname-version.jar which ease the identification.
basically if you follow the convention we, eclipse, felix and many
others follow you can easily work out the bundles' identity without
having to unpack the jar and look at the manifest.
On the subject of maven and unique artifact ids this post from Jason
van Zyl is what made me believe that artifact ids also need to be
reasonably unique (which our scheme provides):
http://www.mail-archive.com/users@maven.apache.org/msg96898.html
Alasdair
On 9 March 2010 23:21, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
>
>> I don't think it is fair to claim it is maven or eclipse winning.
>> Eclipse is not the only group that use this convention. It is also
>> used by felix, and I have been using the convention since I first
>> worked on OSGi 5 years ago. It is pretty common.
>>
>> It is good practice because it makes it quick and easy to identify the
>> identity of the bundle from the jar name, in a structure where you
>> have multiple bundles in a directory it ensures you do not end up
>> replacing one bundle with another which could happen if the jar name
>> is not unique enough.
>>
>> It is my understanding that it is good practice to have the artifact
>> id in maven unique in any case so people who gather jars together in
>> assemblies do not end up replacing jars by mistake. That is what this
>> achieves.
>>
>
> So to be a little more verbose about what I meant....
>
> Maven has the idea that if you have a few million jars, you might not want
> them all in the same directory. So it has a coordinate system that makes
> it easy for an organization to have short jar names and assure everyone that
> it's artifacts can be distinguished from everyone elses, by using the
> groupId but not necessarily requiring unique artifact ids.
>
> Other systems, AFAIK including eclipse, have the idea that you only have a
> few jars, maybe 1000, and putting them all in the same directory is fine. In
> this situation you need to assure the jar name is unique, and the usual
> method seems to be to form something resembling
> <groupId>.<aritifactId>-<version>.jar from a minimal artifactId. In order
> to get maven to name the jars in this style, you need to include the groupId
> as a prefix in the artifactId, which is obviously redundant for maven.
>
> My personal opinion is that the non-maven approach is pretty ridiculous, but
> this seems to be a rather unpopular opinion in the osgi world at this time.
>
> For the "assembly" scenario you mention, I'd just include a
> mini-maven-repository with the desired jars, thus preventing any possible
> confusion about what a jar is, even with non-unique artifactIds.
>
> thanks
> david jencks
>
>
>
>> Alasdair
>>
>> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>>
>>>> I think the reason is that the bundle symbolic name is the unique id
>>>> of the bundle. It has to be globally unique.
>>>> When you use a non OSGi environment, you don't care about the jar
>>>> name, you can simply rename it and it won't hurt anyone.
>>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>>> name does. A good practice is to have the jar be named
>>>> symbolicname-version.jar which ease the identification. But the
>>>> constraint of uniqueness on the symbolic name kinda forces the use of
>>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>>> hence for the artifact.
>>>>
>>>> Makes sense ?
>>>
>>> Why is naming the jar symbolicname-version.jar good practice? Obviously
>>> if
>>> you think this then you will do it, but you've just asserted that doing
>>> this
>>> is a good idea without any support.
>>>
>>> It seems to me that the question kinda boils down to who wins, maven or
>>> eclipse.
>>>
>>> david jencks
>>>
>>>
>>>>
>>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>>>
>>>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
>>>>>> our jars to follow the bundle_symolicname-version.jar convention it
>>>>>> forces
>>>>>> duplication in the artifact id.
>>>>>>
>>>>>> This is why I was asking if we could get the jar name to be generated
>>>>>> from the group and artifact id on IRC last week.
>>>>>
>>>>> That's not really answering my question. artifactid is essentially the
>>>>> jar file name and trying to get maven to act otherwise, is just going
>>>>> to
>>>>> have a bad ending... So, to rephrase in your terms, why does the jar
>>>>> file
>>>>> name need to follow the current naming convention?
>>>>>
>>>>> --kevan
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>
>
--
Alasdair Nottingham
not@apache.org
Re: Aries release - the shape of repo org/apache/aries
Posted by David Jencks <da...@yahoo.com>.
On Mar 9, 2010, at 12:56 PM, Alasdair Nottingham wrote:
> I don't think it is fair to claim it is maven or eclipse winning.
> Eclipse is not the only group that use this convention. It is also
> used by felix, and I have been using the convention since I first
> worked on OSGi 5 years ago. It is pretty common.
>
> It is good practice because it makes it quick and easy to identify the
> identity of the bundle from the jar name, in a structure where you
> have multiple bundles in a directory it ensures you do not end up
> replacing one bundle with another which could happen if the jar name
> is not unique enough.
>
> It is my understanding that it is good practice to have the artifact
> id in maven unique in any case so people who gather jars together in
> assemblies do not end up replacing jars by mistake. That is what this
> achieves.
>
So to be a little more verbose about what I meant....
Maven has the idea that if you have a few million jars, you might not
want them all in the same directory. So it has a coordinate system
that makes it easy for an organization to have short jar names and
assure everyone that it's artifacts can be distinguished from everyone
elses, by using the groupId but not necessarily requiring unique
artifact ids.
Other systems, AFAIK including eclipse, have the idea that you only
have a few jars, maybe 1000, and putting them all in the same
directory is fine. In this situation you need to assure the jar name
is unique, and the usual method seems to be to form something
resembling <groupId>.<aritifactId>-<version>.jar from a minimal
artifactId. In order to get maven to name the jars in this style, you
need to include the groupId as a prefix in the artifactId, which is
obviously redundant for maven.
My personal opinion is that the non-maven approach is pretty
ridiculous, but this seems to be a rather unpopular opinion in the
osgi world at this time.
For the "assembly" scenario you mention, I'd just include a mini-maven-
repository with the desired jars, thus preventing any possible
confusion about what a jar is, even with non-unique artifactIds.
thanks
david jencks
> Alasdair
>
> On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>>
>> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>>
>>> I think the reason is that the bundle symbolic name is the unique id
>>> of the bundle. It has to be globally unique.
>>> When you use a non OSGi environment, you don't care about the jar
>>> name, you can simply rename it and it won't hurt anyone.
>>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>>> name does. A good practice is to have the jar be named
>>> symbolicname-version.jar which ease the identification. But the
>>> constraint of uniqueness on the symbolic name kinda forces the use
>>> of
>>> the org.apache.aries.xxx naming convention for the symbolic name,
>>> hence for the artifact.
>>>
>>> Makes sense ?
>>
>> Why is naming the jar symbolicname-version.jar good practice?
>> Obviously if
>> you think this then you will do it, but you've just asserted that
>> doing this
>> is a good idea without any support.
>>
>> It seems to me that the question kinda boils down to who wins,
>> maven or
>> eclipse.
>>
>> david jencks
>>
>>
>>>
>>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller
>>> <ke...@gmail.com> wrote:
>>>>
>>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>>
>>>>> Maven insists on naming the jar artifactid-version.jar since we
>>>>> wanted
>>>>> our jars to follow the bundle_symolicname-version.jar convention
>>>>> it forces
>>>>> duplication in the artifact id.
>>>>>
>>>>> This is why I was asking if we could get the jar name to be
>>>>> generated
>>>>> from the group and artifact id on IRC last week.
>>>>
>>>> That's not really answering my question. artifactid is
>>>> essentially the
>>>> jar file name and trying to get maven to act otherwise, is just
>>>> going to
>>>> have a bad ending... So, to rephrase in your terms, why does the
>>>> jar file
>>>> name need to follow the current naming convention?
>>>>
>>>> --kevan
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
I don't think it is fair to claim it is maven or eclipse winning.
Eclipse is not the only group that use this convention. It is also
used by felix, and I have been using the convention since I first
worked on OSGi 5 years ago. It is pretty common.
It is good practice because it makes it quick and easy to identify the
identity of the bundle from the jar name, in a structure where you
have multiple bundles in a directory it ensures you do not end up
replacing one bundle with another which could happen if the jar name
is not unique enough.
It is my understanding that it is good practice to have the artifact
id in maven unique in any case so people who gather jars together in
assemblies do not end up replacing jars by mistake. That is what this
achieves.
Alasdair
On 9 March 2010 20:43, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
>
>> I think the reason is that the bundle symbolic name is the unique id
>> of the bundle. It has to be globally unique.
>> When you use a non OSGi environment, you don't care about the jar
>> name, you can simply rename it and it won't hurt anyone.
>> In OSGi, the name of the jar doesn't matter either, but the symbolic
>> name does. A good practice is to have the jar be named
>> symbolicname-version.jar which ease the identification. But the
>> constraint of uniqueness on the symbolic name kinda forces the use of
>> the org.apache.aries.xxx naming convention for the symbolic name,
>> hence for the artifact.
>>
>> Makes sense ?
>
> Why is naming the jar symbolicname-version.jar good practice? Obviously if
> you think this then you will do it, but you've just asserted that doing this
> is a good idea without any support.
>
> It seems to me that the question kinda boils down to who wins, maven or
> eclipse.
>
> david jencks
>
>
>>
>> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com> wrote:
>>>
>>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>>
>>>> Maven insists on naming the jar artifactid-version.jar since we wanted
>>>> our jars to follow the bundle_symolicname-version.jar convention it forces
>>>> duplication in the artifact id.
>>>>
>>>> This is why I was asking if we could get the jar name to be generated
>>>> from the group and artifact id on IRC last week.
>>>
>>> That's not really answering my question. artifactid is essentially the
>>> jar file name and trying to get maven to act otherwise, is just going to
>>> have a bad ending... So, to rephrase in your terms, why does the jar file
>>> name need to follow the current naming convention?
>>>
>>> --kevan
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
--
Alasdair Nottingham
not@apache.org
Re: Aries release - the shape of repo org/apache/aries
Posted by David Jencks <da...@yahoo.com>.
On Mar 9, 2010, at 12:27 PM, Guillaume Nodet wrote:
> I think the reason is that the bundle symbolic name is the unique id
> of the bundle. It has to be globally unique.
> When you use a non OSGi environment, you don't care about the jar
> name, you can simply rename it and it won't hurt anyone.
> In OSGi, the name of the jar doesn't matter either, but the symbolic
> name does. A good practice is to have the jar be named
> symbolicname-version.jar which ease the identification. But the
> constraint of uniqueness on the symbolic name kinda forces the use of
> the org.apache.aries.xxx naming convention for the symbolic name,
> hence for the artifact.
>
> Makes sense ?
Why is naming the jar symbolicname-version.jar good practice?
Obviously if you think this then you will do it, but you've just
asserted that doing this is a good idea without any support.
It seems to me that the question kinda boils down to who wins, maven
or eclipse.
david jencks
>
> On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com>
> wrote:
>>
>> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>>
>>> Maven insists on naming the jar artifactid-version.jar since we
>>> wanted our jars to follow the bundle_symolicname-version.jar
>>> convention it forces duplication in the artifact id.
>>>
>>> This is why I was asking if we could get the jar name to be
>>> generated from the group and artifact id on IRC last week.
>>
>> That's not really answering my question. artifactid is essentially
>> the jar file name and trying to get maven to act otherwise, is just
>> going to have a bad ending... So, to rephrase in your terms, why
>> does the jar file name need to follow the current naming convention?
>>
>> --kevan
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Aries release - the shape of repo org/apache/aries
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the reason is that the bundle symbolic name is the unique id
of the bundle. It has to be globally unique.
When you use a non OSGi environment, you don't care about the jar
name, you can simply rename it and it won't hurt anyone.
In OSGi, the name of the jar doesn't matter either, but the symbolic
name does. A good practice is to have the jar be named
symbolicname-version.jar which ease the identification. But the
constraint of uniqueness on the symbolic name kinda forces the use of
the org.apache.aries.xxx naming convention for the symbolic name,
hence for the artifact.
Makes sense ?
On Tue, Mar 9, 2010 at 21:20, Kevan Miller <ke...@gmail.com> wrote:
>
> On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
>
>> Maven insists on naming the jar artifactid-version.jar since we wanted our jars to follow the bundle_symolicname-version.jar convention it forces duplication in the artifact id.
>>
>> This is why I was asking if we could get the jar name to be generated from the group and artifact id on IRC last week.
>
> That's not really answering my question. artifactid is essentially the jar file name and trying to get maven to act otherwise, is just going to have a bad ending... So, to rephrase in your terms, why does the jar file name need to follow the current naming convention?
>
> --kevan
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Aries release - the shape of repo org/apache/aries
Posted by Kevan Miller <ke...@gmail.com>.
On Mar 9, 2010, at 2:06 PM, Alasdair Nottingham wrote:
> Maven insists on naming the jar artifactid-version.jar since we wanted our jars to follow the bundle_symolicname-version.jar convention it forces duplication in the artifact id.
>
> This is why I was asking if we could get the jar name to be generated from the group and artifact id on IRC last week.
That's not really answering my question. artifactid is essentially the jar file name and trying to get maven to act otherwise, is just going to have a bad ending... So, to rephrase in your terms, why does the jar file name need to follow the current naming convention?
--kevan
Re: Aries release - the shape of repo org/apache/aries
Posted by Alasdair Nottingham <no...@apache.org>.
Maven insists on naming the jar artifactid-version.jar since we wanted
our jars to follow the bundle_symolicname-version.jar convention it
forces duplication in the artifact id.
This is why I was asking if we could get the jar name to be generated
from the group and artifact id on IRC last week.
Alasdair
On 9 Mar 2010, at 18:49, Kevan Miller <ke...@gmail.com> wrote:
>
> On Mar 8, 2010, at 8:56 AM, Jeremy Hughes 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.
>
> I seem to recall some discussion on this previously, but can't say I
> came away with an understanding. So, I'll ask my naive question...
> What's the motivation for naming artifactid's this way? e.g.:
>
> org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.1-
> incubating-SNAPSHOT/org.apache.aries.blueprint.core-0.1-incubating-
> SNAPSHOT.jar
>
> --kevan
Re: Aries release - the shape of repo org/apache/aries
Posted by Kevan Miller <ke...@gmail.com>.
On Mar 8, 2010, at 8:56 AM, Jeremy Hughes 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.
I seem to recall some discussion on this previously, but can't say I came away with an understanding. So, I'll ask my naive question... What's the motivation for naming artifactid's this way? e.g.:
org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.1-incubating-SNAPSHOT/org.apache.aries.blueprint.core-0.1-incubating-SNAPSHOT.jar
--kevan
Re: Aries release - the shape of repo org/apache/aries
Posted by Joe Bohn <jo...@gmail.com>.
I figured that was more likely the case.
I'll make the recommended changes and update the groupIds and
artifactIds to match the rest of Apache Aries and more particularly
other samples. If we end up changing the direction and going with the
shorted artifactIds (per other discussions) we can change them all at
the same time - at least they will be consistent.
Thanks,
Joe
Jeremy Hughes wrote:
> On 10 March 2010 03:00, Joe Bohn <jo...@gmail.com> wrote:
>> Jeremy,
>>
>> I can't help but notice that in your list below you don't mention the
>> AriesTrader sample at all. I guess that means that it is perfect for
>> release just the way it is? ;-)
>
> Ah that was an oversight - I think it has something to do with, at the
> time I created the list, ariestrader not being built from a top level
> build. I see it's hooked in now. I see the groudId is parent groupId
> is org.apache.aries.ariestrader instead of
> org.apache.aries.samples.ariestrader. I thought we discussed changing
> this.
>
> The jars I can see currently being put into the local repo in
> org/apache/aries/ariestrader are:
>
> ./assemblies/ariestrader-all-eba/0.1-incubating/ariestrader-all-eba-0.1-incubating.eba
> ./assemblies/ariestrader-jdbc-eba/0.1-incubating/ariestrader-jdbc-eba-0.1-incubating.eba
> ./modules/ariestrader-api/0.1-incubating/ariestrader-api-0.1-incubating.jar
> ./modules/ariestrader-beans/0.1-incubating/ariestrader-beans-0.1-incubating.jar
> ./modules/ariestrader-core/0.1-incubating/ariestrader-core-0.1-incubating.jar
> ./modules/ariestrader-derby-ds/0.1-incubating/ariestrader-derby-ds-0.1-incubating.jar
> ./modules/ariestrader-entities/0.1-incubating/ariestrader-entities-0.1-incubating.jar
> ./modules/ariestrader-persist-jdbc/0.1-incubating/ariestrader-persist-jdbc-0.1-incubating.jar
> ./modules/ariestrader-persist-jpa-am/0.1-incubating/ariestrader-persist-jpa-am-0.1-incubating.jar
> ./modules/ariestrader-persist-jpa-cm/0.1-incubating/ariestrader-persist-jpa-cm-0.1-incubating.jar
> ./modules/ariestrader-util/0.1-incubating/ariestrader-util-0.1-incubating.jar
> ./modules/ariestrader-web/0.1-incubating/ariestrader-web-0.1-incubating.jar
>
> So if we are to follow what I've proposed for the rest instead of:
>
> org/apache/aries/ariestrader/ariestrader-api/0.1-incubating/ariestrader-api-0.1-incubating.jar
>
> we would have:
>
> org/apache/aries/samples/ariestrader/org.apache.aries.samples.ariestrader.api/0.1-incubating/org.apache.aries.samples.ariestrader.api-0.1-incubating.jar
>
> and instead of the BSN in that bundle being
> org.apache.aries.ariestrader.modules.ariestrader-api it would be
> org.apache.aries.samples.ariestrader.api
>
> and then we would apply that to all the other 'modules'.
>
> With the .eba assemblies, instead of:
>
> org/apache/aries/ariestrader/assemblies/ariestrader-all-eba/0.1-incubating/ariestrader-all-eba-0.1-incubating.eba
>
> we would have:
>
> org/apache/aries/samples/ariestrader/org.apache.aries.samples.ariestrader.all-0.1-incubating.eba
>
> and instead of the BSN in that eba being ariestrader.eba it woul be
> org.apache.aries.samples.ariestrader.all ... but I suspect this is the
> eba-maven-plugin's fault.
>
> WDYT?
>
>> Joe
>>
>>
>> Jeremy Hughes 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:
>>>
>>> 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
>>>
>>
>> --
>> Joe
>>
>
--
Joe
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 10 March 2010 03:00, Joe Bohn <jo...@gmail.com> wrote:
>
> Jeremy,
>
> I can't help but notice that in your list below you don't mention the
> AriesTrader sample at all. I guess that means that it is perfect for
> release just the way it is? ;-)
Ah that was an oversight - I think it has something to do with, at the
time I created the list, ariestrader not being built from a top level
build. I see it's hooked in now. I see the groudId is parent groupId
is org.apache.aries.ariestrader instead of
org.apache.aries.samples.ariestrader. I thought we discussed changing
this.
The jars I can see currently being put into the local repo in
org/apache/aries/ariestrader are:
./assemblies/ariestrader-all-eba/0.1-incubating/ariestrader-all-eba-0.1-incubating.eba
./assemblies/ariestrader-jdbc-eba/0.1-incubating/ariestrader-jdbc-eba-0.1-incubating.eba
./modules/ariestrader-api/0.1-incubating/ariestrader-api-0.1-incubating.jar
./modules/ariestrader-beans/0.1-incubating/ariestrader-beans-0.1-incubating.jar
./modules/ariestrader-core/0.1-incubating/ariestrader-core-0.1-incubating.jar
./modules/ariestrader-derby-ds/0.1-incubating/ariestrader-derby-ds-0.1-incubating.jar
./modules/ariestrader-entities/0.1-incubating/ariestrader-entities-0.1-incubating.jar
./modules/ariestrader-persist-jdbc/0.1-incubating/ariestrader-persist-jdbc-0.1-incubating.jar
./modules/ariestrader-persist-jpa-am/0.1-incubating/ariestrader-persist-jpa-am-0.1-incubating.jar
./modules/ariestrader-persist-jpa-cm/0.1-incubating/ariestrader-persist-jpa-cm-0.1-incubating.jar
./modules/ariestrader-util/0.1-incubating/ariestrader-util-0.1-incubating.jar
./modules/ariestrader-web/0.1-incubating/ariestrader-web-0.1-incubating.jar
So if we are to follow what I've proposed for the rest instead of:
org/apache/aries/ariestrader/ariestrader-api/0.1-incubating/ariestrader-api-0.1-incubating.jar
we would have:
org/apache/aries/samples/ariestrader/org.apache.aries.samples.ariestrader.api/0.1-incubating/org.apache.aries.samples.ariestrader.api-0.1-incubating.jar
and instead of the BSN in that bundle being
org.apache.aries.ariestrader.modules.ariestrader-api it would be
org.apache.aries.samples.ariestrader.api
and then we would apply that to all the other 'modules'.
With the .eba assemblies, instead of:
org/apache/aries/ariestrader/assemblies/ariestrader-all-eba/0.1-incubating/ariestrader-all-eba-0.1-incubating.eba
we would have:
org/apache/aries/samples/ariestrader/org.apache.aries.samples.ariestrader.all-0.1-incubating.eba
and instead of the BSN in that eba being ariestrader.eba it woul be
org.apache.aries.samples.ariestrader.all ... but I suspect this is the
eba-maven-plugin's fault.
WDYT?
>
> Joe
>
>
> Jeremy Hughes 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:
>>
>> 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
>>
>
>
> --
> Joe
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Joe Bohn <jo...@gmail.com>.
Jeremy,
I can't help but notice that in your list below you don't mention the
AriesTrader sample at all. I guess that means that it is perfect for
release just the way it is? ;-)
Joe
Jeremy Hughes 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:
>
> 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
>
--
Joe
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
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
>>>
>>>
>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
Joe Bohn wrote:
> zoe slattery wrote:
>>
>>>>
>>>> 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 am beginning to think it probably isn't possible :-).
>>
>> I spent some time trying to work out how to generate a platform zip
>> for the blog sample. Generating the zip using the assembly plugin is
>> straightforward enough but I ran into problems when the
>> apache-release process checks the licenses. I think it's checking for
>> META-INF/LICENCE inside every jar in the zip. Of course it doesn't
>> find them for equinox platform jars - so it chokes.
>>
>> A better plan would be to make a standalone-assembly project that
>> will create a zip that just has a pom.xml (the same as the one in the
>> the blog-assembly project) and the platform configuration files
>> (configuration/config.ini). The zip could be extracted into say /tmp,
>> then 'mvn install' should create the whole platform as long as the
>> user have maven and java installed. I have this working perfectly. To
>> create the zip I run:
>>
>> mvn install -Papache-release
>>
>> from within the standalone-assembly project, the zip file is created
>> and installed in .m2/repository. Great.
>>
>> However - this won't work as part of build of the full tree, the
>> problem is:
>>
>> [INFO] [assembly:single {execution: source-release-assembly}]
>> [INFO] Skipping the assembly in this project because it's not the
>> Execution Root
>>
>> so, the zip file will never be built.
>>
>> Is there another way to do this? Or am I missing something obvious?
>> If not I think we just have to say that people who want to run the
>> samples have to check out and build Aries - this seems less than
>> ideal to me. My standalone-assembly project is not checked in, I can
>> do so if anyone else wants to look at this.
>
> A few things come to mind here:
> 1) Back before we had the eba-maven-plugin I had a rather complicated
> scheme to create my EBAs. I went through a lot of hoops to create the
> appropriate *.eba and but it involved ant and wasn't pushed to the
> repo - so I used the build-helper-maven-plugin to push it out the
> maven repo. I wonder if this will work for this scenario.
> 2) Geronimo does something very similar in their build. They generate
> a set of geronimo assemblies in zip and tar.gz using a custom plugin -
> geronimo-maven-plugin. It might be a bit strange but we could
> potentially use that plugin or perhaps copy it, strip all that we
> don't care about and keep just what we need.
> 3) I've been told that Karaf does something similar for their
> assemblies - not sure what they use but it might be worth a look.
I had a look at (1) and couldn't find a way that it helped. (2) and (3)
sound interesting - we can't be the only project trying to do something
like this.
I checked in my additional project (under the blog sample) - it does
work if we don't use the apache-release profile but I feel there must be
better ways...
Zoe
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 24 March 2010 20:28, Joe Bohn <jo...@gmail.com> wrote:
> zoe slattery wrote:
>>
>>>>
>>>> 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 am beginning to think it probably isn't possible :-).
>>
>> I spent some time trying to work out how to generate a platform zip for
>> the blog sample. Generating the zip using the assembly plugin is
>> straightforward enough but I ran into problems when the apache-release
>> process checks the licenses. I think it's checking for META-INF/LICENCE
>> inside every jar in the zip. Of course it doesn't find them for equinox
>> platform jars - so it chokes.
>>
>> A better plan would be to make a standalone-assembly project that will
>> create a zip that just has a pom.xml (the same as the one in the the
>> blog-assembly project) and the platform configuration files
>> (configuration/config.ini). The zip could be extracted into say /tmp, then
>> 'mvn install' should create the whole platform as long as the user have
>> maven and java installed. I have this working perfectly. To create the zip I
>> run:
>>
>> mvn install -Papache-release
>>
>> from within the standalone-assembly project, the zip file is created and
>> installed in .m2/repository. Great.
>>
>> However - this won't work as part of build of the full tree, the problem
>> is:
>>
>> [INFO] [assembly:single {execution: source-release-assembly}]
>> [INFO] Skipping the assembly in this project because it's not the
>> Execution Root
>>
>> so, the zip file will never be built.
>>
>> Is there another way to do this? Or am I missing something obvious? If not
>> I think we just have to say that people who want to run the samples have to
>> check out and build Aries - this seems less than ideal to me. My
>> standalone-assembly project is not checked in, I can do so if anyone else
>> wants to look at this.
>
> A few things come to mind here:
> 1) Back before we had the eba-maven-plugin I had a rather complicated scheme
> to create my EBAs. I went through a lot of hoops to create the appropriate
> *.eba and but it involved ant and wasn't pushed to the repo - so I used the
> build-helper-maven-plugin to push it out the maven repo. I wonder if this
> will work for this scenario.
> 2) Geronimo does something very similar in their build. They generate a set
> of geronimo assemblies in zip and tar.gz using a custom plugin -
> geronimo-maven-plugin. It might be a bit strange but we could potentially
> use that plugin or perhaps copy it, strip all that we don't care about and
> keep just what we need.
> 3) I've been told that Karaf does something similar for their assemblies -
> not sure what they use but it might be worth a look.
Karaf has a profile called 'release' which uses the assembly plugin. I
assume it is used instead of a profile from further up the food chain.
The plugin config doesn't alter the runOnlyAtExecutionRoot flag. So if
we were to use our own profile for releasing then we'd be following
the Karaf pattern. I think that's ok at least for now.
>
> Joe
>
>>
>> Zoe
>>
>>>
>>>
>>>>
>>>>> 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
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Joe Bohn <jo...@gmail.com>.
zoe slattery wrote:
>
>>>
>>> 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 am beginning to think it probably isn't possible :-).
>
> I spent some time trying to work out how to generate a platform zip for
> the blog sample. Generating the zip using the assembly plugin is
> straightforward enough but I ran into problems when the apache-release
> process checks the licenses. I think it's checking for META-INF/LICENCE
> inside every jar in the zip. Of course it doesn't find them for equinox
> platform jars - so it chokes.
>
> A better plan would be to make a standalone-assembly project that will
> create a zip that just has a pom.xml (the same as the one in the the
> blog-assembly project) and the platform configuration files
> (configuration/config.ini). The zip could be extracted into say /tmp,
> then 'mvn install' should create the whole platform as long as the user
> have maven and java installed. I have this working perfectly. To create
> the zip I run:
>
> mvn install -Papache-release
>
> from within the standalone-assembly project, the zip file is created
> and installed in .m2/repository. Great.
>
> However - this won't work as part of build of the full tree, the problem
> is:
>
> [INFO] [assembly:single {execution: source-release-assembly}]
> [INFO] Skipping the assembly in this project because it's not the
> Execution Root
>
> so, the zip file will never be built.
>
> Is there another way to do this? Or am I missing something obvious? If
> not I think we just have to say that people who want to run the samples
> have to check out and build Aries - this seems less than ideal to me. My
> standalone-assembly project is not checked in, I can do so if anyone
> else wants to look at this.
A few things come to mind here:
1) Back before we had the eba-maven-plugin I had a rather complicated
scheme to create my EBAs. I went through a lot of hoops to create the
appropriate *.eba and but it involved ant and wasn't pushed to the repo
- so I used the build-helper-maven-plugin to push it out the maven repo.
I wonder if this will work for this scenario.
2) Geronimo does something very similar in their build. They generate a
set of geronimo assemblies in zip and tar.gz using a custom plugin -
geronimo-maven-plugin. It might be a bit strange but we could
potentially use that plugin or perhaps copy it, strip all that we don't
care about and keep just what we need.
3) I've been told that Karaf does something similar for their assemblies
- not sure what they use but it might be worth a look.
Joe
>
> Zoe
>
>>
>>
>>>
>>>> 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
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 23 March 2010 16:53, zoe slattery <zo...@googlemail.com> wrote:
>
>>>
>>> 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 am beginning to think it probably isn't possible :-).
>
> I spent some time trying to work out how to generate a platform zip for the
> blog sample. Generating the zip using the assembly plugin is straightforward
> enough but I ran into problems when the apache-release process checks the
> licenses. I think it's checking for META-INF/LICENCE inside every jar in the
> zip. Of course it doesn't find them for equinox platform jars - so it
> chokes.
>
> A better plan would be to make a standalone-assembly project that will
> create a zip that just has a pom.xml (the same as the one in the the
> blog-assembly project) and the platform configuration files
> (configuration/config.ini). The zip could be extracted into say /tmp, then
> 'mvn install' should create the whole platform as long as the user have
> maven and java installed. I have this working perfectly. To create the zip I
> run:
>
> mvn install -Papache-release
>
> from within the standalone-assembly project, the zip file is created and
> installed in .m2/repository. Great.
>
> However - this won't work as part of build of the full tree, the problem is:
>
> [INFO] [assembly:single {execution: source-release-assembly}]
> [INFO] Skipping the assembly in this project because it's not the Execution
> Root
>
> so, the zip file will never be built.
>
> Is there another way to do this? Or am I missing something obvious? If not I
> think we just have to say that people who want to run the samples have to
> check out and build Aries - this seems less than ideal to me. My
> standalone-assembly project is not checked in, I can do so if anyone else
> wants to look at this.
Sure, I think it's worth checking it in to share even if it's not
finished. I'll take a look if you do.
>
> Zoe
>
>>
>>
>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
Jeremy Hughes wrote:
> On 24 March 2010 14:19, zoe slattery <zo...@googlemail.com> wrote:
>
>> Hi Jeremy - just to add a couple more bits of information inline
>>
>>>>>> 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 am beginning to think it probably isn't possible :-).
>>>>
>>>> I spent some time trying to work out how to generate a platform zip for
>>>> the
>>>> blog sample. Generating the zip using the assembly plugin is
>>>> straightforward
>>>> enough but I ran into problems when the apache-release process checks the
>>>> licenses. I think it's checking for META-INF/LICENCE inside every jar in
>>>> the
>>>> zip. Of course it doesn't find them for equinox platform jars - so it
>>>> chokes.
>>>>
>>>> A better plan would be to make a standalone-assembly project that will
>>>> create a zip that just has a pom.xml (the same as the one in the the
>>>> blog-assembly project) and the platform configuration files
>>>> (configuration/config.ini). The zip could be extracted into say /tmp,
>>>> then
>>>> 'mvn install' should create the whole platform as long as the user have
>>>> maven and java installed. I have this working perfectly. To create the
>>>> zip I
>>>> run:
>>>>
>>>> mvn install -Papache-release
>>>>
>>>> from within the standalone-assembly project, the zip file is created and
>>>> installed in .m2/repository. Great.
>>>>
>>>> However - this won't work as part of build of the full tree, the problem
>>>> is:
>>>>
>>>> [INFO] [assembly:single {execution: source-release-assembly}]
>>>> [INFO] Skipping the assembly in this project because it's not the
>>>> Execution
>>>> Root
>>>>
>>>> so, the zip file will never be built.
>>>>
>>>> Is there another way to do this?
>>>>
>>>>
>>> Assembly plugin would be the ideal way. Does setting
>>> runOnlyAtExecutionRoot to false work? It seems the default for this is
>>> false anyway, but maybe something in a parent / grandparent pom etc is
>>> setting it to true.
>>>
>>>
>> This: <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot> is set in the
>> Apacche7pom. Use of a profile (in this case the Apache7pom) will override
>> any local settings, so if we have project poms that explictly set
>> <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot> they are simply
>> ignored.
>>
>> Thus - the only way that I can find to generate a zip/tar from something
>> that is not the execution root is to take a copy of the apache-release
>> profile from the Apache7pom, remove the line
>> <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>, paste it into a
>> pom.xml (I tried samples) and rename it to 'aries-release'. I can then
>> create artifacts using the assembly plugin which are treated as part of the
>> release using:
>>
>> mvn install -Paries-release
>>
>
> Is aries-release the same as the apache-release profile except the
> runOnlyAtExecutionRoot flag change?
>
Yes
>
>> Just FYI - I tried:
>>
>> mvn install -Papache-release -DrunOnlyAtExecutionRoot=false
>>
>> hoping that an explicit command line flag would override the 'true' setting.
>> It doesn't.
>>
>> Summary: Right now I can't see a way to release samples that are easy to run
>> AND use the Apache7pom release profile. I wish there was a way around this
>> but at the moment I think we are looking at:
>>
>> (a) Release samples which people can run without having to checkout and
>> build the whole of Aries and use a modified Apache7 release profile.
>>
>
> by this I take it that you mean add a profile called aries-release
> (that you used above) to the Aries parent pom rather than modifying
> anything in the Apache 7 pom
>
>
>> (b) Use the Apache7 release profile and make people who want to run our
>> samples either assemble their own platform, or checkout and build Aries.
>>
>
> I don't like forcing people to checkout and build Aries in order to
> run the samples. Assembling their own platform is possibly even more
> distasteful because it is not automated.
>
> The objective here is to create a platform which we know works for
> users to quickly get something running. Something else this will
> achieve is if they were to do more complex things - like Joe was
> suggesting earlier - they always have a fallback that works.
>
> So I'm +1 to (a). I will bring start a discussion on
> repository@apache.org about why this flag is set in the Apache pom and
> if there's a known way of overriding it.
>
>
>> I don't like either option much so would like to hear from anyone who has a
>> better solution.
>>
>> Zoe
>>
>>>
>>>> Or am I missing something obvious? If not I
>>>> think we just have to say that people who want to run the samples have to
>>>> check out and build Aries - this seems less than ideal to me. My
>>>> standalone-assembly project is not checked in, I can do so if anyone else
>>>> wants to look at this.
>>>>
>>>> Zoe
>>>>
>>>>
>>>>
>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 24 March 2010 14:19, zoe slattery <zo...@googlemail.com> wrote:
> Hi Jeremy - just to add a couple more bits of information inline
>>>>>
>>>>> 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 am beginning to think it probably isn't possible :-).
>>>
>>> I spent some time trying to work out how to generate a platform zip for
>>> the
>>> blog sample. Generating the zip using the assembly plugin is
>>> straightforward
>>> enough but I ran into problems when the apache-release process checks the
>>> licenses. I think it's checking for META-INF/LICENCE inside every jar in
>>> the
>>> zip. Of course it doesn't find them for equinox platform jars - so it
>>> chokes.
>>>
>>> A better plan would be to make a standalone-assembly project that will
>>> create a zip that just has a pom.xml (the same as the one in the the
>>> blog-assembly project) and the platform configuration files
>>> (configuration/config.ini). The zip could be extracted into say /tmp,
>>> then
>>> 'mvn install' should create the whole platform as long as the user have
>>> maven and java installed. I have this working perfectly. To create the
>>> zip I
>>> run:
>>>
>>> mvn install -Papache-release
>>>
>>> from within the standalone-assembly project, the zip file is created and
>>> installed in .m2/repository. Great.
>>>
>>> However - this won't work as part of build of the full tree, the problem
>>> is:
>>>
>>> [INFO] [assembly:single {execution: source-release-assembly}]
>>> [INFO] Skipping the assembly in this project because it's not the
>>> Execution
>>> Root
>>>
>>> so, the zip file will never be built.
>>>
>>> Is there another way to do this?
>>>
>>
>> Assembly plugin would be the ideal way. Does setting
>> runOnlyAtExecutionRoot to false work? It seems the default for this is
>> false anyway, but maybe something in a parent / grandparent pom etc is
>> setting it to true.
>>
>
> This: <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot> is set in the
> Apacche7pom. Use of a profile (in this case the Apache7pom) will override
> any local settings, so if we have project poms that explictly set
> <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot> they are simply
> ignored.
>
> Thus - the only way that I can find to generate a zip/tar from something
> that is not the execution root is to take a copy of the apache-release
> profile from the Apache7pom, remove the line
> <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>, paste it into a
> pom.xml (I tried samples) and rename it to 'aries-release'. I can then
> create artifacts using the assembly plugin which are treated as part of the
> release using:
>
> mvn install -Paries-release
Is aries-release the same as the apache-release profile except the
runOnlyAtExecutionRoot flag change?
>
> Just FYI - I tried:
>
> mvn install -Papache-release -DrunOnlyAtExecutionRoot=false
>
> hoping that an explicit command line flag would override the 'true' setting.
> It doesn't.
>
> Summary: Right now I can't see a way to release samples that are easy to run
> AND use the Apache7pom release profile. I wish there was a way around this
> but at the moment I think we are looking at:
>
> (a) Release samples which people can run without having to checkout and
> build the whole of Aries and use a modified Apache7 release profile.
by this I take it that you mean add a profile called aries-release
(that you used above) to the Aries parent pom rather than modifying
anything in the Apache 7 pom
> (b) Use the Apache7 release profile and make people who want to run our
> samples either assemble their own platform, or checkout and build Aries.
I don't like forcing people to checkout and build Aries in order to
run the samples. Assembling their own platform is possibly even more
distasteful because it is not automated.
The objective here is to create a platform which we know works for
users to quickly get something running. Something else this will
achieve is if they were to do more complex things - like Joe was
suggesting earlier - they always have a fallback that works.
So I'm +1 to (a). I will bring start a discussion on
repository@apache.org about why this flag is set in the Apache pom and
if there's a known way of overriding it.
>
> I don't like either option much so would like to hear from anyone who has a
> better solution.
>
> Zoe
>>
>>
>>>
>>> Or am I missing something obvious? If not I
>>> think we just have to say that people who want to run the samples have to
>>> check out and build Aries - this seems less than ideal to me. My
>>> standalone-assembly project is not checked in, I can do so if anyone else
>>> wants to look at this.
>>>
>>> Zoe
>>>
>>>
>>>>
>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
Hi Jeremy - just to add a couple more bits of information inline
>>>> 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 am beginning to think it probably isn't possible :-).
>>
>> I spent some time trying to work out how to generate a platform zip for the
>> blog sample. Generating the zip using the assembly plugin is straightforward
>> enough but I ran into problems when the apache-release process checks the
>> licenses. I think it's checking for META-INF/LICENCE inside every jar in the
>> zip. Of course it doesn't find them for equinox platform jars - so it
>> chokes.
>>
>> A better plan would be to make a standalone-assembly project that will
>> create a zip that just has a pom.xml (the same as the one in the the
>> blog-assembly project) and the platform configuration files
>> (configuration/config.ini). The zip could be extracted into say /tmp, then
>> 'mvn install' should create the whole platform as long as the user have
>> maven and java installed. I have this working perfectly. To create the zip I
>> run:
>>
>> mvn install -Papache-release
>>
>> from within the standalone-assembly project, the zip file is created and
>> installed in .m2/repository. Great.
>>
>> However - this won't work as part of build of the full tree, the problem is:
>>
>> [INFO] [assembly:single {execution: source-release-assembly}]
>> [INFO] Skipping the assembly in this project because it's not the Execution
>> Root
>>
>> so, the zip file will never be built.
>>
>> Is there another way to do this?
>>
>
> Assembly plugin would be the ideal way. Does setting
> runOnlyAtExecutionRoot to false work? It seems the default for this is
> false anyway, but maybe something in a parent / grandparent pom etc is
> setting it to true.
>
This: <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot> is set in
the Apacche7pom. Use of a profile (in this case the Apache7pom) will
override any local settings, so if we have project poms that explictly
set <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot> they are
simply ignored.
Thus - the only way that I can find to generate a zip/tar from something
that is not the execution root is to take a copy of the apache-release
profile from the Apache7pom, remove the line
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>, paste it into a
pom.xml (I tried samples) and rename it to 'aries-release'. I can then
create artifacts using the assembly plugin which are treated as part of
the release using:
mvn install -Paries-release
Just FYI - I tried:
mvn install -Papache-release -DrunOnlyAtExecutionRoot=false
hoping that an explicit command line flag would override the 'true'
setting. It doesn't.
Summary: Right now I can't see a way to release samples that are easy to
run AND use the Apache7pom release profile. I wish there was a way
around this but at the moment I think we are looking at:
(a) Release samples which people can run without having to checkout and
build the whole of Aries and use a modified Apache7 release profile.
(b) Use the Apache7 release profile and make people who want to run our
samples either assemble their own platform, or checkout and build Aries.
I don't like either option much so would like to hear from anyone who
has a better solution.
Zoe
>
>> Or am I missing something obvious? If not I
>> think we just have to say that people who want to run the samples have to
>> check out and build Aries - this seems less than ideal to me. My
>> standalone-assembly project is not checked in, I can do so if anyone else
>> wants to look at this.
>>
>> Zoe
>>
>>
>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
Jeremy Hughes wrote:
> On 23 March 2010 16:53, zoe slattery <zo...@googlemail.com> wrote:
>
>>>> 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 am beginning to think it probably isn't possible :-).
>>
>> I spent some time trying to work out how to generate a platform zip for the
>> blog sample. Generating the zip using the assembly plugin is straightforward
>> enough but I ran into problems when the apache-release process checks the
>> licenses. I think it's checking for META-INF/LICENCE inside every jar in the
>> zip. Of course it doesn't find them for equinox platform jars - so it
>> chokes.
>>
>> A better plan would be to make a standalone-assembly project that will
>> create a zip that just has a pom.xml (the same as the one in the the
>> blog-assembly project) and the platform configuration files
>> (configuration/config.ini). The zip could be extracted into say /tmp, then
>> 'mvn install' should create the whole platform as long as the user have
>> maven and java installed. I have this working perfectly. To create the zip I
>> run:
>>
>> mvn install -Papache-release
>>
>> from within the standalone-assembly project, the zip file is created and
>> installed in .m2/repository. Great.
>>
>> However - this won't work as part of build of the full tree, the problem is:
>>
>> [INFO] [assembly:single {execution: source-release-assembly}]
>> [INFO] Skipping the assembly in this project because it's not the Execution
>> Root
>>
>> so, the zip file will never be built.
>>
>> Is there another way to do this?
>>
>
> Assembly plugin would be the ideal way. Does setting
> runOnlyAtExecutionRoot to false work? It seems the default for this is
> false anyway, but maybe something in a parent / grandparent pom etc is
> setting it to true.
>
It is set to true in the Apache7pom.xml. So, my understanding of this is
that we if want to use the Apache release process we are stuck with
it...does any Maven expert know a way around this?
>
>> Or am I missing something obvious? If not I
>> think we just have to say that people who want to run the samples have to
>> check out and build Aries - this seems less than ideal to me. My
>> standalone-assembly project is not checked in, I can do so if anyone else
>> wants to look at this.
>>
>> Zoe
>>
>>
>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Jeremy Hughes <hu...@apache.org>.
On 23 March 2010 16:53, zoe slattery <zo...@googlemail.com> wrote:
>
>>>
>>> 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 am beginning to think it probably isn't possible :-).
>
> I spent some time trying to work out how to generate a platform zip for the
> blog sample. Generating the zip using the assembly plugin is straightforward
> enough but I ran into problems when the apache-release process checks the
> licenses. I think it's checking for META-INF/LICENCE inside every jar in the
> zip. Of course it doesn't find them for equinox platform jars - so it
> chokes.
>
> A better plan would be to make a standalone-assembly project that will
> create a zip that just has a pom.xml (the same as the one in the the
> blog-assembly project) and the platform configuration files
> (configuration/config.ini). The zip could be extracted into say /tmp, then
> 'mvn install' should create the whole platform as long as the user have
> maven and java installed. I have this working perfectly. To create the zip I
> run:
>
> mvn install -Papache-release
>
> from within the standalone-assembly project, the zip file is created and
> installed in .m2/repository. Great.
>
> However - this won't work as part of build of the full tree, the problem is:
>
> [INFO] [assembly:single {execution: source-release-assembly}]
> [INFO] Skipping the assembly in this project because it's not the Execution
> Root
>
> so, the zip file will never be built.
>
> Is there another way to do this?
Assembly plugin would be the ideal way. Does setting
runOnlyAtExecutionRoot to false work? It seems the default for this is
false anyway, but maybe something in a parent / grandparent pom etc is
setting it to true.
> Or am I missing something obvious? If not I
> think we just have to say that people who want to run the samples have to
> check out and build Aries - this seems less than ideal to me. My
> standalone-assembly project is not checked in, I can do so if anyone else
> wants to look at this.
>
> Zoe
>
>>
>>
>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
>>
>> 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 am beginning to think it probably isn't possible :-).
I spent some time trying to work out how to generate a platform zip for
the blog sample. Generating the zip using the assembly plugin is
straightforward enough but I ran into problems when the apache-release
process checks the licenses. I think it's checking for META-INF/LICENCE
inside every jar in the zip. Of course it doesn't find them for equinox
platform jars - so it chokes.
A better plan would be to make a standalone-assembly project that will
create a zip that just has a pom.xml (the same as the one in the the
blog-assembly project) and the platform configuration files
(configuration/config.ini). The zip could be extracted into say /tmp,
then 'mvn install' should create the whole platform as long as the user
have maven and java installed. I have this working perfectly. To create
the zip I run:
mvn install -Papache-release
from within the standalone-assembly project, the zip file is created
and installed in .m2/repository. Great.
However - this won't work as part of build of the full tree, the problem is:
[INFO] [assembly:single {execution: source-release-assembly}]
[INFO] Skipping the assembly in this project because it's not the
Execution Root
so, the zip file will never be built.
Is there another way to do this? Or am I missing something obvious? If
not I think we just have to say that people who want to run the samples
have to check out and build Aries - this seems less than ideal to me. My
standalone-assembly project is not checked in, I can do so if anyone
else wants to look at this.
Zoe
>
>
>>
>>> 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
>>>
>>>
>>
>>
>
>
Re: Aries release - the shape of repo org/apache/aries
Posted by Joe Bohn <jo...@gmail.com>.
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
Re: Aries release - the shape of repo org/apache/aries
Posted by zoe slattery <zo...@googlemail.com>.
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.
> 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
>
>