Community
Participate
Working Groups
Bundle manifests should only list required bundles. It seems that most bundles specify too many requirements, e.g. o.e.m.modeling.tests has almost 70 dependencies.
Well, I typically only add a dependency if the project won't actually build without them. I'll admit I've been lazy with .tests, but with a quick scan I can't see much that I can get rid of their short of going through each individual bundle and pulling them out. GMF and Papyrus in particular are really bad as far as dependency granularity goes.
Found a few things in modeling.ui I can do without including mylyn java (good catch there) and some eclipse ui stuff. But not much else. We're integrating a lot of stuff so its natural to have a lot of dependencies. https://github.com/MilesParker/mylyn.incubator/commit/b453a37d738fb0d0d38111d3749a5381164f6f8f
(In reply to comment #1) > Well, I typically only add a dependency if the project won't actually build > without them. I'll admit I've been lazy with .tests, but with a quick scan I > can't see much that I can get rid of their short of going through each > individual bundle and pulling them out. GMF and Papyrus in particular are really > bad as far as dependency granularity goes. PDE also has support for removing unused dependencies automatically. We may want to split up the test bundle further to gain better modularization. One of the things that's not quite clear to me is why modeling.ui would have a gmf dependency while it's part of the EMF feature. I would have expected the EMF feature to have dependencies on pure EMF only?
(In reply to comment #3) > (In reply to comment #1) > PDE also has support for removing unused dependencies automatically. We may want Yes, in my experience it has been overly aggressive so I always end up needing to put stuff back in (and then forgetting to remove the automatically inserted version qualifiers :#) But I tried it again and it didn't do badly, I just had to manually fix a couple of things. So I've just taken a good whack out of some more. > to split up the test bundle further to gain better modularization. Yeah, I usually go on for one on these, especially since there is some stuff that we might want to be able to isolate if things go south. This was sort of a short term thing while I worked that package structure out. > One of the things that's not quite clear to me is why modeling.ui would have a > gmf dependency while it's part of the EMF feature. Um, because I overlooked it? Good catch.
OK, I think this is pretty minimal. Please reopen if you disagree.
