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 65229

Summary:	Allow more general use of certain support classes/methods
Product:	projects	Reporter:	Jan Lahoda <jlahoda>
Component:	Ant Project	Assignee:	Milan Kubec <mkubec>
Status:	RESOLVED WONTFIX
Severity:	blocker	CC:	mkrauskopf, pjiricka, rmatous
Priority:	P2	Keywords:	API
Version:	5.x
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Exception Reporter:
Bug Depends on:
Bug Blocks:	73474

Description Jan Lahoda 2005-09-27 22:01:03 UTC

In the ant/project module, there are support classes/methods that seem to be
more general and usable even for modules/project types which are not ant
projects by nature.

Particularly:
-EditableProperties
-PropertyUtils.resolveFile, PropertyUtils.relativizeFile, maby other methods
-GlobFileBuiltQuery (although it depends on the AntProjectHelper, it seems that
the only thing it needs from it is the project directory. Naturally, this class
should be exposed only through a factory method.)

Comment 1 Jesse Glick 2005-09-27 23:03:05 UTC

It is true that some of these could reasonably be sedimented to lower API/SPI
levels. Comments:

- EditableProperties is pretty generic, just follows java.util.Properties spec.

- PropertyUtils.{resolve,relativize}File try to follow Ant semantics for
relative pathnames, but are probably generic enough to be useful without Ant as
well.

- GFBQ is trickier. It uses a PropertyEvaluator, which is I think Ant-specific
to some extent (or at least the standard impl is); may be easy to abstract that
out into a separate custom interface. Harder part is use of FileChangeSupport
(private in ant/project currently) - which should really be cleaned up, sped up,
tested better, expanded in scope, and put into the FS API.

Comment 2 Martin Krauskopf 2005-09-27 23:11:32 UTC

Also I believe that method in apisupport/project
org.netbeans.modules.apisupport.project.Util.[load|store]Properties could be
available somewhere. Jesse is against to have those method directly in the
EditableProperties since he wants to keep it analogous with java.util.Properties
as he wrote in some "Re: cvs_commit". But I really believe that such mehtod, its
code, will be copied on a lot of place through the (not only) NB_CVS code. So
would be nice to provide it.
Also consider org.netbeans.modules.apisupport.project.EditableManifest
(apisupport/project)

Comment 3 Sherold Dev 2005-10-12 11:40:52 UTC

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

Comment 4 Jesse Glick 2005-10-12 16:28:38 UTC

Problem with moving EditableProperties (i.e. copying & deprecating original) is
that several other API classes already refer to the original EP:

http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-project-ant/org/netbeans/spi/project/support/ant/class-use/EditableProperties.html

What do we do with them?

Comment 5 Jesse Glick 2006-10-14 00:10:54 UTC

Current Preferences storage uses java.util.Properties which loses ordering.
Should try to use EditableProperties instead.

Comment 6 Jesse Glick 2008-02-20 23:43:22 UTC

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

Comment 7 Jesse Glick 2009-07-22 19:59:53 UTC

Closing in favor of more specific and limited issue #92518 and issue #66577.