Sounds like a great initiative. We in Eclipse Platform are also simplifying our project structure at the moment (combining multiple sub-projects). Great to see that WTP plans to go a similar route.
Best regards, Lars On Tue, Jul 11, 2017 at 11:09 PM, Robert Stryker <stry...@redhat.com> wrote: > Hey everyone: > > So I've been working on getting that dependency graph stuff going, and I > haven't been very successful because of the cycles ;) I have some raw data, > which is excluding (for the most part) test plugins, but a few test plugins > snuck their way into the report because they're in weird folders like > "development" instead of "tests". So just gloss over those where possible. > > The purpose of this missive is to try to: > 1) get a properly ordered project with CI with Jenkins, fewer jobs, fewer > repos, etc, wherever possible; > 2) To identify what exact coding changes (other than repo merges) will be > necessary; > 3) To get +1's by current component leads to do the above, ie, express a > willingness to get things done. Without a willingness to make some changes, > we might be stuck with an old and convoluted structure and alienate the new > releng guy ;) (ie Nick Boldt) > > Full gist with raw data is here: > https://gist.github.com/robstryker/b584195b5067b0909dc2b57cbcc9ef8f > > But, I can provide a summary. > > WTP can be thought of as basically 5 tiers: > 1) Common/server at the bottom > 2) jsdt / source-editing > 3) javaee stuff (javaee, ejb, webservices) > 3a/3b) webservices.axis2, webservices.jaxws, and jsf > 4) Dali at the top > > Tier 1: > > Common/Server is a bit messy at the moment. Common depends on server > currently because it exposes an extension point that uses wst.server's > IRuntime. JavaEE uses that extension point. If we refactor that extension > point, it could use the facet IRuntime instead and break the circular > dependency. > > QUESTION 1) > IS SUCH A CHANGE APPROPRIATE AT THIS TIME? If it's not appropriate, or > cannot be approved, then we might have real issues in breaking these > circular dependencies between repos until the next major release. > > Once that's broken (there are gerrit pushes for that change), there's still > one more issue: org.eclipse.jst.common.ui (in common) depends on > org.eclipse.jst.common.frameworks (in javaee). > > One of these plugins needs to move, either up or down. Luckily the only > things between javaee and common are jsdt/sourceediting and server. The data > doesn't show either would be affected by either a move up or a move down. > > QUESTION 2: CAN ONE OF THESE PLUGINS BE MOVED AT THIS TIME? > > Servertools would look much nicer if it was 1 repository. > > QUESTION 3: Will the servertools lead consent to a merge of their repos? > > Tier 2: jsdt / source-editing. These two have circular dependencies among > themselves. It'd be great if these 2 projects could figure out a proper > heirarchy, or, alternately, if they'd agree to be merged into one repo ;) > > QUESTION 4: Are the jsdt / source-editing repos able to break their circular > dependencies? If no, are they willing to be merged into one repo? > > > Tier 3+: JavaEE / EJB / Webservices: These guys need a bit more > investigation. We could theoretically merge ALL of it into one repo, which > would be very convenient but I'm not sure it's 100% appropriate. > Alternately, we could deep-dive to see if or how the dependencies could be > broken. I haven't had time to deep-dive on a plugin-by-plugin level yet. > > Tier 4: Dali: Dali is fine. Probably doesn't need any changes. > > > All of the above is regarding primarily the plugins themselves, NOT any test > bundles. Nick and I have been working at a pom structure that would allow > builds of your plugins (ie mvn clean install) to occur against only your > required dependencies (and fail if you depend on something that is not on > your tier or lower), and a different profile to use for integration tests. > > This is required because, surprisingly, almost all unit tests are actually > integration tests with code much further up or further down the stack as > compared to where the tests live. > > So basically, the 4 questions are, when can we begin making changes (even to > API if necessary or moving plugins between repos) to Tier 1, is servertools > willing to merge their repos, and are jsdt/sourceediting capable of breaking > deps or do they consent to a repo merge? > > Thanks all > > - Rob Stryker > > > _______________________________________________ > wtp-dev mailing list > wtp-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/wtp-dev -- Eclipse Platform UI and e4 project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com _______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/wtp-dev
