Home » Eclipse Projects » Eclipse Titan » Eclipse Titan, Cygwin, EPLv2 and GPL
|
| Re: Eclipse Titan, Cygwin, EPLv2 and GPL [message #1805874 is a reply to message #1805778] |
Fri, 26 April 2019 09:05   |
|
Hi Harald,
you are raising a valid and interesting point;
however, let me set aside for the moment the license related issues and approach it from a purely technical perspective;
let me start with the fact that we have a long experience of delivering Cygwin based Titan packages
within the company and we have seen all the benefits and downsides of it.
On the negative side, the main problem we see with Cygwin is that it does not support the concept of LTS; this means that
any new Titan version could be delivered with the actual latest version of Cygwin,
which implies that the user will have to change/refresh it's OS; usually this is viewed as a nuisance.
Also, it means that in our Jenkins infrastructure , running day and night, testing the code on several different platforms,
we have to use an arbitrary Cygwin version, which may not be the same as the one used for final delivery.
Again, not a benefit.
Let's see now the advantages of using Cygwin: obviously the main reason for that is to "Get that Linux feeling - on Windows".
But this may be irrelevant if you want to use Titan in command line only, or with editors other than our own Eclipse IDE,
as for this scenario there are better, more flexible alternatives,such as Windows Subsystem on Linux, containers, virtual images etc.
Situation changes if you want to use the Titan core and the Eclipse plug-ins together in the comfort of your Windows laptop and aim for a complete develop-build or develop-build-execute cycle.
In this case virtual machines, containers etc. will behave as remote hosts, so the Eclipse plug-ins will only assist in editing etc. but to build and execute the code a second
channel (a command line terminal) has to be opened.
With Cygwin this changes, as the Titan binaries installed in Cygwin are native Windows binaries, so the Eclipse plug-ins
(installed in Windows, and not under Cygwin!-to circumvent resource restrictions imposed on the Cygwin environment)
can invoke them to compile and run.
However , there are limits to this, due to resource limitations in Cygwin (and notebooks too), as this could be practical for small (thousands to tens of thousands of lines)
and possibly medium (tens of thousands to hundreds of thousands of lines) sized projects,
but for large ones ( hundreds of thousands of lines to millions of lines) probably one is better off using a multicore server with the full Titan environment installed,
and the Windows notebook used as a terminal only.
In summary Cygwin addresses accurately Windows portability, but it's only practical during development ( and not necessarily production-style execution as well) of small or medium size TTCN-3 projects -with the Eclipse IDE- on a Windows machine.
And yes, I agree, that is a considerable mass of users.
Nevertheless, we have a different, and we believe, better proposition for them.
To build the tension a bit more, let me add a bit of a historical background:
The legacy Titan core does roughly the following during compilation:
-parses the code and performs a syntactical and semantic analysis
-based on the information in the code builds a so-called Abstract Syntax Tree which reflects all the structural information
-using the AST, the intermediate C++ code is generated (and then compiled with a C compiler and executed)
The Eclipse plug-ins that have been added some years later , do the first two steps totally independently(!)
from the legacy Titan part, using Java libraries.
This implies that by adding a Java code-generation part and a code execution part, we could obtain an independent tool which uses Java as an intermediate language.
And this is exactly what we have done.
Add to this the info that Java in the last ten something years became more and more popular in writing professional applications, sometimes replacing C/C++.
Whoever opted for Java as a development language will probably abandon a C/C++ based test platform as it is inconvenient to maintain two different platforms, one for development and one for test.
We have experienced this migration within the company and we see the Java code generation as a means to regain our users.
To cut the long story short, in the next release we will publish a new Eclipse plug-in that will generate and execute Java code from TTCN-3.
This new plug-in will address:
-portability to Windows
-but also will help in development becoming more interactive, as the build times we measured so far are one or two orders of magnitude (!) shorter,
than the ones measured with the legacy C/C++ workflow.
As a downside, not the full scale of features will be offered initially: only the RAW codec is supported currently, next to be added being JSON;
not the whole range of test ports will be available; expectedly the protocol modules might need some trimming and so on.
However we see this as a superior alternative to Cygwin or any other solution trying to build a bridge between Windows and Linux.
Please keep an eye on our future releases for details.
Harald, I hope this answers your question and explains why we were not thinking along legalizing the Cygwin line.
I know that you are not necessarily a fan of Eclipse and Java, but we would be grateful if you could look into our new
tool and tell us your impressions.
Thank you and best regards
Elemer
[Updated on: Fri, 26 April 2019 09:26] Report message to a moderator |
|
|
| Re: Eclipse Titan, Cygwin, EPLv2 and GPL [message #1806019 is a reply to message #1805874] |
Tue, 30 April 2019 14:48 |
|
Hi Elemer,
thanks a lot for your comprehensive outline for the future of TITAN. I personally (honestly) don't care much about cygwin compatibility as it relates to a platform that cased to be relevant to me already in the days of Windows 95. I was just reading the license compatibility related note in the README file and thought I'd point out that GPL - EPL compatibility can now be achieved with the move to EPLv2.
Regarding the general move to Java:
It's your project and of course you can take its development into the direction that you see fit. I personally certainly dislike that move, but I'm would never be as arrogant as to saying my personal taste has any relevance for other projects. In terms of using it within the test suites we're writing in Osmocom: We won't technically be able to use anything but the existing TTCN3-to-C++ compiler until/unless the Java version is feature compatible with all the (many) features of TITAN/TTCN-3 we use by now.
And also, to be honest, any migration to a new, significantly different TTCN3 compiler/runtime (whether or not in Java) is not something we'd be enthusiastic about, but likely only do once we really have to. Apart from faster compile time (which currently is rather long, but not a constraining factor nor unlikely to become one) I don't currently see any advantages that would be relevant to what we're doing. TITAN being "un-fancy", "Linux-ish", "command line driven", and/or "legacy" are actually all extremely positive aspects that make the project attractive :)
It would be good to get some confirmation that the existing C++ "world" continues to be "supported" (as far as unpaid, FOSS support goes) at least until the Java version is feature-complete to the new Java version.
Best regards,
Harald
|
|
|
| Re: Eclipse Titan, Cygwin, EPLv2 and GPL [message #1806024 is a reply to message #1806019] |
Tue, 30 April 2019 16:33 |
|
Hi Harald,
thank you for giving me the opportunity to clarify:
We have no intention to abandon the legacy command line "Linux-ish" "engineer-gray" environment; we see the two products as completing each other, addressing two different audiences, maybe with some possible overlapping.
As an example, the legacy environment gladly executes on micros equipped with ARM processors and small memory which is prohibitive for the Java environment.
As far as my personal preference goes, I must confess I'm not a user of the Eclipse plug-ins myself, but my product responsibility should and does extend beyond that.
We hope the Java-based product will attract new users and that should ultimately benefit everyone, even the die-hard command line crowd, of which I proudly consider myself part of.
Best regards
Elemer
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 02:58:42 GMT 2024
Powered by FUDForum. Page generated in 0.03503 seconds |
] 
Search
Help
Register
Login
Home
