I think the manifest is a good resource to specify the dependencies a -concrete- artifact has on the world. The advantage is that it is very well specified, it is supported by many implementations, and it supports finer grained dependencies than the coarse require jar approach (which looking at the 1500 files in my m2 repo from just developing a simple independent plugin seems not scaleable in the long run).
However: 1. The manifest is not a development format. During development you should be able to create variations (test, source, debug, deploy, java class file versions, etc) as well as multiple jars. You should also be able to parametrize aspects. Redundant information is evil! 2. The manifest uses a syntax that is developed over time. I think we need a more generalized dependency and constraint language that can cover all our dependency requirements (screen size, memory, processor, vm version, etc). I think OBR2/RFC 112 is a long way in that direction but it requires more work, for example, the uses: directive can currently not be modelled in it. Richard has used this model for his resolver however. 3. The manifest system has little support for readability (especially after it is formatted). This is not a problem for computers, it stinks for users. On the plus side, it is not nearly as hard to read as XML! :-) 4. A file like the POM is clearly better suited to be used as central development descriptor. Unfortunately the Maven people made some choices implementing Maven that have all kinds of nasty, including architectural, consequences (a single target jar is one, but there are many more). To conclude. The best situation would be if both Maven and Eclipse could agree on a project descriptor that would handle real life dependencies (packages, deployment requirements like screen size, memory), would not contain redundancies, and would actually be readable by mere humans. Anyway, realistically, I think the best approach currently is to get maven to generate the manifest with as many OSGi headers as possible. I have written a new plugin that is based on the bnd jar (see http://www.aqute.biz/php/tools/bnd.php). This plugin allows the generation of all OSGi headers, verifies all OSGi headers, and it can handle versioning, etc. However, this plugin works quite differently from the normal packaging. It does not blindly put the bin directory in the jar, it uses the classpath to create the JAR. You specify (with wildcards) which packages should be placed in your JAR (you can also copy files, including preprocessing, if you want). Richard is currently testing this. Unfortunately, plugins are pretty intrusive in your POM so people prefer an approach where the OSGi headers are created by default. I am therefore working with Jason to get the core lib of that tool into standard maven. If Jason accepts this, then all JARs generated by maven would contain default OSGi headers for free (importing anything from any contained package, exporting all contained packages, bundle symbolic name from group + artifact id, description, etc). This would make any maven artifact a bundle, which would be very good for evangelizing OSGi. Kind regards, Peter Kriens JM> It would be interesting to have Maven natively understand OSGi metadata. JM> This is interesting in two places/ways: JM> - Built bundles have a manifest.mf that fully specifies what the bundle JM> can supply and what it needs. If Maven could read the manifest directly, JM> you would not need a POM for the bundle when buliding it. This in turn JM> would allow people to build against products and other delivered software JM> which does not live in an accessible maven repo. JM> - At development time, some people prefer to specify their dependencies in JM> manifests rather than poms. Having Maven read dependency info from the JM> manifest would eliminate the need to duplicate that information. JM> Jeff JM> Jason van Zyl <[EMAIL PROTECTED]> JM> 09/28/2006 01:41 PM JM> Please respond to JM> felix-dev@incubator.apache.org JM> To JM> felix-dev@incubator.apache.org JM> cc JM> Subject JM> Creating OSGi bundles with the Maven JAR Plugin JM> I'm thinking about ApacheCon again so I remember that at the last JM> ApacheCon we talked about modifying the JAR plugin to create OSGi JM> bundles for you guys automatically. I'm hoping that I can try and JM> demo something for ApacheCon (not for any preso, but just to show it JM> can work) so I'm wondering where this ended up. I'm now subscribed to JM> the list so maybe I dropped the ball. JM> Thanks, JM> Jason. -- Peter Kriens Tel +33467542167 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599
