Niclas Hedhman <[EMAIL PROTECTED]> wrote on 09/30/2006 05:15:34 AM: > On Saturday 30 September 2006 08:27, Jeff McAffer wrote: > > - Built bundles have a manifest.mf that fully specifies what the bundle > > can supply and what it needs. If Maven could read the manifest directly, > > you would not need a POM for the bundle when buliding it. This in turn > > would allow people to build against products and other delivered software > > which does not live in an accessible maven repo. > > Huh? Do you think that jakarta-commons people would want to bother about
> package dependencies, instead of their current "jar dependencies" approach. > I don't. It doesn't bring them anything useful at all. At the most, we could I was being very careful to enable people to do as they choose. No where do I say that people must do anything. If jakarta-commons likes jar dependencies, great! Quite a number of people in this list are fond of package dependencies and currently AFIAK, Maven does not support them. I would be very happy to be wrong. > Requiring that projects has to maintain the Manifest down to the last dot, > ain't very likely to happen. Again, there was no must or require in anything I wrote. Some people want to do that. Maven does not enable that workflow thus excludes those people. > > - At development time, some people prefer to specify their dependencies in > > manifests rather than poms. Having Maven read dependency info from the > > manifest would eliminate the need to duplicate that information. > > "Some people" ;o) > Have heard that argument for long now, but it seems to me being more a view > enforced onto "some" by Eclipse ways of doing things. If Eclipse had chosen > another approach X, then the sentence above would have been "some people > prefer X". Of course! And if Maven had choosen another approach... This isn't a mystery or secret plot. There are several communities doing things in different ways. Each way has its benefits and drawbacks. I'm observing that Maven would get higher acceptance in some communities (e.g., Eclipse) if it was better able to support the workflows those communities have developed. Communities, whether it be Jakarta or Eclipse or Felix or ... are slow to change once they have figured out what works for them. > The manifest is not a strong candidate for describing dependencies, and that Err, the manifest is all about describing dependencies and has a very rich vocabulary for doing so. > cited reasons of not using it; > > - Doesn't haven any kind of "scope", such as Test, Develop and Production. Some communities do this a different way. This information clearly does not belong in the manifest either way. > - Makes it harder to generate several outputs from the same codebase > (although Maven requires a similar limitation). Actually we have many projects that compile multiple JARs while constructing one bundle. It is true however that the Eclipse usecases do not drive a requirement to build one project and produce multiple bundles. In any event, this information also does not belong in the manifest. That's why Eclipse has a build.properties file. Its a sucky format etc etc but no one ever proposed putting that info in the manifest. > - Doesn't allow additional build-time meta-info. Yup. That doesn't belong in the manifest either. See the build.properties file. > Manifest specifies "Bundle-ClassPath: abc.jar", but what jar is that and how > is that obtained?? For the 'click-myself-to-death' systems it is up to the > user to manually 'fix' that, typically by committing jar files into CVS/SVN > (a discouraged practice at ASF), and YET Eclipse store information about that > in its own files, which I think proves the suitability of the manifest as a > build co-ordination tool is over-rated, and time for the Eclipse folks to > admit it ;o) We do not commit JARs into CVS! Not sure where you got that idea but it is patently incorrect. In general you don't even need the JARs until you actaully want to ship. 90% of the time Eclipse bundle developers are running directly from the project's binary output folders in the workspace (and that is not even committed). The build-time information (eg., build.properties) describes the mapping between the development time and deployment time shape of things so when you export a bundle, you get the JARs described. Look Jason asked for opinions on what Maven could do to improve the building of bundles. I gave my opinion and tried to represent it only as that. Clearly you work in a completely different way. I can't fathom not using an IDE, you can't fathom using one. That doesn't make one of us right or wrong. Frankly it is hard to understand what all the resistance is about. All that is being suggested is that at the point Maven goes to read the POM, it look for a manifest as well. That way people can put the dependency etc info wherever they are happiest. It would be great for Maven be more useful in a broader set of communities. To do that it either needs to more/less seamlessly support current practice or be remarkably better in ways that the end users/developers involved want thus motivating them to change. That has nothing to do with particular technologies. It is just community dynamics. Jeff
