The result of the call to
Maven.resolver().resolve("groupId:artifactId:version").
withoutTransitivity().asSingleFile();
e.g.
Maven.resolver().resolve("myProjectGroupId:myProject:1.1")
.withoutTransitivity().asSingleFile();
results sometimes in the correct jar file with the name
artifactId-version.jar e.g. myProject-1.1.jar,
but sometimes I get a file
artifactId-unknownNumericalId.jar e.g. myProject-6244235517268120190.jar
that doesn't exist in the maven repository. I couldn't find any hint under which circumstances I get the right file or I get the file with the unknown id.
Could someone help me here?
Related
I have a gradle.build file https://github.com/JetBrains/java-annotations with
project(':java5').archivesBaseName = 'annotations-java5'
line and I have a error there:
* What went wrong:
A problem occurred evaluating root project 'java-annotations'.
> Project with path ':java5' could not be found in root project 'java-annotations'.
I have no idea what is "project" keyword syntax, could you point me to the proper documentation? Could you tell me what went wrong during "gradle build"?
Thank you!
The project method locates a project by path, which in this case is java5 relative to the root project (indicated by the leading :). As seen in the javadoc this method returns another Project instance, and here its archiveBaseName property is accessed.
I have a gradle build which generates war file. I want to copy war file to my application servers' dropins directory which is somewhere outside of project directory. I have following copy task to do this.
task copyWarToDropins(type: Copy,dependsOn:[war]) {
from './build/libs/bds-service-token-1.0-SNAPSHOT.war'
into file('/apps/dropins') // want to copy to 'C:/apps/dropins' directory
rename { fileName -> 'bds-service-token.war' }
}
build.dependsOn copyWarToDropin
It evaluates /apps/dropins relative project directory and does copy there. I have tried many ways I can think of but could not make it copy to C:/apps/dropins directory.
Can someone please help?
First, please note that using into file(...) is redundant, as each call to into(...) will be evaluated via Project.file(...) anyhow.
As you can read in the documentation , file(...) handles strings in the following way:
A CharSequence, including String or GString. Interpreted relative to the project directory. A string that starts with file: is treated as a file URL.
So, one way to solve your problem could be using an absolute file URL.
However, if you continue to read the documentation, you will see that Java File objects are supported. So you could simply create such an object:
into new File('C:/your/absolute/path')
I have a pom for a couple of modules. When checking one of the files of this module:
./sources/target/build/xxxxx/xxxxx-2.13-jar-with-dependencies.jar
./compiled/target/build/xxxxx/xxxxx-2.13-jar-with-dependencies.jar
the required result is the following (without the version):
xxxxx-jar-with-dependencies.jar
I tried different ways like the <finalName>, <warName>, <bundleFileName>, <outputDirectory>, <stripVersion> but none of them seems to be working, the result I am getting by using most of them is:
./sources/target/xxxxx-jar-with-dependencies.jar
./sources/target/build/xxxxx/xxxxx-2.13-jar-with-dependencies.jar
./target/xxxxx-jar-with-dependencies.jar
./compiled/target/xxxxx-jar-with-dependencies.jar
./compiled/target/build/xxxxx/xxxxx-2.13-jar-with-dependencies.jar
it's the result I need, but not on the files I want.
I have a TeamCity (9.0.2) build configuration which contains the following artefact path pattern:
App\Agent\**\bin\%env.Configuration%\** => Deployment\AgentBuildPackage.%env.ApplicationVersion.EMX%.%system.build.number%.zip
which will create a file named something like AgentBuildPackage.4.5.0.185.zip in an artefact folder named Deployment
The current structure is like this:
Deployment/
AgentBuildPackage.4.5.0.185.zip/
MyFirstServiceFolder/
bin/
Debug|Release/
All the Files
The artefact archive contains all the folders it finds under App\Agent which is great. What I can't figure out is how to flatten those individual folders so they no longer contain the /bin/Release sub-folders.
What I want is
Deployment/
AgentBuildPackage.4.5.0.185.zip/
MyFirstServiceFolder/
All the Files
Can anyone tell me how please?
You can specify target folders within your target archive by using the ! character after the name of the .zip file. Like this:
folderA\** => output.zip!/afolder/
Depending on how many service folders you have, this could be quite verbose, as you'll need to do it for each one, but it should do what you've described:
App\Agent\MyFirstServiceFolder\bin\%env.Configuration%\** => Deployment\AgentBuildPackage.%env.ApplicationVersion.EMX%.%system.build.number%.zip!/MyFirstServiceFolder/
Here's the documentation page on specifying artifact paths if you haven't seen it yet: https://confluence.jetbrains.com/display/TCD9/Configuring+General+Settings#ConfiguringGeneralSettings-PathsPatterns
I have seen two different syntax in Karaf to add a repo, e.g.,
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml/features
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml
Can someone explain the difference between the 2? I believe they are both referring to a features file but they are in different locations?
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/xml
Doesn't actually work for me. BUT I think can break down what is happening.
mvn:org.apache.camel/camel-example-osgi/2.10.0 is a maven URl with an implicit 'type' and 'classifier'. The type is 'jar' and the classifier is empty, by default. Therefore it resolves to a file called camel-example-osgi-2.10.0.jar. (artifactId-version[-classifier].type)
In this case:
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml is a type of 'xml' and no classifier. This resolves to a file called camel-example-osgi-2.10.0.xml, which doesn't exist.
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml/features is a type of 'xml' and a classifier of 'features'. This, then, resolves to a file called camel-example-osgi-2.10.0-features.xml . We can look on the server and see that this file exists: http://repo1.maven.org/maven2/org/apache/camel/camel-example-osgi/2.10.0/
I can't find good documentation for it but 'classifier' adds the -$classifier to the filename. This is how some maven artifacts have a classifier of -jdkN and -jdkM or -jdbc4 or -jdbc3 on them.
References: https://ops4j1.jira.com/wiki/display/paxurl/Mvn+Protocol
http://maven.apache.org/pom.html#POM_Relationships