[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] LSP4E: A Problem Waiting to Happen?
|
Hi
Yes I think I saw something similar a few weeks ago, when I needed to do
a feature-affecting change for MoDisco.
But mostly I never use the aggregator tooling since it breaks EMF [1]
Once a tool has bitten you a few times, you remember to avoid it like
the plague.
Usually my changes are for repo-name/feature range only and so are much
better done with a text editor.
Regards
Ed Willink
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=527164
On 08/12/2019 12:17, Stephan Herrmann wrote:
thanks for nagging :)
While we are at it, is anybody using validation from the aggregation
editor??
Reason for asking: whenever I try that, it aborts with this message:
Unable to load repository
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository
Unable to load repository
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/
Build failed! Exception was org.eclipse.core.runtime.CoreException:
Unable to load repository
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/
yes, my browser can see that repository. Is p2 not ready to read from
archive.e.o? Is the repo broken by any terms?
anybody else seeing this?
Stephan
On 08.12.19 10:23, Ed Merks wrote:
Hi,
It's me the nagger again. I know many of you are editing your
*.aggrcon manually. This is mildly annoying. When I edit using the
editor and save my changes, all the files being edited manually change.
I can and do revert all these, but it's annoying.
Unfortunately this approach also makes it easy (and likely) to
overlook problems in the consistency of the overall simrel.aggr
resource.
In addition, the recommended process for contributing is to point
your contribution at a specific update site:
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#The_best_format_and_process_for_contributing_to_Sim._Release
When you don't do this, your contribution will potentially change
dynamically, which might be convenient for you, but it is problematic
from an overall consistency point of view. It's also less than idea
if your specific site updates its content dynamically...
Why do I harp about this? I'm quite sure that lsp4e intends to
contribute the 0.13.0 release for 2019-12:
https://projects.eclipse.org/projects/technology.lsp4e/releases/0.13.0
But look closely at what the editor tells us:
While the "dynamically changing" repo (I can only assume that this is
the case) does contain version 1.30.0, this is *not *what's
contributed to the the 2019-12 release train. Somewhere (and I have
no clue from where) the 0.12.0 version is found and that's what's on
the train:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-12/http___download.eclipse.org_releases_2019-12_201912061000/org.eclipse.lsp4e_0.12.0.201909270706.html
I'm quite sure this is not the intent so I've opened this Bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=557998
Regards,
Ed
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev