Je vais vous parler de ce que je connais le mieux dans cette nouveau version d'Eclipse.
Je veux parler en premier lieu du projet API Tooling. Ce projet a été introduit dans la version 3.4 de manière très succincte. La version incluse dans Galileo est beaucoup plus aboutie.
API Tooling fournit de nombreuses tâches ant pour pouvoir faire des validations lors d'un build ant. Ces tâches ant sont notamment utilisées dans les builds Eclipse eux-même depuis plusieurs mois.
La validation peut également être faite au fur et à mesure du développement à l'aide d'un builder. Chaque projet PDE (pour l'instant les projet Java ne sont pas supportés) peut être converti vers API Tooling.
Une fois ceci fait il suffit de paramétrer une "baseline" qui sert de référence pour la définition des APIs afin d'avoir une validation faite par API Tooling.
La fonctionnalité que je préfère est la validation des librairies. Ceci permet de s'assurer lors du développement que les types, méthodes et champs utilisés depuis les librairies correspondent bien aux environnements d'exécution spécifiés pour le projet.
Prenons un exemple. Si je définis un projet avec comme environnement d'exécution J2SE-1.4, je ne suis pas supposé utiliser de méthodes définies uniquement en J2SE-1.5 ou JavaSE-1.6. Malheureusement Eclipse utilise comme JRE par défaut celui qui est utilisé pour démarrer Eclipse.
Donc si j'utilise une VM 1.6 pour démarrer Eclipse et qu'ensuite je crée un nouveau projet PDE, je vais avoir des librairies 1.6 sur le classpath de mon projet. Si je n'installe pas de JRE 1.4 correspondant à l'environnement d'exécution que je veux utiliser, je peux très facilement (en utilisant l'assistant de code (Ctrl + Space)) utiliser par mégarde une mauvaise méthode.
API Tooling va valider tous les références dans les librairies pour s'assurer que toutes existent dans l'environnement spécifié dans le fichier MANIFEST.MF et non uniquement dans les librairies utilisées sur le classpath.
Cela garantit qu'à l'exécution le fichier jar généré fonctionnera bien sur une VM 1.4. Cette fonctionnalité n'est pas spécialement intéressante quand un seul environnement d'exécution est spécifié, mais elle devient par contre essentielle quand plusieurs le sont en même temps comme:
J2SE-1.4, OSGi/Minimum-1.1, CDC-1.0/Foundation-1.0,...
Voilà pour API Tooling. Je vous encourage vraiment à convertir tous vos projets PDE pour utiliser cette fonctionnalité.
L'éditeur HTML de WTP a également fait des progrès notables dans la version 3.5 (Galileo).
JDT fournit de nouveaux outils pour retravailler le code, des améliorations dans le formatteur de code, des nouveaux outils pour aider à coder (assistant de codage). JDT reste un environnement de référence pour développer en Java sur un nombre de plateformes impressionnant.
L'intégration de Subeclipse dans le train Galileo simplifie grandement l'utilisation de référentiels SVN. Je ne suis pas très familier avec SVN lui-même, mais j'ai pu facilement accéder à des référentiels SVN et sauver mon code sans être trop perdu par rapport au support intégré avec le SDK pour CVS.
J'utilise aussi régulièrement Mylyn qui je l'avoue me simplifie grandement la vie en intégrant un client Bugzilla directement dans Eclipse. Ça fonctionne toujours aussi bien. Mylyn permet également de mieux cibler le code sur lequel on travaille et permet de partager ce "contexte" avec d'autres personnes.
Bref, Galileo est une nouvelle version qui vaut le détour. Il me reste encore à découvrir beaucoup d'autres projets intégrés avec Galileo: CDT, EMF, GEF, ...
Si vous avez des questions, n'hésitez pas!
Bonne découverte à tous!
Olivier
Thursday, July 30, 2009
Thursday, February 26, 2009
Discovered the new about dialog
Investigating bug 265691, I opened the about dialog (Help>About Eclipse SDK).
I was expecting the old look with several buttons.
I was pleased to see that there is only one button now called "Installation Details".
Clicking on it opened a nice dialog that contains all the previous information organized using tabs. This is more compact, more scalable!
I like it! Thumps up to whoever did it!
The resizing of this dialog is not optimal, but it is definitely a good start! For example, a sash between the two boxes would be nice to be able to resize the bottom part.
I was expecting the old look with several buttons.
I was pleased to see that there is only one button now called "Installation Details".
Clicking on it opened a nice dialog that contains all the previous information organized using tabs. This is more compact, more scalable!
I like it! Thumps up to whoever did it!
The resizing of this dialog is not optimal, but it is definitely a good start! For example, a sash between the two boxes would be nice to be able to resize the bottom part.
Wednesday, December 10, 2008
Invalid references in system libraries now detected!
It has been a long time since I blogged, but in the upcoming 3.5M4 release there is a new feature that I'd like to talk about.
API Tools provides a new feature to detect invalid references in system libraries. How many times did an Eclipse build fail because some code from a 1.5 library was used in a bundle tagged as 1.4? Too many times!
Now this kind of failures should be gone if all bundles are using API Tools.
Here is what you need to do to be all set:
1) Make sure that API tools is enable for your bundle
2) Then you select your bundle
3) Open the preferences for API Tools:
4) Select Warning or Error for the "Invalid references in system libraries"
5) Once the rebuild is complete, you should get new markers corresponding to this option.
This is especially useful for bundles that have multiple execution environments. It is difficult to make sure that all method invocations, type references or field accesses are included in all the specified execution environments.
Let me know if you have any question regarding this new option. All potential issues should be reported against PDE/API Tools component.
API Tools provides a new feature to detect invalid references in system libraries. How many times did an Eclipse build fail because some code from a 1.5 library was used in a bundle tagged as 1.4? Too many times!
Now this kind of failures should be gone if all bundles are using API Tools.
Here is what you need to do to be all set:
1) Make sure that API tools is enable for your bundle
2) Then you select your bundle
3) Open the preferences for API Tools:
4) Select Warning or Error for the "Invalid references in system libraries"
5) Once the rebuild is complete, you should get new markers corresponding to this option.
This is especially useful for bundles that have multiple execution environments. It is difficult to make sure that all method invocations, type references or field accesses are included in all the specified execution environments.
Let me know if you have any question regarding this new option. All potential issues should be reported against PDE/API Tools component.
Friday, March 14, 2008
API Tooling at Eclipsecon
For those who want to know what API tooling can do for you, you should come to the API Tooling presentation at Eclipsecon. This is Wednesday at 2:30pm in room 207.
Friday, February 22, 2008
Api Tooling went live in nightly builds!
Since last Friday, api tooling is now part of the SDK.
I encouraged you to give it a try and let me know if you find anything wrong. Don't hesitate to open a bug report against the API Tools component of the PDE product.
You can read the API Tools wiki to find out how to use it. All comments are welcome.
Also if you are interested by this project, we (Darin and I) will have a presentation at Eclipse con about the current work done for 3.4. Feel free to subscribe to the mailing list of this presentation to let us know your expectations.
The plan is to be in the next integration build.
Olivier
I encouraged you to give it a try and let me know if you find anything wrong. Don't hesitate to open a bug report against the API Tools component of the PDE product.
You can read the API Tools wiki to find out how to use it. All comments are welcome.
Also if you are interested by this project, we (Darin and I) will have a presentation at Eclipse con about the current work done for 3.4. Feel free to subscribe to the mailing list of this presentation to let us know your expectations.
The plan is to be in the next integration build.
Olivier
Wednesday, November 21, 2007
Traceability of API breakage
I know that an API is not supposed to be broken, but.... in real life this happens.
In the context of the API tooling effort, we need to handle this case when checking for binary compatibility between two Eclipse drops.
An example would be that an API provider defines an interface that can be implemented by clients with a method that takes an internal type as a parameter. This API is not usable for the clients. The provider then changes the signature of the method to use an interface type instead of the internal type. Now the API is usable, but this change technically speaking a breaking API change.
This kind of changes should be documented in the porting guide, but I believe it should also be document at the source code level.
One way to do this would be to have a javadoc tag on the corresponding API that would state this is a known breakage. Something like:
@breakage-change The parameter type has been changed to use an API type instead of an internal type
The binary compatibility checker could then realize that this is a known breakage and don't report it anymore.
The next question is: "Since this is an API breakage, should the version of the corresponding bundle change its major version?".
I'd like to get your opinions on this topic.
Thank you.
In the context of the API tooling effort, we need to handle this case when checking for binary compatibility between two Eclipse drops.
An example would be that an API provider defines an interface that can be implemented by clients with a method that takes an internal type as a parameter. This API is not usable for the clients. The provider then changes the signature of the method to use an interface type instead of the internal type. Now the API is usable, but this change technically speaking a breaking API change.
This kind of changes should be documented in the porting guide, but I believe it should also be document at the source code level.
One way to do this would be to have a javadoc tag on the corresponding API that would state this is a known breakage. Something like:
@breakage-change The parameter type has been changed to use an API type instead of an internal type
The binary compatibility checker could then realize that this is a known breakage and don't report it anymore.
The next question is: "Since this is an API breakage, should the version of the corresponding bundle change its major version?".
I'd like to get your opinions on this topic.
Thank you.
Monday, September 10, 2007
The method getCanonicalName() is undefined for the type Class
This is my first blog entry. So forgive me for my "poor" writing skills.
Last week compile errors were found in the nightly builds. The first error was:
The method getCanonicalName() is undefined for the type Class
This is actually quite simple to prevent this kind of errors. But before I talk about how to fix it, it should be clear to understand how this is possible.
This method is a method that is defined in 1.5. In Eclipse it would be tagged with the javadoc tag @since 1.5.
In order to get it, you need to start Eclipse with a JDK1.5 and never add another JRE in the installed JREs list. Then even if you specify that your project takes an execution environment 1.4, you will have a JRE 1.5 on the classpath. The JRE 1.5 that you used to start Eclipse has been installed by default. It is a potential match for an execution environment 1.4 and since there is no other JRE installed, it is used as the JRE library on the project classpath.
The Eclipse compiler doesn't check if a method is defined in the JRE1.5 or 1.4 even if the project settings are compliance 1.4, target 1.2 and source 1.3. We have requests to add this kind of support in the compiler, but this is not the purpose of this blog. So since the compiler doesn't check that the method that is used in the project comes from a 1.4 JRE, the project compiles fine on the committer's machine. Then the code is committed and retrieved for the next nightly build.
The nightly build is however using a JRE 1.4 on the project's classpath to match the 1.4 execution environment requirement. And this is how a compile error is raised during the nightly build. It might seem obvious and simple enough so that readers are wondering why I talk about this.
Last week the problem arised twice. Once for the error mentioned above and the second time with this error:
The method valueOf(String) in the type Long is not applicable for the arguments (long)
So it seems that it might be worthwhile to explain how to prevent it this error once for all. The solution is quite simple.
Always install the JRE that corresponds to the project's execution context requirement. And if your project doesn't have such a requirement, edit the manifest file to add it.
If a 1.4 JRE is installed when the execution environment 1.4 is specified for a project, it will be used. If you want to be sure which one is used, check the preference page Window>Preferences>Java>Installed JREs>Execution Environments.
Then you check which JRE is set to be a perfect match for the execution environment you are using.
Once this is done, you are sure that the right JRE ends up in the project's classpath and that if you code compiles in your workspace, it will also compile in the Eclipse builds.
Let me know if you find this kind of blog useful or completely obvious and useless.
Olivier
Last week compile errors were found in the nightly builds. The first error was:
The method getCanonicalName() is undefined for the type Class
This is actually quite simple to prevent this kind of errors. But before I talk about how to fix it, it should be clear to understand how this is possible.
This method is a method that is defined in 1.5. In Eclipse it would be tagged with the javadoc tag @since 1.5.
In order to get it, you need to start Eclipse with a JDK1.5 and never add another JRE in the installed JREs list. Then even if you specify that your project takes an execution environment 1.4, you will have a JRE 1.5 on the classpath. The JRE 1.5 that you used to start Eclipse has been installed by default. It is a potential match for an execution environment 1.4 and since there is no other JRE installed, it is used as the JRE library on the project classpath.
The Eclipse compiler doesn't check if a method is defined in the JRE1.5 or 1.4 even if the project settings are compliance 1.4, target 1.2 and source 1.3. We have requests to add this kind of support in the compiler, but this is not the purpose of this blog. So since the compiler doesn't check that the method that is used in the project comes from a 1.4 JRE, the project compiles fine on the committer's machine. Then the code is committed and retrieved for the next nightly build.
The nightly build is however using a JRE 1.4 on the project's classpath to match the 1.4 execution environment requirement. And this is how a compile error is raised during the nightly build. It might seem obvious and simple enough so that readers are wondering why I talk about this.
Last week the problem arised twice. Once for the error mentioned above and the second time with this error:
The method valueOf(String) in the type Long is not applicable for the arguments (long)
So it seems that it might be worthwhile to explain how to prevent it this error once for all. The solution is quite simple.
Always install the JRE that corresponds to the project's execution context requirement. And if your project doesn't have such a requirement, edit the manifest file to add it.
If a 1.4 JRE is installed when the execution environment 1.4 is specified for a project, it will be used. If you want to be sure which one is used, check the preference page Window>Preferences>Java>Installed JREs>Execution Environments.
Then you check which JRE is set to be a perfect match for the execution environment you are using.
Once this is done, you are sure that the right JRE ends up in the project's classpath and that if you code compiles in your workspace, it will also compile in the Eclipse builds.
Let me know if you find this kind of blog useful or completely obvious and useless.
Olivier
Subscribe to:
Posts (Atom)