Bug 47507 - [40cat] Transitively required libraries not automatically added to runtime classpath
[40cat] Transitively required libraries not automatically added to runtime cl...
Status: NEW
Product: java
Classification: Unclassified
Component: Project
4.x
All All
: P2 with 17 votes (vote)
: TBD
Assigned To: Tomas Zezula
issues@java
prj-ui-cand, OSLO
:
: 47493 47799 55089 59357 61176 79404 80618 96526 99569 121610 124842 133442 140382 142962 162337 180686 186208 195336 241265 (view as bug list)
Depends on: 70076
Blocks: 41537 47089 52273
  Show dependency treegraph
 
Reported: 2004-08-19 18:38 UTC by llturro
Modified: 2014-03-27 22:51 UTC (History)
19 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
dup in web folder (7.96 KB, image/png)
2004-12-03 11:08 UTC, llturro
Details
dup in build folder (7.26 KB, image/png)
2004-12-03 11:08 UTC, llturro
Details
dup in project view (8.93 KB, image/png)
2004-12-03 11:09 UTC, llturro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description llturro 2004-08-19 18:38:39 UTC
[ BUILD # : 200408121535 ]
[ JDK VERSION : J2SE 1.5.0 ]

Suppose this scenario:

Project Lib requires project SubLib.
Project App requires project Lib.

App -> Properties will show on Required Projects:
Lib
SubLib

But SubLib wont be added in runtime classpath. You are forced to 'Add [SubLib] Project' to App, despite it was already detected as a 'required project'
Comment 1 Jesse Glick 2004-08-19 18:45:25 UTC
You need to explicitly add whatever you need to the runtime classpath.
"Required Projects" is just a summary of related projects that will be
opened together with this one; it does not correspond directly to
anything in the project's build or run semantics.

Might never fix for j2seproject's since there is no defined packaging
standard for them. A technology with a well-defined packaging and
aggregation notation, such as Java WebStart, could handle this cleanly.
Comment 2 Jesse Glick 2004-08-19 18:53:47 UTC
Note that it is intentional that SubLib is not in App's *compile*
classpath - you may well not want it to be, if it is only used
"privately" inside Lib and not "exported". Might additionally be nice
to have an option to export SubLib from Lib, or from the other
perspective to pick up Lib's complete classpath in App. Not the same
issue as the runtime classpath, however.
Comment 3 llturro 2004-08-19 19:02:51 UTC
Ok, then there is something unclear to me. In ClassPath for Running
Project, one of the options reads 'ClassPath for Compiling Sources'.
Well, when I click on Build & Clear it will build and clear App, Lib
and SubLib. How can it be that clicking on Run will not run? Maybe
'ClassPath for Compiling Sources' should read 'ClassPath for Compiling
Sources except subnested projects'? Don't you think is one defect?
Comment 4 llturro 2004-08-19 19:05:47 UTC
Jesse, I posted before reading your last comment. SubLib is included
in App's compile classpath!!! The problem is not in App's runtime
classpath.
Comment 5 llturro 2004-08-19 19:23:48 UTC
Correction to the last post: The problem is IN App's runtime classpath.

I just re-assigned project dependencies and tried it once more. It
Cleans and Builds, but doesn't Run.
Comment 6 Jesse Glick 2004-08-19 19:53:36 UTC
The compile-time classpath for App probably contains just Lib, not
Sublib - unless you explicitly added Sublib. The runtime classpath is
normally a superset of the compile-time classpath; you can explicitly
add further items you do not need to compile against (e.g. JDBC
drivers or JAXP implementations, or a subsubproject as in this case).

When you select Clean & Build, all recursive subprojects are built in
turn.

"Maybe 'ClassPath for Compiling Sources' should read 'ClassPath for
Compiling Sources except subnested projects'?" - not sure what you're
getting at. It is exactly what it says - the classpath used when
compiling sources in this project. Nothing more nor less.
Comment 7 llturro 2004-08-20 10:01:03 UTC
Adding JDBC, JAXP and the like I do using Library Manager. I'm talking
about Projects. You want me to understand the interiors, something I
could only try at much, to excuse an unclear project behavior. I lost
time before I understood SubLib existed as required project, I could
clean and build, but was missing in runtime classpath. Your projects
are too a good thing to have this missing.
Comment 8 Jesse Glick 2004-08-20 17:22:00 UTC
Simplest and safest improvement I can think of: when customizing
compile-time classpath of j2seproject A by adding B (j2seproject only?
or any project?), if B contains some (transitive) subproject C (again,
j2seproject only, or any project?) which is not already in either the
compile-time or run-time classpath for A, prompt the user:

1. Just add B. (Current behavior.)

2. Add B, and also add C to the compile-time (and thus implicitly also
run-time) classpath. Suitable if C is "exported" by B.

3. Add B, and also add C to the run-time classpath only. Suitable if C
is "privately used" by B.

This choice would need to be presented for each such C.

If adding B to the run-time classpath, choice #2 would be skipped; the
user would just be prompted to also add C to the r/t classpath.

Of course this would not prompt you to readjust A's classpath should
B's classpath change to not include C (or to include a new C2), but it
would at least handle many situations correctly, and alert the user in
an appropriate context to the possibility of making this kind of
adjustment.

Need some clarification on border cases - applicable only to
j2seproject subprojects, or any subprojects? If j2seproject
subprojects only, it is possible to know *how* B is using C - whether
it is using it in the c/t or only r/t classpath. (If the latter, would
skip choice #2 even if adding B to A's c/t cp.) If any subprojects,
then you only know "C is a subproject of A", no more.

Jano should something like this be considered for 4.0? We are long
after UI freeze of course, but it would be a reasonably simple dialog
that might improve usability in the case of complex project
dependencies (and discoverability of the distinction between c/t and
r/t cp's and their use). Might be able to get an exemption for it.
Comment 9 llturro 2004-08-20 18:10:37 UTC
Here I'm bothering again. I found two more things involved in this issue:

1) Code completion don't see SubLib.
2) SubLib.jar isn't copied to WEB-INF/lib folder on web applications.

Comment 10 Jesse Glick 2004-08-20 19:08:15 UTC
Re. code completion on SubLib - will be there if you add it to the
compile classpath of App. If you don't, you will not have code
completion on it - this is intentional.

Re. web apps - don't know anything about it, please file a separate
issue (component 'web').
Comment 11 llturro 2004-08-23 19:33:11 UTC
I think I understand your point of view and I agree is desirable to
have some freedom at the moment to include, or not, libraries. It was
not my original point when I started this issue. I was refering
exclusively to projects. Those ones get opened along with the 'main
project' when 'Open required projects' is checked. Libraries wont show
on project's view, but required projects will do, so you have to agree
there is a difference. Maybe that's the reason you send me to webapp
regarding to web application's reference, but to me is much of the
same problem. Why do they open if they wont finally be included in
runtime?
Comment 12 Jesse Glick 2004-08-23 20:39:04 UTC
I *am* talking about projects, not libraries.

The list called "Required Projects" does not really mean much; does
not correspond to anything in the main project's behavior as such.
There is no implication that they will all be used in the main
project's runtime classpath, etc. It is simply a recursive
(transitive) list of projects by "project dependency" relationship,
which will be opened if you keep that checkbox checked, on the
assumption that you may be interested in editing them. (If not, don't
bother opening them.)

For j2seproject's, a direct project dependency occurs when one project
is used in at least one of another project's classpaths (compiling,
running, or compiling tests), and means that the subproject will be
built before the main project is built. Other kinds of projects may
assign different meanings to the project dependency relationship: e.g.
an EAR project (when EJB support is added) will have as subprojects
web apps and EJB-JARs, and the web apps may have as subprojects tag libs.
Comment 13 zikmund 2004-08-24 09:54:14 UTC
I have been thinking of similar enhancement for a week.
I concluded that 'best solution' would be like Jesse's #3, but not
adding C to A's r/t cp - better could be offer adding of whole B's r/t
cp as subset of A's r/t cp. This would avoid problems of
synchronization when you change B's r/t cp.
Comment 14 Jesse Glick 2004-08-24 17:24:41 UTC
*** Issue 47799 has been marked as a duplicate of this issue. ***
Comment 15 athompson 2004-08-24 17:48:47 UTC
since i would guess that in most cases people would want 'C' added to
the runtime classpath, perhaps an 'opt-out' strategy is in order. if
'B' is added as a dependency to 'A', then all of B's dependencies are
recursively added to the runtime classpath of A as separate entries
(sort of like an automatic option 3). users that do not want them in
the compile time path can manually remove them if they like. i think
it's best to have the extra step in the remove case because it will
probably be less common.
Comment 16 athompson 2004-08-24 17:50:11 UTC
correction:

users that do not want them in the *run* time path can manually remove
them if they like.
Comment 17 Jesse Glick 2004-08-25 00:18:42 UTC
Re. inclusion of B's r/t CP as a portion of A's - probably not
possible, sorry.

Re. other suggestions - plausible, but will not do them for 4.0.
(Anyway you would not have synchronization after changes in CP of
subprojects without a rather more complex system.)

Will just remove "Required Projects" from the customizer dialog as it
is more misleading than helpful.
Comment 18 David Konecny 2004-08-26 12:22:34 UTC
"Will just remove Required Projects from the customizer dialog as it
is more misleading than helpful." - done. Checkbox "Build Required
Projects" was moved to compilation panel and renamed to "Build
Projects on Classpath".

Done in:
src/org/netbeans/modules/java/j2seproject/ui/customizer/Bundle.properties;
new revision: 1.31; previous revision: 1.30
src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerCompile.form;
new revision: 1.7; previous revision: 1.6
src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerCompile.java;
new revision: 1.10; previous revision: 1.9
src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerGeneral.form;
new revision: 1.7; previous revision: 1.6
src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerGeneral.java;
new revision: 1.12; previous revision: 1.11
Comment 19 Milan Kubec 2004-08-30 15:30:15 UTC
Removing of list of Required Projects - verified.
Renaming of checkbox - verified.
Both in dev-200408291800.
Comment 20 Petr Jiricka 2004-09-01 17:52:05 UTC
Sorry, so what remains from this enhancement? What additional changes
are still required? I am getting lost. Thanks. 
Comment 21 Jesse Glick 2004-09-01 19:55:52 UTC
The whole issue is still valid (though whether it should ever be
solved in j2seproject, as opposed to e.g. a Web Start project type, is
an open question). All we did for 4.0 was remove the display of
"Required Projects" from the properties dialog on the grounds that it
misleadingly implied that all of those projects would actually be in
your runtime classpath, which is not necessarily the case.
Comment 22 David Konecny 2004-09-06 14:14:02 UTC
*** Issue 47493 has been marked as a duplicate of this issue. ***
Comment 23 Jesse Glick 2004-10-04 20:28:56 UTC
Possible fix: define a property to project.properties called
'run.classpath.transitive'. Add ${run.classpath.transitive} to the
definition of 'run.classpath'. When the project is opened and
run.classpath.transitive is defined, go through all entries in the
evaluated version of ${run.classpath} - ${run.classpath.transitive},
try to map them back to sources (SFBQ), then find ClassPath.EXECUTE
for each. Update run.classpath.transitive to be those entries in the
union of those ClassPath's which are not present in ${run.classpath} -
${run.classpath.transitive}.

