I am using the mybatis-generator in a maven project to generate the Java files for a few tables. At the end of the generation, I would like to generate a few non-java files like properties files and resources. However the default generator allows me to generate only XML and Java files. Is there any way to also get the generator to create sql files, SPI definitions and property files for example?
Looking inside the generator, it seems that the Generated java files and XML files go through some further process(formatting et al). Even if I write a custom plugin, I can generate an XML or an sql file only but not a properties files or an sql file. Even if I did, I cannot get the process to finish because the subsequent steps would fail.
Currently, I am getting over these by creating my own files and writing them thru a custom plugin. However, during the plugin execution, the folder target/generates-sources/mybatis-generator is not created yet. Therefore assuming that location to have already been created is ruled out. On the other hand, if I go ahead and create the folder and its internal META-INF/services folder, I am not sure if this will be overwritten at a later stage. In addition, my plugin does not (by virtue of the way the generator initiates plugins), have access to the project root folder. So that is not an option either.
I neither have access to the ShellCallBack, implying that postponing the file creation to a well defined time-point in the build process is also not possible.
So how do I go about creating the service definitions and the additional resource files?
The last resort is to hard-code the project folder or to pump the project folder through a property. This is coming to my rescue now. But clearly, the generated files are being detected by my git client and I have to clean up these files also despite their being dynamic.
Hints please?
Thanks in advance.
Rahul
The generator currently supports Java, Kotlin, and XML file generation. There is an open feature request to support other file types in plugins. You can follow it here: https://github.com/mybatis/generator/issues/752
Related
I'm trying to import a C project to eclipse (CDT) that is managed by waf. There is a list of predefines generated by waf (when running ./waf configure). That list has to be imported to Project->Properties->C/C++ General/Paths and Symbols/Symbols/GNU C so that the indexer knows about them and does not print errors. That list (when using the GUI) is stored to the .cproject file. I created a Build Target that runs ./waf configure and stores the list to a file named DEFINES.txt. How do I automatically update the list of .cproject with the values of DEFINES.txt after running the Build Target?
I thought about the following solutions and their follow-up problems:
Solution: Writing a plug-in.
Problem: What is the appropriate extension point?
Solution: Writing an external program that calls ./waf configure reads DEFINES.txt and writes the list to .cproject. That program replaces the old Build Target.
Problem: How safe is this? Am I allowed to change the .cproject file by an external program without causing any problems?
Solution: Implementing the .cproject updating algorithm in wscript file.
Problem: This is not a solution for me, because the project is used by others, too, that do not use eclipse as IDE. So the modified wscript will cause errors if the other developers want to build the project.
Does anybody have better ideas or some advice?
Here is how to go about it:
Writing a plug-in: What I recommend you do is write an extension to the LanguageSettingsProvider. The FAQ has some more info, but the summary is that provider does:
This extension point is used to contribute a new Language Settings
Provider. A Language Settings Provider is used to get additions to
compiler options such as include paths (-I) or preprocessor defines
(-D) and others into the project model.
CMake has an option to generate .cproject as part of its configure state, so you could do something similar. See the CMake Wiki for inspiration, but the summary is that you don't store and .cproject/.project in source control and have CMake (or waf in your case) generate the IDE specific files.
You could also just pick up the build settings using the build output parser and ignore the DEFINES.txt altogether. That requires running the build once from within Eclipse for CDT to see all the commands, and requires the commands to be parseable in the build output.
I have a bunch of generated source files which then are used in a GWT-based code. When I'm just recompiling the project everything is fine but when in comes down to a super-dev mode - that's where I'm completely lost.
The question is following - is there's a way I can tell to the GWT launched in a super-dev mode that changes in this particular folder should trigger recompiling of the whole project?
Files I'd like to monitor changes belong to a java package but are not java or "*.gss" files.
What I've tried so far is to invoke watcher-maven-plugin which just reruns mvn generate-sources whenever file in a given folder changes. I don't like this approach because it looks a bit redundant and over-engineered to me - after all, GWT code server somehow triggers source generation when *.gss files are changing, that gives a hope that somehow I can shove in other type of files as well.
I have a Maven project written in Scala and deployed as a .jar. The project has the typical structure:
project-root
|__src
|__main
| |__scala
| |__resources
|
|__test
|__scala
|__resources
I have many hardcoded values in the application that I'd like to extract to a configuration file.
I could just create a text config file anywhere, read it from the code and use the parameters, but I'm looking for a best practice/approach. I'd like to take this things into account:
Is there a way such that I can change config values and not have to rebuild the .jar? That would be very practical.
Where would be the best location for the file? E. g. create a project-root/src/config directory and put the file there?
Any remarkable reasons about choosing among different formats? I'd go with XML, but I've seen quite a bit of YAML and HOCON around...
If you want to be able to change configuration values without building the jar, you will want your config external to the artifact. There are ways to modify the contents of the built jar but I don't think that is what you are wanting to do. If you want to have config you can change on the fly, keep it out of your jar and reference it on the Classpath at runtime.
If you want to keep it on your artifact, and rebuild when you change values, keep the configuration file in src/main/resources. Maven will automatically package it into your jar for you at the root of the archive.
As for format, that's probably personal preference. Reading YAML usually requires another library such as snakeyml to parse effectively, so if you are trying to keep your library light on dependencies, maybe look at .config or .properties files instead. Otherwise, XML and YAML are always nice for complex configuration.
Is it possible to deliver an update which contains only the updated libraries and not the whole package of data. in our application only a few files are updates regularly. The other ones never. With Auto update over the net this would result in a much smaller package...
Is such a setup possible and how?
Thank you.
You can do this by saving your project to a different file (keeing the application ID) and removing the unnecessary files from the distribution tree. When you compile that project, an updates.xml file is created as usual. Use that updates.xml file for auto-updates instead of the updates.xml file from the standalone installer project.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.