What is the best way to deploy my web project (or ear project) to remote server and glassfish?
How to use ant-deploy.xml and build-impl.xml that netbeans create for this purpose?
Using autodeploy folder and separately adding sun-resources.xml to the GF Or Using ant and....
Would you please explain me step by step?
Regards
Well, you could manually deploy your app via the admin console.
Or you could use the asadmin command. A remote deployment in its simplest from would look like:
asadmin deploy --user=<adminuser> --host=<hostname> <path to jar/war/ear>
And this could be shell scripted, or wrapped in Ant, or Maven.
Or you could use more specialized tools (the Ant Task, the maven glassfish plugin, the maven asadmin plugin, Cargo).
It all depends on your context, there is no single answer and there are many possibilities. If you don't know what you're looking for, just use the Ant build scripts created by NetBeans.
Use a combination of:
To answer this question, it is useful to take a broader perspective and to consider the whole development/deployment life-cycle. The actual deployment of a .war or .ear archive in Glassfish is only one step of the cycle.
If you want to be really effective, you need to consider a combination of tools and practices for automating the construction and the deployment of your software applications. This is especially true if you work in a "real-world" environment with developer machines, continuous integration machines, QA machines and production machines.
I will elaborate a bit on these items in the following paragraphs. In particular, I will explain why I think that today, custom shell scripts driven by maven are better than the glassfish maven plugins available in the community.
For many people doing java development, maven is a well-known tool. For the others, here is a very brief introduction. The goal of maven is to automate the construction of software artifacts. It is a framework (in the same sense as an object-oriented framework), which means that:
In essence, when you use maven, you describe what kind of software artifact you are building (is it a .jar, is it a .war, is it an android app, etc.). By default, maven expects to find source files, test files and resources in specific locations. By default, maven knows that building the software requires to go through different phases: compilation, unit testing, packaging, deployment, integration testing, documentation generation, etc.
Another thing that maven does for you (and which is often the first reason for using the tool) is dependency management. Maven specifies a way to identify libraries (with a name and a version), which are made available through repositories (there are both public, global repositories and private repositories). With maven, you specify things like "I depend on magiglib version 1.2.2". When you ask maven to do the build, it will automatically fetch the lib, store it in a local repository and use it for the construction and the packaging. No need to deal with manual transfers of .jar files, no risk to introduce bugs because different version of the same lib are used by different developers or at different stages.
Last but not least, maven offers the ability to customize the construction of your software, depending on the target deployment machine. Think about the following use cases:
During development, think that every developer may have a different installation (mysql may not listen on the same TCP port, glassfish may not be installed in the same directory, passwords will be different, etc.).
A development machine is obviously different from a continuous integration environment, which is itself different from a QA or a production environment (again, just think about networking, file system, credentials).
Maven supports these use cases with the combination of variables, profiles and resource filtering:
Maven is an extremely powerful tool, and as such has a learning curve. If you use Netbeans, you can actually create a maven-driven project with a couple of clicks and benefit from the basic features (e.g. dependency management). For advanced topics, there is very good documentation available. I will not go into further details here.
Once you have understood the value of maven and decided to use it, the next question is how you can use it to do the actual deployment of the .war or .ear archive into Glassfish (locally or remotely). This is where you have a number of options and where we have learned quite a few things over the years (we have been using maven with glassfish for several years now).
The first thing that you can do is to use one of the glassfish maven plug-in. There are different plug-ins available. They have quite different capabilities and different levels of support. It turns out that the most powerful plug-in is actually not supported anymore and does not work with Glassfish 3 out of the box. The plugin was interesting, because it made it possible not only to deploy archives into Glassfish, but also to create resources (jdbc pools, jms queues, etc.). It also made it possible to create glassfish domains on the fly (very useful to run integration tests and make sure that a fresh domain was used for that). Anyways, the new plugins (that are described in the product documentation) are not that powerful and purely focus on the deployment task.
In the build system that we created and made evolve over the years, we were able to achieve a lot of control and flexibility by combining the glassfish maven plugin with profiles and resource filtering. The solution works, is solid, yet is quite complex (our pom.xml and settings.xml has grown a lot and has become heavy).
So, if I was setting up a new build system from scratch, I would probably do things a bit differently. If you look at the code of the glassfish maven plugins, you will see that they are pretty much wrappers around the asadmin command line tool provided by Glassfish (and it is because the parameters and behavior of asadmin has changed from one glassfish version to the other that the maven plug-ins have been broken).
What I would do is:
write a set of shell scripts to create glassfish domains, create resources (jdbc, jms, etc.), deploy .war and .ear. The scripts would use asadmin to interact with glassfish (it is possible to use asadmin both locally and remotely);
embed maven variables in these scripts and use resource filtering to dynamically create environment-specific versions of the scripts;
use the maven exec plug-in to run the scripts at different stages of the maven build cycle (integration test, run, custom goals, etc.).
You can use ant task to deploy war file to glassfish-V3;
Build.xml content;
<target name="deploy"
description="deploys application to glassfish">
<exec failonerror="true" executable="cmd">
<arg value="/c" />
<arg value="asadmin --user ${gfUser} --passwordfile ${gfPassFile} --host ${host} deploy build/${war}" />
</exec>
</target>
More os independent way to deploy app:
<presetdef name="asadmin">
<java jar="${glassfish.home}/modules/admin-cli.jar" fork="true" jvm="${java.home}/bin/java" >
<arg line="--port ${glassfish.admin.port}" />
</java>
</presetdef>
<target name="deploy">
<asadmin failonerror="true">
<arg value="deploy" />
<arg value="--force=true" />
<arg value="${ear.file}" />
</asadmin>
</target>
you colud use asadmin preset with any asadmin tasks...
I have found that several methods work well depending on your scenario:
Glassfish allows for automatic hot-deployment of resources placed in the right location "inside" the files of a running Glassfish. The default location for Glassfish 3.1.2.2 is glassfish-3.1.2.2/glassfish/domains/domain1/autodeply. I've previously found that under Windows it occasionally does not discover that a file has been updated, so first a removal and awaiting the undeployment before deploying in again, may be necessary.
The administrator page (default port 4848) contains a deployment section allowing users to upload and deploy, disable and enable, and undeploy applications. This is what I've found to be the most robust for manual maintenance.
It also does not require full access to the underlying server.
The cargo project allows for automatic deployment to a suitably configured Glasfish instance.
The following command executed with a pom.xml describing a war deployment will (as of 2012-10-17) download and execute a glassfish with the current project deployed to it.
mvn clean verify -Dcargo.maven.containerId=glassfish3x -Dcargo.maven.containerUrl=http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip org.codehaus.cargo:cargo-maven2-plugin:run
(along with a small snippet in pom.xml telling cargo additional details about the glassfish location)
Maven support has been good with Glassfish 3. The primary benefit is that you do not need to download and unpack and start Glassfish manually - maven can do it all automatically.
See http://embedded-glassfish.java.net/ for instructions.
I've only used this briefly, but it appear to be a nice alternative to the IDE-centric solutions.
Adding points to Answer from @Pascal Thivent, (I hope it would helpful for others with similar question)
1)It is just mouse click to start,stop,deploy the application with Netbeans.
2)Besides working with Eclipse or Netbeans or your favorite IDE
2.1)On Windows dev environment: start with command-line tools like asadmin during your development. 2.2)On Linux dev environment: use shell scripts and automate the deployment process.
2.3)Use autodeploy and Netbeans remote deployment in dev environment. 2.4)use scripted or command-line remote deployment is based on the need
3)You come up with a most appropriate approach like develop a 'build script' based on the project needs & interest, and other considerations like organisational process.
Without maven or ant, just adding necessary jars manually is not bad idea at all. After adding jars, deploy from admin console or just use build script.
Maven fails some times with JavaEE jars..but you have solutions in SO. I go with Maven some times based on existing sample project and organisational process. I also use ant that comes default with Netbeans Java EE project.
