Thanks Jonathan, anything you can do is much appreciated.
Cheers,
Peter.
Jonathan Costers wrote:
I was working on the maven artifacts a while ago, and have that work still
available in my (outdated) workspace.
When I find some time (difficult lately) I'll contribute what I have.
I remember I was able to build Maven artifacts for just about any River JAR.
I have raised the same concern earlier.
The Class-Path mechanism conflicts with a number of things, including Maven
...
Similarly, I was working on integrating that piece of code into the River
codebase before.
However there was some problem with it. I'll (again) dig into my workspace
and get more details.
3) To what degree would a further restructuring of the code be of
interest? I don't necessarily have specific ideas here (yet), but it
seems like we're finally free to begin to move things around in a way
that would serve the project's goals and it would be good to have the
conversation first.
Is it going to make the codebase easier to maintain? If your talking about
making the platform more modular, eg, each platform service could be it's
own subproject or something like that, provided we can provide a migration
path for existing Jini 2.1 users then that has to be a plus. I've thought
about this sort of modularisation and for those not wanting to do separate
downloads for components, we can distribute a complete zip artifact. I
think if your considering ease of development and improving the application
development experience then I'm all for it. I think net.jini.* has to be
evolved with backward compatibility in mind, however com.sun.* is your
oyster.
Completely agree. Some form of restructuring/modularization has been
preformed already, but there is certainly room for more of the same.
