You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Brian Murphy <bt...@gmail.com> on 2010/03/18 22:31:51 UTC
River jar files in mvnRepository
It appears that someone has uploaded a number of
the River jar & zip files as artifacts to the mvnRepository
site (http://mvnrepository.com/search.html?query=jsk-platform).
That is,
jsk-platform.jar, jsk-lib.jar, jsk-resources.jar
jini-core.jar, jini-ext.jar,
jini-starterkit.zip, jini-start-examples.zip
Thanks to that person/people, by the way.
Although poms corresponding to each of the jar files
that are produced by a river build were created and
checked in to the river repository
(https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk/poms),
it appears that many of the other jar files from the
build were not uploaded. In particular,
start.jar, tools.jar
reggie.jar, reggie-dl.jar
outrigger.jar, outrigger-logstore.jar, outrigger-snaplogstore.jar
mahalo.jar, mahalo-dl.jar
etc.
Was there a reason these other jar artifacts were excluded?
(I'm not a maven user so I admit that I may be unfamiliar
with the conventions of maven and that repository).
If not, is there a mechanism or protocol for getting them included?
[As a side note, for what it's worth, if folks are still using jini-core.jar
and jini-ext.jar, they should consider no longer using those jars;
and use jsk-platform.jar, jsk-resources.jar, and jsk-lib.jar instead.]
Thanks for any help and/or insight regarding this issue,
Brian
Re: River jar files in mvnRepository
Posted by Brian Murphy <bt...@gmail.com>.
On Mon, Mar 22, 2010 at 11:58 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
Brian,
>
> Does JRMP utilise the RMIClassLoader method loadProxyClass(String codebase,
> String[] interfaces, ClassLoader defaultLoader)?
>
> Is the use of rmic redundant?
I think so, but I can't say for sure. Peter Jones would know.
Brian
Re: River jar files in mvnRepository
Posted by Peter Firmstone <ji...@zeus.net.au>.
Brian Murphy wrote:
> On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
> Are you talking about just removing the generation of the stubs
> in the build scripts, or are you talking about the use of JRMP
> for example?
>
> I'm not sure about the usefulness of manually generating
> the stubs.
Brian,
Does JRMP utilise the RMIClassLoader method loadProxyClass(String
codebase, String[] interfaces, ClassLoader defaultLoader)?
Is the use of rmic redundant?
Cheers,
Peter.
Re: River jar files in mvnRepository
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
>>
>> For new users, I think offering a couple of Maven archetypes would be
>> useful,
>
> Agree here, and not just for new users.
One of the predominant concerns for me, is the security of the endpoints so that
rogue services and users on a LAN can not exploit the test environment, as well
as creating separation of legitimate users on the same network. What this
implies to me, is that lookup groups should be employed, and secure jeri with
SSL endpoints using machine generated rsa-2048 certs should be the default.
In a test environment, on the same machine, running out of an IDE, the
configuration of all of this would be under the control of the IDE
build/deployment environment (maven, ant or other build tools can do all the
work so that it's not a "ide dependent" plugin).
Again, creating a simple com.sun.jini.start.ServiceStarter config should be
straight forward, to start all of River. To start selected services, something
more IDE specific would perhaps be needed, or some standard config file that
simply lists which River services you need.
The verbosity of the com.sun.jini.start.ServiceStarter config file is the issue
I think we can deal with super easy. Taking a simple list of services to start
and having the file generated would be a tool to help developers. But then
being able to start ServiceStarter with that config automatically would be icing
on the cake.
I am really interesting in the Groovy config work that Dennis has done with Rio.
The issue of course, is that we'd need to think seriously about only
supporting a Maven environment to help developers pull in Groovy as a dependency
if we chose to use groovy based config (it is an enhancement because it does
make some things easier).
Imagine something simple like the following steps.
// Generate a new certificate file
rsaCert = Utilities.rsaCert( 2048 );
// Get the list of services we want to deploy.
services = new String[] {
"reggie", "mahalo", "javaspaces", "norm" };
// Get the configuration with the cert specified for use
config = Utilities.secureConfig( rsaCert, services );
Utilities.deployRiver( config );
Now this doesn't take into consideration all the customization that might occur,
but it would use AllPermission for anything that connects with that certificate.
Logging configuration is another issue. My http://logman.dev.java.net project
has a Jini service that deploys as a Java LogManager instance using command line
arguments to specify, through properties, how to deploy it. Something like that
might be another thing to include as a "better" River environment for testing.
Just thinking out loud...
Gregg Wonderly
Re: River jar files in mvnRepository
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> It would also be great if River could provide assistance in testing services, making it easy to build & test. IMO, there should be no reason why developers that may want to use River should have to figure out how to bootstrap their test environment. The test harness is part of the project, but how would developers use it as part of their development process?
>
>
It looks like the test harness can take care of setting up the various
services required to simulate the basic environment, it appears the
intent was there for just such a purpose, I could use some help cleaning
it up, your right we need tools to make developing easier.
Re: River jar files in mvnRepository
Posted by Dennis Reedy <de...@gmail.com>.
>
>
> For new users, I think offering a couple of Maven archetypes would be
> useful,
Agree here, and not just for new users.
Over in Rio land I just spent a considerable time & effort to move from an Ant based project to a Maven project, and along the way created a Rio archetype (and other mojos) that provide complete project generation, including service source, test cases and configuration. Basically after running the archetype your service is up and running in moments. If interested you can take a look here http://www.rio-project.org/rio-archetype.html and here http://www.rio-project.org/plugin-intro.html).
It would also be great if River could provide assistance in testing services, making it easy to build & test. IMO, there should be no reason why developers that may want to use River should have to figure out how to bootstrap their test environment. The test harness is part of the project, but how would developers use it as part of their development process?
Regards
Dennis
Re: River jar files in mvnRepository
Posted by Patrick Wright <pd...@gmail.com>.
> Well, we could aim for something far more simple than the JSK? Something
> with real simple exports. I've got a Exporter class somewhere, you only give
> it the component name and the reference to the service implementation and it
> works. I also got a ReggieStarter class lying around, which starts reggie
> from within the program with minimal config. If we provide a global instance
> of a Configuration object that produces a minimal config, would that be
> enough to get people started?
There were lots and lots of efforts at "quick start" (open source)
libraries for Jini, but these were all (to my knowledge) run as
outside projects, often by 1+ persons; none seemed to gather momentum.
I suggest that if we are going to offer a "quick start" we cast the
net far and wide and see what is already available that we can learn
from, and possibly get contributions from.
Personally, I think some practical goals for what could be put into
core would include annotations for declaring services and optional
IOC/DI-based configuration, at least in service definition, in
particular offering a means to use Spring/Guice/JSR 299 for
configuration.
On the client side, I could see value in a simple utility above the
SDM, which builds on the caching already available and allows for
transparent balancing across multiple service instances of a
particular type and/or failover if a service instance disappears or
has problems.
For both service and client, some JMX beans would come in handy for
monitoring the current state of the system.
For new users, I think offering a couple of Maven archetypes would be
useful, as it is a convenient way to define and share a project
skeleton with everything downloaded and installed for new users. The
major Java IDEs all support reading Maven POM files directly, which
_really_ makes it easy to open up and get started with a foreign
codebase.
Interested in where this discussion goes.
Patrick
Re: River jar files in mvnRepository
Posted by Gregg Wonderly <gr...@wonderly.org>.
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> Sim & Gregg had a recent discussion about utilising a Static Factory
>> to help beginners grasp the power and purpose of Jini / River, perhaps
>> someone has an implementation they might like to contribute?
>
> Well, we could aim for something far more simple than the JSK? Something
> with real simple exports. I've got a Exporter class somewhere, you only
> give it the component name and the reference to the service
> implementation and it works. I also got a ReggieStarter class lying
> around, which starts reggie from within the program with minimal config.
> If we provide a global instance of a Configuration object that produces
> a minimal config, would that be enough to get people started?
I think we really should look over com.sun.jini.start.* and in particular the
actions in ServerStarter to see if there is a simpler way to use the package
programatically. It's already fairly painless to create instances of the
various ServiceDescriptor implementation classes and create() running service
instances.
In the past, I've played with some ideas that are visible in the
(http://whatsitdo.dev.java.net project) and elsewhere
(http://startnow.dev.java.net and the PersistentJiniService class) to try and
work on reducing startup time. I have some other things laying around as well.
In the end, what I think is the top issue, is that we have Rio, Seven,
com.sun.jini.start, and many other ways to "launch" services, and none really
have a common base that allows deployment of the same artifacts in all cases.
There is always some type of configuration or deployment control that needs to
be provided. I still think that this is not a "value added issue." I think
that the details of a Jini service are all well described by the same set of
data in all cases, but it's just packaged differently, and that creates a gulf
across which few people can travel.
Gregg Wonderly
Re: River jar files in mvnRepository
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Peter Firmstone wrote:
> Sim & Gregg had a recent discussion about utilising a Static Factory to
> help beginners grasp the power and purpose of Jini / River, perhaps
> someone has an implementation they might like to contribute?
Well, we could aim for something far more simple than the JSK? Something
with real simple exports. I've got a Exporter class somewhere, you only
give it the component name and the reference to the service
implementation and it works. I also got a ReggieStarter class lying
around, which starts reggie from within the program with minimal config.
If we provide a global instance of a Configuration object that produces
a minimal config, would that be enough to get people started?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: River jar files in mvnRepository
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Brian Murphy wrote:
>> On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <ji...@zeus.net.au>
>> wrote:
>>
>>
>>
>>> The old jar's are easily removed, but what about obsolete / duplicate
>>> interfaces, any suggestions?
>>>
>>>
>>
>> I'm not aware of any duplicate interfaces. Could you be more
>> specific?
>>
>
> I don't have any specifics in mind, just posing the question. I was
> hoping there might be a way to reduce the conceptual codebase size a
> developer has to get over to participate in River development.
Actually I'll correct myself here, it isn't the codebase size per say,
it's determining each part and it's purpose, I guess what's really
needed is a good update of our doc's, for the basics of utilising Jini
and the current River implementation, then we could have an advanced
addendum where implementation details and platform issues or corner
cases are discussed, details which are generally only documented on user
list archives and research articles. I did make some recent changes
attempting to dispel some confusion over what constituted the Jini Spec
and the River Implementation. See
http://incubator.apache.org/river/doc/ for our current docs, perhaps we
should create a Jini Architecture Specification Version 2.0? Copy 1.0,
remove all references to using RMI and document the new methods.
Sim & Gregg had a recent discussion about utilising a Static Factory to
help beginners grasp the power and purpose of Jini / River, perhaps
someone has an implementation they might like to contribute?
>
>> I believe there were some deprecated items that were scheduled
>> for removal after the appropriate number of releases had occurred.
>> Don't know what interfaces would be considered obsolete though;
>> such a designation might be more about opinion than functionality
>> or utility.
>>
>> There have been some comments in past threads about the
>> value of services like the lookup discovery service and the
>> lease renewal service; both of which have little usage as far
>> as I know. Some have even questioned the usefulness of the
>> event mailbox service, but for what it's worth, I can tell you that
>> I know of projects/companies that do use that service. So I
>> don't know where the line should be drawn, or what criteria
>> should be applied when deciding when something should be
>> removed.
>>
>> Do we need to continue supporting rmic stubs? Should we remove
>> facilities
>>
>>> for RMI communication other than those utilised through JERI?
>>>
>>>
>>
>> Are you talking about just removing the generation of the stubs
>> in the build scripts, or are you talking about the use of JRMP
>> for example?
>>
>
> I'm not against the use of the JRMP protocol, provided that client and
> the Service
> implementation don't depend on it, so the Service and client can use
> other transport
> protocols also.
> Exporter exp = new JrmpExporter();
>
> Provided only Exporter methods are used, it can be replaced by any
> other Exporter
> implementation.
>
> However I believe we still support (discouraged) applications
> extending UnicastRemoteObject which implicitly exports a proxy and
> require the generation rmic proxy stubs. Having two distinctly
> different mechanisms for Remote proxy object creation for Services
> causes confusion. At a minimum we need to change our docs to reflect
> that.
>
> Seeing that a Service is designed to be an abstraction where service
> implementations can be exchanged, it would be wrong to tie a client to
> an implementation detail of the Service, which is what extending
> UnicastRemoteObject does.
>
> The interface net.jini.core.lookup.ServiceRegistrar has the following
> method:
>
> EventRegistration notify(ServiceTemplate tmpl, int transitions,
> RemoteEventListener listener, MarshalledObject handback, long
> leaseDuration);
>
> Where the MarshalledObject is an instance of java.rmi.MarshalledObject.
>
> Jini has it's own later version of
> net.jini.io.MarshalledInstance
> net.jini.io.MarshalledObject
>
> Where the latter is a convenience class for converting
> java.rmi.MarshalledObject.
>
> This is a little off topic; I've been looking into what's required to
> support Java cdc, namely a minimum of Personal Basis Profile 1.1.2 (a
> subset of J2SE 1.4.2) and while it supports java.rmi.Remote and all
> the exceptions, it doesn't support the server component of rmi and it
> lacks java.rmi.MarshalledObject.
>
> There are a significant number of devices: Amazon Kindle, Blue Ray
> Players, Set top boxes, extending this profile.
>
> Unfortunately interfaces cannot be changed, however there is something
> that can be done:
> A super interface without the offending method inserted into the
> inheritance hierarchy. However what is actually required to support
> cdc is still under investigation.
>
>> I'm not sure about the usefulness of manually generating
>> the stubs.
>
> Are these stubs generated for Clients and Services utilising
> JrmpExporter?
>
> I had a search through the source code I can't see any real dependency
> on using UnicastRemoteObject?
>
>> But if you're talking about removing classes like
>> JrmpExporter and IiopExporter, I'd be very much against that.
>>
>
> No, Exporters are part of Jini 2.
>
>> Brian
>>
>>
> Best Regards & thanks for the reply,
>
> Peter.
>
Re: River jar files in mvnRepository
Posted by Peter Firmstone <ji...@zeus.net.au>.
Brian Murphy wrote:
> On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>
>
>> The old jar's are easily removed, but what about obsolete / duplicate
>> interfaces, any suggestions?
>>
>>
>
> I'm not aware of any duplicate interfaces. Could you be more
> specific?
>
I don't have any specifics in mind, just posing the question. I was
hoping there might be a way to reduce the conceptual codebase size a
developer has to get over to participate in River development.
> I believe there were some deprecated items that were scheduled
> for removal after the appropriate number of releases had occurred.
> Don't know what interfaces would be considered obsolete though;
> such a designation might be more about opinion than functionality
> or utility.
>
> There have been some comments in past threads about the
> value of services like the lookup discovery service and the
> lease renewal service; both of which have little usage as far
> as I know. Some have even questioned the usefulness of the
> event mailbox service, but for what it's worth, I can tell you that
> I know of projects/companies that do use that service. So I
> don't know where the line should be drawn, or what criteria
> should be applied when deciding when something should be
> removed.
>
> Do we need to continue supporting rmic stubs? Should we remove facilities
>
>> for RMI communication other than those utilised through JERI?
>>
>>
>
> Are you talking about just removing the generation of the stubs
> in the build scripts, or are you talking about the use of JRMP
> for example?
>
I'm not against the use of the JRMP protocol, provided that client and
the Service
implementation don't depend on it, so the Service and client can use
other transport
protocols also.
Exporter exp = new JrmpExporter();
Provided only Exporter methods are used, it can be replaced by any other
Exporter
implementation.
However I believe we still support (discouraged) applications extending
UnicastRemoteObject which implicitly exports a proxy and require the
generation rmic proxy stubs.
Having two distinctly different mechanisms for Remote proxy object
creation for Services causes confusion. At a minimum we need to change
our docs to reflect that.
Seeing that a Service is designed to be an abstraction where service
implementations can be exchanged, it would be wrong to tie a client to
an implementation detail of the Service, which is what extending
UnicastRemoteObject does.
The interface net.jini.core.lookup.ServiceRegistrar has the following
method:
EventRegistration notify(ServiceTemplate tmpl, int transitions,
RemoteEventListener listener, MarshalledObject handback, long
leaseDuration);
Where the MarshalledObject is an instance of java.rmi.MarshalledObject.
Jini has it's own later version of
net.jini.io.MarshalledInstance
net.jini.io.MarshalledObject
Where the latter is a convenience class for converting
java.rmi.MarshalledObject.
This is a little off topic; I've been looking into what's required to
support Java cdc, namely a minimum of Personal Basis Profile 1.1.2 (a
subset of J2SE 1.4.2) and while it supports java.rmi.Remote and all the
exceptions, it doesn't support the server component of rmi and it lacks
java.rmi.MarshalledObject.
There are a significant number of devices: Amazon Kindle, Blue Ray
Players, Set top boxes, extending this profile.
Unfortunately interfaces cannot be changed, however there is something
that can be done:
A super interface without the offending method inserted into the
inheritance hierarchy. However what is actually required to support cdc
is still under investigation.
> I'm not sure about the usefulness of manually generating
> the stubs.
Are these stubs generated for Clients and Services utilising JrmpExporter?
I had a search through the source code I can't see any real dependency
on using UnicastRemoteObject?
> But if you're talking about removing classes like
> JrmpExporter and IiopExporter, I'd be very much against that.
>
No, Exporters are part of Jini 2.
> Brian
>
>
Best Regards & thanks for the reply,
Peter.
Re: River jar files in mvnRepository
Posted by Brian Murphy <bt...@gmail.com>.
On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> The old jar's are easily removed, but what about obsolete / duplicate
> interfaces, any suggestions?
>
I'm not aware of any duplicate interfaces. Could you be more
specific?
I believe there were some deprecated items that were scheduled
for removal after the appropriate number of releases had occurred.
Don't know what interfaces would be considered obsolete though;
such a designation might be more about opinion than functionality
or utility.
There have been some comments in past threads about the
value of services like the lookup discovery service and the
lease renewal service; both of which have little usage as far
as I know. Some have even questioned the usefulness of the
event mailbox service, but for what it's worth, I can tell you that
I know of projects/companies that do use that service. So I
don't know where the line should be drawn, or what criteria
should be applied when deciding when something should be
removed.
Do we need to continue supporting rmic stubs? Should we remove facilities
> for RMI communication other than those utilised through JERI?
>
Are you talking about just removing the generation of the stubs
in the build scripts, or are you talking about the use of JRMP
for example?
I'm not sure about the usefulness of manually generating
the stubs. But if you're talking about removing classes like
JrmpExporter and IiopExporter, I'd be very much against that.
Brian
Re: River jar files in mvnRepository
Posted by Peter Firmstone <ji...@zeus.net.au>.
Brian Murphy wrote:
> The organization and packaging model was changed as part of
> the 2.0 release, resulting in the jsk-*.jars. If I recall, there was
> some documentation provided with the release that described
> the details, as well as the motivation for the change.
>
> The intent at the time, was to not force folks to migrate their
> existing apps and scripts until they had had some time to get their
> heads around 2.0; after which, the obsolete/deprecated jars -- such
> as jini-core.jar, jini-ext.jar, and sun-util.jar -- would be removed.
> Unfortunately, various events occurred which either distracted
> or prevented the team from doing so.
>
> Brian
>
>
I've been waiting to pose the question about just what should we be
keeping. Considering our resources, I believe we need to refactor /
clear out any crud going forward.
The old jar's are easily removed, but what about obsolete / duplicate
interfaces, any suggestions?
Do we need to continue supporting rmic stubs? Should we remove
facilities for RMI communication other than those utilised through JERI?
Regards,
Peter.
Re: River jar files in mvnRepository
Posted by Brian Murphy <bt...@gmail.com>.
On Thu, Mar 18, 2010 at 4:54 PM, Jeff Ramsdale <je...@gmail.com>wrote:
Good to hear from you!
>
Back at'cha, Jeff.
>
> I believe these jars were posted several years ago by Chris Sterling
> as part of the Maven Jini Plugin:
Yep. Although the connection wasn't obvious at first,
I discovered this fact right after I sent the original message.
> I posted a Jira issue for exactly this issue:
> http://issues.apache.org/jira/browse/RIVER-317 and as a result someone
> posted the poms I provided to svn but no process was put into place to
> apply those poms to the artifacts and deploy them to the Central
> Repository.
Yeah, I remember that. I was hoping that in addition to posting
the poms, the jars had been deployed as well.
Oh well. I guess I'll install the jars I need in the local repository
until this is sorted out.
> I was going to raise the issue again after the current
> vote completed. Meanwhile, Dennis Reedy had some very reasonable
> comments about the poms I posted. A little more discussion is probably
> warranted prior to releasing the artifacts as Maven artifacts. Dennis
> has some experience now with using Jini jars and Maven with the latest
> Rio builds. Perhaps he'll reiterate his suggestions to the list? I'd
> be glad to help out but we'll need someone on the inside to assist in
> getting things deployed once we work out the pom details.
>
Okay. Sounds good.
> By the way, mvnrepository.com is an ad site that scrapes the real
> Maven Central Repository. Helpful for searches, perhaps, but not
> definitive. The real repo is at http://repo1.maven.org/maven2/ and can
> be searched via http://repository.sonatype.org.
>
Thanks for the info. Although the search interface provided by the
add site was actually fairly nice, a more definitive search would be
preferable.
that's an interesting point about jini-core and jini-ext. Are
> these still artifacts of the build?
I believe they still are (a quick scan of the top-level build.xml
shows targets for each).
The organization and packaging model was changed as part of
the 2.0 release, resulting in the jsk-*.jars. If I recall, there was
some documentation provided with the release that described
the details, as well as the motivation for the change.
The intent at the time, was to not force folks to migrate their
existing apps and scripts until they had had some time to get their
heads around 2.0; after which, the obsolete/deprecated jars -- such
as jini-core.jar, jini-ext.jar, and sun-util.jar -- would be removed.
Unfortunately, various events occurred which either distracted
or prevented the team from doing so.
Brian
Re: River jar files in mvnRepository
Posted by Jeff Ramsdale <je...@gmail.com>.
Hi Brian, Good to hear from you!
I believe these jars were posted several years ago by Chris Sterling
as part of the Maven Jini Plugin:
https://maven-jini-plugin.dev.java.net/ At the time things were
different in both the Maven and Jini worlds--a little more
free-for-all in posting artifacts to Maven and no one in the Jini
world thinking too much about Maven. I think it would be better for
Apache River to manage its own artifacts now (and I don't think Chris
plans to maintain the plugin).
I posted a Jira issue for exactly this issue:
http://issues.apache.org/jira/browse/RIVER-317 and as a result someone
posted the poms I provided to svn but no process was put into place to
apply those poms to the artifacts and deploy them to the Central
Repository. I was going to raise the issue again after the current
vote completed. Meanwhile, Dennis Reedy had some very reasonable
comments about the poms I posted. A little more discussion is probably
warranted prior to releasing the artifacts as Maven artifacts. Dennis
has some experience now with using Jini jars and Maven with the latest
Rio builds. Perhaps he'll reiterate his suggestions to the list? I'd
be glad to help out but we'll need someone on the inside to assist in
getting things deployed once we work out the pom details.
By the way, mvnrepository.com is an ad site that scrapes the real
Maven Central Repository. Helpful for searches, perhaps, but not
definitive. The real repo is at http://repo1.maven.org/maven2/ and can
be searched via http://repository.sonatype.org.
Finally, the service jars (reggie, outrigger, etc.) are under the
services dir (https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk/poms/services/)
but that's an interesting point about jini-core and jini-ext. Are
these still artifacts of the build?
-jeff
On Thu, Mar 18, 2010 at 2:31 PM, Brian Murphy <bt...@gmail.com> wrote:
> It appears that someone has uploaded a number of
> the River jar & zip files as artifacts to the mvnRepository
> site (http://mvnrepository.com/search.html?query=jsk-platform).
> That is,
>
> jsk-platform.jar, jsk-lib.jar, jsk-resources.jar
> jini-core.jar, jini-ext.jar,
> jini-starterkit.zip, jini-start-examples.zip
>
> Thanks to that person/people, by the way.
>
> Although poms corresponding to each of the jar files
> that are produced by a river build were created and
> checked in to the river repository
> (https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk/poms),
> it appears that many of the other jar files from the
> build were not uploaded. In particular,
>
> start.jar, tools.jar
> reggie.jar, reggie-dl.jar
> outrigger.jar, outrigger-logstore.jar, outrigger-snaplogstore.jar
> mahalo.jar, mahalo-dl.jar
> etc.
>
> Was there a reason these other jar artifacts were excluded?
> (I'm not a maven user so I admit that I may be unfamiliar
> with the conventions of maven and that repository).
>
> If not, is there a mechanism or protocol for getting them included?
>
> [As a side note, for what it's worth, if folks are still using jini-core.jar
> and jini-ext.jar, they should consider no longer using those jars;
> and use jsk-platform.jar, jsk-resources.jar, and jsk-lib.jar instead.]
>
> Thanks for any help and/or insight regarding this issue,
> Brian
>