fyi, don’t know if is related or not, but I ran into a recent issue where some modules (metadata sharing, registration app) no longer compile using Java 6. I added a comment to RA-954 with my findings.
I had assumed that we would build only openmrs core with Java 8, and we
would continue building reference application modules with Java 6 as long
as we are still supporting the current platform versions of openmrs.
What is a specific example where we are building a module with Java 6 and
it won’t run on platform 2.0?
Trying to build uiframework (Java 1.6) against OpenMRS 2.0 (Java 1.8) fails when the module tries to compile against Concept.
It seems the class layout versions Java 1.6 - ver 50 and Java 1.8 - ver 52 are incompatible.
I suspect cross java builds will also have problems with any code relying on reflection if nothing else.
Test building with Java 1.7 has the following results:
as @mogoodrich indicates most classes build but classes using reflection fail.
Generally speaking I would prefer that we try to do special-case hacks for
these things (e.g. use reflection, the @OpenmrsProfile annotation, and
dynamic bean definitions) but keep building the module with Java 6.
Just to be clear, we currently are NOT taking that approach, @darius. As RA-954 gets made to each module, I need to start building it with Java 7 instead of Java 6. So seemed like we need to put the brakes on / have a design call if you feel strongly about this. (Unfortunately, I haven’t been following the issue closely to understand the underlying issues, nor do I know if we are breaking running the modules with Java 6).
Some guidance is still needed on this topic in order to continue work RA-954 and child tickets…
Though some of the problems identified earlier in this thread was due to a wrong approach in building modules for platform 2.0, there has to be a decision on how best to approach this problem in general.
Is it the consensus that we should keep one trunk for all branches, build against java 1.6 and use conditional compilation (and reflection) to handle API changes, or do we want to branch out for various module versions to support different platform versions?
I don’t know enough about the issues to know if there is a generally
applicable answer to this, or if it needs to be done on a case by case
basis per module.
But my baseline expectation would be that most of the refapp-included
modules continue being primarily built against platform 1.x, as long as we
are supporting platform 1.x release lines, and that their platform-2.x
components are added in a maven submodule.
I would generally expect that whoever is updating a module to work with
platform 2.0 should chat with the module owner about how they want to
approach it. If that has already happened, or if module owners don’t
actually want to have this level of input, then I don’t want to slow things
Is there an illustrative example of a module that has already been updated,
and this update is not huge, so we can start discussion from a real example?
A few months back the old classes still existed but were deprecated. At that time I addressed the backwards compatibility issue by refactoring the Spring bean definitions and adding a a set of old-style templates. Looks like possibly someone has removed the deprecated classes already? One option to avoid lots of 2.0-specific builds would be going through a deprecation cycle.
Also in this particular case I thought the new classes had been backported to previous core versions. In which case the modules could simply be updated to build against the backported classes, no need to create a 2.0-specific build?