This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 62228 - nbdeploy task does not work for freeform projects
Summary: nbdeploy task does not work for freeform projects
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Freeform (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P2 blocker with 2 votes (vote)
Assignee: Andrei Badea
: 53547 (view as bug list)
Depends on:
Blocks: 89477
  Show dependency tree
Reported: 2005-08-12 16:44 UTC by _ gsporar
Modified: 2008-04-25 13:13 UTC (History)
3 users (show)

See Also:
Exception Reporter:

Example standalone deployer (38.69 KB, application/octet-stream)
2007-04-13 16:21 UTC, rcauble

Note You need to log in before you can comment on or make changes to this bug.
Description _ gsporar 2005-08-12 16:44:35 UTC
If a user has an existing web/enterprise application then they probably have an
existing Ant script.  Which means if they want to use NB for development on that
application they will probably create a freeform project.  

One of the reasons for using NB would be to take advantage of the server plugins
that are available.  Instead of hassling with starting/stopping the server
manually the user could go to the Runtime tab and see the server status, click
on the plus sign (+) and see the apps. that are deployed, etc.

But to fully make use of a server plugin, the user might want to use the
nbdeploy Ant task in their build.xml.  That way when they are using NB, the NB
plugin is responsible for starting the server, etc.  Unfortuntately, the
nbdeploy Ant task does not work for freeform projects.  The text below is from
an email from Pavel:

"Dont' try, it is not supported. The nbdeploy task that is used in standard web
module projects does not work with freeform web modules. The nbdeploy task does
not run outside of IDE and it needs certain things from project (from its
lookup) that are not implemented in freeform project.

There are 2 ways to fix this. One would be to implement support for nbdeploy in
freeform project. This would be relatively easy, but it would still run only in
IDE. The other option would be to change deployment to use pure ant tasks w/o
dependency on IDE infrastructure. This is something we have had on our plan for
some time, there is even a prototype, but we never had time to complete it."
Comment 1 Jesse Glick 2005-08-12 17:27:30 UTC
Nothing to do with freeform projects as such - it is a problem with the task.
Comment 2 Andrei Badea 2005-08-18 09:56:45 UTC
The question is whether users really need a task defined by the IDE in order to
deploy their projects. If the user has already written a  build script for his
project, he has probably written a task for deployment too. He will then expect
he could run this task from the IDE (as he can do with the run, build, etc. tasks).

Reassigning to Pavel for evaluation.
Comment 3 _ gsporar 2005-08-18 15:11:26 UTC
>The question is whether users really need a task defined by the IDE in order to
deploy their projects.

To me that's not the question at all.  Someone who already has an Ant script in
all likelihood already has a deploy target that puts the .war/.ear in the right
place, etc.  

The issue is that we want people who are using free-form projects to be able to
take full advantage of the facilities provided for non-free-form projects.  A
non-free-form project can use nbdeploy and nbdeploy will use NB's plugin for the
server to determine if the server needs to be started (and if it does, it will
start it).  But if you have a free-form project, you cannot use nbdeploy to take
advantage of the NB plugin's functionality.
Comment 4 John Jullion-ceccarelli 2005-08-19 07:17:47 UTC
I think it would be good to allow users to use the IDE to deploy their
applications through the IDE. Part of my overall campaign to have free-form
projects contain the same functionality as standard projects :-) Could this be
done as part of the effort to make the web and J2EE Ant scripts runnable from
the command line?
Comment 5 Geertjan Wielenga 2005-08-19 11:49:38 UTC
Anything that makes free-form projects less different from standard projects is
a good thing. 

On top of that, I think making nbdeploy available to free-form projects would
also be very good if we want to have a strong story for JBoss, WebLogic, etc.
Free-form projects would be used by existing JBoss users, as well as for porting
JBoss (and other servers') samples to be used with NetBeans IDE.
Comment 6 rcauble 2007-04-13 16:21:55 UTC
Created attachment 40901 [details]
Example standalone deployer
Comment 7 rcauble 2007-04-13 16:27:37 UTC
We ran into this issue and ended up creating our own standaloneDeployer in our 
module. I've attached a stripped down module that contains only this deployer. 
The attachment contains 2 projects:

1)A netbeans module project standalone-deploy/StandaloneDeploy

2)A freeform ant project which uses this task.

