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 52998 - Review of moving ProjectClassPathExtender into public package
Summary: Review of moving ProjectClassPathExtender into public package
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
Depends on:
Blocks: 49653
  Show dependency tree
Reported: 2005-01-05 15:25 UTC by Tomas Zezula
Modified: 2006-03-24 12:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Diff (28.91 KB, patch)
2005-01-05 15:28 UTC, Tomas Zezula
Details | Diff
Diff to previous patch: Added @since to ProjectClassPathExtender (514 bytes, patch)
2005-01-06 13:34 UTC, Tomas Zezula
Details | Diff
Diff to previous patch: Fixed arch.xml (377 bytes, patch)
2005-01-06 13:35 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2005-01-05 15:25:49 UTC
The ProjectClassPathExtender is used by the form
editor to extend the compilation classpath of
j2seproject by new classpath entry when bean is
added into component palette.
The ProjectClassPathExtender was a private
contract between form editor and j2seproject.
Moving this interface into the public SPI will
remove the implementation dependency of
java/j2seproject and form editor on the
java/project module.
Comment 1 Tomas Zezula 2005-01-05 15:28:33 UTC
Created attachment 19498 [details]
Comment 2 Tomas Zezula 2005-01-05 15:33:33 UTC
Changed interfaces: Added new public interface

Stability Category: Should become stable in the NetBeans 4.1
Comment 3 Tomas Zezula 2005-01-06 13:34:39 UTC
Created attachment 19525 [details]
Diff to previous patch: Added @since to ProjectClassPathExtender
Comment 4 Tomas Zezula 2005-01-06 13:35:37 UTC
Created attachment 19526 [details]
Diff to previous patch: Fixed arch.xml
Comment 5 Tomas Pavek 2005-01-10 14:58:37 UTC
I've reviewed the change. It looks ok, I agree with integrating it.
Comment 6 Miloslav Metelka 2005-01-10 15:39:31 UTC
The change seems fine to me as well. I agree with the integration.
Comment 7 Jesse Glick 2005-01-10 18:49:27 UTC
@since tag should use, not just

Re. j2seproject/build.xml change: I think some ide/* module now has an
impl dep on j2seproject, alas, so this may not be possible any more.
Note that your patch will no longer apply against trunk as is.

Patch to j2seproject/.../project.xml is not related, is it? If not,
please just do it in the trunk.

Coordinate with dkonecny since he also has planned changes (in
apireviews) to the AntArtifact interface, which I seem to recall would
affect the addAntArtifact method signature.

Now that the parameter types in the PCPE methods are all arrays,
shouldn't the method names be pluralized? E.g. addLibraries,
addArchiveFiles, addAntArtifacts. For that matter, what is the reason
for this change? According to the Javadoc it seems that the semantics
of calling

pcpe.addLibrary(new Library[] {lib1, lib2});

are the same as

pcpe.addLibrary(new Library[] {lib1});
pcpe.addLibrary(new Library[] {lib2});

so it seems an unnecessary complication to pass an array. In fact the
only known client, form, still only adds one item at a time. Is there
some hidden reason for this change?

In apichanges.xml, you must use consistent capitalization:

In apichanges.xml, please use <class> and <issue>.

Don't forget Copyright 2005.

s/can not/cannot/g; s/in the case when/in case/g
Comment 8 Tomas Zezula 2005-01-11 08:17:57 UTC
IDE depends on java/j2seproject - I know, it is the new module.
IDE does not depend on java/project - this dependency can be removed.
The array is used due to performance, if the client needs to add more
classpath entries it can use an array and project is saved just once.
I will change the method names to plural.
Comment 9 Tomas Zezula 2005-01-11 09:41:10 UTC
While taking look at David's scheduled changes I've decided to change
the parameters from an array back to single object. It will be a bit
slower for client of this API which needs to add more classpath
entries, currently there is no one, but as the addArtifact(...)
requires an additional argument, an URI of build output, the array
version of the API will be ugly (addArtifacts (AntArtifact[] , URI[])).
Comment 10 Tomas Zezula 2005-01-11 10:37:18 UTC
I've fixed all problems Jesse reported.
Comment 11 Jaromir Uhrik 2006-01-18 10:47:07 UTC
Marking this issue as VERIFIED since the issue reporter == issue owner.