Community
Participate
Working Groups
Currently @artifact is a special parameter that's processed on a case by case basis by the specific ProvisioningAction that uses it. One of the problems we've seen is where a user reference's @artifact in an action that does not support the syntax. Another problem is that the @artifact lookup done in actions is currently touchpoint specific so even if an action supports the @artifact syntax the lookup might not find the artifact. For example if an artifact is "collected" by the Eclipse touchpoint an action from the Native touchpoint will not find the artifact when referenced with @artifact. These consistency problems are confusing to everyone and we might consider providing consistent support across the board for @artifact or perhaps deprecating that and suggesting the use of ${artifactLocation} and be done with it.
Created attachment 134914 [details] exploratory patch This patch adds an ${artifactLocation} parameter to the Install, Uninstall, Configure and Unconfigure phases. The lookup is done using the touchpoint type of the IU which is not ideal but I'm not sure how else we would do it.
Simon, Thanks for opening this. I am all for making things more sane and easier to support in the future. I'm a little confused as to how this helps my particular case of wanting to install root files into a location other than ${installFolder} though, which is what I am trying to do in the newsgroup posting that prompted you to open this bug (http://www.eclipse.org/newsportal/article.php?id=6212&group=eclipse.technology.equinox#6212). As far as I can tell, this will give you a way to reference artifacts within your feature and make @artifact more sane (I'm all for that). How does this allow me to provide a different touchpoint action for a root files IU? Also, I have seen in the code lots of comments about multiple artifacts per IU. In short, they are theoretically possible, but quietly ignored. For example, '@artifact' refers to the "first" artifact in an IUs artifact list. Also, I think, fundamentally, other operations will just ignore other artifacts and just handle the first one as well. Is this going to address that issue as well?
Multiple artifacts per IU is not possible (see bug 179519), however artifact is the granalurity of what we download, and as you have probably found, an artifact that deliver multiple files.
It's tempting but likely risky to squeeze this in to 3.5. I'm going to look at doing this in 3.5.1 as it makes it much easier to mix and match actions and further makes it much easier to write custom actions that need to reference the artifact location.
Another approach worth thinking about here is to just have "collect" always use one artifact repo. For cases like the bundle-pool we can use mapping rules to still install in plugins and features relative to the install folder. The benefit is that looking up an artifact location is always the same regardless of how the artifact was collected.
It is not clear how that helps. What is @artifact supposed to refer to? The downloaded thing before install or after install? Seems like there would be a need for both. Perhaps that is relative to the phase in which the var is used? The thing that we were looking for was after install as the input to a copy action wanting to copy some file from the bundle (artifact) to some other place. (one example)
@artifact refers to the absolute file location of the artifact. This location does not change after the collect phase has completed and the artifact downloaded into the download cache or the bundle pool. For features and (where necessary) bundles the unzipping is done as part of the eclipse touchpoint's collect "action". Currently I feel we have very strong coupling between the collect "actions" and the various touchpoint repo. What I'm looking for in this bug is one consistent way to get artifact locations ideally without having to have knowledge of what collect action was run. What I was getting at in my previous comment is that we might consider using just one repo and then mapping rules to get the different classification of artifacts in it. What this might look like is for the artifacts.xml typically at the root of an eclipse install to have a rule something like: <rule filter='(& (classifier=binary))' output='${repoUrl}/p2/org.eclipse.equinox.p2.core/cache/binary/${id}_${version}'/>
This has not been added to 3.6 yet. At this point I would prefer to see this moved to 3.6 rather than rushed in 3.5.1. If needed, once it is in 3.6 we can decide to backport to 3.5.x.
Agree. This seemed like it was going to be a hot button but haven't heard any complaints so 3.6 is a better target.
Fixed in HEAD. I've added support for ${artifact.location} which should be used in preference to @artifact. @artifact will continue to be processed by the existing actions that support it however the actions in all cases will try to do a lookup for "artifact.location" in the action parameters. I've updated the action tests to verify with both old and new style. In terms of implementation "artifact.location" is created by the touchpoint when the operand is initialized either when the IU has a touchpoint assigned to or when an action associated with the touchpoint is invoked. The artifact.location will "only" be set if the parameter is not already set and the touchpoint finds the artifact in it's touchpoint specific cache. In this way we specifically allow and test the most common problematic case where a native action uses artifact.location with an IU that references the eclipse touchpoint.
.
