> On Sep 3, 2015, at 3:43 AM, Peter <j...@zeus.net.au> wrote: > > +1 for putting it in the net.jini.config API namespace, the DSL lives in > net.jini.config.
Arguably, the important thing, the thing that really _should_ be in net.jini.config, is the Configuration interface., bakes that forms part of the API that one uses to create services. If the Configuration interface changed, the code to start up any service would immediately break. The ConfigurationFile implementation is in there because it’s in there. Developers never see the ConfigurationFile class if they’re using the Configuration interface and the ConfigurationProvider correctly. > This is a good thing, we should consider deprecating the DSL in favour of > Groovy. > Really? We should force Java developers to learn a new programming language so they can configure their system? I do not understand your logic in saying “we should consider deprecating the DSL in favour of Groovy”. Nor your logic. I’m not saying the Java-like Configuration DSL is wonderful, but surely a Groovy-based DSL vs a Java-based DSL is purely a matter of taste. > There's no standards body for Jini standardization, we need to be able to > manage and evolve our API sensibly, This is my point, lest you think I’m just “resisting progress”. Sensibly is the key word. We, the Apache River project, inherited the Jini Specification, but then we very purposefully drew a line around it, saying “This is a point of reference for when people write services”. We adopted the policy that changes to the specification need to be discussed and voted on, because those changes affect users of the tool set. Changes to the Jini API cross a line of demarcation where _we_ decided, long ago, that “we really need to talk about it”. That’s why I’m challenging cavalier statements like “we should consider deprecating the DSL in favour of Groovy”. The demarcation point of the specification should serve as a reminder that we’re writing this thing in order to let people create service-oriented architectures. We need to consider the users. > locking out progress would lead to paralysis and inevitable obsolesence. > > The Groovy configuration is far superior to the DSL in many ways, Please specify. > leaving it as an implementation detail, discourages usage. > Here is my real point when I suggest that GroovyConfiguration might be best separated out into a separate project. We could structure a project, discuss it, vote on a release and have it into Maven Central by the end of next week. So users of River could have an easy way to use a GroovyConfiguration pretty much RIGHT NOW (I realize they can use it now, but it would be easier if they had a jar file with the right provider api hooks) instead of having it when they get around to adopting River 3.0, which will be after we get around to releasing River 3.0. When I have, in the past, talked about “navel gazing”, this is what I mean. Here we are, arguing over whether the existing configuration DSL should be entirely replaced, and what the right package is, when we could have created a separate deliverable and had it done by now, if only we were willing to use the actual extension mechanism that’s built into the existing product rather than talk about changing the public API! When I argue against messing around with the JTSK, it’s because delivering useful functionality to users in small increments will be faster than making any changes to that behemoth. No matter how you slice it, the larger the deliverable, the longer things take, especially if we’re doing our due diligence correctly and considering the downstream impact. Believe it or not, when I show a bias against touching the JTSK I am promoting a bias towards action. Pardon my venting. It’s because I have used Jini in real applications and truly, truly think it’s a technology that we should be promoting, so anything that gets in the way of ACTUALLY SHIPPING SOMETHING kind of gets under my skin. I’ll stop now. Cheers, Greg Trasuk > Peter. > > > On 3/09/2015 5:17 AM, Dennis Reedy wrote: >>> On Sep 2, 2015, at 304PM, Greg Trasuk<tras...@stratuscom.com> wrote: >>> >>> >>>> On Sep 2, 2015, at 2:45 PM, Dennis Reedy<dennis.re...@gmail.com> wrote: >>>> >>>> Hi Greg, >>>> >>>> I am quite aware of the purpose of the net.jini namespace :) The >>>> GroovyConfig class follows net.jini.config.ConfigurationFile packaging. >>>> Building groovy-config.jar follows the current approach of external jars >>>> (dependent jars) relies on the dep-libs/groovy/groovy-all2.3.8.jar. The >>>> only time you’ll have a Groovy runtime dependency is when you add >>>> groovy-config.jar to your classpath. Furthermore, the groovy-config.pom >>>> declared a dependency on groovy-all so you’ll get groovy resolved >>>> transitively when using dependency management. >>>> >>> OK, I’m just trying to avoid entanglements in the build. We keep talking >>> about wanting to modularize and simplify the build, so it seems odd to be >>> adding more stuff into the JTSK core rather than spinning stuff out of it. >>> But as I said, I don’t have a strong opinion. >> I was just following the lead of net.jini.config.ConfigurationFile. If >> others feel strongly about this, I’ll move it into org.apache.river.config. >> If thats the case, then ConfigurationFile should move as well? Otherwise >> lets keep it in net.jini.config >> >>> I do have a strong opinion about the use of dep-libs. I don’t like it. I >>> don’t like it at all. We need to deal with getting jar files out of the >>> source release. I don’t think we have any business archiving and >>> distributing someone else’s artifacts, even if the license does allow it. >>> I do know that Apache policy is that releases are source code only. I >>> tried to introduce Ivy a while ago and got slapped down, so I’ll let >>> someone else figure out how to separate the stuff out and then distribute >>> the deps separately. >> I tend to agree with the dep-libs, but it’s what we have now. Do you want to >> make this a pre-requisite to the 3.0 release? I have a small window to help >> getting 3.0 in shape to be a release candidate, if we all agree to adding >> Ivy (yuck, but its a step towards dependency management), I could try and >> fit that in - that is as long as all the dep-libs are resolvable from >> central. >> >> Simplest case; for a source release we can exclude dep-libs. If someone >> wants to build they can svn checkout a branch. >> >> >>>> Also, took a look at your mods to deploy_river.groovy, no problem that you >>>> needed to use gpg:sign-and-deploy-file, but curious as to why you chose to >>>> put the command to execute in a list instead of use the string as before? >>>> >>> I don’t remember, it was a while ago. I seem to recall that I had to >>> change it to get it to work. Probably something about escaping the >>> characters to keep Maven happy, but I don’t recall exactly. Feel free to >>> change it if it makes more sense. >> No problem, it’s a utility, if that makes it work, fine with me. Was just >> curious. >> >> Thanks >> >> Dennis >> >> >
