Today our requirements for tracking which projects feed the aggregates are *three tiny pieces* of information: a) build with the MINIMUM target platform b) test with the MAXIMUM target platform c) use the correct BUILD_ALIAS d) SPOILER ALERT, there's a 4th piece too - see below. All three of those *can be set in Jenkins* - in fact we set the first *two* already (we only set BUILD_ALIAS for JBDS to force it to be GA instead of Final). Then we would only need to *encourage* people to use the latest parent pom for local testing, and not actually need it for running builds. But IMHO the Task JIRAs force people to run local tests, and gentle encouragement will lead to things NOT getting done. -- If you'd like we can test this approach with the 8.1.0 builds in Feb/March. As long as BUILD_ALIAS & the max target target platform version (something like 4.42.0.*) are incremented in Jenkins (to move through Beta1/CR1/Final/GA), and all the projects w/ changes have properly upversioned their plugins/features where necessary, everyone can continue to use the 4.2.1.Final-SNAPSHOT version of the parent pom. Enforcing we all use the latest parent pom is a convention... but it isn't *strictly necessary* after we drop a x.y.0.Final (as long as Jenkins has the correct information needed). (It is required for 4.3.0.before-Final builds because the value of the *minimum* target platform IS changing every month or so, and we're adding variables to support migration of integration tests out of the unit test suites, etc. So for the ramp up to the 0.Final, we DO need everyone using the latest parent pom.) --- HOWEVER... there is a fourth reason to use the latest parent pom. Our parent pom defines the list of upstream sites used when building the individual projects (eg., Server depends on Base), which for 4.2.1.Final includes two unchanged project sites: Hibernate and LiveReload. https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.2.x/pare... For master branch, everything will be new, so we use all the staging (nightly) sites: https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... This list is also used when creating the composite site we use to determine that: * everything in the site can be co-installed (using headless p2.director installation test) * if there are changes to the contents of one or more project, the aggregate will be rebuilt to pick up those upstream changes, and we'll see failures as soon as possible* So again, this is important for x.y.0.before-Final builds, but not for x.y.z.maintenance builds (since those minor changes should be compatible. Interesting example... you list the two projects out of 17 which in fact have no commits in github 4.2.x branch since 4.2.0.Final release. :D * - for example, recent refactorings in Server's AS Tools test plugins in master have caused webservices tests to fail due to a missing dependency. -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com