Hi again, Sorry for the delay.
I'm assuming that the previous messages exchanged about this merge proved that there was some interest on going forward with it. With that in mind I had another look on how this could be done and I have to partially agree with what Siegfried Goeschl proposed on his last message. [Exec] is a broader project and it seems to make sense to integrate [Launcher] into it. Even if we call the final product something else. I thought that a good point for integration could be a non disruptive approach by simply implementing the LauncherBootstrap ([Launcher]) behaviour into the org.apache.commons.exec.Executor interface. This would provide us with a valuable extension of the java execution bootstrap technique around the carefully planed executor interface. I would also probably leave behind the LaunchTask and LaunchFilter and drop the Ant approach. A bit of tidy up and code update could also be performed with this merge such as moving i18n files into resources, probably some extra work on the documentation as well. Please let me know what you think so that I can start getting my hands onto the actual job itself. Thank you in advance, Ricardo Ricardo Espírito Santo On 10 June 2013 11:27, Siegfried Goeschl <sgoes...@gmx.at> wrote: > Hi folks, > > had a quick look > > * similar functionality of both components > > * launcher has some bells and whistles regarding launching Java processes > compared to commons-exec > > * commons-launcher has Ant dependencies > > IMHO retiring commons-launcher and moving it to commons-exec is a good idea > > > Cheers, > > Siegfried Goeschl > > > On 10.06.13 12:07, Ricardo Espírito Santo wrote: > >> Hi Emmanuel, >> >> Thank you for your comments. Please find mine @inline. >> >> Regards, >> Ricardo Espírito Santo >> >> >> On 10 June 2013 00:48, Emmanuel Bourg <ebo...@apache.org> wrote: >> >> Le 09/06/2013 22:03, Ricardo Espírito Santo a écrit : >>> >>> - Very similar objectives, features and aims >>>> >>> >>> exec: Invoke an external application from Java >>> launcher: Start a Java application from the shell >>> >>> Besides launching something they don't look that similar to me. >>> >>> >> That's a very good similarity! They both launch something and since that >> is >> 99% of what they do I'd say they do pretty much the same thing. >> >> If you look at any other Commons sub project I believe you will find that >> none of them addresses only one issue. >> >> >> >>> >>> - Simplification of the overall Commons project by reducing the number >>>> of >>>> specific projects without compromising feature delivery >>>> >>> >>> That doesn't look like an issue. >>> >>> >> It is not an issue on its own but having a lot of choices requires a more >> intricate knowledge of the components and more specific nuances between >> them. Surely we want to move towards a simpler and easier user experience. >> >> >> >>> >>> - The merged project will probably involve and capture attention of new >>>> contributors >>>> >>> >>> Not sure to see how merging projects attracts new contributors. But if >>> it works I suggest merging all Commons projects into a big one :) >>> >>> >> The memento in both Exec and Launch seems to have halted and I believe >> that >> by creating a new project, new users who have actually done some work for >> either project in the past and also for those just looking for something >> easy and small to start contributing to Commons will be drawn in - No one >> likes to commit work to a project which has been parked for over 5 years. >> >> >> >>> >>> - Code share and total lines of code reduction >>>> >>> >>> Not an issue considering the small size of these components. >>> >>> >> I agree, not an issue but surely this should be an aim and a philosophy >> rather than a technical consideration. - My reasoning is: even if its just >> 10 duplicate lines they shouldn't be duplicate in the first place. >> >> >> >>> >>> - General update of both project’s source code >>>> >>> >>> This can be done without merging. >>> >>> >> True but it hasn't been done so far. Why? no interest in either >> projects... >> Aren't the most active projects the ones which do more than one thing and >> interest more users ? >> >> >> >>> >>> [Reasons not to merge] >>>> >>>> - Broadening the focus of each project >>>> >>>> - The actual work of planning the merge, merging and documenting imply >>>> person-hours that could be applied to more functional tasks >>>> >>> >>> I agree, let's fix the issues that actually matter to our users. >>> >>> >> Again a few issues have been raises, patches have been proposed and yet >> the >> development has nevertheless halted. >> >> >> >>> Emmanuel Bourg >>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
