| Re: [cdt-dev] "An error happened while checking if user has a signed agreement" |
_______________________________________________Hello everyone,
Thank you, Jonah, for your answers. We are shipping plug-ins that can be installed into end user's Eclipse installation. Maybe in the future it will be a product. I tried your answer 1 and it seems to be a good solution for us, as there are a lot of classes I need to touch. But it's a short-term solution. I feel that some of the changes might be relevant in general, so in the future I also want to try your answer 3: Contribute back to CDT.
To start with that I filed a minor bug (550807) and tried to push a quick fix for it. But following this https://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT instruction step by step leads to "remote rejected" when I try to push.
In the message details it says: "An error happened while checking if user has a signed agreement". I have signed the ECA.
Alexander Blaas had exactly the same problem (https://bugs.eclipse.org/bugs/show_bug.cgi?id=549810) and he seems to have been the first one in the internet with this problem. The solution for him was "The gerrit user DB was a bit messy about your account. I fixed it.". I don't remember to have anything done that could mess up the DB entry for my account. What else could I have done wrong to get this message?Thank you
Sadik
On 03/09/2019 15.21, Jonah Graham wrote:
Hello Sadik,
That sounds all very interesting and I you have come to the right place for this type of question & discussion.
I am going to provide three answers, depending on your use case. Let's use this as a starting point, so please come back with some follow-up questions.
1) Are you shipping a product or some plug-ins you want end users to be able to install into their existing Eclipse installation they may have obtained elsewhere? If you are just doing a product, then the way that many other vendors are handling the "fork" is to fork the code, but not rename anything. Then you can "mvn package" your forked CDT and add that to your product. Doing this will make it fairly reasonable to re-merge your code with original CDT as needed. (You mention that your plug-ins have to work along side of CDT, but that can be orthogonal to product vs plug-ins)
2) If you want to ship plug-ins, then the best bet may be to simply copy the classes you can't extend with the given extensibility options. This can work better or worse depending on the structure of CDT. Sometimes you can just copy out and modify the 3-4 classes you need, but sometimes you simply need to copy too much and it becomes cumbersome.
3) Contribute the extensibility that you want back to CDT. Can you contribute back changes in a non or minimally interfering way to CDT core? Then you can operate without a fork at all. In practice this may mean combining this option with 1 or 2 so that you can ship your solution now, but by contributing back it means you won't diverge forever.
My experience is that when the whole of CDT (core) is forked & renamed, that maintaining that fork can get quite cumbersome - however in the short term it can get you to a release faster. The best long term maintainability option is to not fork.
I hope that this is a good starting point for you. Please do come back with questions.
Jonah
On Tue, 3 Sep 2019 at 05:22, Sadik Özoguz <soezoguz@xxxxxxxxxxx> wrote:
_______________________________________________Hi everyone,
I follow this mailing list for a while now, but I usually ask my stupid questions about CDT on StackOverflow where always the same people give me helpful answers and even upvote my question, no matter how stupid it is. This time I was suggested to ask in this mailing list, and I hope I don't bother you. I would be grateful If someone can give me helpful answers on what I ask in the short part. In case the short part is too short to understand the question, I added a longer explanation.
In short:
What is the best way to fork org.eclipse.cdt.core? I need to evaluate for our company whether forking cdt is a good option for us or not. Are there best practices? I want to fork as little as possible, because I only need to change few functionalities, mainly in Indexer and Source Parser classes. I also need to avoid conflicts with the original CDT plugins so that our plugin works alongside the CDT plugins. Is that possible without forking everything
I did:
git clone http://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
Then I created a new branch "fork" based on master and replaced every string "org.eclipse.cdt.<>" by "my.url.cdt.<>". I renamed the import statements, the dependencies, the directory names and every occurence of "org.eclipse.cdt". Then I imported started to import "my.url.cdt.core" in eclipse and then "ui" and "native", because I noticed that I need to add at least these two.
Long explanation on why I want to evaluate if forking CDT is a good choice:
We are working on a new User Interface for our tool "RT-Tester". The new UI is an Eclipse Plugin. RT-Tester is a test automation tool for automatic test generation, test execution and real-time test evaluation. It comes with a powerful test language (Real-Time Test Language, RTTL) for efficient development of procedures for automated test execution. That language is based on C++ and adds some new concepts. When coding in RTTL our Eclipse Plugin should provide the coder with a working SourceParser and Indexer. Until now I tried to do achieve that the 'normal' way: by using extension points to add languages and content types and extending CDT classes. But I couldn't find good work arounds for some problems (that's why I was asking so many questions on SO). Examples for bad work arounds: Building the Abstract Syntax Tree becomes a problem when it comes to new concepts that are not part of C++. For example there is a concept called "abstract machine" which looks something like this:@abstract machine {
}
Some of the other RT-Tester-concepts are only allowed to be used inside an abstract machine body and others are only allowed to be used outside. I can add a node of type ICPPASTNamespaceDefinition for this abstract machine, only because its syntax is similar to a namespace but actually has nothing to do with a namespace. This is not a good work around. I can extend IASTNode (ignoring the noextend annotation) and add a custom node but the indexer is not going to understand it nor is the outline view.
Another problem is that "@abstract machine" needs highlighting. I can add the two language keywords "abstract" and "machine" to have it highlighted, but that will also highlight only "machine", if someone uses that as a variable identifier. Creating one token for "@abstract machine" would require to change the Lexer. The Lexer class is declared final, so the behavior of the Lexer can only be customized in a very limited way. Using Semantic Highlighting doesn't work either, because the abstract machine needs to be parsed as IASTName then (but it's a declaration, so it should be parsed as IASTDeclaration).
A related problem is displaying syntax errors for incorrect usage of RT-Tester-Concepts. There are about 60 RT-Tester commands and the only support I can provide currently is that the commands are ignored by preprocessor or parsed as something different by the parser, so that the AST is built up without problems and features like "go to declaration" or "call hierarchy" work as expected.
Another problem might occur when the indexer tries to resolve file paths, because our files usually remain on a server. Another problematic RT-Tester-Concept is a "channel", which is declared in a cnl-file (*.cnl). In the declaration of variables used to write/read from a channel, a channel type definition has to be used which is the channel identifier appended with "_t". Now the indexer will not find <channel_name>_t as it has never been declared. I can rename token images but that comes with undesired side effects.
I could mention more examples, but I home the motivation, why we want to check whether a fork is a good choice, becomes clear.
And the main question is: What is the correct/best way to fork CDT if I only want to change functionality in the core plugin?Thank you,
Sadik
-- Sadik Özoguz Verified Systems International GmbH Geschäftsführerin Dr.-Ing. Cornelia Zahlten HR B 18341 Amtsgericht Bremen Am Fallturm 1 28359 Bremen, Germany mail: soezoguz@xxxxxxxxxxx tel: +49 421 572 04-286 fax: +49 421 572 04-22 http://www.verified.de
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/cdt-dev-- Sadik Özoguz Verified Systems International GmbH Geschäftsführerin Dr.-Ing. Cornelia Zahlten HR B 18341 Amtsgericht Bremen Am Fallturm 1 28359 Bremen, Germany mail: soezoguz@xxxxxxxxxxx tel: +49 421 572 04-286 fax: +49 421 572 04-22 http://www.verified.de
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev