Community
Participate
Working Groups
Build ID: 3.5 M5 Steps To Reproduce: The --iu argument only supports a single IU More information: My use case is needing to update a 3.4.1 installation based on org.eclipse.sdk.ide and org.eclipse.sdk.feature.group. The interdependences are such that I can't update one and then the other, I need to update both in the same operation.
We are unlikely to have time to work on that shortly. If you wanted to provide a patch that would be the best. The code leaves in the org.eclipse.equinox.p2.director.app bundle.
The challenge I see with this is not technical, but rather a usage challenge. Currently we specify the director args as -installIU <someIU> and -version <some.version.number>. The question is, how do we specify this for multiple IU / Version pairs. we could change (or add a new argument) -install <someIU>_<some.version.number>, <someOtherIU>_<1.2.3> Otherwise we will be faced with specifying two lists of things, with the expectation that they line up. thoughts?
(In reply to comment #2) > The challenge I see with this is not technical, but rather a usage challenge. > Currently we specify the director args as -installIU <someIU> and -version > <some.version.number>. The question is, how do we specify this for multiple IU > / Version pairs. > I think a new -install parameter makes sense (optionally deprecate the -installIU and -version fields). The use of an underscore character as a version delimiter may be a little confusing, since versions often employ the underscore in their strings. The comma character is the separator for URI lists, does that make sense here too? Install a single IU: -install <some.IU.1> Install a single IU with a version: -install <some.IU.1>,<version.x.y_1> Install a multiple IUs without specific versions (last comma optional): -install <some.IU.1>,,<someIU.2>, Install a multiple IUs with specific versions: -install <some.IU.1>,<version.x.y.1>,<some.IU.2>,<version.x.y.2> Install a multiple IUs with optional specific versions: -install <some.IU.1>,,<some.IU.2>,<version.x.y.2> The current -install and - version fields would feed into the first two usages above. Ian and I briefly discussed this feature request off list. I'd be happy to supply a patch once we agree on the usage format.
(In reply to comment #3) > I think a new -install parameter makes sense (optionally deprecate the > -installIU and -version fields). > > The use of an underscore character as a version delimiter may be a little > confusing, since versions often employ the underscore in their strings. The > comma character is the separator for URI lists, does that make sense here too? The problem with comma is that you will have to use the double comma if you don't want to specify a version. This looks a little awkward -install foo,, bar,, Does anybody know if '_' can be used in a bundle name? If not, then we can parse up to '_' and from there to the comma (or next blank) we treat as the version. If there is no '_', then we don't have a version. foo_4_1_3.2 would be tokenized as foo(4_1_3.2)
What about driving this by a properties file or something like that?
(In reply to comment #5) > What about driving this by a properties file or something like that? I think the common use case is to drive the director app from a script (it is a lot of typing from the command line), so I'd like to be able to generate an all-inclusive command line without indirecting through a file. That said, would it make sense to log a new request to support importing an installer properties file?
(In reply to comment #4) > Does anybody know if '_' can be used in a bundle name? If not, then we can > parse up to '_' and from there to the comma (or next blank) we treat as the > version. If there is no '_', then we don't have a version. > > foo_4_1_3.2 would be tokenized as foo(4_1_3.2) > Yes '_' is valued in a bundle name. Most commonly seen as something like: org.eclipse.equinox.launcher.win32.win32.x86_64. '-' is also allowed.
(In reply to comment #7) > Yes '_' is valued in a bundle name. Most commonly seen as something like: > org.eclipse.equinox.launcher.win32.win32.x86_64. '-' is also allowed. I was just talking to Ian. How would square brackets work? -install some.IU.1[version.1],some.IU.2,some.IU.3[version.3] (I have yet to find the definition of valid osgi bundle names anywhere.)
square bracket should work. The grammar is accessible in the osgi spec but you have to sign up to get it.
(In reply to comment #8) > (In reply to comment #7) > > Yes '_' is valued in a bundle name. Most commonly seen as something like: > > org.eclipse.equinox.launcher.win32.win32.x86_64. '-' is also allowed. > > I was just talking to Ian. How would square brackets work? > > -install some.IU.1[version.1],some.IU.2,some.IU.3[version.3] > > (I have yet to find the definition of valid osgi bundle names anywhere.) > A version specification can contain brackets if it is a non OSGi version (i.e. a full OmniVersion instance in string form), so would need to be parsed to find the matching end bracket. And, I am wondering if it ever will be meaningful to ask for a range (where brackets also are used). So, the issue here is to find a) a character that delimits the IU name from the version, and b) a character that stops version parsing. My suggestion is to use "=" and "," (but I have not checked if "=" is a valid char in the IU name). A picked "," as delimiter as it is not allowed in a version (as it is used as delimiter in a range). i.e. - install some.IU=version1,someIU.2,some.IU.3=version.3
I don;t remember the format but I'm pretty sure I implemented this in the installer (no access to a p2 workspace right now). Perhaps we should try to be consistent? (of course I could have done something brain-dead...)
Jeff, I looked for something in the installer to model this work on but didn't find it. It would be best to do something here that can be used in both places (in terms of syntax if nothing else). Henrik, my use cases of using the director app to provision an internal corporate installation don't require use of a version range. I will always want to install a specific version of the top-level IUs (which in turn may declare dependencies that use version ranges). I'm not arguing against version ranges though, I just can't think of a use case.
Terry, see InstallDescriptionParser#initialize. Here is it parsing a number of properties from a description file, but it could similarly be command line arguments. In particular see the handler for PROP_ROOTS, which parses an arbitrary list of id/version pairs.
The format proposed by Terry: -install some.IU.1[version.1],some.IU.2,some.IU.3[version.3] suggests that we use ranges, which we don't. We could of course, and let this '[xxx]' be the same as '[xxx,xxx]' which would then actually make everything right with Terrys format. That however, introduces another problem, namely the >= range since it cannot be specified this way. Henriks proposal: -install some.IU=version1,someIU.2,some.IU.3=version.3 is better in this respect but if we ever want to consider ranges, we need to do it from the very start and say that whatever comes after '=' is a range specification, not a version. I.e. some.IU.3=3.0 >= 3.0 some.IU.3=[3.0] Exactly 3.0 some.IU.3=[3.0,3.0] Exactly 3.0 some.IU.3=obscure\[1.0\] >= obscure[1.0] (non OSGi containig [] characters)
Now I'm confused. I don't see the immediate need to have to specify range on the command line of the director and if we needed we could require them to be double squared (e.g. foo[[1.0.0, 2.0.0]]). So given that we don't really have any better proposal, that we need something and we can't afford to fix #273200, let's move forward with this.
You realize that in some sense, the only real difference between Teds proposal and mine is the use of '='. Teds: some.IU.3[version.3] mine: some.IU.3=[version.3] The meaning would be exactly the same (exactly version.3). Thinking more about it, there's no conflict in supporting both formats so if we at least allow the '=', we will open up for a nicer and less confusing range syntax in the future. Would that be OK?
and that should of course be Terry, not Ted. Sorry.
IMO - go for the "=", even if not initially required, it makes it easier to extend it in the future, and there is no harm in having it there.
I only see two particular requirements: - The syntax should be simple in the simple case. we are very good at making complex thing possible but seem to have a pension for exposing all that complexity to everyone. - The syntax of the director and that of the installer should be the same. That way it at least looks like we are building a coherent solution.
(In reply to comment #19) > - The syntax of the director and that of the installer should be the same. > That way it at least looks like we are building a coherent solution. > The current syntax used in the installer is: -install some.IU.1/version.1,some.IU.2,some.IU.3/version.3 So lets settle for that and then, post 3.5, we can introduce the new syntax: -install some.IU=someRange where '=' is optional when the range is delimited by []. The only drawback I can see with that approach is that perhaps it feels more natural to let '=' mean exact version and to let '/' be followed by a range. But anyway... The parser for the current syntax is in the VersionedName class. Apparently we have two such classes. See bug 273674.
Created attachment 133520 [details] Update director application to accept a list of IUs
I followed Ian's suggestion to update InstallableUnitQuery to accept an array of IUs/versions. The director application has been minimally changed. Now both "-installIU" and "-uninstallIU" take either single arguments or comma-separated lists. For "-installIU", each element can be a either and "iu" or an "iu/version" pair, with "/" as the separator character. Would it make sense to add "-installIUs" and "-uninstallIUs" arguments as well? The original "-version" parameter is treated as a default range, and applied wherever the optional "/version" part of the "iu/version" pair is not specified: -installIU a.b.c -version 2.0 yields a.b.c/2.0 -installIU a.b.c/1.0,x.y.z -version 2.0 yields a.b.c/1.0, x.y.z/2.0 This patch depends upon 273674, since that is a nice consolidation. I added a "join" function to StringHelpers.java since Strings.join() is not available. JarProcessor.concat() could reuse it, and probably others. In the new InstallableUnitQuery constructor, it is best to ensure that the lengths of the input arrays are equal. Surrounding code suggested using the Assert macro to throw an IllegalArgumentException. I'm not sure what the contract is for InstallableUnitQuery.getId() and InstallableUnitQuery.getRange(). They are not accessed anywhere in the p2 source code. Given that InstallableUnitQuery now accepts multiple IUs they don't have the same meaning anymore. If they were not public I would remove them. For backwards compatibility I have them return the first element. Does anyone have a better suggestion?
Terry, thanks for the patch. I already have a fix for this in the new director app that I'm working on but perhaps this one can be applied to the old app. I did not include the -version argument in the new app since I think it's confusing to combine that option with the multiple IU's syntax. Using one query to find all IU's was something I found rather difficult since it then became hard to figure out if one of them was missing.
(In reply to comment #23) > I did not include the -version argument in the new app since I think it's > confusing to combine that option with the multiple IU's syntax. > Yes, starting with a new app, it makes sense to drop the -version argument. Is this new application going to be bundled with the equinox-p2-agent (bug 268188)? Having a single app that does mirroring, metadata generation, and remote installations is extremely useful.
(In reply to comment #24) > Is this new application going to be bundled with the equinox-p2-agent (bug > 268188)? Having a single app that does mirroring, metadata generation, and > remote installations is extremely useful. > Isn't that a question of grouping things together in a useful feature that contains all the needed apps? Why do you need one single app?
This new application will still reside in the p2.director.app bundle, as such it will be delivered in the agent. Note however that we are having problems with the agent (just bogus dependencies and such) and we will probably not make it available for M7 and but we will turn it on again for RC1 (see bug #274453). Sorry for the inconvenience. Closing this as fixed since this has been addressed with the release of the patch in 268138
