Poll: Do you reuse module files between different projects?

There was a bright idea in previous poll to store all project related files in the separate folder. Quite logically, .iml files can be stored there as well but that leads modules will be tied to a particular project, right?

So, had you ever have a module linked to two or more projects?

19 comments
Comment actions Permalink

Yep, we re-use modules between projects at our company. I think one of our modules is used in around 9 projects, so I'd prefer them not to have any tie-in to a specific project.

Whilst (loosely) on the subject, I'd quite like to re-use project library configurations between projects as well ;). I realise global libraries are project independent, but sharing those with the rest of the team and keeping them in-sync just isn't possible - hmm, I've just seen this mentioned in the project-file-splitting thread, so at least I'm not the only one!

Message was edited by:
Simon Knott

0
Comment actions Permalink

I don't think sharing a module between projects is a good way to construct projects. If a module is shared between projects, it should be kept in an independent project.

So I don't (and don't want to try to) have a module linked to two or more projects.

0
Comment actions Permalink

No. We usually have a 1-1 module to project mapping.


"Maxim Shafirov" <max@intellij.net> wrote in message
news:13055737.1161555195532.JavaMail.itn@is.intellij.net...

There was a bright idea in previous poll to store all project related
files in the separate folder. Quite logically, .iml files can be stored
there as well but that leads modules will be tied to a particular project,
right?

>

So, had you ever have a module linked to two or more projects?


0
Comment actions Permalink

We also tend to have a 1-1 mapping between project and modules.


Regards,

Bruce Ritchie

0
Comment actions Permalink

So, had you ever have a module linked to two or more projects?


Yes, this happens for exactly 53 of our application independent modules.

Tom

0
Comment actions Permalink

If a module is shared between projects, ...


Isn't that the rational behind a module? If not, for what purpose they exist?

Tom

0
Comment actions Permalink

sort of. Same module files, different projects for different branches. but the projects are pretty similar.

we do have projects that combine the modules in different ways. so proj A might have modules 1,2,3, but B has only 2,3, etc.

I can see the 80 (or 95%) case having the modules in the same dir as projects, but give us the option to move it (with relative references) to a different folder.

0
Comment actions Permalink

Maxim Shafirov schrieb:

So, had you ever have a module linked to two or more projects?


Yes.

Our project is splitted in "library" and "application".
While the "library" could be its own projects, its much easier to share
the "library" module between various applications as this makes
refactoring much easier.

Developers without permission to change the "library" do not need to
import this module, they can refer to a jar.

For massive refactorings I even load all applications and the library in
one project.

So I use the project as a "unit of work" or "what I would like to do
currently".


Ciao,
Mario

0
Comment actions Permalink

We use module sharing a lot!

0
Comment actions Permalink

Yes, we have "core" functions which live in the "core" module, then we
have a Web project, an RMI project, etc., etc.

Currently the module files are stored in the root of the SVN directory
corresponding to the module (svn/core/core.iml, svn/web/web.iml, etc.)
Our project files aren't currently shared but would logically go up a
level (svn/app1.ipr, svn/app2.ipr)

R

0
Comment actions Permalink

Maxim Shafirov wrote:

So, had you ever have a module linked to two or more projects?


Yes, absolutely. Saving .iml files with a certain project may be good for small
and simple projects, but this should really stay optional.

Sascha

0
Comment actions Permalink

Yes, for Images plugin for instance :)

0
Comment actions Permalink

Yes, this is a good approach for sharing dependencies between projects while retaining edit ability upon them.

If anything, it would be nice to make this easier to do.

0
Comment actions Permalink

Yes

There was a bright idea in previous poll to store all project related
files in the separate folder. Quite logically, .iml files can be
stored there as well but that leads modules will be tied to a
particular project, right?

So, had you ever have a module linked to two or more projects?



0
Comment actions Permalink

Yes, but mostly when the different projects are actually just different branches for the same project. For example, let's see we're developing Application A (AA), which depends on Utility Library B (ULB), which is developed outside the release cycle/branching of AA.

I'll create a project for each branch in AA, and if more than one of these branches use the same ULB version, they'll include the same ULB module file.

0
Comment actions Permalink

No module sharing, although we probably should. We've got a couple of large projects with many modules, some of which represent applications. The application modules should probably be split off into separate projects, which share the core services modules.

--Dave Griffith

0
Comment actions Permalink

Dependency management, both between project modules and between modules and libraries. It also makes a handy unit for high-level division-of-labor on large projects (particularly with module grouping).

--Dave Griffith

0
Comment actions Permalink

Yes, we do. We have two modules which are used in all of our projects (applications). One contains third party tools, libraries, etc, while the other one contains our framework/infrastructure code.

Further, there are some higher level modules which have some common business logic which are used for more than one product.

It is my belief that this is the most important purpose of modules and though they can server other purposes, this is the only critical feature.

--Tim

0
Comment actions Permalink

Yes, we use reuse module files.

0

Please sign in to leave a comment.