Let's ignore Beans for this release we have more important things to do I guess. 

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

It would be a pretty sad state of affairs to ignore beans with all the new
functionality in the Form Editor.  This needs higher priority, and it needs to
be marked as a DEFECT not a FEATURE as it is an integral part of Java
development as JavaBeans are required every where including EL in JSP, Bean
Binding, NetBeans Module Development (even TCs are JavaBeans).

This is little too general statement. Could you please specify which features of
the old Beans module you want to see be brought back? Obviously saying that all
is not the right answer :-). Thanks

Well, from a JavaBeans perspective the "Bean Patterns" Node needed to be
enhanced and expanded not removed.  All the BeanInfo editor is needed.  The
other features of being able to add properties need to be available as well. 
The nice thing about all those features is they aid the developer in JavaBean
development.

One of two things can happen here.  The features can remain visible as now and
be enhanced a little bit more in the future or the "Bean Patterns" Node can have
a sub-node for the BeanInfo Editor there, and the BIE not be shown in a separate
dialog.  All the functionality in the beans module at least which is accessible
from the sub-node in the explorer view is extremely useful.

So either we see what we see in NB 5.5 or we see:
SomeClass.java
-Bean Patterns (with a nice Java Bean icon ... context menu "Add BeanInfo" and
"Remove BeanInfo" if BeanInfo is available ... needs undo or can rely on local
history)
--someProperty (these are available as they help with beans with no BeanInfo)
--someOtherProperty
--Bean Info (if a BeanInfo is added to the bean this becomes enabled ... this
contains the information from the dialog Bean and BeanInfo nodes, is there any
real use for multiple BeanInfos returned by the getAdditionBeanInfo method?)
---Properties
---Event Sources
---Methods

Then we can add methods, properties, and event sources from this area.  So, not
only can we edit the BeanInfo information, but we can also add the entities
(methods, properties, event sources) here so we can manage them right away. 
This will make the BeanInfo editor that much more useful.  The sub-classes will
still need their sub-nodes visible under the .java files, and then the "Bean
Patterns" node will need to be available for them.  

I don't like it, but I would even settle for a NavigatorPanel being registered
for .java files.  The only issue here is without the Java API allowing us to tie
into the Navigator panel with some type of an SPI or API to allow adding a Node
in the Members hierarchy in the Members panel for each class we will need to
examine the class file for all sub-classes and display the full hierarchy in the
BeanInfo NavigatorPanel.  Which seems to move the UI consistency issues to a
different level.  I think having the nodes available in the explorer view is
better for now until something can be worked out with the Java project or
something else can be figured out.

So, that all being wrote, is there a resource need here?  Do you want some help
designing and building this?  Can you move design discussions to the community
wiki?  The given URL seems to be some VPN access only URL as I can not access
it.  This is a must have for NB 6.0 as Beans are used every where, and this
pushes the ease of use out the door in favor of the developer doing all the
BeanInfo work by hand.

I think the other features such as Customizers and Editors should be able to be
started from the BeanInfo editor instead of just being able to have their class
names entered.  So, we need a scheme to allow the user to select a class name
from he known classpath, enter in the name, or create a new customizer or
property editor.  This will make it that much more efficient for developers
working on beans.  Also, properties and events can have differently named
methods than the standard bean patterns.  These should be able to be defined and
chosen by the developer.  There seems a lot we can do here to make JavaBean
development better instead of worse by removing features.

>This is little too general statement. Could you please specify which features of
>the old Beans module you want to see be brought back? Obviously saying that all
>is not the right answer :-). Thanks

Just some comments.  This is part of the problem with not asking users before
removing a feature or features.  You used the terms "general statement", "old
Beans module", and "Obviously".  Yet, if you were to ask JavaBean developers
which features they want to remove from the BeanInfo and Bean Patterns editor
you would more than likely get a much different set of responses.  

