Mavenize the build process - Phase 1: building the native code via Maven#582
Mavenize the build process - Phase 1: building the native code via Maven#582lgoldstein wants to merge 1 commit intojava-native-access:masterfrom
Conversation
lgoldstein
force-pushed
the
maven-phase1-native
branch
from
eaebd4e to
1c06e26
Compare
|
The component can be easily tested by: cd native |
|
Could you please point at a good example of an "ideal" maven build for reference? |
|
I don't know what "ideal" means, but IMO the current ANT script used to build the project is quite complex. There is a lot of "code" that Maven does better and in a more concise way. In addition to this, ultimately we want to publish the artifacts as Maven ones - therefore, using Maven to build the project seems more natural. Furthermore, the dependencies that we need (e.g., junit) are easier to manage via Maven instead of having to keep them checked in Git. As far as a Maven reference - see Apache Mina SSHD (which is also maintained by me...) |
|
I vote for maven, however I don't think we should merge maven changes until they replace at last a big part of the build process AND simplify it. I mean I wouldn't put to on master until we rely on it to build. |
|
As I have previously stated, I believe Maven-izing the whole project all at once is a big undertaking involving a lot (!) of changes, so doing it all at once seems very lengthy and cumbersome. This is especially true since due to the duration it may take until a stable Maven build is likely to be very long (I cannot devote 100% of my time to it...) and keeping up with the frequent changes in the master is going to be very difficult. That is why I prefer doing it in (very) small steps that we can test separately - like Lego building blockx - where at the end we will tie together all these small blocks into the big construction. Meanwhile, we keep using the ANT build until we are reasonably sure that Maven can take over. That is why these changes should reside in the master even though they are not currently being used, so that they evolve alongside the other changes. |
There was a problem hiding this comment.
minor: Might want to remove this comment. I'm guessing it was copy/paste from parent pom.
lgoldstein
force-pushed
the
maven-phase1-native
branch
from
1c06e26 to
32baafd
Compare
|
Fixed all indicated remarks and re-pushed |
There was a problem hiding this comment.
I don't think these ant dependencies are needed because they are not used as dependencies. Further down, they are declared as deps of a plugin in <plugin-mgt> section, which should suffice.
4 participants
My goal is to eventually execute the build process using only Maven (with some help from the antrun plugin). However, Maven-izing the whole project at once is a complex and daunting task. This why, I would like to tackle it in phases, where each phase will add another Maven "conversion" of the full build process until we can achieve a full build and release cycle using only Maven. For the time being, ANT will continue to be the build framework until this goal is reached, and (as you will note) the Maven build artifacts reside under the target sub-folder, whereas the ANT ones reside under the build one. This way, we can keep the "parallel" builds without interfering with one another until we are ready to switch to the Maven one.