[ https://issues.apache.org/jira/browse/PROTON-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464985#comment-13464985 ]
Rafael H. Schloming commented on PROTON-35: ------------------------------------------- I agree with Hiram on the C front. In fact I think, given the project goals, that building C with maven is really a non starter from *both* the proton-j and proton-c angle. In the C world Maven is definitely not considered idomatic, and there are many places the C implementation will need to reach where a Java build dependency would be a blocker (e.g. linux kernel). In the Java world I can't imagine a Maven build with a C dependency would be the most popular thing either. Given that we want maximum adoption, reach, and ubiquity on both fronts, I think it would be very counter productive to try to build C with maven or Java with cmake. Regarding the patch, I think there are a few points from IRC worth bringing up here. As I understand it the motivation of this has to do with maven's ability to automatically perform release management tasks, i.e. it needs to be in a particular place in the SVN tree hierarchy relative to where the "trunk" part is. That said it's a bit of a kludge given that the top level directory is really composed of independent components, e.g. proton-j, proton-c, and the tests directory can all be checked out and used standalone which is I think important for the idomaticness/adoption of each sub portion. I'm also concerned that from the perspective of the people navigating the directory looking for the C code (or the javascript code when that arrives) that a top level pom.xml would be a big misdirection. Are there other options here we could consider that would make maven happy? Hiram pointed out on IRC that moving the trunk up a level would facilitate independent releases of proton-j and proton-c and would eliminate the desire for this extra pom.xml since the source tree would match maven's conventions, however I'm not sure we're ready to say whether or not we're doing independent releases yet and I don't particularly relish the idea of moving everything around, and if we are going to move stuff I'd rather go to git anyways. Would a git repo change the situation at all since we would not be forced to choose the point at which we put the giant trunk in the middle of our directory path, or would maven's conventions still balk at multiple independent builds sharing a single repo? > Convert to a maven multi-module build > ------------------------------------- > > Key: PROTON-35 > URL: https://issues.apache.org/jira/browse/PROTON-35 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j > Reporter: Hiram Chirino > Priority: Minor > Attachments: PROTON-35.patch > > > Having a multi-module build just means having a pom.xml at the root of the > project. This way it will be easier to add additional optional modules in > the future and setup CI builds of the java bits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira