I need to add a new profile to the users settings.xml as part of an IDE Plugin. Currently I'm directly parsing and modifying the actual file, but I would prefer to use Maven APIs like SettingsWriter.
Reading, modifying and writing works fine, but unfortunately comments and formatting are lost in this process. Is there a way to keep the comments, or a different API that I can use for this?
Related
The question regards an endpoint that I want to make available only for demoing and should not be part of the project in production. Therefore I need to find a way of making the piece of code that reveals this endpoint available only when it should be.
I thought of using a different .properties file when it is needed, but this requires creating another one and changing the configuration and if there is a more simple way I would like to know.
Maybe building with a different Maven profile? Can I use the Maven profile name inside the code?
I'm using Maven Java API to configure Maven in a custom Java project.
In particular I need to configure some Maven settings, among which there are proxy settings.
How can i do this? I googled a lot, but I found no examples on how to use Maven from Java.
Can You give me an example or a guide, a snippet of code, whatever you want to clarify HOW TO USE (AND CONFIGURE) Maven by Java API, i.e from Java code?
I found this maven reference, but what do I specifically need?
Thanks in advance.
I've already seen this question, but unfortunately there is no mention on how to edit settings.xml from maven api, I suppose it is possible, but I'm not sure of it, so I asked a new question, wider than that one, how can I manage Maven from Java? settings, run, properties, whatever... is it possible?
For example, about settings management, I found this API maven-settings, it can be useful? It's "read-only" API? I guess it isn't, but I've found no way how to "write" modifications to file, there are no examples on how to use it.
Well, yes, you are a bit crazy. You can take a look at some plug-ins which modify pom.xml files. For example, the versions-set facility shown here:
http://www.mojohaus.org/versions-maven-plugin/set-mojo.html
The source code for that plug-in will show you how to modify pom.xml files, but you also want to modify the settings.xml file.
All of these files are XML. Basically, you want to obtain a DOM for the .xml file. So, you can use generic XML tools to (1) read the file, (2) modify the document model, (3) write the data back to disk.
Note well: Maven caches the .xml files. You have to stop the maven executable and restart it to force it to re-read the .xml files. It sounds like you'll probably be doing this as a matter of course. :-)
I'm looking for a best practice for injecting local files into a project that are not being tracked with source control in such a way that the source-controlled version of the file is blind to the changes.
In particular, I have a context file with database credentials in it. I want to keep the raw "put your credentials here" file in source control, but I need to have that file filled out with the appropriate credentials for my development setup (or the production server, or what have you) without those credentials being pushed back into source control. Obviously, I can just edit the file locally and not check it back in. However, that becomes tedious over time, being careful that I don't accidentally check in the file with the credentials to the central code repository every time that I need to check a change in. An alternative approach would be to check in a "-dist" type file that each user would have to rename and edit to get the project to build at all.
I tried looking into Maven Overlays as that looked like it would require me to build a whole separate project for just my local credentials, with a pom.xml and a war file. That seems like a lot of overhead for just a couple of files. What I'm really after is a way to tell maven "if the file X (which isn't in source control at all) exists locally, use it. If not, use file Y (which does exist in source control)." It seems like there should be a fairly automatic way to handle it.
Simple
I have done this in the past, it is very simple, have a single file for example default.config that gets checked into version control, have another file called local.default.config that is in your svn.ignore file. Have Maven copy the local.default.config over the default.config if it exists, or have it copy both and your application look for local.default.config and then default.config if the first doesn't exist.
You can even use the same default.config name and have the application look in multiple places, with your home.dir as the highest priority, then some place else.
An ideal version of this will read all the files in some priority and use the last found property from all the files, then you could have default.config with all your properties, and local.default.config with only the few that need to change for your local configuration.
More Sophisticated Maven Oriented
Maven has multiple ways to get where you want to be:
Use Maven profiles to enable and disable a property that holds the file name you want to use and use the maven-resources-plugin to copy the file you specify in the profile.
Use the filter feature in Maven with profile driven properties.
Use the maven-replacer-plugin to manipulate the file directly based on profile driven properties
Use the maven-dependency-plugin and store your files in your local Maven repository and pull them down from their during the package phase.
profiles are very powerful and a perfect fit for configuring Maven for different environments. I have a local, dev, qa and release profile in every pom.xml. I set the local profile to active by default, and pick the others as I need them with mvn [goal] -P dev which will automatically disable local and use the properties specificed in the dev profile.
More sophisticated SVN oriented
You could work off a local development feature branch and only have your local configuration on that branch, and when you merge your code changes back to the trunk exclude your changes to the configuration file from the merge. This is actually how I would do it since, we use Git. Branching isn't so painful in SVN that this isn't an option
I am sure there are other Maven solutions as well. Either way you solve it svn.ignore is your friend. And Maven profile usage can be very powerful.
Is the Maven replacer plugin a solution for your need?
We use jasypt to encrypt our passwords within properties files read by Spring. The tool can be used without Spring as well. This makes it very simple to keep your properties files in source control.
If your issue is user credentials, then I would suggest that you use a test account for any automated tests that you run.
I think filtering may suit your needs. You can have a local.filter that is not checked in and prod.filter that is. You can use the prod.filter by default and substitute the local.filter based on a command-line flag or local profile that developers would need to use, but deployers would not.
I'm writing a Java application that needs a lot of static data that is stored in many enum types. Since I would like an user-friendly way to customize this data using for example xml or json files but I'm not allowed to do it directly with enums I was looking for a way to elegantly do it.
Maybe a good solution would be to have a separate java program that reads the xml files and produces the java sources that are then compiled with the remaining part of the sources. My doubs is how to automatize this process in a stand alone way (eg ant?) and how to integrate it seamlessly with eclipse so that it is autOmatically done when I'm working with the project.. Does anything similar to what I'm looking already exists? Any suggestion to solve my problem?
Thanks!
If the items and the overall structure are somehow fixed (and what varies most is the values of the attributes), you could consider defining the enum with one entry for each of your items and let the enum populate its own constants with data read from an external source (XML / JSON) -- at load time or on demand.
Create a project whose sole job is to generate java from your sources.
Make sure that the generation phase is done by Ant.
Now, wrap this project into eclipse and use a custom ant builder, that calls the target in your already existing build.xml.
This is a standard part of our dev infrastructure, so this definitely works.
You can write a maven plugin that generates the code. There are some plugins that do that. It won't work automatically, but you can connect it to the standard maven lifecycle so it gets executed just before compile.
I just did something like that recently.
You can have ant seamlessly integrate with eclipse to achive that:
In Eclipse open project properties, go to "Builders", click "New...", select "Ant Builder", select a build file, go to "Targets" tab and click "Set Targets..." for "Auto Build". Select the desired target and you are done. The target will run every time you save a source file (if "Build Automatically" is selected).
Have you considered including the XML files in your jar, and loading them on startup into maps that use the enum as a key?
Is it true that the only configuration file I need to bother with is pom.xml ?
It seems to me that Java guys live xml more than any other stuff,is that true?
Maven uses XML for POM files because XML is a good choice for describing things ... and a POM file is a description of a project. I supposed that the Maven implementors could have invented a custom language, but then lots of people would have complained about having to learn another language syntax.
It would make no sense to express Maven POM files in some kind of scripting language because they are not "scripts" in any recognizable sense.
It seems to me that Java guys live xml more than any other stuff,is that true?
No. "Java guys" use all sorts of technologies for configuring things: XML, JSON, properties files, databases, bespoke languages, you name it someone has used it.
If your problem is that you hate using XML, either:
get over it,
get an editor that hides the XML syntax from you,
use (shudder) Make,
use (whimper) build scripts written in some clunk old scripting language, or
go away and implement a better solution.
But I'll stick with Maven, thanks.
Is it true that the only configuration file I need to bother with is pom.xml ?
Yes, Maven uses a pom.xml file to describe a project's medata and extend Maven's behavior, which also known as the Project Object Model (POM) file.
Maven will also look by default for a per user configuration file in ~/.m2/settings.xml but this file is optional.
Why doesn't maven use scripts for this kind of job, I don't see xml has any advantage here, which is why I don't like ant
What should Maven have used in 2002 if not XML? Makefiles? In my opinion, XML was and still is a very decent choice for a declarative Project Object Model. Yes XML is verbose but it is perfect for the job and allows to benefit from nice things like validation, transformation, code completion which seem important to me.
Now, nothing forces you to use Maven if you don't like it and feel free to use Gradle or Gant or Buildr (if the size of their communities is not a concern).
Just in case, note that Maven 3 offers polyglot support (see this post and this one) but as I said, writing a pom in Groovy, YAML, etc doesn't only have advantages (e.g. validation).
You probably want to give some attention to the settings.xml file too. However, for the most part you are correct, everything is in the pom.xml