Here what you need to do to test this out:

1)Unzip the attached

2)Open the project standalone-deploy/StandaloneDeploy. 
(I'm using Netbeans 5.5+JDK1.5)

3)Right-click on the project->Run Project

4)Within the launched netbeans instance, open the project

5)Right-click on StandaloneDeployTest->Run Project. It should launch and open
a browser.

6)Now try debugging. Set a breakpoint in index.jsp. 
Right-click on StandaloneDeployTest->Debug Project. It should launch and open
a browser. The debugger will suspend on your breakpoint.
Comment 8 rcauble 2007-05-05 16:17:42 UTC
Note that the standalone deployer does not work for SunONE Application server. 
I tried the following:

1)change the default application server by adding the following 
DefaultInstance.settings to 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server-string PUBLIC "-//org_netbeans_modules_j2ee//DTD ServerString 
1.0//EN" "nbres:/org/netbeans/modules/j2ee/deployment/impl/server-string.dtd">
<server-string plugin="J2EE" url="[C:\Sun\AppServer]

2)Run the project. I get:

No Project and/or J2eeModuleProvider located for C:\standalone-
See the server log for details.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy
        at org.netbeans.standalonedeploy.StandaloneDeploy.execute
Caused by: java.lang.IllegalStateException: No Project and/or 
J2eeModuleProvider located for C:\standalone-
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.init
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy
        ... 19 more

