You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2014/04/10 05:33:47 UTC
Health of the Apache River Project
Hi all:
I thought I’d get a jump on preparing the board report for next month, so I started looking at how the River project is doing.
If you were to get a list of the commits to River’s svn repository in the past year or so (svn log http://svn.apache.org/repos/asf/river -v -l200), you’d see the following
- Looks like the only people committing in that time were gtrasuk (me), peter_firmstone, jcosters, sijkes, and dreedy
- Most of my commits (gtrasuk) were against the 2.2 branch in preparation for releases and associated documentation, and against the river-container skunk branch, working on the River Container.
- jcosters prepared a skunk project in support of RIVER-427.
- Peter has been working on the qa_refactor branch.
- sisjkes added to a project on the skunk branch called ‘SimpleJeri’
- dreedy added the fix to Levels.java to the 2.2 branch (which gtrasuk later merged over to the qa_refactor branch). Also copied pom files over to the qa_refactor branch.
A while ago, I requested help on the River Container, and was asked to move it outside the project to GitHub.
Around the same time, Dennis offered to contribute the Rio project’s code, and then because of community reaction, withdrew the offer.
So, assuming that Dennis and I now do most of our work outside River, the project is left with pretty much only one active committer.
New users seem to have a difficult time adopting River for applications. I’ve already stated my opinion on why, and I was asked to remove my proposed solution from River.
We haven’t added to the committers or PMC in several years.
As a result of scaring off users, I don’t think we have any potential committers “in the pipeline”. There are a few “old Jini guys” kicking around, but personally I’ve hesitated to suggest adding them as committers, because anytime we talk about Jini, the newer folks ask us to not make this a code museum.
Although we have had some interesting discussions on the mailing list, and suggestions for additional features in River (like object-oriented codebase annotations), I haven’t seen a lot of suggestions that are (in my opinion) “user-oriented” and will help drive adoption (although I agree that the apparent concurrency/JMM issues need to be addressed).
I continue to believe that the Jini networking approach is a valuable and usable approach to building service oriented architectures in Java. Nonetheless, this doesn’t look like a healthy project. Does anyone have any opinions on what we can do to move it forward, or is it time for the attic? And if the River project is dead, what does that mean for Rio, Blitz JavaSpaces, and other projects that build on top of River? Are they active? What happens if River is dead?
By the way, Apache doesn’t see PMC chairs as project leaders, so my role is to facilitate discussion and ask hard questions, not set the project’s direction. Having said that, if people feel I should be doing something different as PMC chair, I’m willing to try anything, or even step aside if that will improve things.
Best regards,
Greg Trasuk,
PMC Chair, Apache River.
Re: Health of the Apache River Project
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 10/04/2014 10:42 PM, Rafał Krupiński wrote:
> Dnia 2014-04-10, czw o godzinie 22:15 +1000, Peter Firmstone pisze:
>> Rafał,
>>
>> If you're considering a new git hub project, I'd reccommend using the
>> qa_refactor branch, it contains a significant number of bug fixes.
>> ClassLoader and URI string handling perform very well also.
> I'm only willing to start it if it's to be incorporated by the
> "community" (I guess that would be Greg ;) and officially released at
> some point, and I don't see a consensus on whether to replace current
> development tree with qa_refactor.
No, my plans are to continue fixing bugs for now, then I'll leave the
build for the River community to decide.
Dennis Reedy created a Maven build for river in skunk.
> I was going to test our project with qa_refactor anyway. Is it a drop-in
> replacement for 2.2.2?
Sure is, far fewer bugs and will completely blow away any other build
performance wise, it's basically now limited by Java socket speed, so
the next step would be to use faster network communications like UDT.
You won't see any contention, but beware, it will expose concurrency
bugs in your software.
Regards,
Peter.
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-10, czw o godzinie 22:15 +1000, Peter Firmstone pisze:
> Rafał,
>
> If you're considering a new git hub project, I'd reccommend using the
> qa_refactor branch, it contains a significant number of bug fixes.
> ClassLoader and URI string handling perform very well also.
I'm only willing to start it if it's to be incorporated by the
"community" (I guess that would be Greg ;) and officially released at
some point, and I don't see a consensus on whether to replace current
development tree with qa_refactor.
I was going to test our project with qa_refactor anyway. Is it a drop-in
replacement for 2.2.2?
Regards
Rafał
Re: Health of the Apache River Project
Posted by Peter Firmstone <ji...@zeus.net.au>.
Rafał,
If you're considering a new git hub project, I'd reccommend using the
qa_refactor branch, it contains a significant number of bug fixes.
ClassLoader and URI string handling perform very well also.
Regards,
Peter.
On 10/04/2014 7:17 PM, Rafał Krupiński wrote:
> Dnia 2014-04-09, śro o godzinie 23:33 -0400, Greg Trasuk pisze:
>> Hi all:
> Hi Greg,
>
> Now I feel bad for not contributing my extensions to River, that I have
> implemented for SORCER (nb open source on github).
>
> We have our own ServiceStarter, historically based on River's and I
> think I could contribute some patches based on that..
> I also have some preliminary work on downloadable URLStreamHandlers, and
> I'd be happy to contribute it to River once it's done.
>
> The only problem is, I don't know anything about River's build process,
> ant scripts, classanddepjar tuning and @Betas. It would be much easier
> for me to contribute if River was mavenized. There was a discussion on
> that, but it's dead now and I don't see that materializing into code
> (maybe I don't know where to look).
>
> Maybe the problem is that I wait for others to do the work instead of
> doing it? Shall I start a new github project for mavenized river and
> initiate the migration?
>
> Regards
> Rafał
>
Re: Health of the Apache River Project
Posted by Michał Kłeczek <mi...@xpro.biz>.
To be honest - I would prefer River being mavenized.
But I understand it would be a huge effort and the benefits are disputable.
I found working with existing build easy - just imported the project into
Eclipse - had to set up some library paths etc. Ant build works fine.
The only issue is that there is no automatic "mvn install" support - so there
is a problem if you want to test your changes locally using some maven based
services.
There is only a script that deploys jars to Maven Central.
The fix is to - instead of relying on the script - modify the poms to use Maven
build-helper plugin and let Maven handle "install" and "deploy".
I would share this patch some time ago. But here we get to another problem
with River community (IMHO). I've got an impression new committers are not
welcome
Sending patches is a PITA. And I cannot work on my own branch in SVN (since I
am not a committer). Various proposals were commented along the lines of "do
your own project at github" - it does not really make new people FEEL welcome.
My advice to River community would be - make new committers welcome - let them
work on their ideas, make them feel comfortable and - possibly - merge their
work. At this moment my impression is that contributions, new ideas, changes
etc. are actually rejected. So the project is stalled.
Thanks,
Michal
On Thursday 10 of April 2014 20:15:33 Rafał Krupiński wrote:
> Dnia 2014-04-10, czw o godzinie 12:21 -0400, Greg Trasuk pisze:
> > Patches welcome! And new committers needed.
>
> (...)
>
> > People have commented that the build system and the source code structure
> > is difficult to understand, and prevents them from participating in the
> > development. I understand that, but I also think that when we start to
> > talk about changing the build system, there’s a couple of incorrect
> > assumptions at work.
> >
> > First, we need to realize that the build system is there to produce
> > artifacts. In the case of the current releases, these artifacts are, in
> > fact, published to Maven Central. So although River isn’t built using
> > Maven, it is certainly compatible with Maven. A downstream project can
> > use any build system that can access Maven Central’s repository. That at
> > least covers Grails, Ivy, and Maven, and probably others.
> >
> > Second, at the current time, River releases one source package that
> > includes everything that River delivers, and so right now, everything
> > River releases is built using the archaic (but working!) River build
> > system.
> I think you missed the point.
>
> I'm already a user, and I'm perfectly happy with the current build
> system. In fact I couldn't care less about the build system.
> Provided I remain a user.
>
> But becoming a contributor, or even a committer is entirely another
> matter. I don't understand the project structure and I don't want to
> touch those ant scripts, especially classanddepjar task, with a stick,
> let alone modify it.
>
> (...)
>
> > Having said that, I wouldn’t jump in and “Mavenize River”. Why would we
> > need to take on such a huge job, if the current build system works (ugly
> > though it is)?
> From my perspective, as long River is built this way, "Patches (not)
> welcome!".
--
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
Re: Health of the Apache River Project
Posted by Gregg Wonderly <gr...@wonderly.org>.
I’d like to understand what the issue is with building using ANT?
Is it that you can’t “build and run” in your IDE that supports Maven? What is the real issue here?
Years ago, I altered the ant build, slightly, to work in my local environment due to some path/tool location issues as I recall. But, since that time, I’ve just been able to build using ANT. It runs for a while if there are lots of changes, but not so long for a small number of changes.
How will moving to Maven “reduce” the build time, or uncomplicated the build process if the same artifacts come out of the build that are built at this time?
I’m trying to understand the overall issue, not be harsh or pushing back on change.
Gregg Wonderly
On Apr 10, 2014, at 1:40 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> Hi Rafal:
>
>
> On Apr 10, 2014, at 2:15 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
>>
>> I think you missed the point.
>>
>
> Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it. And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system.
>
> On the other hand, if you’re looking at contributing something that will end up being in a different jar file (like I think you mentioned downloadable URLStream handlers), then ignore the current build system and create a new module with whatever build system and integration tests you like. We’ll create a new git repository for it, and release it as a separate module that a River user could add to their class path. It’s still a part of the River project, and users of River will greatly appreciate it.
>
>
>> I'm already a user, and I'm perfectly happy with the current build
>> system. In fact I couldn't care less about the build system.
>> Provided I remain a user.
>>
>> But becoming a contributor, or even a committer is entirely another
>> matter. I don't understand the project structure and I don't want to
>> touch those ant scripts, especially classanddepjar task, with a stick,
>> let alone modify it.
>>
>
> Don’t get me wrong - I’m not defending the current project structure. I completely agree that I don’t want to touch the existing scripts either. But that doesn’t have to get in the way of contributing. If you’re adding new features, you don’t have to plug into the existing project.
>
>
> Cheers,
> Greg Trasuk
Re: Health of the Apache River Project
Posted by Peter <ji...@zeus.net.au>.
I'm relatively tool agnostic, as long as we eventually arrive at a replacement solution for classdep.
For the ant folks, there's Ivy for dependency resolution, Maven or Gradle are also capable of performing the same job.
Dennis Reedy has shown how the build structure can be broken up into modules that mirror the current jar file build result, while remaining build tool agnostic.
The work performed by Gregg and Sim on ClassLoading is an important step. Which reminds me, it's probably about time I merged this work in qa-refactor.
Regards,
Peter.
----- Original message -----
> Dnia 2014-04-12, sob o godzinie 20:15 -0500, Gregg Wonderly pisze:
> > There are very few things about River’s “jars” that are cast in stone.
>
> Everything is cast in stone for me until I can understand the project
> structure.
>
> Part of the problem is that whole River *source* comes in one big bucket
> of spaghetti. It's difficult to see where the classes go without
> checking build.xml. Then we have the classenddepjar: one class goes to
> multiple jars and might end up in classloaders with different
> classpaths. It's hard to maintain its configuration, actually it has to
> be "tuned" to achieve desired result. How do I know I don't get CNFE on
> some untested path in production? These problems don't exist in todays
> projects.
>
> Without source structure reflecting modules and clear dependencies it's
> really hard to see the big picture. I can't see the boundaries of the
> modules, nor how do they interact without first reading all of it.
>
> > I know that it is “work” to create a build system if you need
> > something different than what something comes distributed with. But,
> > that’s the question here. If the build system is keeping people from
> > contributing, then why isn’t there a “github” distribution of the
> > appropriate tooling that everyone can try and see how much better it
> > is?
>
> Every build based on Ant is custom while the majority of projects built
> with Maven is purely standard.
>
> > I am one of those developers who will only waste/spend so much time
> > fighting with something before I either throw it away, or roll my own
> > so that I know what is going on and don’t waste my time with lack of
> > transparency that keeps me from understanding how my software is
> > actually working.
>
> It may be good for you, but what happens with potential contributors, if
> only the author can understand it?
>
> Regards
> Rafał
>
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-12, sob o godzinie 20:15 -0500, Gregg Wonderly pisze:
> There are very few things about River’s “jars” that are cast in stone.
Everything is cast in stone for me until I can understand the project structure.
Part of the problem is that whole River *source* comes in one big bucket of spaghetti. It's difficult to see where the classes go without checking build.xml.
Then we have the classenddepjar: one class goes to multiple jars and might end up in classloaders with different classpaths. It's hard to maintain its configuration, actually it has to be "tuned" to achieve desired result.
How do I know I don't get CNFE on some untested path in production? These problems don't exist in todays projects.
Without source structure reflecting modules and clear dependencies it's really hard to see the big picture. I can't see the boundaries of the modules, nor how do they interact without first reading all of it.
> I know that it is “work” to create a build system if you need something different than what something comes distributed with. But, that’s the question here. If the build system is keeping people from contributing, then why isn’t there a “github” distribution of the appropriate tooling that everyone can try and see how much better it is?
Every build based on Ant is custom while the majority of projects built
with Maven is purely standard.
> I am one of those developers who will only waste/spend so much time
> fighting with something before I either throw it away, or roll my own
> so that I know what is going on and don’t waste my time with lack of
> transparency that keeps me from understanding how my software is
> actually working.
It may be good for you, but what happens with potential contributors, if
only the author can understand it?
Regards
Rafał
Re: Health of the Apache River Project
Posted by Gregg Wonderly <ge...@cox.net>.
On Apr 10, 2014, at 4:12 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia 2014-04-10, czw o godzinie 14:40 -0500, Gregg Wonderly pisze:
>
>> Maybe you can explain at this point. Is the problem that you can’t build, at all, to test your changes? Is this because you don’t have ANT?
>
> Are you, by any chance, being sarcastic?
I am not trying to be sarcastic, I am trying to find out what keeps you from editing River files to make changes you want, testing those changes and submitting them. One of the chief things for me, is the question of how does a “build” system cause a “source tree” to be uneditable, untestable etc.
There are very few things about River’s “jars” that are cast in stone. You can pretty much create two jars, one from services and one from proxies and be done. The multiple *-dl.jar files are a separation of “function” that might reduce overall downloads, but in the end, the overhead of multiple http transactions is probably much larger than the overhead of downloading all the proxies in a single jar.
I know that it is “work” to create a build system if you need something different than what something comes distributed with. But, that’s the question here. If the build system is keeping people from contributing, then why isn’t there a “github” distribution of the appropriate tooling that everyone can try and see how much better it is?
I am not trying to push back and be sarcastic. I am trying to be serious about what the real problem is.
I am one of those developers who will only waste/spend so much time fighting with something before I either throw it away, or roll my own so that I know what is going on and don’t waste my time with lack of transparency that keeps me from understanding how my software is actually working.
>
>> It seems it’s because you don’t know how to use the ANT build system, which I can understand. But also, you need to understand that there are people who have no idea how to use Maven either.
>>
>> So, overall, how can we simplify things if there are always new and different build tools/standards that some people know and others don’t?
>
> Is learning a new tool the problem or how would the migration address
> the problem of lack of contributions and new committers?
Learning a new tool is the question at hand. If you find Maven to be your build tool of choice, then I think you’ve already decided to learn a new tool. If you don’t know how to use ant to build with the build mechanism that exists, then that creates a problem. If that is THE PROBLEM for everyone, then that’s what we need to understand and remedy it would seem.
Gregg
> Regards,
> Rafał
>
Re: Health of the Apache River Project
Posted by Peter Firmstone <ji...@zeus.net.au>.
It's not so much that ant is the problem, more so that classdep needs to
be maintained for new java features to correctly determine
dependencies. But then it cannot determing Class.forName dependencies...
Tim Blackmann & I contributed the ClassDep Java 5 language support code
based on ASM.
Regards,
Peter.
On 11/04/2014 5:40 AM, Gregg Wonderly wrote:
> On Apr 10, 2014, at 2:35 PM, Rafał Krupiński<ra...@sorcersoft.com> wrote:
>
>> Dnia 2014-04-10, czw o godzinie 14:40 -0400, Greg Trasuk pisze:
>>> Hi Rafal:
>>>
>>>
>>> On Apr 10, 2014, at 2:15 PM, Rafał Krupiński<ra...@sorcersoft.com> wrote:
>>>
>>>> I think you missed the point.
>>>>
>>> Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it.
>> If you want patches and committers it shouldn't be a problem to change a
>> few lines, or even half a class in the core River. But it's not, so you
>> get no patches nor new committers.
> Maybe you can explain at this point. Is the problem that you can’t build, at all, to test your changes? Is this because you don’t have ANT? It seems it’s because you don’t know how to use the ANT build system, which I can understand. But also, you need to understand that there are people who have no idea how to use Maven either.
>
> So, overall, how can we simplify things if there are always new and different build tools/standards that some people know and others don’t?
>
> Gregg
>
>
>>> And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system.
>> It's not the issue here.
>>
>> (...)
>>> Don’t get me wrong - I’m not defending the current project structure.
>> Then I guess I don't understand what are you doing.
>>
>> Regards,
>> Rafał
>>
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-10, czw o godzinie 14:40 -0500, Gregg Wonderly pisze:
> Maybe you can explain at this point. Is the problem that you can’t build, at all, to test your changes? Is this because you don’t have ANT?
Are you, by any chance, being sarcastic?
> It seems it’s because you don’t know how to use the ANT build system, which I can understand. But also, you need to understand that there are people who have no idea how to use Maven either.
>
> So, overall, how can we simplify things if there are always new and different build tools/standards that some people know and others don’t?
Is learning a new tool the problem or how would the migration address
the problem of lack of contributions and new committers?
Regards,
Rafał
Re: Health of the Apache River Project
Posted by Gregg Wonderly <gr...@wonderly.org>.
On Apr 10, 2014, at 2:35 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia 2014-04-10, czw o godzinie 14:40 -0400, Greg Trasuk pisze:
>> Hi Rafal:
>>
>>
>> On Apr 10, 2014, at 2:15 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>>
>>>
>>> I think you missed the point.
>>>
>>
>> Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it.
>
> If you want patches and committers it shouldn't be a problem to change a
> few lines, or even half a class in the core River. But it's not, so you
> get no patches nor new committers.
Maybe you can explain at this point. Is the problem that you can’t build, at all, to test your changes? Is this because you don’t have ANT? It seems it’s because you don’t know how to use the ANT build system, which I can understand. But also, you need to understand that there are people who have no idea how to use Maven either.
So, overall, how can we simplify things if there are always new and different build tools/standards that some people know and others don’t?
Gregg
>> And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system.
>
> It's not the issue here.
>
> (...)
>> Don’t get me wrong - I’m not defending the current project structure.
>
> Then I guess I don't understand what are you doing.
>
> Regards,
> Rafał
>
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-10, czw o godzinie 14:40 -0400, Greg Trasuk pisze:
> Hi Rafal:
>
>
> On Apr 10, 2014, at 2:15 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
> >
> > I think you missed the point.
> >
>
> Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it.
If you want patches and committers it shouldn't be a problem to change a
few lines, or even half a class in the core River. But it's not, so you
get no patches nor new committers.
> And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system.
It's not the issue here.
(...)
> Don’t get me wrong - I’m not defending the current project structure.
Then I guess I don't understand what are you doing.
Regards,
Rafał
Re: Health of the Apache River Project
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Rafal:
On Apr 10, 2014, at 2:15 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
> I think you missed the point.
>
Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it. And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system.
On the other hand, if you’re looking at contributing something that will end up being in a different jar file (like I think you mentioned downloadable URLStream handlers), then ignore the current build system and create a new module with whatever build system and integration tests you like. We’ll create a new git repository for it, and release it as a separate module that a River user could add to their class path. It’s still a part of the River project, and users of River will greatly appreciate it.
> I'm already a user, and I'm perfectly happy with the current build
> system. In fact I couldn't care less about the build system.
> Provided I remain a user.
>
> But becoming a contributor, or even a committer is entirely another
> matter. I don't understand the project structure and I don't want to
> touch those ant scripts, especially classanddepjar task, with a stick,
> let alone modify it.
>
Don’t get me wrong - I’m not defending the current project structure. I completely agree that I don’t want to touch the existing scripts either. But that doesn’t have to get in the way of contributing. If you’re adding new features, you don’t have to plug into the existing project.
Cheers,
Greg Trasuk
Re: Health of the Apache River Project
Posted by Greg Trasuk <tr...@stratuscom.com>.
>>
>> inly compatible with Maven. A downstream project can use any build system that can access Maven Central’s repository. That at least covers Grails, Ivy, and Maven, and probably others.
>>
Did I say Grails? I meant Gradle, of course. Sorry for the confusion.
Greg
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-10, czw o godzinie 12:21 -0400, Greg Trasuk pisze:
> Patches welcome! And new committers needed.
(...)
> People have commented that the build system and the source code structure is difficult to understand, and prevents them from participating in the development. I understand that, but I also think that when we start to talk about changing the build system, there’s a couple of incorrect assumptions at work.
>
> First, we need to realize that the build system is there to produce artifacts. In the case of the current releases, these artifacts are, in fact, published to Maven Central. So although River isn’t built using Maven, it is certainly compatible with Maven. A downstream project can use any build system that can access Maven Central’s repository. That at least covers Grails, Ivy, and Maven, and probably others.
>
> Second, at the current time, River releases one source package that includes everything that River delivers, and so right now, everything River releases is built using the archaic (but working!) River build system.
I think you missed the point.
I'm already a user, and I'm perfectly happy with the current build
system. In fact I couldn't care less about the build system.
Provided I remain a user.
But becoming a contributor, or even a committer is entirely another
matter. I don't understand the project structure and I don't want to
touch those ant scripts, especially classanddepjar task, with a stick,
let alone modify it.
(...)
> Having said that, I wouldn’t jump in and “Mavenize River”. Why would we need to take on such a huge job, if the current build system works (ugly though it is)?
>From my perspective, as long River is built this way, "Patches (not)
welcome!".
Re: Health of the Apache River Project
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Rafal:
Some commentary below…
Greg.
On Apr 10, 2014, at 5:17 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia 2014-04-09, śro o godzinie 23:33 -0400, Greg Trasuk pisze:
>> Hi all:
>
> Hi Greg,
>
> Now I feel bad for not contributing my extensions to River, that I have
> implemented for SORCER (nb open source on github).
>
https://github.com/sorcersoft/sorcer
> We have our own ServiceStarter, historically based on River's and I
> think I could contribute some patches based on that..
What kind of changes did you make to ServiceStarter?
> I also have some preliminary work on downloadable URLStreamHandlers, and
> I'd be happy to contribute it to River once it's done.
>
Patches welcome! And new committers needed.
> The only problem is, I don't know anything about River's build process,
> ant scripts, classanddepjar tuning and @Betas. It would be much easier
> for me to contribute if River was mavenized. There was a discussion on
> that, but it's dead now and I don't see that materializing into code
> (maybe I don't know where to look).
>
Let’s talk about the build system. It was originally based on Make, then ported to Ant, and we’ve talked in the past about switching to Maven. Grails has also been suggested.
People have commented that the build system and the source code structure is difficult to understand, and prevents them from participating in the development. I understand that, but I also think that when we start to talk about changing the build system, there’s a couple of incorrect assumptions at work.
First, we need to realize that the build system is there to produce artifacts. In the case of the current releases, these artifacts are, in fact, published to Maven Central. So although River isn’t built using Maven, it is certainly compatible with Maven. A downstream project can use any build system that can access Maven Central’s repository. That at least covers Grails, Ivy, and Maven, and probably others.
Second, at the current time, River releases one source package that includes everything that River delivers, and so right now, everything River releases is built using the archaic (but working!) River build system.
But there’s no requirement that we only have one product!
So, if someone wanted to contribute something else to River, they’re free to build that module using whatever build system they want to use. The River Container used Maven. Your improved ServiceStarter, if you contributed it, could use Maven. Had Rio been contributed, it could have used Grails or whatever.
What I’m saying is that if we’re adding functionality, there’s no reason to limit ourselves to the current build system. Now, if you’re altering existing code, as Peter has been doing in qa_refactor, you’re kind of stuck. However, if somebody wanted to create a JMM-safe implementation of Reggie, for instance, they could certainly pull out the Reggie code and mavenize it on its own. Reggie (just as an example) is published to Maven Central as it’s own set of artifacts.
> Maybe the problem is that I wait for others to do the work instead of
> doing it? Shall I start a new github project for mavenized river and
> initiate the migration?
>
There’s another fallacy here, that we can’t use git, so additional projects need github. In fact, ASF now has git repositories available (I understand that github has some other features that people find useful. In fact, ASF is working on tighter integration, so for instance, we’ll soon be able to accept pull requests directly). We certainly could setup a git repository (as in fact I did for River Container), and in fact it’s automatically mirrored to github. It doesn’t have to be all-or-nothing.
Having said that, I wouldn’t jump in and “Mavenize River”. Why would we need to take on such a huge job, if the current build system works (ugly though it is)? Rather, I’d suggest that we think about having another River deliverable to include a new unit of functionality.
> Regards
> Rafał
>
Re: Health of the Apache River Project
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-04-09, śro o godzinie 23:33 -0400, Greg Trasuk pisze:
> Hi all:
Hi Greg,
Now I feel bad for not contributing my extensions to River, that I have
implemented for SORCER (nb open source on github).
We have our own ServiceStarter, historically based on River's and I
think I could contribute some patches based on that..
I also have some preliminary work on downloadable URLStreamHandlers, and
I'd be happy to contribute it to River once it's done.
The only problem is, I don't know anything about River's build process,
ant scripts, classanddepjar tuning and @Betas. It would be much easier
for me to contribute if River was mavenized. There was a discussion on
that, but it's dead now and I don't see that materializing into code
(maybe I don't know where to look).
Maybe the problem is that I wait for others to do the work instead of
doing it? Shall I start a new github project for mavenized river and
initiate the migration?
Regards
Rafał