I've been reading the docs for the deploy plugin, and am confused about the altDeployment repository parameters.
There are these three params:
altDeploymentRepository
altReleaseDeploymentRepository
altSnapshotDeploymentRepository
Whereas the altRelease and altSnapshot seem to be fairly straightfoward, I'm not sure what the altDeploymentRepository setting is for. Is that supposed to be a superset of the Snapshot and Release?
Can someone clarify the difference between the three settings and when to use which?
altDeploymentRepository
No idea
altReleaseDeploymentRepository
Let's say you are going to build the artifact which does not have any SNAPSHOT attached to your pom file. Ex: 43.0.1 (this is release version) 43.0.1-SNAPSHOT (this is SNAPSHOT version), release version will always be unique...also it means you have properly tested all the code.
So when you define releaseRepo, your artifact will load into the release repository
altSnapshotDeploymentRepository
SNAPSHOT artifact is useful for initial testing: once you build the code, respective artifact will load into the snapshot repository
Related
I'm trying to do a clean install on this project
https://github.com/jberet/jberet-wildfly-samples
I'm stucked with this error:
Could not resolve dependencies for project
org.jberet.samples:clusterInfinispan:war:1.4.0.Alpha-SNAPSHOT: Failed
to collect dependencies at
org.jberet:jberet-wildfly-cluster-infinispan:jar:1.3.0.Final: Failed
to read artifact descriptor for
org.jberet:jberet-wildfly-cluster-infinispan:jar:1.3.0.Final: Failure
to find org.jberet:jberet-wildfly:pom:1.4.0.Alpha-SNAPSHOT
It appears that artifactory is ONLY available on search.maven.org
I tried to do either a force update -U and to manually clean the local repo directory, but nothing changes.
I wonder if I have to manually add the above repo or should automatically seek there
Any hints?
I think he didn't publish 1.4.0.Alpha in maven center.
You can try to change 1.4.0.Alpha to 1.3.0.Final in pom.xml like this
<parent>
<groupId>org.jberet</groupId>
<artifactId>jberet-parent</artifactId>
<version>1.3.0.Final</version>
</parent>
<groupId>org.jberet.samples</groupId>
<artifactId>wildfly-jberet-samples</artifactId>
<version>1.3.0.Final</version>
And use mvn clean install -Pwildfly
Wow, you are right: https://search.maven.org/artifact/org.jberet/jberet-wildfly-cluster-infinispan/1.3.0.Final/jar
I'm not sure if anybody here on Stackoverflow will be able to help you.
Continue your issue with jberet's community: https://github.com/jberet/jberet-wildfly-samples/issues/2 you have to solve it with them.
EDIT:
Now that I think more about it, it's also possible to add their SNAPSHOT repository to your settings.xml file: https://maven.apache.org/settings.html#Repositories but I didn't find link to their repository.
Anyway: witnessing this I would stay away from jberet project, because this is a big failure on their part.
Read the maven error: "failure to find org.jberet:jberet-wildfly:pom:1.4.0.Alpha-SNAPSHOT" means there is a a dependency referencing org.jberet:jberet-wildfly:pom 1.4.0.Alpha-SNAPSHOT.
Either the repository forbids deploying SNAPSHOT (and it make sense for central)
either your configuration forbids downloading SNAPSHOT (see http://maven.apache.org/settings.html#Repositories).
You should check local pom.xml referencing 1.4.0.Alpha-SNAPSHOT and replace it with a non SNAPSHOT (1.4.0.Alpha for beginners).
I want to use a range for the version of some dependency. But I don't really get it how it should be defined for my case.
Here's the results of lookup - maven-metadata-nexus.xml file.
<versioning>
<latest>0.1.0-SNAPSHOT</latest>
<versions>
<version>0.0.13-SNAPSHOT</version>
<version>0.0.14-SNAPSHOT</version>
<version>0.0.15-SNAPSHOT</version>
<version>0.0.16-SNAPSHOT</version>
<version>0.0.17-SNAPSHOT</version>
<version>0.1.0-SNAPSHOT</version>
</versions>
<lastUpdated>20190826092951</lastUpdated>
</versioning>
I want to import the latest 0.1.x dependency, so I thought writing range this way would do the thing
<dependency>
<groupId>my.group.id</groupId>
<artifactId>my-artifact</artifactId>
<version>[0.1, 0.2)</version>
</dependency>
However, maven says that there's no version of my artifact available.
Defining range as [0.1.0-SNAPSHOT, 0.2) fixes the problem, but I don't really understand why I need to be so specific with the boundary and is it a good practice or not. What's the right way to define such ranges?
Maven treats SNAPSHOT version differently than "normal" versions.
"normal" (published in a repo) version is typically immutable. It can't be updated nor removed and no matter when you access it will still be the same.
SNAPSHOT versions are the opposite of that. They can change at any time (think work in progress).
Typically SNAPSHOTs are only to be found in your local repo. If you want to use SNAPSHOTs from remote repo you have to explicitly tell Maven that repo provides SNAPSHOT versions.
With that distinction in mind, Maven folks have decided that
Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. There is no need to compile against development code unless you are explicitly using a new feature, under which the snapshot will become the lower bound of your version specification.
Since approx. 72h I'm getting The job exceeded the maximum time limit for jobs, and has been terminated. on TravisCI which seems to be related requesting artifacts from mvnsearch.org, e.g. https://travis-ci.org/document-scanner/document-scanner-aggregator/builds/266942578. I assume it's a remote repository which I'm not using, but some of the project's dependencies are.
mavensearch.org seems to be unreachable or responding very slowly. I don't find any news on their operational status. It's odd that the issues isn't fixed within 72h, so I assume a long-time issue.
The only possible solution I could imagine would be to add the download and installation of a maven proxy to the Travis CI build script and proxy mavensearch.org in a Maven settings.xml file. Is there any way to avoid this?
It doesn't work to use the mirror element in ~/.m2/settings.xml because it references the repository id in referenced POMs which can be those of transitive dependencies and can change if snapshots are used and need to be checked and eventually adjusted after every version change.
A couple of actions may be done:
The Common Build Problems: My builds are timing out - Travis CI answer provides a couple of solutions. One of them is «to extend the wait time» for the Maven process.
Enable caching of the Maven dependencies: Caching Dependencies and Directories: Caching directories (Bundler, dependencies): Arbitrary directories - Travis CI.
Use a repository manager: «act as dedicated proxy server for public Maven repositories».
Additional references:
Nexus example:
Maven Repositories - Nexus Repository Manager 3 - Sonatype Help. See «Browsing and Searching Maven Repositories» (general information) and «Configuring Apache Maven» (settings.xml-related information) sections.
«User manual» for the use case: Using Nexus 3 as Your Repository – Part 1: Maven Artifacts | TheNEXUS.
The general question: How does one mirror a maven repository?.
Enabling caching on Travis CI by adding
cache:
directories:
- $HOME/.m2
to .travis.yml turned out to be not the solution at all or only a temporary one (for approx. 40 builds over the last week; because mvnsearch.org became available again or for other reasons hard to figure out), I found the following more promising solution (which is way easier than setting up a Nexus repository manager instance which can be used as a mirror):
Add
- echo -e '<?xml version="1.0" encoding="UTF-8"?>\n<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.1.0"\n xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">\n <mirrors>\n <mirror>\n <id>mvnsearch-unavailable</id>\n <name>mvnsearch-unavailable</name>\n <mirrorOf>mvnsearch</mirrorOf>\n <url>http://repo1.maven.org/maven2</url>\n </mirror>\n </mirrors>\n <profiles>\n <profile>\n <id>no-mvnsearch</id>\n <repositories>\n <repository>\n <id>mvnsearch</id>\n <url>http://www.mvnsearch.org/maven2</url>\n <releases>\n <enabled>true</enabled>\n </releases>\n <snapshots>\n <enabled>true</enabled>\n </snapshots>\n </repository>\n </repositories>\n </profile>\n </profiles>\n <activeProfiles>\n <activeProfile>no-mvnsearch</activeProfile>\n </activeProfiles>\n</settings>' > $HOME/.m2/settings.xml
- cat $HOME/.m2/settings.xml
to .travis.yml which will override uses of http://www.mvnsearch.org/maven2 in any hard to control transitive dependency and use the Maven central repository http://repo1.maven.org/maven2 which covered all dependencies in my case (it might not in other cases).
Note that Murphy's Law applies as it does to anything: Maven 3.1.1 ignores this setting even though it claims to use the mirror in its debug output (ouch!).
The build is now 7 minutes faster than it was with the temporary working caching solution.
When I add Neo4j 1.9.M05 to my project dependencies (with maven), I'm getting the following error in eclipse:
ArtifactDescriptorException: Failed to read artifact descriptor for org.neo4j:neo4j-kernel:jar:tests:1.9.M05: UnresolvableModelException: Failure to find org.neo4j:parent:pom:1.9.M05 in http://m2.neo4j.org/releases was cached in the local repository, resolution will not be reattempted until the update interval of neo4j-release-repository has elapsed or updates are forced
This seems to make sense because the URL "http://m2.neo4j.org/content/repositories/releases/org/neo4j/parent" does not exist. Was anybody able to use 1.9.M05 already? Is there another public repository where I can find this dependency?
ps: does anybody know when the neo4j-cypher-dsl module gets updated to 1.9.M05?
For now, you can bypass this problem by manually placing this parent pom in your local maven repository (or upload it to your companies nexus, or ...).
If the parent has not been deployed, I would suggest you file a bug report with the authors, as this won't work. They'll either have to deploy the parent, of spin off a new release.
The version-numbers for our jars have to be longer them x.x.x.
We would rather need x.x.x.x to integrate some old-fashioned self-made mechanism.
This is, because we tag our software with x.x.x and as soon as we have a delivery to a customer one specific jar has to be build exactly at this point of time to fit to another backend,
which communicates with our program. For that reason this one jar has the version 2.3.4.1,
when generated and in next delivery of the same Version it is build and named 2.3.4.2.
Now artifactory cannot handle this an doesn't save more than x.x.x.2 in some cases.
So we thought of maybe edit the regular expression in the maven repository layout (see attached Screenshot) Because testing the path in the field below shows,
that it cannot handle the version number. Of course for the rest of our jars still x.x.x has to work..
For Example here is the maven-metadata.xml
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>com.firm</groupId>
<artifactId>someid</artifactId>
<version>1.5.1</version>
<versioning>
<latest>1.5.1</latest>
<release>1.5.1</release>
<versions>
<version>1.4.62</version>
</versions>
<lastUpdated>20120926073942</lastUpdated>
</versioning>
</metadata>
The folder structure looks like:
someid
- 1.4.62
- 1.4.62.1
- 1.4.62.2
- 1.4.62.3
If we deploy an new artifact version (1.4.62.1), the maven-metadata.xml contains the 1.4.62.1 version.
But the artifactory overrides the version number (1.4.62.x) to (1.4.62) after an unspecified time. It seems that the artifactory only support major, minor and revision numbers, and deletes the buildnumber.
Now we looking for a solution do disable this behavior.
We use the JFrog Artifactory version 2.5.0 (rev. 13086).
I apologize in advance that this will be an unsatisfactory answer for you.
Your version format is incompatible with the version format used by Maven. Maven uses a .. format for version numbers. Anything after this needs to be prefaced with a dash for it to be properly used by Maven. For more information about how version numbers are used and formatted in Maven, please refer to this section of the Maven book: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html