This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 49648 - Support SPI: read/write properties to project/
Summary: Support SPI: read/write properties to project/
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Hrebejk
Depends on: 49637 51151
Blocks: 41837
  Show dependency tree
Reported: 2004-09-28 18:02 UTC by Jesse Glick
Modified: 2005-01-16 19:21 UTC (History)
5 users (show)

See Also:
Exception Reporter:

Proposed class supporting the ANT->Swing->ANT conversion and storing to EditableProperties (7.53 KB, text/plain)
2004-12-13 15:50 UTC, Petr Hrebejk
Patch of the arch.xml int ant/project with added usecase (2.30 KB, text/plain)
2004-12-13 15:52 UTC, Petr Hrebejk
Modified version of the SourceGroup (8.18 KB, text/plain)
2005-01-11 11:21 UTC, Petr Hrebejk
Unit test for the store group (6.43 KB, text/plain)
2005-01-11 11:22 UTC, Petr Hrebejk
Demo of the StoreGroup usage in the J2SE project (13.72 KB, text/plain)
2005-01-11 11:24 UTC, Petr Hrebejk

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-09-28 18:02:49 UTC
Should support appropriate defaults, formatting of
properties by type, etc.
Comment 1 Petr Hrebejk 2004-12-13 15:50:09 UTC
Created attachment 19258 [details]
Proposed class supporting the ANT->Swing->ANT conversion and storing to EditableProperties
Comment 2 Petr Hrebejk 2004-12-13 15:52:20 UTC
Created attachment 19259 [details]
Patch of the arch.xml int ant/project with added usecase
Comment 3 Petr Hrebejk 2004-12-13 16:02:30 UTC
I would like to propose to add the API (see for support for
creating Swing models from ANT properties and for storing them back to
the project. For the short howto on using the API please see the
arch.xml.diff attachement. 

Please ingnore the surrounding Ant class. It won't be there when the
decision about the target package will be made. The question (very
likely for Jesse) is what the target package and or package should be.

1) ant/project 
  - Will mix plain ant support and swing models
  - possible ant/project dependency on project/libraries see 2)
2) ant/project
  - I'm thinking about adding more methods into the StoreGroup class
    e.g. methods for creating TableModel from classpath this would
    require dependency of ant/project on project/libraries
3) new module ant/projectui same package as in 2)
  - This module could depend on ant/project and on project/libraries


Comment 4 Petr Hrebejk 2005-01-02 15:24:22 UTC
Anoter aspect to consider when deciding about the place where to put
the api could be issue #49650 : Support SPI: artifact chooser.
In fact this is AntArtifactChooser and relies on AntArtifact and
AntAtifactQueryClasses and as such should probably not reside in
ProjectUIAPI module. (Project UIAPI module should not depend on ant
ANT secific implementation, I guess)
Comment 5 Jesse Glick 2005-01-04 02:51:11 UTC
Re. location: ant/project
sounds OK to me. I don't see any problem with ant/project ->
project/libraries. If we change our mind later, it is easy to split
the .ui package into its own module (using ModuleAutoDeps).

arch.xml patch is nice but (1) don't use the <h3>; (2) create valid
XHTML: <p></p> is evil, and text should be inside a <p>. Also, do we
really need the use case in arch.xml where it is hard to find?
Couldn't you just make up some sample code and paste it right into a
<pre> block in the StoreGroup Javadoc, where people would expect to
look for usage information? I think it is more appropriate to use
arch.xml to list *links* to appropriate and helpful documentation, not
as the main source of that documentation.

Now for the patch itself:

Need Javadoc for StoreGroup().

Class Javadoc for StoreGroup should be more descriptive, I guess.

Looks like a unit test for this stuff would be straightforward and
helpful. After all, you're using Swing models, which are much easier
to handle inside a test than the real component.

'models' is a Map<String,Object[]|Document>, not a
Map<String,Object[][]> as its comment implies. Right? And it seems
that the code in store(...) which casts models.get(...) to Object[] is
wrong as createStringDocument calls models.put(String,Document).

