cvs commit: ports/java/jgraphx Makefile distinfo

[Rob Farmer]

On Sat, Aug 28, 2010 at 2:28 AM, Chris Rees <utisoft at gmail.com> wrote:
> 2010/8/27 Alexey Dokuchaev <danfe at freebsd.org>:
>> On Thu, Aug 26, 2010 at 09:53:32PM -0700, Rob Farmer wrote:
>>> This breaks math/scilab (which is the only dependency in the ports
>>> tree). Unfortunately, the author of jgraphx seems to completely
>>> disregard backwards compatibility and changes the API in virtually
>>> every release.
>>>
>>> I tried to patch Scilab based on their git repository (which has
>>> support for 1.4.0.1), but hundreds of revisions have passed and they
>>> have rearranged their tree a bit and added/removed some files, so it
>>> didn't go well.
>>>
>>> IMHO, we need to either create a separate jgraphx-scilab port or keep
>>> this in sync with Scilab (this is what Debian, Ubuntu, and Gentoo are
>>> doing).
>>
>> Considering Scilab is the only consumer of jgraphx, it seems having
>> special port would be an overkill.  I think we should keep the two in
>> sync, and probably work with upstream maintainers of both projects to
>> improve compatibility and API inheritance in the future.  Separate port
>> of jgraphx-scilab is palliative solution, i.e. it simply increases the
>> entropy, not solving the underlying problem.
>>
>> ./danfe
>
>
> Since Scilab is the only consumer of jgraphx, I don't mind reverting it.
>
> Actually, I wrote that while trying to repair Scilab myself, so if you
> want maintainership of jgraphx too, that's fine.

I don't want to feel like I'm stealing your ports, but I do think it
would be a good idea to have them maintained together.

>
> Alternatively you could have it as another distfile in Scilab rather
> than depending on the port....

I hadn't thought about this, but it may actually be the best solution
- as far as I'm aware, the reason for having libraries in separate
ports is to allow multiple applications to use the same copy, but
given the instability of the jgraphx API, I think it is unlikely that
multiple ports could depend on one common version of jgraphx (at least
without significant patching), so the benefits of having a jgraphx
port are probably limited. Thoughts?

-- 
Rob Farmer

>
> Chris
>