Community
Participate
Working Groups
Build Identifier: helios for java ee Build Identifier: helios for java ee developers i have a static web project, test-html, with a html file. and a js project, test-js, in the include path of the web project. i expected that test-js could end up in the deployed test-web's web content layout. Setting this in "Deployment Assembly" by mapping test-js project to something like "/javascript" does nothing. This setting even dissapears after setting it in test-html's preferences. Should this be normal behaviour of "Deployment Assembly"? Is it possible to export a references js project into a web project's web layout on a http server when deploying the latter? What are the steps to follow? Reproducible: Always
Assigning to Chuck for initial investigation.
From what I can see, you'd need to add a CONSUMED-type project reference, for which there is no UI for at the moment. You can hand-modify the component xml file though... but again that could be risky and is not actually advised unless you know what you're doing. Long story short, it's possible, but there is not, and never has been, a UI to do what you're asking. =] Hope that helps.
1. That means that i cannot spred my js files in js projects. All js files must be in WebContent of my static web project (if i want them to be deployed). Is that correct? Then the notion of javascript include path serves just for compiling purpuses, not for packaging. But in many cases it is necessary that an include path end up in the static web projects' deployed layout, because yo'd need those files of the include path at runtime too. 2. Then what is "Deployment Assembly" for in a js project? 3. Is this functionality of point 1 targeted for some future version? 4. You're speaking about a hack to do this. Can you provide a working example? Thank you very much.
Rob, is this a scenario we should look into supporting?
Carl: I'm not sure on the exact purpose of the static web project. From my vague understanding of it, I would imagine that it is 'static', that it's structure is not customizable, and if anything, we should not allow a module assembly page for it. But this is of course due to me not truly knowing the usecase of the static web project or what it was designed for. What do you guys think? Is static web project meant to be static and not customizable? Or is it meant to be dynamic and able to be customized as well?
I've just verified that the Javascript project is not a module core project. We could conceivably add the ability to create a reference type which is simply any workspace folder, but up to now we haven't done that because of concerns by adopters that this would make loops too hard to find. There's really no way to accomplish this without adding a new reference type to map to any folder (which may upset adopters)
retargeting old bugs to the future
Pushing to maintenance, but since javascript projects are NOT modulecore projects, I feel adding that now would make a huge incompatibility between old and new such projects. I think the best fix might be to ensure that javascript projects do not have a Deployment Assembly page showing.
Rob, I just created a Static Web project using WTP 3.3 RC 3. To clarify, it is a modulecore project. It has the following in its .project file: <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature> It has a properly formatted .settings/org.eclipse.wst.common.component file, and it has two facets defined: wst.web 1.0 wst.jsdt.web 1.0 Is the underlying problem here the fact that folders cannot be mapped into any project using the Deployment Assembly page? I believe that there is a separate bug open for that.
Carl: Static web projects *ARE* modulecore projects. Javascript projects *ARE NOT* modulecore projects. Adding a reference to a javascript project does not convert it to a utility project, for some reason, so it remains not a module-core project. The reference remains in the static web project's component.xml file, but the following call to get the references returns a 0-length array: Map<String, Object> options = new HashMap<String, Object>(); options.put(IVirtualComponent.REQUESTED_REFERENCE_TYPE, IVirtualComponent.FLATTENABLE_REFERENCES); IVirtualReference[] refComponents = vc.getReferences(options); The reason is that the DefaultReferenceResolver resolves a URI similar to "module:/resource/test-js/test-js", and executes the following: targetComponent = ComponentCore.createComponent(targetProject); The targetComponent is then null, and so, when VirtualComponent.getReferences(options) executes, it checks if the target component is null and if it exists. Since the target component is null, this reference is ignored. Since there is no "component" that the javascript project can be made into, the reference is 100% ignored.
To add further details, when using the property page of a Dynamic Web Project, when adding a reference to a javascript project, the javascript project is CONVERTED into a utility project. Same for any plain old java project... gets converted. When using the property page of the Static Web Project, this is not the case. The static web project uses the default module dependency property page, The default module dependency property page uses the standard add-reference page, with the standard list of add-reference sub particles. Dynnamic Web replaces newProjectReference with CustomWebProjectReferenceWizardFragment, and thus, when adding a reference to a POJP, converts it to a utility project. Static Web Project does not do this. A possible fix is to make the static web project's UI match the dynamic web project's, and the method to do that would be to modify WebModuleDependencyPageProvider.canHandle(project) to also check for the static web facet.
Here's what this all comes down to for me: Static Web projects don't require Java, and don't really handle Java well at all. They are really for serving static content: HTML, JS, and other simple things like that. Likewise, JavaScript projects don't handle Java. I believe that we want to make projects referenced in the Deployment Assembly page into modulecore projects. I don't believe that we want to make projects referenced by a Static Web project into Java projects- if they were already Java projects, that's one thing. Converting any project referenced by a Dynamic Web project into a Java Utility Project makes sense- Dynamic Web projects understand and deal with Java. Converting any project referenced by a Static Web project into a Java Utility project doesn't make sense, since Static Web doesn't understand and doesn't deal with Java. (Note: Yes, I know about applets and how you can put class files or a jar into a Static Web project... but the Static Web project itself has no understanding of a classpath or anything else Java-wise... it is not a Java project.) So I would say that simply reusing CustomWebProjectReferenceWizardFragment for a Static Web project would not be a good idea. However, reusing (and possibly refactoring) parts of it for converting referenced projects to modulecore projects would be a great idea.
No longer suitable for anything in 3.3
Moving to 3.4.1
Moving to future - please re-target as appropriate