Attach listeners to those ClassPath's and also to ${run.classpath} and
maybe to the SFBQ's, so that run.classpath.transitive always reflects
the correct value, even if you e.g. change the configuration of
subprojects. Should be listening to changes only while the project is
open.

For purposes of upgrade, if there is no run.classpath.transitive in
project.properties, create it and add to run.classpath. Otherwise do
not add it (in case the user intentionally removed it in
project.properties).

The GUI should show a new entry in the runtime CP customizer, "Runtime
classpaths of subprojects" (or something like this); should not be
removable, I guess.

Should also make sure that the CP customizer shows tooltips or
something making it clear what is going into this classpath, so things
are more transparent.

Could that work?
Comment 24 Jesse Glick 2004-10-19 19:36:39 UTC
Was this intentionally not buildsys-e-cand?
Comment 25 llturro 2004-12-03 11:08:14 UTC
Created attachment 19121 [details]
dup in web folder
Comment 26 llturro 2004-12-03 11:08:41 UTC
Created attachment 19122 [details]
dup in build folder
Comment 27 llturro 2004-12-03 11:09:06 UTC
Created attachment 19123 [details]
dup in project view
Comment 28 llturro 2004-12-03 11:10:32 UTC
Sorry, those screenshots were intended for another issue... ufff!
Comment 29 David Konecny 2005-01-24 13:46:14 UTC
Tomas, moving java project specific issues to you for now.
Comment 30 Jesse Glick 2005-04-05 00:44:32 UTC
*** Issue 55089 has been marked as a duplicate of this issue. ***
Comment 31 Jesse Glick 2005-05-31 18:14:12 UTC
*** Issue 59357 has been marked as a duplicate of this issue. ***
Comment 32 Jesse Glick 2006-02-03 16:50:31 UTC
*** Issue 61176 has been marked as a duplicate of this issue. ***
Comment 33 jillesvangurp 2006-02-07 11:03:06 UTC
I was about to report this as a bug for netbeans 5.0 but then I found this bug.
As I understand it, the autocomplete classpath is intentionally different from
the compile classpath?

