river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Release 3.0
Date Thu, 03 Sep 2015 07:43:50 GMT
+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<trasukg@stratuscom.com>  wrote:
>>
>>
>>> 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 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
>
>


Mime
View raw message