10 comments
Comment actions Permalink

Michael Seele wrote:

do you support modules in the next build? i ask because i saw this fixed
requests:

http://www.intellij.net/tracker/idea/viewSCR?publicId=12682
http://www.intellij.net/tracker/idea/viewSCR?publicId=11733



Well, I think there will be some time before UI for multiple modules
appears to general public. Also, we will want to do some internal testion
of mulitmodule stuff before opening it to public.

Or, we will again get whining threads of unlimited size.

Friendly,
Dmitry



--
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

Regarding the multiple modules I have following questions.

1. Will the module dependencies be enforced by the build-process?

2. Will the code completion/auto-import honour module dependencies?

Tom

0
Comment actions Permalink

1. Will the module dependencies be enforced by the build-process?


Yes, the build/make process compiles modules according to dependencies between them.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

Thomas Singer wrote:

Regarding the multiple modules I have following questions.

2. Will the code completion/auto-import honour module dependencies?


Eventually.

Freindly,
Dmitry
--
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

I am not sure what Thomas asked about dependencies between modules but I had something different in mind:

Will the modules be compiled separately in the order specified in the dependencies and not just as a big project? That way it will enforce that my framework does not have dependencies on application stuff, thing that is not possible currently.

Jacques

0
Comment actions Permalink

Yep, this is what I meant when answered Thomas' question.

--

Best regards,
Eugene Zhuravlev
JetBrains Inc., http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

BTW, does anybody knows, how to compile modules in dependency-order
with a few ANT lines?

Tom

0
Comment actions Permalink

What do you mean?
My answer for now is going so simple that I am quite sure you know this already:
You need to specify a source path, a class path and an output path for each module (output path is not required if you wipe it out every times or if you do not have diamond shaped dependencies). You can then call your standard javac task with these.
If you have control over the layout of your modules, make them follow the same exact one. That way using the "ant" task to redefine the root of each module you can use the same target to build every modules:
]]>

Jacques

0
Comment actions Permalink

Maybe the problem is caused by our use of only one output path.

Example: A, B, C and D are modules ("-->" means "is used by")
A>B>C
-->D

In this case you need compile A first. Save class files from A.
Compile B (using the class files from A), compile C (using the class
files from A and B). Compiling D only must use the class files from A,
not from B nor C.

I doubt, your sketched target allows this dependency.

Tom

0
Comment actions Permalink

And you would be right. It won't work.
We are using multiple different compile targets but we in the process to generalize them.
Our solution is more complicated than my flawed proposition, with a build.xml calling out to a standard-build.xml. In the build.xml we setup all properties (class path included) and delegating targets that propagate these settings to standard targets through ]]>. Using a standard layout means that we do not have to include much in the build.xml but we do list the dependent jars built in other modules.
It isn't really ideal but it is a lot more manageable than Maven... ;)

I hope this make it clearer even though it would not be your simple, few lines of ant script, solution.

Jacques

0

Please sign in to leave a comment.