| Re: [cross-project-issues-dev] [cbi-dev] Building SimRel with Tycho for 2021-03 |
There is a big size difference between the *.jar versus the
*.xml.xz, especially for the content.jar/content.xml.xz:
https://download.eclipse.org/justj/?file=releases/2020-12/202011271000
We'd not want to lose that I think, because this has a
significant impact on the server traffic...
In general I'm concerned that as a contributor to SimRel this
change to the process does not look like an improvement to me,
i.e., it's just different but not actually better in terms of
authoring.
I'm not keen on the separation between where I specify the repo
to use and where I specify what to include from that repo (and the
absence of authoring support for that latter). Because of that
separation, goodness knows if what think I contribute will really
come from my repo and not some other repo.
I also wonder too if the two different implementations
(resolution algorithms) use to build the repositories really do
actually produce the same repositories? E.g., when I contribute
Oomph, I do not contribute the http client bundles (as an
example). I do it that way so that I don't contribute conflicting
or older versions of those things. But what stops the Tycho
resolution mechanism from grabbing potentially older the ones from
the Oomph repository anyway? Nothing I think...
The Planning Council ought to speak out and the simrel participant opinions (if any one has one!), ought to be considered too.
Thanks for having a look Fred.
On Thu, Nov 26, 2020 at 8:58 PM Frederic Gurr <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx> wrote:
* is there a good reason why the pom.xml has been moved to a module
instead of keeping it in the root pom.xml/directory?
No, I just wanted to keep all files in the repo without removing anything; but it's not necessary. The pom.xml/category.xm can totally be in the root folder.
* can you give some insight what "remove-xz"
remove-xz removes the .xz files from the p2 repo because we manually edit the p2 repo with remove-uncategorized and this manual edition seems to fail at updating the .xz files (but works for .xml and .jar files).
and "add-aliens" do or why they are necessary?
The units part of "add-aliens" are the ones that are not in the main validationSet of SimRel. Those units can basically not be installed together with SimRel, they'd make the dependency resolution fail. To me, they'd better be out of SimRel and instead the RAP tools should take care of providing a proper target-platform skeleton to work with, referencing the necessary repos. However they're here at the moment; so the add-aliens adds them to the repo using a way that doesn't check compatibility with other units, so that it doesn't fail.
* how did you create the category.xml file? (side note: I opened the
category.xml file with the category.xml-editor and the opening alone
re-wrote/re-formated the whole file.)
Using the action in CBI aggregator to generate Tycho build from .aggr file.
* According to the comment, the list of repositories in the pom.xml file
was generated with the CBI aggregator tool. Was that only necessary for
the initial list?
Yes.
What would a new project need to add and where? Only
add bundle/feature to the category.xml and add the repository to the
pom.xml?
Exactly.
* is there still a way to only validate changes like the "validate" profile?
Yes, this is new in Tycho and is what triggered that thread. `mvn validate` does that.
If we want to switch to Tycho for the 2020-03 release, we will need to
put some documentation in place for existing and new users what needs to
be changed and done.
Sure. I'll add comments to the pom.xml for your previous questions and a CONTRIBUTING.md to explain how to add/modify content; and will create a new patch set that removes the aggr stuff and put the Tycho-based aggregator at the root. But not before Tuesday.
Cheers
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev