Quy, please evaluate whether jsfloader can handle this structure. If not, we may need to disable the creating.

BTW, could you please attach a simple maven project to this issue for us to use? Thanks!

Created attachment 47034 [details]
sample maven web project.

There appears to be a number of problems adding a visual web page to a maven project.  None of them seem directly
related to the jsf loaders.

When the vw framework is added to the project, the project infrastructure creates the web/Page1.jsp file, causing the
exception in the issue description.  However, the Add Page wizard does the correct thing and creates the jsp file in
src/main/webapp.  After the framework is added to the project subsequent pages only appear in src/main/webapp.

The required libraries are also not added to the project, so our source modeller fails to make the necessary
modifications to the page bean template (most notably the package name).

The attached project looks like not a valid NetBeans project! How can I use NetBeans to open it and add a visualweb
page? Please attach a NetBeans project, thanks!

you need to install the maven support from dev/M10 update center. It's currently missing from dev AU I think (a bug),
you can get the daily nbm binaries from http://deadlock.netbeans.org/hudson/job/mevenide/

I have fixed the hard-code "${basedir}/web" issue. After that, I found that the Meven project do not support Auxiliary
Configuration that Visual Web used for saving project properties! Therefore I have fixed the New File wizard to reject
for creating new Visual Web item.

Now you will see "Visual Web items cannot be created because the target project does not support Auxiliary Configuration
for saving project properties." in the New File wizard and the Finish button is disabled.

In order to make the Visual Web items available for Meven project, the following 2 tasks need to be done:
- Meven should support Auxiliary Configuration that standard Web Project supports
- Meven should support Libraries based on ProjectClassPathModifier.addLibraries calls

If possible, please file bug against the Meven project owner and CC me. Thanks!

the maven support can partially support the addLibrary() call, however please note that in maven you cannot add an
arbitrary jar to the project. You need to translate the jar to a "dependency" which is uniquely identified by
GroupId+ArtifactId+Version. These "dependencies" ought to be found in a remote maven repository in order to make the
maven build reproducible. The maven support knows a bunch of basic "libraries" in netbeans by it's MD5. Please check
#113607 that I'm about to integrate that allows you to specify "maven-pom" volume type for your library that points to
URL fo the Maven POM (Project Object Model) file, that contains the information about the unique identification of the
library to be added. What are the jars that you are adding to the project? what versions?

Regarding AuxiliaryConfiguration: maven integration doesn't support arbitrary shared auxiliary config. non-shared is ok.
What are you adding to the Auxiliary config? I might be able to retrieve that information from the Maven POM and give
you the data in the format you expect (same applies to writing auxiliary config)

Visual Web stores the following Auxiliary configuration in project.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://www.netbeans.org/ns/project/1">
    <type>org.netbeans.modules.web.project</type>
    <configuration>
        <creator-data xmlns="http://www.sun.com/creator/ns" jsf.current.theme="woodstock-theme-default"
jsf.pagebean.package="webapplication1" jsf.project.libraries.dir="lib" jsf.project.version="4.0" jsf.startPage="Page1.jsp"/>

It uses the following call to set the libraries:
  ProjectClassPathModifier.addLibraries(Library[], SourceRootFolder, ClassPath.COMPILE);
and
  WebProjectLibrariesModifier wplm = (WebProjectLibrariesModifier)
project.getLookup().lookup(WebProjectLibrariesModifier.class);
  wplm.addCompileLibraries(Library[]);
  wplm.addPackageLibraries(Library[], PATH_IN_WAR_LIB);

I think these calls are all standard NetBeans APIs.

re aux config: I see. I could probably set most of these props as part of the pom.xml and read them later. Only the
"jsf.project.libraries.dir" property is a problem. What purpose does the directory serve?
Maven cannot handle arbitrary libraries in the source code structures. Everything needs to be placed in local/remote
repositories.

re: libraries.. ProjectClassPathModifier.addLibraries() call is fine as long as I can identify the jars. What
libraries/jars are you adding? 

first time I hear about .addPackageLibraries and .addCompileLibraries methods, need to check what they do. But the
principle shall be the same.

I'm reopening this issue for future Visual Web support for Meven project.

> The ideal and standard solution for this kind of integration would be to define an Interface let's say
> VisualWebModuleImplementation that each project type could place into the project's lookup. The visual web integration
> would then query the project for this interface whenever needed by the UI.
> it could look like this:
>
> interface VisualWebModuleImplementation {
>     String getCurrentJSFScheme();
>     String getJSFBeanPackage();
>     String getJSFProjectVersion();
>     String getJSFStartPage();
> }
>
> Also possibly with the relevant setter methods.
>
> Maven support is free to implement this interface without the need to add AuxiliaryConfiguration to the project.

Visual Web may introduce this interface for post-NetBeans 6.0. I'm just wondering the modules dependency issue. None of
non-visualweb module is currently dependent on visualweb/project/jsf module. Should we need to define this interface
outside of visualweb module so that NetBeans modules can use it?!

> As I already mentioned in issue 113284, the only item where I see more work coming is the jsf.project.libraries.dir
> property. It makes no sense for maven-based projects, which store all relevant dependency information in the pom.xml
> file and the binaries are stored in the local and remote repositories. An arbitrary folder with some binaries is
> non-supported feat in Maven.

As I checked, jsf.project.libraries.dir was only used for Creator 2. Starting from Visual Web Pack for NetBeans 5.5,
this variable is no longer used. It's currently there for backwards compatible. It can be removed for post-NetBeans 6.0.

> BTW are there any special ant steps when building an applicationw ith visual web in it?

Since Visual Web is part of web project, a framework, it does not do any special request for building the application.

BTW, it's still not clear to me the Meven project libraries support. ProjectClassPathModifier.addLibraries looks like
does not add the libraries into the project after the API calls. And Visual Web does also need the other adding
libraries supports, WebProjectLibrariesModifier.addCompileLibraries and .addPackageLibraries methods.

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

potingwu: 
The algorithm for adding libraries to maven projects is following now:
1. check for "maven-pom" volume in the library (which was added lately with issue #113607)
2. if found, use it to populate the pom. If not, proceed.
3. calculate MD5 checksum of the library "classpath" volume jars and try to match against the local maven repository
index. If any matches are found, use them.
4. anything that was not found is basically ignored because I cannot figure out  the proper GroupId+ArtifactId+Version
identifier to put in the pom file.

This is how the maven-pom volume looks like in library definition.
http://deadlock.netbeans.org/fisheye/browse/~raw,r=1.7/netbeans/web/struts/src/org/netbeans/modules/web/struts/resources/struts.xml
It assumes the jar and it's maven pom can be found in some public maven repository.
Having the jars out there is very important for build reproducibility. I wasn't able to find the visual web library jars
at the mvnrepository.com site (which indexes the central repository) or at the java.net's repository
(http://download.java.net/maven/1/)

more user feedback.
http://www.jroller.com/heffel/entry/eclipse_veteran_tries_netbeans_6

I also got some additional feedback personally via email.
Please consider for 6.1.

I have added support in maven to experimental support webframeworks.  On project creation it will currently let you
select a server+j2eelevel along with webframeworks configuration on project creation.
All woodstock libraries are copied to the project and end up on classpath, I have created a mockup
AuxiliaryConfiguration snippet to return the visual web xml element (non-editable now). Unfortunately the visual pages
still show error when created. It can be caused by missing application server jars on classpath (which I don't add on
purpose). But even after adding those jars as dependencies, I get some sort of errors I can't resolve (I have no web
development background). 
1. The visual design page shows errors, while the project is compilable. So something else in play as well.
2. Adding new jsf page isn't allowed until I install a backward compatibility kit. the project is set to j2ee 1.5, but
the visual wizard says it's 1.4. I've workarounded it by installing the backward comp module and copy pasting the
<web-module> header in WEB-INF from elsewhere as the one generated by maven by default is 2.3 version I believe. That
could be the source of problem here.
3. After that I can create a visual jsf page, but get compile errors because unlike the first page which had
com.sun.rave.web.ui.component imports, this one has com.sun.webui.jsf.component imports. No idea why.


That's about where I can get on my own. Someone with j2ee+jsf experience needs to look into this.

Created attachment 53101 [details]
experimental module adding webframeworks

attached is an experimental module that adds webframework support. It works with 3.0.9 version of maven support (soon to
be available on RC2 update center, or here http://deadlock.netbeans.org/hudson/job/mevenide-fcs/)
To add webframeworks, create a new maven project, choose the webapp archetype and on the last panel add the server and
webframework of choice. 

The webframeworks is almost a complete work-around/fix for this bug, except if you move the project to a different
directory or to a different machine, the "Visual JSF Web Pages" (example: Page1.jsp) goes back to being a regular jsp
file (NetBeans NO-longer thinks that it is a "Visual JSF Web Page" (The "Design", "JSP", "Java" buttons are gone)). 
Funny thing is, if I move the project (pom.xml and all subdirectories) BACK to where I originally create the project,
then NetBeans remembers that Page1.jsp IS a "Visual JSF Web Page" (The "Design", "JSP", "Java" buttons come back and I
can visually edit the file again).

What triggers Netbeans to think that the JSP page is a visual one or not?

I found a work around (quite ugly but ...).
http://www.netbeans.org/servlets/ReadMsg?listName=nbusers&msgNo=101594

Just a note when fixing this:

I have also noticed an issue if you try to do a Maven Visual Portlet webapp.  I was able to get everything working using
the webframeworks module (cool, thanks!), but as soon as I added a portlet.xml file to my WEB-INF directory, Netbeans
partially freezes and and the Netbeans UI starts to go crazy.  I have identified the problem.  The issue is that
org.netbeans.modules.visualweb.project.jsf.api.JsfPortletSupportImpl:getPortletDD() tries to get a FileObject of the
portlet.xml file but tries to get it from the wrong directory (/myproject/web/WEB-INF/portlet.xml as defined in
org.netbeans.modules.visualweb.project.jsf.api.JsfProjectConstants) instead of the correct Maven directory
(/myproject/src/main/webapp/WEB-INF/portlet.xml).  

To get around this, I just created a dummy portlet.xml file in the /myproject/web/WEB-INF directory (ugly, but gets
things to work again).  This allowed me to do a Maven Visual portlet application and deploy it successfully.

I have added a few related items to the maven support.
1. Now AuxiliaryConfiguration now works for maven projects.
2. The frameworks panel was added to maven projects allowing to add and configure frameworks from project customizer.
3. at the same time I removed the frameworks panel from project creation as it makes little UI sense and is buggy.

However I still can't make the integration work with jsf+visualweb. struts and spring are fine. The biggest obstracle
seems to be the hard requirement on having "serverInstanceID" passed to the webframeworks. I noticed visual web uses the
server instance for project classpath calculation. However that is not correct in case of maven projects which use the
server only for deployment and not for compilation classpath. Ideally the server shall not be necessary to be defined
until the user starts the deployment.

I noticed that your assumption about serverInstanceID==classpath will get possibly broken by the Sharable Libraries
effort in ant projects as well. If the user decides to create a sharable library for server classpath and then edits it
(and remove/change the library jars), examination of server classpath will not by in synch with the real project classpath.

So ideally you should stop relying on serverInstanceId exclusively and only fallback to it in some cases (like when the
project is not yet created - in the project wizard)

the org.netbeans.modules.visualweb.project.jsf.api.JsfPortletSupportImpl:getPortletDD() methods should lookup the
portlet file based on the web related APIs (WebModuleProvider or someting like that??) and not rely on hardcoded paths.

"serverInstanceId" here is used for the 'Libraries' tab in the New Web Project Wizard's Frameworks step. It is hidden in
visualweb framework and hence is actually not used. The codes were 'inherited' from the JSF framework that its
'Libraries' tab is visible. It detects the target server's JSF support, and then supply the local JSF libraries if needed.

Visualweb does use the project classpath for detecting every library as you described. As I understood from the codes,
even passing serverInstanceId=NULL to visualweb, it won't affect it. And it will work as expected.

I correct myself. ServerInstanceId is not required for visual web, not jsf. I've removed it from my code and Both could
be added as  webframeworks.

During project creating when 'project classpath' is still not available, the JSF framework does use the server ID to
check the server classpath whether the server has the JSF support or not. And based on the information got to adjust the
contents inside the 'Libraries' tab. Actually visualweb somehow uses the same mechanism to check the server JAXRPC
support and decide whether to ask user getting the plugin or not.

As I guess, if the framework manager passing null for serverInstanceID, the result is the server does not support those
func like JSF or JAXRPC. Then it will try to find the local RI jars for project inclusion. That may still work for most
cases.

Since all the recent maven+visualweb problems are discussed in issue#129103, I will mark this one as duplicate of it.
The info in this issue is somehow out-of-date under the current implementation/status.


*** This issue has been marked as a duplicate of 129103 ***