Bug 192850

I need the module that nobody external can yet see (e.g. cannot run into this problem).

I will send you the module offline. Could you please investigate this issue.

Re. #1 - list of frameworks was never considered an important FoD entry point. We have prototyped the code (it is in web.fake module), but we never used it in production. It would have been needed only for VisualWeb and VisualWeb was removed from distribution at the time FoD was introduced.

Re. #2 - I know nothing about the content of the combobox, but I expect the problem to be the same as in #1. It is not FoD entry point.

Re. #3 - your runtime dependencies are not wide enough to guarantee your module can run.


I don't think there is much FoD can do by its own. For #3 you have to enlarge your module runtime dependencies so it not only compiles, but also successfully runs. For #1 (and possibly #2) we can resurrect the code in web.fake module. This needs to be driven by owner of the frameworks dialog/infrastructure (I can help with the layer API review and FoD interaction) however. Or you wide your module dependencies even more.

I expect you are seeking for a quick (and dirty) solution, so I suggest you depend on some wide and well tested unit of deployment in your new module. For example on web.kit or javaee.kit.

Jarda, one question please. If I create a Java Web project (in fresh userdir) then all features Petr's issue talks about gets correctly enabled. Why this does not happen in Petr's step #3? Is it because step #2 enabled a subset of these features? But that should not matter no? Java Web project is set of features and that set should be fully enabled before you proceed. Thanks for clarification.

Jarda, could you answer my question please? Thx.

> Re. #1 - list of frameworks was never considered an important FoD entry point.

This is strange, because in fact we have several more web frameworks on the update center, such as GWT, Click or others. I just tried with GWT, and it has the same problem as the internal plugin I originally used. So web frameworks need to be an entry point.

> Re. #3 - your runtime dependencies are not wide enough to guarantee your module can run.

When my module M1 depends on a non-user-visible module M2 (one which has AutoUpdate-Show-In-Client: false), should not the entire kit containing M2 be activated?

I also want to know the answer to David's question.

Please comment.

Re. "subset": As soon as the support for JavaEE projects is enabled (this time due to installing a module from update center), ergonomics no longer care about the project type. 
Re. "framework as entry point" - somebody needs to productize the code in web.fake module
Re. "visible/nonvisible dependencies" - module system by itself does not differentiate between kits and visible, invisible modules. It does what your dependencies suggest.

Did changing dependencies of your module helped? Btw. if you are not satisfied with direct dependency on web.kit, you can use Provides/Needs/Recommends tokens. Basically all your additional modules would need or recommend presents of web.kit.

(In reply to comment #8)
> Re. "subset": As soon as the support for JavaEE projects is enabled (this time
> due to installing a module from update center), ergonomics no longer care about
> the project type.

Thanks. I still do not understand *the cause* of this problem though. There must be an assumption which FoD makes which gets broken in this scenario and that's what's causing this problem. What's that assumption? I mean if you do steps #2 and #3 without ergonomics it passes but with ergonomics it does not. So if it is true what you say above then in step #2 ergonomics enables only subset of what is enabled in non-ergonomics case yet afterwards ergonomics "no longer care about this project type"? Why ergonomics does that? Based on what??

(In reply to comment #9)
> subset of what is enabled in non-ergonomics case yet afterwards ergonomics "no
> longer care about this project type"? Why ergonomics does that? Based on what??

I believe that the module which provides templates for new web project is enabled. Then it takes preceedence over ergonomics own registration of that template.

I did some testing to get better understanding and I think that regardless of ergonomics some dependencies are not expressed and therefore this cannot work properly. Correct me if I'm wrong, but here is what I did and observed. I started full IDE without ergonomics, disabled most of the modules and tried to install Petr's JSF component module. The result was that Web Project and JSF Framework was enabled but none of the other frameworks like Struts or Spring and none of the other component suites like PrimeFaces. And it make sense - Petr's component provider module depends only on web.jsf which in turn depends on web.project and other modules but none of these express dependency on Spring, Struts, PrimeFaces etc.

Yarda earlier said that making Petr's module dependent on "web.kit or javaee.kit" is quick and dirty solution. Is it?? How else it should be done so that it is not a dirty solution? Let's forgot about ergonomics for now just for simplicity's sake. Thanks.

(In reply to comment #11)
> I started full IDE without ergonomics, disabled most of the modules and tried to
> install Petr's JSF component module. 

Perfect, this is exactly how to test dependencies in this case. 

> Yarda earlier said that making Petr's module dependent on "web.kit or
> javaee.kit" is quick and dirty solution. Is it?? 

Well, you have to test if it is solution. Being a one line change I think it classifies for quick. Solving the problem by brute force (e.g. depend on everything) I think it classifies for dirty.

> How else it should be done so
> that it is not a dirty solution? Let's forgot about ergonomics for now just for
> simplicity's sake. Thanks.

My preferred solution is to productize web.fake and make it real entry point. web.fake is almost ready, but there can be other entry points. As such this classifies for elegant, but costly solution.

> Petr's component provider module depends only on web.jsf which in turn depends
> on web.project and other modules but none of these express dependency on
> Spring, Struts, PrimeFaces etc.

One quick think that you could test is to make sure that web.project recommends some token like "org.netbeans.modules.web.project.framework" and each of the framework providers provide that token. Unless I am mistaken, the moduel system will enable all provides of the token that are available when enabling web.project. I am CCing Jesse to confirm (when he gets back in January).

Anything else I can do or can I unassign myself?

Thanks for your help Jarda. Me or Petr will do something with this issue after holidays.

(In reply to comment #12)
> Unless I am mistaken, the module system
> will enable all providers of the token that are available when enabling
> web.project. I am CCing Jesse to confirm

Yes, when there are multiple providers of a token, all that can be enabled without some problem are enabled.

Partially fixed: http://hg.netbeans.org/web-main/rev/dc29b9e9e265
However, the original scenario still does not work completely for me: when I install my JSF component library plugin (which depends on the JSF framework, which in turn depends on "web applications" kit), all the web frameworks are correctly enabled, but the PrimeFaces component suite plugin is not.

I suspect this is due to the behavior of the provides/recommends relationship: it seems that if I am installing plugin A which provides a token, and it depends on plugin B that recommends this token, then if there is plugin C that also provides this token, C will not be enabled. However, if A, B, C are disabled, and I enable B, then the IDE will also enable both A and C. Is that correct? 

If so, then this is slightly counterintuitive.

I consider this mostly fixed, so lowering to P4. However, one other weird thing: looking at the updated generated dependencies report at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/build/generated/deps.txt, I see now that web.kit recommends hibernateweb (as expected), but does not recomment struts, spring.webmvc or jsf.kit, as I would expect. Why is that?

Integrated into 'main-golden', will be available in build *201101130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/205b9f882114
User: pjiricka@netbeans.org
Log: #192850 - tightening dependencies including provides/recommends relationships to make plugin enablement in the web frameworks area more intuitive.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss