I think that's a good finding. https://bugs.eclipse.org/514585 <https://bugs.eclipse.org/514585>
-Gunnar -- Gunnar Wagenknecht [email protected], http://guw.io/ > On 31. Mar 2017, at 17:45, Doug Schaefer <[email protected]> wrote: > > From what I can tell in my quick debug session, it looks like Mylyn (the > FocusedTeamUIPlugin)is causing Subversive to load on startup. And it’s > actually the bundle activators that kick off this dialog. I suppose ideally, > the dialog isn’t needed until an actual SVN repo is needed. > > <6084765B-C032-4C27-9693-30026DBC6948.png> > > From: <[email protected] > <mailto:[email protected]>> on behalf of Igor > Vinnykov <[email protected] <mailto:[email protected]>> > Reply-To: Cross project issues <[email protected] > <mailto:[email protected]>> > Date: Friday, March 31, 2017 at 6:40 AM > To: 'Cross project issues' <[email protected] > <mailto:[email protected]>> > Subject: Re: [cross-project-issues-dev] Subversive Dialog (was Re: Neon.3 > Update Problems: To Fix and Howto Fix?) > >> Hi Ed, >> >> Yes, that's correct, the dialog is displayed only when SVN features are >> accessed at the first time, i.e. you open SVN Repositories view, for >> example. I don't know why it is opened prematurely in Eclipse distributions >> - that's the question to integration authors. >> >> Best regards, >> Igor Vinnykov >> >> From: [email protected] >> <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of Ed >> Willink >> Sent: Friday, March 31, 2017 1:21 PM >> To: [email protected] >> <mailto:[email protected]> >> Subject: Re: [cross-project-issues-dev] Subversive Dialog (was Re: Neon.3 >> Update Problems: To Fix and Howto Fix?) >> >> Hi Igor >> >> I just installed Subversive (without any extra integrations) in my workspace >> with many modeling projects. I performed a few GIT, CVS activities without >> seeing the Subversive dialog. It didn't appear till I opened an SVN >> perspective. Reasonable. >> >> This suggests that >> - Subversive SVN Team Provider is well-behaved >> - platform / GIT / CVS are well-behaved >> - some other project/integration is waking up SVN prematurely. >> >> Regards >> >> Ed Willink >> >> >> On 31/03/2017 11:01, Ed Willink wrote: >>> Hi Igor >>> >>> I don't think that it is the Subversive dialog that is the problem; that is >>> a necessary inconvenience that you have agreed with Wayne. >>> >>> The problem is the eagerness with which it is displayed. It should not >>> appear until the user has indicated that an SVN action is required. A >>> GIT/CVS only user should never see the SVN dialog. >>> >>> Perhaps you are putting up the dialog too soon. Perhaps some other project >>> tickles all the team providers and so provokes your dialog into premature >>> appearance. >>> >>> Regards >>> >>> Ed Willink >>> >>> >>> >>> >>> On 31/03/2017 10:49, Igor Vinnykov wrote: >>>> Hello, >>>> >>>> I've noticed the Subversive Connectors installation dialog on the >>>> screenshot, so are there any questions/problems regarding Subversive >>>> connectors distribution? This topic was discussed multiple times with >>>> EMO/Wayne, so I can continue this discussion if anybody is interested. >>>> >>>> Best regards, >>>> Igor Vinnykov >>>> Subversive Team >>>> >>>> From: [email protected] >>>> <mailto:[email protected]> >>>> [mailto:[email protected] >>>> <mailto:[email protected]>] On Behalf Of Ed >>>> Merks >>>> Sent: Friday, March 31, 2017 12:14 PM >>>> To: [email protected] >>>> <mailto:[email protected]>; Cross project issues >>>> Subject: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and >>>> Howto Fix? >>>> >>>> Hi, >>>> >>>> The original thread is fractured into many threads so its kind of >>>> impossible to follow each thread with a reply but I'll try at the bottom >>>> of this note, i.e., below the =========== >>>> >>>> But before doing that, I'd like to re-focus on the most important >>>> questions: We currently have a problem with Neon.3, will we fix it, and if >>>> so how will we fix it? >>>> >>>> The discussion has quickly digressed (constructively) into solving the >>>> issue of how Orbit dependencies should be managed by projects and by the >>>> release train. Unfortunately I see this as a world hunger issue; not one >>>> that is easily addressed and I believe not one we can wait for in order to >>>> solve the Neon.3 problem. Let's face it, we've not been able to produce a >>>> proper Oxygen milestone in months, we still don't have one now, and we >>>> won't have one until next month, we hope. >>>> >>>> For Neon we've done three maintenance releases. Neon.1 needed a respin >>>> and Neon.3 looks to be in need of the same thing. Clearly something is >>>> seriously wrong. But if we spend our time on solving the Orbit world >>>> hunger issue, will we arrive at a solution in time for Oxygen, let alone >>>> in time to fix Neon.3? I am very, very doubtful. >>>> >>>> As another data point, if I install the egg-laying-wool-milk-pig for >>>> Neon.3. The following happens. I'm prompted to accept this license: >>>> >>>>> Red Hat, Inc. licenses these features and plugins to you under certain >>>>> open source licenses (or aggregations of such licenses), which in a >>>>> particular case may include the Eclipse Public License, the GNU Lesser >>>>> General Public License, and/or certain other open source licenses. For >>>>> precise licensing details, consult the corresponding source code, or >>>>> contact Red Hat, Attn: General Counsel, 100 East Davie St., Raleigh NC >>>>> 27601 USA. >>>>> >>>> I'm not sure how this license slipped into the release train. Aren't >>>> there checks for this? (Sorry to digress, but this is also unacceptable.) >>>> >>>> Launching the final installation comes up like this: >>>> >>>> <image001.jpg> >>>> >>>> Clearly a disgusting mess, but I've mentioned that before and the same >>>> projects are still doing the same bad things, so we clearly all accept >>>> this situation as normal. >>>> >>>> The most important point here is the error log (first attachment) is full >>>> of exactly the problem indications (bundle wiring problems) we should have >>>> expected from the Neon.3 repository's contents, if someone were to install >>>> an arbitrary combination of the repository's contents. It's really not so >>>> hard to test this! >>>> >>>> If I create the same installation with my local build of the Oomph 1.8 >>>> installer---which installs my locally built version of Oomph 1.8 so the >>>> Oomph setup plugins are no longer disabled because I made the userstorage >>>> dependency optional and eliminated the strict <=4.4 upper bound >>>> constraints on httpclient, which was such a bad idea I can almost have a >>>> canary to think this done to solve a problem with no anticipation of the >>>> problems it would cause---then I can visit all the preference pages >>>> producing the second attached much larger log. It seems clear that proper >>>> testing really doesn't happen for far too many projects on the train. >>>> With distributed responsibility, no one is really responsible... >>>> >>>> ================================== >>>> >>>> Orbit Issues >>>> >>>> 1) Respinning Linux Tools against Oxygen Mx seems to miss the point that >>>> we should only distribute released versions of bundles, so no Neon build >>>> should redistribute any unreleased version of anything. If a new version >>>> of something is needed for security reasons or other reasons, it should be >>>> released first. And doing that in a maintenance train without testing the >>>> overall impact is clearly something we should never do again (without >>>> waving a bunch of red flags of warning). And as Martin Oberhuber asks, is >>>> nothing in place to check for this? So suppose we do respin with a fixed >>>> released version, like what we have for Oxygen M6, then most likely we'd >>>> still have the problems we have in Oxygen M6 so we'd need a fix to the >>>> resolver in Neon. Better would seem to respin with the old version(s) of >>>> the Orbit bundles, but somehow we can never delete the broken version from >>>> Neon and because it has a higher version number is likely to slip back in >>>> unexpected (though hopefully not, given that features have pinned their >>>> bundle versions). >>>> >>>> 2) Don't include Orbit bundles in your project's features. Sounds like a >>>> great idea, but begs endless questions, and while solving a problem might >>>> well introduce more new problems than it solves. The first question (as >>>> Carsten points out) is how do these things end up in a repository, and if >>>> they are in a repository somehow, how are they categorized? It's hard to >>>> get them in and once you do, they're categorized poorly. The next >>>> question is, how do they end up in the release train, if the projects that >>>> need them don't contribute them? Directly from Orbit you say? But which >>>> ones should be pulled in from Orbit and how is that discovered? Are >>>> those the ones the projects have tested against? Then there is the >>>> question of whether an installation is deterministic if the bundle version >>>> isn't pinned? It's not; it will depend on what's in the repos that are >>>> available at resolve time. But Gunnar argues that even packages are not >>>> deterministic, which I think is false: if the feature pins the bundle >>>> version and the package requires the feature, then the pinned bundle is >>>> definitely in that package. But regardless, Gunnar's important point is >>>> that the runtime wiring seems kind of non-determinstic, and while uses >>>> constraints might help, who the heck understands those well, what tooling >>>> produces it correctly for us, is that nicely integrated in PDE, and will >>>> it be properly maintained (in contrast to lower bound constraints which >>>> you can pretty expect will remain on whatever stale version they were >>>> initially set to). This may well be the right direction in which to go, >>>> but getting there isn't going to be even half the fun... >>>> >>>> Regards, >>>> Ed >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>> >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >>> >>> Virus-free. www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> [email protected] >>> <mailto:[email protected]> >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > <image001.jpg>_______________________________________________ > cross-project-issues-dev mailing list > [email protected] > <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
