|[cross-project-issues-dev] Projecrt IMport difficulties (was Re: FW: [Doug on the Eclipse CDT] New comment on "Eclipse smells kind of dead"???.)
Some interesting points, not all of which I recognize.
On 13/07/2013 07:39, Ed Merks wrote:
Ask yourself, as a committer with a significant amount of experience working on your own project (i.e., you know a lot about how to work with Eclipse's infrastructure), if you wanted to work on some other Eclipse project Foo to provide a patch for a problem, how much work is it to do the following:
Eclipse has very good Java support, so the best source of the code is the SDK. I see progressively more challenging use cases.
1) Quick Hack. I expect to be able to import an interesting plugin as source and use an instrumented version of it in a nested Eclipse. This usually works, but I have submitted a number of Bugzillas where it doesn't. Shame on all projects that fail to provide the sources or omit auto-generated sources for distributed code.
2) Simple fixes. I expect to be able to import an interesting plugin from its CM in very much the same way. This was much easier with CVS that allowed single plugin checkout. It is also more reliable when projects tag their CM to identify the matching state for the milestone build. This provides an ability to submit patches, but may open up the horrors of magic tooling, in which case a full development workspace is necessary...
For the above use cases, I think it is largely a matter for project testing to ensure that the builds work.
3) Full development workspace. This has been undermined by GIT, which does at least now support Team Project Sets, but the very long checkout time and disposition details for complete repos when only one plugin is required (e.g. the EMF Examples Library) makes it very unattractive to develop/test/use. The lack of utility of the GIT Team Project Set has stopped me complaining about the Team Project Set being removed from the PMI again.
Here we need new shared discipline. With GIT, perhaps
- the Team Project Set should be available on the PMI, with drag and drop from Browser to Package Explorer
-- it should disable auto-builds
-- it should clone the GIT repo
-- create Working Sets all named "Project ...."
-- include "Project Archive ..." and or "Project Dead ..."working sets that clearly identify all the garbage in the repo that should be ignored
-- (dead projects should have their builders and natures commented out.)
- the ...releng plugin should provide one or more further Team Project sets to install all required dependencies for tooling etc,.
-- the user may need some control over activation of these
This seems to benefit from a little bit of help from PSF tooling
- DND from browser
- build disabling
- delegation and configuration of releng PSFs after the main PSF
The rest is just naming and discipline and could at least work today.
I find that mostly the JVM is not a problem. Surely everyone uses 7 as their primary VM? It is just that we develop for lesser VMs and it is the testing of the variants that can cause nightmares. In particular if the workspace preference is not set for 1.5 compliance bad things happen, since we have no inter-project setting inheritance.
Why can't e.g. emf.common be designated the EMF 'settings' plugin so that emf.ecore and all auto-generated plugins inherit their non-overridden settings from emf.common rather than the exciting surprises that come from the indeterminate workspace? The overrides could be multiply inheritable so that the GMF 'settings' plugin could merge EMF andGEF settings. There may be conflicts, but let's have the developer sort them out once rather than each user.
Perhaps an extension to API tooling can validate that
- Import Plugin with Sources will inherit determinate settings independent of the workspace
- Checkout Plugin from CM will inherit determinate settings independent of the workspace
- multiply inherited settings are not conflicting
Back to the top