I have maven-base ear file.
The ear contains lot of jars the built by same CI-CD process - monolith.
I have implementation of incremental build, that improve the CI-CD times by build the artifacts that changed or affected only. and take the other artifacts from artifactory.
The problem is - when I start new version, I have to build all the artifacts in order to create the artifacts in artifactory the first time. This takes long of time.
Is there a quick way to copy all the artifacts from version 0.1 to version 0.2 in artifactory?
In the beginning of version 0.2, The artifacts are the same.
Thanks
TL;DR
It's not that straight forward.
Personally I think it's not the right way to go. You should probably break your internal dependencies based on their lifecycles, and reuse existing versions instead of rebuilding them.
In more details:
Technically, you can use the JFrog CLI's copy command to copy files in Artifactory. You can also use the Copy Item API directly if you prefer. Copy is a cheap and quick operation in Artifactory because of its checksum based storage (the content is stored only once).
But, that's not enough, mainly because of Maven.
Maven uses a file path format which contains the version - both as a folder and in the file names. The Maven artifacts file path format is (simplified): /<group>/<artifact>/<version>/<artifact>-<version>.<ext>. For example, the jar file of the artifact org.acme:foo:0.1 will have a file like: /org/acme/foo/0.1/foo-0.1.jar.
It means that copying files from folder of 0.1 to 0.2 is not enough, you also need to rename them accordingly.
And that's still not enough - Maven also embeds the the version in files, mainly in the pom file. It means that copying it is also not enough, you need to modify the content of that xml file.
But, it also depends on how you use Artifactory. The best practice is to publish also a build-info when you upload to Artifactory. That usually means that Artifactory stores properties on the files, properties which are specific to the build as part of which they were created and uploaded. These properties are also copied as part of the copy operation mentioned above, and you should remove them from the new version.
To do all of that you can probably write a simple script which lists the files, copy and rename the files, adjust the content of the pom file, and remove the properties.
Related
I'm working in a complex tomcat configuration where I'm using third party proprietary service that is distributed as WARs. In the servlet container I have 10 WARs deployed where only one is coded by us.
We are using maven to manage the project.
I'm declaring the third party WAR files in the POM with provided scope.
My issue comes when I try to use maven to deploy the system in a local testing server.
I'm using maven-dependency-plugin:copy-dependencies goal to copy the right artifacts in the right directories in the local serving tester.
I must copy JAR files in one directory and WAR files to a different directory. But maven is not differentiating the artifacts by packaging. So I end having the JARs mixed with the WARs in the destination directory. While I need to have two executions, one for WARs and one for JARs going to the right directory.
I have only being able to use a copy goal specifying every artifact to copy, but this is difficult to maintain if any developer adds a new dependency, the dependency must also be added to the right copy goal.
I will like to be able to use copy-dependencies goal but being able to indicate that I only want to copy a specific packaging.
Any idea on how I can manage to do that?
Thanks!
You can use -DexcludeTypes=war
https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTypes
Under my user-home/.gradle/caches I am seeing multiple artifacts directories e.g. artifacts-14,artifacts-24, modules-2.
all these folders are storing duplicate artifacts. so my questions is, why and in what conditions gradle has to create multiple artifacts folders? can gradle also be configured to lookup and store artifacts in on directory. doing so I can save disk space from storing duplicate artifacts.
highly sophisticated dependency caching, that does not work (3.4). Build file has a new dependency version yet Gradle still fetches artifact from some weird intermediary dependency cache instead of taking the new version from local maven repo
Gradle contains a highly sophisticated dependency caching mechanism.
You can check a first folder .gradle located under project directory.
Gradle recreates every time the tasks are run.
Also there is a folder .gradle under home directory.
Gradle creates it and uses it to store the depdendencies to reduce the download-time.
The Gradle dependency cache consists of 2 key types of storage:
A file-based store of downloaded artifacts, including binaries like jars as well as raw downloaded meta-data like POM files and Ivy files. The storage path for a downloaded artifact includes the SHA1 checksum, meaning that 2 artifacts with the same name but different content can easily be cached.
A binary store of resolved module meta-data, including the results of resolving dynamic versions, module descriptors, and artifacts.
Separating the storage of downloaded artifacts from the cache metadata permits us to do some very powerful things with our cache that would be difficult with a transparent, file-only cache layout.
You can read more info here. Check the The dependency cache chapter.
I'm new to Maven and we want a way to use checksums to determine when files have been changed in SVN for troubleshooting deployment purposes. We have 2 artifacts that are deployed in our respective environments:
(a) 1 WAR file
(b) 1 configuration folder containing a few .properties files and a few XML files.
We want to track if any of the config files have been modified since building the original WAR file since sometimes developers have added configuration entries that are no longer in synch with the WAR file. We think the ability to compare check sums might be a good help in this area. We use Maven as our build tool and JBoss is our app server.
In pom.xml I added a entry for the maven-install-plugin. When I perform a build using "maven clean package" and then a hard deploy to JBoss by Maven "mvn jboss:hard-deploy" I don't see any specific check sums files.
pom.xml entry for maven-install-plugin contains a element which contains a element that contains a text value of true. According to documentation I have widely read this should generate check sum files. I have searched for these check sum files after both the build and deploy to JBoss. I'm new to Maven and checksums and I have searched online for the last few days unsuccessfully so that is the only reason I'm reaching out for help.
Thanks in advance to anyone who can help,
-Kevin
I have a java application.
I can run the Maven Release task which will do some nice things for me:
Change Version number from 1.0.0-SNAPSHOT to 1.0.0
Increment the version number in my pom to 1.0.1-SNAPSHOT
Tag the release in source control
Upload the resulting package to my maven repository
I'd like to take things a step further. I have some post-build steps that I'm currently doing manually.
Update the launch4j configuration xml file with the appropriate version
Wrap the resulting jar in an executable using launch4j
Copy the resulting EXE into a package directory
Copy several supporting files into the package directory
Zip the package directory up
Email the package to my testers.
Eventually I'm going to have the additional task of building an installer leveraging the package directory.
I don't know that maven or ant are the right tools for automating my remaining 6 tasks, but it looks like either one or a combination of both could potentially accomplish what I need.
I could probably write a batch file or a simple perl script to do these things quicker than figuring out how to do them, but I would prefer to keep things as standard as possible so that I'm not taking on the additional responsibility of supporting a hack of a release process perpetually.
It seems to me that these are tasks that might not be standard part of build/release, but are commonly seen enough that there should be a best/most common practice for accomplishing them.
I would suggest to use the maven-assembly-plugin as well as the maven-launch4j-plugin during your build.
Update the launch4j configuration xml file with the appropriate version
put a placeholder into the configuration xml and let maven replace it during the
the build.
Wrap the resulting jar in an executable using launch4j
use the launch4j-maven-plugin to create the executable.
Copy the resulting EXE into a package directory
I would suggest to put the resulting artifact into a repository manager instead
of a separate folder, cause in Maven all artifacts are stored within
a repository. It might be necessary to setup your own repository manager
(Artifactory, Nexus, Archiva).
Copy several supporting files into the package directory
Using them as resources (src/main/resources) they will be copied
automatically.
Zip the package directory up
Use the maven-assembly-plugin to create a resulting zip file.
Email the package to my testers.
You can use a CI like Jenkins etc. to send the final mail or
you can take a look into maven-changes-plugin which might be solution.
This means all your mentioned steps can be handled by Maven during a usual build. This means in the end you can use the maven-release-plugin to produce a full release which contains all the above steps and produces all the wished artifacts.
If I were you, I would try a combination of the following:
Maven release plugin, unless it is not flexible enough for SCM related processes. If using SVN as SCM, I would use directly SVNKit(inside a custom Maven plugin), if flexibility is a concern.
Maven launch4j plugin.
Maven assembly plugin
Maven Ant Run plugin and/or one or more in-house Maven plugins for the remaining tasks.
We are using maven for building the project. It's legacy and huge one.
We newly added few .keystore files to it's resources folder.
The problem is, once the build is done, the .keystore files are getting tampered [may be maven is trying to replace/search for some placeholders]. Since it's legacy one, the project structure is so much messed up and we don't have separate distributions or no other choice but to go with plain build.
What I want is, tell maven to copy these sort of files without touching them and keeping the build as usual like before.
Between, there's no explicit is mentioned in pom.xml, tried to doing with that as per this http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html but it's messing up the project build.
I don't want to tamper the build, since it's legacy and huge one. We are using Ant plugin
Just switch off filtering for the respective <resource/> or add an <exclude/> for it.
After going through lot of sources, Found the solution http://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html
Thanks :)