> 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 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. > 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. Cheers, Greg Trasuk > Thanks > > Dennis > > >> On Sep 2, 2015, at 205PM, Greg Trasuk <tras...@stratuscom.com> wrote: >> >> >>> On Sep 2, 2015, at 1:36 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: >>> >>> Hi Greg, >>> >>> Okay, gotcha, makes sense. I did however add the necessary trappings to the >>> build so the groovy classes get compiled and put into groovy-config.jar. >>> One proviso though, I am moving org.apache.rover.config.Component to >>> net.jini.config.Component since net.jini.config.GroovyConfig requires it. >>> >> >> I wonder if maybe it should be the other way around? Does GroovyConfig have >> to be in net.jini.config? The >> net.jini namespace is supposed to be for “specification” classes and API. >> If you’re using the groovy-config.jar approach, the user doesn’t need to >> instantiate GroovyConfig, because it will be done automatically by >> ConfigProvider through the plugin mechanism. So GroovyConfig is sort of an >> implementation class - is there any need for the user’s app to have coupling >> to the name and package? Would it make sense for groovy-config to have a >> package all to itself, maybe ‘org.apache.river.config.groovy'? (I don’t have >> a strong opinion, except for a general reluctance to add to the public API >> if it isn’t absolutely necessary). That would be the cleanest thing if we >> were going to do it as a stand-alone release. Also that avoids any >> undefined dependency on the Groovy runtime in the core JTSK jars. >> >> >>> Lastly, are you using the poms/ directory and the deploy_river.groovy >>> utility to publish River artifacts, or are you using something different? >>> I’d like to create a groovy-config.pom in the correct place so it gets >>> published as well. As an aside, I’ll put together an install_river.groovy >>> script to install to local repository for testing if anyone is interested. >>> >> >> Yes, when I did the releases from the 2.2 branch, it is using the >> deploy_river.groovy script and the poms/ directory. I think I’ve edited the >> script though, so you might want to have a look at it. >> >> Cheers, >> >> Greg Trasuk >> >>> Thanks >>> >>> Dennis >>> >>>> On Sep 2, 2015, at 1111AM, Greg Trasuk <tras...@stratuscom.com> wrote: >>>> >>>> >>>> Hi Dennis: >>>> >>>> I realize that it’s already in the trunk, and in the 2.2.x release branch. >>>> But there isn’t anything in there to create a “groovy-config.jar”. I’m >>>> suggesting that we take it out of the JTSK 2.2 trunk tree (which is going >>>> to become 3.0, isn’t it?) and put it into a separate >>>> “releasable”/“Deliverable” unit, much like river-examples. It seems like >>>> useful functionality no matter which version of River someone’s using. If >>>> it isn’t inherently coupled to the code in the trunk, why couple the >>>> release lifecycle to River 2.2 or 3.0? >>>> >>>> But, if you think it’s easier and quicker to add the jar file creation to >>>> 3.0 and get it into Maven Central through that release, then by all means >>>> go for it! >>>> >>>> Cheers, >>>> >>>> Greg Trasuk >>>> >>>> >>>>> On Sep 2, 2015, at 10:41 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: >>>>> >>>>> >>>>> Hi Greg, >>>>> >>>>> The source has already been contributed to River, it has been in the >>>>> project for quite some time (it’s in 2.2 trunk). There was an issue >>>>> created back in 2009 (https://issues.apache.org/jira/browse/RIVER-313) >>>>> that resulted in me donating the requisite support, all we need to do now >>>>> (6 years later), is to create a jar that provides the contributed support. >>>>> >>>>> Dennis >>>>> >>>>>> On Sep 2, 2015, at 1023AM, Greg Trasuk <tras...@stratuscom.com> wrote: >>>>>> >>>>>> >>>>>> Hi Dennis: >>>>>> >>>>>> It might be easier to do a separate deliverable for the Groovy config. >>>>>> That way you could use Gradle or Maven to build it rather than try to >>>>>> munge it into the JTSK’s build system. As you said, in the end you want >>>>>> to have groovy-config.jar with the correct META-INF/…Configuration >>>>>> entry. Long as it ends up in Maven Central, all you need to do if you >>>>>> want the Groovy config is reference the artifact in your build. >>>>>> >>>>>> So, the way to proceed is >>>>>> 1 - Create a Jira issue to get a river-groovy-config git repository setup >>>>>> 2 - Put the right files in that repository >>>>>> 3 - Call a release vote. >>>>>> >>>>>> Is there any reason for it to be tied into River 3.0? I think all the >>>>>> Configuration and ConfigurationFile classes are in net.jini.*, so you >>>>>> could go ahead and release now. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Greg Trasuk >>>>>> >>>>>>> On Sep 2, 2015, at 10:13 AM, Dennis Reedy <dennis.re...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Peter, >>>>>>> >>>>>>> I’d like to enable the option of having Groovy configurations files >>>>>>> with River for 3.0, but I’ve noticed that although the >>>>>>> net.jini.config.GroovyConfig.groovy is part of the project it is not >>>>>>> included in any of the produced jars. Do we have groovy >>>>>>> cross-compilations setup? >>>>>>> >>>>>>> The net.jini.config.Component annotation (used with GroovyConfig) is >>>>>>> part of the extras.jar, should that be there? Perhaps we should create >>>>>>> a groovy-config.jar that has a >>>>>>> META-INF/services/net.jini.config.Configuration with an entry of >>>>>>> net.jini.config.GroovyConfig. That way those that want to use the >>>>>>> Groovy configuration need only to add that jar after jsk-platform.jar. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Dennis >>>>>>> >>>>>>>> On Sep 2, 2015, at 901AM, Peter <j...@zeus.net.au> wrote: >>>>>>>> >>>>>>>> Thanks Dennis. >>>>>>>> >>>>>>>> On 2/09/2015 10:58 PM, Dennis Reedy wrote: >>>>>>>>> Peter, >>>>>>>>> >>>>>>>>> Should be all set now, just pushed the missing sources and resources. >>>>>>>>> >>>>>>>>> Dennis >>>>>>>>> >>>>>>>>>> On Sep 2, 2015, at 357AM, Peter<j...@zeus.net.au> wrote: >>>>>>>>>> >>>>>>>>>> Just performed a clean check out, but the build failed. >>>>>>>>>> >>>>>>>>>> There seems to be a number of packages missing from the spec test in >>>>>>>>>> the qa suite?
