Hi Greg, Some comments inlined below.
> On Sep 3, 2015, at 1046AM, Greg Trasuk <tras...@stratuscom.com> 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. Well, it needs to be in jsk-platform.jar is the important thing. If we choose to make implementations of the Configuration interface go to org.apache.river thats fine. Lets just be consistent. > >> 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? You dont have to learn a new language. Groovy is just an extension of Java. You can certainly learn some of the new idioms and approaches that Groovy provides, or just use straight Java. For that matter, learning some of Java 8’s new features is similar to learning some of the Groovy idioms. I dont think it’s a stretch at all for Java developers to use a Groovy based configuration approach, at least it hasn’t been for so far. Lastly, the current configuration approach requires learning. You have Java syntax, but no behavior. You cannot provide logic, just invocations to static methods. I have found that this has always been a stumbling block for those that have to learn how to configure Jini services. The common reaction I have heard is; “What is this? Is it Java?” The answer is, well kind-of sort of, but no. > > 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. No, its functionality. You cannot provide logic with the current approach, you can with Groovy. > >> 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. > And how exactly are we not doing this? > > >> 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. Well you can use GroovyConfig right now, just add rio-platform.jar to your startup classpath :) I am considering your point wrt creating a separate project, I warming up to it, but I would really rather see River split into a multi-module project instead of splintering off multiple repositories/projects that can be used with the River platform. I see the Groovy configuration implementation as part of the River platform, not an external project. If multiple repositories/projects is the intent/direction then we can define River core, then create stand-alone repositories/projects that depend on River core. Move out Outrigger, Mahalo, Norm, etc … Is that what you’d like to see? Different projects that can be added to core River? Just curious. Would certainly allow things to move at different velocity. > > 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! The public API is not changing at all. > > 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. The JTSK is actually a misnomer, I see little starting point with the Jini Technology Starter Kit. I for one, sincerely hope we mess around with the JTSK to make it more approachable to developers. > > 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. I hope I have misconstrued your point here, and I realize this is a vent, but with all due respect Greg, you seem to imply that we have not, or do not currently use Jini in real applications. I hope you realize this somewhat misguided at best, and that we are all trying to make River more applicable and work in real applications. The reasons why contributions like GroovyConfig (and others) have been introduced is because they are used in real-world applications, make configuration easier (and more easy to understand). IMO, we are trying very hard to actually ship something. I realize you have some issues with whats going on, and from recent discussions, I have gleaned the following: 1. Is it that the Groovy configuration approach has not been put into a separate project although the Groovy configuration implementation (2 classes) has been part of the project for 6 years? 2. Is it that small modifications to the project build (in qa-refactor-namespace branch) have been made to create a groovy-config.jar that allows developers/deployers to use the Groovy configuration capability? 3. Is it the dep-libs approach? I would also love to change this BTW. 4. Is it the package for net.jini.config.GroovyConfig and net.jini.config.Component? This is easily solvable, as I had indicated previously if this is an issue I have no qualms moving it. I just think we should be consistent in that all implementations of net.jini.config.Configuration should be done the same way. 5. Do you ant any of the above put up for a vote? Lets figure this out and get this done. Regards Dennis
