it's the jsf framework codebase that needs to use different api to add jsf jars/libraries to a project. reassigning. the
maven part is reasonably trivial, see ContainerCPModifierImpl,  and feel free to change that once you implement the
logic of when to add on classpath only ad when add to war file as well.
 

my reply from 174899:

re : "As for packaging - the correct approach would be to add this library to the compilation classpath, but not to
package it in the war file. Can this be done using the ClassPathExtender/Modifier APIs?"

there is no such way in the CpExtender/Modifier API as far as I know. There's one way that always adds the "provided"
scope dependencies (thus adds on classpath and not in war).
See org.netbeans.modules.j2ee.core.api.support.classpath.ContainerClassPathModifier, using that one however requires
changes on both sides of the contracts - see org.netbeans.modules.maven.j2ee.ContainerCPModifierImpl

However i'm not sure that the "provided" scope is always desired. As I understood the problem it only affects j2ee 6 +
gf 3, right?
If you add provided scoped dep to the project and run on different app server you will get classnotfounds at runtime.

re. "there is no such way in the CpExtender/Modifier API as far as I know" - true, that's why web project introduces its
own API: org.netbeans.modules.web.project.api.WebProjectLibrariesModifier. Just mentioning it for record.

Probably just adding JSF API (regardless of EE version) should be safe. In cases where JSF impl is missing on server
user can add it themselves to project classpath.

David what about JSF version, do you mean both 1.2 and 2.0? And do we need then to make JSF implementation available in
Library Manager as separate library?

re. "David [...] do you mean both 1.2 and 2.0?" - for JSF 1.2 (or any existing pre-EE technology my general approach is
to leave everything as it was in NB 6.7 unless users were complaining about it. But I think the same approach we are
implementing for JSF 2.0 is applicable for JSF 1.2 as well.

re. "And do we need then to make JSF implementation available in Library Manager as separate library?" - let me think
out loud for a minute about current state: in Ant based projects JSF framework has 3 options in Libraries panel - (1)
use JSF on server (preferred option); (2) use registered library or (3) create a new library (these two options are for
users who knows that their server either do not have any JSF - eg. Tomcat - or users who have to use different JSF
version then available on server). Case (1) requires JSF API only; cases (2) and (3) requires both API and
implementation. So far so good. Now, for Maven there are only options (2) and (3) because server is optional in Maven
context. I'm guessing that Maven integration in NetBeans works like this: when option (2) is selected whatever is
specified in libraries maven-pom volume is added to Maven's pom.xml. In that case I think that current NetBeans JSF
libraries (JSF 1.2 and JSF 2) should keep JSF API and JSF IMPL in classpath volume but should have only JSF API in
maven-pom volume. That would mean that users of Maven project can compile their sources and deploy them to server which
most likely has JSF impl. And if server does not have JSF impl then user has to edit their pom.xml and add the JSF IMPL
jar to runtime classpath by hand. Does it make sense what I'm saying?

David, I've checked removing maven-pom value for JSF impl jar from library and it seems that it works, like you suggested.

Milos, do you have any objections for removing maven-pom value for JSF impl jar? Wouldn't it happen that we will get
issue http://www.netbeans.org/issues/show_bug.cgi?id=170990 back?

Cc'ing also Marek - JSF impl is needed on the classpath because of the facelets editor, so check with Marek before
making this change. We may not be able to do this because of dependency on Marek. Anyway, I don't feel strongly that
this is actually a defect, if it turns out to be hard to do or labor intensive, feel free to change to ENHANCEMENT.

alexey: well observed. If you have the jsf-impl jar in library classpath, but missing in maven-pom volume, you can
eventually get the 170990 issue back. Not exactly the hanging problem (which was AFAIK fixed by another issues), but you
will still get the maven support to attempt to find the jsf-impl jar (as it's in library classpath, but missing the
pom-volume) in the repository index. Due to implementation details though, if there is still something defined in the
maven-pom volume, it will be used. If maven-pom is missing, the other steps will be done..

Guys, please file an issue to web/jsf.editor if you are about the remove the jsf-impl.jar from the compile classpath. I
do need to modify the code so the jsf-impl.jar is taken from the web.jsf20 library instead of from the server classpath.

I agree with Petr that it is not worth to fix too much work (P4 or enhancement).

Marek, do you use jsf-impl.jar in order to provide some editor features? Even if this issue will not get resolved it
would be safer to use required impl JAR from IDE installation rather then from project classpath.

I have excluded the jsf-impl and jsf-api jars from the facelets libraries scanner classpath in web-main#78ae1c52636d.
Since the classloader's parent is the module one and the module depends on jsf20 library, the jars exposed from
web.jsf20 library should be used now.

changed to enhancement

Need to change this back to (possibly waivable) P2 DEFECT because of bug 182282. Basically, JSF implementation bundled in WEB-INF/lib will not work on WebLogic; WebLogic's own implementation needs to be used instead, see this comment: http://netbeans.org/bugzilla/show_bug.cgi?id=182282#c12

This also means that JSF support in Maven is somewhat server-dependent, and we may need to encourage the user to set the server before adding JSF framework (so the IDE knows whether to add it on the packaging classpath, or just use provided scope). This is already the case for JPA, see also bug 178970.

Changing the subject to capture the real issue and requestiong a waiver for NetBeans 6.9. The workaround is to modify the pom file to provide the correct packaging so it works on WebLogic.

6.9 waiver approved.

So conclusion: Need to decide either include or not JSF implementation jar, and for what cases?
(1) use JSF on server -- it is OK
(2) use registered library -- here the main issue. According to the previous comments only JSF API can be left here. But Maven? What if we will add the note about Application Server like it is done in persistence?
(3) is up to the user

Did I miss something?

I don't quite understand the question, but I'd say we need to look at the problems in this order:
- It is becoming clear that the JSF configuration panel needs to be aware of the server, and must behave based on the currently selected server. See bug 188284.
- When the server is known, we need to select the right default, so things work out of the box.
- Then the next question is what will happen when the user changes the default. I am hesitating whether the IDE should do something to prevent the user from shooting himself in the foot, or whether it should just give her the freedom to screw up. Opinions?

(In reply to comment #16)
> I don't quite understand the question, but I'd say we need to look at the
> problems in this order:
> - It is becoming clear that the JSF configuration panel needs to be aware of
> the server, and must behave based on the currently selected server. See bug
> 188284.

I mean that issue when written about providing note about Application Server. 

> - When the server is known, we need to select the right default, so things work
> out of the box.
> - Then the next question is what will happen when the user changes the default.
> I am hesitating whether the IDE should do something to prevent the user from
> shooting himself in the foot, or whether it should just give her the freedom to
> screw up. Opinions?

What about option like it is done for missing server or library? When the project is highlighted with an warning triangle, and resolve <some> problem... item appeared in popup menu for the project. It can be done when the JSF RI is not present in the classpath, this would work for Tomcat case, and for Maven Web App case.

> What about option like it is done for missing server or library? When the
> project is highlighted with an warning triangle, and resolve <some> problem...

Yes, this could work.

Currently a big part of bug 182282 is implemented, i.e. for Ant projects, the user can choose which server library to use when using JSF on WebLogic. The same choice should be available also for Maven projects when WebLogic is set as the target server. Do we know how specifically to solve this?

Integrated into 'main-golden', will be available in build *201007160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c03db73b2b0d
User: Alexey Butenko <alexeybutenko@netbeans.org>
Log: #175130: Bundling the JSF implementation in WAR archive for Maven projects does not work on WebLogic
#188284: The IDE should warn the user when adding JSF and no target server is set

Finally I've merged JSF libs back to add API with IMPL when choosing Registered libs option as we discussed in email.
http://hg.netbeans.org/web-main/rev/17767f52f748

So it seems that we can consider the issue as fixed.
There are some cases left such as javaee-web-api and jsf-api on EE6 Maven project, but IMO it should be filled separately.

Added check box: package this library to WAR for maven+no server case
http://hg.netbeans.org/web-main/rev/98fcd7ce6c85

Integrated into 'main-golden', will be available in build *201007170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/17767f52f748
User: Alexey Butenko <alexeybutenko@netbeans.org>
Log: #175130: splitting JSF libs back.