Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Native plug-ins

----- Original Message -----
> From: "Doug Schaefer" <dschaefer@xxxxxxx>
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>, "mike milinkovich" <mike.milinkovich@xxxxxxxxxxx>
> Sent: Monday, March 16, 2015 10:05:26 PM
> Subject: Re: [cdt-dev] Native plug-ins
> 
> Ah, never mind. JNA has not be approved. Which is too bad, it’s pretty
> cool.

JNA is not approved but jnr-ffi+friends has a cq open (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9090).
It might be better to use JNR nowadays as it's already used by JRuby and Jython for ffi and is stated to form the basis of JEP 191: Foreign Function Interface (http://openjdk.java.net/jeps/191). 
This was the reason why we are going towards using it in Linux Tools.


Alexander Kurtakov
Red Hat Eclipse team

> 
> Doug.
> 
> 
> On 2015-03-16, 3:58 PM, "Doug Schaefer" <dschaefer@xxxxxxx> wrote:
> 
> >On 2015-03-16, 2:55 PM, "Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>
> >wrote:
> >
> >>On 16/03/2015 10:57 AM, Doug Schaefer wrote:
> >>> One of the topics discussed at EclipseCon was the native plug-ins,
> >>> I.e. the ones that do the Spawner, PTY, Windows Registry, and now
> >>> Serial Port. There is more interest in using this functionality
> >>> outside the scope of the CDT. In fact, I¹ve received a couple of
> >>> requests to use it outside of Eclipse, especially the Serial Port.
> >>>
> >>> I¹ll be taking a look at this in the upcoming weeks. One part of this,
> >>> to make them more mobile in case we want to push it down the stack,
> >>> I¹d like to move it into it¹s own repo. At the very least we need a
> >>> separate build since things like org.eclipse.remote will need to
> >>> depend on it which creates a circular build dependency.
> >>
> >>Doug,
> >>
> >>As discussed at EclipseCon: With respect to Serial Port specifically, we
> >>may want to consider dual-licensing the code EPL+EDL(BSD). That would
> >>ensure that the component could be consumed in GPL licensed projects. I
> >>suspect that a well-written, well-maintained, and liberally licensed
> >>replacement for RXTX would be of great interest.
> >
> >Yes, I am still considering how that would work. The Serial Port
> >functionality depends on the Windows Registry code we have. And if we go
> >there, I would think the rest of the native functionality may be of
> >interest in the same way.
> >
> >I guess the issue then is changing the license of the existing code which
> >would require approval from all the copyright holders, which may be tricky
> >as some of this is really old code.
> >
> >Some of that may be mitigated by using JNA which I hear has been approved
> >for use in the Platform. We could then separate this stuff out into
> >separate plug-ins more easily and then license them differently.
> >
> >Need to think about that a bit more.
> >
> >Thanks!
> >Doug.
> >
> >>
> >>--
> >>Mike Milinkovich
> >>mike.milinkovich@xxxxxxxxxxx
> >>+1.613.220.3223 (mobile)
> >>
> >>_______________________________________________
> >>cdt-dev mailing list
> >>cdt-dev@xxxxxxxxxxx
> >>To change your delivery options, retrieve your password, or unsubscribe
> >>from this list, visit
> >>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >_______________________________________________
> >cdt-dev mailing list
> >cdt-dev@xxxxxxxxxxx
> >To change your delivery options, retrieve your password, or unsubscribe
> >from this list, visit
> >https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top