[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Liviu and All,
I think the first release should be done with whatever way works better
for you at the moment. The public URLs are also is not that important as
you always can redirect them to the better location (that is not
invented yet) using "composite p2 repository" approach.
After the first release I would propose to prepare another package for
EPP. EPP already has several packages that duplicates functionality but
with different focus - so I think that introducing another package
"Eclipse IDE for Embedded Developers" could be the right way to go
forward. Yes, it can share about 90% of its content with "Eclipse IDE
for C/C++ Developers" and I do not see any problem with it.
As for " content inheritance" - I'm not a fan of inheritance, mostly
because it is "one way ticket" and you cannot "uninherit", so I would
suggest to use feature composition. I hope we always can find a way to
declare a proper aggregating feature(s) on CDT side to decrease the
amount of duplicated identifier between "C/C++" and "Embedded" packages.
Another plus for joining the EPP will be the reducing of effort
duplication for package publishing. Well, to be honest, it may create
more work for Jonah as he is co-leading EPP. But Jonah is doing RelEng
work here as well, and from the outside it looks like adding another
package to EPP is much cheaper than introducing and maintaining the
individual "package support" for "Embedded CDT". Jonah, please correct
me if I wrong.
Regards,
AF
25.07.2020 21:34, Liviu Ionescu пишет:
I updated the EPP fork that I used in the past, and the build passed, I was able to create the new packages for 2020-03 with 5.1.1.
I tried to figure out what would be the next step, but could not find a clear answer.
As it is now, the EPP configuration I use is a slightly changed epp.package.cpp where I added the GME features and some small branding fixes.
The first thought was to create a new configuration (epp.package.embedcpp?) and apply the changes there.
Copy/paste for the three projects would probably not be difficult, but maintaining it in sync with future changes in the .cpp projects will.
Also considering the future SimRel integration, what would be the proper solution? Ideally the .embedcpp would inherit from .cpp and change a few things, but I'm not sure such a configuration is possible.
I am tempted to stick to the current EPP fork solution, and for the moment focus on the changes to run the build on Jenkins, so I can sign the resulting packages and publish them on the download servers.
Another issue: I don't know how to handle the location of the released packages. Ideally this location would not change after joining SimRel, but this might not be possible.
Is it ok to publish the results on something like 'https://download.eclipse.org/embed-cdt/packages/2020-03/'?
Alexander, any thoughts?
Thank you,
Liviu
_______________________________________________
embed-cdt-dev mailing list
embed-cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/embed-cdt-dev
