Bug 49550 - Make ReferencesHelper.createForeignFileReference produce relative links based on properties
Make ReferencesHelper.createForeignFileReference produce relative links based...
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Ant Project
4.x
All All
: P2 (vote)
: 4.x
Assigned To: David Konecny
issues@projects
buildsys-e-cand
: API, API_REVIEW_FAST
Depends on: 51151
Blocks: 41535
  Show dependency treegraph
 
Reported: 2004-09-24 22:03 UTC by Pavel Buzek
Modified: 2005-01-11 09:52 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
patch (14.09 KB, patch)
2004-12-09 13:44 UTC, David Konecny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Buzek 2004-09-24 22:03:33 UTC
It would be very useful if
ReferenceHelper.createForeignFileReference()
returned relative path for files under any
external roots as well as for the project
directory. Otherwise I have to add code to check
external roots in every place where I call this
method because using full path for these files is
a bug (49548). 

I am marking this as a defect because the API
would IMO make more sense if it it worked for
external sources. If you cannot fix this for 4.0 I
will have to use the workaround.
Comment 1 Jesse Glick 2004-09-24 23:31:12 UTC
This is an API change, not a bug, so it is not possible for D.
Currently it does what it is supposed to: create relative paths when
it can (when they would be collocated with the project dir), otherwise
absolute paths.

What you want, perhaps, is to be able to configure the RH with a list
of Ant property names which are to be treated as alternate basedirs
that the file might be collocated with, in which case the reference
would be created as shared and of the form
${some.known.property}/some/path. Proposed API would look something like

public void ReferenceHelper.addAvailableBaseDirectoryProperty(String
propertyName);
Comment 2 Pavel Buzek 2004-09-25 00:47:16 UTC
That would work, although I would be happy if it worked just with the
external folders which are displayed in the physical view. I would
actually found that more natural then passing the same set of folders
again.
Comment 3 Jesse Glick 2004-09-25 01:49:28 UTC
Can't "just work" with the folders in the Physical View because (1)
these are defined with a SourcesHelper, which the ReferencesHelper
knows nothing of, (2) it needs to know the Ant property name (or
expression) used to define the external source root.

Amend the proposed API to read

public void ReferenceHelper.addAvailableBaseDirectory(String
text);

where text can be any string possibly containing Ant property references.
Comment 4 David Konecny 2004-12-03 11:10:54 UTC
Usecase: user added external source root and after that added a jar
(lying below this external source root) to project's classpath.
RH.createForeignFileReference() correctly created property based on
the already defined external source root property. Later, user removed
external source root.

What should happen? 

Solution1: external source root property cannot be simply removed in
this case because it is being used by some other property. Perhaps
there could exist helper method <code>boolean
PropertyUtils.isPropertyReferenced(String propertyName,
EditableProperties props)</code>. The disadvantage is that if user
removes the jar from project's classpath then external source property
will never be removed although it is not used anymore.

Solution2: any usages of external source root property must be
replaced with its value and after that it can be safely removed.
Solves the disadvantage mentioned in S1. Again there could he helper
method <code>boolean PropertyUtils.removePropertySafely(String
propertyName, String propertyValue, EditableProperties props)</code>
which would do the replace and return true if a substitution occured.

In both cases it would be project type responsibility to impl above
solutions as part of external source root removal.


Other issue is that project type must be able to unregister external
source roots from RH. So instead of suggested
addAvailableBaseDirectory() method I would rather define 

public void ReferenceHelper.setAvailableBaseDirectory(Set
propertyNames);

Btw. Jesse, what was your motivation for moving from "String
propertyName" param to "String text".
Comment 5 David Konecny 2004-12-09 13:42:51 UTC
I would like to ask for review of simple API addition.

ReferenceHelper class is used for creating references to files used by
project. The class uses project's base directory as base for files
whenever possible. Some projects might have additional external base
folders (for which there already exist a reference) and this issue
requests that files lying under an external base folder take advantage
of the external folder and reuse its reference. The solution is to add
two new methods to ReferenceHelper which allows to add/remove property
names which value is the external folder and which will be used by
ReferenceHelper for creation references based on them.

I will attach source code diff which includes everything needed.

The new API is not used by J2SE project because its external base
folders are packages roots and it is not expected that project would
need to reference any files below these. The request came from Web
team which I believe has more generic external base folders.
Comment 6 David Konecny 2004-12-09 13:44:00 UTC
Created attachment 19230 [details]
patch
Comment 7 Jesse Glick 2004-12-17 17:20:58 UTC
Sorry I did not look at this issue at all, I was too busy. Will attach
some comments shortly.
Comment 8 Jesse Glick 2004-12-17 17:29:44 UTC
Re. moving from String propertyName (e.g. "externalRoot") to String
text (e.g. "${externalRoot}") - in case the project defines the
external dir using something other than a plain property dereference.
Compare various other ant/project SPI methods which accept a string
with possible fixed text and/or multiple property dereferences. But
this is probably not the case in practice, since we are dealing with
entire roots of directory trees, so I don't care much, esp. if it is
easier to implement as propertyName.

Re. addExtraBaseDirectory impl: do not use assertions to check the
validity of arguments passed into an API method, use exceptions, which
should be mentioned in the Javadoc (whether checked or unchecked).

Should not be using Java language synchronization (monitors); should
be using ProjectManager.mutex() in read or write mode as appropriate.

Don't forget to use the date of the actual commit in apichanges.xml.

Otherwise looks fine to me. Pavel, you have been silent about the
proposed change - will it in fact suffice for web projects?
Comment 9 David Konecny 2005-01-04 10:31:17 UTC
Could somebody from web team comment whether this is what you wanted
or not? Thanks.
Comment 10 Pavel Buzek 2005-01-10 14:03:53 UTC
Davide, this looks good for our needs. Thanks!
Comment 11 David Konecny 2005-01-11 09:52:37 UTC
Checked in:
apichanges.xml;
new revision: 1.3; previous revision: 1.2
manifest.mf;
new revision: 1.7; previous revision: 1.6
src/org/netbeans/spi/project/support/ant/ReferenceHelper.java;
new revision: 1.21; previous revision: 1.20
test/unit/src/org/netbeans/spi/project/support/ant/ReferenceHelperTest.java;
new revision: 1.14; previous revision: 1.13


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