> 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
