Now with Apache ant to ensure compilation of a Java component as module,
it is now necessary to provide a `module-info.java` file and use **Java
11 or later**.
This passive registration registers all UNO services that are present in
a component's Java or Python implementation. This fixes issue #156.
To be considered as a UNO service a Java Class must have:
- An ctor with `com.sun.star.uno.XComponentContext` as unique parameter.
- A **static final** field `m_serviceNames` of type `String[]` (ie: an
array of String) and having as values the name of the UNO service. This
field can be private, protected or public, it doesn't matter.
For a Python class to be considered a UNO service it must:
- Exist a global variable `g_ImplementationHelper` declared as follows:
`g_ImplementationHelper = unohelper.ImplementationHelper()`.
- Exist a global variable `g_ImplementationName` declared as follows:
`g_ImplementationName = 'com.sun.star.MyServiceName'`.
- Exist a global variable `g_ServiceNames` declared as follows:
`g_ServiceNames = ('com.sun.star.task.JobExecutor', )`.
- Although this is not controlled, it will also be necessary for it to
have the following code:
```
g_ImplementationHelper.addImplementation(YourPythonClass, # UNO object class
g_ImplementationName, # Implementation name
g_ServiceNames) # List of implemented services
```
In order to improve the integration of **Ant** and `javac` now changes
to the Eclipse `.classpath` file will produce an update to the
`build.properties` file. This file has a new property
`uno.java.classpath` that allows to provide `javac` with all the
necessary dependencies when compiling.
If in Eclipse a sibling project is declared as a dependency then either
its jar archive (if it was produced by a `Build.jardesc` file) or its
`bin` folder (the folder where Eclipse puts the `.class` files) will be
available in the `uno.java.classpath` property of the `build.properties`
file.
This allows us to have compilations with `javac` (ie: **Ant**) that work
just as well as compilation by Eclipse's internal compiler.
Concerning the Java jar archives to be put in the `MANIFEST.MF`
`Class-Path` of a UNO Java project, there are two ways to do it:
- Either create a `lib` or `libs` folder at the root of the UNO project.
In this case all archives put in this folder are put in the `Class-Path`
of the `MANIFEST.MF`.
- In the absence of a `lib` or `libs` folder, all archives local to the
project and declared in the Eclipse build path will be put in the
`Class-Path` of the `MANIFEST.MF`.
- Only UNO projects and not configured by default will be listed in Eclipse.
- The Ant script requires version 1.9.1 minimum and will let you know if necessary.
- It is possible to change the SDK of any project.
If in Eclipse you have declared a Java version 9 or higher and there is
a file named **module-info.java** in the source folder then Eclipse will
automatically add the necessary libraries in the module path and no
longer in the class path as for a non-modular project.
Similarly LOEclipse will add the necessary LibreOffice libraries in the
module path if the project is modular.
Regarding the build of the oxt file, only the Ant script has been
updated to take into account the creation of modular archives.
Here is an update taking into account the idl file compilation utility
**unoidl-write** (see issue #130)
- Now if you change the LibreOffice and SDK version of a project (ie:
Project -> Properties -> LibreOffice Properties) then the
build.properties file will be updated if it exists.
- When generating the Ant script (ie: Project -> Export -> LibreOffice
-> Generate Ant script file) the build.properties file will be created
if it does not exist.
- The main builder of the UNO-IDL (ie:
org.libreoffice.ide.eclipse.core.builders.TypesBuilder.java) will
automatically switch to the utility provided by the SDK (ie: idlc or
unoidl-write) if it changes.
- The Ant script has been updated to take into account unoidl-write and
the different filenames on Windows (ie: unoidl-write vs
unoidl_write.exe).
- Many corrections on the integration of SDK tools have been made in
order to support Windows. However, concerning Windows, no tests has be
done because I am not able to do them.
- In order to take advantage of the warnings in Eclipse the
**CheckStyle** plugin has been restarted (ie: it was no longer correctly
configured) and all files whose code did not meet the requirements of
the `/build/checkstyle.xml` file have been updated. It is expected that
the file headers (license and copyright) will be modified in order to
avoid the last warnings still visible in Eclipse.
- Java 17 is now the minimum version. This seem to be required by the
various Eclipse archives that LOEclipse uses (ie: org.eclipse.jdt).
- The template java file
`java/source/org/libreoffice/ide/eclipse/java/registration/RegistrationHandler.java.tpl`
has been rewritten using generics so that Eclipse warnings stop.
- The test file
`core/source/org/libreoffice/ide/eclipse/core/wizards/pages/ManifestExportPageControllerTest.java`
has been moved to the
`core/source/org/libreoffice/ide/eclipse/core/unittests` folder to allow
error-free compilation. This seems to fix [issue
#125](https://github.com/LibreOffice/loeclipse/issues/125).
- All Java methods marked as deprecated have been updated to their
replacement method.
Following this PR there are still in the Eclipse problems:
- 21 warnings including 4 TODO.
- 72 infos corresponding to the file headers (license and copyright).
An uncompressed mimetype file at the beginning of the oxt files has been added. It is supposed to help with the recognition of the oxt file type on Apple platforms.
Updating the package.properties file will be done either through the CheckBoxTreeViewer or through the text editor. Changing one will change the other. The loading of this window has been optimized (a few seconds).
Files and directories that are symbolic links are now visible in the CheckBoxTreeViewer (ie: no more filtering) and taken into account in the build of oxt archives. This allows to benefit from a single source for the location of libraries and therefore easier updates.
1. extend the error info when the file RegistrationHandler.classes does not exist in the package defined by company prefix and outputextension
2. display the error dialog in syncExec thread
3. throw an exception when error with RegistrationHandler.classes file
When subdir "libs" in Project root dir exist, then all the Jars are used as external libs.
1. Listet into the main-jar meta.inf file
2. Copied into the generated otx file
