| 3 | | This page gives a quick and easy way to create Fragment which can overwrite Plugin functionalities. |
| | 3 | This page gives a quick and easy way to create Fragment which can overwrite Plugin functionalities based on the developer fragment to allow logging to the console. |
| | 4 | |
| | 5 | **Problem** |
| | 6 | Logging should be done to a log file allowing to debug errors on user systems. However for developers that is inconvenient and logging to the console is preferred. This could easily be done through code changes however its easy to forget these changes and lose the log files. |
| | 7 | |
| | 8 | **Solution** |
| | 9 | Creating a fragment to the plugin with the log functionality that overwrites the default log file behavior. A second product file for developers will be created which is in sync with the normal product file but has the fragment as additional dependency. |
| | 10 | |
| | 11 | **Step by Step** |
| | 12 | * Create a fragment plugin |
| | 13 | * Eclipse main menu ''File'' -> ''New'' -> ''Project...'' |
| | 14 | * In the dialog choose ''Fragment Project'' from the ''Plug-in Development'' folder |
| | 15 | * In the following wizard specify the name and select the plugin whose functionality should overwritten (in case for the logging that is the core plugin that has the logging configuration) |
| | 16 | * In the fragment add a class with exactly the same name of the close you want to overwrite. The class also needs to be placed in the same package. |
| | 17 | * The function works that the code gets merged not replaced. That means if the original class has 3 methods and the fragment class only has one of these methods that has now different code, the other two methods will still be active and working. |
| | 18 | * This allows to selectively changed the functionality that needs to be changed but leave the rest of the code intact. |
| | 19 | * Create a copy of the product file which is used for developers. In that copy add the fragment as dependency. |
| | 20 | * It is important to keep the real product and the developer version in sync otherwise this is a severe source for errors. In addition it it necessary to be careful when using the ''Add Required Plug-ins'' button in the product content since this will always add the fragment. |
| | 21 | |
| | 22 | The following steps are necessary for the logging plugin and may not be necessary for all types of fragments. |
| | 23 | * Modify the **build.properties** of the fragment to generate a jar (developers.jar) |
| | 24 | {{{ |
| | 25 | bin.includes = META-INF/,\ |
| | 26 | developers.jar,\ |
| | 27 | bin/,\ |
| | 28 | src/ |
| | 29 | source.developers.jar = src/ |
| | 30 | jars.compile.order = developers.jar |
| | 31 | }}} |
| | 32 | * Modify the MANIFEST.MF to include the jar in the classpath and define the fragment as pathfragment by adding the following two lines in the end of the file (do not forget the " ." in the last line): |
| | 33 | {{{ |
| | 34 | Eclipse-PatchFragment: true |
| | 35 | Bundle-ClassPath: developers.jar, |
| | 36 | . |
| | 37 | }}} |
| | 38 | * In the MANIFEST.MF of the plugin that has the original code add the following two lines to make sure the jar is loaded: |
| | 39 | {{{ |
| | 40 | Bundle-ClassPath: developers.jar, |
| | 41 | . |
| | 42 | }}} |
| | 43 | * Since Eclipse chaching will prevent to that logging to the console will work more than once you have to follow the instructions [FixingLogIssueWithFragment here]. |
