Niclas Hedhman <[EMAIL PROTECTED]> 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 systems. > Eclipse meaning the entire thing, that I personally am not very fond of as a > development tool, although I think Eclipse as an RCP for my own applications > make total sense.
We've had this discussion before. No one in this discussion is proposing that Eclipse the IDE has to be used for anything. We are talking about 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, ...) then > > you may end up shipping several different layouts. > > The general approach is in Maven camps the opposite. Any needed artifact gets > published to a repository. Last time I checked 13000 something Jars was > available in Mavens central repository, then plus many projects having their > own to fill some remaining gaps. There can't be many Java OSS projects that > is not present... > > There is indeed a huge investment in standardizing this issue, and Eclipse is > the significant exception, rather than the rule, at least from my angle of > view. In this part of the discussion I am focused on shipping products/offerings/... I am not aware of any products that, upon installation to the user's machine, go and fetch JARs from a Maven repo. Local or remote. The issue is that if JARs are named for the convenience of the development time repo and these names are not unique, then people deploying products have to replicate the repository structure in their offerings or rename the artifacts to ensure uniqueness. Neither is much 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 fine > > choice. > > Well, if you bring the analogy full circle, you will quickly discover that > Maven follows this (now) more than you want to think, and Eclipse less 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 instead > stored hierarchically on the file system according to the package name. > Uhhhhh.... Maybe a quick look at http://www.ibiblio.org/maven2/org/apache/ > gives you a hint (the many non hierarchical items in the root are unfortunate > legacy) yes, I confess that this has been confusing me greatly (being a Maven newbie). In the repo you point out there seems to be several different approaches and conventions. Even in some of the examples that have been bandied around here there are things like log4j/log4j/1.1.3. The hierarchical package form you described in your other post is more intersting/consistent. Some clarifying questions then... Can you express a clear bi-directional mapping of BSN and version onto groupId, artifactId, version and ultimate JAR name? Is it true that all '.' in groupIds are converted to '/' (i.e., dirs) in the Maven repo? Is this true for '.' in the artifactId? In any event, the issues of robustness and confusion remain. For example, take a look at http://www.ibiblio.org/maven2/org/eclipse/equinox/osgi/3.1.1/ You will see that it contains osgi-3.1.1.jar. This is what we named as org.eclipse.osgi_3.1.1.jar. Notice that the groupId does not match the BSN and the JAR has been renamed. So there is ambiguity in the groupId (perhaps the person who did this just did it wrong?). The JAR itself has a nice simple name (osgi-3.1.1.jar) but this is hardly unique. So, now when you go to ship a product you have to replicate the dir structure or do other things to avoid collisions. > You just choose to require that it has to be on the filename, and creating a > non-existing analogy. Certainly filenames are just one way. As for the analogy, perhaps it is poor. Dunno, it still works for me. There are a couple differences being glossed over - people generally speaking do not have to manipulate individual class files. They manage whole dirs or whole JARs. Ideally perhaps one would not have to manipulate bundle JARs but that is our unit of delivery so its hard to see that need going away. - in the package/class structure <root>/org/apache/felix/Framework.class the actual class is org.apache.felix.Framework. There is a very clear and simple mapping to the file structure. This seems to come back to whether or not there is a simple rule for mapping BSN and version onto the dir based file structure. Jeff
