Most of the project artifacts (build time, run time libraries) needed by our development environment is handled dynamically via maven dependencies. But there are other programs which have to be used for all developer accounts before they can reliably use the system (e.g. JDK, Ant, svn client or tortoise svn, eclipse, maven, jboss appserver ...)
Is there a way to automate this, so that you can get the developer quickly up to speed on the development environment. How an where do you store such artifacts (currently we point to a http server to download such artifacts, but its quite burdensome over a period of time), what other options exist over here.
EDIT 1:
Some of the tools don't make changes to the registry, predominantly you unzip and run (e.g. ANT, JBoss, ...).
Some of the tools say Tortoise SVN is painful as you need to install them via their installer. If the vendor starts pushing out their delta changes, there is no clear way to push these changes to all developer machines)
We've been using Virtual Machines with Ubuntu Linux for a year now, to do exactly what you're describing. That way, the only thing developer need to do to get started is run a virtual machine with all the necessary stuff on it.
It has a little bit of performance penalty, but you can work perfectly with it.
The simplest solution would be to prepare a disk image for the whole machine which would contain all these tools. But that is not a 'modular' option as it also dictates the operating system.
The best solution would be 1 big archive that contains all the tools needed. The problem with this option are the files that would be missing due to not installing the tools properly (such as the svn shell extensions that are defined in the Windows Registry).
Unfortunately, there is no common method to do all this. It's an extremely painful process to set everything up, took me around 4 hours to set up my current workstation (eclipse, svn, maven, ..)
But it could be worse: Imagine you used MS Visual Studio with MS Sql Server. Their setup scripts take a HORRIBLE time installing. Service Pack 1 for VS took 90 minutes to install.
One options is to create a system image but it also have its downsides.
Our system support department tried this option but quickly found out that some of the tools installed on the machine that was used to create the system image were storing user/license information during installation. When the image was restored on a brand new system, license collisions were reported.
Related
is there a difference between using my java program as a jar file as opposed to using a software like IzPack to create an installer and install it onto a system ? Does it make any difference performance wise and what are some benefits ( if any) of going either way ( aside from creating shortcuts) ?
Using jar directly allows it to be used in other machines.
If you were to use IzPack to create an installer, it will still work in other systems after installation.
As far as I know, there is none performance-wise.
Your question is very vague.
Some tools like WinRun4J can be helpful to optimize the amount of memory available for your program at startup. WinRun4J and PackR allow to use a custom name for the executable which is useful if you want to hide the fact that your program uses Java.
Some web browsers under some operating systems break the downloaded JARs by wrapping them in ZIPs for "security purposes".
Some tools use a fat JAR in input and produce a kind a native bundle which is more familiar for the end users, PackR and JNDT produce APP files for OS X, JNDT produce RPM and DEB packages for GNU Linux.
Whether it is a jar file or Izpack installed java app, there won't be any performance difference.
The main differentiator I see is the user experience. For simple applications it doesn't make much difference. But for any medium to large scale application which needs to perform some prerequisite checks, capture configuration data from user, upgrade the application etc, installer helps a lot in making installation more user-friendly.
So using Izpack or in any installer in general, improves the user experience. Some of them I can think of are:
Installer can perform any software prerequisite checks before
installing the application.
Allows user to choose the installation location
Prompts for any required input parameters or configuration and validating it
Allows the user to enter these input or configuration data
Upgrades the software by taking care of any data software or data/configuration migrating and ensures proper rollback in case of
failures.
Without the installer most of these need manual intervention and installation becomes more error prone, manual errors and becomes a tedious job for the user.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Java is one of my programming languages of choice. I always run into the problem though of distributing my application to end-users.
Giving a user a JAR is not always as user friendly as I would like and using Java WebStart requires that I maintain a web server.
What's the best way to distribute a Java application? What if the Java application needs to install artifacts to the user's computer? Are there any good Java installation/packaging systems out there?
There are a variety of solutions, depending on your distribution requirements.
Just use a jar. This assumes that the user has the the correct java version installed, otherwise the user will get "class-file format version" exceptions. This is fine for internal distribution inside a company.
Use launch4j and an installer like NSIS. This gives you a lot more control, although the user can still do stupid stuff like un-installing the java runtime. This is probably the most popular approach, and what I currently use.
Use Webstart. This also assumes that the user has the correct java version installed, but it's a lot easier to get going. My experience is that this is fine for tightly controlled intranet environments, but becomes a pain with larger deployments because it has some many weird failures. It may get better with the new plug-in technology in Java 1.7.
Use a native-code compiler like Excelsior JET and distribute as a executable, or wrap it up in an installer. Expensive, and it generally ties you to a slightly older version of java, and there is some pain with dynamic class-loading, but its very effective for large-scale deployment where you need to minimise your support hassles.
advanced installer makes it easy to package java apps as windows executables, and it's quite flexible in the way you can set it up. I've found that for distributing java applications to windows clients, this is the easiest way to go.
JSmooth is a simple program that takes your jar and wraps it up in a standard windows executable file. It comes with a simple GUI that allows you to configure the required JVM, bundle it with the application or provide an option to download it if it's not already installed. You can send the exe file as is or zip it with possible dependencies (or let the program download the extra dependencies from the net on startup). It's also free, as in beer and speech, which may (or may not) be a good thing.
If it's a real GUI-having end user application you should ignore the lanaguage in which you wrote the program (Java) and use a native installer for each of your chosen platforms. Mac folks want a .dmg and on windows a .msi or a .exe installer is the way to go. On Windows I prefer NSIS from NullSoft only because it's less objectionable than InstallShield or InstallAnywhere. On OSX you can count on the JVM already being there. On Windows you'll need to check and install it for them if necessary. Linux people won't run Java GUI applications, and the few that will, know what to do with an executable .jar.
It depends on how sophisticated your target users are. In most cases you want to isolate them from the fact that you are running a Java-based app. Give them with a native installer that does the right thing (create start menu entries, launchers, register with add/remove programs, etc.) and already bundles a Java runtime (so the user does not need to know or care about it). I would like to suggest our cross platform installation tool, BitRock InstallBuilder. Although it is not Java-based, it is commonly used to package Java applications. It can be easily integrated with Ant and you can build Windows installers from Unix/Linux/Mac and the other way around. Because the generated installers are native, they do not require a self-extraction step or a JRE to be already present in the target system, which means smaller installers and saves you some headaches. I also would like to mention we have free licenses for open source projects
Although I haven't used NSIS (Nullsoft Scriptable Installer System) myself, there are install scripts that will check whether or not the required JRE is installed on the target system.
Many sample scripts are available from the Code Examples and Real World Installers pages, such as:
Java Launcher with automatic JRE installation
Simple Java Runtime Download Script
(Please note that I haven't actually used any of the scripts, so please don't take it as an endorsement.)
executable files are best but they are platform limited i.e. use gcj : http://gcc.gnu.org/java/ for linux to produce executables and use launch4j : http://launch4j.sourceforge.net/ to produce windows executables.
To package on linux you can use any rpm or deb packager. For win32 try http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System
I needed a way to package my project and its dependencies into a single jar file.
I found what I needed using the Maven2 Assembly plugin: Maven2 Assembly plugin
This appears to duplicate the functionality of one-jar, but requires no additional configuration to get it going.
For simple Java apps I like to use Jar's. It is very simple to distribute one file that a user can just click on (Windows), or
java -jar jarname.jar
IMHO, jar is the way to go when simplicity is a main requirement.
I develop eclipse RCP applications. Normally to start an eclipse application an executable launcher is included. I include the java virtual machine inside the application folder in a /jre sub directory to ensure that the right java version will be used.
Then we package with Inno Setup for installation on the user's machine.
What's the best way to distribute a
Java application? What if the Java
application needs to install artifacts
to the user's computer? Are there any
good Java installation/packaging
systems out there?
In my experience (from evaluating a number of options), install4j is a good solution. It creates native installers for any platform, and is specifically geared towards installing Java apps. For details, see "Features" on its website.
install4j is a commercial tool, though. Especially if your needs are relatively simple (just distribute an application and install some artifacts), many other good options exist, including free ones (like izPack or the already mentioned Lauch4j). But you asked for the best way, and to my current knowledge install4j is the one, especially for distributing larger or more complicated Java (EE) apps.
The best answer depends on the platform. For deployment on Windows, I have had good results using a combination of one-jar and launch4j. It did take a little while to set up my build environment properly (ant scripts, mostly) but now it's fairly painless.
Well from my point of view the superior distribution mechanism is to use something like ClickOnce, or WebStart technology. You just deploy the version to the server and it gets automatically to the clients when the version is released.
Also the Eclipse RCP platform contains UpdateManager that does what WebStart do, but also much more.
Since I am using Maven2 for building, the deployment is just a piece of cake: copy the built jar to the location on the server, update the jnlp file if needed and you are done.
installanywhere is good but expensive one - i have not found (as) good free one
I would zip the jar file along with other dependent jars, configuration files and documentation along with a run.bat/run.sh. End user should be able unzip it to any location and edit the run.bat if required (It should run without editing in most of the cases).
An installer may be useful if you want to create entries in start menu, desktop, system tray etc.
As a user I prefer unzip and run kind of installation (no start menu entries please). However People outside IT industry may have different preferences. So if the application is largely targeted for developers zip-run.bat route and applications for general public may be installed using a installer.
I am working on a enterprise product and primarily there are 3 pieces to it swing based client, DB, Server(for now we can ignore DB part). Being enterprise product Client and Server comes with their own installer(it is not like configuring apache or JBOSS and deploy war's on it).
We have CI configured to generate the nightly OS specific builds for Client and server which can be installed.
So we have to test these build regularly on specific OS, which requires a lot of manual process of installing and creating system with X version client on Y OS OR X version server on Y OS. This is becoming very tedious since we are all on windows and doing next-> next -> really sucks(I have created a script which installed our product via shell but then it is still steps which I believe can be automated, but don't how). And also we need an isolation.
Now I am thinking how can we automate this process of creating these test machine. I have just started exploring Vagrant/Docker if they can be helpful to me (and under the their concept, still doesn't understand Puppet/Chef though) and I am confused in which strategy should I adopt
Create VM via vagrant and run my installation script on that box (This will require one VM per Client or per server)
Create VM via vagrant and run my client docker containers on it (this I guess, will require one VM for multiple client or server, since they would be under container)
Note: I have to create VM, since we are on window.either via vagrant or via boot2docker
So my question are
If these 2 strategy are valid and not wrong then out of these 2 which strategy should I adopt out of two ?
Are there any different strategy that I am missing or am I approaching this in right way ?
If strategy #2 is to be adopted then how can I create container/docker images in which my client is installed
how can I create container/docker images in which my client is installed
You must put in a Dockerfile all what you do in order to have your client started and configured.
In order to do so, you can either create a container, do all the stuff, and then docker commit or the better way is to put all the required commands in a Dockerfile, so that when you do a slight modification, you build a new version easily with a basic docker build -t myclient_version_n .
Check the docs
https://docs.docker.com/examples/mongodb/#creating-a-dockerfile-for-mongodb
and how to automate builds
http://docs.docker.com/docker-hub/builds/#automated-builds
how to create a Dockerfile
https://docs.docker.com/examples/nodejs_web_app/#creating-a-dockerfile
and have a look at existing Dockerfiles of containerized application in the docker Hub
https://registry.hub.docker.com/
An alternative to Vagrant would be to use Docker Machine. You could leverage the cloud providers as #m1keil mentioned too. Machine can provision Docker hosts on a number of providers and they are ready to go.
Disclosure: I work at Docker and am the maintainer of Machine :)
Your strategies seem valid to me. The addition of containers (docker) to your process might help you speed up and parallelize the testing process (if it's fully automatic testing) since the initialization time and the general resource consumption of a container are lower. However one cannot give you definitive answer without inspecting your testing process first. And since you haven't provided any details about it, it would be hard to tell you if you should use the first or the second strategy.
You can take advantage of the cloud and use services such as AWS, Azure, GCE, etc to initialize machines and run your tests. You can use Vagrant to do this, or skip Vagrant and create your own simple scripts by using the appropriate APIs of your chosen Cloud provider.
Also you can take a look at services such as Travis.ci, Circle.ci, and others, which might help you created automated testing pipe without the need to spend too much time on the plumbing.
I really like docker's ease of use via the Dockerfile. The Dockerfile let's you very easily update and control the software in the docker image, and then you can provision it in you CI/testing environment. Docker now has native Windows support, so this shouldn't prevent you from being able to use it: https://docs.docker.com/docker-for-windows/ Furthermore, I like that you can setup very lightweight, minimal machines, with only the build and runtime dependencies needed for your project, and store them for free on hub.docker.com. Depending on how long it takes to build & install certain dependencies, this can speed up your testing because you can just download a docker image with everything already installed and built, and then just build and test your actual project.
I use this for https://github.com/sourceryinstitute/opencoarrays, which is GCC's official implementation of Coarray Fortran. I have a little project https://github.com/zbeekman/nightly-docker-rebuild that lets you setup nightly docker image builds on hub.docker.com in under two minutes. I use this to trigger builds of https://github.com/zbeekman/nightly-gcc-trunk-docker-image because I can't rebuild GCC from source on Travis-CI.org without the build timing out. This way, I delegate the GCC nightly build to hub.docker.com and then just docker pull zbeekman/nightly-gcc-trunk-docker-image into a travis-ci instance to test OpenCoarrays against the latest GCC trunk.
I'm trying to migrate from Windows to Linux as a Java development platform, and while the transition has generally been pretty painless, there are a few points of uncertainty that I'd like some feedback on. I'm running openSUSE 11.4, but I'm open to hear what works on other distros.
Where do you install your JDK from? This one is surprisingly not as cut and dry as most people make it out to be. OpenJDk 6 is available in the openSUSE repositories, and was very easy to install. However it's currently update 21, and right now the Oracle release is at update 24. I'm used to a little alert in Windows notifying me that my Java needs updating but that doesn't appear to be the norm in Linux. Do Java developers forgo the JDK in their package manager and install the binary directly? Or is there another way?
Where do you install Eclipse? There seems to be a general agreement online that Eclipse is best installed by simply downloading the binary and extracting it somewhere, but where's the usual place I would extract a program like Eclipse or Ant? I've seen votes for /usr/local and /opt online, but no definitive answer.
Where do you put your Jetty/Tomcat? Similar to the eclipse question, where do most Linux Java developers put their Jetty/Tomcat/other container.
What are some of the differences between the way you setup development versus production At the very least it seems I don't want to run my servlet container as root, that makes sense to me. But what other practices should I watch out for? Is there anything else that could make my development environment easier, but perhaps less secure?
I found this question was similar but ultimately too high level and didn't get into details of how actual developers are setting up their environment. If there's other resources you feel answer these questions, please share them here.
Thanks for your time.
Q> Where do you install your JDK from?
A> I never bother with other JDKs coming from outside Sun/Oracle mainly because our product is only certified to work with Sun/Oracle JRE. On my desktop, I run Kubuntu, but I never use apt-get for this but always download them manually. Reasons:
distro maintainers rarely rush to upgrade packages, as their primary concern is to make dependant apps (such as OpenOffice) work. If JDK changes from 1.6.0_20 to 1.6.0_21, they simply don't care. I might do because a newer patch might have an important bugfix or I simply want to try if my app still passes all the unit tests.
it might be a nightmare to retain old JDK versions. We still support older versions of our product and if I upgrade to a newer Kubuntu, I don't have guarantees that some ancient JDK will still be available as a package.
I am not sure some distros even support multiple existence of JDKs on the same machine.
My preference is to keep all JDKs/JREs in /opt and make a symlink to the newest one or the one I need most. I simply don't see why installing JDK manually is a problem.
I also set the PATH to the newest JDK/JRE.
Same thing (and similar arguments) apply to Ant and Maven.
Q> Where do you install Eclipse?
A> I use IntelliJ but the same applies. I store IDE in my home folder. This allows me to have different versions of it, update them without needing sudo, etc. I could as well install it in /opt but I guess I got this habit when I was downloading and testing newest IntelliJ IDEA EAP every week so I can quickly delete the older versions and do not pollute /opt. Finally, other programs might require Ant/Maven/JDK but it's only me who uses IntelliJ hence the different approach.
Q> Where do you put your Jetty/Tomcat?
A> I have a separate folder tomcats under /home where I have ~10 different Tomcat instances. Each of Tomcats is used for a different version of my app (we bundle Tomcat with our app). This is necessary because one deployment of our app can have different Tomcat settings (or even version) than another.
Q> What are some of the differences between the way you setup development versus production
A> It very much depends on your app. For example, we need some partitions to have lower access latencies but having less space (e.g. gigabytes for Lucene indexes) VS others which can have higher latencies but require more space (e.g. terabytes for content repositories). We, however, design our app so that all these different aspects can reside on different partitions which are configurable. Some partitions need to have special limitations (e.g. file upload) so this doesn't overflow other partitions. There is no simple one-for-all answer to this question, but obviously most of these concerns don't matter that much for a development environment.
Where do you install your JDK from?
I use Arch Linux myself, and we have the oracle jdk/jre in the repository itself. Hence, use your distro-repository if it has the oracle jdk/jre else get it from oracle itself.
Where do you install Eclipse?
Again, the same answer as above applies to this as well. If however, there is any issue with the distro provided version, I always put my custom installs in /opt/ - /opt/java , /opt/eclipse, /opt/netbeans - etc. I dont install stuff in my home folder (except in circumstances where I don't have permission anywhere else - rare), since that would mean that other users would need access to my home folder to run the stuff. I don't want production (or development for that matter) stuff having direct access to my home.
Where do you put your Jetty/Tomcat?
The same answer as above applies here as well. Only in circumstances, where I have installed more than one version, I create an /opt/experimental/ and install there so that I know which one my production is running and which one I can remove when no longer required.
What are some of the differences
between the way you setup development
versus production?
If possible, I always setup different machines for production and development work. Different computers, but exactly identical setup. The only systems that can push code to the production system are those in the development group. Where this segregation is not possible, I prefer to have different install for the servers, so that while I am tweaking the development configuration, my main servers don't crash or something. Also development setup will generally include a clean_up script that makes it ready for production (dropping unnecessary priviledges for db accounts, cleaning up, etc.
Have whatever, setup you will, just make sure you have different database setup for development and production purposes.
The Sun version of Java for openSUSE is on the nonOSS disk (go here and scroll down for an ISO), which is an additional disk image, not part of the main install disk ISO (or you can pull the RPMs from here).
As far as eclipse is concerned, if I'm installing at the system level, I tend to drop it in /opt. You might want to read this article on how best to handle plugins.
(Don't let them steer you off openSUSE, it is the best distro for KDE IMO.)
Working with linux is a lot less hand holding then the windows environment that you're use too. If I were you I would switch distros to either RedHat or Ubuntu, I use to use SUSE and never looked back since I switched.
You can put your JDK/Eclipse/Tomcat binaries in a couple of different places. If you are the only one going to be using them I suggest you put them in your home directory somewhere. For your Eclipse/Tomcat stuff you can but them in a local bin and then add that local bin to your PATH in your .bashrc. You can also set the location of your JDK to a JAVA_HOME env variable in your bash. If you need any more specific help with setup let me know.
1) We have had several problems with OpenJDK (bugs, etc) so we always use the sun jdk.
2/3) A good rule to live by when living in Linux, is always install your custom software under your home folder. Linux needs to be reinstalled from time to time, but everything in your home folder is in a separate disk-partition, so it lives on. I always installs/unzips custom software such as eclipse to /home/myuser/opt, so my eclipse lives at ~/opt/eclipse. I also symlinks the eclipse-binary to my /home/myuser/bin folder for easy access. When I upgrade or change any software, I just rewire the symlink.
4) Production and development environments should be as close as possible to identical. This elimenate loads of bugs caused by different configurations etc.
I create a /usr/local/java directory and unpack the JDK(s), Eclipse, Maven, Ant, Groovy and Grails in there, then create symlinks to /usr/local/bin.
I have been tasked to set up a Java based development environment across multiple Windows machines. The problem is that I want to the process to be done automatically and easily on each machine so the developers don't have to waste time downloading and installing all the different applications. Ideally, I would like to have the following:
Automated and unattended initial installs
Some sort of a monitor on those installations that would make sure the settings remain constant between all machines
A possibility to push new settings/programs/upgrades when required.
I've looked into several tools for the job. Currently the most promising one seems to be Puppet . However, Puppet doesn't work as well in Windows...
Using a VM image would solve the first requirement, but it is out of the question since the hardware is different across the machines and upgrades won't come easy.
Has anyone had any experience with this sort of task? How would you solve it?
I've been playing with Vagrant for a couple weeks and finding it a fantastic tool for this. It uses Puppet, Chef, or a customer "provisioner" on top of a VirtualBox, and is controlled by a simple command. They have a great tutorial/tour that will show you what it's capable of.
As an example, the direction I've been heading this week is writing Puppet scripts/modules to setup my production server, and all the dynamic parts are handled by parameterized classes. So my development environment will have the same OS, the same firewall settings, the same daemons, etc--all without affecting my host OS or doing any manual configuration steps.
That being said, I've not used it on a day-to-day basis so I don't know if there are any blocking issues, but I have used manually managed VirtualBox for the same purpose without trouble, so I don't foresee any problems.
The more interesting functionality is pulling information from the developers machines. The development environment changes, and different developers try out new things/programs/settings at a rate that is difficult to keep up with if it is not automated. Only having one configuration (the centralized model) kills your ability to respond to change. It is important to understand the differences between configurations, though.
One interesting option might be to standardize on the Eclipse IDE plus a set of plugins (SCM, testing, J2EE development etc.) and use the Eclipse update mechanism to deploy an identical configuration to every machine. Dependencies, synchronization and suchlike would be handled automatically by the Eclipse platform.
This might not work for you if you need some specific tools that are not available inthe Eclipse ecosystem, but my personal development environment is 100% Eclipse based so it is certainly possible to make this work.
Java can be installed globally easily. For Windows have your system administrator push out the MSI file embedded in the Java JRE installation executable. For Ubuntu ssh in and have the sun-java6-jdk module installed.
Then Eclipse is just a matter of pushing out an unzipped distribution to the users.
Most developers like to customise their setups, so I'm not sure this is going to be popular. You could go bleeding edge and look to provide them with instances on the cloud (once you've got one set-up correctly you can clone away!).
1) Use a Disk Image.
or
2) Put everything (Eclipse executable etc.) in SVN (or some other source repository). Then they just have to install SVN and checkout.