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
