Bug 192850 - Web frameworks broken by an autoupdate plugin that provides a JSF component library
Web frameworks broken by an autoupdate plugin that provides a JSF component l...
Status: NEW
Product: javaee
Classification: Unclassified
Component: Code
7.0
PC Mac OS X
: P4 (vote)
: TBD
Assigned To: issues@javaee
issues@javaee
: ERGONOMICS
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-03 14:29 UTC by Petr Jiricka
Modified: 2011-01-13 07:46 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2010-12-03 14:29:11 UTC
1. Use the all-in-one NetBeans build from Dec 3 or later, start with a fresh userdir
2. Install a plugin that provides a JSF component library (this is a plugin that is not published externally, but I have it locally). This will enable the web development features.
3. Create a new Java Web project,  progress to the frameworks panel.
Problem #1: Only JSF framework is visible, no nother frameworks (Spring, Struts, Hibernate)
4. Select JSF framework and switch to the Components tab
Problem #2: Only the component set provided by the Autoupdate module is present in the combo box, but not PrimeFaces (which is bundled with NB by default)
5. Finish the wizard and let the scanning finish
Problem #3: Code completion for JSF tags in index.xhtml does not work

All the problems disappear when I delete the ergonomics cluster and do the whole scenario from scratch.
Comment 1 Jaroslav Tulach 2010-12-06 09:34:32 UTC
I need the module that nobody external can yet see (e.g. cannot run into this problem).
Comment 2 David Konecny 2010-12-06 19:39:53 UTC
I will send you the module offline. Could you please investigate this issue.
Comment 3 Jaroslav Tulach 2010-12-07 12:49:08 UTC
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.
Comment 4 David Konecny 2010-12-07 21:47:15 UTC
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.
Comment 5 David Konecny 2010-12-12 19:11:37 UTC
Jarda, could you answer my question please? Thx.
Comment 6 Petr Jiricka 2010-12-14 14:42:14 UTC
> 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.
Comment 7 David Konecny 2010-12-16 21:08:25 UTC
Please comment.
Comment 8 Jaroslav Tulach 2010-12-17 09:44:03 UTC
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.
Comment 9 David Konecny 2010-12-19 19:02:48 UTC
(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??
Comment 10 Jaroslav Tulach 2010-12-20 14:17:27 UTC
(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.
Comment 11 David Konecny 2010-12-20 23:22:13 UTC
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.
Comment 12 Jaroslav Tulach 2010-12-21 07:55:13 UTC
(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).
Comment 13 Jaroslav Tulach 2010-12-22 14:25:33 UTC
Anything else I can do or can I unassign myself?
Comment 14 David Konecny 2010-12-22 20:38:38 UTC
Thanks for your help Jarda. Me or Petr will do something with this issue after holidays.
Comment 15 Jesse Glick 2011-01-07 21:56:47 UTC
(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.
Comment 16 Petr Jiricka 2011-01-11 15:23:41 UTC
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.
Comment 17 Petr Jiricka 2011-01-12 13:28:21 UTC
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?
Comment 18 Quality Engineering 2011-01-13 07:46:39 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo