I agree, option 1 is best. Alasdair
On 10 March 2010 14:45, Lin Sun <[email protected]> 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 <[email protected]> wrote: >> On 9 March 2010 23:21, David Jencks <[email protected]> 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 <[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] >>> >>> >> > -- Alasdair Nottingham [email protected]
