Modules are edited under "Tools/Edit Modules". Basically what it means is that you can create a DAG of sub-projects (modules) within one project. Each module has a source path, test path, and libraries, as well as possible dependencies on other modules in the same project.
I'm seeing a couple of bugs with it (issues posted or soon will be), but overall it's very sweet indeed.
Yes, I have noticed that if I include another project as a depedancy, then it will not use that project in its classpath so I am having to jar up one project using ant and then include that jar into my 2nd module just so that it can see the other classes.
Modules are edited under "Tools/Edit Modules". Basically what it means is
that you can create a DAG of sub-projects (modules) within one project. Each module has a source path, test path, and libraries, as well as possible dependencies on other modules in the same project. >
I'm seeing a couple of bugs with it (issues posted or soon will be), but
Hmmm. It works for me. I just split one of my projects into two modules, one dependent on the other, and the classes of the first are included in the build and run classpaths of the second. Very slick, actually. Post a Tracker item.
so is suppose to help eliminate the need for multiple projects? For instance before if I had several configurations for the same application I would need multiple project files. Now I should use one project with multiple modules?
Modules don't automatically include the libraries of other modules that they depend on in their classpath. Could this be what you're seeing? Valentin indicated that this was intentional. I submitted an SCR for making letting the user have the option of automatically including the libraries from other modules:
You can vote for it if you'd like to have the feature (although Valentin's response suggested that it wouldn't be implemented until after the Aurora release).
Vil.
Grant Gochnauer wrote:
Yes, I have noticed that if I include another project as a depedancy, then it will not use that project in its classpath so I am having to jar up one project using ant and then include that jar into my 2nd module just so that it can see the other classes.
Ah, that makes sense. My setup didn't have any such missing dependencies, so it just sailed though. Wow, what a horrible misfeature. I can vaguely understand some motivation for it at compile time, but I certainly hope the run class path is "doing the right thing" and rolling up all of the dependent classpaths.
Ah, that makes sense. My setup didn't have any such missing dependencies,
so it just sailed though. Wow, what a horrible misfeature. I can vaguely understand some motivation for it at compile time, but I certainly hope the run class path is "doing the right thing" and rolling up all of the dependent classpaths. >
It's important to be able to (optionally) export libraries from a module so that other modules which depend on it can have these libraries available at compile time and run time. Eclipse provides this feature and it's very useful.
Modules are edited under "Tools/Edit Modules". Basically what it means is that you can create a DAG of sub-projects (modules) within one project. Each module has a source path, test path, and libraries, as well as possible dependencies on other modules in the same project.
I'm seeing a couple of bugs with it (issues posted or soon will be), but overall it's very sweet indeed.
Yes, I have noticed that if I include another project as a depedancy, then
it will not use that project in its classpath so I am having to jar up one
project using ant and then include that jar into my 2nd module just so that
it can see the other classes.
--Grant
--
-
Grant Gochnauer
http://www.gochnauer.org
"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:19797969.1066747919053.JavaMail.itn@is.intellij.net...
that you can create a DAG of sub-projects (modules) within one project.
Each module has a source path, test path, and libraries, as well as possible
dependencies on other modules in the same project.
>
overall it's very sweet indeed.
Hmmm. It works for me. I just split one of my projects into two modules, one dependent on the other, and the classes of the first are included in the build and run classpaths of the second. Very slick, actually. Post a Tracker item.
so is suppose to help eliminate the need for multiple projects? For instance before if I had several configurations for the same application I would need multiple project files. Now I should use one project with multiple modules?
Modules don't automatically include the libraries of other modules that they
depend on in their classpath. Could this be what you're seeing? Valentin
indicated that this was intentional. I submitted an SCR for making letting
the user have the option of automatically including the libraries from other
modules:
http://www.intellij.net/tracker/idea/viewSCR?publicId=19263
You can vote for it if you'd like to have the feature (although Valentin's
response suggested that it wouldn't be implemented until after the Aurora
release).
Vil.
Grant Gochnauer wrote:
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
Ah, that makes sense. My setup didn't have any such missing dependencies, so it just sailed though. Wow, what a horrible misfeature. I can vaguely understand some motivation for it at compile time, but I certainly hope the run class path is "doing the right thing" and rolling up all of the dependent classpaths.
Yuck.
--Dave Griffith
certainly hope the run class path is "doing the right thing" and rolling up
all of the dependent classpaths.
Of course the run classpath includes libraries from dependent modules as
well.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:32339662.1066834708836.JavaMail.itn@is.intellij.net...
so it just sailed though. Wow, what a horrible misfeature. I can vaguely
understand some motivation for it at compile time, but I certainly hope the
run class path is "doing the right thing" and rolling up all of the
dependent classpaths.
>
>
It's important to be able to (optionally) export libraries from a module so that other modules which depend on it can have these libraries available at compile time and run time. Eclipse provides this feature and it's very useful.
I just voted for this enhancement.