Hi Dennis and others: Comments intertwined…
> On Sep 3, 2015, at 12:01 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > > 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. > I’m with you on this >> >>> 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. > I think we’re in agreement. Perhaps our confusion is because I haven’t fully explained what I mean by “separate deliverable”. I should probably create a separate thread to talk about “projects and deliverables” and how they relate to repositories. The gist of what I’m getting at is that a “release” shouldn’t be a big thing. Right now, we “release” River, and it generates 10 or so artifacts. Problem is, a good change to a single artifact requires us to consider the impact on every other aspect of the project. We need to reduce that coupling (given, of course, that there is always some artifacts really do have natural coupling). > 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. Yep, that’s it in a nutshell. So if someone says “Here’s a patch that speeds up lookups”, we can go ahead and consider it in isolation, and release it quickly. And people could build the part they’re interested in working on, without having to understand the existing complicated build structure. > >> >> 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. > Totally agree with you. Except instead of making the JTSK more approachable to developers, I argue for making Jini technology more approachable. One of the big points I’d like people to take from the river-examples work is that you absolutely do not need to download or build the JTSK in order to use Jini/River. >> >> 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). > Yeah, you misconstrued my point; my fault - I guess I wasn’t clear enough. I actually REALLY LIKE the idea of getting Groovy configuration out there in a ‘groovy-config.jar’ that you can just drop into your classpath, or call it out in your dependency list in Maven or Gradle. I’m trying point out that since the Configuration system already has the extension mechanism of the META-INF entries, and GroovyConfiguration doesn’t depend on anything that isn’t in the public API, there’s no need to tie it into releasing River 3.0. > 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? > See above - I’d like to get improvements to the user experience out there as quickly as possible. Tying them to the process of releasing the JTSK can only slow things down. > 3. Is it the dep-libs approach? I would also love to change this BTW. I do dislike deps-lib. > > 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. > I’m pretty sure we agree here, Dennis. I don’t want to give the impression that I think this is a big issue. > 5. Do you ant any of the above put up for a vote? Not at the present time. > > Lets figure this out and get this done. > > > Regards > > Dennis > > > > >
