[
https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Reedy updated RIVER-300:
-------------------------------
Comment: was deleted
(was: The organization of the project is structured as follows:
apache-river \
|- river-libs (*)
|- river-dl
|- river-lib
|- river-services (*) \
|- reggie (*) \
|- reggie-proxy
|- reggie-service
|- outrigger (*) \
|- outrigger-proxy
|- outrigger-service
|- river-platform
|- river-start
At this time, each module produces one artifact (the directories with a '*' do
not produce artifacts, they are used for source code organization). The
produced name of the artifact is the same as the name of the module, with the
addition of the version number of the project.
Going forward we may find that we need to provide additional processing options
in river-platform to produce equivalent jsk-resources and jsk-policy.jar
artifacts.
All Java source code is located in accepted standard locations
src/main/java
Groovy source would similarly be located in
src/main/groovy
All test code for each module is encouraged to be located in
src/test/java
As for determining what classes go in what module, the approach is simply to
look at what classes are in what jar file and organize the modules accordingly.
Key to the modularization was to remove reliance on classdepandjar.
It should be simple to see how additional services can be added to this
structure by following the convention of:
<service> \
| - <service>-proxy
| - <service>-service
More information on the convention used for this project can be found here:
http://www.rio-project.org/conventions.html
Building
--------
If using Maven, well, you use Maven. If you are not familiar with Maven you
want to start here
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Running either
> mvn install
Or
> mvn package
The distribution is placed into
dist/target/apache-river-2.2-SNAPSHOT
If using Gradle,
> gradle build
> gradle -q dist
The distribution is placed into
distribution/
The produced jars for either distribution are as follows:
lib/
outrigger-service-2.2-SNAPSHOT.jar
outrigger-snaplogstore-2.2-SNAPSHOT.jar
reggie-service-2.2-SNAPSHOT.jar
river-lib-2.2-SNAPSHOT.jar
river-platform-2.2-SNAPSHOT.jar
river-start-2.2-SNAPSHOT.jar
lib-dl/
-------
outrigger-proxy-2.2-SNAPSHOT.jar
reggie-proxy-2.2-SNAPSHOT.jar
river-dl-2.2-SNAPSHOT.jar
The produced archives also have converted the com.sun.jini namespace to the
org.apache.river namespace.
Testing
-------
Right now there are no testcases included in the contributions. Ideally, we
would move forward with adding testcases to each constituent module. That way
as each module is assembled, it will run through it's testcases in an automated
fashion.
The current testing framework can be easily added to the existing build setup
in the same way as it's run today, perhaps tied to a specific lifecycle using
Maven), or to a specific task (using Gradle). The latter may be more accepted
since Gradle has strong Ant ties and semantics.)
> 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
>
>
> 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.
