Migrating from Eclipse: need advice for project layout

Hi there,

I am planning to migrate fom Eclipse to IDEA.

Yes, I have read the migration FAQ :-) but there is no note about something corresponding to working sets.

In Eclipse, I have one workspace with two working sets. One working set contains my Swing projects and the other one my Android projects.
Every working set contains one library project that is used by (most) other projects in the same working set. The projects are completely independent of each other (except the library project of course).
In the Swing working set, I have one additional tools project (a code generator).
Most imes, I stay on one working set for a while, but I often switch between projects within one working set.
I am using git, and every project has its own repository.

So, what is best ?

altenative a)
Two IDEA projects, one for all the swing Projects, the other for Android. Every Eclipse project becomes an IDEA module.
But:
Is IDEA able to handle one git repository per module ?
How should I configure the build when (nearly) every module will make up an executable jar (or apk) ?

alternative b)
Every Eclipse becomes an IDEA project with a single module and import the library project's module everywhere.
But:
This means I will always have to open / close IDEA instances when I switch between projects or have opened multiple ones at a time.
What happens if I change something in the library project from one instance ? Will the other one correctly handle the changes ?
From my general computer experience, I know that it is never good to have something opened from two programs or two instances.

Something besides project layout ...
I _love_ the jar exporter of Eclipse. Click through the wizard one time to create a .jardesc file and afterwards just click on "export jar". That's all you need to do. Similarly, Android projects can be built by "create signed .apk".
Does IDEA have similar features or will I need to go for a build tool like Ant, Maven or whatever ?

I plan to start with the community edition and maybe later upgrade to ultimate.

4 comments
Comment actions Permalink

When I work with people that are switching from Eclipse to IDEA, I strongly recommend that they create a separate IntelliJ IDEA project for each project. This includes branches. A separate IDEA project for the HEAD/TRUNK/MAIN, and a separate one for each branch. This prevent a lot of confusion and errors. You do not have to deal with setting up strange search scopes (and remember to use them). When you search each the project, you only get results from that project. When you go to open Class Xyz, you get the one from the project or branch you are actively working on. I've seen numerous cases where developers accidentally make a change in the wrong class or on the wrong branch when working in Eclipse because of its central  workspace concept.

The other advantage of this methodology is that it helps encourage good practices. It prevents the "but it builds fine on my PC" syndrome caused by shared configurations in a common workspace. It ensures that each project, and its needed dependencies, stand on its own.

When switching over to IntelliJ IDEA, this -- not having a single common workspace -- is typically the biggest question point, and resistance point, for former Eclipse users. They struggle with IntelliJ IDEA's "one IDE project per project initiative" concept. Some actively try to resist and create a single project with numerous module groups (to represent a project initiative) each containing modules. This will however cause problems, and greatly hamper some of the powerful features within IDEA. IDEA's one IDE project per project effort is just a different working paradigm than the Eclipse Workspace concept. You just need to get use to it. (I personally greatly prefer the IDEA methodology.) I would encourage you to try it for a few weeks. You will get use to it. (As have many of the people I've worked with who have resisted it to varying degrees.) Yes, this means having a few IDEA windows open if you are working on several efforts simultaneously. But again, I see this as a benefit. Having to actively switch from one project to another (and that's were Alt+Tab is useful) helps draw a mental destination that you are switching projects. It prevents errors IMHO. And an advantage in a multi-monitor setup (or even a  large single monitor setup) is that you can have Project A here, and Project B over there. This allows for much easier back and forth; and much easier comparisons. So again, go with the one IDE project per project effort. Try it (for at least 3 or 4 weeks). You will get use to it, and dare I say, end up liking it.:)

mnaeher wrote:
What happens if I change something in the library project from one instance ? Will the other one correctly handle the changes ?
From my general computer experience, I know that it is never good to have something opened from two programs or two instances.

