Every developer in our company needs a settings.xml file for using Maven. This settings.xml file is completely equal for each developer (we do not have any passwords etc. in it). Occasionally, it will be edited by the build manager.
What is an easy way to distribute new versions of settings.xml?
Theoretically, I can think of three possibilities:
Write a newsletter and tell everyone to copy the new settings.xml from a central source.
Put the settings.xml on a network drive and tell Maven to grab it from the globally valid path (how?)
Use the Nexus mechanism of settings.xml templates. I understood that the user can grab a new version by using a Maven goal (so again, writing a newsletter "Please update!") but I am not sure whether it can be run in batch mode inside (each) build process.
Which approach is the most practical one?
You could create a symlink to some network share containing your settings.xml.
For example, in Windows:
mklink C:\Users\username\.m2\settings.xml \\server\share\settings.xml
This needs to be done one time on all developer machines.
Then maven and all other IDEs should treat this file as local.
P.S. Newsletter and wiki could be better approach though. Some devs may still need to modify their settings.xml sometimes for a special project or so. It is better to leave them in control of their dev environment.
Nexus has a feature for managing and distributing settings files.
https://books.sonatype.com/nexus-book/reference/maven-settings.html
I think this is the third option you've listed.
Looks like something that could be automated.
Related
Recently, I have had to port an app from Tomcat to Wildfly and I'm currently working on setting up the modules directory for Wildfly.
It took a little bit of learning, but I figured out how to set up Spring, ActiveMQ RA, and several other libs as modules. This is working, but it has me worried about future maintenance of the modules directory. I have had to craft the entire directory by hand and I am worried about having to do this for every new dependency that every new app needs.
What are the best practices for maintaining JBoss Modules? Is the modules directory put into some version control system like SVN to detect and propagate changes?
Lets say I need a new framework in my app. From my understanding I would need to download the jars, create a modules directory for the jars, and then repeat this process for each environment in which I need Wildfly. What happens when needing to do this while other apps are running? This seems extremely time consuming in the long run.
I feel like there is a much better way to do this that I am either not realizing or too green with JBoss to understand.
With Maven and a pom, its so simple to hook up to a local or remote repo, and have the entire directory built out and available everywhere automatically. I feel like there must be something similar for JBoss Modules.
At the heart of my question: How are others using JBoss Modules and maintaining it within a production environment? What resources should I read or utilize?
Thanks for your time.
Kevin
I'm also looking for a solution for this.
I have previously been in projects where the JBoss CLI is being used. But I dont like that. It adds complexity as the JBoss CLI scripts are something new that developers need to understand. Changes in files are easier to understand.
I'm thinking of this:
Put a directory in a git-repo that has the exact directory structure as JBoss version used.
standalone-full.xml is put in git-repo/jboss-eap-6.4/standalone/configuration/standalone-full.xml
module.xml-files is put in git-repo/jboss-eap-6.4/modules/system/layers/.../module.xml
Also a setup.sh that will:
Copy the files from the git-repo to the installation directory of JBoss.
Download any jar-files, needed for the modules.xml, from a configured Nexus server. And put them into correct modules-directory.
The benefits are:
No binary files in git.
Changes to configuration of JBoss can be tracked.
The setup can be a part of a bigger scripted setup of for developers or docker images...
I recently started developing a plugin, which consist of several Eclipse Plugin-Projects. I use Maven/Yycho as a build tool and GitHub as version control system.
Now I was wondering what to push to my GitHub repositories. The POM files and Feature/Updatesites as well? It seems that this stuff is:
very User specific (the path are relative to the file structure on my computer)
do other developers need that stuff or should I give them the freedom of choosing their own build tools?
To clarify, I have right now 6 Eclipse projects:
*.plugin1
*.plugin1.tests
*.plugin2
*.releng
*.feature
*.p2updatesite
Would it be good practise to share everything? From my feeling I would say I will only share plugin1+tests & item # 2 (without the pom files) so that everyone can take care themselves about building.
You don't have to add to your repo:
anything that can easily be regenerated
anything with local paths specific to a user
Regarding building, ideally you should version at least a script able to generate the right pom, in order for a new contributor to be able to get going as fast as possible after cloning it.
If you can have config files with only relative paths (instead of absolute one), then you can include those, for others to use.
See for instance ".classpath and .project - check into version control or not?".
I have a Swing/Java application that is being used for clients and has weekly updates.
The problem is the setup just lay out the classes and their respective directories and on the update I just update the classes.
I want to do a single jar containing all the classes, but I'm not sure how would I be able to update it...
Also some clients need some updates during the week where only one or two classes would be updated.
What is the right way of doing this ?
Im using Eclipse.
EDIT: I know how to create the jar, I just dont know how to dynamically update it.
I would suggest you look into Java WebStart which is designed to do exactly what you need.
You need to first create the finished deployment and then you can look into creating a JNLP file for the deployment, and a way to put all the files to a web server for the user to access. For now just let the user download the whole thing every time you update. When you get more experienced you can look into how you can make incremental updates.
I would strongly recommend including a build number or timestamp in the deployment paths so a jar file is not cached incorrectly in the client by accident.
The general way of doing this, even if only small changes were made, would be to repackage your JAR after each update and give that JAR to a user. The user would replace the existing JAR. How you produce your JAR is up to you. Many IDEs support it, you could write a shell script, use existing build systems like ant or maven or even make, whatever. (See edit below)
If your JAR is very large and deployment is cumbersome, you may be able to split your project into smaller subcomponents, each with their own JAR, and only redistribute the ones containing changes. That may or may not be a major refactoring for you, and it might not even be appropriate. For most small or average size projects, this is generally unnecessary.
As for deployment, there are also a zillion ways to make that easier on the user. You could just give them a JAR file. You could use e.g. install4j. You could use Java Web Start (although its kind of clunky). There are others.
Both install4j and JWS support automatically checking for updates. If you choose to support that feature, all you would need to do is update your distribution site, and users would receive updates automatically. That's also up to you.
But a short answer to your question is: If you have all of your classes packaged in a JAR, no matter how many classes change, you'll want to give the entire updated JAR to the user. The benefit that counters this cost is that a JAR is a nice, compressed, self-contained collection of your application/library's source, which makes management and deployment very convenient.
Edit: Responding to your edit where you specify that you are using Eclipse, Josh M gives you instructions in his comment on your answer. To add to his comment, to export a Runnable Jar you'll have to have a Run Configuration set up which, if you've been running your application in Eclipse already, you probably already have. If not you can create one in the Run menu.
Edit 2: Please refer to Thorbjørn Ravn Andersen's answer as well for some good JWS tips.
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 trying to figure out the optimum way to develop and release a fairly simple web application, and I'm running into several problems. I'll outline the decisions I've made, because somewhere I've clearly gone off the rails.. Hugely grateful for any help!
I have what I think is a fairly simple web application. It contains a couple of jsps that reference a couple of java beans, and the usual static html, js, css and images.
Decision 1) I wanted to have a clear and clean release procedure, such that I could develop on my local machine and then release reliably to a production machine. I therefore made the decision to package the application into a war file (including all the static resources), to minimize the separate bits and pieces I would need to release. So far so good?
Decision 2) I wanted things on my local machine to be as similar as possible to the production environment. So in my html, for example, I may have a reference to a static file such as http://static.foo.com/file . To keep this code working seamlessly on dev and prod, I decided to put static.foo.com in my /etc/hosts when developing locally, so that all the urls work correctly without changing anything.
Decision 3) I decided to use eclipse and maven to give me a best practice environment for administering and building my project.
So I have a nice tight set up now, except that:
Every time I want to change anything in development, like one line in an html file, I have to rebuild the entire project and then wait for tomcat to load the war before I can see if it's what I wanted. So my questions are:
1) Is there a way to connect up eclipse and tomcat so that I don't have to rebuild the war each time? ie tomcat is looking straight at my actual workspace to serve up the static files?
2)I think I'm maybe making things harder by using /etc/hosts to reflect production urls - is there a better way that doesn't involve manually changing over urls (relative urls are fine of course, but where you have many subdomains, say one for static files and one for dynamic, you have to write out the full path, surely?)
3) Is this really best practice?? How do people set things up so that they balance the requirement for an automated, all-encompassing build process on the one hand, and the speed and flexibility to be able to develop javascript and html and css quickly, as quickly as if one just pointed apache at the directory and developed live? What do people find works?
Many thanks!
Edit: Thanks all for your great responses! If I could mark them all right, I would.. This has really helped me out. What I'm hearing is that best practice is to conserve the structure of the webapp in development, and run it in as close an environment to production as possible. Seems like the differences between people are the extent to which people are prepared to hot deploy resources into the servlet container, circumventing the build process for a little extra speed or convenience. That makes sense. Thanks again.
This is much like what I have to do at work, although we use ant (for now?). Also, while I use an IDE (or two), I refuse to have one as part of my build process, EVER. Somebody needs to be able to understand and tune your build.
Is there a way to connect up eclipse
and tomcat so that I don't have to
rebuild the war each time?
1) I think you're relying too much on your IDE. Usually I have an Ant build.xml that has a couple of tasks: one is "build war" the other is "update jsps." Building the war compiles all the code, packages it, deploys it to Tomcat and restarts everything. Updating the jsps doesn't restart the server, it's just a straight copy from my local files to Tomcat's deployed instance. No restart necessary since they're JSPs. Takes about half a second.
where you have many subdomains, say
one for static files and one for
dynamic, you have to write out the
full path, surely?
2) No way, Jose. So you mean any time the server name changes, you have to recompile your code? If you need to support dynamic URLs you might just want to bite the bullet and take a look at a framework to do the heavy lifting for you. I'm partial to Stripes (which supports dynamic URL rewriting out-of-the-box)... there are others.
To answer #1, I would suggest the following:
Spend some time learning maven to build your .war without eclipse. It's not that hard with the proper archetype. See here for more details: http://maven.apache.org/guides/mini/guide-webapp.html
Maven can generate eclipse projects either through mvn eclipse:eclipse or by using the m2 plugin
For deployment to your local machine and to production, use the maven cargo plugin. http://cargo.codehaus.org/Maven2+plugin and http://blank.jasonwhaley.com/2010/03/automated-deployment-with-cargo-drive.html
To answer question #2, there's nothing wrong with modifying your /etc/hosts file to mimic production. Just have a quick script that lets you add/remove those entries and flushes your dns cache. I do exactly that all of the time. (be sure to make your browser clear its cache frequently also through its relevant setting).
To answer question #3) yes this is how you should be doing things. Each build should result in a single deployable artifact that you can deploy to any of your environments in one step. You need to make sure you can do this without your IDE and use the IDE only as a tool to help you during the development phase.
Others have already answered you, I'll just comment on this (this too long for a comment btw so I make it an answer):
Every time I want to change anything
in development, like one line in an
html file, I have to rebuild the
entire project and then wait for
tomcat to load the war before I can
see if it's what I wanted.
If you change one line in an html file, there's no need to rebuild the entire project.
Note that I always rebuild the full .war and redeploy my .war but this takes less than two seconds (less than one second to rezip the .war [that's really what a .war is, a zipped file] and less than one second to redeploy it) because:
you don't need to recompile your entire project when you simply change one line in an html file
Same when you change one .java file: you can simply recompile that one file and re-war.
I wrote my own Ant build file from scratch (no Maven here) and I've got several targets. I can force a "clean build", that shall re-compile everything but typically I'm simply repackaging and redeploying the .war
You can check it for yourself: build a .war, unzip it in, say, directory dir1, then modify one .html (or one .java/.class file) and build a new .war and unzip that new .war in, say, dir2.
Then compare dir1 and dir2: now fix your build process so that you can create that second .war without needing to recompile everything.
Changing one .html, .java, .jsp, .css, .js / whatever file and redeploying a new .war should be a matter of seconds (less than two seconds if you didn't throw the kitchen sink in your Webapp).
Note that on the very same project, another developer here prefers to "hot deploy" / replace the files directly in the exploded webapp (I prefer to redeploy a .war everytime and because my complete repackage/redeploy takes less than two seconds I'm fine with it that way).
You don't need to reconstruct war file if your project is an Dynamic Web App in Eclipse and configured Tomcat server properly. Follow the below instructions:
1) Check out the below of how to configure tomcat server with eclipse:
http://greatwebguy.com/programming/eclipse/make-eclipse-and-tomcat-play-nice-together/
2) Use relative paths for your application but not absolute paths.
3) If you follow the above 2 steps properly then you have a best environment for development.
during development, you should configure eclipse and tomcat so that no rebuild/redeloy is required. just modify html/css/jsp etc, save, and refresh browser to see the result.
but before deploying to production site, you should do a clean full build and test it carefully.
domains: they should be in a config file; dev and prod should have different config files.