Oomph the build
wimjongman opened this issue · 12 comments
We want our builds to mimic what has been done for other projects, e.g. BIRT:
https://download.eclipse.org/birt/updates/index.html
Ed @merks, can you help us with this? I can do the lifting if you tell me what you need:
- Target platform
- ...
I see there is already a setup. I've not tried it yet, but I will...
Are you asking that you'd like the *.target to be generated as side effect of resolving the targlets as is current done for BIRT?
The build promotion stuff I understand. I see your ci instances don't use a Jenkinsfile. That would make configuration of the job much easier, and managed in the clone rather than separately.
Let me investigate how the setup current works and sketch out some scaffolding for what would be needed. Both EMF and Oomph use too, so I have a vested interest in in be well maintained...
The setup doesn't work, so I started to repair it:
ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the install because one or more required items could not be found.
ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1695451715693
ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Draw2d 3.10.100.201606061308 (org.eclipse.draw2d 3.10.100.201606061308) requires 'java.package; com.ibm.icu.text 3.8.1' but it could not be found
If I import all the projects, there are many errors.
I guess I should not do that, but do they exist if they are not used/maintained?
Some I could try to fix, but I don't know data binding well to know what the replacements should be...
It's better if I only import the feature and its dependencies, but even then, there are errors:
I've not looked at the build to see how the dependencies are specified, but I don't find a meaningful *.target...
I don't get the sense that the builds are producing things that are tested to work with (or even compiled against) the latest Eclipse Platform...
Yes, many widgets are without an owner so the build can be stale for some projects when moving to newer Eclipses. I will take a look at that. I know the bidi stuff is special, @tomsontom should be able to comment on that.
What do you mean with bidi? Eclipse Databinding?
What do you mean with bidi? Eclipse Databinding?
As far as I know bidi refers to bidirectional text.
Normally that was bidi means to me as well. In this case though, most of the compile errors come from the removal of the untyped data binding APIs and it's not so clear to me (from lack of experience) the replacements, and Tom contributed the data binding extensions to EMF, so in this case I think that was what was meant...
Ed, I have fixed the psf file it is in releng/org.eclipse.nebula.feaure/Nebula_All.psf. Can I add that to oomph as a file predicate in the working set node?
No. (I’m not even sure what you are hoping that would do. )
Create working sets.
Is it OK now ?
I assume you'd still like your build restructured? When i try to reproduce the build locally, it doesn't reproduce at all. I think it's not currently in a buildable state because of version inconsistencies in the poms.
There are still lots of projects not imported into the workspace but which appear to be part of the build. E.g., when I added the incubation feature, there are some small errors. I'll provide a PR for that. But I think you still build against photon which is really old and I'm not sure that things build against photon will actually run.