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.
1) Install Netbeans 6.0 2) Import the existing 5.5.1 CDC project 3) Open project in 6.0. 4) It doesn't have the source path, since it appears to be pulling from a single source. We have our existing shipping code base in 5.5.1 netbeans CDC projects. We have source code from multiple paths on very old code bases. Aren't in the position to restructure the code to be in a single path. This is a project killer for us. We want to upgrade to new versions of Netbeans, but can't because of this limitation. We are working with SUN on a CVM for our device and using Netbeans as the IDE for the emulator releases.
Example of paths: \phone\generation3\src\ \phone\generation4\src\ \phone\common\src\ It will not import a project that uses code in all three paths. Netbeans expects the source to all be in the same \generation path.
assigning directly to psuchomel based on customer request
I am tracking this issue for time and I am aware of this problem. Not sure how quickly is this fixable, for sure not 6.5, but possibly in patch or next release. Decreasing to P2 as far as this bug is hitting only small number of users with specific setup. Thanks for filling the issue.
Should go to 7.0
Question for chawes: Will it be usable for you if we - Do support multiple source roots for 7.0, BUT - Source roots have nothing to do with configurations, but are global - in other words, if you want to exclude a source root from one configuration, then they must not share packages if you want to exclude an entire package from one source root; and if the same file exists in two source roots, you cannot choose which root it comes from? As long as the only reason you want multiple source roots is because you have existing sources which are that way, we can probably make that work. But if you want to, say, have one device's code come from one source root, and another device's include a different source root, *and* some of the paths to files or folder inside the two roots are the same, I'm not sure if we can deliver that. Here is why: - Mobility has a concept of filtering, which you can use to filter things out, BUT - That filtering happens with the .class file output from the build - once there are .class files there is no practical way to tell which source root they came from (if it is possible that there are two versions of the same class in two source roots) - If we try to support multiple source roots where the collection of source roots is associated with a configuration, we quickly run into a combinatorics problem: The project.properties will need to contain source-root-count * configuration-count properties to handle all of the filtering possibilities. It is possible, but such a change is extremely high risk for everyone with existing J2ME projects. It might be possible to do it differently and associate multiple source roots with configurations at the compilation stage - i.e. it affects the sourcepath of the compiler; that would get us around some of the problem, perhaps.
Created attachment 74155 [details] Latest patches to support multiple source roots - plenty more to do though
Created attachment 74188 [details] Latest patches to support multiple source roots - plenty more to do though
CHawes emailed: > Sorry this took so long to reply... > > With your proposal, this would fail: > > /root/src/g3/Type.java > /root/src/g4/Type.java > /root/prj/g4/G4Type/nbproject > > Where the g4 netbeans project would be using Type.java from the g4, but > the existence of the same name in g3 in the root would make it fail? > Even though it would never be compiled or included in the g4 project? Basically yes. g3/Type.java would get compiled into build/classes. Then g4/Type.java would get compiled and clobber g3/Type. Actually the order they are in in the compilation classpath would determine which one you would get. *That* I have more-or-less working (still a bit of things to do, and since a lot of code in mobile projects relies on reading "src.dir" from nbproject/project.properties I'm sure I've missed some cases where I still need to modify the code to look for "src.a.dir", "src.b.dir" and not assume there is only one source dir). Basically, the build system is pretty pluggable and expects to be able to hand off the results of one stage of compilation to another. So just having a bunch of source dirs that all get compiled into build/classes is fine - everything else can work with that result unchanged. If source dirs were associated with configurations (i.e. Configuration A owns $PROJECT/a1-src and $PROJECT/a2-src and $PROJECT/common, and configuration B owns $PROJECT/b1-src and $PROJECT/b2-src and $PROJECT/common, we're starting to talk about *massive* changes to the infrastructure, plus the combinatorics issues I mentioned, with high risk of both bugs and destabilizing other people's projects which would have to be migrated to the new build scripts and infrastructure to support all of this. I.e. a long, hundreds of man-hours project to make this work at the end of which could lie disaster. Now, there are ways to do what you want to do with the existing infrastructure today - i.e., separate packages for genA and genB, and filtering which packages go with which configurations (if you want the end result to be in the default package, obfuscation can do that for you). But basically, what I can probably give you for 7.0 is what I described above, and it does fail for the src-a/Type.java src-b/Type.java scenario.
Tim, any feedback from Cisco on this?
Can't get source code, but I did recently get a clear description of how to set up a similar config by email.
I suspect all related issues are now resolved - if not, please reopen this issue with justification and additional info. Thanks.