I would like to use the jgitver maven plugin to automatic define the version of eclipse plugins, features, repository that are built with tycho in pomless mode.
The version management of this 3 plugins are:
jgitver computes a version depending on git tree and tags, create a logical copy of pom, set the new version and associate the new pom to the current plugin in the maven reactor.
For tycho, version are defined in pom and in manifest.mf or feature.xml files. A version consistency check is performed.
When the pom is not defined, pomless maven generates a temporary pom file named .polyglot.build.properties using versions defined in manifest or feature file.
The input path are defined here and depends on PolyglotModelUtil.
The easier way would be a Jgitver evolution to locally update the feature.xml and manifest.MF. It would be a bad idea because a local file would be modified that is not compliant with the plugin philosophy.
A better way would be a Jgitver evolution to generate temporary feature.xml and manifest.MF files that would have been updated with the computed version. Then tycho and tycho-pomless should be forced to use them.
It seems to be possible if i succeed in setting a new ModelProcessor.LOCATION option
Do you think it's an effective way to solve this compatibility problem?
Do you see an alternative?
Thanks for your help.
You could also use directly the jgitver library to participate into your build environment ; it is a pure java library.
The library is the base of both the maven and gradle plugins.
Related
I am handling multi module Maven project in which I have defined a property productversion which is inherited by all child modules. I am using this even in the parent tag defined in child pom's. The build when ran is successful and the correct version jar is being deployed in local repository.
Problem I am encountering is that I am not able to build a child module in isolation. it is saying "Non-resolvable parent pom" . this might be because of using this property and maven install the pom file in repository and then on running; parent child relationship are read from local repository pom only.
Is this issue addressed in any of the Maven version?
Can we update the pom in local repo as part of the build process?
I would strongly recommend to upgrade to a more up-to-date version of Maven cause Maven 2.2.1 is EoL for a year now (has been done in february 2014).
To solve what you like to achieve you can use Maven 3.2.5 (or Maven 3.3.1)
Excerpt from the release notes:
A simple change to prevent Maven from emitting warnings about versions
with property expressions. Allowed property expressions in versions
include ${revision}, ${changelist}, and ${sha1}. These properties can
be set externally, but eventually a mechanism will be created in Maven
where these properties can be injected in a standard way. For example
you may want to glean the current Git revision and inject that value
into ${sha1}. This is by no means a complete solution for continuous
delivery but is a step in the right direction.
I am using Maven assembly plugin with which I generate single Jar file with all dependencies for my application (unpacked by definition in jarlib.xml given here: https://gist.github.com/knyttl/7cc0730ae0fb6947cbda). This dependency.jar can be then put on class path with my application.jar and run as java -cp application.jar:dependencies.jar my.class.Runner. The problem are however multiple versions of the same artifacts when unpacking jars.
For instance I am using org.apache.xmlrpc:xmlrpc-server:jar:3.1.3 which depends on javax.servlet:servlet-api:jar:2.3. In my application I need to use different, newer version of the javax.servlet, but when unpacking, the new version is skipped and the old one is used instead.
Is there a way to ignore the dependency given by xmlrpc-server?
Is there a way to prioritize the newer version of javax.servlet?
Is there a way to create single jar without unpacking the dependencies and being able to use them with -cp application.jar:dependencies.jar? When I tried to build the jar without unpacking, none of the inner jar classes were found when running the application.
Sounds like what you really want is the shade plugin - the ability to create a single jar with all of these included. https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
The best solution I found is using <exclusions> directly in the <dependency> tag directly in the pom, without any plugins.
On mvnrepositry, when you search for a certain module, there's a link to download the binary. For some versions it has a pom.xml file available for download instead of the jar. What are you supposed to do with that pom.xml? It seems like if I specify a version that does not have a downloadable jar, but instead downloadable pom.xml, my maven build will fail. Is what I'm seeing correct?
Modules that only have pom files are maven modules with pom packaging. They are used to aggregate multiple modules into one unit. You can use such a module as a dependency for your maven project. Maven will download the pom file, analyze the dependencies included in that pom file and download those & add it to your automatically.
Even modules that have jars (jar packaging) have a pom file associated with them. This pom file defines the other dependencies that are required for using it. Maven will automatically process and fetch those dependencies (transitive dependencies).
This makes specifying and managing dependency for any project. You will specify the top level modules that your projects directly depends on and other things required will automatically figured out and downloaded. It also makes it easier when you have upgrade to a new version - all the transitive dependencies will get upgraded automatically.
One of the reason that cause this is because of licensing issue.
License for such JARs prohibit public redistribution in such approach. So someone provide only the POM so that you can get the JAR yourself and install it to your local maven repo/ internal repo, together with the POM provided.
I wonder if it is possible, to stop Maven 3.0 downloading old libraries and use only distinct versions.
(prefering the local repo and the versions where i downloaded Javadoc and sources manually)
For example using JUnit 3.8.2, 4.8.1 and the newest 4.x, but never <3.8.1, 4.5, 4.6-Snapshot etc.
Background: I have my actual projects and local repo on first drive (SSD) with limited space.
If i try an maven archetype to start a new project (often for learning a new theme), maven like downloading i.e. junit 4.5
but i don't like to edit the pom manually looking over my local versions, thinking about compatibilties
and i don't like to purge and download the prefered dependencies again and again.
Are there any tools, plugins, settings or best practices to get this going ?
What i tried so far...
going Offline doesn't help cause my preferred IDE offer download manually only for doc+src
=> "Could not resolve dependencies... The repository system is offline but the artifact ... is not available in the local repository."
best practice for now is (netbeans) in context menu "Remove
dependecy" on project and "Add as Dependecy.." from local repository
tree. (like screenshots ?)
After reading much new stuff i finally agree to Spencer Kormos:
If you're using archetypes, there's not much you can do...
Best practice for me is now this:
Small solution
- create the pom using an archetype
- add <dependencyManagement../> decribing the prefered dependency in the top of the pom
- add <scope>provided</scope>
- optionaly you can add the <exclusions.. />
- remove the conflicting <version../> tags in the generated pom
- the <dependencyManagement../> section i will use for copy/paste in other projects
Greater solution (hopefully) ?
- create a parent/master pom with <dependencyManagement../> of prefered artifacts
- use the from archetype generated pom as module or child-project
- use the master pom for grouping dependencies with <packaging>pom</packaging>
Some of the stuff i read the last day only two links allowed :-(
Maven-Model (look for dependencyManagement under project)
Maven: The Complete Reference, Chapter 3.6.1. Grouping Dependencies
If you specify the versions in your pom.xml (as a dependency, or excluding an older version from a dependency), it shouldn't download any other jars than those specified (or excluded).
I have quite a situation here: another team is building a Flex SDK and delivers it as a huge set of separate SWC files. At this point I cannot make them build a single SWC file library.
I'm trying to use these files as Maven dependencies to pass to Flexmojos but they are like 40 files and I don't want to manage each of them as a separate dependency (after all they are parts of the same thing).
Is there a way to:
Install all of the SWC files as artifacts in the local repo? (with the same groupId and version and auto-generated artifactId I guess)
Import these as dependencies using a "wildcard" or plugin that generates dependencies at runtime or something?
this won't work that way. Dependency declarations can't be dynamic, this would break the build. What you can do is have your deployers create a rollup pom with packaging pom containing all of the SWC dependencies and deploy that pom into your nexus repository. You'd be able to use that pom dependency. The benefit would be that the pom is maintained in a single central location.
You can use the build-helper-maven-plugin to add artifacts to the Flex SDK project. As a result you can use the SDK project as a dependency and got all files which you can use.