[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983744#action_12983744
]
Tom Hobbs commented on RIVER-300:
---------------------------------
I don't think that the package rename was a step to far. The only issue with
merging the two tasks is making this live is now a much larger issue with
regards to River users. The next release after River-300 makes it into the
trunk will obviously contain some pretty serious changes as far as they're
concerned.
The next steps seem sensible. Choosing Gradle or Maven should probably be #1,
unless you're happing bringing them both along at the same time and deferring
the decision? I've never had a good experience trying to force Maven to do
something it doesn't want to do, so maybe dropping that in favour of Gradle
would be easier all round? Can something built with Gradle still publish
artifacts to Maven repos?
Tasks 2 and 3 could probably be done in either order or concurrently. I'm
particularly interested to see how how the QA and JTReg tests will behave and
can be segregated.
> introduce maven to the river build process
> ------------------------------------------
>
> Key: RIVER-300
> URL: https://issues.apache.org/jira/browse/RIVER-300
> Project: River
> Issue Type: Improvement
> Components: build
> Reporter: Jools Enticknap
> Attachments: apache-river-gradle.zip, apache-river-maven.zip,
> river-modularization-overview.odt, river-modularization-overview.pdf
>
>
> Currently the river build using ant, but it's a custom build process and has
> many hang overs from the original make build.
> Given that the project has no 3rd party dependencies, it would be very easy
> to break the code up into modules.
> Please feel free to add to this JIRA if you have any opinions on how the
> maven repository should be setup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
