Community
Participate
Working Groups
I'd think not. This is similar concept to some of the issues discussed in bug 345503, where are features are not "tied down". But, it goes beyond that, since, even if specific versions of features were specified, I think, from what I'm seeing, that bundles listed as optional in a manifest.mf would be pulled into EPP package, if the bundle happened to exist in the common repository. And, I'm not sure that's right ... seems a "product" should be completely defined by its features. This has risen now, for JEE package, due to the "javax.transaction" bundle being included. See bug 348156. I first thought that was an EPP issue ... then thought it was a WTP (dali) issue, but now am wondering if indeed an EPP issue, if EPP is pulling in bundles simply because another bundle lists it as optional. The reason for my shifting view is that at one point, I could see if I installed WTP via P2, then javax.transaction would be installed ... so I thought it was part of some content metadata touchpoint install instructions, or something, but later learned I did the test wrong ... if I install WTP via p2 with common repository disabled, then javax.transaction is not installed. In other words, javax.transaction is indeed in no part of WTP, except that one bundle lists it as "optional". I guess I've always thought of an "optional" statement in the manifest as meaning "use, if some feature happens to install it", not "install, if some repository happens to have it available". Is there a common, agreed-to interpretation? So ... I am hoping, Markus ... you can tell me if this is intentional? Purposely including optional bundles not named in a feature? Is there some way to turn that off for EPP Packages? It may sound like a "big change" during our final week, but if it was a simple switch, I'd like to try a build without it, and see exactly what would be different ... if anything would break without some optional bundle, which, if so, means it wasn't so optional after all :) My main purpose, for now, is to keep that javax.transaction bundle out of our JEE EPP package, and longer term, it is to have "perfectly reproducible builds" that depend only on feature definitions ... not simply what is or is not available in the repository. Advice welcome.
Quick and short answer: I couldn't find an option that changes this behaviour in the p2 director. The only solution could be to add something to the p2.inf file that disables or that prohibits the installation of this plugin. But I am unsure if that works. I can look into this later today, but any advice from the p2 team would be very welcome.
I wasn't able to find any solution in EPP and the way we call the p2 director. It is either the p2 director which is missing this ability, or it is my inability to find the correct parameter. I think we should forward this bug to the p2 team, since it is in my opinion not a EPP issue, at least I need some advice or hints what to try next.
See bug 348156 comment #9 for more background on the p2 metadata. My hope is that the p2 director has a hidden feature that I am not aware of.
Apparently, from a quick search of bugzilla, this problem has come up many times before, such as see bug 247099. In those cases, it was the IDE and "install" that was being discussed ... and seems this EPP related issue is more directly related to p2 director. Seems to me, if p2 director (or "install") can not be told to avoid optional dependencies, there's no way to create a perfectly reproducible "product" based on features. It would always vary, depending on what happened to be in repository the repository (and/or what repositories were selected). Is there another way recommended to create a perfectly reproducible product, based on features only?
The only guarantee that p2 makes in term of resolution is that given a set of repos and a set of IU to install the outcome will be the same. As pointed out, this is the same discussion than in bug #247099. In short there is no option on the director itself to avoid this behaviour because it is not the right place to fix it. For example, if I start by installing WTP with the "no optional" mode, later when the user installs something else from different repo what is the behaviour? As indicated in bug #247099 I think this sort of behaviour needs to be a flag in the profile or something like that. As for this particular pb it could be possible to avoid it by adding in the incriminated bundle a p2.inf that will mark the dependency as non-greedy. Closing as dup for now. *** This bug has been marked as a duplicate of bug 247099 ***
Thanks for the confirmation, Pascal. This was in line with what I found out, but I wasn't sure if I had missed something.
(In reply to comment #5) > The only guarantee that p2 makes in term of resolution is that given a set of > repos and a set of IU to install the outcome will be the same. > And given that the contents of the set of repos can change over time, there is no guarantee the outcome will be the same, over time. Interesting. Seems if we in WTP wanted to guarantee the same install, based solely on our feature definitions, we could go through our content.xml file, and add greedy='false' to all <required elements that specified optional='true'. I say it that way, since if that is conceptually the right or good thing to do, then sounds like a good feature request to automate it ... but, not sure for who. PDE build? I find it interesting that the p2.mirror task, via slicing options, has ability to specify includeOptional="false" but p2 director does not. I'm not saying if that's right or wrong ... but interesting. > > As for this particular pb it could be possible to avoid it by adding in the > incriminated bundle a p2.inf that will mark the dependency as non-greedy. > If I could lean on your expertise a bit more ... what's an incremented bundle? :) More to the point, the bundle we include in our WTP feature is a bundle we get in a pre-built form (similar to how we all get a bundle from Orbit). So, can our WTP feature have a p2.inf file, that "specifies" a required statement for this pre-built bundle? Or, does the p2.inf have to go in that bundle itself? It would make sense if it could go in our feature (for our use case) since in our WTP feature, installed in IDE, we'd want to say it should be non-greedy. But, if someone else was including this pre-built bundle in say an app server runtime, then they might well want it to be a greedy requirement. Complicated. If we could specify this requires, in our feature, for the prebuilt bundle o.e.persistence.core (which we include) with a p2.inf file with something like requires.1.namespace=java.package requires.1.name=javax.transaction requires.1.range=1.1.0.$qualifier$ requires.1.optional=true requires.1.greedy=false then that'd be pretty easy (in practice, and conceptually) but somehow doesn't seem like this would work. A little too indirect? Seems to me the o.e.persistence.core bundle would still generate its own requires properties. But what do I know. :) I am more concerned about the general case ... and admit that I feel a little dumb learning just now that installs are not completely predictable ... that it depends on which repos one uses (or, exactly what time). :( Much thanks for any continued observations. I will follow other bugs.
> Seems if we in WTP wanted to guarantee the same install, based solely on our > feature definitions, we could go through our content.xml file, and add > greedy='false' to all <required elements that specified optional='true'. That would not suffice because there is no guarantee of order in which p2 consults the repository. Consequently if there was other copies of this IU in other repositories but with the unchanged dependencies, then you would not be guaranteed to get the tweaked IU. > I say it that way, since if that is conceptually the right or good thing to do, > then sounds like a good feature request to automate it ... but, not sure for > who. PDE build? The current behaviour of p2 is to generate greedy optional dependencies. We could likely change that in the p2 publisher for 3.8 but this would require a new version of the IUs to be used and everybody to adopt this new publisher. > I find it interesting that the p2.mirror task, via slicing options, has ability > to specify includeOptional="false" but p2 director does not. I'm not saying if > that's right or wrong ... but interesting. Yes this because :) Someone has suggested the addition of this flag ont he director but I think this is a nice hack but not the right solution. > > > > > > As for this particular pb it could be possible to avoid it by adding in the > > incriminated bundle a p2.inf that will mark the dependency as non-greedy. > > > > If I could lean on your expertise a bit more ... what's an incremented bundle? > :) > > More to the point, the bundle we include in our WTP feature is a bundle we get > in a pre-built form (similar to how we all get a bundle from Orbit). > > So, can our WTP feature have a p2.inf file, that "specifies" a required > statement for this pre-built bundle? Or, does the p2.inf have to go in that > bundle itself? It would make sense if it could go in our feature (for our use > case) since in our WTP feature, installed in IDE, we'd want to say it should be > non-greedy. But, if someone else was including this pre-built bundle in say an > app server runtime, then they might well want it to be a greedy requirement. > Complicated. I look at this in the same way than when I get a bundle. If the manifest is bogus I get it fixed at the source otherwise I can't use it. p2 metadata is similar in this regard. If the producer encodes too much specifics into the IU (e.g. greedy dep), then I need to have him fix it so I can use it. In this particular case, I think we could play a trick by having a patch that patches the non greedy dependency and replace it with nothing, or introduce a negative requirement. > I am more concerned about the general case ... and admit that I feel a little > dumb learning just now that installs are not completely predictable ... that it > depends on which repos one uses (or, exactly what time). :( This has always been the case. The pb really is that if ppl don't tighten up their ranges then p2 will have no indication on which version to pick and will pick whatever is the highest (this is the current policy in the resolver). We tried to come up with ways to improve this by offering something in between teh control imposed by locking versions in features and control in the repo, we called that affinity, but never managed to put a semantics to it. This is ideally where I would like to see things going. > Much thanks for any continued observations. I will follow other bugs.
