The follow structure
src
service
service1
Service.java
Service.properties
I want that the output generated by gradle would be
classes
service
service1
Service.class
Service.properties
So, I need that the files(.properties) keep in the same directory of the class after build, but the gradle copy the files .properties (resources) to another directory
how can I do it?
I assume you are trying to place them there so they can be loaded from the classpath? The best way to make them available to your class loader is to place them into src/main/resources which is part of the standard directory layout. Gradle will find them there and they will be placed at the root of your jar (by default I believe it ignores property files in src/main/java).
It would also be good to move your java files to to src/main/java. Using the standard directory layout is a convention that will help other developers understand the code. It also allows you to use certain tools out of the box with less configuration because those tools can make assumptions about where things live.
So the new structure would be like:
service1-project
src
main
java
service1.java
resources
service.properties
If you use the standard directory layout, I think you will achieve the end-result of what you are trying to do (which is really to load the properties file within Java). If for some reason you have to avoid the standard directory layout, then you have to start doing custom configuration (a downside of using a non-standard project layout). In Gradle, you should be able to do this by hooking into the Java Plugin's processSourceSetResources target.
Related
I have developed a cucumber based selenium automation framework and have used Page Object with Page Factory as the design pattern for it.
Below are different components of my automation framework :
Page Objects.
POJOs
sharedutilities
Feature Files
Config file
Expected Data folder
Extent config.xml
chromedriver.exe
Reports folder
I am not entirely satisfied with the way I have arranged these components inside maven project. There are multiple source folder for Maven like src/test/java, src/main/java, src/test/resources, src/main/resources, are there some standard set of guidelines on what to put inside these 4 folders depending on the components which I have mentioned above ?
General guidelines:
src/main/java contains your application code (.java files)
src/main/resources contains any non-code files that go with your application. for instance property files or config files for your application (if they are not Java config files, like your config.xml).
src/test/java contains any test code (.java files) for your application. If you mirror your package structure from src/main/java testing frameworks like Junit can automatically find the right classes to test without having to specify imports for them. In the case of Cucumber, this is where your step definitions go, as well as any other code that helps you perform your Cucumber tests (like the Page Objects in your example).
src/test/resources contains any non code files that go with your tests. In the case of Cucumber, this is where the feature files go. If you have a separate test config.xml that would go here.
If you have only test code, you might not have a src/main folder. I'd recommend locating your test code in the same repository as the system you're going to test, as this will make it easier to get fast feedback.
Regarding your question:
Page Objects -> src/test/java
POJOs - depending on whether they are application POJOs or test POJOs -> src/main/java or src/test/java respectively
sharedutilities - asusming this is code to help your tests -> src/test/java
Feature Files -> src/test/resources
Config file -> depends on whether this is for the application or test, and whether its code or xml.
Expected Data folder - not sure what you mean. Test files (like .json or something) might go in src/test/resources
Extent config.xml - probably src/test/resources
chromedriver.exe - might go in your root directory. (I might recommend against including .exe in your project; how are you going to deal with different OS?)
Reports folder -> would probably go to a target folder?
Hope this helps.
I'm looking for the appropriate location to place resources that are used by the build, like a license header template file or a file with code formatter settings.
The buildSrc seems like the most appropiate place (e.g. buildSrc/src/main/resources), but I only found it mentioned in the context of Build sources.
Another option would be src/build/resources. Perhaps there are better locations I didn't consider.
What would be the most appropriate directory for these resources?
In many gradle builds the convention of using $rootproject/gradle as folder for build resources has been established. you can have a config folder to store your license files / checkstyle configs etc. in there.
I have two web application projects in place, Project A and Project B. Project B has war dependency on Project A. Both projects have messages.properties files to handle i18n. However, the location of properties is same for both the projects. I am using maven war overlay plugin to overlay files of Project A on to Project B. If files are in the same location for these two projects, maven will not override Project B's files and leave them as is. However, this leads to maintenance problems as new text for i18n has to be added in messages.properties of both the web applications.
Is there a way to tell maven war overlay plugin to merge the properties files at the time of packaging? The logic of not overriding files when already present serves us well otherwise.
You should be able to achieve this with the Maven Cargo plugin outputting an uberwar.
http://cargo.codehaus.org/Merging+WAR+files
It doesn't know how to merge properties files out of the box, but it's super easy to implement a custom merger, all you need to do is implement org.codehaus.cargo.module.merge.MergeProcessor, and have it available on the classpath.
You probably just want to write a simple merger that can concatenate files together, unless you have duplicate properties then you might need to do something a little more fancy.
I want that a maven project can be used as a black box jar. This is needed because second project was born its way, and I don't want to integrate its code by hand. So the best way is that this project is going to save it's data on db, but it should use a service offered by the "wrapper" project to save them.
The idea is simple, the secondary project can expose just a method to which I will pass the service that offers the save method as a parameter.
The secondary project should not have configuration files, but should rely on the father application's properties.
Any idea to do this fast and almsot good? Thanks for any suggestion.
EDIT 2013/03/07: The idea behind this is that the second project should generate a classic jar library that looks a properties file into the classpath of the host project. Something like Quartz/Spring/... you import jar and you provide the properties file.
I just defined some classes to load properties from the classpath, and some interfaces to make the two projects interact.
In pom.xml of the parent project I imported the child project excluding it's dependencies to avoid conflicts.
It was a pretty easy task at the end.
I saw lots of code generation plugins in Maven put generated code in target/generated-source/*plugin-name* directory. But I didn't find it documented anywhere in Maven standard directory layout. http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
Where is it documented in Maven? Or it's just a convention that everyone follows?
This is not described as part of the standard directory layout, since these files are generated( hence, they end up in the target/ directory). By the target/generated-source/plugin-name convention the plugin-writer is pretty sure it won't clash with generated sources of other plugins. The plugin-writer is also responsible for binding this source folder to the Maven project.
As a user you shouldn't notice much of it.