Introduction to Projects, Modules, and LIbraries

An Introduction to Projects, Modules, and Libraries

This is an attempt to make sense of the different new terms related to
project configuration. I may be way off on some points so feel free to
correct me.

Projects

A Project contains a number of settings (editable in the Project Properties
dialog), and a number of modules (editable in the Configure Project dialog).
Project files are stored in the project directory and have the extension ipr.

Modules

A Module is a set of classes with the same output directory. A Module contains
one or more Content Entries, where each entry has Source Folders and Test Source
Folders. Source Folders contain the source code for the Module classes. The
Test Source Folders contain source code to test classes that are used to test
the Module classes.

A Module can have a separate Test output path where all test class files are
put. This together with the Test Source Folders keep the test files separate
from the distributable files.

Module definitions are stored in files with the extension iml, for example
printing.iml. The module definition files are stored in the project directory.

Modules can be reused between projects, but the current version has many
limitations. One is that there is no GUI to accomplish this. Another is that
a module cannot be opened by more than one project at a time. A third limitation
is that modules cannot have their own Version Control Sustem (VCS) configuration.
The VCS configuration is part of the project settings.

Libraries

Libraries are read-only references to classes that you want to use in your
modules/projects. You cannot modify the classes of a Library from within
a project that uses the library.

Application libraries (Global libraries)

Named libraries created as Application libraries are available in other projects.

Project libraries

Named libraries created as Project libraries are available only in this project.

Module libraries

Module libraries are not available for reuse by any other project or module.
They just provide a way to refer to prebuilt classes.

Best Practice

What to do of all this? What is the recommended way to set up a project?

You have a base directory where you put all your projects. Let's say c:\projects.
In this directory you put your different project directories. For example:

In a project directory you put the project file and a directory for each of
your modules.

In a module directory, you have a class output path and a test class output
path. You also have a Content Entry with a Source folder and a Test Source Folder.

For every class that you add in a src directory you (should) add a test class in the
test_src directory.

To deploy your application, you pull together the files in all classes directories to
a single directory or a single jar file. You may also put each separate classes directory
in its own jar file.

26 comments

That's a pretty good description. Have you thought about posting it on the
intellij.org website?

The only thing I would add to it is that each module has its own set of
libraries, which place additional classes and/or resources in the classpath
for that module. These libraries are not visible to any users of the module,
so it may be necessary for dependent modules to include some or all of the
same libraries.

Nice work,
Vil.

Mikael Karlsson wrote:

An Introduction to Projects, Modules, and Libraries

]]>
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0


You need to add something about inter-module dependencies, and also about configuring JDK for each module. If you're going to show .ipr files on your "best practice" example, you'll also want to show the .iml files. Other than that, looks good.

0

This is all nice, but how to bridge these modules/libraries with my ANT
build script, which (surprise!) knows nothing about all this stuff, namely
about classpaths and output dirs.

I think that this complex project structure requires proper management not
only while maintaining files, but while compiling and building. Build-it ANT
with proprietary tasks, maybe?


0


"Michael Jouravlev" <mikus@mail.ru> wrote in message
news:bpdmr2$p07$1@is.intellij.net...

This is all nice, but how to bridge these modules/libraries with my ANT
build script, which (surprise!) knows nothing about all this stuff, namely
about classpaths and output dirs.

>

I think that this complex project structure requires proper management not
only while maintaining files, but while compiling and building. Build-it

ANT

with proprietary tasks, maybe?


Built-in :)


0

FWIW, I've been building an Aurora-to-Ant plugin, which will create build files based on the modules structure. It can either create a single project-wide Ant file, or an Ant file per module plus a project Ant file which calls out to them. It knows about output files, differences between test and source paths, libraries, ordering, and dependencies, and can create tasks for compiling source and test, running tests, and creating javadoc (no jarring or rmic, though). Mostly a finger exercise to learn the modules structure, but it works fairly well. I'll likely release in about a week, once I've finished testing and polishing it up.

--Dave Griffith

0

Michael Jouravlev wrote:

>This is all nice, but how to bridge these modules/libraries with my ANT
>build script, which (surprise!) knows nothing about all this stuff, namely
>about classpaths and output dirs.
>

>

There is related request :
http://www.intellij.net/tracker/idea/viewSCR?publicId=18625

You could add your comments about modules to it.

Alain

0

The module definition files are stored in the project directory.


They can be placed in any location. The current UI allows to create modules
in the same directory only. This will be changed in the next build.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Mikael Karlsson" <no_mail@jetbrains.com> wrote in message
news:15526319.1069170934797.JavaMail.itn@is.intellij.net...

An Introduction to Projects, Modules, and Libraries

>

This is an attempt to make sense of the different new terms related to
project configuration. I may be way off on some points so feel free to
correct me.

>

Projects

>

A Project contains a number of settings (editable in the Project

Properties

dialog), and a number of modules (editable in the Configure Project

dialog).

Project files are stored in the project directory and have the extension

ipr.
>

Modules

>

A Module is a set of classes with the same output directory. A Module

contains

one or more Content Entries, where each entry has Source Folders and Test

Source

Folders. Source Folders contain the source code for the Module classes.

The

Test Source Folders contain source code to test classes that are used to

test

the Module classes.

>

A Module can have a separate Test output path where all test class files

are

put. This together with the Test Source Folders keep the test files

separate

from the distributable files.

>

Module definitions are stored in files with the extension iml, for example
printing.iml. The module definition files are stored in the project

directory.
>

Modules can be reused between projects, but the current version has many
limitations. One is that there is no GUI to accomplish this. Another is

that

a module cannot be opened by more than one project at a time. A third

limitation

is that modules cannot have their own Version Control Sustem (VCS)

configuration.

The VCS configuration is part of the project settings.

>

Libraries

>

Libraries are read-only references to classes that you want to use in your
modules/projects. You cannot modify the classes of a Library from within
a project that uses the library.

>

Application libraries (Global libraries)

>

Named libraries created as Application libraries are available in other

projects.
>

Project libraries

>

Named libraries created as Project libraries are available only in this

project.
>

Module libraries

>

Module libraries are not available for reuse by any other project or

module.

They just provide a way to refer to prebuilt classes.

>

Best Practice

>

What to do of all this? What is the recommended way to set up a project?

>

You have a base directory where you put all your projects. Let's say

c:\projects.

In this directory you put your different project directories. For example:
projects\ > xmleditor\ > imgviewer\]]>
In a project directory you put the project file and a directory for each

of

your modules.
projects\ > xmleditor\ > xmleditor.ipr > parser\ > printer\ > editor\ > imgviewer\]]>
In a module directory, you have a class output path and a test class

output

path. You also have a Content Entry with a Source folder and a Test Source

Folder.

projects\ > xmleditor\ > xmleditor.ipr > parser\ > classes > test_classes > src > test_src > printer\ > editor\ > imgviewer\]]>
For every class that you add in a src directory you (should) add a test

class in the

test_src directory.

>

To deploy your application, you pull together the files in all classes

directories to

a single directory or a single jar file. You may also put each separate

classes directory

in its own jar file.

>


0

+1

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:11280665.1069179650089.JavaMail.itn@is.intellij.net...

FWIW, I've been building an Aurora-to-Ant plugin, which will create build

files based on the modules structure. It can either create a single
project-wide Ant file, or an Ant file per module plus a project Ant file
which calls out to them. It knows about output files, differences between
test and source paths, libraries, ordering, and dependencies, and can create
tasks for compiling source and test, running tests, and creating javadoc (no
jarring or rmic, though). Mostly a finger exercise to learn the modules
structure, but it works fairly well. I'll likely release in about a week,
once I've finished testing and polishing it up.
>

--Dave Griffith



0

a module cannot be opened by more than one project at a time.


In fact I was not correct when I said that. More precisely it's allowed but
if you modify some settings of the module opened in 2 projects from one
project, the second project will not recognize these changes smoothly and
suggest to "Reload project". However I didn't check exactly in the way I
described.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Mikael Karlsson" <no_mail@jetbrains.com> wrote in message
news:15526319.1069170934797.JavaMail.itn@is.intellij.net...

An Introduction to Projects, Modules, and Libraries

>

This is an attempt to make sense of the different new terms related to
project configuration. I may be way off on some points so feel free to
correct me.

>

Projects

>

A Project contains a number of settings (editable in the Project

Properties

dialog), and a number of modules (editable in the Configure Project

dialog).

Project files are stored in the project directory and have the extension

ipr.
>

Modules

>

A Module is a set of classes with the same output directory. A Module

contains

one or more Content Entries, where each entry has Source Folders and Test

Source

Folders. Source Folders contain the source code for the Module classes.

The

Test Source Folders contain source code to test classes that are used to

test

the Module classes.

>

A Module can have a separate Test output path where all test class files

are

put. This together with the Test Source Folders keep the test files

separate

from the distributable files.

>

Module definitions are stored in files with the extension iml, for example
printing.iml. The module definition files are stored in the project

directory.
>

Modules can be reused between projects, but the current version has many
limitations. One is that there is no GUI to accomplish this. Another is

that

a module cannot be opened by more than one project at a time. A third

limitation

is that modules cannot have their own Version Control Sustem (VCS)

configuration.

The VCS configuration is part of the project settings.

>

Libraries

>

Libraries are read-only references to classes that you want to use in your
modules/projects. You cannot modify the classes of a Library from within
a project that uses the library.

>

Application libraries (Global libraries)

>

Named libraries created as Application libraries are available in other

projects.
>

Project libraries

>

Named libraries created as Project libraries are available only in this

project.
>

Module libraries

>

Module libraries are not available for reuse by any other project or

module.

They just provide a way to refer to prebuilt classes.

>

Best Practice

>

What to do of all this? What is the recommended way to set up a project?

>

You have a base directory where you put all your projects. Let's say

c:\projects.

In this directory you put your different project directories. For example:
projects\ > xmleditor\ > imgviewer\]]>
In a project directory you put the project file and a directory for each

of

your modules.
projects\ > xmleditor\ > xmleditor.ipr > parser\ > printer\ > editor\ > imgviewer\]]>
In a module directory, you have a class output path and a test class

output

path. You also have a Content Entry with a Source folder and a Test Source

Folder.

projects\ > xmleditor\ > xmleditor.ipr > parser\ > classes > test_classes > src > test_src > printer\ > editor\ > imgviewer\]]>
For every class that you add in a src directory you (should) add a test

class in the

test_src directory.

>

To deploy your application, you pull together the files in all classes

directories to

a single directory or a single jar file. You may also put each separate

classes directory

in its own jar file.

>


0

Why does it every time I read something about the new projects and modules stuff I feel like the IDE is dictating project structure instead of the development team dictating project structure. The IDEA handles our structure quite well, but I have yet to figure out how we can acomplish it in a easy way with Aurora. Here's what we have:

C:\project\Java <--- source files go in here.

C:\project\Java\META-INF <-- things like application.xml, ejb-jar.xml go here (yes, it's at the top of the "src" directory

What I still find interesting is that if I want an EJB module, I seem to have to put the src directory different than my project's source directory. But in our case, the whole project is both. In that case, would I just need an EJB Module?

I know many people would disagree with our project layout (and there are days that I do), but its worked like this for a very long time and my IDE shouldn't force me into some contrived project layout structure. (something I tend to dislike about other IDEs)

Am I just missing something?

Thanks,
Patrick

0

I couldn't agree more.

I brought this issue up a while ago (I'm in the same boat as you) (http://www.intellij.net/forums/thread.jsp?forum=22&thread=51598) and was surprised to find out that there is this limitation.

I don't think an IDE should suggest/require a specific project structure, especially when the to-be-deprecated, current project structure works so well in IntelliJ 3.0. And I really do not want to have change around our project directory layout to accomodate IntelliJ 4.0.

A bug was submitted on this issue (http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) but there hasn't been any response yet - it is still in the Submitted state. (BTW, Is that normal?)

0

Basically, what you need is a way to specify either a root directory for
your source directory, or a package corresponding to your source directory.

Root directory:
src = c:/myco/src/com/myco/util
root = c:/myco/src

Package:
src = c:/myco/src/com/myco/util
package = com.myco.util

Would that solve your problem?

Are there any plans for something like this in Aurora?

0

Are there any plans for something like this in Aurora?


Of course not in Aurora.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Mikael Karlsson" <no_mail@jetbrains.com> wrote in message
news:1514716.1069230115971.JavaMail.itn@is.intellij.net...

Basically, what you need is a way to specify either a root directory for
your source directory, or a package corresponding to your source

directory.
>

Root directory:
src = c:/myco/src/com/myco/util
root = c:/myco/src

>

Package:
src = c:/myco/src/com/myco/util
package = com.myco.util

>

Would that solve your problem?

>

Are there any plans for something like this in Aurora?

>
>


0

Sh*t! "Of course not"???
I was under impression that the debate some time ago
showed the need for src pointing into the package structure
(with specifying which package that directory is).
This was possible in 3.0 and many people's work relies on that.

r.

Valentin Kipiatkov (JetBrains) wrote:

>>Are there any plans for something like this in Aurora?


Of course not in Aurora.

0

Sh*t! "Of course not"???


Would you expect we do drop everything existing now and reimplement it?
This would take another 3-4 months.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Richard Nemec" <rndzank@attbi.com> wrote in message
news:bpfm8r$c8m$1@is.intellij.net...

Sh*t! "Of course not"???
I was under impression that the debate some time ago
showed the need for src pointing into the package structure
(with specifying which package that directory is).
This was possible in 3.0 and many people's work relies on that.

>

r.

>

Valentin Kipiatkov (JetBrains) wrote:

>

>>Are there any plans for something like this in Aurora?
>
>

Of course not in Aurora.

>



0

Yes, I think that would solve the problem. It'd be a 'good thing' if one could also specify the test path for a source directory.

0

Well, I don't expect you guys to drop everything you've alread done. But at the current rate, I don't see how my project will be able to upgrade to Aurora without moving a lot of things around...which gets me back to "The IDE shouldn't dictate layout, the project should".

I am going to keep checking each EAP build as things get closer to finalized ( my biggest problem right now is setting up J2EE stuff, and I know that's going through a major revision ) and hope that at some point I can make our current project work with the new stuff (because I really like a lot of the new stuff)

Thanks,
Patrick

0

Huh!?!?!? I've got to admit that this response really surprised me (to say the least)! The problem that this thread points out is a big problem for a number of your customers.

Given IntelliJ's wonderful and intuitive interface and ease of use I'd have expected that JetBrains would be more concerned about backwards compatability.

When/if Aurora comes out without providing a way around this particular problem a large number of existing, paying customers are going to be screwed because they will not be able to cleanly convert their 3.0 ipr/iws files into the module-aware paradigm. As you can tell by the responses that you've already received on the bug I've filed (http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) , there are a number of people in the EAP program that have this particular problem. There have got to be many more of your customers (that aren't involved in the EAP) out there that have a project directory structure like the one described above.

You are asking (some of) your existing customers to change around their project directory structure which, in some cases, is a lot of work. Or, failing that, they will have to have all of their source (in our case, 2000 java files, 500 jsps) in one project.

Is that really what you want?!?!?!

0

I cannot understand how request #20491 may be related to backward
compatibility with Ariadna. It says about "subprojects" and as I understand
subprojects are modules in Aurora. But modules were not supported by Ariadna
at all.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"David Macklem" <no_mail@jetbrains.com> wrote in message
news:15632251.1069271125505.JavaMail.itn@is.intellij.net...

Huh!?!?!? I've got to admit that this response really surprised me (to say

the least)! The problem that this thread points out is a big problem
for a number of your customers.
>

Given IntelliJ's wonderful and intuitive interface and ease of use I'd

have expected that JetBrains would be more concerned about backwards
compatability.
>

When/if Aurora comes out without providing a way around this particular

problem a large number of existing, paying customers are going to be screwed
because they will not be able to cleanly convert their 3.0 ipr/iws files
into the module-aware paradigm. As you can tell by the responses that
you've already received on the bug I've filed
(http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) , there are a
number of people in the EAP program that have this particular problem.
There have got to be many more of your customers (that aren't involved in
the EAP) out there that have a project directory structure like the one
described above.
>

You are asking (some of) your existing customers to change around their

project directory structure which, in some cases, is a lot of work. Or,
failing that, they will have to have all of their source (in our case, 2000
java files, 500 jsps) in one project.
>

Is that really what you want?!?!?!



0

I cannot understand how request #20491 may be related
to backward
compatibility with Ariadna. It says about
"subprojects" and as I understand
subprojects are modules in Aurora. But modules were
not supported by Ariadna
at all.

Valentin,

Thanks for responding.

My use of the term subproject seems to be confusing. What I mean by subproject is a project within a larger project. This means that a large project with many components can be handled in Ariadne with a project file per component. In Ariadne, these components can all be under the same source tree. In Aurora, they cannot. For example:

My source directory structure is the following:
/myco/src/com/myco/util
/myco/src/com/myco/engine
/myco/src/com/myco/manager

In each of the util, engine and manager directories I currently have an ipr file (Ariadne project file). This project file permits me to code, debug, build that specific 'subproject': either util, engine or manager.

I find I can't do the same thing in Aurora without going to a lot of trouble to exclude the other 'subproject' source subdirectories (and, even with that, the test directories are not specifiable). I don't think it is permissible or advisable in Aurora to have projects with overlapping sources.

(Please see my original posting on this subject - http://www.intellij.net/forums/thread.jsp?forum=22&thread=51598&tstart=0&trange=15 - it is more long winded but, hopefully, more explanatory.)

I believe that one potential solution to this problem is to selectively turn off the "Package name 'com.myco.util' does not correspond to file path ''" error/warning message.

Again, I do appreciate that you are taking the time to respond. And, if you can't tell :), this is a serious problem for our development team as we do not want to have to restructure our source directory layout as a result of moving to Aurora.

Kind regards,
David Macklem

0

We have two problems mixed in this thread:

- one is about subprojects (modules)

- two is about partial source inclusion (src/package) that usually
is used with the subprojects thinking (or using them if available,
but they were not in 3.0.x) - the request 20491 (the discussion there)
explains clearly, that the term subproject is mainly used for
specifying one package in a bigger source structure as part of
someone's src (without having the wrong package errors).

The problem "two" is about backwards compatibility. And this is the one
we are shouting very loud we really NEED it.

Please, read the thread again carefully and you'll see what we ask for.

I don't have URLs for the other threads, where we discussed the exactly
same problem.

r.



Valentin Kipiatkov (JetBrains) wrote:

I cannot understand how request #20491 may be related to backward
compatibility with Ariadna. It says about "subprojects" and as I understand
subprojects are modules in Aurora. But modules were not supported by Ariadna
at all.

0

Hmm.. So as I can see you want to have a source directory where only some
subdirectory is included into the project. But how do you compile the
project then? Aren't classes in thid subdirectory depend on others in the
source folder?

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"David Macklem" <no_mail@jetbrains.com> wrote in message
news:24720883.1069438457736.JavaMail.itn@is.intellij.net...

I cannot understand how request #20491 may be related
to backward
compatibility with Ariadna. It says about
"subprojects" and as I understand
subprojects are modules in Aurora. But modules were
not supported by Ariadna
at all.

>
Valentin,

>

Thanks for responding.

>

My use of the term subproject seems to be confusing. What I mean by

subproject is a project within a larger project. This means that a large
project with many components can be handled in Ariadne with a project file
per component. In Ariadne, these components can all be under the same
source tree. In Aurora, they cannot. For example:
>

My source directory structure is the following:
/myco/src/com/myco/util
/myco/src/com/myco/engine
/myco/src/com/myco/manager

>

In each of the util, engine and manager directories I currently have an

ipr file (Ariadne project file). This project file permits me to code,
debug, build that specific 'subproject': either util, engine or manager.
>

I find I can't do the same thing in Aurora without going to a lot of

trouble to exclude the other 'subproject' source subdirectories (and, even
with that, the test directories are not specifiable). I don't think it is
permissible or advisable in Aurora to have projects with overlapping
sources.
>

(Please see my original posting on this subject -

http://www.intellij.net/forums/thread.jsp?forum=22&thread=51598&tstart=0&trange=15 -
it is more long winded but, hopefully, more explanatory.)
>

I believe that one potential solution to this problem is to selectively

turn off the "Package name 'com.myco.util' does not correspond to file path
''" error/warning message.
>

Again, I do appreciate that you are taking the time to respond. And, if

you can't tell :), this is a serious problem for our development team as we
do not want to have to restructure our source directory layout as a result
of moving to Aurora.
>

Kind regards,
David Macklem



0

BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not necessarily, I've got this case, and the files in those subdis (sub package) don't have dependancies to other classes. Like a utilities package where class files are just that utilities.

Valentin Kipiatkov (JetBrains) wrote:
| Hmm.. So as I can see you want to have a source directory where only some
| subdirectory is included into the project. But how do you compile the
| project then? Aren't classes in thid subdirectory depend on others in the
| source folder?
|
-


BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/wJ/H+cV9vuB27SARAtCuAJ47XjFuwcm42WoMDrUa2HYmAdDumwCdFpXu
RGJosjmJuOte/gJ98Hdjy1w=
=l7a3
-


END PGP SIGNATURE-----

0

Valentin, there are several different use cases for that:
1.
The project itself is compiled independently by (for example) an Ant script.
That is (IMHO) the most typical case. IDEA is used for smart coding/refactoring
and code browsing. A project in this case may be one to tackle smaller
area/problem.
2.
There may be overlapping projects that share some packages within a common
src structure.
3.
There may a bigger project, that has clearly defined set of packages that
may be used independently (and modified to make sense).
4.
Another typical case - project uses a big external code (e.g. set of EJBs).
In order to investigate the behavior, the interfaces and their implementation
has to be put as sources (maybe just as library sources), but not all
(the external code is again too big and the project needs just one smaller part).

r.

Valentin Kipiatkov (JetBrains) wrote:

Hmm.. So as I can see you want to have a source directory where only some
subdirectory is included into the project. But how do you compile the
project then? Aren't classes in thid subdirectory depend on others in the
source folder?

0

Valentin Kipiatkov (JetBrains) wrote:

Hmm.. So as I can see you want to have a source directory where only some
subdirectory is included into the project. But how do you compile the
project then? Aren't classes in thid subdirectory depend on others in the
source folder?


Probably not. The PerformaSure project consists of 3 main applications,
Nexus, Workstation and Agent. All three applications share some common
code, but are essentially independent. However, the source code is all
in one source hierarchy:

src/java/
com/sitraka/pas/
agent/
common/
nexus/
workstation/

agent, nexus, and workstation use classes in common, but common must not
use classes in agent, nexus or workstation. In the Ant build script
these packages are compiled all together and dependencies between the
packages are enforced by static code analysis tests. Separation of the
apps is done using fileset includes when creating the jars which have a
classpath in the manifest to specify their runtime dependencies.

It would be nice to define modules for each of the applications, and
probably a module for the common package which each of the app modules
depends on. This would allow the GUI team to use a project which only
has the workstation and common modules, and the backend team to use a
project which only has the agent, nexus and common modules.

Currently, we (those of us using the EAP) use a project with one module
that has everything in it. Everybody else is using 3.0.5 with
essentially the same configuration.

My point being that while there is nothing essentially broken in this
directory layout, it does not fit very well into the IDEA model of a
project with multiple modules that have different source roots. It would
be better to be able to designate, for a module, the source root and
which directories (or perhaps packages) within that source root are
included in that module.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

0

Please sign in to leave a comment.