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 Wed, 02 Sep 2015 19:04:49 GMT

> On Sep 2, 2015, at 2:45 PM, Dennis Reedy <dennis.reedy@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 <trasukg@stratuscom.com> wrote:
>> 
>> 
>>> On Sep 2, 2015, at 1:36 PM, Dennis Reedy <dennis.reedy@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 <trasukg@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.reedy@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 <trasukg@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.reedy@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 <jini@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<jini@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?


Mime
View raw message