It depends on how you define them. If you define a "Global Library", a change in one place changes it in another (so all projects using the global library "see" the change). If you define it as a "Project Library", its availability and scope, and thus its changes, are limited to the project. And finally, if you define it as a "Module Library", its availability and scope, and thus its changes, are limited to the module. See the following help page for more information: http://www.jetbrains.com/idea/webhelp/configuring-project-structure.html

mnaeher wrote:
Something besides project layout ...
I _love_ the jar exporter of Eclipse. Click through the wizard one time to create a .jardesc file and afterwards just click on "export jar". That's all you need to do. Similarly, Android projects can be built by "create signed .apk"
Does IDEA have similar features or will I need to go for a build tool like Ant, Maven or whatever ?

I'm not that familiar with Eclipse. So I may not understand what "Jar Explorer" does, but in IDEA, in the project window, you can expand library JARs to view their content in a tree structure. And if you have the sources attached, even open the source files. (If you do not have sources attached, you can open the file to see the method signatures, but no source code.)  The "Go to class" and "Go to file" dialogs have options that allow you to include non-project files (i.e. libraries) so you can go to them. And finally, all the search and find usages dialogs have the ability to include the libraries as part of the search scope.  As for the "export jar" option, what does that feature do? Let me know, and I can let you know if IDEA has something similar. (Or someone else may come along and be able to answer that.)


<edit - answering missed questions>

Is IDEA able to handle one git repository per module ?

Yes. In fact IDEA can handle different respositories on a a per directory level (and this can be different systems - CVS for one directory/module, GIT for another, and SVN for yeat another). But again, I would encourage a single project per project effort. It makes configuration much simplier.

How should I configure the build when (nearly) every module will make up an executable jar (or apk) ?

Not an issue with a 1-to-1 mapping. This is what I meant above by "hamper some of the powerful features within IDEA". With a 1-to-1 mapping, you avoid these types of configuration hassles. It could be done in a "one IDEA project to many Project efforts" paradigm. But it becomes a hassle. IDEA's central design concept is the 1-to-1 mapping. So Use the Force Luke... Let go... Don't resist it :)

0
Comment actions Permalink

Whow, that's areally big and helpful answer.

About jars ... it looks like there is a misunderstanding.
The Eclipse feature I really love is a jar exporter, not a jar explorer.
It is a simplified easy-to-use build tool for creating executable jars without the need of configuring external build tools such as ant.

I don't think I can use a strict 1 to 1 mapping, because I have one library project for all my Swing applications and another one for all of my Android apps. Maybe I did not point this out clearly enough in my question.
And I am often coding some experimental stuff where I need to extend the library while working on an application. So, I really do not want to edit the library code and the application code seperately. At least when refactoring something in a library project, I will need to open the library code and all depentend application code at once.

I think I will start with one project per application and then take a look at the options on how to connect the library project to the application projects. Then I will see the difference between the different library types you wrote about. Well, this is something I am not familiar with :-)

Thanks a lot.

0
Comment actions Permalink

mnaeher wrote:

About jars ... it looks like there is a misunderstanding.
The Eclipse feature I really love is a jar exporter, not a jar explorer.
It is a simplified easy-to-use build tool for creating executable jars without the need of configuring external build tools such as ant.

Sorry about that. I guess I read too quickly and thought I saw "explorer" rather than the "exporter" you actually wrote.Oops. In IDEA, you can define artifacts to build. One option is a JAR. There are various options when configuring the JAR to be built... such as whether to include dependencies in the jar, the main class (to make executable), a manifest file to use, and such. To define an artifact, go to File > Project Structure, on the left, select "Artifacts" under the "Project Settings" section. Click the add button (top center) to add a new artifact. You build an artifact via the menu Build > Build Artifacts... See the"Configuring Artifacts" section in the help guide for more information.

mnaeher wrote:

