Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Projecrt IMport difficulties (was Re: FW: [Doug on the Eclipse CDT] New comment on "Eclipse smells kind of dead"???.)


Comments below.

On 13/07/2013 11:03 AM, Ed Willink wrote:
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.
Yes, though it's more valuable to provide a patch, which is best done via the team support, so better to have the project extracted from git and submit a patch for review to gerrit...

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...
Yes, that's often the case.

For the above use cases, I think it is largely a matter for project testing to ensure that the builds work.
With gerrit submission and associate hudson triggers it's even better because all the tests are executed...

3) Full development workspace. This has been undermined by GIT,
I'm not sure why you say that.  I've grown to love git and am just falling in love with gerrit!
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.
Hmm.  In general git's performance is so dramatically better than CVS that I've not found this to be a problem...
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
Yes, or some improved version that considers more of the issues.  I.e., the external dependencies of these things...
-- it should disable auto-builds
-- it should clone the GIT repo
-- create Working Sets all named "Project ...."
Often projects themselves know better what working sets are appropriate...
-- include "Project Archive ..." and or "Project Dead ..."working sets that clearly identify all the garbage in the repo that should be ignored
Better to specify what should be included...
-- (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,.
Buckminster is extremely helpful and perhaps under utilized for this purpose...
-- 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.
In the end, all the infrastructure that's needed exists, it's mostly a matter of automated orchestration...


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.
Even if it's set to that, you can still end up calling methods from 1.6.

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?
Yes, a common set of project-specific settings that can be shared across dozens of plugins is another issue.
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
Yes, all these kinds of things are what's needed to lower the barrier to entry.


        Ed Willink


cross-project-issues-dev mailing list

Back to the top