I think this year more students will prefer to use IntelliJ rather than Eclipse. IntelliJ can't load two projects into one workspace, and can't thus display the code coverage across these projects. Last year Martin created the jpacman-mvn-multimodule project for IntelliJ users. I suggest to change his structure slightly, and not have both the jpacman-template and jpacman-framework repositories as git module, but only use git submodules for the core and move the template into a regular Maven submodule within the template repository:
jpacman-template
> jpacman-framework (git submodule)
> jpacman-tests (jpacman-tests/... in repo)
On the student side, not too much will change. They have to initialize the git modules first, which can be done along with the clone operation as a one-liner: git clone --recursive git://github.com/foo/bar.git or after clone (git submodules init && git submodules update). Then the parent project should be imported as a Maven project, which will then work out of the box for both Eclipse and IntelliJ.
Another benefit is that we can create an aggregated code coverage report [1]. This can be used for the mvn site but would also be useful would we at some point want to display the code coverage in Devhub (for example through operias).
Now there's one real downside to this and that is that students learn Maven dependencies the wrong way. They might think having Maven dependencies as a submodule or even git module is required or preferred in some way, which it's not. I think we can work around this by letting them add another Maven dependency themselves in the labwork (upgrade a JUnit version, add Cucumber, etc.).
I would be willing to set up this structure and create a PR, but I first would like to have a small discussion with @avandeursen and the TA's whether or not this would be useful and if these changes would be merged in to the template. We also have to test/debug the support for git submodules in Devhub, as I have seen some issues which might have been related to submodules (https://github.com/devhub-tud/devhub/issues/236).
With IntelliJ, there is the possibility to import extra modules into a project, which gives the possibility of cross module coverage analysis. Using this instead of maven multi-modules for now.
I think this year more students will prefer to use IntelliJ rather than Eclipse. IntelliJ can't load two projects into one workspace, and can't thus display the code coverage across these projects. Last year Martin created the jpacman-mvn-multimodule project for IntelliJ users. I suggest to change his structure slightly, and not have both the jpacman-template and jpacman-framework repositories as git module, but only use git submodules for the core and move the template into a regular Maven submodule within the template repository:
On the student side, not too much will change. They have to initialize the git modules first, which can be done along with the clone operation as a one-liner:
git clone --recursive git://github.com/foo/bar.git
or after clone (git submodules init && git submodules update
). Then the parent project should be imported as a Maven project, which will then work out of the box for both Eclipse and IntelliJ.Another benefit is that we can create an aggregated code coverage report [1]. This can be used for the
mvn site
but would also be useful would we at some point want to display the code coverage in Devhub (for example through operias).Now there's one real downside to this and that is that students learn Maven dependencies the wrong way. They might think having Maven dependencies as a submodule or even git module is required or preferred in some way, which it's not. I think we can work around this by letting them add another Maven dependency themselves in the labwork (upgrade a JUnit version, add Cucumber, etc.).
I would be willing to set up this structure and create a PR, but I first would like to have a small discussion with @avandeursen and the TA's whether or not this would be useful and if these changes would be merged in to the template. We also have to test/debug the support for git submodules in Devhub, as I have seen some issues which might have been related to submodules (https://github.com/devhub-tud/devhub/issues/236).
[1] http://stackoverflow.com/a/18282605/2104280