river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: Release 3.0
Date Thu, 03 Sep 2015 14:51:41 GMT
+1 on a short path to a 3.0 release.   Everything else can go into a
backlog for 3.1+.


Bryan Thompson
Chief Scientist & Founder
4501 Tower Road
Greensboro, NC 27410
http://blog.bigdata.com <http://bigdata.com>

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Thu, Sep 3, 2015 at 10:46 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:

> > On Sep 3, 2015, at 3:43 AM, Peter <jini@zeus.net.au> wrote:
> >
> > +1 for putting it in the net.jini.config API namespace, the DSL lives in
> net.jini.config.
> Arguably, the important thing, the thing that really _should_ be in
> net.jini.config, is the Configuration interface., bakes that forms part of
> the API that one uses to create services.  If the Configuration interface
> changed, the code to start up any service would immediately break.
> The ConfigurationFile implementation is in there because it’s in there.
> Developers never see the ConfigurationFile class if they’re using the
> Configuration interface and the ConfigurationProvider correctly.
> >  This is a good thing, we should consider deprecating the DSL in favour
> of Groovy.
> >
> Really?  We should force Java developers to learn a new programming
> language so they can configure their system?
> I do not understand your logic in saying “we should consider deprecating
> the DSL in favour of Groovy”.  Nor your logic.  I’m not saying the
> Java-like Configuration DSL is wonderful, but surely a Groovy-based DSL vs
> a Java-based DSL is purely a matter of taste.
> > There's no standards body for Jini standardization, we need to be able
> to manage and evolve our API sensibly,
> This is my point, lest you think I’m just “resisting progress”.  Sensibly
> is the key word.  We, the Apache River project, inherited the Jini
> Specification, but then we very purposefully drew a line around it, saying
> “This is a point of reference for when people write services”.  We adopted
> the policy that changes to the specification need to be discussed and voted
> on, because those changes affect users of the tool set.  Changes to the
> Jini API cross a line of demarcation where _we_ decided, long ago, that “we
> really need to talk about it”.  That’s why I’m challenging  cavalier
> statements like “we should consider deprecating the DSL in favour of
> Groovy”.
> The demarcation point of the specification should serve as a reminder that
> we’re writing this thing in order to let people create service-oriented
> architectures.  We need to consider the users.
> > locking out progress would lead to paralysis and inevitable obsolesence.
> >
> > The Groovy configuration is far superior to the DSL in many ways,
> Please specify.
> > leaving it as an implementation detail, discourages usage.
> >
> Here is my real  point when I suggest that GroovyConfiguration might be
> best separated out into a separate project.  We could structure a project,
> discuss it, vote on a release and have it into Maven Central by the end of
> next week.  So users of River could have an easy way to use a
> GroovyConfiguration pretty much RIGHT NOW (I realize they can use it now,
> but it would be easier if they had a jar file with the right provider api
> hooks) instead of having it when they get around to adopting River 3.0,
> which will be after we get around to releasing River 3.0.
> When I have, in the past, talked about “navel gazing”, this is what I
> mean.  Here we are, arguing over whether the existing configuration DSL
> should be entirely replaced, and what the right package is, when we could
> have created a separate deliverable and had it done by now, if only we were
> willing to use the actual extension mechanism that’s built into the
> existing product rather than talk about changing the public API!
> When I argue against messing around with the JTSK, it’s because delivering
> useful functionality to users in small increments will be faster than
> making any changes to that behemoth.  No matter how you slice it, the
> larger the deliverable, the longer things take, especially if we’re doing
> our due diligence correctly and considering the downstream impact.  Believe
> it or not, when I show a bias against touching the JTSK I am promoting a
> bias towards action.
> Pardon my venting.  It’s because I have used Jini in real applications and
> truly, truly think it’s a technology that we should be promoting, so
> anything that gets in the way of ACTUALLY SHIPPING SOMETHING kind of gets
> under my skin.  I’ll stop now.
> Cheers,
> Greg Trasuk
> > 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
> >>
> >>
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message