I have a multi-module maven project with one root and multiple child projects. I am planning to use SL4J for logging. However, I have to place the log4j.properties in all child projects to be able to configure log4j.
To be able to reuse a single properties file, I tried keeping the file in src\main\resources directory of the root. However, sl4j complains that it cannot find the properties file unless it exists in each individual project.
Is it possible what I am trying to do? If so, how do I do that?
The 'distributable' is responsible for the final log4j.properties, not every dependency is has. However, tests will probably complain about the absence of this file, so put a version of log4j.properties under src/test/resources.
Related
I have the following Maven project structure.
project
-- src
-- main
-- java
-- models
-- resources
I want to create and deploy a jar project-models.jar containing everything inside the folder models and nothing else. Since I'm not very familiar with Maven, I'd really appreciate if you could provide me some example.
models belongs to resources (They should neither be compiled nor tested, should they?)
See How to create an additional attached jar artifact from the project:
Specify a list of fileset patterns to be included or excluded by adding <includes>/<include> or <excludes>/<exclude> and add a classifier in your pom.xml.
Note: the jar-plugin must be defined in a new execution, otherwise it will replace the default use of the jar-plugin instead of adding a second artifact. The classifier is also required to create more than one artifact.
My maven top level project refers to a common-db project. In this project I have a spring file which defines the DB parameters.
However, I want the top-level project to define the DB parameters through the profile and inject these into the spring config file in /src/main/resources.
The top-level project only does the filtering on its own /src/main/resources files and ignores those located in the JAR dependencies.
How can I do this?
So you want to depend on common-db but then modify its contents to change the parameters in the config file? Ok, if you really want to do that, you could do something convoluted where you use dependency:unpack to expand the common-db jar, then overwrite / filter its contents, and then use a custom jar:jar execution to re-jar up the dependency and ship it with your application.
But, wow - why would you jump through all these hoops? Like #hoaz suggested, just place your application-specific config in the same classpath location so that it is loaded before common-db's default configuration. This is the convention followed by many, many Java libraries.
I am working on a java maven project with several modules.
I am facing issues with sharing configuration files from one module to its dependency.
For instance i have a module named utils which holds a log.properties file and i would like to use it in another module named gui. What is the best practice to do this ?
Currently we put the log.properties in a config directory as Maven standard layout suggest it, and it is not included in the jar file. Is it correct ? Should I put it in resources instead ?
I use assembly plugin to copy it to a common config directory, this works well, but when I try to build each module individually the config file cannot be reached. How can i solve this ?
Thanks for your help,
Pierre.
You should put your configuration in src/main/resources/config/. This way it will be included in the jar by default. The maven convention is that only src/main/java and src/main/resources are contained in the final jar by default.
Making property files directly accessible to other modules is not a good practice. You should provide a service in the module owning the configuration that is the only place where those files are accessed. This service will be able to give configurations to other modules. Otherwise you violate the single responsibility principle.
You can configure maven to include the src/main/config directory in the built artifact by specifying it in the resources section of the pom as described here.
I have a project with more than an hundred external library dependencies, here we use tomcat with this endorsed jar libs configured on a directory in the server (now is under $CATALINA_HOME/lib/endorsed), so the webapp can access those resources on runtime start.
I wanted to try jetty instead, because tomcat takes too much memory and crashes frequently. Now I'm wondering if there is a parameter to pass on maven-jetty-plugin to specify this jar's folder so as the webapp class loader find them in its classpath.
I've tried extraClasspath in configuration tag, but it seems to load only classes and ignore all jars in the directory I set into (if I pass the full name path of the jar, it is loaded, but I don't want to set every library that I need there).
Thanks in advance for the help
update:I know it's not a standard maven operation, i'm searching for an emergency workaround since this project is very huge and I can't refactor as I want.
But also I expected this feature was not as tricky as it seemed to me at first glance.
You need to pass them as absolute paths, or, alternatively, have them as dependencies of the plugin itself.
What you want to have done goes against Maven's portability principles, so don't expect it to support it.
I have some questions derived from a problem that I have already solved through this other question. However, I am still wondering about the root cause. My questions are as follows:
What is the purpose of spring.handlers and spring.schemas?
As I understand it's a way of telling the Spring Framework where to locate the xsd so that everything is wired and loaded correctly. But...
Under what circumstances should I have those two files under the META-INF folder?
In my other question linked above, does anybody know why I had to add the maven-shade-plugin to create those two files (based on all my dependencies) under META-INF? In other words, what was the ROOT CAUSE that made me have to use the maven shade plugin?
What is the purpose of spring.handlers and spring.schemas?
well you more or less found it out by yourself, let's add some more details:
some spring libraries contain a spring.schemas and a spring.handlers file inside a META-INF directory
META-INF/spring.schemas
re-maps(*) schemalocation to a xsd inside the library
(abstract) only re-mapped versions are supported by this library
META-INF/spring.handlers
provides namespace handler classes for specific namespaces
the namespace handler class provides the parser logic to parse spring-batch beans, like job,
step, etc.
(*) the actual re-mapping happens during the build of the spring application context
Under what circumstances should I have those two files under the
META-INF folder?
normally the files are inside the spring library jars you use, but you can use the mechanism to implement own namespace bean parsing, then you would have own files
In my other question linked above, does anybody know why I had to add
the maven-shade-plugin to create those two files (based on all my
dependencies) under META-INF? In other words, what was the ROOT CAUSE
that made me have to use the maven shade plugin?
if you use a spring namespace in your spring configuration, you need the appropriate files
the problem arises when you want to run a java application:
with a main class either
the spring libraries need to be on the classpath
or all is merged into one jar, which has to be on the classpath (*)
as war/ear server application, the spring libaries need to be on the classpath, normally inside the war
i guess you did not start the mainclass with the complete classpath and i updated my answer for your first question too
(*) if you merge all into one jar, you have to make sure, that the contents of all spring.schemas/spring.handlers files are merged into one spring.schemas and one spring.handlers file, see this answer for a configuration with maven to create an all-in-one.jar