I need to read properties file located inside resources folder of buildSrc special module to create kotlin object which will be accessible by other project modules.
I tried to put this properties file
in the root project folder(this case sometimes works sometimes not, so I look for more reliable case)
inside of buildSrc folder directly
and now trying by putting inside "conventional" resources folder inside buildSrc which even highlighted by ide as recognized resources folder
But during assembling of modules I get Exception file not found on the line load()
So 2 questions:
where properties file should be located
how to read it from kotlin inside buildSrc module.
Gradle has a somewhat complex class-loading hierarchy, and I don't know enough of it to be able to explain what is going on under the hood. However, I can give you some hints.
First of all, the methods getResource and getResourceAsStream is present in both a Class and a ClassLoader, and they behave differently.
On a Class, if you don't prefix it with a slash, it will look for resources relative to the package of the class. With a slash, it looks at the root of the hierarchy. As you don't know the package of the compiled script as done by Gradle, the correct way to reference the file is javaClass.getResourceAsStream("/file.properties") (notice the slash).
If you use the methods from a ClassLoader instead, a leading slash is meaningless. So here, Thread.currentThread().contextClassLoader.getResource("file.properties")) is correct.
The last thing to consider is when you can use the methods from the class and when you have to use a ClassLoader. From what I can tell, you can use the class method when in the same project (or plugin). So this should work from within buildSrc. But if you want to get the resource outside buildSrc, I believe you need to go through the context classloader.
After trying different variants I have found 100% stable and working variant - instead of reading a properties file, parsing it and validating input - just use kotlin objects as ready to use configuration! With this approach the problem of a current folder and accessibility of resources is gone which is what I needed.
Related
I have a file MyTaskListeners.gradle located somewhere and in each of my projects I want to import this file and only add the desired listeners.
E.g. MyTaskListeners.gradle might have TimingsListener, FlowListener, SomeOtherListener1, SomeOtherListener1, ... and in a certain projects build.gradle i would like you write something like:
apply from: 'utils.gradle'
gradle.addListener new TaskFlowListener()
How can I get the classes from MyTaskListeners.gradle to be available and known in the projects build.gradle? With what I have written above the classes are not known
unable to resolve class TaskFlowListener
Classes (and even methods for that matter) defined in script plugins are not directly accessible outside of that individual script. If you have utility classes that you want on your build script classpath and want to avoid packaging/publishing them as an individual project, you can use the buildSrc project.
I'm using IntelliJ IDEA and my project has a default Maven structure.
I often run into the scenario where I need to create a new class or resource in the same package, but in different folder (one of src/main/java, src/main/resources, src/test/java, src/test/directory). The case where I'm editing a class in src/main/java and I need to create a test in src/test/java is covered by the Create Test command.
What about the other scenarios?
Often I find myself writing a unit test and I'd like to create a test resource in the same package in test resources folder. Is there a quick way how to achieve that?
What you can do at least is to copy the path of your package, and then (in the test resources dir) say new directory, and paste the path there. You then need to delete the absolute prefix, but can keep the package definition. With deep package structures, this at least helps a bit.
To the best of my knowledge (via 10 years of use) there is not a built in way to do this. It is something I've recently been desiring for creating default Spring Test Context files. Your post has promoted me to open a Feature Request for auto-generating the spring text context. I'd recommend you either add a comment to that request, or open a separate feature request.
I have a jar file .I want to include it into BE and want the output to be same as in eclipse.
How do I add this file and use the methods of it.
I tried adding it into the build path of the project folder but the methods are not coming under CUstom Functions.I am not sure if this is the correct way or not
How do i go about it.?
Help required.
Your jar file needs to contain a file called "functions.catalog" that describes the static methods of your classes that are exposed to BE as custom functions. The XML format for functions.catalog is described in the dev guide (Chapter 18 in BE 5.1.1's Developer's Guide).
Note that you can only expose static methods to BE. So a "classical" library will require you to write static wrapper methods around everything that is non-static.
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
I'm having a stupid configuration issue with Ibatis in my Spring project. Please don't jump on me about how all this was setup, I'm just following the "in house project structure policy".
So here is the structure, we have the "src/main/resources/META-INF/" folder that contains all of our config files used by the application, and then there is a "src/test/resources/META-INF/" that contains only the config files that have different settings to run unit testing.
Well in our case that's only one file, the src/main/resources/META-INF/spring/application-config.xml became the src/test/resources/META-INF/spring/test-application-config.xml. I'm am not going to outline the small differences between the two, because that part works fine.
The test-application-config.xml imports the src/main/resources/META-INF/spring/data-access-config.xml file just fine, which in turns use the src/main/resources/META-INF/ibatis/sqlmap-config.xml successfully... After that is when it goes to Hell.
See up until now we're using Spring to find the next config files in the classpath, but when we hit sqlmap-config.xml we leave the spring framework for the ibatis framework I believe, which loads the resource files defined inside it relative to the classpath (that's taken from the doc, whatever that means).
Inside the sqlmap-config.xml are defined a few resource files we're using that live inside the src/main/resources/META-INF/ibatis/mapping folder.
They are referenced like this:
<sqlMapConfig><sqlMap resource="/META-INF/ibatis/mapping/MyObject.xml"/></sqlMapConfig>
That works fine when I run the app normally, but when I run my JUnit test cases I get an IO exception stating that it can't find the file /META-INF/ibatis/mapping/MyObject.xml.
I've tried to change the path in the sqlmap-config.xml to "mapping/MyObject.xml" but that didn't help. I've also tried to use the Spring classpath prefix "classpath:META-INF/ibatis/mapping/MyObject.xml", didn't work either.
Anyone would have any idea on how to set that Ibatis properly so it works for both the app and the junit?
Thanks.
To solve this problem, I removed all the the Ibatis files and folders from the src/test/resources/META-INF folder.
The sqlmap-config.xml in src/main/resources/META-INF/ibatis/mapping file now maps like this:
<sqlMapConfig><sqlMap resource="META-INF/ibatis/mapping/MyObject.xml"/></sqlMapConfig>
Please note that compared to my initial post the leading "/" is gone... I think that's what made the difference here.
Hopes this helps anyone running into similar issues.
Just to see whether what you are saying is actually the problem.. you might want to place your mappings (MyObject.xml) in the same folder as sqlmap-config.xml. I say this because I've had my fair share of spring + ibatis + unit testing problems. (see resolved question asked by me)
Also, you might be getting IO exception because the mappings file does not exist outside the container (when you run tests).
You should also post definition for bean created from SqlMapClientFactoryBean. This should have configLocation property that contains path to sqlMapConfig xml
I had the same problem and could not find a (quick) solution that explained what exactly could be going wrong. Hence my answer.
As Spring documentation for Ibatis says:
Remember that iBATIS loads resources from the class path, so be sure
to add the 'Account.xml' file to the class path.
In your case by adding META-INF to your webproject build path i.e. if you used Eclipse, set <classpathentry kind="src" path="META-INF"/> in your projects' .classpath (This will be visible under Navigator view in Eclipse)