Javadoc for createBooleanButtonModel and various pieces of impl say
"enabled/disabled", yet cBBM Javadoc also says "on/off". Which is it?
Note that Ant accepts "on/off" but not "enabled/disabled" so I don't
know where "enabled/disabled" is coming from.

Remove the System.out.println.

Why do you do

Document d = new PlainDocument();
d.remove(0, d.getLength());

If the document has just been created, surely you do not need to
remove anything from it.

You can throw an AssertionError from the BadLocationException catches,
since it should be impossible.


There is no particular reason to require an EditableProperties to be
passed in; any Map<String,String> would do. However if you do use it,
please call setProperty, not put.

Document and enforce threading: must store(...) be called from EQ?

Would like to see a diff of j2seproject using the new API, as well as
positive comments from at least one other potential user.
Comment 6 Jaroslav Tulach 2005-01-04 06:34:45 UTC
Usecase in arch.xml is displayed at
should be written in a way to be meaningful on that page. Of course
(other) usecase in javadoc is useful as well. 

Test should of course be a must in a regular api development.
Comment 7 Jesse Glick 2005-01-04 16:34:01 UTC
"Usecase in arch.xml is displayed at
should be written in a way to be meaningful on that page. Of course
(other) usecase in javadoc is useful as well." - I don't follow the
logic here. If there is one known use case for a particular class,
surely it is best to put the actual sample code directly into the
class Javadoc, where it is obvious if you are looking at the Javadoc;
and add an href to the use cases page for people looking there.
Comment 8 Jaroslav Tulach 2005-01-04 17:05:39 UTC
usecase in class javadoc + link to it is sufficient. I was referening
to the fact that usecases.html should become entry point for main
nbdev tasks. This would not work without the link.
Comment 9 Petr Hrebejk 2005-01-11 11:21:47 UTC
Created attachment 19601 [details]
Modified version of the SourceGroup
Comment 10 Petr Hrebejk 2005-01-11 11:22:48 UTC
Created attachment 19602 [details]
Unit test for the store group
Comment 11 Petr Hrebejk 2005-01-11 11:24:25 UTC
Created attachment 19603 [details]
Demo of the StoreGroup usage in the J2SE project
Comment 12 Petr Hrebejk 2005-01-11 11:26:40 UTC
The required changes done. And attached. Test written and attached.
Also attached demo of the usaage in J2SE project. The useage in the
panels should be staight forward e.g. someComponent.setModel(). See
the test.

Would like to check in tomorrow. (Jan 12 2005)
Comment 13 Jesse Glick 2005-01-11 20:32:34 UTC
In the unit test, you could avoid the need for the
PlainPropertyEvaluator nested class; see PropertyUtils methods
fixedPropertyProvider and sequentialPropertyEvaluator.

Don't forget SPL in (and 2005 copyrights everywhere).

In J2SEUIProperties: s/Propeties/Properties/g

Catch of BadLocationException in retrieving text from a Document
should I guess throw an assertion error - should never happen.

J2SEUIProperties: various static fields could be final. Also, probably
many of the public constants are already defined elsewhere? Some are
unused, too: SRC_DIR and TEST_SRC_DIR at least.
Comment 14 Jaroslav Tulach 2005-01-12 09:45:13 UTC
Seems to me that your implementation does not allow two models for  
the same property in one StoreGroup. Even not very likely, I guess  
that this is not the desired behaviour.  
I suggest to add link to CVS to show sample usage in J2SE to the 
javadoc of StoreGroup. 
Comment 15 Jesse Glick 2005-01-12 19:30:35 UTC
What would you do with two models for the same property? Which one
would you store from??
Comment 16 Jaroslav Tulach 2005-01-13 12:41:02 UTC
At least throw exception.
Comment 17 Jesse Glick 2005-01-13 16:03:48 UTC
Agreed; assuming that it is forbidden to have >1 model for a single
property, the create* methods should throw IAE if it is attempted (and
Javadoc and the throws clause should both mention this).
Comment 18 Petr Hrebejk 2005-01-16 19:21:49 UTC
Proposed changes checked in.