|
Feature #1 of this issue could be introduced iteratively. Here is a possible progression:
1) Provide the ability to deploy an oar via an http uri. For instance, the CLI could support a command such as: 'rio deploy http://repo2.maven.org/maven2/org/apache/river/services/outrigger/outrigger-2.1.1.oar 2) Provide the ability to deploy an oar via Maven groupId/artifactId/version semantics. For instance, the CLI could support a command such as: 'rio deploy org.apache.river.services:outrigger:2.1.1' in which the oar packaging is assumed as is the use of the Maven Central Repository (http://repo2.maven.org/maven2 3) Provide the ability to configure additional repositories, whether in the Rio installation itself (for the CLI, or, possibly, the UI) or in the UI as a persisted preference. 4) Use the Nexus indexing standard to locally cache indexes for remote repositories and provide interactive assistance to the user. For instance, a user could type a portion of a deploy command (once in an interactive Rio session, for instance) and benefit from Unix-style tab completion for matching artifacts with a packaging of "oar." In the same fashion, the Rio UI could provided a filtered tree view (much like m2eclipse does in Eclipse when resolving Maven dependencies) displaying eligible oar artifacts from known repositories. None of the suggestions above change how Rio packages or provisions services, only how it obtains an oar to be provisioned. -jeff Including the Maven Rio plugin and using it to build Rio is something that I have just started to do. Syncing Rio artfacts with the central repository is also something that is planned. If you could get the River community stuff handled that would be great though.
What I am working on is creating a multi module project that has the following modules:
boot
Thoughts? The products of each of these modules will produce corresponding jars. The rio-core module produces rio-core-${pom.version}.jar rio-core-dl-${pom.version}.jar. This changes from the current build that produces rio.jar and rio-dl.jar What should be done with the current bin, config and system directories? Are these the product of an assembly that gets created? Overall it looks fine, though I'm not familiar enough with the Rio code to know exactly what goes in each. Just to clarify, in addition to these directories you'll have a parent pom that resides in the root directory as well as a pom in "services" with a packaging type of "pom". Each of the directories above would contain a pom with packaging of "jar."
Could you explain what the system directory is for? I think config, at least, would be placed somewhere under a src dir for the root project. That is, as a peer of these jar dirs there would be a src dir with subdirs. The parent project wraps the others, so it would seem appropriate to house these dirs and their contents in the parent. As discussed on the list (or perhaps Jira), I have come to believe that config files should reside in src/main/resources, unless there were a change to the oar standard to place them in META-INF. I've been poking around Infinispan lately, and their repository resembles where you're going: http://anonsvn.jboss.org/repos/infinispan/trunk/ One issue that comes up, though, is how (if) one can run Rio in place without building a full distribution. That probably merits some discussion. |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Provide better integration with Maven
1) Promote the Maven Rio Plugin to first-class citizen status within Rio. That is, treat it the same as the rest of the code with respect to e-mail lists, the source code, Jira, etc., as well as publishing its Maven-generated website. (Meanwhile, I have a patch I'd like to offer that reduces a lot of code duplication and makes the code more maintainable.)
) This may require coordinating with the Apache River community to get their artifacts posted, but I inquired about this earlier this summer and received a positive response.
2) Sync Rio artifacts to the Maven Central Repository (see: http://maven.apache.org/guides/mini/guide-central-repository-upload.html
3) Use the Maven Rio Plugin to build services provided by Rio. This would include the Lookup Service the Provision Monitor, and Cybernode, as I understand things. (How about Compute Resource and Webster--are they considered services?)
While step 3 could be considered optional it supports the (reasonable, I think) goal of "eating one's own dogfood." Additionally, any lessons learned in converting these services to a Maven-based build could lead to improvements to the Maven Rio Plugin and Rio's potential support of Maven in general.
-jeff