Bennett, Timothy (JIS - Applications) wrote:
For *trivial* tasks like compiling code and building jar artifacts, Maven2 is quite enough mature to proceed with current code base. Maven2 is still in the alpha-beta phase at this point (I believe) mainly because there is still a host of Maven1 plugins that still need converted to Maven2, and maybe some of the more sophisticated project management facilities are still being tweaked.
For me, this was more an issue of letting things settle down a little bit. Everything is so fluid right now that it seems like we'd be chasing our tails.
The current Felix code base has a *very* simple Ant build file, and replicating this functionality using the current Maven2 is no big deal.
Of course, I trivialized the Ant build file when I put it in the repo. Oscar has a less trivial, but ugly build file.
I am not adamantly against using an isomorphic "simple" Maven build file right now. I just don't really want to try to decide the entire project Maven build file right now.
I am more than willing to check out a new simple build file if you send it to me and tell me what I have to do to use it...keeping in mind that I have never used Maven before. :-)
The Ant build file currently compiles all the code as one unit, then jars up three libs (moduleloader.jar, osgi.jar, and felix.jar) and three bundles (bundlerepository.jar, shell.jar, and shellui.jar). The questions I have is do we think these sets of artifacts still make sense, or do we want to consider organizing the same code into different artifacts. That is, do we consider pulling out the interfaces into one or more api jars that we can version separately from the implementations of those interfaces?
This current structure wasn't an attempt at a "real" structure, just getting the stuff into the repo and making it buildable.
With the latest discussions of the repo reorg, I would fully expect the bundles to eventually move into the bundle area.
As a quick *mavenization* test, I attempted to use maven to separately build the three lib artifacts, but it is clear that re-organization is likely because there are circular dependencies with the three current libs -- that is code in osgi.jar depends on code in felix.jar, and code in felix.jar depends on code in osgi.jar. If we want to decouple aspects of the *core* framework code in order to separate concerns, then we are going to have to tackle how we want to organize the code base from an artifact build and dependency perspective. The fact that we have circular dependencies between at least two of the lib jars is indication enough to me that we at least have a little work to do in code/project organization realm. The extent of that work depends on how far down the SoC path we feel is important.
You have to expect dependencies from felix.jar to osgi.jar. The reverse dependencies are a little more tricky and ugly. The ugly part is that I just grabbed the R4 sources from Eclipse since they are under EPL so that we would have them to compile against until the official R4 release comes out which will also be under EPL; Eclipse has dependencies back into their framework, so I just hacked them to get them to compile with Felix. The tricky part is that we will probably want these circular dependencies too, because this is done for optimization purposes.
In the end, mavenization can't proceed until these questions are resolved, not because the maven2 code base is sitting at an alpha/beta state instead of a final state.
To me it is more of an issue of do we need the "perfect" project structure NOW to proceed or can we move forward with the project structure slowly. Clearly, everyone agrees that the current structure is inadequate for the long run. I am concerned with the short run. Heck, the ink is barely dry on the name change. :-)
Flame away...
Awww, it wasn't that bad, was it? ;-) -> richard
