commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <sgoes...@gmx.at>
Subject Re: [Launcher] [Exec] Merge Proposal
Date Mon, 10 Jun 2013 10:17:36 GMT
Hi folks,

there is actually "launcher" code in commons-exec - see

org.apache.commons.exec.launcher

I'm having a look "Launcher" code this evening

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 <ebourg@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
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message