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 271314 - Unable to deploy EAR with additional WAR or EBJ module that is not a project of the EAR with ANT project
Summary: Unable to deploy EAR with additional WAR or EBJ module that is not a project ...
Status: NEW
Alias: None
Product: serverplugins
Classification: Unclassified
Component: GlassFish (show other bugs)
Version: 8.2
Hardware: PC Mac OS X
: P2 normal (vote)
Assignee: Petr Hejl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-17 03:03 UTC by brett
Modified: 2017-08-17 03:06 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description brett 2017-08-17 03:03:37 UTC
To reproduce, create an ANT EAR project with an EBJ and WAR module.  With the EJB and WAR projects registered as additional content, you can deploy the EAR from within the IDE which uses directory deployment.

Now remove the WAR project from the additional content of the EAR and add the WAR project's built WAR from the the "dist" directory of the WAR project.  

Now try to deploy the EAR.  This time the deployment fails because the WAR is not expanded in the "gfdeploy" that is created.  

Worse however is that you cannot disable the "directory deployment" and deploy the EAR archive itself because the generated "build-impl.xml" will always use the "nbdeploy" task if "netbeans.home" property is defined.

There is also no means to get in between during the creation of the "gfdeploy" to expand the WAR using ANT either.

Debugging what is going on, I see that in EarProjectProperties.java, only registered additional content that registered as a "project" is considered as a module.

    public static Map<String, J2eeModuleProvider> getModuleMap(EarProject project) {
        Map<String, J2eeModuleProvider> mods = new HashMap<String, J2eeModuleProvider>();
        for (ClassPathSupport.Item item : getJarContentAdditional(project)) {
            Project p;
            if (item.getType() == ClassPathSupport.Item.TYPE_ARTIFACT && !item.isBroken()) {
                AntArtifact aa = item.getArtifact();
                p = aa.getProject();
            } else {
                continue;
            }
            J2eeModuleProvider jmp = p.getLookup().lookup(J2eeModuleProvider.class);
            if (null != jmp) {
                J2eeModule jm = jmp.getJ2eeModule();
                if (null != jm) {
                    String path = getCompletePathInArchive(project, item);
                    mods.put(path, jmp);
                }
            }
        }
        return mods; // project.getAppModule().setModules(mods);
    }

Only these registered modules are considered to be expanded in "gfdeploy".

There needs to either be some way to disable "directory deployment" or detect this condition and automatically disable "directory deployment" or detect the type of additional content and expand accordingly or provide a hook somehow to the "build.xml" to be able to be able to expand the content using a custom target.

I can find no means to work around this at this point.
Comment 1 brett 2017-08-17 03:06:03 UTC
See bug#271216 that I wrote about providing the ability to force archive deployment.  I don't think this should be the final solution as one completely loses the benefits of directory deployment.