Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] AMP optional dependencies issue Re: Aggregator / B3 / Buckminster Question

Brilliant! If it works... Is this hard to setup, i.e. something I could do in a few minutes? Are you sure P2 mirror won't do the same trick and grab the optional dependencies and/or can we exclude specific bundles?

[followups off list]

On Jun 8, 2011, at 4:09 PM, Konstantin Komissarchik wrote:

> You should be able to use p2 mirror utility to mirror a subset of your
> existing repository, then point aggregator at that smaller repo. That would
> keep your bundles binary identical in both places.
> 
> - Konstantin
> 
> 
> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles
> Parker
> Sent: Wednesday, June 08, 2011 4:06 PM
> To: Cross project issues; Wayne Beaton
> Subject: [cross-project-issues-dev] AMP optional dependencies issue Re:
> Aggregator / B3 / Buckminster Question
> 
> 
> Groan. Good news is that my aggregator passed, bad news is that it includes
> stuff it shouldn't. So I have the answer to my question and the answer is
> that the aggregator *will* pull over plugins that haven't actually been
> requested. Thanks Martin for the bug report, I'm glad I'm not the only
> person who was surprised by this.
> 
> AMP will need to rebuild, and I'm left with a few options given that I need
> to provide the GEF3D plugins on the AMP site, but it shouldn't be part of
> the Indigo release proper, unless Wayne thinks we can get an exception for
> that. ;) (I have committer rights and I've fixed the simrel issues for GEF3D
> I think, but it isn't on Indigo release train.)
> 
> 1. Remove the optional plugins, which will cause some inconvenience to end
> users but nothing show-stopping.
> 2. Try to discover some way to force aggregator not to include these
> optional plugins or to remove them from the built or deployed aggregator.
> 3. Only build the Indigo targeted feature itself and point the aggregator at
> that.
> 
> I'm inclined for option 3 but that means that the contents of the "Release"
> repos my project points to and what is included in the Indigo aggregator
> will be different only in version qualifiers. Wayne, would that be kosher?
> 
> cheers,
> 
> Miles
> 
> 
> On Jun 8, 2011, at 2:33 PM, Oberhuber, Martin wrote:
> 
>> Hi Miles,
>> 
>> Optional dependencies being installed sounds like
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099
>> 
>> Thanks,
>> Martin
>> --
>> Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
>> direct +43.662.457915.85  fax +43.662.457915.6
>> 
>> 
>> -----Original Message-----
>> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles
> Parker
>> Sent: Wednesday, June 08, 2011 11:31 PM
>> To: Cross project issues
>> Subject: Re: [cross-project-issues-dev] Aggregator / B3 / Buckminster
> Question
>> 
>> 
>> I'm also thinking that perhaps I could simply exclude these bundles from
> the aggregator, but looking at the docs, it seems that you can *add* bundles
> and use Exclusion Rules to exclude *features*, but there doesn't seem to be
> any way to exclude plugins. And I'm not at all clear on why P2 would include
> these anyway. I always thought that the purpose of features was to provide a
> clear indication of what the user wants to install. Does anyone know why is
> P2 is adding optional stuff not included in the feature?!
>> 
>> On Jun 8, 2011, at 1:20 PM, Miles Parker wrote:
>> 
>>> OK, I've got AMP staged and it appears to be working but the signing
> report revealed an issue that I'm hoping people can give advice on...
>>> 
>>> I've got some plugins that have optional dependencies on stuff that will
> *not* be part of the Indigo release -- they're Eclipse hosted and IP ok, but
> the project isn't participating. My thinking was that that would work fine,
> but when I get the feature that I'm providing for Indigo from my release
> update site, P2 goes ahead and grabs the optional dependencies as well, and
> I then get a signing message. My *thinking* is that when the aggregator
> runs, P2 will *not* get those optional plugins unless of course the user has
> also added the AMP release update site separately. I won't be able to
> actually test that until the aggregator runs on my most recent build so I
> wanted to ask if my reasoning seems correct?
>>> 
>>> (My other alternative that I'm just trying now is to remove those
> optional dependencies, but that will mean users that then add those optional
> features may lose functionality.)
>>> 
>>> For buckminster folks, I'm wondering is I set the "eclipse.p2.optional"
> to "false" in the build will that make any difference as far as the
> provisioning time dependencies go? I'm guessing no..
>>> 
>>> As a side note, I'm trying to diagnose an issue -- somehow my other
> committer's changes in the last week have been lost in the git wilderness --
> like gone, not even accessible in reflog. :( Unfortunately, he's in Central
> Europe, so it's unlikely that I'll be able to get him to try to recommit the
> changes. I've got an open bug with webmaster, so If I am somehow able to
> restore those important bits before the cutoff tonight, I may ask for a
> fresh build.
>>> 
>>> cheers,
>>> 
>>> Miles
>> 
>> 
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top