I'm trying to use maven to move folder using some regexp to change 1 folder in the path.
My project has multiple packages like :
src/main/java/<package1>/<folderToMove>/files.properties
src/main/java/<package2>/<folderToMove>/files.properties
src/main/java/<package3>/<folderToMove>/files.properties
I need to move those files.properties to the target folder without in the path like :
target/classes/<package1>/files.properties
target/classes/<package2>/files.properties
target/classes/<package3>/files.properties
I found a solution using maven-resources-plugin but I have to specify manually the source and destination paths, which is not possible due to the number of folders.
I'm looking for a solution using a regex like :
<source>(src/main/java)(/.*)(/folderToMove/)(/*properties)</source>
<destination>(target/classes)\2</destination>
My regex is probably wrong I just added it to have an exemple of a solution that would work for me.
Is there any maven plugin allowing me to do this, or do I need to add a bash script and call it from maven?
Related
I need to rename set of files in maven without using Maven-Antrun-plugin in a single execution or command.
I have many property files with same suffix ab_bc.properties,de_bc.properties,etc and I need to replace the suffix to some other name like ab_BR.properties,de_BR.properties.
Is there any plugin available to do the same in Maven?
I tried Maven-assmbly plugin and copy-rename plugin but adding lot of files makes it more complex.
You can give this plugin a try or have a look on workarounds with the Maven Assembly plugin, see related question here.
Hope that helps :)
I've set up a repository to distribute plug-ins using Npackd. I am aware, that I can use a batch script to move all files from a package wherever I want, but I'm afraid I might accidentally overwrite files. Currently, my setup works like this (which is npackd common practice, I believe):
a package myFile.zip gets downloaded
the contents gets extracted to %PROGRAMFILES%\myPackage\myFile
a batch script optionally moves the files elsewhere
Unfortunately, the Npackd documentation doesn't explain the internal process of how this is handled. My first concern is that a folder myPackage already exists and might get overwritten, consequently its files being moved by my Install.bat. Is there a way to define the destination path before the files get extracted? Since I'm installing plug-ins for an existing software, this would avoid my script moving all the files.
One way to achieve could be "abusing" the 7z examples, but if possible I'd like to a avoid the dependency since my plug-ins stored inside a standard zip archive, and Npackd can handle these without dependencies.
Npackd always creates a new directory during the installation of a package version. Normally the name of this directory is the package title (e.g. "Firefox"). If this directory already exists the version number is used as a suffix (e.g. "Firefox-27.0.1"). If this directory is also already there an underscore and a number is used additionally (e.g. "Firefox-27.0.1_2", "Firefox-27.0.1_3", etc.)
There is no way to define where a package should be installed exactly. As you would probably define a dependency on the main software package in each plugin anyway, I'd recommend something like this:
<dependency package="com.mycompany.WordProcessor" versions="[5.00.2195, 6.1)">
<variable>WP</variable>
</dependency>
<file path=".Npackd\Install.bat">copy spellcheck.dll "%WP%\plugins"</file>
I have a Bamboo plan that involves building with maven on Windows. The default path to the build directory under the bamboo user is long, and some files end up over the 255-char Windows limit. I wanted to solve the problem by (for this plan only) change the location where the Mavens are run to a short dir, C:\build. I can check out files, then run a script step to copy them from the build dir to C:\build. The Maven bamboo task is configured to override the project file, using C:\build\pom.xml instead. That all works fine. However, when it gets to the 'check in the updated pom' part of release:prepare, it somehow decides that the original build directory with the long path is right, dying with an error.
Anybody know how to specify that the updated pom is also supposed to come from C:\build? I tried overriding the 'Working Sub Directory' entry, but that won't let me specify a full path, so C:\build is out.
Did you try to override the localRepoDirectory parameter?
The command-line local repository directory in use for this build (if specified).
Default value is: ${maven.repo.local}.
You may set this parameter using a property in the POM:
<properties>
<propertyName>C:\build</propertyName>
</properties>
...
<localRepoDirectory>${propertyName}</localRepoDirectory>
It can be overridden in the Bamboo Maven command:
mvn -DpropertyName="D:\build" clean package
(Bamboo variables can also be used to set the propertyName)
You may define a single property with the desired path and use it in several places in the pom.xml.
Turns out there were several different things going on with the Maven 3.x task:
By setting the Override Project File to C:\build\pom.xml, I was able to get the task to try to build in C:\build.
Part of my copying of files from the normal root directory to C:\build was wrong. I'd used xcopy but forgot to add a /H to copy the .svn data as well, so the 'check-in updated pom' step failed because it couldn't find the .svn files.
Once the release:prepare and release:perform were finished, a bamboo 'Artifact Copy' step had been defined earlier to copy several generated artifacts back to the maven repository. Turns out that while this step is somewhat configurable about what files to copy and where they are to be found, it does not support providing an absolute path as the directory to copy from, unlike the Override Project File for the maven tasks. So I had to introduce yet another step, a script to copy the generated artifacts back from C:\build... to under the build root.
All in all, I wasn't able to mess with the build root as I wanted to, but by using the Override Project File and two scripts to copy the source files to C:\build and the artifacts back from C:\build, I got done what I needed to do.
I´m building an RCP application using tycho. The RCP application uses p2 and its self updateable capabilities configuring the respository in an p2.inf file. Works like a charm.
Now I want to introduce a placeholder ${updatesiteurl} in the p2.inf file and replace it with the URL according to the environment for which it is built. But unforunately it get´s replaced with an empty string instead of the environment variable which I guess happens because tycho, or the p2 director, replaces some escaped characters (like the ":" which is ${58} for example).
Any ideas how this could be solved? I thought about explicitly declaring the resource plugin and binding it to an earlier build phase but that didn´t work either...
What finally worked is: I moved the p2.inf file to directory /p2 and let the maven resource plugin copy the file with the replacements to a temporary folder in /target. Now a copy task copies the file in a later phase (why the hell didn´t this work in the same phase...) to the the root directory, where the .product file is, since both have to be in the same directory (with the same prefix). Finally clean deletes the p2.inf file in the root directory...
I use Teamcity to build different packages and want to save those Packages as Artifacts. My Artifact Path in TeamCity is the following:
%system.teamcity.build.workingDir%\**\Release**/*.wsp => Solution
Now TeamCity collects all WSP-Files in any Release-Directory after building correctly. But it is saved including all subdirectories like:
I only want the .wsp-File directly under "solution" without the directory tree.
From TeamCity docs:
wildcard — to publish files matching Ant-like wildcard pattern ("" and
"*" wildcards are only supported). The wildcard should represent a
path relative to the build checkout directory. The files will be
published preserving the structure of the directories matched by the
wildcard (directories matched by "static" text will not be created).
That is, TeamCity will create directories starting from the first
occurrence of the wildcard in the pattern.
http://confluence.jetbrains.net/display/TCD65/Configuring+General+Settings#ConfiguringGeneralSettings-artifactPaths
In your build script ( or additional final build step) you will have to copy the necessary files to a single folder and publish that folder as Artifacts
Instead of copying as #manojlds suggests, you might be able to achieve something by modifying the OutputPath in yout .csproj file, or feeding in an OutDir property override when building a .sln (if you are). Be warned that neither of these approaches are perfect - for example, TeamBuild (the CI server in the Visual Studio ALM Tooling) redirects everything into one directory, which can cause a complete mess and only works for the most simple cases.
I had this issue where I wanted to gather various install files from subdirectories. Adding a PowerShell runner as a build step is quite powerful and solves this nicely...
get-childitem -Recurse -Include *.wsp | Move-Item -destination .
This will move them to the root prior to TeamCity looking at the artifacts, where the basic artifact paths like *.wsp can pick it up for the final output.