Sorry for the late response, but the point about the Extension Repo making
this a moot point is an important one.
The idea that you need to get your processor into the main codebase to have
it be known and useful is something
that is easier to overcome than a language war.
On February 13, 2018
I completely second Mike's sentiment here as well as cautionary
statements by other contributors over this thread's history (Matt
Burgess' post in particular). Besides fueling flame wars and religious
inquisition, you cannot open the door to Scala without opening it to
other (JVM languages at
Milan,
I don't think you can do that without creating a lot of fuel for a flame
war. I have personally never met a Scala developer who was incapable of
writing decent Java. The same is true of Groovy. I think anyone who finds
the requirement to use Java over their language of choice to be a deal
I think we should not add blindly any language but should be open to add couple
of language like Scala.
In Bigdata world Scala/Python/Java are widely accepted.
Thanks,
Milan Das
Interset
On 2/13/18, 10:20 AM, "Weiss, Adam" wrote:
I think it makes the most
I think it makes the most sense to me for us to publish a separate repo with a
module and nar build for now and post when it's available in the users group.
Thanks for the discussion everyone, hopefully we can start making some helpful
contributions soon.
-Adam
On 2018/02/10 23:43:31, Tony
It is like Matt read my mind.
On Sat, Feb 10, 2018 at 6:26 PM, Matt Burgess wrote:
> I'm fine with a vote, but I'll be voting to keep Java as the single
> language for the (non-test) code. I share the same concerns as many of
> the other folks as far as accepting other
I'm fine with a vote, but I'll be voting to keep Java as the single
language for the (non-test) code. I share the same concerns as many of
the other folks as far as accepting other languages, it's mainly the
"slippery slope" argument that I don't want to turn into a
JVM-language flame war. If
Wasn't there a warning trigger about the NiFi distro size from Apache
recently? IMO, before talking alternative languages, solve the modularity
and NAR distribution problem. I think the implementation of a module won't
matter much then, the point being not everything has to go in the core,
base
This probably necessitates a vote, yeah?
Frankly, I’m usually happier writing Scala, and I’ve not encountered any
problems using processors written in Scala, but I think it’ll be important to
tread lightly.
There’s a few things that pop into my head:
- Maintainability and reviewability. A
I agree more with Andy about sticking with Java. The more varying languages
used, the more challenging it is to maintain. Once the code is part of the
Apache NiFi git repo, it is now the responsibility of the committers and
PMC members to maintain it.
I’d even say I am somewhat against the
+1 to Joe's response. If you can develop a component in Groovy or Scala
(or Clojure!) more quickly/comfortably, or if allowing components written
in other languages would encourage people to contribute more, I'm all for
it.
On Sat, Feb 10, 2018 at 7:42 AM Joe Witt wrote:
>
i personally would be ok with it for an extension/processor provided it
integrates well with the build.
i would agree with andys view for core framework stuff but for extensions i
think we can do it like mikethomsen suggested.
others?
thanks
joe
On Feb 10, 2018 7:30 AM, "Mike Thomsen"
I'm just a community contributor, so take that FWIW, but a compromise might
be to publish the Scala code as separate maven modules to maven central and
then submit a thoroughly tested processor written in Java. As long as you
have enough unit and integration tests to give strong coverage, I
Hi Adam,
It’s great that your team wants to contribute to NiFi. I think there should be
some discussion from other community members on this, but I’ll give my view
here. At this time, I believe we should only accept core contributions in Java.
It’s not because I have a predisposition against
Devs,
I have some interns starting with my team and we use Scala internally for our
work.
If I wanted to have them work to contribute some new processors, would they
have to be Java to be included with the base distribution or could they use
Scala as long as it fit within your current build
15 matches
Mail list logo