+1 for putting it in the net.jini.config API namespace, the DSL lives in
net.jini.config. This is a good thing, we should consider deprecating
the DSL in favour of Groovy.
There's no standards body for Jini standardisation, we need to be able
to manage and evolve our API sensibly, locking out progress would lead
to paralysis and inevitable obsolesence.
The Groovy configuration is far superior to the DSL in many ways,
leaving it as an implementation detail, discourages usage.
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
