Mailing-List: contact river-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Message-ID: <27934067.92021295560846202.JavaMail.jira@thor>
Date: Thu, 20 Jan 2011 17:00:46 -0500 (EST)
From: "Dennis Reedy (JIRA)" <jira@apache.org>
To: river-commits@incubator.apache.org
Subject: [jira] Commented: (RIVER-300) introduce maven to the river build
 process
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/RIVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984429#action_12984429 ] 

Dennis Reedy commented on RIVER-300:
------------------------------------

Peter,

(Side note: this format is getting hard to reference previous comments).

> When you say  the public API of services; interfaces and classes common to clients, services and proxy's These would be > the platform services in this case.

I think this is the current jsk-lib.jar (and inclusively jsk-dl.jar).

I think I see where you are going (still not sure), but perhaps this may help:

The jsk-dl.jar (in this work effort river-dl) could really be re-named river-api (or river-client). These are the classes a client requires to use services.

I dont think we need both river-dl and river-api (or river-client), they serve both the same purposes.

The river-lib (depends on river-dl(or river-api/river-client pick one), gets those classes naturally through its dependency resolution and classpath.

The change here is that river-api must be in the classpath of river-lib, it is no longer optional (as jsk-dl.jar was optioal in the classpath of jsk-lib.jar)

> 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.