Looking at the source code of SunONEDeploymentConfiguration, it looks like the 
problem is in getProvider which assumes it can get the J2eeModuleProvider from 
the project rather than from the J2EEModuleProvider that was passed into 
private J2eeModuleProvider getProvider(File file) {
        J2eeModuleProvider provider = null;
        if(file != null) {
            FileObject fo = FileUtil.toFileObject(file);
            if(fo != null) {
                Project project = FileOwnerQuery.getOwner(fo);
                if (project != null) {
                    org.openide.util.Lookup lookup = project.getLookup();
                    provider = (J2eeModuleProvider) lookup.lookup
            } else {
                File parent = file.getParentFile();
                if(parent != null) {
                    provider = getProvider(parent);
        return provider;

It's very important to us that this problem be resolved for the sake of people 
who want to use Sun Application server. Using the Web project is not an option 
for us because it is important that we integrate easily with existing ant 
scripts which do far more than the basic web application ant script. 
Comment 9 Petr Jiricka 2007-05-24 08:47:46 UTC
*** Issue 53547 has been marked as a duplicate of this issue. ***
Comment 10 Sherold Dev 2007-05-24 13:25:35 UTC
Your problem is not very easy to solve.

Code in j2eeserver and in some of the plug-ins relies on the fact that
J2eeModuleProvider instance can be obtained from the project lookup, it is a
contract which is specified in J2eeModuleProvider javadoc.

The right way to go would be to implement the J2eeModuleProvider in the freeform
project as other projects do. One of the reasons for this is that user should be
allowed to select the server instance he wants to deploy his project to in the
project properties dialog. I notice that right now you are deploying to the
'default' server instance. Please note that the 'default' server instance
approach is not really supported anymore, we wanted to remove the related API
already in NB 5.5, but we had to keep it because of the Maven IDE support. We
will probably remove it in NB 6.0, however. For more info about this see issue

Another thing you should be aware of is that in NetBeans 6.0 we made
incompatible changes in the j2eeserver API because of the new NetBeans Java
infrastructure. For more info refer to

You might want to take a look at the j2eeserver Ant deployment support, see
org.netbeans.modules.j2ee.deployment.devmodules.api.AntDeploymentHelper. This
support was implemented to replace the nbdeploy task in J2EE projects when
deploying from command line - outside the IDE, but its usage is quite general.
Limitations are that only the GlassFish and the Tomcat plug-in support it at the
moment and that starting/stopping of the server is not supported.
Comment 11 rcauble 2007-06-01 15:29:45 UTC
Is there anyway I can bribe you not to remove the default server instance? Or 
at least keep it until the freeform project has been enhanced to be a full-
blown j2eemodule provider? Currently we have our own version of nbdeploy 
(attached) which relies on the notion of the default project. Since this can be 
made without changing any netbeans core code, it was the only choice for us for 

I guess it terms of priorities, we have the following:
1)Being able to deploy to *a* server. This is a must have.
2)Being able to deploy to *any* server type. We're going to get beatup if we 
can't support Glassfish long-term, but is less important than #1 since it's 
just for their dev environment that they would need to use Tomcat.

The AntDeploymentHelper you mention sounds interesting, but it is very 
important for us to be able to start a server automatically. 
Comment 12 rcauble 2007-06-04 21:13:12 UTC
Having thought about this a bit more, I would encourage you to consider the 
possibility of going with the approach of a standalone nbdeploy task, where all 
parameters are inputs to the ant task, rather than trying to get them from the 
project lookup. (I see what you mean about there being a number of places which 
attempt to lookup in the project, so I realize that it's not a trivial 
exercise, but should be considered). Also, from
our standpoint, I don't think that adding J2eeModuleProvider to the ant project 
lookup will get us the functionality we need (see item 1 below).

The 2 main advantages I see to this are as follows:
1)It's more powerful in that it gives the ant script full control over what 
gets deployed. Consider the use case of more than one war per project. This may 
sound theoretical, but it's not, in fact it is something that we are doing 
today. To give you some background we have an ant project with a build script 
setup such that it builds from a single source a war for different target 
environments - dev, test, and production. This project is geared towards 
professional services deployments of an enterprise software product. In a 
typical deployment, there will be a dev/test environment with a different set 
of resources that in production. The wars produced differ in some configuration
and the database repository to which they refer. The ant build has a "current-
target" property which controls the war which is produced when the
project is built and the war which is deployed to Netbeans appserver when the 
project is run. Commonly, there will be a problem which can only be seen on a 
production resource, and so they will need to run their production 
configuration in their IDE to debug it. 

2)It's more re-usable since it can be used in any project, not just a project 
which implements J2eeModuleProvider. This is nice for people
who are implementing their own project types (it's one less thing that needs to 
be implemented).
Comment 13 Sherold Dev 2007-06-05 10:27:21 UTC
I see no reason why you should want to depend on the default server. It is
something which is not supported anymore and its behavior is non deterministic.

What you should do is to override the J2eeModuleProvider.getServerInstanceID and
J2eeModuleProvider.getServerID() methods and return IDs of a server you want
your module to be deployed to.

We certainly would like to make the nbdeploy task standalone, there is a lot of
reasons for it. Unfortunately, we haven't had free cycles for it yet.
Comment 14 Andrei Badea 2007-07-04 09:58:43 UTC
The EJB freeform project has been dropped from NetBeans 6.0.
Comment 15 rcauble 2007-07-05 03:05:17 UTC
I'm not sure what the EJB freeform project is. Is this the same as the ant freeform project?
That is what I thought this bug was describing. Can someone please confirm? I really hope that there
is a misunderstanding and that you are not dropping support for the ant freeform project! We are heavily dependent upon 
Comment 16 Andrei Badea 2007-07-09 10:38:26 UTC
We are not dropping the Ant freeform project per se, but one of its natures. An Ant freeform project is composed of one
or more natures, which provide support for various technologies. Until 6.0 there was a Java SE nature, a web nature (for
supporting web projects) and an EJB nature (for supporting projects using EJB). In 6.0 we are dropping the EJB nature.
The support for Java SE and web freeform projects stays.
Comment 17 rcauble 2007-07-09 13:39:40 UTC
Ok. Thanks. I feel better! 

But would you agree that this bug would still be valid for the ant project? 
Really what we need is a standalone deploy task (like the one attached) that works regardless of
of which project it is running from.
Comment 18 Andrei Badea 2007-07-09 16:49:02 UTC
I'm not convinced about the need of a standalone deploy task, but reopening since the bug was closed accidentally
because it was assigned to j2ee/ejbfreeform.
Comment 19 Petr Jiricka 2007-07-09 17:21:59 UTC
Ok, moving to web/freeform, as it still applies to it.
Comment 20 rcauble 2007-07-09 19:20:24 UTC
Thank you!
Comment 21 Milos Kleint 2007-08-28 08:55:19 UTC
has cargo (at been evaluated as a possible alternate solution for standalone deployment? I'm sure a
separate module could be written that would provide the necessary ant script snippets..
Comment 22 Jiri Prox 2008-04-11 01:13:43 UTC
moving opened issues from TM <= 6.1 to TM=Dev