Agree, this would be good to implement. We need to find a way how to easily modify pom without worries about losing some configuration parts.
I'll try to do this for the next release.

CCing also Martin

Thanks Martin for CCing. Guys maybe I don't understand fully to the issue ... Haven't we that already implemented?

When you want to include support fully bundled framework (like JSF, Primefaces, Struts, Spring), bundled library contains section "maven-dependencies". In cases of non-bundled (RichFaces and ICEfaces) maven properties are stored at Ant library creation. In any case stored maven deps should extend the project pom.xml by including that library to the project CP (in the wizards or customizers). Or should it do something differently?

But I must agree that the support for Maven libs/dependencies should be improved:
1, in case of RF, IF user must create ant library to make maven support working - this could resolve something like Maven libraries manager
2, users are not able to change pom dependencies stored at Ant Libraries - again some customizer for Maven Libraries or improved Ant Libraries window could probably help here

Martin: Unsure how to interpret your comment..was it an "implementation note", or a note to me as a user of Netbeans? I surely don't want to do anything about Ant when working on Maven projects;)

(In reply to comment #4)
> Martin: Unsure how to interpret your comment..was it an "implementation note",
> or a note to me as a user of Netbeans? I surely don't want to do anything about
> Ant when working on Maven projects;)

Yeah, rather "implementation note" to mjanicek that the base in frameworks works but the maven libraries concept is probably missing some features.

Totally agree with you. I think that my point Nr.1 would include your request. Actually theoretically there could be placed form controls for getting dependencies information in every framework panel, but this solution would be quite non-conceptual. So I think that ideal would be philosophy of Maven and Ant libraries which could be somewhere managed and included to projects (CP or dependencies) by clients, web frameworks.

AFAIK currently no Maven library (dependency) can exists w/out Ant one. Am I right Martin?

(In reply to comment #5)
> AFAIK currently no Maven library (dependency) can exists w/out Ant one. Am I
> right Martin?

I'm not completely sure if I understand what you mean by ant library/dependency, but normally you don't need to do anything with Ant to add a Maven dependency. You just need to change the pom and it will get downloaded from maven repository.

Actually in my comment 1 I didn't know that we are already expanding pom.xml with maven dependencies. Now even I don't know what is missing :)

..I would suggest to let the evaluation to Mondey so we can speak about it personally :)

I also don't understand what's missing. Viggo, can you please provide exact steps to reproduce?

(In reply to comment #7)
> I also don't understand what's missing. Viggo, can you please provide exact
> steps to reproduce?

I think that Viggo request is correct. When you imagine that you are only Maven developer, you don't want to create Ant library to be able to extend the maven project. But it's quite core maven functionality which should get improvements I guess.

Agree with MartinJ, better to speak about that on Monday personally. :)

As Martin says, when I'm working on a project in Netbeans and I'm ONLY using Maven, NOT Ant, then I don't want to fiddle with any Ant-related things. 

I expect that when I have a Maven project with a pom.xml as the heart of the project, then when I add support for a framework like Richfaces, IceFaces, PrimeFaces, Spring MVC, Struts 2 or any other frameworks "supported" by Netbeans (by being in the list of frameworks in Netbeans it IS supported in my definition!), then an entry in pom.xml within the 
<dependencies>
   <groupId>GROUP ID TO FOR INSTANCE PRIMEFACES</groupId>
   <artifactId>ARTIFACT ID TO FOR INSTANCE PRIMEFACES</artifactId>
   <version>VERSION FOR INSTANCE PRIMEFACES</version>
</dependencies>

MUST be added with a dependency to the framework.

