> Means, using the new p2 publisher is obligatory and greedy=false is > not obligatory. > <quote>If the old behaviour is desired, i.e. an optional dependency > shall be satisfied during installation whenever possible, the > dependency can be annotated with an additional > directive:resolution:=optional;x-installation:=greedy. > </quote> > I use the new p2 publisher and x-installation directive. So it's ok. > Still friends? :)
Yes, still friends . But, with greatest respect, I think you are trying to read the requirements as a literal contract that might contain loop-holes that can be worked around, rather than as guidelines to make the Simultaneous Release (and common repository) as good as possible. We are after the "as good as possible". [And, if you really were confused by the wording or intent, feel free to say so and we can improve the wording. We didn't "completely rule it out" because, who knows, there might be a few cases its justifiable, just like there are a few cases where jars can not be signed or can not be pack200'd ... but ... pretty obvious to use a publisher to change the default, and then work around that default for each and every case of "optional" does no good to anyone. I'm still not sure why you went to that extra work ... though, I'm sure you had your reasons at the time.] If it turns out you (your projects) are the only only ones using blanket "installation:=greedy", you know what I'm going to recommend to the Planning Council, right? While my word is never "the final say", if you insist on keeping it like that, and insist you want to be in the common repo, I'm afraid the burden will fall to you to justify it. I'm pretty sure your presence in the common repo would fall under the "do no harm" clause of the requirements document [1] if you are looking for another requirement to "get around" :). And, who knows, I could be wrong. Wouldn't be the first time ... at least the third or fourth ... hundredth! time. I'm disappointed this discussion is taking place so late in the cycle, but I appreciate we are having it. Thanks, [1] http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Do_No_Harm From: Dennis Hübner <dennis.hueb...@itemis.de> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 05/25/2012 03:54 AM Subject: Re: [cross-project-issues-dev] More on greediness attribute Sent by: cross-project-issues-dev-boun...@eclipse.org Thank you for your briefly response, David. Obligatory. To be in common repo. From http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#OSGi_bundle_format <quote> Clarification on 02/01/2012: the repositories produced and contributed must use p2 publishers that produce greedy='false', by default, in the content metadata. See bug 247099 and the p2 Publisher wiki for some history and details on this issue of greedy vs. non-greedy requirements. </quote> Means, using the new p2 publisher is obligatory and greedy=false is not obligatory. <quote>If the old behaviour is desired, i.e. an optional dependency shall be satisfied during installation whenever possible, the dependency can be annotated with an additional directive:resolution:=optional;x-installation:=greedy. </quote> I use the new p2 publisher and x-installation directive. So it's ok. Still friends? :) > I'd like that people accept, that this is a valid combination and don't nag on projects, who use it. I've obviously not done a good job of education, but its not a valid combination. Its been that way "for years", wrongly, and so many people complained about it something had to be done. (Not literally just because of complaints, but conceptually ... people were convinced it is a bad idea to automatically infer install behavior based on (optional) runtime requirements ... and this repo-metadata-attribute solution was thought to be the "least of all evils", say as opposed to changing p2's behavior itself). Yes… We all have our horrors and our demons to fight. Thanks for your commitment. So we are trying to improve the yearly Release and its common repo. Yes, its a change from previous years. And, now, the reason its a requirement to be in common repo, is its something we must do consistently for it to work. Otherwise, one project would be "forcing" their preferences on all other participants. Or, worse, causing the install behavior to be undefined and indeterminint. I am going to try to improve the report. Bug 380571 - greediness report needs work Martin's pointed out what may be one bug. Maybe there's others. Plus, while I was hoping to avoid spending so much of my time on this, I will see if I can add "back tracking" to the report, so we'll know who has the conflicting specifications. If anyone knows now that they wants _all_ their optional runtime dependencies to be installed greedily, then they should probably not be in the common repo, and suggest they just have their own, where they can do what they want with their metadata and not conflict with other participants. I'm open to discussion, but don't see how the conflicting specifications could ever work. > it's not as bad as missing about.html files or unsigned jars, isn't it? Right, not as bad as missing about.html files ... and, I don't know ... almost as bad as unsigned jars :) Thanks to all, <graycol.gif>"Oberhuber, Martin" ---05/24/2012 09:59:53 AM---Hmm, I thought we had been through all that discussion on bugzilla already (I can't find the ref ri From: "Oberhuber, Martin" <martin.oberhu...@windriver.com> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 05/24/2012 09:59 AM Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time! Sent by: cross-project-issues-dev-boun...@eclipse.org Hmm, I thought we had been through all that discussion on bugzilla already (I can't find the ref right now since bugzilla is down). In a nutshell, - Optional greedy is bad since it can cause side-effects : When I install A and optional greedy B,C happen to be available they get installed even when I don't ask for them, causing unexpected side-effects. - Yes Optional non-greedy has no effect on the installer; But, the p2 metadata also serves as documenting the OSGi/runtime dependencies from all MANIFEST.MF in a repo so having it in there is extra information that may help some and doesn't hurt. Martin -----Original Message----- From: cross-project-issues-dev-boun...@eclipse.org [ mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas Hallgren Sent: Thursday, May 24, 2012 3:37 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time! On 05/24/2012 03:13 PM, Gunnar Wagenknecht wrote: > Am 24.05.2012 14:57, schrieb Thomas Hallgren: >> One could very well argue that an optional non-greedy dependency is >> completely useless and doesn't fulfill any other purpose but documentation. > We have a bunch of bundles in place that have optional non-greedy > dependencies to allow flexibility at runtime. For example, Logback can > be configured via API, XML or Groovy. Groovy as well as XML > configuration require additional dependencies. Imaging all those > dependencies were greedy. Then they would be installed of course. Now they are not installed and the dependencies have no purpose aside from what I mentioned earlier, documentation. > BTW, they need to be optional for the bundles to properly resolve if > the dependencies aren't there. They need to be declared to allow the > bundle class loader to load them if they are available. To my knowledge, the bundle class loader is using the MANIFEST.MF, not the p2 meta-data. So my argument still stands. - thomas _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<<inline: graycol.gif>>
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
