Re: [cross-project-issues-dev] AMP optional dependencies issue Re: Aggre

["Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>]

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