(In reply to comment #9)
> As Martin says, when I'm working on a project in Netbeans and I'm ONLY using
> Maven, NOT Ant, then I don't want to fiddle with any Ant-related things. 
> 
> I expect that when I have a Maven project with a pom.xml as the heart of the
> project, then when I add support for a framework like Richfaces, IceFaces,
> PrimeFaces, Spring MVC, Struts 2 or any other frameworks "supported" by
> Netbeans (by being in the list of frameworks in Netbeans it IS supported in my
> definition!), then an entry in pom.xml within the 
> <dependencies>
>    <groupId>GROUP ID TO FOR INSTANCE PRIMEFACES</groupId>
>    <artifactId>ARTIFACT ID TO FOR INSTANCE PRIMEFACES</artifactId>
>    <version>VERSION FOR INSTANCE PRIMEFACES</version>
> </dependencies>
> 
> MUST be added with a dependency to the framework.

viggonavarsete: Actually it already works so in case of JSF, Spring, Struts 1 (Struts 2 isn't supported yet), PrimeFaces.

I'm thinking that I could change validation of non-budled JSF suites (RF, IF) where the setup could be always valid for Maven projects and some (latest) framework dependency would be included into the project. It would be the easiest solution for now.

Based on a private discussion with Martin F, I understand the problem now - for frameworks/libraries which are not bundled with the IDE and where the user is prompted to specify the location (e.g. RichFaces), we don't want to show the "add local jars" UI in Maven projects. 

So, I suggest the implementation could be:
- If we detect that we are in a Maven project (Martin says that this can be done without a dependency on the Maven module itsel), then we display a different UI instead of the "Add Library" button. This UI will prompt for the pom URL.
- Then, we can use org.netbeans.modules.java.api.common.util.CommonProjectUtils.createJavaLibraryImplementation (in module java.api.common) to create a library implementation, plus org.netbeans.spi.project.libraries.LibraryFactory.createLibrary to create a library. This library can then be passed to the project's ClassPathModifier, which for Maven will do the right thing - add the dependency.

Changing to defect targeted to this release for now.

I'm not sure if I agree upon the suggested solution. Currently when I add support for PrimeFaces, Netbeans will know that it has a notion of PrimeFaces 3.4 (for some reason, see attached screenshot!), and the following is put into pom.xml:

        <dependency>
            <groupId>unknown.binary</groupId>
            <artifactId>primefaces-3.4</artifactId>
            <version>SNAPSHOT</version>
        </dependency>

This is ALMOST perfect already. I just want the following changes:
1. Since Netbeans knows about PrimeFaces 3.4 (from where btw?), then it should also be able to insert correct groupId, artifactId and version!
2. This should also be true for the other frameworks!

So what I think need to be done in Netbeans is:
1. Whenever Netbeans team wants to add support for a new framework, or a new version of a framework, then Netbeans team must bundle enough information about the supported framework and store it internally. By "enough information" I mean:
 - Name of Framework (i.e PrimeFaces)
 - GroupId (can easily be googled to find a public Maven repository)
 - ArtifactId (can easily be googled to find a public Maven repository)
 - Version (can easily be googled to find a public Maven repository)
 - Repository (optional, but would be great if Netbeans also added a repository for it if not available in a public repository)
2. Whenever wants to use a new Framework in his/her project then the information  from step 1. must be used to generate enough information in pom.xml

Easy as that :)

Created attachment 127206 [details]
A screenshot where Netbeans "knows" about a specific version of a framework

Ah, NOW I understand. Well, this comment illustrates why it's important to provide EXACT steps to reproduce, including observed vs. expected behavior. Then I of course agree that NetBeans should not add unknown.binary. BTW this sounds like a regression, I believe it used to work correctly.

So I'd say there are two subissues:
- unknown.binary for libraries that are bundled with the IDE
- inadequate UI for libraries which are not bundled

Ok, I would like to try it summarise what I'm suggesting to do:
1, viggonavarsete: If your dependency for Primefaces looks as you attached (I'll try it with clean userdir then), it's definitely a bug which must be fixed.
that's situation and solution for Primefaces

2, ICEfaces and RichFaces will not force you into library creation. The work flow should correspond with the Ant/Maven one. It will stay the same for Ant project. For Maven project - I speak with core maven guy and he told me that it's not common to have there anything like user customizable dependency (we agreed on that also with MartinJ). So I propose in the "Maven UI" (whatever it will mean) just show the dependency which will be used but don't do it user customizable. 

BTW, I'm thinking about totally pruned UI for the Maven cases since it could be a little bit useless. What about to not show "More" buttons in Maven projects at all? It could make whole situation much more clear and easy to use.

yes, I think you can remove the "More"-buttons, I've never understood the reason for having them on a Maven-based project. When you add support for a given ("Netbeans supported") framework then the outcome should be a dependency in pom.xml, no need to have a user interface for anything in my opinion.

(In reply to comment #16)
> BTW, I'm thinking about totally pruned UI for the Maven cases since it could be
> a little bit useless. What about to not show "More" buttons in Maven projects
> at all? It could make whole situation much more clear and easy to use.

Definitely agree! They make no sense at all, would be great to get rid of them :)

Part #1 - Primefaces resolved in web-main #76dd00ec3776.

Integrated into 'main-golden', will be available in build *201211070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/76dd00ec3776
User: Martin Fousek <marfous@netbeans.org>
Log: #220694 - Supported frameworks must also generate correct dependency in pom.xml #1

Part #2 done in web-main #7588f436777a.

These changes look pretty big but there doesn't change anything in the Ant behaviour so it handles just current maven issues differently. I checked everything what crossed my mind to don't bring any regression and I believe that also viggonavarsete will take a look once it will be available in the daily build.

In any case I'm going to fix still about 2 issues in this area and then I will ask JirkaS for detailed testing of this functionality. Jirko, I'll visit you tomorrow to talk about that with you more. Thanks.

I will test this as soon as it's available:)

Integrated into 'main-golden', will be available in build *201211080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/7588f436777a
User: Martin Fousek <marfous@netbeans.org>
Log: #220694 - Supported frameworks must also generate correct dependency in pom.xml #2

I forgot to close this one as fixed since:
web-main #76dd00ec3776
web-main #7588f436777a

I'm happy with the implemented solution! After some discussion we agreed, and you executed quickly! I'm very satisfied with the solution, the discussion and life in general:)