river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Release 3.0
Date Thu, 03 Sep 2015 17:26:15 GMT
Hi Dennis and others:

Comments intertwined…


> On Sep 3, 2015, at 12:01 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> 
> 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.
> 

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


Mime
View raw message