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.
Related
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)
I have a Tycho build project that successfully builds a feature and its bundles as well as a p2 repository. Everything is built using .qualifier and -SNAPSHOT. For example:
My MANIFEST.MF file in my bundle is has the version of the bundle set to something like ...
Bundle-Version: 1.0.3.qualifier
My feature is also has its version set to ...
<feature version="1.0.3.qualifier"
id="com.myurl.my.feature"
label="My Feature"
provider-name="My Company">
My pom.xml file has its version set like so...
<version>1.0.3-SNAPSHOT</version>
This all works great. The resulting bundles have the qualifier replaced with the standard timestamp, and the resulting built manifest file's version looks like this...
Bundle-Version: 1.0.3.201402101829
The resulting plugin jar file has a name as such as...
com.myurl.mybundle.1.0.3.201402101829.jar
My artifacts that get deployed to my Maven repository have the -SNAPSHOT
1.0.3-SNAPSHOT
What I want to do is change my version numbers from using .qualifier and -SNAPSHOT at release time so that I can deploy to my Maven repository a bundle that doesn't have a -SNAPSHOT associated with it.
I use this command to change my version numbers...
org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.0.3
After I execute this command, I run my maven build, and the resulting artifacts now have version numbers that don't have the .qualifier and -SNAPSHOT, which is what I expect.
But... What I would like to do is have the resulting bundles have a timestamp as they did when I was using the .qualifier, but I want the artifacts that are deployed to my Maven repository to not have the -SNAPSHOT modifier. Is this possible using some thing like the ...
-DforceContextQualifier
... thats availabe in the tycho-packaging-plugin? If so, how?
We have moved from Archiva to Nexus and are still using Maven 2.
We execute eclipse:eclipse locally so that Eclipse .project and .classpath files are generated, based on the dependencies in the POMs, and then we import the projects into Eclipse to do our development. We don't use M2Eclipse for a variety of reasons.
Since using Nexus, we have the problem that projects don't always reference each other in the workspace, rather they reference the respective JAR.
I have noticed that Nexus is appending a timestamp to the JAR name, and the MVN output states, e.g.:
[INFO] Artifact myapp-bom:jar:7.3.0.2.1-SNAPSHOT already available as a workspace project, but with different version. Expected: 7.3.0.2.1-20120508.115037-68, found: 7.3.0.2.1-SNAPSHOT
I get the feeling that is the reason why eclipse:eclipse generates .classpath files which contains JAR references (based on local maven repo) rather than project references. When we used Archiva (and there were no timestamps) then we used to get project references, and that is exactly what we want.
Has anyone else had this problem and how is it solved? I read that maven 3 forces timestamps to always be generated. Again, how do you get eclipse:eclipse to generate sensible .classpath files?
Cheers,
Ant
PS - some of our projects come from different SVN repositories. It seems that if the Eclipse Projects are refernced in the parent pom, eclipse:eclipse creates a project reference, but if the Eclipse Projects are from a different parent pom, but still in the workspace, then it can only generate JAR references.
The problem was resolved by using maven-eclipse-plugin (eclipse:eclipse) version 2.9, rather than 2.8! Doh...
In my RAD, when I open up the MANIFEST.MF file for an ejb project, because I need to add dependencies, in the UI, I see (under dependencies):
Select other JARs or modules contained by the EAR that are required by this JAR or module. Only valid or existing dependencies are shown.
What does it mean by Only valid or existing dependencies. I say this because not all projects in the workspace are listed under Dependencies. And the project that I need to add as dependency is not listed here. What is the reason for this?
I found the solution although do not understand the reason. I need to add the project jar under JAVA EE Module Dependencies
I changed the version from jFreeChart in the pom.xml of my maven project from 1.0.12 to 1.0.13.
Now I get the error
"The type org.jfree.ui.layer cannot be resolved to a type. It is indirectly referenced from required class files."
What does this mean? I just updated the jfreechart dependency.
The type is in the JCommons library. I think the problem is that the JFreeChart has not been properly distributed to maven in version 1.0.13. In the IBiblio directory listing, you can see that a .pom file is missing (as opposed to version 1.0.12, where it's present).
This means that maven has no ideas what the dependencies are. It still downloads the artifact through it's filename by convention, but it doesn't know anything about the context.
Now you can either complain to the vendor and demand a proper pom or create your own pom file (start with the old version and adjust it until things start working) and deploy it to your company's repository (or your local repository) using install:install-file or deploy:deploy-file.
My guess is that you'll at least have to include the following dependency
<dependency>
<groupId>jfree</groupId>
<artifactId>jcommon</artifactId>
<version>1.0.15</version>
</dependency>
(If you want to do it the easy way, just add the above dependency to your own project pom)