Is there a plugin available for maven which i can use to generate all the dependencies of a project ? For example I have a server folder which contains folders like below
-server
--test1
--test2
--test3
when i run a particular comand from server folder it should generate all the dependency info in the target folder of server. I know if I use dependency:analyze-report it will generate in all the folders target, but I want then all together in the top folder. Please let me know if there is any way.
Related
I really don't have much experience in developing let alone using build tools.
I was assigned a task to build dependencies locally and get the jar files.
say I have a list of deps (GAV) like this:-
1. org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC
2. com.auth0:java-jwt:3.18.2, etc
3. openapi4j:openapi-operation-validator:1.0.7, etc
So i was able to download the source code url from maven repository and source code from github programmatically, for example :-
org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC - https://github.com/JetBrains/kotlin
com.auth0:java-jwt:3.18.2 - https://github.com/auth0/java-jwt
openapi4j-openapi-operation-validator-1.0.7 https://github.com/openapi4j/openapi4j
but there are many build.gradle files in different directories, how do I know which directory should I move into before running the gradle build command.
Things I have already tried and failed:-
For deps like this openapi4j:openapi-operation-validator:1.0.7, i can directly go into the openapi-operation-validator folder in the Github repo (https://github.com/openapi4j/openapi4j ) and run the gradle build command, but not all projects are structured like that I guess?
For deps like this com.auth0:java-jwt:3.18.2, the artifactId (java-jwt
) is already present in the github path (https://github.com/auth0/java-jwt), so i can run the gradle build command on the root github repo.
From the spring guides , among all the Gradle.build files available I can check which file has:-
jar {
archiveBaseName = <artifactId>
archiveVersion = <version>
}
, then I can move to that dir and run Gradle build, but not all build.gradle files have this.
None of the above approaches are concrete, is there any other firm approach that I can use to tackle the problem?
Your approach is generally correct.
You need to find the source code in github/gitlab/wherever, read the readme file and try to build it with whatever build tool was used there.
This may or may not work.
I downloaded maven gz file, unzipped same, but i dont know where the m2 is stored. I imagine im missing a step but i cant see what one?
Is there aninstall script etc?
[root#atddpvm5 apache-maven-3.5.4]# cd /var/tmp/apache-maven-3.5.4/
[root#atddpvm5 apache-maven-3.5.4]# ls
apache-maven DEPENDENCIES doap_Maven.rdf LICENSE maven-builder-
support maven-core maven-model maven-plugin-api
maven-resolver-provider maven-settings-builder NOTICE README.md
CONTRIBUTING.md deploySite.sh Jenkinsfile maven-artifact maven-compat
maven-embedder maven-model-builder maven-repository-metadata maven-
settings maven-slf4j-provider pom.xml src
By default the .m2 folder is stored in the home folder of the user. In this case since you are using root, the path is most likely /root/.m2. You also have to use the -a switch with ls to see that folder, since it's a hidden folder (it starts with a .). Note that the folder will only be created on the first usage of Maven, i.e. when you call a maven command on a maven project, like mvn clean install.
Additionally it looks like you have downloaded the source distribution of Maven, which only makes sense if you want to work on Maven itself. You might want to download the binary distribution, if you just want to use it.
I am trying to create a maven-plugin that generates new files based on a template file (basically using the FreeMarker language). I can successfully generate the files if I run the maven plugin from the directory of my maven-plugin project since my plugin accesses the template file based on a relative path.
However, if I try to run the plugin in some other java project directory, I cannot find the template file. I do not want to copy the templated file into the new java project.
I searched around to see if the maven plugin can access files within itself when another project is using the plugin but wasn't successful. Most of the documentation refers to accessing the java project files, and not the maven-plugin files.
Is this even possible or is there a better approach/workaround to tackle the problem?
Edit (Directory structure):
Maven-Plugin (FileGenerator):
src
--main
--java
--FileGenerator.java (references the TemplateFile based on the path to the root project)
TemplateFile
If I run the plugin as a standalone, I am able to generate new files based on the TemplateFile. I achieve the following structure
Maven-Plugin (FileGenerator):
src
--main
--java
--FileGenerator.java
TemplateFile
NewFile1
NewFile2
However, if I run the plugin in another directory (such as part of another java project) with the command mvn myplugin:mypluginplugin:1.0-SNAPSHOT:build
Another Java Project
src
--main
--java
--AnotherFile.java
pom.xml
I get an error mentioning that the TemplateFile cannot be found. Is there a way for the plugin to reference the TemplateFile regardless of where it is run at?
Ideal Output After running plugin
Another Java Project
src
--main
--java
--AnotherFile.java
pom.xml
NewFile1
NewFile2
I have an off the shelf application that ships a version of gradle with it. It also has scripts that are hard coded to set GRADLE_HOME to this location.
I want to zip up this dir, put it in nexus and replace it with the gradle wrapper.
How do I configure the gradle wrapper to download this zip from nexus and extract it to a specific location in the project?
EDIT: In the gradle-wrapper.properties I have
distributionPath=wrapper/gradle
However, I end up with it being unzipped to
...\wrapper\gradle\gradle-2.3-bin\8gn7esgljqyucijpbynjk93oc\gradle-2.3
How do I get it to unzip to the path I specified and not to the subdirs?
The location to which Gradle gets unpacked is a combination of the distributionBase and distributionPath properties in gradle-wrapper.properties file. The location specified by distributionPath will always be considered as relative to distributionBase. The only available values for distributionPath are GRADLE_USER_HOME and PROJECT. Even when using PROJECT the wrapper will still generate the folder structure you see above.
If you want to control this more precisely I'd suggest not relying on the wrapper to do this and instead add a task to your build specifically for this purpose.
I have a very specific question. The project I am on is a maven3 driven multi-module Project. The Project uses the SVN-Api to synchronize data from a repository and process it. More specifically:
A Manager, upon recieving an update call, will contact a remote svn repository and sync the files to the harddrive, where it will afterwards process them.
I want to create an appropriate folder Structure, with the assembly plugin. When I run a package command, ideally the output in the target folder would be
target
- data <- this is the base folder for the external repository
--- .svn <-- repository-information
--- group1 <-- subfolders on repository
--- group2
--- group3
- program.jar <-- contains java classes, executable
- config.xml <--- config file, editable by user
- other miscalleanous files
So frankly, this poses a number of problems and on top of this, I don't have too much experience with the assembly plugin. What I am not quite getting is how I am able to differentiate between files that should be put into the jar and files that should be kept outside the jar.
I have read about the assembly descriptors, I have however only seen examples that either include or exclude files, none that provide information about the relative positions the files should later have in the target folder.
Thanks for your time.
Regards,
Keno
So after some research I decided to go the following (simple) way:
At startup, The program fetches the location it's jar file is at, then checks for an resource folder outside the char. If none is found, it checks out the base directory of the svn server and starts crunching numbers. This way didn't require any fiddeling with the maven pom, and it works for testing as well.