[cross-project-issues-dev] Projecrt IMport difficulties (was Re: FW: [Do

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Ed

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:

• Extract that project's source repos; Does Foo have many repos? Goodness forbid does it use SVN? If it uses git, does it also use gerrit so you can commit changes for review?
• Ensure that you have the appropriate VM; Does Foo need Java 1.4, 1.5., 1.6 or 1.7 to be available?  Do they have project specific settings to help?
• Install the right tools in the IDE; Does Foo rely on build and generator tools that you'll need to produce runnable code?  Does Foo rely on tools to work with its specialized artifacts?
  
• Provision a target platform with the right things needed by Foo just to compile and run the tests.  Are those dependencies documented? Are there 30 such dependencies? Which p2 repos do those dependencies come from?  Which versions of the dependencies are needed by which branches of Foo?
• Provision a workspace with the necessary projects;  Are there 300 hundred of them?  Are they logically grouped into working sets.   Do you have you have to figure that out yourself?

How many of these issues are well addressed by team project sets?   Just the last bullet I think.  Also, consider this: how many of you have tried one of those for project Foo, and ended up with a sea of errors that can and will cost you hours to address?  This is one of the key barriers to entry, because those hours spent on setup time will drive anyone but the most resilient to despair and saps the very lifeblood from those we wish to tap for involvement and contribution.

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

    Regards

        Ed Willink