Community
Participate
Working Groups
It seems that the version 1.1 p2 repo does not include a number of required dependencies. I'm using linuxtools-1.1.zip from the download site and trying to install into an eclipse platform installation that has had rg.eclipse.cdt.feature.group and org.eclipse.jdt.feature.group installed. The downloads page only mentions CDT as a dependency but I also needed JDT and then all of the following plugins were pulled from the Juno update site as well: net.sourceforge.lpg.lpgjavaruntime_1.1.0.v201004271650.jar org.antlr.runtime_3.2.0.v201101311130.jar org.eclipse.cdt.core.lrparser_5.2.0.201206111645.jar org.eclipse.cdt.core.lrparser.xlc_5.1.0.201206111645.jar org.eclipse.cdt.core.parser.upc_5.1.0.201206111645.jar org.eclipse.cdt.make.xlc.core_5.2.0.201206111645.jar org.eclipse.draw2d_3.8.0.201206112118.jar org.eclipse.dstore.core_3.3.100.201205300905.jar org.eclipse.dstore.extra_2.1.400.201205300905.jar org.eclipse.ptp.rdt.core_4.1.0.201206130201.jar org.eclipse.ptp.remote.core_6.0.0.201206130201.jar org.eclipse.ptp.remote.ui_6.0.0.201206130201.jar org.eclipse.ptp.services.core_2.1.0.201206130201.jar org.eclipse.rse_3.4.0.201205300905.jar org.eclipse.rse.core_3.3.0.201205300905.jar org.eclipse.rse.processes.ui_3.0.400.201205300905.jar org.eclipse.rse.services_3.2.200.201205300905.jar org.eclipse.rse.services.dstore_3.2.0.201205300905.jar org.eclipse.rse.subsystems.files.core_3.3.0.201205300905.jar org.eclipse.rse.subsystems.processes.core_3.1.300.201205300905.jar org.eclipse.rse.subsystems.shells.core_3.1.300.201205300905.jar org.eclipse.rse.subsystems.terminals.core_1.0.300.201205300905.jar org.eclipse.rse.ui_3.3.0.201205300905.jar org.eclipse.tcf_1.0.0.201206051725.jar org.eclipse.tcf.core_1.0.0.201206051725.jar org.eclipse.tcf.rse_1.0.0.201206051725.jar org.eclipse.zest.core_1.3.0.201206112118.jar org.eclipse.zest.layouts_1.1.0.201206112118.jar I'm using Juno on RHEL 5.5 Thanks.
Well, what will be installed depends on what you select. If you select the whole Linux Tools a number of things will be downloaded. We do not aim on including other projects bundles in our repo if they are available from the main release repository. Can I assume that the bug is about not having all dependencies listed on the downloads page?
I'm not sure what you mean. I guess there are two ways to look at the problem. One is that the documentation is unclear. The downloads page says: "Specific tools require their underlying native tools (ex. Valgrind, OProfile, SystemTap, LTTng, Perf). Other dependencies of some tools include CDT. Installations via the p2 repository will automatically get these dependencies." To me this means, that I should need nothing other the Eclipse Platform and CDT in order to install the plugin successfully. That's not true though. I needed JDT and a number of other plugins as well (even though they were from the main release repository). I ran into this though because I was building an eclipse-linuxtools package for RHEL 5.5 and wanted to do so automatically using only pre-downloaded tarballs. In other words, I was trying to do so without using connecting to online repositories. I ended up just including the rpm, gcov, man, and valgrind feature groups to avoid having to include other dependencies not included with the linux tools p2 repo. I suggest at least clarifying the documentation. Ideally, dependencies would either be included with the linux tools p2 repo or be available via other small self contained p2 repos. I don't think you should have to be connected to the release repo in order to complete an install, but that's just my opinion. Thanks.
Jeff, please take care of this one.
(In reply to comment #2) > I'm not sure what you mean. I guess there are two ways to look at the > problem. One is that the documentation is unclear. The downloads page says: > > "Specific tools require their underlying native tools (ex. Valgrind, > OProfile, SystemTap, LTTng, Perf). > Other dependencies of some tools include CDT. > Installations via the p2 repository will automatically get these > dependencies." > > To me this means, that I should need nothing other the Eclipse Platform and > CDT in order to install the plugin successfully. That's not true though. I > needed JDT and a number of other plugins as well (even though they were from > the main release repository). > > I ran into this though because I was building an eclipse-linuxtools package > for RHEL 5.5 and wanted to do so automatically using only pre-downloaded > tarballs. In other words, I was trying to do so without using connecting to > online repositories. > > I ended up just including the rpm, gcov, man, and valgrind feature groups to > avoid having to include other dependencies not included with the linux tools > p2 repo. > > I suggest at least clarifying the documentation. Ideally, dependencies > would either be included with the linux tools p2 repo or be available via > other small self contained p2 repos. I don't think you should have to be > connected to the release repo in order to complete an install, but that's > just my opinion. > > Thanks. Daniel, there are two forms of installation. You either use the Fedora/RHEL model or you use the Eclipse update installer. The Fedora/RHEL packages all have their Requires set up so that if you yum install, you will get all the various sub-dependencies installed for you. In the case of the Eclipse install/update, it is assumed that you will access the needed Eclipse repo(s). In all cases, you should start with the composite Eclipse repo which has been at least tested. Each feature installed should add an update site to the list of update sites and then you can then receive updates from them, as prescribed by each upstream project. The Linux Tools repos are used to seed the Eclipse release train aggregation. As such, they will never contain dependencies; only those components contributed by the Linux Tools project. It is not reasonable to expect Linux Tools to provide these dependencies for you in its repo. Other projects participating in the aggregation do not do this. What gets dragged in, depends on you what you choose to install. The PTP packages for example are brought in by the remote profiling tool plug-ins. The Eclipse update/installer will tell you everything that is needed to install and you can certainly stop, back up, and remove various features you have no need of to see if that drags in less packages. We can certainly add some additional content to the comment about which projects we draw directly from, but to expect a full dependency list is not reasonable.
Thanks for the reply Jeff. I think not including additional dependencies is fine, but I do think all direct dependencies should be documented. Ideally, I think the comments or the installation directions should say exactly what you need to download in addition the the vanilla Eclipse Platform to get a working install. I think someone should be able to go to the site, read what's needed, download it all, and then be able to install without having to connect to any online repositories. I realize that your average user will do online installs and updates, but I don't think that should be a requirement. Right now, it's possible to do an offline install/update, but I would have to develop the instructions myself based on testing with an online install or via inspecting the packages to find all the required dependencies. I see no reason why it those couldn't and shouldn't be documented. Why do you say having a full dependency list is unreasonable? I'm not an eclipse guru, but I think it's pretty standard in most of the open source world for projects to list their dependencies as part of their documentation.
(In reply to comment #5) > Thanks for the reply Jeff. > > I think not including additional dependencies is fine, but I do think all > direct dependencies should be documented. Ideally, I think the comments or > the installation directions should say exactly what you need to download in > addition the the vanilla Eclipse Platform to get a working install. I think > someone should be able to go to the site, read what's needed, download it > all, and then be able to install without having to connect to any online > repositories. I realize that your average user will do online installs and > updates, but I don't think that should be a requirement. Right now, it's > possible to do an offline install/update, but I would have to develop the > instructions myself based on testing with an online install or via > inspecting the packages to find all the required dependencies. I see no > reason why it those couldn't and shouldn't be documented. > I think we agree. I do not think that listing all the feature and plug-in versions that are required is reasonable. No other project does this. Listing the direct required projects and the release numbers is certainly reasonable and other projects in fact do this (e.g. PTP) FWIW, the repo you have downloaded was built against the aggregate repository. Theoretically, our true dependency is the Eclipse Juno repo used for the build and testing. From the top-level pom.xml: <platform-version-name>juno</platform-version-name> <eclipse-site>http://download.eclipse.org/releases/${platform-version-name}</eclipse-site> <swtbot-site>http://download.eclipse.org/technology/swtbot/snapshots</swtbot-site> <orbit-site>http://download.eclipse.org/tools/orbit/downloads/drops/R20130118183705/repository</orbit-site> > Why do you say having a full dependency list is unreasonable? I'm not an > eclipse guru, but I think it's pretty standard in most of the open source > world for projects to list their dependencies as part of their documentation. I was referring to specifying every dependency including those of other projects or listing individual features and plugins required. I will update the downloads page for the latest 1.2.1 release.
> > I will update the downloads page for the latest 1.2.1 release. Downloads page has been updated for latest 1.2.1 release. CDT supplies cdt and lpgjavaruntime jars. GEF supplies zest and draw2d. PTP supplies remote support. RSE supplise rse jars. TCF supplied the tcf jars. Orbit supplies antlr
> Downloads page has been updated for latest 1.2.1 release. Just took a look and that's perfect. Exactly, what I was hoping for. Thanks!
