On mercredi 12 janvier 2011 at 17:45, Frank Griffin wrote : > In theory, the packager of such an application could create > supplementary packages for the specific versions of included JARs and > build them first from source. But for something like NetBeans or > Eclipse, that's going to be a lot of work....
I don't know for netbeans (maybe it is the same as eclipse), but eclipse needs anyway all of its dependencies inside his own plugins directory, so it would anyway be hard to use other system installed jars. But the source of the required version could probably be included in the src.rpm of the requiring plugins and built/installed before them (but I actually have no idea how eclipse plugins are built from source). The problem is, many eclipse plugins (or plugins collections actually) have dependencies on the same libs (for example xalan and xerces) which they all provide in their zip archive. We cannot have them in each package that need them as it would create file conflicts between those packages. So we would need to create separate packages for those "external dependencies plugins". They could be built from their own source (from the official project) and then the real plugins would depend on them. That would probably require a special naming convention for dependencies between plugins (as the package doesn't provide "xalan" but "xalan as an eclipse plugin") Or maybe, if the jar in the external dependency plugin is actually the same (or compatible) version as the on from the normal package maybe we could make a plugin package only containing the eclipse related files (plugin.properties) and creating a symlink to the system wide jar. But that mean that eclipse plugins, which are now frequently provided as single jar files, would need to be packaged as files and directories like in older eclipse releases. What do you think? -- Renaud Michel
