Source organisation woes

I'm having trouble understanding the benefits of the new way of organising the source code, as opposed to the source and project directory paradigm of previous IDEA versions. Specifically, I don't see how the following (which was very easy to do in IDEA 3.0) is possible without a major hassle in Aurora:

I have a package, heggland.reuse, containing classes I use in several of my projects. I want to be able to edit these classes from all my projects that use them. When I make a release build of a project, I want only the heggland.reuse classes that are actually used in the project, to be compiled to the output path.

This is easy in IDEA 3.0. I use the same source path for all my projects, and just add heggland.reuse to the project paths. When making the release build, I remove heggland.reuse from the project paths; the classes I use are compiled anyway.

In Aurora, I don't see how this is possible. If I want to share heggland.reuse between projects, it seems I have to put the package in its own separate directory, apart from my other heggland.* packages, which is a bit of a pain - now my code is all over the place, instead of in a single neat hierarchy. But I can't figure out how to make IDEA build the project like I want to, compiling just the necessary heggland.reuse classes. Compiling the main class compiles only the dependencies, but then resources aren't copied, so that doesn't help.

Do I have to use a build tool? Or have I misunderstood how Aurora wants me to use projects? I'm sure the new source code organisation scheme is supposed to be an improvement, but I'm afraid I don't see a single benefit. Can anyone make me see the light?

3 comments

Jon,

Although it is not exactly the same issue, I've raised somewhat the same concerns in http://www.intellij.net/forums/thread.jsp?forum=22&thread=51598&tstart=15&trange=15.

I have problems with, what seem to me, to be requirements on the source directory structure also and would love to see some configurability in or modification of the module paradigm.

Although the above link has some alternatives that might be able to help you - I'd prefer to see some sort of response from JetBrains...

Wish us luck :)

0

Although it is not exactly the same issue,


It's the same, it's just our reasons for complaining that are slightly different. :)

and would love to see some configurability in or
modification of the module paradigm.


Agreed. I'd be happier if someone could just explain what the benefits of the new paradigm is. I'm all for separation of test code and regular code, but that you could do easily with the old system as well. To me, the new system is a pure downgrade.

Although the above link has some alternatives that
might be able to help you - I'd prefer to see some
sort of response from JetBrains...


I've voted for the bug, at least.

0

At present, I would say that the benefits are subtle, but I can see them getting more real. Beyond simply adding another level of logical grouping, I see three main payoffs.

1)Dependency enforcement. The new system will prevent dependencies on high-level modules from sneaking into low-level modules. No circular module dependencies is a very good thing. Segregation of third-party library dependencies is also very nice.

2)Quicker testing cycles on low-level modules, since you don't need to rebuild the entire project to test a module, just that module and it's dependencies.

3)New high-level modules may be in an uncompilable state, but that won't prevent people from working with other modules.

Not huge benefits, but nothing to sneeze at either.

0

Please sign in to leave a comment.