I have valid, compiling (actually working) code. If I do a alt+f (fix imports) I
get an error about a class that can't be found. The class is indeed in a library
dependency of a library on the project. Autocomplete doesn't seem to be working
either for this class. However there are no red lines for compile errors (which
is correct) if I add the code manually. 

I don't see why the autocomplete classpath should be anything else then the
compile classpath. 
Comment 34 Jesse Glick 2006-02-07 15:25:31 UTC
jillesvangurp: whatever problem you're having sounds unrelated and should
probably be filed separately with details to reproduce from scratch if at all
possible.
Comment 35 Jesse Glick 2006-06-29 16:05:28 UTC
*** Issue 79404 has been marked as a duplicate of this issue. ***
Comment 36 John Baker 2006-06-29 20:03:31 UTC
What's the status of this ?

Since there have been many duplicates filed, we need a solution

This proposal would work for me:
"Possible fix: define a property to project.properties called
'run.classpath.transitive'. Add ${run.classpath.transitive} to the
definition of 'run.classpath'. When the project is opened and
run.classpath.transitive is defined, go through all entries in the
evaluated version of ${run.classpath} - ${run.classpath.transitive}"

Thanks
Comment 37 Tomas Zezula 2006-06-30 13:17:12 UTC
I doubt it will work, it will affect head less build since it depends on the
project open in the IDE.
Comment 38 Jesse Glick 2006-06-30 14:07:46 UTC
The headless build would not depend on the project being open. It just means
that *changes* to subproject classpaths would not propagate into the
superproject's classpath unless they were made through the IDE, with the
superproject open. You would need to be careful to ensure that if a subproject
depends on a library that the dep in the superproject is given as a library dep,
not a raw JAR dep, so that the path could be overridden consistently in a
headless build.

