Community
Participate
Working Groups
For an RCP app, we need the ability to specify the links directory away from the RCP directory. We have a need to have several apps share the RCP implementation without sharing the apps themselves. Thus we want to start the RCP and point it to an application specific config and workspace as well as an application specific links area.
See also: bug 35037, bug 46226, bug 68526, bug 79363.
Need a bit more info here. First are you using update.configurator? this is the only way the links dir will do anything for you. Second, do you really care about what plugins are *deployed* or just which are *installed*? The point here is that the configuration is the guy who defines what plugins are presented (installed) to the runtime for execution. You can have 1000s of plugins in linked dirs and otherwise but have a configuration that only lists 3 and you will only get those 3. There may be some minor performance impacts during certain install operations but in general the runtime only cares about the plugins that it has been told about. Using this model you and all your friends can make as many extensions (links dir entries) as you want but each "product" comes with a configuration that identifies the list of features/plugins to use (via the platform.xml file). Then you run eclipse -configuration <my configuration> and only those plugins in <my configuration>/org.eclipse.update/platform.xml are run. If you update this configuration, only that configuration is affected. Does this work for you?
I have gotten this to work by specifying all the plugins in config.ini using osgi.bundles. This is not what I want to be doing. I do have the update.configurator plugin as that seemed the only way to get anything to work. I had thought that the solution was to keep the platform.xml from a working version but, when I deleted the links directory from the eclipse RCP install dir, platform.xml was replaced (put into the history) with one that did not have the linked directories. What I want is to have multiple apps installed on a machine using the same RCP installation but with no intermingling of plugins between any of the apps.
We like using update.configurator because it allows for pieces to be added easily (later installs, user plugins, 3rd party plugins, etc.). I think what Jim is asking for is the following. Assume there's an Eclipse install on the machine (could be a bare RCP + the configurator or it could be a full SDK). Call that the Base. We don't want to modify the Base. We might not even be able to because of permissions or policy. Later we want to install a rich client program, call it P1. This will go in a directory completely seperate from the Base. It will include only plugins and features unique to P1, and not any of the RCP plugins like osgi or core.runtime. P1 is the first in a long line of rich client programs so we don't want to duplicate any common stuff. P1 has a links directory with Base.link which points back to the Base. First attempt: We copy startup.jar into P1 and create a batch file (or use the native launcher) to run the Main class. The startup code figures the Install Dir is P1, and fails to find osgi and the configurator in P1/plugins (apparently this is before the code that knows about the links directory) and aborts with "Could not find framework". Second attempt: We try creating a batch file in P1 that runs java with a classpath pointing to Base/startup.jar. The startup code figures the Install Dir is the Base, gets osgi and configurator and other plugins out of Base/plugins ok, but has no way to relate back to the P1 directory. It looks in Base/links, which doesn't exist, so it aborts with "Application P1.application could not be found in the registry". If there was a way to provide some kind of "links path" instead of a single links directory then we could tell it to look in P1 and P1/links to compute the closure of all the plugins needed to run P1 (and possibly extensions to P1). Another possible implementation is move knowlege of the links directory very early into the launcher so that even the framework could be acquired from there. There may be other ways to address it that you could think of. Looking ahead a little, when P2 comes out, we want to support running P1 only, running P2 only, or running a product suite that combines P1 and P2. Without changing P1 or the Base. And so forth. It's almost like "product fragments" but backards from the normal way you think of fragments working. See also bug 53338 comment #3 for a different perspective.
It seems the only point of contention here is that you don't want to update the eclipse/links directory. Not sure why not. This is completely expected. By doing this you will have one base that "knows" about all the plugins in P1, P2, ... (the extensions). This does NOT mean that when you run Eclipse all those plugins will be installed into the running eclipse. That is the job of the configuration. You can have any number of configurations you want. The configurations's job is to carve up the pool of plugins to form a consistent set to run. These (and only these) are installed into OSGi/runtime and thus run. Concrete example. - install base as you described - install P1 in a completetly separate location. P1 should include: - all the plugins/features you care to put there - a configuration (complete with platform.xml) that identifies the features/plugins from P1, base and whatever else you need) - an eclipse launcher (use the new one with the .ini file) or a bat file that runs eclipse -configuration <p1>/configurations -cp <base>/startup.jar - add P1.link to base/links User then runs the launcher/bat in P1 and gets P1 function. Repeat for P2 etc. Seems like you tried this but had problems? Did you do exactly what is described?
When I tried this I did not have the links directory under eclipse. The platform.xml specified the different extension directories but was over- written when eclipse started. Is there maybe some documentation on the format of platform.xml that I am missing? Also, the senario that you are describing seems to presume that you would never use the update configurator, is that true? Am I to fully specify osgi.bundles? I do not neccessarily want app1 to know about the plugins available in app2.
Caveat: There may be a bug that you are encountering that is scuppering the use I am describing. What I am saying "should" work. i've not had time to confirm. Adding Dorian to the party to make sure I'm not blowing smoke. Acutally, the scenario presumes that you ARE using update.configurator. It is the guy that reads the platform.xml. As you have seen, you don't really want to be messing with the osgi.bundles list. Not fun. If you use osgi.bundles then you are, in effect, not using the configurator (the configurator may go and find some plugins to install but the would find that they rae already installed cause they were on the osgi.bundles list). As for app1 and app2 knowing about each other, again, my point is that app1 == configuration 1, app2 == configuration 2. Having 5000 plugins in the same shared plugins dir does not mean that you know about all of them. You only get to see the ones you are told about in your configuration.
Where are the docs for platform.xml?
When I looked at platform.xml it showed the static locations of the contents of the links directory. So, why do I even need the links directory if I have platform.xml? Mind you, I would rather not have to code platform.xml at all. That seems the job of the update configurator. If I could tell the configurator where to look for the links directory then none of this would be an issue. By the way, why isn't the update configurator part of the RCP installation?
the links dir is the mechanism for locating plugins not for choosing which plugins to run. The platform.xml is the mechanism for choosing which plugins to run. My sense here is that your are fighting the design. You might not need the links dirs. Perhaps they are only used by update.configurator when it needs to do a full reconcilation? Dorian? Don't know where the doc for the file is. Dorian should be able to help there. There is alot of discussion about update.configurator and its in/exclusion in/from the RCP. Summary is that features etc are update notions and update is not a base part of RCP. The current (config.ini) story is not happy and we are looking at the options.
My experience has shown that the platform.xml does not seem to work to boot up the application. The update conigurator seems to be required. That is, unless I am not using the correct features of platform.xml. I am using a platform.xml that was created by the update configurator.
With the hope I don't confuse you more, let me add a couple of comments about platform.xml: Platform.xml is currently an internal format, but I plan to document it anyway (bug 74637). The file is generated by the update.configurator on a first run, or upon a configuration change (new installs, updates, feature disabling, and so on). Normally, the file is under the complete control of the update.configurator: one can change it programmatically using the IPlatformConfiguration interface, but it is best left up to the update configurator to manipulate it as it needs. *Important*. If you manually edit it, then make sure that the "date" attribute in the root element <config> is not there. I won't go into the technical details about how configurator handles timestamps and all that, but just edit the file and don't write a date attribute in the <config>. The update configurator will regenerate the file with the appropriate timestamp, without touching the rest of the file. Links is the pre 3.0 way to handle multiple installation folders, and because platform.xml is not API, it is still supported. Changes in links will be reflected in platform.xml. If platform.xml ever becomes an API, than links could be deprecated.
These kinds of caveats are the very reason why it would be much more friendly for enterprise deployments of the sort we are trying to accomplish if Jim's original request could be accommodated. When you start talking about "internal format" and such, it makes me very concerned about our ability to automate the process of creating the right plugin.xml content for each of our deployed applications and have it hold up over time. In addition, it is much more clean for us and our customers if the application level plug-ins can be partitioned rather than all dumped into one directory. This kind of separation of the various installed applications is what they will expect. There will not necessarily be any relationship with the various installed applications. Some feature sets may run together as part of a given suite of applications, others will be totally unrelated applications. As Ed noted in an earlier comment, our desire is to create something like an RCP "framework install" such that we can lay down various versions of the RCP on a machine and then *separately* install various applications to run on top of it. So, the reason that we are pushing against your design is not to be difficult with you, but to satisfy the kind of enterprise customer deployment requirements that we need to satisfy. As such, I would really like have you consider this request from our perspective rather than trying to shoehorn our requirements into a workaround using the current behavior that you have implemented. That said, I would suggest a two phased approach. In phase one, your help in getting us up and running using platform.xml has been and will continue to be greatly appreciated. In phase two, let's discuss how we can satisfy enterprise deployment requirements. This is something that the add-in provider community requested for the development roadmap as a high priority item and it has been accepted per the recent draft that I have seen. We don't need a fix immediately, but we need to know the path forwards.
This really meshes well with some of the comments in bug 53338. If the links directory did not have to be under eclipse then you get what Ed was talking about in that bug. Also you reduce "dll hell" which is basicly what you have with this current implementation. I do not like the idea of being told to use internal, undocumented, methods to achieve our goals.
Just to clarify the "internal" aspect of platform.xml: Its syntax is currently internal, but if the solution to the problems described here or elsewhere requires it to be public, then it can be polished and made API. Also, using the API's in the org.eclipse.update.configurator package you can create, set the content and save the configuration (platform.xml), without you having to know the exact syntax. I know of a group who's taken this approach and things work ok for them (but they had to do some work to get it going).
Is the intent that the links directory go away? If so, what is the intended way to do the same thing in the future? If the links directory is not intended to go away then moving its location seems fairly simple. It appears to be accessed in only one place and it appears to be hardcoded. That can be changed to be a property access instead and the property can be initialized to the current value. Then all we would have to do is set the property in config.ini.
I just tested using platform.xml to define things. I don't think it works the way you are stating. First I could not use it without the links directory, which seems to support what you are saying but doesn't make that much sense to me. If I have already specified the locations of the linked in extensions, why replace what I have. I would guess that it is simply responding to the fact that the links had changed so it is removing those links I had specified. To test that theory I put the links directory back and had the correct platform.xml. Things ran fine. I then added a new entry to the links directory which would simulate installing another RCP app. I re-ran the app and then looked at platform.xml. It contained the new entry. This is not what was implied in comment #5. So, unless I am missing something, there is NO way to have app 1 that only knows which bundles are installed for it vs app2 which could have a totally separate set without using osgi.bundles. Maybe I am missing the point of comment #5.
We are in agreement on the problem and that it is interesting but the differ on the solution. For us the links dir has a very specific and narrow purpose (as outlined) and it appears that in your usecase, you do not the function for which links was designed. So lets set that aside and look at the mechanism that is designed to address this usecase. What you really want is to manage the platform.xml. This is what defines the configuration that you run. For example, try the following - delete all links directories you can possibly find - install a base Eclipse (whatever that is for you) in c:\base - install Product 1 someplace separate in c:\product1 - create c:\product1\eclipes\configuration\org.eclipse.update and add the follwoing platform.xml <?xml version="1.0" encoding="UTF-8"?> <config transient="false" version="3.0"> <site enabled="true" policy="USER-EXCLUDE" updateable="true" url="platform:/base/"> <feature application="org.eclipse.ui.ide.workbench" id="org.eclipse.platform" primary="true" url="features/org.eclipse.platform_3.1.0/" version="3.1.0"> <root>platform:/base/plugins/org.eclipse.platform_3.1.0/</root> </feature> <feature id="org.eclipse.jdt" url="features/org.eclipse.jdt_3.1.0/" version="3.1.0"> </feature> <feature id="org.eclipse.pde" url="features/org.eclipse.pde_3.1.0/" version="3.1.0"> </feature> </site> <site enabled="true" policy="USER-EXCLUDE" updateable="true" url="file:/c:/product1/eclipse/"> <feature id="your id here" url="features/your feature location here/" version="your version here"> </feature> </site> </config> - note that I took a guess at what would be in your base so you may have to update the feature list there. - also add the relevant features in the site for product 1. - now run eclipse -configration c:\product1\eclipse\configuration This should just work. You can install product 2 in the same way and the two will be isolated. You could even then simply create a platform.xml thta listed sites for the base, product1 and product2 and get a "suite". You can ship the structure (including platform.xml) I just defined on the CD and the only install time work would be to update the url for the site (i.e., change c:\product1 to be the right value). Alternatively you could use the update API to craft the platform.xml at install time (this requires an initialization run of the installed product. something like eclipse -initialize -configuration c:\product1\eclipse\configuration If you want to have direct control over the platform.xml and are sensitive to the current non-API ness of platform.xml then we should convert this bug into a "please make platform.xml API" bug.
This works. There is no links directory. I have a feature for my app and a feature for any shared plugins. So the solutions appears to be that we need to 1) document platform.xml 2) Provide a wizard for editting platform.xml. I would suggest that there be a product wizard much like there is a feature wizard. This wizard collects other features together in the platform.xml. Question: Originally I was not using a feature for the app nor for the shared plugins. The update configurator managed it for me. With this solution, is the feature now required? Should we be encouraging the use of features more in the other case?
Glad this works for you. As for the wizard etc, what I will suggest is that rather than going this path, we should investigate doing it through the existing Update API. In a shared install scenario you should likely initialize the configuration anyway. So at install time you would run eclipse -configuration p1 -application <some update application> that causes Update to add p1 to the current configuration as a site. In effect you are adding yourself to yourself. My understanding from Dorian is that this capability exists now and is reasonably straightforward. Perhaps Dorian can point us at a simple example? I am all for making platform.xml API and providing editing capabilities. See bug 46226. Not sure that this is absolutely necessary for this usecase however as you may actually be better off with the solution outlined above (running something on install).
For comment #19: you don't have to use features. They will be very useful, though, if you plan to update or provide patches later. Using update.core you can programmatically, or from the command line, perform install/update/etc. operations. As for Jeff's comment #20: The command to add a site to the configuration is part of the update headless support, but it needs the org.eclipse.update.core plugin. The syntax is described at: http://help.eclipse.org/help30/index.jsp? topic=/org.eclipse.platform.doc.isv/reference/misc/update_standalone.html in particular: java -cp c:/base/eclipse/startup.jar org.eclipse.core.launcher.Main -application org.eclipse.update.core.standaloneUpdate -command addSite -from d:/p1 -configuration d:/p1/configuration If you don't install that plugin, then you need to create a platform.xml that lists the two sites (the base and the p1 site), even empty, and let the update configurator fill in the rest. platform.xml as API: documenting the current behavior is fine, but making it API would require some more work, so update does not get locked in the current format. On the other hand, because it can be editted via API's, perhaps PDE can provide the editor, without exposing the actual xml syntax.
There's still a problem with this approach. I want to have a native launcher p1.exe with its own icon in the d:\p1 directory. If I simply copy eclipse.exe then it complains that: "The P1 executable launcher was unable to locate its companion startup.jar file (in the same directory as the executable)." If I copy startup.jar too then it complains that: "An error has occurred. See the log file..." and the log file says: java.lang.RuntimeException: Could not find framework at org.eclipse.core.launcher.Main.getBootPath(Main.java:401) at org.eclipse.core.launcher.Main.basicRun(Main.java:174) at org.eclipse.core.launcher.Main.run(Main.java:710) at org.eclipse.core.launcher.Main.main(Main.java:694) Any suggestions? I tried setting the shared_ur attribute in platform.xml, variants of this: <config date="1105998242796" transient="false" version="3.0" shared_ur="file:/d:/base/eclipse"> but as I expected it had no effect. Maybe eclipse needs an -installDir option to tell it where to find startup.jar and the framework instead of assuming the directory containing the native launcher or its parents?
The -install option or the osgi.install.area property allow you to set that. See: http://help.eclipse.org/help30/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html
org.eclipse.platform.Main parses the -install option which sort of does what I want, though I still have to have a local copy of startup.jar because the native launcher doesn't respect that.
Oops, you are right, I misunderstood your question. -vmargs -jar <your-path>/startup.jar, then?
No effect. eclipse.c looks explicitly for the startup.jar file in the same directory as eclipse.exe or in parent directories as a mark of a correct install directory. I guess I could make a dummy startup.jar and put the real one on the classpath but this is getting kludgy.
The problem with startup.jar is captured in bug #81969.
so can this bug be closed now?
Yes, we can close this.