NB 6.0 is not out yet.  The features are in NB 5.5, so it isn't exactly old
functionality.  I can't think of any of the Bean Info editor functionality I
want to live without.  I use it all the time, and I certainly do not want to end
up typing the monotonous code associated with a BeanInfo class over and over
again.  

BeanInfos are commonly and generally needed with JavaBeans.  I have answered
numerous questions on the topic over the course of the past few years on the NB
users mailing lists.  I have shown people how to create JavaBean libraries for
inclusion in the IDE and in the palette using the BeanInfo editor.  I have been
planning a tutorial which covers this as I have answered it quite a number of
times.  The features not only save time, but they help newbies get up to speed
on JavaBeans development.

OK I see, all the functionality is needed. Now the only problem is to find some
volunteers who will port it to 6.0. Thanks for the long description. It is a
little surprise to me that someone likes the guarded block based beaninfo. I
might try to do at least something myself. But there is very little time so as
said before we need some volunteers. 

BTW: IMO asking the whole user base if you can remove a feature is nonsense.
There is always someone who will say you should not. The right question sounds
very differently. But it is probably not "politically correct" to discuss this
in open source bug tracking system.

Yes, you are going to have some dissenters with any question.  The main point is
that a few not make major decisions for the whole without good input.  Otherwise
who is the IDE helping?  We have got to get to the point where we are getting
more community feedback.  Yes, talking about it here isn't politically correct,
but we have to start some where.  Anyways, we can deal with general community
issues in a different place and time.

I'll volunteer to help work on the features as they are important to me.  I have
some features I'm to help with in the Form Editor as well.  So, these will tie
me up pretty much in all my spare time ... day job isn't working on NetBeans
features, but instead I use the IDE for my daily job, and I contribute where I can.

We need to talk to some of the folks who were part of removing the sub-nodes on
Java files I suppose.  That is unless you have some good ideas as how to support
it better.  I like the BeanInfo being under Java nodes because this helps work
on multiple beans at the same time as the view remains static while working on
multiple files.  If we put it in a NavigatorPanel what will happens is:

1) User selects a .java file.
2) The first NavigatorPanel is shown (Members Panel)
3) The user has to select from a combo-box the Bean Info panel.

Currently (5.5) the user can have multiple files expanded to the "Bean Patterns"
node.  They still have to access the BeanInfo Dialog however.  To me it would be
more productive to have the BeanInfo editor et. al under the .java file "Bean
Patterns" sub-node to make it more useful for working on multiple files.

As far as guarded blocks are concerned, I don't mind so much as it keeps me from
having to do so much manual labor.  However, there may be some who object.  We
can either tell them they can still add the BeanInfo manually and do it all by
hand, or we can look into the new Java support and see if there would be some
way of not forcing it to be guarded block protected (we would have to be able to
discern the BeanInfo patterns through programming though...might be more trouble
than it is worth).

Do we need to setup a wiki page on the public wiki to start working on the
design?  Others viewing this comment, do you have any ideas about the UI of
BeanInfo editing?

I should add to the user actions list:

4) When the user selects another .java file or comes back to a file they were
previously on steps 1-3 must be repeated every time.  Not very efficient for
developer time when working on a bean library.

Hello,

one of my wife's gripes about NetBeans is that she does not like the
intermediate nodes under java nodes - she would like to have there directly
methods/fields under the java node. One might ask the obvious question: 

Where have all the looks gone?
Long time passing
Where have all the looks gone?
Long time ago
Where have all the looks gone?
Girls have picked them every one
When will they ever learn?
When will they ever learn?

David

Do you want to know? :-)
I think you know.

Beans resurrection branch created and first very basic rewrite to Retouche
checked into it. 

For more info about status and to discuss the issue please go to:
http://wiki.netbeans.org/wiki/view/Beans_90907Experiment

