Currently trying to get Micronaut to work with Pitest and it is failing due to an NPE caused by the fact Micronaut does not include the source file in the debug info of the outputted class.
I was wondering if there is a way to configure Micronaut to support this?
Reproducible sample of this issue
I was wondering if there is a way to configure Micronaut to support
this?
In currently existing versions of Micronaut, there isn't.
The classes in question don't have source files, not directly anyway. Annotation processors in Micronaut create classes to support other classes which live in the project which do have source files. It is conceivable that the annotation processors could reference the original source files in the generated .class files but offhand I am not sure what the implications of doing so would be. You are welcome to open an enhancement request at https://github.com/micronaut-projects/micronaut-core/issues.
Related
I am trying to add support for kotlin for one of the IDEA plugins.
So far, I found this page and understood that I need to work with kotlin PSI files, such as KtClass and others.
When I was setting up my project I added idea source files to sdk(by cloning this repo), to make it easier to debug + see documentation.
However it seems that these idea source files doesn't include kotlin source files, such as mentioned KtClass and others, which I use in my project. Currently I see only decompiled version of these files.
Is there any way to add them like with other IDEA source files?
Those source files belongs to the Kotlin plugin, which is not strictly a part of IntelliJ IDEA distribution. You need to add the Kotlin plugin source to the project as well as the IDEA source.
There're two modules needed:
https://github.com/JetBrains/kotlin/tree/master/idea
https://github.com/JetBrains/kotlin/tree/master/compiler/psi/src/org/jetbrains/kotlin
A little intro:
I work on a project with legacy codebase witch uses internal xml based descriptors with specific file extensions (about may be 10 extensions).
Let it be *.desc, *.check etc.
To have code highlighting for such a files I can configure Idea to consider these types of files as XML.
It's available through:
Preferences / Editor / File types
And then add all custom extensions to 'Recognized file types': 'XML'
Our project uses gradle as build tool
and my question is:
Is it possible to make same configuration via dsl of gadle 'idea' plugin?
The short answer is: No.
One could create a custom Gradle task that will modify IDE file type preferences XML file in the config directory. While it's possible to run such task automatically on the project refresh in IntelliJ IDEA, it will most likely not work since you can't modify IDE configuration when IDE is running (the changes will be reverted). So, you will have to run it from the command line, outside of IntelliJ IDEA when IDE is not running.
It's probably not what you want, but if documented, can be used by the team as the manual step to make this configuration change easier.
Using gradle idea is not recommended anyway.
A better way might be to provide your own IDE plug-in that will associate these file extensions with XML file type and instruct the team to install this plug-in.
This is for Struts 1.x (I'm using 1.3.10).
I've noticed that Struts is unable to pick up resource bundles in the ApplicationResources.properties file if it is not placed somewhere in the default classpath (e.g., com.abc.SomePackage).
For instance, if I put the ApplicationResources.properties file in a custom folder /WEB-INF/strutsResources and configure the struts-config.xml thus:
<message-resources parameter="/WEB-INF/strutsResources/ApplicationResources"/>
I've read that the resources need to be on the classpath so I've also tried adding the /WEB-INF/strutsResources folder to the classpath. It still does not pick up the resource keys.
I've double-checked that the strutsResources folder is actually deployed to the server (I'm using Glassfish v3), so the file is there, it's just not being parsed.
P.S.
If you're wondering why I'm trying to do this, I just wanted to organize my code a little better ("better," IMO). Since the ApplicationResources.properties file is not really a class, I wanted to place it in a resources folder by itself.
I've checked that placing the ApplicationResources file in a package in the src directory works just fine.
Ultimately, the answer is yes. You can play some interesting games by configuring a custom className and/or factory and get messages however you want (including from a database) and so on. This allows you to customize whatever you want*.
I agree the resources aren't a class, but putting them on the classpath is a common practice, and allows resources to be loaded as a resource, e.g., from inside a jar. I'm sympathetic, but I'd leave it as-is.
*Like reversing all the text; a fun prank to play on your co-workers and QA department.
Its best leave it on the classpath.
It's stadard practise to include properties files on the classpath, especially if you're planning on packaging it up in your WAR/EAR. You're keeping it under WEB-INF so you gain no benefit from moving it off the classpath, and you'll just confuse other developers who have to work on the project and you've had to put a hack in to make this work.
If you want to keep your files external to your deployable WAR/EAR then that's a valid reason for not using the classpath. Typically this will require some configuration as part of your deployment to specify where the file is to reside.
For example specify the location using
a JVM argument (e.g. -Dprops.file=/config/myapp.properites)
lookup from a JNDI resource
use a PropertiesFactoryBean if you're using the Spring framework (I
use Spring's ApplicationContext with Struts 1 MVC)
read properties from a database writing your own
ApplicationPropertiesDAO class that initialises itself durnig your
applications bootstrap process (e.g. Spring application contact,
Servlet in web.xml, Listener in web.xml, etc)
When I try doing the serialization examples from Ruminations of a Programmer's "JSON Serialization for Scala Objects" article I run into the error:
Exception in thread "main" java.lang.NoClassDefFoundError: scala/util/parsing/syntax/Tokens.
I have found that it happens when trying to deserialize. I was just wondering if there was a simple fix. I would really like not having to redo my whole project and downloading all my jars again.
This mainly occurs when the scala library is not present in your source path.
just check that it is present in build path.
If you are using eclipse the plugin doesnt work properly some times.Just make a new folder in your project and paste scala library into it and give it to build path.
I'm happily using the Maven bundle-plugin to create OSGi manifest headers for my modules. However, when there are configuration files that pull in classes which aren't referenced directly in the code, the plugin can't tell which packages it's going to need.
One example is a bundle with domain models that constitute a Persistence Unit for JPA. The driver class is part of the PU configuration and either set in an XML file or at runtime when the EntityManager is instantiated. I have to manually add an Import-Package header for the driver class that I want to load, or I get CNF errors.
Another example is a Struts war, where the web.xml pulls in the Struts dispatcher that's otherwise not found anywhere in the code and has to be manually added to the headers.
How can I avoid this?
I tried adding the required packages as dependencies with a provided scope, but that didn't help.
In the plug-in section of the bnd configuration you can specify plug-ins to analyze these files and contribute to the import-package header. For spring it looks like this:
<_plugin>aQute.lib.spring.SpringComponent</_plugin>
I am not sure, what descriptors are supported on top of spring. Just take a look at the source (it's in the Apache Felix SVN) and see for yourself. In the worst case you have to write your own plug-in, but at least it is possible! Also peter kriens site about the bnd explains the usage and some internals.
Other then that I am not aware of any simple solution.