Hi Gert,
I think that we need to distinguish two topics:
1/ for a logical point of view:
- in which project the bundles are embedded
- what's groupId we need to use
2/ for a technical point of view:
- where the bundles are releases and exposed (OBR)
From my point of view:
- the SMX project needs to manage only SMX related bundles (for example,
component bundles, etc). The groupId still org.apache.servicemix
- tiers bundles (such as the one in smx4/bundles) should be maybe
embedded in a more generic project (such as apache-bundles or something
like thin) with a groupId different from the org.apache.servicemix one.
Nevertheless it has an impact for us (especially around features as the
groupId changes).
- as more and more apache projects provide bundles (like us, commons,
cxf, etc), all this kind of bundles should be available on a central
OBR. As discussed yesterday, the nexus OBR extension can be very helpful.
Regards
JB
Gert Vanthienen wrote:
L.S.,
Last night, I was looking for a bundle for Sun's JNA and I created a
pom.xml for generating it in our own bundles project. However, we can
not release this at Apache because JNA is LGPL-licensed.
This raises the question if our Apache project is the ideal place for
creating and releasing those bundles. Most of the things we use have
an Apache-compatible license, but for the other stuff we would need to
look for another location. Wouldn't it be a better idea to move all
of the bundles to another location instead of having things at two
distinct locations? Any suggestions on where to move things?
On the other hand, the SpringSource folks already have a large set of
bundles that are publicly available at
http://www.springsource.com/repository/app/. Do we want to
build/maintain our own bundles next to those available or should we
just use what's available out there?
Thoughts?
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
