river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Release 3.0
Date Thu, 03 Sep 2015 16:01:09 GMT
Hi Greg,

Some comments inlined below.

> On Sep 3, 2015, at 1046AM, Greg Trasuk <trasukg@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

> 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.



View raw message