eclipse
Build January as a "pure" Maven project
To ease contribution and more easily manage builds we are considering changing January's build system from Maven+Tycho to "pure" Maven. This eases development of features such as #144 and opens up January for contribution from anyone more easily.
This discussion started on january-dev, the conclusions will be added here in due course.
Here's a detailed report of setting up a January development environment in IntelliJ IDEA community edition, starting from the January master state of April 16th.
I'm on a Windows 10 with a 1.8 JDK.
The result of what I've been trying is on the branch https://github.com/erwindl0/january/tree/erwin/enh/165/january-maven-non-eclipse for your review. Just let me know if/how you want to work with it or not!
Steps done to figure things out :
- fork to erwindl0 & clone locally
- create a branch
- Open Project... from root january folder (i.e. the cloned repo)
- let IntelliJ run a bit, importing stuff, loading plugins/deps etc (what is this?)
- projects visible but : 5.1 src folders not recognized, nothing is done in a build 5.2 when no src level is set, default 1.5 seems to be assumed (was also the case in Netbeans).
- Set a build>sourceDirectory>src in o.e.j.releng POM
- sources are recognized now, build errors because of 1.5 language level assumption and missing dependencies
- set Java level 7 in IntelliJ => does not create this in POM (contrary to Netbeans)! Just sets this in the .iml metadata file!
- add maven.compiler.source and ...target 1.7 properties in that o.e.j.releng POM
- add dependencymanagement section in o.e.j.releng POM for all 3rd party deps
- add dependencies in all the module poms (without version info, as that is then inherited from the dep-mgmt spec)
- examples & test projects have issues with level 1.7 (generic cast syntax with type token in method calls as described before) => set compiler props in POM + IJ module settings to 1.8
- finally, set tycho target config to pomDependencies = consider and remove target file from the spec
- try the mvn tycho build
- error from inside slf4j api : manifest has a dep on org.slf4j.impl 1.6.0 but this is not in their poms!
- add a hard dep on slf4j-simple 1.7.10 in o.e.j.releng POM
- then an error for Junit : the 4.12 taken from Maven Central is not an OSGi bundle, so does not export its packages etc. This causes errors when building e.g. the o.e.j.asserts project => we can not just build with maven deps from Maven Central
- Replace references to org.junit bundle by org.apache.servicemix.bundles.junit (to try out the other stuff, can not be kept like that!)
- Then there's a strange error for the releng.p2 Resolving step : stating that the o.e.j bundle can not be resolved as it can not find the o.a.c.lang bundle. Although the individual resolving of the o.e.j works fine, and the commons-lang 2.6 artifact in my local repo is a correct bundle !?!?
- Remove the releng.p2 module from the build and retry
- build works upto the examples project, where the tycho surefire fails as it apparently needs org.eclipse.osgi (which is not in the official/mvn standard dependencies)
- give up on getting the Tycho build working with only maven deps. So rollback 13, 16 and 18.
- now everything works well in IntelliJ and for a mvn clean install build.
Conclusion :
- let's keep a normal target platform for Tycho, next to the maven deps (so e.g. use std junit>junit in plain maven deps, Tycho will get the Junit bundle from Orbit anyway)
- risk : a January consumer project may fetch deps from maven central that are not osgi bundles! So if the consumer project is an OSGi application that is not using a Tycho build with Orbit p2 repo for its target contents, this may lead to issues I guess???
Erwin, thanks for the detailed analysis. I have had a look at your fork and we will definitely want to pull some of that across.
a January consumer project may fetch deps from maven central that are not osgi bundles!
That is a very good point and an interesting problem. It sounds like I will need some more complete "post-install" tests to ensure everything continues to work. i.e. test running with and without OSGi that everything is pulled together OK.