[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984757#action_12984757
]
Dennis Reedy commented on RIVER-300:
------------------------------------
I dont see any reason to keep service-ui.jar in the mix as an additional
artifact. The service UI work seems to fit in very nicely with the intent and
purpose of jsk-dl (river-dl), breaking it out into it's own module seems
overkill IMO.
I would like to move ahead and change:
river-dl -> river-api
I think keeping river-lib as-is for now makes the most amount of sense. With
this approach,
river-lib -- depends-on --> river-api
Clients that want to use the service interfaces in river-api need only to
include river-api in their classpath as a direct dependency. Consider if they
want to simply discover a JavaSpace today, clients need to include (at least)
jsk-dl.jar in their classpath (most likely clients include jsk-lib in their
classpath).
> 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.
