On Thursday 07 December 2006 12:41, Aaron Siri wrote: > "What Peter's tools has done so far, is to traverse the bytecodes and > locate all the packages that are referenced one way or the other. A task > not fit for humans." > > But with maven you've already done this with the dependency definitions. > It wouldn't have compiled otherwise. Maven will also take care of > dependency dependencies and let you specify packaging intent. The plugin > then needlessly does a lot of bytecode inspection just to figure out what > maven already told you was needed. As a stand-alone tool that is slick, as > a maven plugin it is redundant and confusing.
Well, that is incorrect. Firstly, every compile I have seen on the market includes rt.jar, which contains all kinds of classes that must be imported if referenced one, two or more levels down. Secondly, everything on the market isn't compiled with Maven. Many projects out there has been "mavenized" independently and most of them has poms without dependency information, hence the information is lost. > Why oh why would you even bring up the jar vs. package debate? For better > or worse .jar is the standard "packaging" mechanism and packages have been > regulated to namespace duty. ;) As long as code is delivered via .jars > why don't we keep it in that format? I don't want to second guess why > things are packaged as they are. We are just trying to keep our bundles > neat and organized. :P Well, the "world is wrong" ;o) and the OSGi community has chosen to state that, stick by it and evangelize that "package" keyword is more than a classname prefix (namespace is inapproriate term as well, since the JVM has a concept of class namespace different from this). Now, personally I am not much in favour of "inlining", but there are exceptions. Example; Let's say I use one class in the Jakarta Commons Collection jar. I don't like to have my bundle depend on a "not yet bundlized" commons-collection, and sticking a 558kB into my bundle seems a bit of overkill, especially if it is a very commonly recurring class. I agree that inling should not be default, but it should be supported. I disagree that Maven's model is rich enough to support OSGi modelling, and I doubt that we will ever see a change, partly due to the "WTF do you mean is wrong with the Jar as the versioned artifact to drive the compile and runtime cycles?" attitude that is the first reaction when trying to explain the problem domain to non-OSGiers. Cheers Niclas
