What impact will be happen if I change the Bundle-Version which present in Manifest.MF file?
Also I could not understand why we used Bundle-Version, Manifest-Version, Bundle-ManifestVersion into Manifest.MF file?
Manifest-Version is the version of the Java manifest specification that this manifest uses - normally always 1.0. You won't normally change this.
Bundle-ManifestVersion is the version of the OSGi manifest specification that this manifest uses. Again you won't normally change this.
Bundle-Version is the version of the plugin in the form 'major.minor.micro.qualifier'. 'qualifier' is usually some sort of build id. You will normally increment one of 'major', 'minor' or 'micro' each time you change the plugin.
OSGi uses the term 'Bundle' for what Eclipse calls a 'plug-in'.
Bundle-Version - The version of the OSGi bundle (in Eclipse bundles are also called plug-ins): bundles can define dependencies to other bundles in a version range
Manifest-Version - The version of the JAR Manifest format (up to now 1.0)
Bundle-ManifestVersion - The version of the OSGi Manifest format which extends the JAR Manifest format (2 since release 4)
Related
It's a .jar available in various versions at Maven Repo.
But what category is it? It is published by org.codehaus.groovy, the same outfit that I get my groovy-all dependency from. I also find that import groovy.sql doesn't work in a script unless I specifically include this dependency. So it would appear not to be part of the core language.
Outside a Gradle context I find that I have to manually put the .jar file under ~/.groovy/lib in order to use it. If I put the wrong version (e.g. 2.5.9 for 3.0.2) under ~/.groovy/lib the script won't run... even if I'm not using groovy.sql at all!
Is this a "dependency"? It seems a typically powerful and hassle-free Groovy way of manipulating databases. Are there any other powerful add-on (non-core) Groovy .jar file modules like this, which have to be manually placed under ~/.groovy/lib, that I should know about?
groovy consists of subprojects:
https://github.com/apache/groovy/tree/master/subprojects
and groovy-sql one of the subprojects
all subprojects are published in maven as separate libraries
prior to version 2.5 there was groovy-all-XX.jar that includes all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.4.19/
however starting from v 2.5 groovy-all represented by groovy-all-XX.pom that depends on all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.0/
so, to include all groovy features you have to specify groovy-all in your maven/gradle/... dependency
and finally useful site to dig dependencies:
https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-all/3.0.2
In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.
Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:
However, I am not able to reference that module in my module-info.java. I tried
require org.eclipse.swt.3.106.1.v20170926;
require org.eclipse.swt;
require swt;
None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and
jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d
says that the module descriptor can not be derived. Also see
Unable to derive module descriptor for auto generated module names in Java 9?
If I download a newer version of swt.jar from
http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip
I get following output that looks promising:
swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets
I also depend on org.eclipse.jface and could not find a seperate download for it.
=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?
Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.
requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'
or
requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar
but module-info.java does not seem to support such a syntax.
I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.
I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200
Edit
When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using
require org.eclipse.swt;
and having the Plug-in Dependencies in the Modulepath.
However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.
I created a min example at
https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin
and I filed a bug report at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089
Related questions:
How to use 3rd party library in Java9 module?
Unable to derive module descriptor for auto generated module names in Java 9?
Force Eclipse (Helios) to use a newer version of SWT at application runtime
JFace libraries stand-alone download (not picked from Eclipse plug-ins)
New Keywords in Java 9
What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.
Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.
This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:
Automatic-Module-Name: org.eclipse.swt
I created new xerces bundle from jar. I can see two org.apache.xerces bundles now - one from orbit 2.9.0 and "my" 2.11.0. If I try to export product then only the version from orbit is exported
I tried to specify version in dependency for org.apache.xerces using properties, but it does not help, the entry is also marked as erroneous (how to see the reason?).
I am using
Eclipse for RCP and RAP Developers
Version: Luna Service Release 1 (4.4.1)
Build id: 20140925-1800
I missed qualifier! I need to put e.g. 2.11.0.201411051547 instead of simply 2.11.0. That is not really what I want- modifying product configuration after each plugin build, but it helps to force export of missed bundle.
We use tycho-buildtimestamp-jgit as explained in the tycho wiki to create reproducible version qualifiers for bundles.
The bundle jars created in the target/ directory are still named bundle.name-1.2.3-SNAPSHOT.jar even though the MANIFEST.MF already contains the generated version qualifier.
Why isn't SNAPSHOT replaced with the generated qualifier? How can the pom.xml be adjusted to include the generated version in the bundle file name?
Every bundle built by Tycho has a Maven version and an OSGi/p2 version. Which one of the two versions you see depends on the context. E.g. in the target/ folder, being a Maven concept, you will see the bundle jar with the Maven version.
If you aggregate the bundle into a p2 repository (with the packaging type eclipse-repository), you'll see the bundle jar with a file name that includes the OSGi version.
Note that the tycho-buildtimestamp-jgit plugin only affects the OSGi version, i.e. the replacement of the qualifier literal. Maven's SNAPSHOT literal is never replaced by Tycho.
Alright, this is a little bit wierd. I've checkout apache-poi version 3.9 source code from
http://archive.apache.org/dist/poi/release/src/
But I can not find the source code for poi-xml-schemas. I have been googling but to no avail. Where is the code repository for these project? Is it a separate project from the poi source code or it is from some other project used as a library, but where is the code repository?
This is covered in the Apache POI FAQ (#14), from which I quote:
14. I can't seem to find the source for the OOXML CT.. classes, where do they come from?
The OOXML support in Apache POI is built on top of the file format XML Schemas, as compiled into Java using XMLBeans. Currently, the compilation is done with XMLBeans 2.3, for maximum compatibility with installations. (You can use the resulting classes on the XMLBeans 2.3 runtime, or any later version of XMLBeans. If you are currently using XMLBeans 2.2 or earlier, you will unfortunately have to upgrade, but this isn't common any more).
All of the org.openxmlformats.schemas.spreadsheetml.x2006 CT... classes are auto-generated by XMLBeans. The resulting generated Java goes in the ooxml-schemas-src jar, and the compiled version into the ooxml-schemas jar.
The full ooxml-schemas jar is distributed with Apache POI, along with the cut-down poi-ooxml-schemas jar containing just the common parts. The source jar isn't normally distributed with POI. It is, however, available from Maven Central - ask your favourite Maven mirror for the ooxml-schemas-src jar. Alternately, if you download the POI source distribution (or checkout from SVN) and build, Ant will automatically download the specification XML Schema, and compile it for you to generate the source and binary ooxml-schemas jars.
https://repo1.maven.org/maven2/org/apache/poi/ooxml-schemas/1.0/
has the ooxml schema ----- CTArray jar files.