The root problem BTW is that Ant does not really permit the superproject to call
the subproject's property evaluation as a subroutine and collect the results. It
would be possible (by writing and reading named .properties files) but complex,
probably inefficient, and hard to make work across different project types.
Comment 39 rmatous 2006-07-19 14:58:04 UTC
*** Issue 80618 has been marked as a duplicate of this issue. ***
Comment 40 Jesse Glick 2006-12-09 16:15:38 UTC
See also issue #51052 re. deps among libs.
Comment 41 Jesse Glick 2007-02-26 19:11:42 UTC
*** Issue 96526 has been marked as a duplicate of this issue. ***
Comment 42 Jesse Glick 2007-04-03 03:00:02 UTC
*** Issue 99569 has been marked as a duplicate of this issue. ***
Comment 43 Jesse Glick 2007-10-26 19:15:41 UTC
*** Issue 120220 has been marked as a duplicate of this issue. ***
Comment 44 Tomas Zezula 2007-11-14 14:55:33 UTC
*** Issue 121610 has been marked as a duplicate of this issue. ***
Comment 45 Jesse Glick 2008-01-09 22:14:47 UTC
*** Issue 124842 has been marked as a duplicate of this issue. ***
Comment 46 fommil 2008-01-09 23:34:25 UTC
There doesn't seem to be much activity on this RFE. In the last 2 years dupe after dupe has been added (there are more dupes than votes! buggy issue 
tracker...)

Are there any plans to add this essential feature in upcoming releases? Most of the competing IDEs have this as it is necessary for codebases with library 
projects.
Comment 47 athompson 2008-01-10 14:51:56 UTC
this is a p2
Comment 48 athompson 2008-01-10 14:54:42 UTC
at this point, though, you may want to consider completely integrating Maven.
Comment 49 fommil 2008-01-10 20:48:41 UTC
Just so that it is here with the bug report... my workaround is that for every "project" I define a library in the Library Manager called "library.dep". Here is 
where I define the classpath, sources and javadocs for that project's dependencies.

