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 42903 - AntArtifact should support multiple products per one target
Summary: AntArtifact should support multiple products per one target
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Konecny
Keywords: API
Depends on:
Blocks: 41535 42864
  Show dependency tree
Reported: 2004-05-06 16:38 UTC by Adam Sotona
Modified: 2004-08-13 12:10 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

API change diff (31.69 KB, patch)
2004-05-12 17:43 UTC, David Konecny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Sotona 2004-05-06 16:38:16 UTC
1. wrong property name is created when referenced
project contains spaces in name
2. the same reference name is used for two
different ant articats of the same referenced project
3. relative JAR path is not URL-decoded

Project.jar-all};${reference.My Project.jar-all}

reference.My\ Project.jar-all=${project.My
Comment 1 Jesse Glick 2004-05-06 18:35:14 UTC
Assigning to David for now.

Re. #1 - yes RH is supposed to replace dangerous chars with '-' or '_'
or something.

Re. #2 - not sure about it.

Re. #3 - should not be using URL encodings in property values since
Ant does not interpret them. Probably a bug in PropertyUtils.relativize.

Is there a reason why this is filed as P1? Is this blocking some kind
of work for you? If not, it is P2.
Comment 2 Adam Sotona 2004-05-07 07:37:42 UTC
OK, changed to P2, sorry.

ad #2: reference is constructed from project name and target but
different jar taken is not mentioned

ex.: one J2ME project can have multiple configurations, all of them
are build by jar-all target but jars are located at different folders.

libs.classpath=${reference.My Project.jar-all};${reference.My
- references twice the same

reference.My\ Project.jar-all=${project.My
- but this is the only one of referenced artifacts
Comment 3 David Konecny 2004-05-10 14:40:53 UTC
I will fix #1 and #3.

As for the #2: this is caused by your configurations about which
ReferenceHelper does not know nothing. Please look at it and suggest
some solution/patch how you think the ReferenceHelper should be
modified to be still usable for you. The very stupid solution I can
imagine is that you use ReferenceHelper as is and after it generates
the property you read the value and store it as
<configuration>.reference=reference_value or something like. I do not
remember details how your configurations are implemented. There are
certainly other solutions.

Also take a look at which
you might need to use too. See issue 42520 for more details.
Comment 4 Adam Sotona 2004-05-10 15:50:10 UTC
ad #2 reference name just need to be uniqe. There is no problem with
configurations of current project but with the referenced one.

Problem is that two Ant articats can differ only in URI
Comment 5 Jesse Glick 2004-05-10 16:54:41 UTC
Two AntArtifact's *cannot* differ only in artifact location; they must
be using a different target. The primary key is [project,targetName].
Clean target name, type, and artifact location are non-key data. So if
ReferenceHelper creates properties of the form


then it is behaving correctly.
Comment 6 David Konecny 2004-05-10 22:00:47 UTC
Jesse, in that case we should update Javadoc for
AntArtifactProvider.getBuildArtifacts() to say that.

Here are two thoughts on how this could be fixed:

The ReferenceResolver could be modified to take in account also the
artefact location. That is, for two same AA with different artefact
location it would generate one ID for project
("project.<FOREIGN_PROJ>") and two IDs for file references
("reference.<FOREIGN_PROJ>.jar" and "reference.<FOREIGN_PROJ>.jar-2").
I think it is doable. The RH.removeReference(projName, targetName)
must be updated and perhaps some other methods too. But this change
kills one feature: if user changes output path in project A and the
project is used from project B then we cannot automatically update
reference value in project B to point to new filename. That's bad.

Improvement of previous solution could be: enhance AA with new method:

  * Returns identifier of the AntArtifact which must be UNIQUE WITHIN
  * ONE PROJECT. By default it is target name which produces the
  * artefact, but if your target produces more that one artefact then
  * you must override this method and uniquely identify each artefact.
 public String getID() {
     return getTargetName();

The method would be overriden in J2ME and would return e.g.:
(getTargetName() + "-" + getConfigurationID()). RH would be modified
to use this ID.
Comment 7 Jesse Glick 2004-05-11 00:53:18 UTC
Second solution sounds acceptable.
Comment 8 David Konecny 2004-05-12 17:43:01 UTC
Created attachment 14831 [details]
API change diff
Comment 9 David Konecny 2004-05-12 17:46:08 UTC
Attached is diff with changes. Unfortunately there is couple of API
changes and not all are compatible:
* AntArtifactQuery.findArtifactByTarget() renamed to
findArtifactByID(). I could leave there findArtifactByTarget() but its
return value would have to be changed to array anyway. So I just
removed it.

* second parameter of ReferenceHelper.removeReference() and
removeRawReference() is still of type String but now it is ID and not
target name anymore

* ReferenceHelper.RawReference constructor has one more parametr: ID.
I considered to provide backward compatible constructor using target
name as ID, but I think it is better to break potential code in Web or
J2ME and point them to the change

* old project with persisted references to some other project will be
broken now: IllegalArgumentException will be thrown because persisted
artifact in project.xml does not store ID. Again, could be tolerated
for some time, but we do not have commitment to project format so I
think it is better to break it now then later.

If you find these changes OK I will commit it and post note on nbdev.
Comment 10 Jesse Glick 2004-05-12 20:50:22 UTC
Sounds OK to me.

Don't forget about #1 and #3 - should probably be filed separately.
Comment 11 David Konecny 2004-05-13 09:33:18 UTC
#1 - filed as issue 43190
#3 - files as issue 43191
Comment 12 David Konecny 2004-05-13 09:35:11 UTC
Adam, please verify. Thanx.

Fixed in:
Checking in src/org/netbeans/api/project/ant/;
new revision: 1.8; previous revision: 1.7
Checking in src/org/netbeans/api/project/ant/;
new revision: 1.4; previous revision: 1.3
Checking in src/org/netbeans/spi/project/ant/;
new revision: 1.4; previous revision: 1.3
Checking in src/org/netbeans/spi/project/support/ant/;
new revision: 1.8; previous revision: 1.7
Checking in
new revision: 1.8; previous revision: 1.7