Community
Participate
Working Groups
The Acceleo features shouldn't "include" their dependencies (guava, kohsuke, antlr). Including the dependencies within the Acceleo features mean that we end up with an exact required version when building the features instead of the range that we really depend on. acceleo depends on guava [15,22) but since the feature includes guava, we end up building a feature that will include guava 21 since that is what's currently available when we build: <plugin id="com.google.guava" download-size="2612" install-size="5867" version="21.0.0.v20170206-1425" unpack="false"/> The dependencies should be present in the update site so as not to force users to add orbit as an available update site when installing, but we shouldn't force an exact version from the features.
New Gerrit change created: https://git.eclipse.org/r/130386
Gerrit change https://git.eclipse.org/r/130386 was merged to [master]. Commit: http://git.eclipse.org/c/acceleo/org.eclipse.acceleo.git/commit/?id=58045d28b184f93223e324547fd44aae71947d08
You are right that dependencies are dependencies and should not be included in the acceleo features. No doubt. But the current solution triggered an issue. I don't open new bug because I'd like to discuss it first. Now installing the acceleo we end up with the com.google.guava plugin. The plugin doesn't belong to any feature. Maybe it is a bug in the equinox, but the root user, or more generally - the installer, run elipse with the central configuration and uses equinox.simpleconfiguration strategy with the build.info file where guava plugin is listed. Other users use their own local configuration without this file by default. They use the platform.xml strategy or scanning the pool directories. Both strategies ignore bundles without their features and guava is unavailable for them. Maybe the solution is to make com.google.guava.feature not only the plugin? btw: the official update site contains 3.7.7 as the newest one while eclipse update site - 3.7.8 btw2: ocl seems not being on the dependency list
Hello Tomasz, I'm not entirely sure what your issue is? Acceleo depends on Guava, so we're still packaging guava in our update site so that it is available for users installing Acceleo. We're just not forcing a specific version. Installing Acceleo through p2 will work since guava is available. If the installer somehow ignores it, then it would be a bug of the installer as far as I see it?
Hi Laurent, I mean not installer but rather Target Platform recognizer issue. When I return home where I have debugged it I will put the responsible classes and methods names. The legacy(?) simpleconfiguration strategy finds the plugin correctly but the newer ones ignore it because the com.google.guava (and not only it) is not a part of any feature. The man who installed the eclipse (the most of users) use the simple strategy but in shared environment users different from the installer don't by default. I'm not sure whether the plugin should be enveloped in feature. If yes, somebody should make such package (maybe Obeo, maybe Google, maybe ...) - the issue at our side. If not, the equinox shouldn't ignore unfeatured (unmanaged) plugins - the issue at their side. I don't know which answer is correct.