I don't think I can use a strict 1 to 1 mapping, because I have one library project for all my Swing applications and another one for all of my Android apps. Maybe I did not point this out clearly enough in my question.
And I am often coding some experimental stuff where I need to extend the library while working on an application. So, I really do not want to edit the library code and the application code seperately. At least when refactoring something in a library project, I will need to open the library code and all depentend application code at once.
I think I will start with one project per application and then take a look at the options on how to connect the library project to the application projects. Then I will see the difference between the different library types you wrote about. Well, this is something I am not familiar with :-)

We may just be getting caught up in nomenclature a bit. To me a "Project", or "Application" has dependencies on one or more "Libraries". A "Library" is an API or framework such such as Logback, apcahe commons lang, my utilities, etc. So I guess I'm misunderstanding you when you mention you have a "Library" consisting of numerous "applications". To me. that's a "Project Group" or "Set of Applications" or some such name. But again, that's just a nomenclature thing. What matters is how you can set up IDEA. And I think you can still accomplish what you want.

An IntelliJ IDEA project can have multiple IntelliJ IDEA modules. An IntelliJ IDEA module can be used in one or more IntelliJ IDEA Projects. For example, if you have a "Fancy Math Utilities" module, that module can be used in both your "Warp Engine" project, and your "Time Machine" project. The "Time Machine" project may also then use a "Flux Capacitor" module as well as it's own dedicated "Time Machine - main" module. It can then use the external (compiled) "DeLorean Car" library. You can have a "Fancy Math Utilities" project that only has the "Fancy Math Utilities" module defined. If you want to focus only on enhancing the "Fancy Math Utilities" code, you open the "Fancy Math Utilities" project. But if you are working on the "Time Machine" project, you can still make changes (and compile, and build artifacts) for the "Fancy Math Utilities" module. In this case, the "Fancy Math Utilities" module is used in three projects. A change to code in the "Fancy Math Utilities" module affects and is is 'seen' in any of the projects that use that module. A module can have a dependency on another module. So your "Time Machine - main" module might have a dependency on the "Fancy Math Utilities" module, which in turn has a dependency on the "Basic Math Utilities" module which in turn has a dependency on the "Apache Commons Math" library. In turn, you "Time Machine" Project consistes of the "Time Machine - main",  "Fancy Math Utilities", & Basic Math Utilities" modules, and the "DeLorean Car" library.

So nomenclature asside, here is what a project and a module are in the context of IntelliJ IDEA...

From the IntelliJ IDEA "Module" help topic:

A module is a discrete unit of functionality which you can compile, run, test and debug independently.
Modules contain everything that is required for their specific tasks: source code, build scripts, unit tests, deployment descriptors, and documentation. However, modules exist and are functional only in the context of a project.
Configuration information for a module is stored in a .iml module file. By default, such a file is located in the module's content root folder.


Ffrom the"Project" help topic:

Whatever you do in IntelliJ IDEA, you do that in the context of a project. A project is an organizational unit that represents a complete software solution.
Your finished product may be decomposed into a series of discrete, isolated modules, but it's a project definition that brings them together and ties them into a greater whole.
Projects don't themselves contain development artifacts such as source code, build scripts, or documentation. They are the highest level of organization in the IDE, and they define project-wide settings as well as collections of what IntelliJ IDEA refers to as modules and libraries.


And finally, from the "Library" help topic:

A library is a collection of compiled code used in your modules as is. For Java, for example, a library is a set of class files stored in an archive or directory (or in a number of archives and directories).
Libraries may optionally include the source code for the library classes as well as corresponding API documentation. Including the source files and documentation is optional and doesn't alter the way the library is used in any way. However, it adds the ability to use inline documentation extracted from the source code, and also to view the API documentation right from the IDE.


I hope that helps.

0
Comment actions Permalink

Whow again.

I think (or hope ?) I got it. Now, there is the time to try it.

And again, Thank you very much for the good and detailed exlanation.

0

Please sign in to leave a comment.