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 46380 - Can only add project dependency if other project produces jar file
Summary: Can only add project dependency if other project produces jar file
Status: RESOLVED INVALID
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks: 41537
  Show dependency tree
 
Reported: 2004-07-21 12:18 UTC by tboerkel
Modified: 2004-08-13 12:11 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tboerkel 2004-07-21 12:18:10 UTC
I am trying to add a dependency to another
project, where the other project does not produce
a jar file as result.
I am going to the first project's properties,
"Compiling Sources" and click on "Add Project".
When I choose the other project folder, it wants
to add that one's jar file.
Instead, it should just add the project and
(internally) add the second projects
build.classes.dir and all CLASSPATH entries from
the second project to the first project's
CLASSPATH (at the end).
Comment 1 psuk 2004-07-22 09:18:17 UTC
subcomp->project
Comment 2 _ ttran 2004-07-22 20:56:33 UTC
Interproject dependency is implied based on who uses artefact (jar)
produced by whom.  This is considered a feature not a limitation.

Jesse, this is as designed, correct?

Thomas: what you try to do is not what the IDE wants to support. 
Instead you should let the first project produces the jar and the
second project take that jar and the additional jars as its classpath
entries.
Comment 3 tboerkel 2004-07-22 21:23:35 UTC
That does not make sense IMHO. Why should I be forced to produce a
jar, only to be able to use dependency? 
We have 2000 classes in the sub project. Generating a jar file every
time I build, takes too long and is completely unnecessary. We only
generate a jar file for distribution, that is once a year. Otherwise
we do not need a jar file, because the classes dir is in the CLASSPATH.
Comment 4 _ ttran 2004-07-22 21:43:39 UTC
how much time it takes to create a jar?  How it compares to the
compilation time?

Anyway I suggest you to go to nbusers mailing list and ask for
opinions from other users.  If there are enough people who share the
same need like yours, we will consider implementing this in a future
release
Comment 5 Jesse Glick 2004-07-22 21:59:44 UTC
Removing comma to clarify summary - previous version meant something
completely different and nonsensical in English. :-)

Simple workaround: give the 'jar' target in the subproject an empty
body, and include the build/classes/ dir (rather than the dist/*.jar)
of the subproject in the superproject's classpath.
Comment 6 tboerkel 2004-07-23 10:42:08 UTC
Jesse: 
Your workaround works. I think in some earlier NB 4.0 version, I could
not add the dependency if the jar did not exist.

Trung:
Clean&Build without jar file: 35 seconds
Clean&Build with jar file: 1 minute 27 seconds
NB puts not only the project classes in the jar file, but also other
jars (3rd party) from the classpath and also the sources (src and
class dir are identical here). 
I'll file a new issue about this. But without the sources, it would
still take significant time to build the jar.
Comment 7 _ ttran 2004-07-23 16:36:11 UTC
> NB puts not only the project classes in the jar file, but also other
> jars (3rd party) from the classpath and also the sources (src and
> class dir are identical here). 

weird.  Which project type(s) are you using?
Comment 8 Jesse Glick 2004-07-23 18:18:32 UTC
The comments about the JAR including too much were filed separately
and also closed as invalid; probably user error in the build script.

Normally creating a JAR from *.class files is at least an order of
magnitude faster than compiling them, so the overhead is not very
noticeable, though of course for large projects used over the course
of months it may be worthwhile to optimize out this step.