I'm trying to include spock-core-1.1-groovy-2.4 into my environment, but it seems it contains some statements in its MANIFEST.MF file, that are not quite legal, e.g. a dependency on net.bytebuddy;version="[1.6.0,1)" which gets me this error:
Status ERROR: org.eclipse.equinox.p2.artifact.repository code=0 Range
minimum "1.6.0" is not less then range maximum "1.0.0" (inclusion is
required at both ends if the versions are equal)
...when I'm trying to include it into my eclipse repository. Is there a workaround?
No work around. That statement is illegal. You need to either fix the statement or use a different version of the bundle which a valid manifest.
Related
I'm looking for a formal definition of version number formats for .NET Core project.json files.
version
Visual studio creates a default version number of "1.0.0-*". I would love for this to mean the * gets updated on successive builds (it doesn't). The build version number is 1.0.0. What does the * mean and what are the legal possibilities?
dependencies
I expected the dependency numbering to follow the nuget versioning rules given that KPM is basically a nuget front-end, but it doesn't appear to support bracket numbering (eg "[1,2)") - I get "not a valid version string" when I try anything other than a blank or x.x-* format.
Outside of the source, does anyone have a link to a formal definition?
I'm not sure what's wrong with looking into the source for a definition. I think that's the most accurate place to search, especially now that vNext is hosted on GitHub.
Looking at the exception described, we're pointed to SemanticVersion.cs.
In the method TryParseInternal, it's fairly obvious why you're running into issues when attempting to declare min/max versions that way. There is simply no handling for [,] or (,) built into that method.
If we look into the regular NuGet version specification, it's obvious that TryParseVersionSpec does have this handling built in.
As for documentation specifying acceptable formats, you'll probably have to wait until it's out of CTP status. If you believe it's an issue, you should document it in GitHub. The contributors are very responsive to these types of issues. Personally I'm not sure if there's a need for setting a maximum version of a dependency when it's deployed with your build.
I am trying to set conflict managers in Ivy, but I can't find a concrete example of how to set them. For example, to set the "strict" manager, what would this look like?
<conflict-managers>
???
</conflict-managers>
<rant>
Yeah, isn't Ivy documentation a hoot! I mean, does it have to be well organized and complete? Does it really have to make sense. I mean, it's not like my job depends upon it!
Wait a second, it does...
</rant>
Sorry, I have to get the state of Ivy documentation off my chest. It makes Maven documentation look wonderful in comparison.
The best book on Ivy I've found is Manning's Ant in Action. It's a seven year old book that's out of print (but is still available as an ebook. If it wasn't for this book, (which is using Ivy 1.4), I would have been completely lost. Unfortunately, it doesn't delve deep into the Ivy settings.
There is a listing of all of the possible conflict managers buried deep in the Ivy documentation.
all this conflicts manager resolve conflicts by selecting all revisions. Also called the NoConflictManager, it doesn't evict any modules.
latest-time this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
latest-revision this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions.
latest-compatible this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end, this conflict manager does not allow any conflicts (similar to the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
strict this conflict manager throws an exception (i.e. causes a build failure) whenever a conflict is found.
I haven't played around with them, but I believe you simply do the following in the ivy-settings.xml:
<conflict-managers>
<latest-revision/>
</conflict-managers>
You can also define conflict management in your ivy.xml too which might be a bit more practical since it can be defined on a module-by-module basis.
Of course a few examples would have gone a long way with this, but the Ivy documentation doesn't provide many.
The best book on Ivy I've found is Manning's Ant in Action.
That was me. Ivy has moved on a lot since then, and so have builds
One issue with the ivy conflict managers is that it differs from maven, whose policy is "shallowest on the graph first", that picks the closest one. This is good if you explicitly ask for a version, bad if you have >1 transitive dependency when "closest" isn't what you want.
With ivy you can hit the strict resolve which says "you have to explicitly resolve every single conflict in your dependencies". This adds extra work # build time, but has a key result: if you explicitly declare the versions of things you want, you are now in control of what you have in your classpath.
The Ivy reference documentation strictly follows the XML tag structure of the ivy.xml and ivy-settings.xml files. You are expected to extract the information required directly from the document structure.
Decoding from the Ivy docs:
The conflict-managers tag is for declaring what conflict managers a project may use and configuring them if they accept configuration, not for setting the conflict manager to use.
<conflict-managers>
<latest-cm name="mylatest-conflict-manager" latest="my-latest-strategy"/>
<compatible-cm name="my-latest-compatible-conflict-manager" latest="my-latest-strategy"/>
</conflict-managers>
The settings tag has an attribute for choosing the default conflict manager:
<settings defaultConflictManager="strict"/>
Or in an ivy.xml:
<dependencies>
<dependency.../>
<conflict manager="strict">
</dependencies>
Note that most of the conflict managers are more liberal in their interpretation of your intentions than you would expect. Two examples:
* Branches are considered irrelevant, if a dependency is available on two branches the "latest" family of resolvers will pick the latest available from either.
* Both the "latest-time" and "latest-revision" resolvers ignore version constraints except to set boundaries on the matching space. e.g. if a depends on b-1.0 and c-1.0 but c-1.0 depends on b-5.0 then you will get b-5.0 despite it not meeting the constraint requested.
I assume your need is result of discovering one of these design flaws.
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
The Maven POM schema is version 4.0.0.
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
Actually, the configuration element of a plugin can contain anything. So <foo>bar</foo> is valid (and will just be "ignored" by a given plugin if it's an unknown parameter).
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
This change has been introduced for the resolution of MEAR-46 as we can read in the (approximative) comment of the svn commit: r471886.
Added defaultLibDir as an alias of defaultJavaBundleDir which is more understable
If you look closer at the diff, you'll see that defaultLibBundleDir is the new name of the parameter and that the old defaultJavaBundleDir is declared as an alias.
So both work, both do the same thing, but only the "new" one is documented in the parameters list of the ear mojo. You can safely change to defaultLibBundleDir and this will make things more clear.
Also worth noting is that the Maven Integration for WTP eclipse plugin (m2e-wtp) only supports the documented defaultLibBundleDir option, not the older defaultJavaBundleDir.
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultLibBundleDir
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultJavaBundleDir
In my project, there are 2 libraries, each of which depend on the XML parsing class java.xml.parsers.DocumentBuilderFactory. Each of these libraries reference the file from different jar (one gets it from a jar called xmlParserAPIs while another gets it from xml-apis-1.0.b2.jar). Unfortunately there are different versions of the class in each of these files so I am seeing runtime errors, depending on the order they are loaded. Both of these xml jars are transitive dependencies of 3rd party libraries. Is there a good way to handle this conflict?
edit: I'm not sure if it makes a difference on how to handle the problem but this only happens in testing because one of the dependencies is in the test scope.
thanks,
jeff
(...) Unfortunately there are different versions of the class in each of these files so I am seeing runtime errors, depending on the order they are loaded.
In theory, xml-apis.jar and xmlParserAPIs.jar (from xerces2-j) are the same JARs but with different names, xmlParserAPIs.jar being deprecated for years (see this message and this one).
If your dependencies relies on different and incompatible versions of xml-apis.jar, I would say that these dependencies are mutually exclusive, in other words incompatible, at least for the versions you're using. The only solution would be to find versions with a converging dependency.
In case they could use compatible versions, use a dependency exclusion for xmlParserAPIs.jar to use xml-api.jar only.
I'm not sure if it makes a difference on how to handle the problem but this only happens in testing because one of the dependencies is in the test scope.
No, this just explains why you don't get the problem at runtime (because the test scoped is not on the classpath then and, obviously, doesn't conflict).
I've a repository containing snapshot artifacts with timestamps.
I want to create an assembly, that contains the dependencies. This works fine. But the artifact names contains the timestamp. So i wonder how to remove the timestamp from filename for the assembly only.
I've used this dependencySet:
<outputFileNameMapping>${artifact.artifactId}-${artifact.version}.${artifact.extension}</outputFileNameMapping>
But version seams to contain already the timestamp. So is there any chance to get a 1.1.1-SNAPSHOT instead of 1.1.1-20100323.071348-182?
I'm using version 2.2-beta-4 of maven-assembly-plugin.
Could you try the following for the outputFileNameMapping:
${artifactId}-${baseVersion}.${extension}
According to issues like MASSEMBLY-67, MASSEMBLY-91:
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use ${version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.
Update: After feedback from the OP, the exact syntax is (wasn't totally sure of this):
${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}
I faced a similar issue when trying to build a bundle with the assembly plugin which contained a folder with the version number (I'm packaging WSDLs and XSDs).
The workaround I found is quite simple, I put the actual version number in a property (e.g. 1.0), which makes it available in the bundle.xml file for the assembly plugin, and set the pom version's to:
<version>${service.version}-SNAPSHOT</version>
This way the content of my package isn't influenced by the SNAPSHOT marker, in particular it isn't modified when doing the release.