I think there is a lot of merit in this idea. Creating a standard ".jsd" that described where to put which files (and therefore, which files are needed) would make River service creation and deployment much simpler.
One of my frustrations is the sprinkling of different discrete files and bits and bobs that are all required to start up a service. Of course, once you're used to what is needed it becomes second nature, but developing that second nature is a pain. As is troubleshooting when your second natures lets you down! However, defining an archive file structure that describes everything you need - and presumably ant tasks and the maven equivalents, to generate and start/stop these things - will make life a whole lot easier. Where I work, we have a concept of a grouping of services which can all be started together, often in the same JVM. Any given host can run multiple "service groups". We developed our own directory structure which describes where everything goes, new "service groups" then use a template of that directory structure. The problem with this, though, is that the scripts are all OS specific and need constant configuring and maintaining. Also, hand rolling a "service group" directory is error prone (although made simpler with some Bash magic). If I understand Gregg (do I?) developing a way to package a service or services could be left to some, River supplied, automated tool. Starting them then becomes a simple process of; $ java com.sun.jini.start.ServiceStarter MyService.jsd Or something. I also like the idea of making a mechanism of dropping these ".jsd" files into other container environments. Dare I say "OSGi"? And have them handle the starting/stopping of them. River is great in that you can do a whole heap of really clever and amazing things with it. But speaking as an "app developer" who just wants to write services that will live solely within his own companies secure and safe subnet, River/Jini can be an absolute pain. Again, if I understand it right, these ".jsd" files would take away much of that pain. Right? Great idea, Gregg. In my opinion, this is well worth a Jira of its own and some serious thought/effort put into it. Cheers, Tom -----Original Message----- From: Gregg Wonderly [mailto:[email protected]] Sent: 01 October 2009 20:08 To: [email protected] Subject: Re: Maven Artefacts RIVER-317 - AR2 Release Dennis Reedy wrote: > Hi Gregg, > > To a certain extent I think having an archive would make sense, but as > it relates to Maven created service artifacts I am not so sure. I am not trying to focus this issue on solving anything related to maven. Instead, I am trying to discover what people think about creating an archive structure that could then be used for service deployment into various environments. Clearly, we could provide an archive assembler that used maven for managing the content of what was placed in the archive. The generation of the archive is one issue. But, on the other end is the consumption, and that's where I'd like to initially focus the discussion. I think that if we feel like it is something that the containers and deployment environments could use, and benefit from, than we can talk about providing such archives as a maven component from the river build. I'd like to discuss deployment issues regarding packaging, managing various pieces of a service deployment in particular environments, and solutions people have put together to see if there really is a place for such a thing, or if I'm just barking up the wrong tree. Gregg Wonderly www.sucdenfinancial.com Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ Telephone +44 203 207 5000 Registered in England no. 1095841 VAT registration no. GB 446 9061 33 Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239 This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify [email protected] immediately and delete it from your computer system. We believe, but do not warrant, that this email and its attachments are virus-free, but you should check. Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email. The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment. This message has been scanned for viruses by Mimecast.