I created new issue 103550 which is somehow connected to this one, though not
duplicate of this.
I believe that the current state of explorer window (that java files don't have
children) is ok. The place for java file structure is in Navigator. And as I
described in issue 103550, there should be and option to show beans properties
in Navigator and Members windows.
Concerning the Bean Patterns node: I think its location was quite non-intuitive.
I discovered that there is such thing in NetBeans after long time of using IDE.
So perhaps it should be somewhere else, maybe as separate view (window) opened
via context action, based on the old Bean Info Editor, or somehow merged with
Navigator and/or Members view?

Your issue is a duplicate.  This issue is going to address it.  Please see the
wiki page referenced in this issue.

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

I need to explain what I wanted in issue 103550 in more details:
My idea was to have a "lighter" version of Bean Info: instead of Bean Patterns
node I just wanted to add new node type into Navigator
and Members window. Now there are "field", "method" and "constructor" nodes. I
wanted to add "property" node type, and the new filtr to turn on/off
showing properties nodes. This is because I don't treat all the getXXX and
setXXX methods as real methods. Semantically, they are not the real methods, but
they simply constitue the property. So in order to have the clear view of class
members (in navigator or members window) I should be able to see one property
node instaed of each setX/getX pair (or getX if read only) methods. Displaying
setX/getX methods make Navigator/Members tree bloated.
This means that we need some new filter to switch between combinations like:
1.display all methods ("real" and getters/setters) - as it is now
2.display "real" methods only and properties
3.possibly other combinations (only "real" methods and no properties, or only
properties and no methods) 
This becomes a bit complicated, but I believe it could be really useful.
Perhaps we need to have two new filters: "Hide setters/getters" and
"Display/Hide properties" - this should enable us to display all views mentioned
above.

The Bean Info And Bean Editor I treat as some separate and more
coplicated/detailed thing. But it should not be thrown away, obviously.

BTW: the wiki mentioned in this issue is not reachable: before Access Denied,
now I get Server not found.

I got a "deal breaker" comment at JavaOne today from a visitor to the NetBeans 
pod. He said he wants to recommend NB for his entire team, but refactoring 
won't rename a bean property. If you rename the field, the getter and setter 
is not changed. His workaround was to open the class node and rename the bean 
node, but that's gone in 6.0 M9. 

vaughn: AFAIK workaround to rename a property via the Beans node does not help
much. Yes it renames field + getter/setter but without any refactoring. We would
like to add this to the Rename Refactoring action.

Some improvements done in the branch:
1) Tree does not collapse any more
2) Icons for classes
3) Handles innerclasses
4) Types for properties shown

See screenshot

Created attachment 42277 [details]
screenshot

To me this would make sense to be consistent and have all bean work within the
bean patterns navigator panel.  The beans module really needs to add support for
refactoring as we are getting ready to add to the form module.  Then refactoring
renaming of a bean pattern method would need to be thought out.  To the regular
refactoring it would just appear to be a method name which alerts refactoring
support in other modules, and to the beans module it would be renaming a
property or one of the setters or getters which would in turn create a
refactoring transaction and alert other modules.  I suppose renaming of standard
property patterns in refactoring would be fine, but obviously the beans module
needs to be aware of the refactoring to update property descriptors etc if they
are being used which would need to be the case if we start supporting the user
using methods outside standard property patterns (for instance methods which
begin with can instead of is).

We need to allow the user to choose at refactor time whether to keep the method
under control as a property setter or getter (a pattern set/get/is doesn't have
to be used and the read/write method can be determined by a PropertyDescriptor)
or if they want this method to no longer be part of a property.  We would also
need to determine if the methods parameter set is changed whether it matches
anything a property can use.  If not then some how the user needs to be informed
(if controlled under BeanInfo) this method will not be able to be used as a
property setter or getter...anyways, that is the general idea, to have it tied
to refactoring.

>BTW: the wiki mentioned in this issue is not reachable: before Access Denied,
>now I get Server not found.

