Replies: 7 comments 19 replies
-
|
I would not want to split org.eclipse.equinox.security I think this should impact what the built equinox-SDK zip would include. Such a move would need to be broadcast pretty clearly to inform users where to find the moved bundles. |
Beta Was this translation helpful? Give feedback.
-
Is there any specific reason? The
The equinox-SDK includes also P2 (and then p2 ui stuff ...) and something else, I'm not quite sure whats the purpose of this is ...
It seems the SDK ist not realy "standalone" so one actually would already need the platform repo/platform SDK so maybe it would not be a big issue for users anyway? In a perfect world, I think equinox should be able to be build from scratch without any platform or i-build repos and even released independently... |
Beta Was this translation helpful? Give feedback.
-
To keep development of security stuff to one repository. I never spent that much time in the equinox.security implementation, but IIRC |
Beta Was this translation helpful? Give feedback.
-
|
For sure it is a consumer, but looking at the history at |
Beta Was this translation helpful? Give feedback.
-
|
What profitable outcome do you expect in this refactoring? |
Beta Was this translation helpful? Give feedback.
-
As described the equinox build currently depends on eclipse.platform (what depends on equinox) ... that makes it hard to release equinox independently of platform in the same build, so we currently need a large, slow and inflexible "aggregator build" to account for some preference page managed in equinox that has no benefit for the equinox story that is:
So the main goal is that equinox can be release / build independent of platform / UI stuff.
If you think its better to move more stuff away, go on ... I just trying to find as small as possible improvements and "disruption". |
Beta Was this translation helpful? Give feedback.
-
|
I also found that equinox depends on regarding the SDK zip, it seem to also contain P2 stuff so just technically speaking if we move a bundle from one repository to another, it would still be possible to include it in such a SDK zip through the aggregator update-sites... So would it be an option if we keep the features/sites as is for now but move the bundle? FYI @akurtakov This is directly related to my current attempt to have a "maven compatible" deployment as in this PR #128 but it is hard to get this right if the build depends on foreign (snapshot) dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
I still don't understand why is this move a prereq for the "maven compatible" deployment? I fully understand the principal separation of core/ui bundles and preferably separating the builds and etc. but this would lead us down the rabbit hole as there is too much interdependencies and the only way to do proper separation is having more dedicated git repos with separate releng but we tried to move away of many git repos for ease of contribution sake. |
Beta Was this translation helpful? Give feedback.
-
Currently
That's why I choose the one I would assume is the "root" of all and actually this works already quite well except some special cases that are:
I can also add 3+4 to the "ignore list", that is they won't contribute any useful maven-meta-data but first want to investigate if there is any chance to solve this issues, so we can release equinox independent and anytime of any other platform repo/aggregator. The next would be P2, where one could consume the (snapshot) release of equinox (lets ignore the UI parts for now), and then P2 can also be released independent and anytime and then finally Tycho can also consume this without need to waiting for a quarterly release and hoping that the maven-data is not wrecked :-) |
Beta Was this translation helpful? Give feedback.
-
|
Now, I understand what you try to achieve and like the end goal a lot. Let's see what @tjwatson thinks about independent releases of Equinox first before we continue with technical details. |
Beta Was this translation helpful? Give feedback.
-
|
I would also like independent releases of Equinox as an end goal. I am fine moving equinox.security.ui to platform, but like I mentioned, I think it best to keep all of equinox.security.* in one repository. We could move jobs to Equinox, but the more OSGi "pure" way is to move everything that is not dealing with implementing the OSGi specifications out of Equinox altogether, including the extension registry itself. Basically everything that was originally split out of org.eclipse.equinox.common I see very little evidence that anyone consumes any of these bundles without also having the If I had the time to invest, I would want all these bundles to be moved to platform along with anything else in Equinox that depends on the extension registry. Ultimately I would want to recombine all of these core.runtime bits back into a single That would leave equinox as the most basic core and then platform the thing everyone else is based off of to do Eclipse platform stuff.. |
Beta Was this translation helpful? Give feedback.
-
|
I realize what I stated above is likely too much for anyone to realistically act upon in one go, if ever. If the easiest thing to get to the end goal (Equinox independent release) is to move selective stuff to and from Equinox then I would not object. |
Beta Was this translation helpful? Give feedback.
-
|
I think there is a false premise here from which conclusions are being drawn. The premise seems to be that Equinox can't release without the Platform's release because Equinox depends on the Platform with special attention specifically on org.eclipse.ui:
But it only depends on really old versions of these things. Versions that are released already, long ago. That bundle also depends on org.eclipse.core.runtime. So why isn't that also problem? Many things depend on org.eclipse.core.runtime:
I think we should keep in mind that we can release anything as long as we make sure that it works with a released version of its dependencies as declared by the lower bounds. Otherwise one couldn't release the Platform unless EMF releases and EMF can't release unless the Platform releases, but neither of those statements true because neither the Platform nor EMF depend on specific things in the latest version of either. I get the sense that taking this deck of cards and reshuffling it is going to prove futile at best. I'm not even sure why one specific dependency on one specific bundle was singled from all the other dependencies... |
Beta Was this translation helpful? Give feedback.
-
No one said it isn't ;-)
As @tjwatson said, the main culprit here is the split nature of ".core.runtime" so whether or not someone depend on this or that
It is never futile to improve things instead even if that do not solve all possible problems ... so one valid decision might be that equinox no longer ship an UI bundles (that is only this single one here) because UI is not a projects concern.
Well the problem is we declare this but no one test this, e.g it is never build nor checked that such a thing still works ...
Well actually the final goal outlined by @tjwatson can be archived fast and easy (fro equinox), we simply delete all of the mentioned bundles and equinox ships the ones from the 2022-09 release from now on... simple as ABC isn't it? And as no one depends on the "latest stuff" there shouldn't be a problem at all! |
Beta Was this translation helpful? Give feedback.
-
|
I think we stopped having a serious technical conversation. |
Beta Was this translation helpful? Give feedback.
-
Why do you think so? Because all other argument are are always "false premise"? Can you show a "technical" way to release given that both equinox and platform depend on a new feature off either? Just because it "works" today, where we never update, even though this won't work at all because of all the singleton bundles, does not mean there is no problem with such cyclic dependencies! And we have already seen multiple times how this breaks consumers that only want to use parts of that in their builds... |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure what to say about Yes, of course if there are two-way changes, releasing them independently is a problem. You didn't say that though but rather suggested deleting a bunch of things forever, which is not a serious technical point to be made. How often does this bundle need something new from SWT or the UI? In any case, it seems releasing parts of org.eclipse.core.runtime's split packages is already a major problem. Seems like show stopper. Can we say anything technical about what will resolve that issue? |
Beta Was this translation helpful? Give feedback.
-
You wrote:
An I do not take offense of any kind, just noticed that it often is that case (my be a wrong feeling though):
That makes it hard to argue on a technical level.
And that's all what I have suggested from the beginning, that one can't release (in all cases) both independently if the reverence each other. That we can release somehow (now) as we have not the case is something that was never neglected., it is just very hard, just assume something like Log4J would be detected today in Equinox and one would ask for an immediate bugfix how would this work? Release equinox and hope that there is nothing newer used anywhere? Scedule a full simrel release? Actually it would take weeks, while one better need days if not hours in such a case to spin a release. Even the very very simple request to deploy one single artifact that is nowhere used in platform directly and completely stand alone was regarded too complex and user has to wait for more than two hours until finally the next release was out: this is simply horrible and shows that there is a real problem.
This is just a logical extension of the argument "we can release because we only rely on old stuff" to show that actually this is not a valid argument. I would consider this valid if e.g. Equinox would always use the latest released platform and platform always using the latest released equinox in its build and release target platform like Tycho does, but thats not the case and I assume would also be not accepted at all.
Nothing you would like as it won't be backward compatible (as far as I know) :-) Maybe one could use some dirty hacks like creating a complete new,bundle put all code there and properly export it, reference that in the others with visbility=reexport ... |
Beta Was this translation helpful? Give feedback.
-
|
The statement Along the line of what you are suggesting, it would be not totally unreasonable, for example, to say "Equinox bundles should not use any new API from the Platform until after one release cycle". I think that would be reasonable and manageable. I think it would possible to do builds and run tests that would verify that this works correctly. Also, I don't think security.ui is highly evolving and it seems to me that this bundle needing immediately to use something new from the Platform would be an uncommon event. As a case in point, EMF does builds to ensure that everything other that the Xcore support works (compiles and passes all the test) for very old versions of the Platform: https://ci.eclipse.org/emf/job/all-target-platforms/ I.e., the lower bounds really are tested... I imagine it would be possible to set up such a build for Equinox and perhaps that way would be less work, and would produce quicker results, without breaking anything, than trying to untangle the messy inter-dependencies, one by one, until the every last one is gone, hopefully, eventually. I'm trying to make a constructive suggestion, so please don't read "everything is sunshine and roses" between the lines... |
Beta Was this translation helpful? Give feedback.
-
|
The point about So from my point of view, as someone working in different projects (and not all find that eclipse is the end of all glory), I don't see any value in managing it here as:
So that's was the only thing I suggested here it is small it is focused and it is doable. The rest was just came out of the discussion, "if we do this would it not be good to also do ..." and then it turned into something "this might be to big and we will never archive it" ... |
Beta Was this translation helpful? Give feedback.
-
|
Your comment here suggested releasing Equinox independently was a goal: You reiterated that point here to characterize that goal as the profitable outcome of the refactoring: You reiterated the point again here: Now you argue that mostly purely for "separation of concerns," Equinox would be better off without UI dependencies. That being said, at the same time you are also suggesting, yet again, that getting a step closer to independent releases is a goal (among 'other' goals). It's really hard to pin down what exactly you are hoping to achieve and why that is so important when you yourself bring in so many tangential concerns, topics, and goals. For example when you start out by mentioning that I know you want the discussion to be focused, but the focal point seemed to be general |
Beta Was this translation helpful? Give feedback.
-
It is a goal for me, and this is a small step towards this goal
Well as said, I'm looking for improvements that are actionable to reach a higher goal, and if it helps people to better understand I also try to describe what one can call a "vision" ... and there was even some kind of agreement by @tjwatson and @akurtakov that this in the end would be a good achievement.
I don't get whats the problem with this, these are not exclusive to each other nor contradictory reducing (unnecessary) dependencies help in better managing releases and makes development more focused and removes the burden of maintaining unrelated stuff. So there is always more than one "goal" a certain change can improve. So if "separation of concern" seems irrelevant for someone, "having independent releases" might be relevant for them so they can be certain that the first is good if it pays off the other as well.
I think the main goals and motivations are exhaustively explained, at least I have no idea how to better paraphrase it ... and it is important to "me" because I use equinox/platform a lot and many people I talk with have similar concerns and it is often state that trying to improve is useless because of the bureaucracy and retentissement of "eclipse", on the other hand there are always complains "we" must do something so people contribute more/don't migrate to VsCode/InteliJ/... so what I try instead of complain, is looking for ways to improve and actually make a difference.
I already mentioned I'm open to solve this in a larger scale, but it doesn't help at all to say "we should take a larger scale" and on the other hand claim "we can't reach that goal realistically". So I try to find the smallest possible increment that could be archived... what will lead to another thing that then seems achievable and so on ... As a result we have now maven-artifacts as first-class citizen in PDE/Tycho something that was claimed to be "never achievable", mixed reactor builds, also something that "most probably can never be archived", and many more ... just because they do not affect everyone does not mean they are of no helping others. One should always think outside the box.... |
Beta Was this translation helpful? Give feedback.
-
|
Let's say we have a rule "Equinox bundles should not use any new API from the Platform until after one release cycle" and let's say we set up a build that builds Equinox against 4.25 to test that it compiles and to demonstrate that the tests pass. Is that not actionable? Is that not a small enough step? If we did this, wouldn't it be possible to release Equinox more often? (I imagine it would be good to do this for p2 as well.) Perhaps the above is out of focus or tangential to the primary theme, but in almost every post here you come back to this as the goal toward which this one simple change is one single step in that one right direction. But then you get frustrated that we look toward the next step and the next step. Not only that you simply don't respond at all the concrete suggestion repeated in my first sentence above. This is a suggested improvement that could help address a really tough problem in just a few steps, that to me appear actionable. In any case, at at this point, I think I've said all that needs to be said. Others like @tjwatson @arunkumart @mickaelistria and can decide what actions make the most sense. |
Beta Was this translation helpful? Give feedback.
-
That's actionable, but would mean complicate build and development, what contradicts the whole purpose of making build simpler and easier to manage. So we just replace one odd thing by another even more complex one. |
Beta Was this translation helpful? Give feedback.
-
While working with the maven info generation for equinox I noticed that equinox has an inter-connection with eclipse.platform through the
org.eclipse.equinox.security.uibundle (it requiresorg.eclipse.ui).It seems equinox itself has no use for this UI bundle and as it cannot work without platform I wonder if it would be possible to move that bundle to the
eclipse.platformrepository to make equinox repo more self contained?Beta Was this translation helpful? Give feedback.
All reactions