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 <[email protected]> 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
<[email protected]> 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
[email protected]