Yes, not the one in the URL, but the one mentioned in comments on
http://wiki.netbeans.org.

Petr, can we set the nb wiki page to the URL, or is the link in the URL needed
by your team?

Feel free to change the URL.

All that "we need" refactoring/beaninfo means. You will do it? Just for record
for me this is out of scope for 6.0 for sure. Except rename refactoring will
probably rename getters and setters as Jan Pokorsky mentioned that's all.

Petr, "we need" really just means what we need to do.  I don't think all of it
can be done by 6.0.  I have committed to helping the form project implement
refactoring support.  After that I will be glad to work on this part as I can. 
In the wiki I added refactoring support as part of the "future" section.

I've installed 6.0 M9 and cann't find the BeanInfo-Editor. 
I thought this was an bug or the BeanInfo-Editor is moved to an other place -
but now I read (coincidentally) that the BeanInfo-Editor should die - is this
realy true?

I used the BeanInfo-Editor to generate and modify *BeanInfo.java for my custom
Beans (=Swing Controls - added to GUI-Palette), toogle include Properties and
Methods, configure Properties (Expert, Hidden, Description, Property Editor
Class ...).

There is a lot of code generated by the BeanInfo-Editor in *BeanInfo.java -
would be very painfull to code this.

It's very important for me that I could use the BeanInfo-Editor in future (maybe
as plugin or submenu of a submenu of a...)

I meant to post another note earlier than this. I wrote Petr and we decided we
are both too busy for this to make it into the 6.0 release, but directly after,
if I remember correctly, and definitely for me (I don't want to put words in
Petr's mouth), the plan is to release an update through autoupdate to add it
back, and then moving forward past 6.0 this should be available again.

Wade is right I think if we start working on it after feature freeze we should
be able to releas it on AU in parallel with 6.0

Thank you very much! I'm happy :-)

Just wanted to add my voice to this issue, I too will miss the BeanInfo Editor/Generator. Anything that can help me 
code a BeanInfo is good! Bring it back from the dead!

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

Possible workaround:  Rename application to NyetBeans
(http://www.m-w.com/dictionary/nyet)

Seriously though, the Java Tutorial relies on this feature, as can be seen at this page.

http://java.sun.com/docs/books/tutorial/javabeans/properties/properties.html

I was just about to learn how to make Bean Properties, but it looks like I'm dead in the water since I already upgraded
to 6.0 beta 1.

You marked the issue as started. Does it mean you are going to work on it? If not mark it as NEW again and don't do such
changes in the future. If yes feel free to contact directly me if you have questions.

I'm sure he did this on accident. I think he hasn't used IZ or something. Notice he was working on the JB tutorials from
java.sun.com and couldn't do them, so I would say that he is fairly new to Java and isn't working on the IDE. Lets just
leave it as started, and I'll see what I can do now. I will be working on it more after Oct. 27, but hopefully I can do
a bit between here and there. No guarantee on how long I will take though...work work work ;-). I think at this point it
is more important to work on than the other features of form (Matisse) which the guys don't have working for
refactoring, and I will then hopefully have more time to work on form later as it is more complicated than this anyways.

Sorry if I marked the status wrong.  It thought with so many posts and the "Beans resurrection branch created", it must
have been a mistake that it was still marked "NEW".  To me, "NEW" would mean nobody had even evaluated the report. 
Maybe "LATER" would have been a better description.  I'm not new to Java.  Just new to Beans and your bug tracking
system.  In any case, I won't touch the status anymore.  
 

The Bean Patterns is a funcinalidade very useful, can't be removed.

I have to concur with the rest of the comments here that this is a very strange move to make. It seems to me as if all
features which are important to serious java programming (for me this includes at least both javadoc and javabeans) have
been left out of 6.0 for reasons I fail to understand. Its really nice that NB can generate a lot of code on its own but
what added value does that really hold when it will only turn out to be seriously harder to customize that code? And
thats not even touching the subject of writing custom javabeans. To me this is a major step backwards, enough to ignore
6.0 for now.

To be honest I don't understand the last comment at all.

1) "javadoc and javabeans have been left out of 6.0 for reasons I fail to understand" - We did not have enough
time/people to rewrite it. As I said several times it was not removed. It was not rewritten and thus it does not work in
6.0. Do you still fail to understand it? Are you offering help? This is open source you are welcome to send patches.
Other way of having beans back soon would be to find some programmer and pay him for rewriting it. There is a free
market all around you (I suppose). Are you offering money?  

