Re[2]: [Maven Plugin] Additional fixes...

[Peter Kriens <Pe...@aQute.se>]

Why is everybody so worried about the filename of the JAR?? It is
trivial to find the BSN + version by looking in the manifest. With
this information anybody can use his own scheme.

Trying to align JAR file names seems a rather useless exercise. An
almost trivial program can rename them to any style you want.

Kind regards,

     Peter Kriens



JM> Niclas Hedhman <he...@gmail.com> wrote on 06/01/2006 02:10:08 AM:

>> On Thursday 01 June 2006 10:48, Jeff McAffer wrote:
>> 
>> > I'm assuming that by "Eclipse being overkill" you mean the Eclipse
>> > filenaming scheme outlined earlier?  I 
>> 
>> Nah... I meant, that I must use Eclipse IDE or I can't develop OSGi 
JM> systems. 
>> Eclipse meaning the entire thing, that I personally am not very fond of 
JM> as a 
>> development tool, although I think Eclipse as an RCP for my own 
JM> applications 
>> make total sense.

JM> We've had this discussion before.  No one in this discussion is proposing
JM> that Eclipse the IDE has to be used for anything.  We are talking about
JM> bundle JAR naming conventions.

>> > If you happen to have 3 or 4 different sources for
>> > bundles that go into your product (OBR, Felix Commons, Equinox, ...) 
JM> then
>> > you may end up shipping several different layouts.
>> 
>> The general approach is in Maven camps the opposite. Any needed artifact 
JM> gets 
>> published to a repository. Last time I checked 13000 something Jars was 
>> available in Mavens central repository, then plus many projects having 
JM> their 
>> own to fill some remaining gaps. There can't be many Java OSS projects 
JM> that 
>> is not present...
>>
>> There is indeed a huge investment in standardizing this issue, and 
JM> Eclipse is 
>> the significant exception, rather than the rule, at least from my angle 
JM> of 
>> view.

JM> In this part of the discussion I am focused on shipping 
JM> products/offerings/...  I am not aware of any products that, upon 
JM> installation to the user's machine, go and fetch JARs from a Maven repo.
JM> Local or remote.  The issue is that if JARs are named for the convenience
JM> of the development time repo and these names are not unique, then people
JM> deploying products have to replicate the repository structure in their
JM> offerings or rename the artifacts to ensure uniqueness.  Neither is much
JM> fun.

>> > I keep coming back to the Java package name analogy.  Java needed a
>> > simple, robust naming scheme for classes.  Since domain names are
>> > universally understood, globally managed and unambiguous they make a 
JM> fine
>> > choice.
>> 
>> Well, if you bring the analogy full circle, you will quickly discover 
JM> that 
>> Maven follows this (now) more than you want to think, and Eclipse less 
JM> than 
>> you argue;
>> Java Package == Maven Group
>> Java Class == Maven Artifact.
>> Java did not say that the Filename of the class must be FQDN, but 
JM> instead 
>> stored hierarchically on the file system according to the package name. 
>> Uhhhhh.... Maybe a quick look at 
JM> http://www.ibiblio.org/maven2/org/apache/ 
>> gives you a hint (the many non hierarchical items in the root are 
JM> unfortunate 
>> legacy)

JM> yes, I confess that this has been confusing me greatly (being a Maven 
JM> newbie).  In the repo you point out there seems to be several different
JM> approaches and conventions.  Even in some of the examples that have been
JM> bandied around here there are things like log4j/log4j/1.1.3.  The 
JM> hierarchical package form you described in your other post is more 
JM> intersting/consistent.   Some clarifying questions then...

JM> Can you express a clear bi-directional mapping of BSN and version onto
JM> groupId, artifactId, version and ultimate JAR name?

JM> Is it true that all '.' in groupIds are converted to '/' (i.e., dirs) in
JM> the Maven repo?

JM> Is this true for '.' in the artifactId?

JM> In any event, the issues of robustness and confusion remain.  For example,
JM> take a look at
JM>         http://www.ibiblio.org/maven2/org/eclipse/equinox/osgi/3.1.1/
JM> You will see that it contains osgi-3.1.1.jar.  This is what we named as
JM> org.eclipse.osgi_3.1.1.jar.  Notice that the groupId does not match the
JM> BSN and the JAR has been renamed.  So there is ambiguity in the groupId
JM> (perhaps the person who did this just did it wrong?).  The JAR itself has
JM> a nice simple name (osgi-3.1.1.jar) but this is hardly unique.  So, now
JM> when you go to ship a product you have to replicate the dir structure or
JM> do other things to avoid collisions.

>> You just choose to require that it has to be on the filename, and 
JM> creating a 
>> non-existing analogy.

JM> Certainly filenames are just one way. 

JM> As for the analogy, perhaps it is poor.  Dunno, it still works for me.
JM> There are a couple differences being glossed over
JM> - people generally speaking do not have to manipulate individual class
JM> files.  They manage whole dirs or whole JARs.  Ideally perhaps one would
JM> not have to manipulate bundle JARs but that is our unit of delivery so its
JM> hard to see that need going away.

JM> - in the package/class structure
JM> <root>/org/apache/felix/Framework.class 
JM> the actual class is org.apache.felix.Framework.  There is a very clear and
JM> simple mapping to the file structure.  This seems to come back to whether
JM> or not there is a simple rule for mapping BSN and version onto the dir
JM> based file structure.

JM> Jeff

-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599