Major Modules problem

I have encountered some serious problem while using refactoring to clean up dependencies between modules:
I moved a class F from package f in module "foo" to package p in module "bar". "foo" depends on "bar", so classes in "foo" can access classes in "bar", but not vice versa.

However F had dependencies on another class G in f (I didn't notice that beforehand, because it wasn't in the "imports" section). Idea DID NOT WARN me that the move will break my code.

Even WORSE when I was moving class G also from f to p, Idea did not correct the broken references in F.

It seems that Idea treats references to a class F in a module that isn't accesible from the current module as "unknown" and having nothing to do with the F.
While this might be the pure and clean logic of module dependencies, this is far from pragmatic.

I am doing major refactorings in a large project and try to extract parts of a module to a new module. I have given up to use two modules in Idea, but now have two content roots in the same module. Basically I am now using ant to show any broken dependencies between both source roots and try to fix them in Idea. It's just not practically to let Idea detect thos broken dependencies by having two modules, though that could save me a lot of time.

I am not sure which tracker entries to file or even what to search for to check if they already exist.

6 comments
Comment actions Permalink

Stephen,

the concerns you raised are important indeed.
We will try to update at least the more important refactorings so that
they report module-dependency related problems in Pallada.
One problem is move of a package or directory.
It is rather impractical to scan all files in moved package/directory
for references that will become invalid after move.
IMO the good idea is to use "Analyze Package Dependecies" before large
package/directory move.

The second part of your message - that IDEA should be able to work with
broken dependencies - is trickier to address in the little time that is left
before Pallada release.

We definitely need to discuss that further.

Friendly,
Dmitry

Stephen Kelvin wrote:

I have encountered some serious problem while using refactoring to clean
up dependencies between modules: I moved a class F from package f in
module "foo" to package p in module "bar". "foo" depends on "bar", so
classes in "foo" can access classes in "bar", but not vice versa.

However F had dependencies on another class G in f (I didn't notice that
beforehand, because it wasn't in the "imports" section). Idea DID NOT WARN
me that the move will break my code.

Even WORSE when I was moving class G also from f to p, Idea did not
correct the broken references in F.

It seems that Idea treats references to a class F in a module that isn't
accesible from the current module as "unknown" and having nothing to do
with the F. While this might be the pure and clean logic of module
dependencies, this is far from pragmatic.

I am doing major refactorings in a large project and try to extract parts
of a module to a new module. I have given up to use two modules in Idea,
but now have two content roots in the same module. Basically I am now
using ant to show any broken dependencies between both source roots and
try to fix them in Idea. It's just not practically to let Idea detect thos
broken dependencies by having two modules, though that could save me a lot
of time.

I am not sure which tracker entries to file or even what to search for to
check if they already exist.


--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Thanks Dmitry. All in all Pallada is a big step forward in how modules are handled (with being able to export libraries, fewer conflicts and better handling of conflicts in module files, like being able to still see the last CVS result if a project needs to be reloaded, ...)

I had not expected that it would be so difficult to check for dependencies that may break. If you could issue a warning for simple refactorings that would be great.
For moving whole packages: How about making the dependency checking optional? It even is problematic only if the target module has fewer dependencies than the source module. I'd rather have Idea spent 10 minutes on checking dependencies than spent hours fixing them by hand.

The part about handling of broken dependencies (once they exist) really is an open issue that is worth discussing, but I haven't a good solution either.

0
Comment actions Permalink

We will try to update at least the more important
refactorings so that they report module-dependency related
problems in Pallada.

It seems build 2118 already contains some module dependency checking. However it's broken - currently it prevents me from moving a file altogether:
http://intellij.net/tracker/idea/viewSCR?publicId=34723

0
Comment actions Permalink

Stephen Kelvin wrote:

>> We will try to update at least the more important
>> refactorings so that they report module-dependency related
>> problems in Pallada.

It seems build 2118 already contains some module dependency checking.
However it's broken - currently it prevents me from moving a file
altogether: http://intellij.net/tracker/idea/viewSCR?publicId=34723


Yup, 2118 somehow was released with a stack overflow on almost any
refactoring (not really related to module dependency checking).
We recommend not to upgrade to it.

However, module dependency checking on refactoring is underway. I am
sure it will be available in build 2119.

Friendly,
Dmitry

--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

When I said that module dependency checking is broken I was NOT refering to the stack overflow, but rather to the fact that moving A produced wrong warning that A.someMember would not be accesible from A itself after moving A.

BTW could you please have a look at tracker entry 34020?!
You have set it to "More info needed", but I supplied that info a while ago:
http://intellij.net/tracker/idea/viewSCR?publicId=34020

0
Comment actions Permalink

Stephen Kelvin wrote:

When I said that module dependency checking is broken I was NOT refering
to the stack overflow, but rather to the fact that moving A produced wrong
warning that A.someMember would not be accesible from A itself after
moving A.


Ok, sorry, missed that part of your post.


BTW could you please have a look at tracker entry 34020?!
You have set it to "More info needed", but I supplied that info a while
ago: http://intellij.net/tracker/idea/viewSCR?publicId=34020


Yup, I will. I have some sort of a queue of unprocessed
requests/notifications, and it have not been piped far enough yet :)

Friendly,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.