Nothing to do with freeform projects as such - it is a problem with the task.

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.

>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.

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?

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.

Created attachment 40901 [details]
Example standalone deployer

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 standalone-deploy.zip

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
standalone-deploy/StandaloneDeplyTest

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.

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 
StandaloneDeploy/build/testuserdir/config/J2EE/InstalledServers

<?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]
deployer:Sun:AppServer::localhost:4848"/>

2)Run the project. I get:

No Project and/or J2eeModuleProvider located for C:\standalone-
deploy\StandaloneDeployTest\web\WEB-INF\sun-web.xml
See the server log for details.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy
(Deployment.java:121)
        at 
org.netbeans.standalonedeploy.StandaloneDeploy$StandaloneDeployer.deploy
(StandaloneDeploy.java:204)
        at org.netbeans.standalonedeploy.StandaloneDeploy.execute
(StandaloneDeploy.java:119)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:64)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.taskdefs.MacroInstance.execute
(MacroInstance.java:378)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.Target.execute(Target.java:341)
        at org.apache.tools.ant.Target.performTasks(Target.java:369)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets
(DefaultExecutor.java:40)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run
(BridgeImpl.java:240)
        at org.apache.tools.ant.module.run.TargetExecutor.run
(TargetExecutor.java:293)
        at org.netbeans.core.execution.RunClassThread.run
(RunClassThread.java:131)
Caused by: java.lang.IllegalStateException: No Project and/or 
J2eeModuleProvider located for C:\standalone-
deploy\StandaloneDeployTest\web\WEB-INF\sun-web.xml
        at 
org.netbeans.modules.j2ee.sun.share.configbean.SunONEDeploymentConfiguration.get
Storage(SunONEDeploymentConfiguration.java:1222)
        at 
org.netbeans.modules.j2ee.sun.share.configbean.SunONEDeploymentConfiguration.get
WebAppRoot(SunONEDeploymentConfiguration.java:1256)
        at 
org.netbeans.modules.j2ee.sun.share.configbean.SunONEDeploymentConfiguration.get
ContextRoot(SunONEDeploymentConfiguration.java:1325)
        at 
org.netbeans.modules.j2ee.sun.ide.j2ee.ConfigurationSupportImpl.getWebContextRoo
t(ConfigurationSupportImpl.java:120)
        at 
org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl.getWebContextRoot
(ConfigSupportImpl.java:236)
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.init
(TargetServer.java:105)
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy
(TargetServer.java:445)
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy
(Deployment.java:106)
        ... 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 
Deployment.deploy()
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
(J2eeModuleProvider.class);
                }
            } 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. 

*** Issue 53547 has been marked as a duplicate of this issue. ***

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
83934.

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
http://wiki.netbeans.org/wiki/view/DDBeanRemoval.

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.

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 
now. 

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. 

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).

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.

The EJB freeform project has been dropped from NetBeans 6.0.

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 
it. 

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.

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.

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.

Ok, moving to web/freeform, as it still applies to it.

Thank you!

has cargo (at cargo.codehaus.org) 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..

moving opened issues from TM <= 6.1 to TM=Dev