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 50076

Summary: Depending on freeform project: ant call performed multiple
Product: projects Reporter: herkules <herkules>
Component: AntAssignee: David Konecny <dkonecny>
Status: CLOSED FIXED    
Severity: blocker CC: navneet
Priority: P3 Keywords: REGRESSION
Version: 4.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 50484    
Bug Blocks: 42682    

Description herkules 2004-10-07 09:53:39 UTC
I have a freeform project that declares multiple
jars in its 'Output' section.

Create a standard NB project and make it depend on
that freeform project. What happens is that
multiple ant calls are generated into build-impl.xml:

    <target name="deps-jar" depends="init"
unless="no.deps">
        <ant target="build" inheritall="false"
dir="${project.HerkulesAnt}"
antfile="batch/build/build.xml"/>
        <ant target="build" inheritall="false"
dir="${project.HerkulesAnt}"
antfile="batch/build/build.xml"/>
        <ant target="build" inheritall="false"
dir="${project.HerkulesAnt}"
antfile="batch/build/build.xml"/>
        <ant target="build" inheritall="false"
dir="${project.HerkulesAnt}"
antfile="batch/build/build.xml"/>
    </target>
Comment 1 Jesse Glick 2004-10-07 15:16:22 UTC
David this is why I recommended that FreeformProjectGenerator produce
only one artifact (for the first JAR it encounters), not one artifact
per JAR. Advanced users who know what they are doing could configure
multiple <export> elements with different targets, but the GUI should
not try.
Comment 2 Jesse Glick 2004-10-07 15:20:00 UTC
The last change in issue #49221 is responsible for this bug. Navneet
requested

"If there are multiple built-to tags, the export tag is generated only
for the first one. I have a project that generates multiple jar files
and I have multiple <built-to> tags under the <compilation-unit>"

but too bad - we should not be creating multiple <export>s with the
same target in this case. The superproject can add the remaining JARs
as plain JARs (not "project"s) if necessary as a workaround. A future
version of AntArtifact could perhaps permit multiple files (e.g. a
path) in a single artifact; the current version does not and I think
it would be nontrivial to make it do so.
Comment 3 navneet 2004-10-07 19:45:37 UTC
The reason I asked for that change was that just mounting jars does
not allow me to set break points on the sources. 

I have a free form project that generates jars and another that is a
web project (with existing sources). All the code for the servlets is
in the jars. If i add the jars and then set the break point in init
method of a servlet in the free form project, that doesn't work. I
already did open a bug for this tool

Is there an alternative ?
Comment 4 Jesse Glick 2004-10-07 21:18:08 UTC
"The reason I asked for that change was that just mounting jars does
not allow me to set break points on the sources." - this has nothing
to do with source stepping. If a JAR is in some classpath you are
using, and it is declared as a build output of a freeform project,
then source stepping should work for it. The <export> element is
irrelevant to that.

"I have a free form project that generates jars and another that is a
web project (with existing sources). All the code for the servlets is
in the jars. If i add the jars and then set the break point in init
method of a servlet in the free form project, that doesn't work." -
well then something else is wrong. I don't know what, but if you file
a separate bug report with complete self-contained steps to reproduce
from scratch, it will be looked at.
Comment 5 David Konecny 2004-10-11 12:39:00 UTC
"The last change in issue #49221 is responsible for this bug." -  I
know. I was not sure about that change but then I thought that you
would comment if you had disagreed and so I did it. My fault, I will
rather ask next time when I'm not sure. :-)

The semantics of <export> is not clear to me. I think that if a target
produces multiple jars then each jar should have its own <export>
record. It is description of what project produces and so there should
be everything. It seems to me that freeform's AntArtifactProvider is
in fault by providing two artifacts of the same type and target.
Comment 6 Jesse Glick 2004-10-11 15:22:09 UTC
As I think I said, AntArtifact does not currently support multiple
files per artifact, so there is nothing ant/freeform could do to
expose multiple JARs from the same target without causing this bug.
Comment 7 David Konecny 2004-10-11 16:08:42 UTC
Yes, I know, but why just because of that we should alter export
section and its semantic to follow the AA? Should not rather export
section allow multiple jars and AA provider be changed to live with
that somehow till AA API is extended?
Comment 8 Jesse Glick 2004-10-11 18:01:17 UTC
"Should not rather export section allow multiple jars and AA provider
be changed to live with that somehow till AA API is extended?" -
perhaps, but changing the syntax won't help anything until the API is
extended. Also I consider the XML schemas frozen for 4.0; we should
not touch the format until 4.1 (meaning a new namespace).
Comment 9 David Konecny 2004-10-13 13:04:55 UTC
The correct fix is to enhance AntArtifact to permit multiple outputs.
That's perhaps 4.1. But what would you prefer to do with this issue
for now? I see couple of choices:

#1) leave as is. Everything works, there is just performance problem
with Ant target being called multiple times during one build.

#2) keep generating <export> elements as now, but modify freeform's
ArtifactProvider to provide AA only for single outputs. If there are
multiple jars exported by the same script/type/build-target then they
would be skipped.

#3) revert last change in 49221 and change it the way that <export> is
generated only when there is one output jar produced by the same
script/type/build-target. This solution has one disadvantage: if user
customize project.xml by hand to contain multiple <export> sections
with the same script/type/build-target then they will have #1 
performance problem again. And it is not said anywhere that they
should not do that. Variation of this solution is to generate <export>
only for the first jar. This might look like bug to end user and I
would rather not do that.

I prefer #1 or #2.
Comment 10 herkules 2004-10-13 13:54:04 UTC
#2 sounds ok for me


<rant>
Hey guys! Please leave at least one way open for me to build my
project with NB! NB4 makes it already *very* hard and cumbersome!
PLEASE don't force me to change my favorite IDE!
</rant>
Comment 11 Jesse Glick 2004-10-13 17:36:20 UTC
#2 is fine.

Joerg - there should be no real problem once you know about this
issue; just add the other JARs using the "Add JAR" button if you need
to, rather than "Add Project". Sorry for the inconvenience.
Comment 12 David Konecny 2004-10-15 15:03:54 UTC
I filed separate issue 50484 for next version to address multiple jars
per AA.

Fixed in:
src/org/netbeans/modules/ant/freeform/ArtifactProvider.java;
new revision: 1.2; previous revision: 1.1
test/unit/src/org/netbeans/modules/ant/freeform/ArtifactProviderTest.java;
new revision: 1.2; previous revision: 1.1
Comment 13 Marian Mirilovic 2005-12-20 15:47:18 UTC
This issue was solved long time ago. Because nobody has reopened it neither
added comments, we are verifying/closing it now. 
If you are still able to reproduce the problem, please reopen. Thanks in advance.