Hi
Also https://bugs.eclipse.org/514587 is a purely SVN bug. Add/Open
project build delta triggers dialog.
Regards
Ed Willink
On 01/04/2017 07:42, Gunnar Wagenknecht wrote:
I think that's a good finding.
https://bugs.eclipse.org/514585
-Gunnar
--
Gunnar Wagenknecht
[email protected] <mailto:[email protected]>, http://guw.io/
On 31. Mar 2017, at 17:45, Doug Schaefer <[email protected]
<mailto:[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]]*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]]*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://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://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
_______________________________________________
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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
