Bug 154046 - project compiles but shows "compilation" badges
project compiles but shows "compilation" badges
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Web Project
6.x
All All
: P2 (vote)
: 6.x
Assigned To: David Konecny
issues@javaee
:
Depends on: 105645 108470
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-27 20:25 UTC by Lukas Hasik
Modified: 2009-02-19 23:27 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
wsdl file for testing (3.63 KB, text/xml)
2008-12-11 09:19 UTC, Milan Kuchtiak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Hasik 2008-11-27 20:25:00 UTC
Product Version: NetBeans IDE Dev (Build 081118)
Java: 1.5.0_14; Java HotSpot(TM) Client VM 1.5.0_14-b03
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

-fresh userdir
-create New Project > Samples > Web Services > Stock Service
--you might need to add server
-build project - it builds
->but there is still "error" badge on org.netbeans.identity.samples.StockService
Comment 1 Milan Kuchtiak 2008-11-28 08:44:22 UTC
This is known issue.
Depends also on enhancement 105645. 
Comment 2 Milan Kuchtiak 2008-12-10 16:24:27 UTC
The issue is pretty serious and it's caused by incorrect implementation of ClassPathProvider in WEB / EJB project.
The build/generated/wsimport/service root is not involved to project's classpath.

Specifically, findClassPath method uses the generic - javaClassPathProvider object to compute classpath :
====
    public ClassPath findClassPath(FileObject file, String type) {
        ClassPath cp = javaClassPathProvider.findClassPath(file, type);
        if (cp != null) {
            return cp;
        }
        FileType fileType = getType(file);
        if (type.equals(ClassPath.COMPILE)) {
            cp = getCompileTimeClasspath(fileType);
        } else if (type.equals(ClassPath.EXECUTE)) {
            cp = getRunTimeClasspath(fileType);
        } else if (type.equals(ClassPath.SOURCE)) {
            cp = getSourcepath(fileType);
        } else if (type.equals("classpath/packaged")) { // NOI18N
            cp = getPackagedClasspath(fileType);
        }
        return cp;
    }
====
Unfortunately, that generic javaClassPathProvider object doesn't include build/generated/wsimport/service root. 

I fixed this temporarily in ClassPathSupportFactory class:
http://hg.netbeans.org/main?cmd=changeset;node=208f6a1698ee

In the feature, after issue 105645 is implemented (generic folder for all generated source root) all hard coded source
roots from SourcePathImplementation class should be removed.
Comment 3 David Konecny 2008-12-11 07:07:27 UTC
Please revert 208f6a1698ee. It impacts all existing project types using it. I remember J2SE project having using test
which your hotfix broke. If you need to hotfix this then change Ejb and/or Web project. Btw. Web project already calls
createSourcePathImplementation with canHaveWebServices=true. And for Ejb you may need to extend ClassPathProviderImpl
constructor to take canHaveWebServices as well.
Comment 4 Milan Kuchtiak 2008-12-11 09:17:09 UTC
The hot fix was reverted: http://hg.netbeans.org/main?cmd=changeset;node=bc3c50146339

Now it's on web and ejb project to fix the issue:
build/generated/wsimport/service folder is not on project's source classpath

To test this issue: create WS from WSDL (Web Services wizard category) from attached wsdl file.
You'll see that 
org.example.duke.AddNumbersFault_Exception is badged with errors
Comment 5 Milan Kuchtiak 2008-12-11 09:19:43 UTC
Created attachment 74838 [details]
wsdl file for testing
Comment 6 Trey Spiva 2008-12-11 15:53:26 UTC
According to the issue 105645 the required enhancement should be in NB 7.  So my question is why put temporary fix in until the new API is completed?
Comment 7 Milan Kuchtiak 2008-12-11 16:31:28 UTC
The answer:
I was trying to fix the regression caused by David Konecny with his refactoring (new implementation) of classpath
provider in Web and Ejb. The code completion for web services should work regardless issue 105645 is implemented or not.

The dependency on 105645 means that when this is implemented we can remove all hard coded source roots from
SourcePathImplementation.
Comment 8 Quality Engineering 2008-12-11 16:57:26 UTC
Integrated into 'main-golden', will be available in build *200812111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/208f6a1698ee
User: mkuchtiak@netbeans.org
Log: #154046: since Web/EJB project's classpath is derived from generic (J2SE) project classpath, canHeveWebServices param must be se to true
Comment 9 David Konecny 2008-12-11 20:27:04 UTC
Fixed locally as 22947ec15993 by adding canHaveWebServices parameter to java.api.common.ClassPathProviderImpl.
Comment 10 Quality Engineering 2008-12-12 17:26:38 UTC
Integrated into 'main-golden', will be available in build *200812121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bc3c50146339
User: mkuchtiak@netbeans.org
Log: #154046: reverting hot fix
Comment 11 Milan Kuchtiak 2009-02-04 17:00:41 UTC
The generated sources are now handled as normal sources.
See the issue 105645.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo