Gang, I have been discussing a lot with the Gradle devs about "recommended project" structure, and they (Peter and Hans) have provided a lot of feedback on how various set ups can be realized.
After some more testing and consideration of the "Git Submodules" feature, I would like to propose that a "unified view" of Qi4j is created. It helps the build system (esp versioning) a lot. So; * Qi4j Core, Libraries and Extensions remain as separate GitHub repositories, authorization reasons (unless we want to go with a social contract instead). * Qi4j Sandbox also remains as separate GitHub repo, mainly to keep it out of view. * Remaining sources are collapsed into the Qi4j SDK repository, which will be accessible by 'anyone'. * Current qi4j-tests will be re-organized for regression, integration and performance tests. The dev work will be slightly 'cumbersome' due to the "Git submodule" issue that I meantioned a few days ago. 1. Checking out the Qi4j SDK. 2. Run "git submodule update". This should only be needed once. 3. If working on 'core', 'libraries' and/or 'extensions; do a 'git checkout develop' in that directory. 4. After committing/pushing any of the above, must do "git add core", "git add libraries" and "git add extensions" respectively in the SDK level directory. Then commit/push the SDK. (Edward; Is there anything I forgot to mention?) Other notes on Gradle; * Gradle will build either from root or from 'current dir'. In the latter, it will also build anything that has changed elsewhere, that the 'current dir' depends on. * There is no need to install Gradle, if you are Ok with running ./gradlew from project root. * The way I am setting up Gradle, it is executing a single phase for all projects before going to next phase. Meaning all compiles will happen before any test compiles which are before any test execution. This can probably open up the possibility to have "testRuntime" dependencies on 'unaccepted' artifacts, for instance a library needing an extension during tests. I have not checked if this actually works. Other notes; * I will let Gradle look inside the dev-status.xml to determine if a module is ready for release. 'beta' would be the minimum, and perhaps place it in a 'lib/beta/' folder in the SDK to make that clear. * All modules will be published as Maven artifacts to OPS4J's repository. I think a couple of artifacts will end up with different group/artifact names, since this build system I am creating is purely algorithmic (to keep the build sources small) and in Maven it is manually maintained and there are some discrepancies... There are probably heaps of other things I should mention... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
