[
https://issues.apache.org/jira/browse/PROTON-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