2) "Is really nice that NB can generate a lot of code on its own but what added value does that really hold when it will
only turn out to be seriously harder to customize that code?" - Does this mean that you find it better to open some
pseudo wizard for a property and type the FQN of the class (not doing any typo) and have the getter/setter than writing
the fields using CC and then generate all the setters and getters after pressing Alt+Insert? Also please notice that the
getters and setters are possible to generate directly from code completion. 

3) The GUI of bean info editor, bean property editors and autocomment was horrible and we should think twice before we
put it back. Believe me I can judge it as I'm the original author of it. :-)

Not to try to turn this into an endless argument but no; I don't understand. NB is, as you stated yourself, an open
source project and fully written and setup by volunteers. It doesn't need to have a christmas release perse so that the
sales will go up because its hitting the market right on primetime. Therefor one would think (or assume) that the
individuals contributing to it won't be pushed or stressed to get certain things out "right on time according to
schedule". And when it comes to essential parts like javabeans and javadoc I sincerely do not understand why its not
being given more priority. I think it might even be better to postpone the entire release by a few months in order to
generate more time and opportunities than to leave essential parts like these out. I understand the /reasons/, I don't
understand /why/. Sometimes small things can make big differences. Alas; just my opinion on the matter. Can't elaborate
more than that; anything beyond this will merely turn out into "I said, you said" which is pointless.

Nice try. We could certainly postpone the whole release. This would:

a) make lot of people who do not care about beaninfo (other things work) wait for several months for 6.0
b) make absolutely no difference for those who do care about the old beans stuff. This is planed for 6.1 or for
autoupdate if the 6.1 is too late. I.e. these guys will have the feature exactly at the same time as in you r proposal.

Sometimes blindly follow the rules described in the Open Source classic books do not make much sense. I'm all for
"release when it is ready". But in something of the size of NetBeans 6.0 you better consider one or few modules a
product not the whole thing.

Did you try 6.0 and the features which replace beans and autocomment? If yes what is exactly the feature you miss? If
not then ... you should try it first.
 
And last but not least, as you did not answer the important questions: "Do you offer help?" "Do you offer money?" I
suppose the answer is no for both. Therefore we should really end the discussion. Thank you for sharing your opinion.
The world is full of smart guys who will give me wise advices what to do and what not to do.

 

 

Is the same branch being used or should I work in the trunk? Is the plan in the Wiki, or at least what we have in the
wiki, still relevant?

I've just resurrected beans module in NetBeans trunk. In fact I've only merged bug90907_experiment branch to trunk.
Now Navigator has a new panel: Beans Panel.

As for wiki page. This page is live. Not up-to-date but live. Now we are going to review the page, create plan a short
UI spec.

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

Is the beans development mailing list being utilized? I wrote to it to subscribe, but I haven't seen any messages. I
didn't know where design discussions etc were taking place. I didn't know what was planned and what or who was doing
what right now, but wanted to work on some feature etc.

I updated wiki page with current status.

As well, this feature is demonstrated too by Sun Java Tutorial, see
http://java.sun.com/docs/books/tutorial/javabeans/introspection/index.html.
There is any chance to get this as a patch or update for 6.0 or 6.0.1, or will be necessary wait until 6.1?

+1 vote to bring that beans support back!

Fixed.