Then if another project ever depends on "project", I add "project.dep" to its runtime (and test runtime) dependencies. This is an unsatisfactory solution 
because the Library Manager is a local definition and cannot be shared across a team, much more so in this hack because "project.dep" is not particularly 
descriptive and may change without developers realising. It also requires effort to add this dependency to the runtime paths.
Comment 50 fommil 2008-03-20 21:55:52 UTC
This is a P1 but nobody has assigned it to a milestone yet... anyone care to comment on if they think this will make 7.0?
Comment 51 fommil 2008-03-21 00:31:40 UTC
(sorry, meant P2, not P1)
Comment 52 Tomas Zezula 2008-03-23 10:18:11 UTC
For 7.0 it should be doable, unfortunately there is no milestone for 7.0 yet. It was not doable for 6.1 release which is rather bug fixing release containing 
already lots of new features.
Comment 53 Tomas Zezula 2008-04-21 16:10:37 UTC
*** Issue 133442 has been marked as a duplicate of this issue. ***
Comment 54 Jesse Glick 2008-11-07 03:30:30 UTC
*** Issue 140382 has been marked as a duplicate of this issue. ***
Comment 55 Jesse Glick 2008-11-07 03:33:27 UTC
*** Issue 142962 has been marked as a duplicate of this issue. ***
Comment 56 malfunction84 2009-01-30 16:17:10 UTC
Now that there are 7.0 milestones, can someone assign a milestone?  I would love to see this in 7.0.
Comment 57 David Konecny 2009-04-21 00:12:14 UTC
*** Issue 162337 has been marked as a duplicate of this issue. ***
Comment 58 cumberland 2009-09-13 18:50:30 UTC
Well, i just spend a lot of time searching the web, before realising that this (in my opinion) essential feature is
indeed missing. What's the point of including another project as dependency but additionally having to reference all of
its libraries by hand. Doesn't this kind of behaviour defy the whole notion of the concept of dependent projects?
I know there are workarounds but they are all kind of ugly and clutter up my projects.
Why not handle it more like the way eclipse does it? Looks a lot more thought through to me. 
Comment 59 Jesse Glick 2010-02-13 10:40:24 UTC
*** Bug 180686 has been marked as a duplicate of this bug. ***
Comment 60 Tomas Zezula 2010-05-27 13:53:11 UTC
*** Bug 186208 has been marked as a duplicate of this bug. ***
Comment 61 Dusan Balek 2011-02-16 14:39:29 UTC
*** Bug 195336 has been marked as a duplicate of this bug. ***
Comment 62 ebresie 2011-02-22 17:22:00 UTC
Any update on this?
Comment 63 Jesse Glick 2011-02-25 04:00:51 UTC
Users needing nontrivial dependency management facilities are advised to use Maven projects.
Comment 64 robertmcauliffe 2012-01-12 13:06:00 UTC
So, the answer to transitive dependencies is "use maven"??? Huh? If you have more than two projects with transitive dependencies in anything like a professional environment, you need this kind of feature, otherwise it becomes too hard to maintain.  OK, so using maven is a solution, but so is using Eclipse (which I'd rather not go to).

I really like the ant-based NB build system and I'm not sure I want to give it up just to get this feature.. :(
Comment 65 Tomas Zezula 2012-01-12 13:16:39 UTC
Unfortunately it's not easily doable with Ant.
See Jesse's comment #38
Comment 66 kawazu428 2012-01-12 13:19:21 UTC
So far I have yet to find any working solution to this problem that does not involve maven. Done it in Eclipse using Eclipse projects and got toasted the very moment another developer tried to check out and build the project on his machine without having most of the dependencies attached to Eclipse projects (via variables, local file system references, ...) available. So from this point of view, the recommendation to use maven seems fine in both Eclipse and NetBeans.
Comment 67 robertmcauliffe 2012-01-12 13:58:57 UTC
1: In response to #38 then:

Here I'm going to show my ignorance of the nuances of Ant, but could a target be added to the build file that output the classpath somehow (even if it meant writing a properties file somewhere temporary?) that the consuming project could then read?

2: On the basis of this being lots of work, is perhaps first-class Ivy integration lower fruit? If so (and depending on specific features, for example refactoring working across dependant projects - at least optionally), this would be a better solution IMHO than having to switch to Maven...

Background:
-----------

For context, and perhaps I'm unusual here, I tend to have a regularised workspace (all developers having the same layout) for related projects where all dependant projects are checked out into the same parent directory and I work on them all simultaneously.  This is handled through Maven/Ivy or by Eclipse project dependencies fine, with the downside for Maven/Ivy of requiring a build/refresh cycle to access the changes to dependency projects.

For example, I might have a product that is composed of projects {A,B,C,D,E} where I have dependencies: {B->A,C->A,D->B,D->C,E->A} perhaps D and E are separate deployables.  I might even have other dependencies like F->A or something in my suite of projects, but I don't really care for this product. 

For this example, I'll setup my workspace as /projects/[A..E] and develop on them all in parallel.  I find it unusual to have a (even mature) dependancy (like A above) without needing to change *something* while changing the product, so I'll need to propagate refactorings and plain code changes easily between these projects.

Because I check out all the projects, I'm happy to have the IDE assume that they're there; but even if it didn't if it took extra advantage *if* they were there, that would benefit me equivalently.

So, the current state of play is Maven or Ivy (Eclipse only) or Eclipse projects. Eclipse projects are a bit nasty in general when you need to build on a build server, so that leaves Maven or Ivy (with a possible manually configured Eclipse project structure to make it work better).

Out of these three options, only Maven works with NB, but having had too much of my development time wasted by Maven's finicky nature, I'd rather play in the Ant-Ivy space for now... until something better comes along.

So, in short, I'd *like* to use Netbeans for this (as I prefer it), but it's a bit hard to sell to others when it's either "switch to Maven" or "maintain deps by hand".

[/rant]
Comment 68 Jesse Glick 2012-01-12 16:37:21 UTC
(In reply to comment #67)
> could a target
> be added to the build file that output the classpath somehow (even if it meant
> writing a properties file somewhere temporary?) that the consuming project
> could then read?

That is basically the approach I suggested at the end of comment #38.

> is perhaps first-class Ivy integration lower fruit?

That fruit would be juicy but it is at the top of the tree, I think - certainly more of a commitment than implementing this RFE. You can look at [1].

> refactoring working across dependent projects

Probably nothing special needs to be done for that.


[1] http://code.google.com/p/ivybeans/
Comment 69 robertmcauliffe 2012-01-13 01:38:08 UTC
Jesse, Thanks for responding - sorry I clearly didn't read your comment closely enough.  

I did look at that IvyBeans project, but it is not up to date for 7 yet.  I may yet investigate further if that's my only option currently. This doesn't seem to be an 'official' Netbeans project - are there any plans to bring it into the fold?

In terms of the difficulty of implementing/performance, these are problems that obviously come up with any feature being added to an application. Is this more a matter of priorities then? I'm just noticing that this has been an issue since [40cat] in '04, that's a long time for something fairly fundamental to wait. Of course, I'd anticipate that there have probably been more important issues?

In which case, is there anything we can do about it?
Comment 70 _ tboudreau 2012-01-13 06:09:02 UTC
> could a target
> be added to the build file that output the classpath somehow (even if it meant
> writing a properties file somewhere temporary?) that the consuming project
> could then read?

I did some experiments with something like this a few years ago (and I'd guess that Jesse's automatic projects do something similar):  Invoke Ant programmatically and programmatically add a target which collects the closure of the dependency's classpath (and does the same recursively for its dependencies);  it would be easy enough to keep a cached copy of that information tied to a hash of the build files if necessary.

Having used it a little bit (Ivy, not IvyBeans specifically), I wouldn't waste time with Ivy.
Comment 71 Jesse Glick 2012-01-13 11:25:12 UTC
(In reply to comment #69)
> I did look at that IvyBeans project, but it is not up to date for 7 yet.

[1] says otherwise as of today! (I have no experience with this plugin.)

> This doesn't seem to be an 'official' NetBeans project -
> are there any plans to bring it into the fold?

I do not know of any plans.

> Is this more a matter of priorities then?

Yes, no one has gotten to working on it yet. While it affects a lot of people, you can always add transitive dependencies to the runtime CP by hand, and people with large multimodule projects often use Maven anyway.

(In reply to comment #70)
> I'd guess that Jesse's automatic projects do something similar

No, autoprojects [2] just watch how a user's build script actually calls <javac>. If that script somehow implements transitive dependency management, whether manually or via a tool like Ivy, then the IDE's editor keeps up.


[1] http://code.google.com/p/ivybeans/#20110113_:_1.2_released
[2] http://wiki.netbeans.org/AutomaticProjects
Comment 72 Tomas Zezula 2012-01-13 12:56:28 UTC
As far as I know this enhancement is not planed.
Tim you will need to have a MD5 or some other hash of project.properties + private.properties (or evaluated javac.classpath) of all dependent projects. It has significant performance impact on the java support. The problem is that the transitive classpath is needed not only by build but also by java.source (editor and any java feature). When there is no such a cache or the cache is invalid the call of ClassPath.entries() will need to execute the Ant script to reevaluate this transitive props. The CP.entires() should be fast and is allowed to be called from EDT. It's used for example by code completion, navigation, etc.
Comment 73 athompson 2012-01-13 16:12:41 UTC
(In reply to comment #69)
> In terms of the difficulty of implementing/performance, these are problems that
> obviously come up with any feature being added to an application. Is this more
> a matter of priorities then? I'm just noticing that this has been an issue
> since [40cat] in '04, that's a long time for something fairly fundamental to
> wait.

<rant ignorable="true">
I honestly don't have much interest in this bug (and I'm not a Netbeans developer) but I can't resist chiming in.  It's not fair to imply that a "fundamental" feature such as transitive deps is "low priority".  The fact is, it *was* a high priority and the netbeans developers implemented it through the use of Maven projects.  So please keep the rhetoric somewhat honest; if anything is low priority, it's implementing transitive deps using a second mechanism when the original mechanism is perfectly adequate.
</rant>

Just out of curiosity (serious question): why do you prefer the "classic" ant-based netbeans project format over the Maven version?  I've been using the Maven version exclusively for years now and I've found it to be better in most respects.
Comment 74 _ gtzabari 2012-01-14 05:10:31 UTC
athompson,

<rant>
I've also been using Maven for years. The ideas behind Maven are great. The implementation is crap. The documentation is horrible, typos in configurations cause silent failures (by virtue of the fact that Maven ignores unknown tags/attributes), and JNI support is nonexistent (try building a project that contains native code and see how far you get).

If you do everything "the Maven way" it works fine, but the minute you wonder off course it's extremely difficult to get anything done. You have to write your own plugin, with all the complexity that entails. Ironically, people recommend Ant for simple projects and Maven for more complex ones. I don't know about Ant, but in my experience Maven is very poorly suited for complex projects. I've spent weeks debugging problems with build scripts. It was a nightmare. And I've actually authored a few Maven plugins so I know more about its internals than most users.
</rant>
Comment 75 sandi_ro 2012-01-14 11:25:23 UTC
quote: "Force users to use use hammer instead of a fork and you will get the hammer thrown back at you. If you have lots of users you may not be able to escape all hammers!"

I vote for having both maven and ant and maybe other systems.  Users needs choices to build a solution that match their needs. 

Hammer here:
I dumped netbeans 2 years ago because of this lack of dependecy tracking based on ant which was (not sure if this still holds true ) the default build system for netbeans projects!
Comment 76 robertmcauliffe 2012-01-15 20:43:40 UTC
@athompson: really @_ gtzabari said most of it.  Although I would add that I think Maven takes the project model idea too far. It's very hard to stay inside the 'norm' for anything of significant complexity, and you end up configuring modules rather than defining a project model.

But really the clincher for me is that when you *do* have a problem, there tends to be only one possible solution (some switch on a plugin), and you end up searching the Internet for ages to find someone, *anyone* that has actually located that configuration </frustration>

To contrast, with Ant (as imperfect as it is) if you run into a problem, even if you can't find the 'proper' fix, you can still work around stuff by scripting in the build.xml

I should mention that I haven't actually used Maven for a few years - these are the reasons I ditched it back then.

So: project model = great, but implemented all too-encompassing, so IMO not worth it
    dependency management = great, but can use Ivy for that (assuming tool support!)

Also note that depending on the *kind* of tool support, Ivy can be a bit of overhead, so not worth it for small-ish project that still have transitive dependancies. Yes, in this case dependencies could be manually copied, but that's more work than strictly necessary.

Overall I can understand your comment; if Maven is considered good, then clearly NB's transitive support is also fine (and the Maven integration is excellent IMO).  It just requires buying into Maven too.
Comment 77 robertmcauliffe 2012-01-15 20:56:42 UTC
just saw this discussion on (roughly) ant vs ivy: http://stackoverflow.com/questions/318804/maven-or-ivy-for-managing-dependencies-from-ant
Comment 78 athompson 2012-01-16 16:32:58 UTC
Thanks for the comments, guys.  I guess my project layouts have all been fairly straightforward; I haven't had any problems with Maven (aside from dep conflicts), even when converting existing projects.

Maven does have an Ant plugin.  Why not have Maven handle the deps and attach Ant tasks to phases to handle the fancy stuff where Maven isn't a good fit?
Comment 79 Tomas Zezula 2014-02-03 09:56:11 UTC
*** Bug 241265 has been marked as a duplicate of this bug. ***


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