The standard maven directory structure includes resources as follows:
src/main/resources
src/test/resources
When a maven build is initiated on a sandboxed environment - e.g. jenkins then all of the artifacts in those directories become available at the sandboxed "current" directory - and without resorting to any paths - either relative or absolute.
But when running mvn test locally the sandboxed environment is not in play: instead it is just the root directory of the project. In this case those resources would seem to need to be accessed via src/main[test]/resources.
Specifically: in a sandboxed environment all of the classes to be run are unpacked into a temporary directory *along with the resources under src/[test|main]/resources*. Therefore: the files/artifacts undersrc/[test|main]/resources` are present in the current directory. The "relative" path to those resources is thus
./
But in the local environment - e.g. running mvn test at the root directory of a local git clone - then the current directory is the git repo root dir. The "relative" path to the artifacts is thus
./src/[test|main]/resources
While I realize the artifacts can also be accessed via classLoader.getResourceAsStream I have apis' that require File access. We use api's like listFiles() and there is also the need to generate files in the given directories using file:// uri as well as literal paths. so we do need file paths.
What can be done here to normalize the paths across these different use cases/environments?
Related
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 use caching in gitlab runner, which builds a Maven Java project. Currently Gitlab runner only allow caching specific paths defined in gitlab yaml file in the cache: clause. When maven builds projects, it generate everything inside target/ folder, which are untracked files in git. So I can simply use untracked: true option to cache everything under target/ folder. The purpose of caching is to skip compiling the files, which have already been compiled by maven under the target/ folder.
However this cache amounts to about 6GB, which is completely unreasonable for its size and time required to create and restore such a giant cache. It caches all jar and war artifacts built during compiling multi-module maven project. However, maven only needs .class files to check changes for re-compilation
So if their was some way using which I can cache only *.class files, and make them available in subsequent builds, then maven could check the .class files and skip re-compiling unchanged files and cache size would also be pretty small. Currently gitlab-runner only allow specifying absolute paths for caching. It does not support regex patterns for paths such as \.class$ (which would have been very useful).
Is there any way I could cache only specific file types using gitlab runner yaml settings?
So based on cascaval's comment, I was able to figure out a solution.
At the end of maven build I ran a command to clean all build artifacts created by maven, which are not used for checking stale status of .java resources. Here is what I wrote -
cd ./projects/directory
find . | grep --perl-regexp --regexp='\/target\/(?!classes|maven)' | xargs rm --recursive --force
This saves all .class files in target/classes folder, including folder structure and also files in maven-status folder, which are probably used by maven to check file status for recompilation.
My last build step in my TeamCity 9.1 project configuration uses the SMB deployer to copy files to a shared network drive (which we use to deploy the version to our users).
The copy is performed fine but the deployer somehow creates all the folders in the hierarchy leading to the bin folder. Example:
My configuration is:
Target URL:
\\theserver\thefolder
Artifacts path:
**\ProjectName\bin\Release\* => .
**\ProjectName\bin\Release\Resources\* => Resources
With this configuration, I'm expecting the files to be copied to \\theserver\thefolder\* and \\theserver\thefolder\Resources\*
However, this is the result I get instead: my files are copied to
\\theserver\thefolder\ProjectName\bin\Release\*
\\theserver\thefolder\Resources\ProjectName\bin\Release\Resources\*
How do I go with my artifacts definition so my files are copied to the proper folder? I'm having such a hard time with this syntax
The **\ prefix is causing the artifact path output to include the matched folder hierarchy.
You'll need to use the full path to the Project folder, also if you want to include nested directories, use the **\* at the end of the artifact path:
\path\to\ProjectName\bin\Release\**\* => .
\path\to\ProjectName\bin\Release\Resources\**\* => Resources
For more information, see the artifact path doco, specifically:
wildcard — to publish files matching Ant-like wildcard pattern (only "*" and "**" wildcards are 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.
I am having an eclipse project created on Ubuntu, in which all the JARs that I am using, are located in a folder /home/xyz/AllJARs. Here the /home is the system home folder. The project as well as the AllJARs folder is git version controlled on a central git server.
So, all the paths to these JARs in the project's build path are /home/xyz/AllJARs. When I'm cloning the project repo and the AllJARs repo on a Windows machine, I'm shown errors related to build path since it can't find the path /home/xyz/AllJARs.
How can I manage this situation where I can have external JAR files in build paths which can work on Ubuntu as well as on a Windows machine? Thanks in advance.
You have two easy options:
use relative paths: for example, put the JAR folder in the folder above your project, then you can set the JARs' paths to ../AllJARs/
put JARs into project: you can also just put the JARs into the project folder; if you've set them up as "External JARs" in project settings, you'll have to remove them from that list, and re-add them with "Add JARs". Eclipse will then look for them locally in the project folder. If you don't want to commit the JARs to the git repo (size and/or permission being a problem), you can just copy them into the Project folder after cloning. While they're not there, you'll be shown a warning, but once Eclipse can find them, everything's fine.
Where is the proper path for creating files using Ruby on a *nix environment? The files must persist between restarts and releases. Obviously using the project path doesn't work as Capistrano will create a new folder for each push.
Capistrano has a system directory created by default that should be linked to the shared/system directory at the root of your release path. This will persist between deployments.
You should put anything there that is not specific to your deployment, for example, attached files or other user uploads.
In your version control system you should be sure to not deploy this directory as to avoid packaging up your development-specific content. Generally it should be ignored, not included in your version control.