Change in managing projects in Aurora

Hi all,

Here's some information on what is planned to change in a way projects are
managed in the next version of IDEA. Your opinions are welcome.

A project will consist of a set of modules (in simple cases for java apps
there will usually be only one module). Each module will have its own set
of working paths, libraries, classpath settings, etc. Basically a module is
what current IDEA project is, but with a few additions.

Modules can be of different types, where its type defines various behavioral
aspects of the module. For example modules of type EJB will have its own
logic of how they are compiled and validation is performed. Also various UI
editors may depend on the module type the file is coming from. For example
ejb-jar.xml from an EJB module will open a DD Editor where from a java
module a simple XML editor.

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

There will be a possibility to specify dependencies between modules that are
considered when building the project.

For simplicity we will not clutter the UI with a few things like dependency
management and the like in case when there's only one module in the project.
Another issue here is that module descriptions are stored as separate
.iml files and can be imported into any number projects (while projects are ]]>.ipr files containing only project-wide settings
a references to modules it contains). There will be a way to create a new
module for the project or add an existing one.

Now regarding paths. A module will have a set of non-overlapping roots
(most likely just one for most projects, but any number is allowed). Any
subnode of this root may be assigned as a source path or an exclude path.
This will be the only way to specify paths.
All this also eliminates the need for multiple output paths. We are also
planning to introduce a special notion of test source paths containing test
cases which may get compiled to a different location. We think it's better
to introduce this special concept instead of having a generic and
hard-to-comprehend one.

Please let us know what you think, since it touches quite a few things in a
way you work with the tool.

Best regards,

Eugene Belyaev


57 comments

Hi, Eugene.

When you are referring to a Web module, are you referring to html and js
files or a WAR module?

Our project is divided in 3 parts called Shared, CoreApp and WebApp. The end
result of their compilation (which is done only in Ant, not through IntelliJ
compilation) is a WAR file and several copied JAR files in addition to some
external config files.

Will such a configuration be easily supported? I am referring mostly to the
ability to have several modules whose packaging is one file.

Where does Ant fit here? Will Aurora still have its own compilation
mechanism or are you using Ant as the compilation engine?

Also, have you moved the run/debug entries to the project file so that the
iws doesn't need to be checked in? As you recall this was a problem that I
and several others had and at the time the general opinion was that the
placement (level) of settings should be configurable so that if we relate to
the iws as the user settings and ipr as the project settings the user can
decide what to do. The 3 levels would be global settings, ipr and iws, so
for example a project could have debug entries and users will be able to add
their own in the iws which wouldn't be checked in.

Lastly, will Aurora support loading ipr files from the start or will we need
to build the project files from scratch?

All in all this sounds interesting and I would just be careful to preserve
simplicity and consistency.

Amnon

"Eugene Belyaev" <beg@intellij.com> wrote in message
news:b45509$6jo$1@is.intellij.net...

Hi all,

>

Here's some information on what is planned to change in a way projects are
managed in the next version of IDEA. Your opinions are welcome.

>

A project will consist of a set of modules (in simple cases for java apps
there will usually be only one module). Each module will have its own set
of working paths, libraries, classpath settings, etc. Basically a module

is

what current IDEA project is, but with a few additions.

>

Modules can be of different types, where its type defines various

behavioral

aspects of the module. For example modules of type EJB will have its own
logic of how they are compiled and validation is performed. Also various

UI

editors may depend on the module type the file is coming from. For

example

ejb-jar.xml from an EJB module will open a DD Editor where from a java
module a simple XML editor.

>

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

>

There will be a possibility to specify dependencies between modules that

are

considered when building the project.

>

For simplicity we will not clutter the UI with a few things like

dependency

management and the like in case when there's only one module in the

project.

Another issue here is that module descriptions are stored as separate
<module name>.iml files and can be imported into any number projects

(while

projects are <project name>.ipr files containing only project-wide

settings

a references to modules it contains). There will be a way to create a new
module for the project or add an existing one.

>

Now regarding paths. A module will have a set of non-overlapping roots
(most likely just one for most projects, but any number is allowed). Any
subnode of this root may be assigned as a source path or an exclude path.
This will be the only way to specify paths.
All this also eliminates the need for multiple output paths. We are also
planning to introduce a special notion of test source paths containing

test

cases which may get compiled to a different location. We think it's

better

to introduce this special concept instead of having a generic and
hard-to-comprehend one.

>

Please let us know what you think, since it touches quite a few things in

a

way you work with the tool.

>

Best regards,

>

Eugene Belyaev

>
>


0

That's an interesting questions actually. For eample the EAR module does
not contain any information except the application.xml file and the end
result of its build is building all modules that are linked to it (ejbs, web
app, etc) and packing all of the to a single EAR file as a j2ee app. I'm
not sure if I understood completely how your app is packaged from the source
code, but seems like it will work with our new concept.

And is a separate build tool, you may still assign different tasks to build
events of modules. We have nothing to do with it.

And yes, Aurora will open old ipr files but will export path entries to a
separate iml file on save.

Eugene


"Amnon I. Govrin" <agovrin@freshwater.com> wrote in message
news:b456si$bau$1@is.intellij.net...

Hi, Eugene.

>

When you are referring to a Web module, are you referring to html and js
files or a WAR module?

>

Our project is divided in 3 parts called Shared, CoreApp and WebApp. The

end

result of their compilation (which is done only in Ant, not through

IntelliJ

compilation) is a WAR file and several copied JAR files in addition to

some

external config files.

>

Will such a configuration be easily supported? I am referring mostly to

the

ability to have several modules whose packaging is one file.

>

Where does Ant fit here? Will Aurora still have its own compilation
mechanism or are you using Ant as the compilation engine?

>

Also, have you moved the run/debug entries to the project file so that the
iws doesn't need to be checked in? As you recall this was a problem that I
and several others had and at the time the general opinion was that the
placement (level) of settings should be configurable so that if we relate

to

the iws as the user settings and ipr as the project settings the user can
decide what to do. The 3 levels would be global settings, ipr and iws, so
for example a project could have debug entries and users will be able to

add

their own in the iws which wouldn't be checked in.

>

Lastly, will Aurora support loading ipr files from the start or will we

need

to build the project files from scratch?

>

All in all this sounds interesting and I would just be careful to preserve
simplicity and consistency.

>

Amnon

>

"Eugene Belyaev" <beg@intellij.com> wrote in message
news:b45509$6jo$1@is.intellij.net...

Hi all,

>

Here's some information on what is planned to change in a way projects

are

managed in the next version of IDEA. Your opinions are welcome.

>

A project will consist of a set of modules (in simple cases for java

apps

there will usually be only one module). Each module will have its own

set

of working paths, libraries, classpath settings, etc. Basically a

module

is

what current IDEA project is, but with a few additions.

>

Modules can be of different types, where its type defines various

behavioral

aspects of the module. For example modules of type EJB will have its

own

logic of how they are compiled and validation is performed. Also

various

UI

editors may depend on the module type the file is coming from. For

example

ejb-jar.xml from an EJB module will open a DD Editor where from a java
module a simple XML editor.

>

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

>

There will be a possibility to specify dependencies between modules that

are

considered when building the project.

>

For simplicity we will not clutter the UI with a few things like

dependency

management and the like in case when there's only one module in the

project.

Another issue here is that module descriptions are stored as separate
<module name>.iml files and can be imported into any number projects

(while

projects are <project name>.ipr files containing only project-wide

settings

a references to modules it contains). There will be a way to create a

new

module for the project or add an existing one.

>

Now regarding paths. A module will have a set of non-overlapping roots
(most likely just one for most projects, but any number is allowed).

Any

subnode of this root may be assigned as a source path or an exclude

path.

This will be the only way to specify paths.
All this also eliminates the need for multiple output paths. We are

also

planning to introduce a special notion of test source paths containing

test

cases which may get compiled to a different location. We think it's

better

to introduce this special concept instead of having a generic and
hard-to-comprehend one.

>

Please let us know what you think, since it touches quite a few things

in

a

way you work with the tool.

>

Best regards,

>

Eugene Belyaev

>
>

>
>


0

A few questions for you, Eugene:

Will there be a module specifically for JARs, or would that be considered a
Java module?

I'm curious about the granularity of dependencies between modules. Will you
only be able to say that module A depends on module B, or will you be able
to specify it in finer detail (i.e. part 1 or module A depends on part 2 of
module B)?

Regarding paths, I guess you're saying that each module would be able to
specify it's own output path? Combined with a test-source-path notion, that
sounds like it would cover most cases. I've found the existing functionality
quite useful though, so I can't help but worry about losing it...

As Amnon mentioned, it would be nice to know where Ant will fit into all
this too.

Thanks for taking the time to discuss this with us all.
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.


"Eugene Belyaev" <beg@intellij.com> wrote in message
news:b45509$6jo$1@is.intellij.net...

Hi all,

>

Here's some information on what is planned to change in a way projects are
managed in the next version of IDEA. Your opinions are welcome.

>

A project will consist of a set of modules (in simple cases for java apps
there will usually be only one module). Each module will have its own set
of working paths, libraries, classpath settings, etc. Basically a module

is

what current IDEA project is, but with a few additions.

>

Modules can be of different types, where its type defines various

behavioral

aspects of the module. For example modules of type EJB will have its own
logic of how they are compiled and validation is performed. Also various

UI

editors may depend on the module type the file is coming from. For

example

ejb-jar.xml from an EJB module will open a DD Editor where from a java
module a simple XML editor.

>

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

>

There will be a possibility to specify dependencies between modules that

are

considered when building the project.

>

For simplicity we will not clutter the UI with a few things like

dependency

management and the like in case when there's only one module in the

project.

Another issue here is that module descriptions are stored as separate
<module name>.iml files and can be imported into any number projects

(while

projects are <project name>.ipr files containing only project-wide

settings

a references to modules it contains). There will be a way to create a new
module for the project or add an existing one.

>

Now regarding paths. A module will have a set of non-overlapping roots
(most likely just one for most projects, but any number is allowed). Any
subnode of this root may be assigned as a source path or an exclude path.
This will be the only way to specify paths.
All this also eliminates the need for multiple output paths. We are also
planning to introduce a special notion of test source paths containing

test

cases which may get compiled to a different location. We think it's

better

to introduce this special concept instead of having a generic and
hard-to-comprehend one.

>

Please let us know what you think, since it touches quite a few things in

a

way you work with the tool.

>

Best regards,

>

Eugene Belyaev

>
>


0

I will use a simplified version of my current project as an unusual
example that I obviously need to deal with. Say we have three projects:
common, product1, and product2. Part of our architecture (to support
customization by those that buy the products) requires that each product
have a set of "shared" source (given to the customer so that they can
add functionality) and a set of closed or "core" source. So our
projects' file structure looks something like this:

common <-- project for classes that are common to all products
bin <-- build.xml and scripts
closed
shared

product1
bin
closed
config <-- configuration files used when running
shared

The closed and shared directories all contain src and classes
subdirectories. Also, product2's structure is identical to product1.

Okay, now a refresher on the parts of Eugene's message that concern me:

A project will consist of a set of modules

>

Modules can be of different types

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

There will be a possibility to specify dependencies between modules
that are considered when building the project.

<

Now regarding paths. A module will have a set of non-overlapping
roots All this also eliminates the need for multiple output
paths.


Okay, it's obvious that I need the modules for product1 and product2 to
depend upon the modules for common. However, it is important in our
scheme that the closed portions of the products not depend upon the
shared portion of the common project. Without multiple output paths and
a definable order, I think I will have to create a separate module for
each closed and shared directory. What I can't gather from this is what
will happen if I have two modules who's roots overlap. For example if I
create modules that are rooted at the closed directories and then want
modules that are rooted at our project root (common, product1, etc.). If
I exclude the closed directories, will that be sufficient? Otherwise, I
would have to create separate modules for the shared directories and
then separate modules for every other directory that is not within
closed or shared (and there are more than just the bin and config
directories listed above) if I want access to them from IDEA.

Please let us know what you think, since it touches quite a few things
in a way you work with the tool.


Provided that overlapping modules can be dealt with, I'd say this solves
a few of the feature requests that I've seen for project dependendies
without too much confusion. (Realizing that my project itself is the
source of much of my personal confusion.)


~Mike

0

Provided that overlapping modules can be dealt with, I'd say this
solves a few of the feature requests that I've seen for project
dependendies without too much confusion. (Realizing that my project
itself is the source of much of my personal confusion.)


Oh, and I forgot to thank you guys (esp. Eugene for writing the message)
for putting this in front of us and asking for feedback.

So... thanks. ;)


~Mike

0

Amnon I. Govrin wrote:

Also, have you moved the run/debug entries to the project file so that the
iws doesn't need to be checked in? As you recall this was a problem that I
and several others had and at the time the general opinion was that the
placement (level) of settings should be configurable so that if we relate to
the iws as the user settings and ipr as the project settings the user can
decide what to do. The 3 levels would be global settings, ipr and iws, so
for example a project could have debug entries and users will be able to add
their own in the iws which wouldn't be checked in.


I would think that Run/Debug settings are more a module-level setting so
they should be stored in the .iml files. The Run/Debug config drop-down
in the toolbar and menu should probably have the modules as top-level
menu entries with submenus for the configurations available in each module.

Ciao,
Gordon

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

0

Mike,

I understand your need to control dependencies between parts of your
project. But why do you need to compile them into different output
directories?

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


"Mike Abney" <michaelno.abneyspam@retek-nospam-.com> wrote in message
news:Xns9335708523EC6michaelabney1990@213.182.181.98...

I will use a simplified version of my current project as an unusual
example that I obviously need to deal with. Say we have three projects:
common, product1, and product2. Part of our architecture (to support
customization by those that buy the products) requires that each product
have a set of "shared" source (given to the customer so that they can
add functionality) and a set of closed or "core" source. So our
projects' file structure looks something like this:

>

common <-- project for classes that are common to all products
bin <-- build.xml and scripts
closed
shared

>

product1
bin
closed
config <-- configuration files used when running
shared

>

The closed and shared directories all contain src and classes
subdirectories. Also, product2's structure is identical to product1.

>

Okay, now a refresher on the parts of Eugene's message that concern me:

>

A project will consist of a set of modules

>

Modules can be of different types

>

The following types of modules will be supported:
- Java
- EAR Module
- EJB Module
- Web Module

>

There will be a possibility to specify dependencies between modules
that are considered when building the project.

<

Now regarding paths. A module will have a set of non-overlapping
roots All this also eliminates the need for multiple output
paths.

>

Okay, it's obvious that I need the modules for product1 and product2 to
depend upon the modules for common. However, it is important in our
scheme that the closed portions of the products not depend upon the
shared portion of the common project. Without multiple output paths and
a definable order, I think I will have to create a separate module for
each closed and shared directory. What I can't gather from this is what
will happen if I have two modules who's roots overlap. For example if I
create modules that are rooted at the closed directories and then want
modules that are rooted at our project root (common, product1, etc.). If
I exclude the closed directories, will that be sufficient? Otherwise, I
would have to create separate modules for the shared directories and
then separate modules for every other directory that is not within
closed or shared (and there are more than just the bin and config
directories listed above) if I want access to them from IDEA.

>

Please let us know what you think, since it touches quite a few things
in a way you work with the tool.

>

Provided that overlapping modules can be dealt with, I'd say this solves
a few of the feature requests that I've seen for project dependendies
without too much confusion. (Realizing that my project itself is the
source of much of my personal confusion.)

>
>

~Mike



0

In fact, the decision of where to strore Run/Debug configurations is rather
ambigous. Probably, it depends on your project and way of your work. For
example, in IDEA development we store .ipr file in the version control
system but different developers have they own run configurations (e.g unit
tests). That's why we decided to store them at the workspace level.

From other point of view it looks useful to share at least some of the run
configurations. I think that either there should be an option to strore them
all at the project level or at the workspace level, or there should be
ability to mark some of the run configuration to be stored at the project
level.

The situation gets even more complicated with introducing modules. We
decided that the .iws file should correspond to the project, not to the
module (because iws file usually contain settings like last open files, etc
which are difficult to be associated with a particular module). In our
current Aurora version, there is no special "workspace" file for each
module, only for the whole project.
So run-configurations (or a particular run-configuration) can be either
stored in the project file, or in the workspace file or in the module file.

What do you think about this?

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


"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:b45dst$u5l$1@is.intellij.net...

Amnon I. Govrin wrote:

Also, have you moved the run/debug entries to the project file so that

the

iws doesn't need to be checked in? As you recall this was a problem that

I

and several others had and at the time the general opinion was that the
placement (level) of settings should be configurable so that if we

relate to

the iws as the user settings and ipr as the project settings the user

can

decide what to do. The 3 levels would be global settings, ipr and iws,

so

for example a project could have debug entries and users will be able to

add

their own in the iws which wouldn't be checked in.

>

I would think that Run/Debug settings are more a module-level setting so
they should be stored in the .iml files. The Run/Debug config drop-down
in the toolbar and menu should probably have the modules as top-level
menu entries with submenus for the configurations available in each

module.
>

Ciao,
Gordon

>

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

>


0

Valentin Kipiatkov wrote:

So run-configurations (or a particular run-configuration) can be either
stored in the project file, or in the workspace file or in the module file.


That sounds good. Might I suggest that, by default, Application and
Applet configs are stored in the module file (since they're
machine-independent), and JUnit, Remote and WebApp configs are stored in
the workspace file (since they're machine/user-dependent). I don't
imagine project-level run/debug configs would be used that often unless
they somehow involve multiple modules.

Ciao,
Gordon


--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

0


Not sure I understand the intended use here. Is this all just for J2EE stuff, and should be ignored for those of us not using IDEA's J2EE integration? If this partitioning is just for compilation/packaging purposes, would there be any visible changes for those of who use Ant rather than IDEA to do compilation and packaging (like god intended)? How would the all of the (amazingly-wicked-cool) navigation features of IDE be affected? Would there be value or heartache in putting my product source and test cases into separate modules? I guess I could have JUnit in my test classpath but not my source classpath, but are there other effect. Will IDEA flag issues if I try to make a reference from module A to module B if A has not been declared as dependent on B? (That could be very, very cool!) Does this imply you'll be adding automatic JAR file creation to IDEA? Does having test source paths (my feature request, woo hoo) mean you'll be adding some sort of test coverage tooling, (perhaps to the inspections pane)? So many questions.

0

Mostly because they are put into different JAR files. For example:
common.jar
common_shared.jar
product1.jar
product1_shared.jar

That is done so that our customers can replace just the shared source
pieces when they deploy a change. (Note: This is a product that uses
pieces of J2EE, but it uses RMI not EJB and a Swing-based UI rather than
servlets. That means there is no EAR concept to apply here.)


~Mike

"Valentin Kipiatkov" <valentin@intellij.com> wrote in
news:b45fec$2cv$1@is.intellij.net:

Mike,

I understand your need to control dependencies between parts of your
project. But why do you need to compile them into different output
directories?

0


"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:b45icl$8id$1@is.intellij.net...

Valentin Kipiatkov wrote:

So run-configurations (or a particular run-configuration) can be either
stored in the project file, or in the workspace file or in the module

file.
>

That sounds good. Might I suggest that, by default, Application and
Applet configs are stored in the module file (since they're
machine-independent), and JUnit, Remote and WebApp configs are stored in
the workspace file (since they're machine/user-dependent). I don't
imagine project-level run/debug configs would be used that often unless
they somehow involve multiple modules.

I'm not sure I agree with that, as we all use the same run / debug
configurations here, as all the paths are the same relative to the project
path, so our run/debug entries are the same across 7 computers.
>

Ciao,
Gordon

>
>

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

>


0

Amnon I. Govrin wrote:

"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:b45icl$8id$1@is.intellij.net...

>>That sounds good. Might I suggest that, by default, Application and
>>Applet configs are stored in the module file (since they're
>>machine-independent), and JUnit, Remote and WebApp configs are stored in
>>the workspace file (since they're machine/user-dependent). I don't
>>imagine project-level run/debug configs would be used that often unless
>>they somehow involve multiple modules.


I'm not sure I agree with that, as we all use the same run / debug
configurations here, as all the paths are the same relative to the project
path, so our run/debug entries are the same across 7 computers.


I'm assuming you're referring to Run/Debug configs for
JUnit/Remote/WebApp and that you have webserver/external stuff installed
in the same on all your machines, thus those configs should be stored in
the module or project. I think that your situation is unusual and that
most developers on a team will not have external applications/files
installed in the same location on their machines, thus those run/debug
configs should be stored in the workspace.

Ciao,
Gordon

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

0

This subject came up several months ago and the general conclusion was that
it should be possible to save settings in several levels (iws, ipr or
global) to make everybody happy.

Amnon

"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:b45tdp$sg$1@is.intellij.net...

Amnon I. Govrin wrote:

"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:b45icl$8id$1@is.intellij.net...

>>That sounds good. Might I suggest that, by default, Application and
>>Applet configs are stored in the module file (since they're
>>machine-independent), and JUnit, Remote and WebApp configs are stored in
>>the workspace file (since they're machine/user-dependent). I don't
>>imagine project-level run/debug configs would be used that often unless
>>they somehow involve multiple modules.
>

I'm not sure I agree with that, as we all use the same run / debug
configurations here, as all the paths are the same relative to the

project

path, so our run/debug entries are the same across 7 computers.

>

I'm assuming you're referring to Run/Debug configs for
JUnit/Remote/WebApp and that you have webserver/external stuff installed
in the same on all your machines, thus those configs should be stored in
the module or project. I think that your situation is unusual and that
most developers on a team will not have external applications/files
installed in the same location on their machines, thus those run/debug
configs should be stored in the workspace.

>

Ciao,
Gordon

>

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

>


0

My primary concern is for use in creating JAR files as well. I suspect we will be told to use Ant...

Kirk

0

Sounds great,
I'd also really like to be able to define settings
independently on each of the three levels global, project,
module (for whatever settings this might eventually make
sense). Project settings would override global settings and
module settings override project settings.
Netbeans has this style of configuration (but you guys would
definitely be able to make a nicer, easier GUI).
I work concurrently on both an open source framework and
on an application using that framework. Each has its own
separate code style.

Stephen

0

Please make sure you guys handle this one with care. The thing is that the current way of handling this is wrong with the current version (Ariadna) of IDEA. The location of the web server should not be stored in the run configuration for that webapp. The location of all external tools should be stored in the IDEA settings storage and then it should not matter where the web server is located, the run/debug definitions should not care.

This issue has been filed already:
http://www.intellij.net/tracker/idea/viewSCR?publicId=2675

The external tools that I can think of needing attention are:
- The location of the external browser
- The location of the cvs client (as well as any other VCS client)
- The location of the JSP/Servlet container
... probably some more but those are the ones I've come across.

Kind regards, Stefan.

0

I have some comments about this since it's been my holy grail to get this right in Ariadna (I've failed on that quest though).

The module idea sounds good. If it's at all possible I think it might be a good idea to offer means for the community to define their own module types through the OpenAPI if it's at all possible.

Another issue here is that module descriptions are
stored as separate
<module name>.iml files and can be imported into any
number projects (while
projects are <project name>.ipr files containing only
project-wide settings
a references to modules it contains). There will be
a way to create a new
module for the project or add an existing one.


How will file paths be handled here? I've had some issues in the past with file paths since I'm working on Linux and the rest of my team is on Windows. Basically I really like relative paths but as you say it will be possible to use the iml files in multiple projects. If I have a project A in location L and a project B in location L2 and I have a module definition file C in location L3, how will the project files store the path to the module definition file C? My suggestion would be to have an option as is possible with the current version of IDEA to specify the path relative to the project file location. The other aspect is, how will the paths for each modules be stored in the module definition files? My suggestion here would be to store the paths of a module relative to the location of the module definition file and then have IDEA calculate the real location by appending the path definition in the module file to the actual location of that file and thus gaining an absolute path.
The point being: Just make sure that this extra complication to the projects won't result in projects that are not shareable across different platforms and please use absolute paths sparingly (my Linux box really hates paths beginning with "c:\").

Now regarding paths. A module will have a set of
non-overlapping roots
(most likely just one for most projects, but any
number is allowed). Any
subnode of this root may be assigned as a source path
or an exclude path.
This will be the only way to specify paths.


What do you mean by that? I take it that we will also have the ability to add classpath, sourcepath and javadoc path to the module? And on that note, please scrap the current way of specifying those paths per project and use library definitions instead (adding the ability to define libraries on an IDE level, user level and project level... there's actually a fourth level now, a module level). The ability to define a library definition and group together sourcepaths, classpaths and javadoc paths for a given "entity" is very important to me and I've really missed being able to do that on a project level (currently it's only possible to define libraries per IDE... that is, the libraries are accessible to all projects on that machine but not when the project is opened on a different machine). Please have a look at http://www.intellij.net/tracker/idea/viewSCR?publicId=2878 for a more detailed discussion about this issue (btw I really hope that this issue will be opened and assigned to Aurora if it hasn't been already through some other issue number).

All this also eliminates the need for multiple output
paths.


Hmmm... I'm not sure that I wouldn't like to be able to define multiple output paths though. I guess I wouldn't need to do that if I can define a module A and then have modules B and C point to A's output path as their classpath, but still... It's not that hard to implement (just copy the class files to the locations defined) and I really don't think it reduces in any way the ease of use of the IDE.
I want to stress that I haven't had any reason to use multiple output paths, but I have a funny feeling that it wouldn't be a bad thing to offer.

The final question that I have is: when will we be able to get our hands on Aurora through an EAP? We've had some good discussions here on this thread but I'm sure that there are a lot of other usability issues that won't come up until we actually start using the tool and physically hit these walls.

0

1. There will eventually be an ability to define your own module types, but
not sure if it will be open in Aurora.

2. Sure, paths will be stored relatively to module file/project file (ones
that are below the module/project file, or all optionally).

3. The way of defining libraries/classpath/etc will be completely changed as
well.

4.

I guess I wouldn't need to do that if I can define a module A and then

have modules B and C point to A's output path as their classpath, but
still...

You shouldn't do that! That is, you shouldn't add any output paths to the
classpath (actually all that you'll be able to add to the classpath, will be
libraries). Just define appropriate dependencies between your modules and
IDEA will do the rest (that is, include necessary output paths when running
or compiling, recognize necessary sources when doing code-insight).

I want to stress that I haven't had any reason to use multiple output

paths, but I have a funny feeling that it wouldn't be a bad thing to offer.

Actually, having multiple output paths makes UI for setting output paths
more complicated...

5. Aurora EAP will start soon (maybe already today). Although it does not
include real module support yet (the project is already splitted into .ipr
and .iml files but multiple modules are not allowed yet).

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


"Stefan Freyr Stefansson" <stefan_freyr_stefansson@hotmail.com> wrote in
message news:7518396.1046944956301.JavaMail.jrun@is.intellij.net...
I have some comments about this since it's been my holy grail to get this
right in Ariadna (I've failed on that quest though).

The module idea sounds good. If it's at all possible I think it might be a
good idea to offer means for the community to define their own module types
through the OpenAPI if it's at all possible.

Another issue here is that module descriptions are
stored as separate
<module name>.iml files and can be imported into any
number projects (while
projects are <project name>.ipr files containing only
project-wide settings
a references to modules it contains). There will be
a way to create a new
module for the project or add an existing one.


How will file paths be handled here? I've had some issues in the past with
file paths since I'm working on Linux and the rest of my team is on Windows.
Basically I really like relative paths but as you say it will be possible to
use the iml files in multiple projects. If I have a project A in location L
and a project B in location L2 and I have a module definition file C in
location L3, how will the project files store the path to the module
definition file C? My suggestion would be to have an option as is possible
with the current version of IDEA to specify the path relative to the project
file location. The other aspect is, how will the paths for each modules be
stored in the module definition files? My suggestion here would be to store
the paths of a module relative to the location of the module definition file
and then have IDEA calculate the real location by appending the path
definition in the module file to the actual location of that file and thus
gaining an absolute path.
The point being: Just make sure that this extra complication to the projects
won't result in projects that are not shareable across different platforms
and please use absolute paths sparingly (my Linux box really hates paths
beginning with "c:\").

Now regarding paths. A module will have a set of
non-overlapping roots
(most likely just one for most projects, but any
number is allowed). Any
subnode of this root may be assigned as a source path
or an exclude path.
This will be the only way to specify paths.


What do you mean by that? I take it that we will also have the ability to
add classpath, sourcepath and javadoc path to the module? And on that note,
please scrap the current way of specifying those paths per project and use
library definitions instead (adding the ability to define libraries on an
IDE level, user level and project level... there's actually a fourth level
now, a module level). The ability to define a library definition and group
together sourcepaths, classpaths and javadoc paths for a given "entity" is
very important to me and I've really missed being able to do that on a
project level (currently it's only possible to define libraries per IDE...
that is, the libraries are accessible to all projects on that machine but
not when the project is opened on a different machine). Please have a look
at http://www.intellij.net/tracker/idea/viewSCR?publicId=2878 for a more
detailed discussion about this issue (btw I really hope that this issue will
be opened and assigned to Aurora if it hasn't been already through some
other issue number).

All this also eliminates the need for multiple output
paths.


Hmmm... I'm not sure that I wouldn't like to be able to define multiple
output paths though. I guess I wouldn't need to do that if I can define a
module A and then have modules B and C point to A's output path as their
classpath, but still... It's not that hard to implement (just copy the class
files to the locations defined) and I really don't think it reduces in any
way the ease of use of the IDE.
I want to stress that I haven't had any reason to use multiple output paths,
but I have a funny feeling that it wouldn't be a bad thing to offer.

The final question that I have is: when will we be able to get our hands on
Aurora through an EAP? We've had some good discussions here on this thread
but I'm sure that there are a lot of other usability issues that won't come
up until we actually start using the tool and physically hit these walls=


0

Do you need to jar them during your development process or it's only
necessary for a production build?

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

"Mike Abney" <michaelno.abneyspam@retek-nospam-.com> wrote in message
news:Xns9335963F2AA15michaelabney1990@213.182.181.98...

Mostly because they are put into different JAR files. For example:
common.jar
common_shared.jar
product1.jar
product1_shared.jar

>

That is done so that our customers can replace just the shared source
pieces when they deploy a change. (Note: This is a product that uses
pieces of J2EE, but it uses RMI not EJB and a Swing-based UI rather than
servlets. That means there is no EAR concept to apply here.)

>
>

~Mike

>

"Valentin Kipiatkov" <valentin@intellij.com> wrote in
news:b45fec$2cv$1@is.intellij.net:

>

Mike,

>

I understand your need to control dependencies between parts of your
project. But why do you need to compile them into different output
directories?



0

The concept of modules is not only applicable to J2EE development. For
example, you might have two or more projects using the same framework. Then
you might define them all as seperate modules. However, it's not the case
for many plain-java projects and in opposite almost all J2EE application
will have multiple modules.

Even if you don't use IDEA compilation ability, you probably run or debug
with IDEA. Having multiple modules allows you to have different classpaths
when running classes from different modules. The navigation and the like
features will be affected in the way that you won't be allowed to use a
class from module A in a module B unless the module B is declared to depend
on the module A.

Does this imply you'll be adding automatic JAR file creation to IDEA?


What do you mean by "automatic JAR file creation"? How would this feature
work?

Does having test source paths (my feature request, woo hoo) mean you'll be

adding some sort of test coverage tooling, (perhaps to the inspections
pane)?

Maybe in future.

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


"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:6469705.1046896500628.JavaMail.jrun@is.intellij.net...

Not sure I understand the intended use here. Is this all just for J2EE
stuff, and should be ignored for those of us not using IDEA's J2EE
integration? If this partitioning is just for compilation/packaging
purposes, would there be any visible changes for those of who use Ant rather
than IDEA to do compilation and packaging (like god intended)? How would
the all of the (amazingly-wicked-cool) navigation features of IDE be
affected? Would there be value or heartache in putting my product source
and test cases into separate modules? I guess I could have JUnit in my test
classpath but not my source classpath, but are there other effect. Will
IDEA flag issues if I try to make a reference from module A to module B if A
has not been declared as dependent on B? (That could be very, very cool!)
Does this imply you'll be adding automatic JAR file creation to IDEA? Does
having test source paths (my feature request, woo hoo) mean you'll be adding
some sort of test coverage tooling, (perhaps to the inspections pane)? So
many questions.


0

"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b47es4$sof$1@is.intellij.net...

... (actually all that you'll be able to add to the classpath, will be
libraries). ...


Please please please don't take away the ability to add simple jars to the
classpath! This is what JBuilder did when I was still using it and I found
it a major hassle to have to create a new library or update an existing
one whenever I wanted to use a new jar. Being able to add jars directly to
the classpath was a big win for me when I switched to IDEA. Don't get me
wrong: it's great to have the option to create and use libraries, but
forcing it is a step backwards.

5. Aurora EAP will start soon (maybe already today).


Now this is great news!

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

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.


0

We might create a special JARModule that will be able to pack certain
contents from other modules to a JAR file, something like the EAR module is
going to do. However, we are not all set with this and it might not make it
to Aurora though.

Eugene



"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:6469705.1046896500628.JavaMail.jrun@is.intellij.net...

Not sure I understand the intended use here. Is this all just for J2EE
stuff, and should be ignored for those of us not using IDEA's J2EE
integration? If this partitioning is just for compilation/packaging
purposes, would there be any visible changes for those of who use Ant rather
than IDEA to do compilation and packaging (like god intended)? How would
the all of the (amazingly-wicked-cool) navigation features of IDE be
affected? Would there be value or heartache in putting my product source
and test cases into separate modules? I guess I could have JUnit in my test
classpath but not my source classpath, but are there other effect. Will
IDEA flag issues if I try to make a reference from module A to module B if A
has not been declared as dependent on B? (That could be very, very cool!)
Does this imply you'll be adding automatic JAR file creation to IDEA? Does
having test source paths (my feature request, woo hoo) mean you'll be adding
some sort of test coverage tooling, (perhaps to the inspections pane)? So
many questions.


0

Sure, we aren't going to drop ability to add simple jars. That would be a
stupid thing.
I only said that the way of managing libraries would be completely changed.
It's not completly defined with all details yet, but if anyone is interested
I could share this new concept with the community.

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

"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote in message
news:b47g7s$f5$1@is.intellij.net...

"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b47es4$sof$1@is.intellij.net...

... (actually all that you'll be able to add to the classpath, will be
libraries). ...

>

Please please please don't take away the ability to add simple jars to the
classpath! This is what JBuilder did when I was still using it and I found
it a major hassle to have to create a new library or update an existing
one whenever I wanted to use a new jar. Being able to add jars directly to
the classpath was a big win for me when I switched to IDEA. Don't get me
wrong: it's great to have the option to create and use libraries, but
forcing it is a step backwards.

>

5. Aurora EAP will start soon (maybe already today).

>

Now this is great news!

>

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

>

Disclaimer

>

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

>
>


0

>Even if you don't use IDEA compilation ability, you >probably run or debug with IDEA.

Actually not true in my case, but that's just me. I always set up an Ant task to run my code, and haven't used a symbolic debugger in over a decade. IDEA's value to me is 75% Java editor (defined broadly, including refactoring, navigation, layout, completion, search, intentions), 17% Java code checker (including inspections and on-line checking), 5% Local VCS, and 3% Ant integration. I'm trying to evaluate this proposal with respect to those priorities.

>What do you mean by "automatic JAR file creation"? How >would this feature work?

In addition to specifying an output directory for compilation, you would specify a jar file to be created as well. Note that I wouldn't use such a feature, but it has been requested and would fit in somewhat with the modules scheme.

>The navigation and the like features will be affected in >the way that you won't be allowed to use a class from
>module A in a module B unless the module B is declared
>to depend on the module A.

Outstanding! I can have IDEA enforce my package layering semantics for me! Absolutely badass, if you can pull it off.

0

It's not completly defined with all details yet, but if anyone is

interested

I could share this new concept with the community.


I'm interested :) Could you please?

Eugene Belyaev


"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b47lk7$hp2$1@is.intellij.net...

Sure, we aren't going to drop ability to add simple jars. That would be a
stupid thing.
I only said that the way of managing libraries would be completely

changed.

It's not completly defined with all details yet, but if anyone is

interested

I could share this new concept with the community.

>

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

>

"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote in message
news:b47g7s$f5$1@is.intellij.net...

"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b47es4$sof$1@is.intellij.net...

... (actually all that you'll be able to add to the classpath, will be
libraries). ...

>

Please please please don't take away the ability to add simple jars to

the

classpath! This is what JBuilder did when I was still using it and I

found

it a major hassle to have to create a new library or update an

existing

one whenever I wanted to use a new jar. Being able to add jars directly

to

the classpath was a big win for me when I switched to IDEA. Don't get me
wrong: it's great to have the option to create and use libraries, but
forcing it is a step backwards.

>

5. Aurora EAP will start soon (maybe already today).

>

Now this is great news!

>

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

>

Disclaimer

>

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

>
>

>
>


0

Both. I like to build the jars because sometimes during development process I upload to a development server which emulates the final steps. Sometimes I like to have 2 frames open and I would like to fix something in one project, which the second project depends on, and have it jarred up to a Library directory I use for all the jar files involved in projects.

0

Valentin Kipiatkov wrote:

I only said that the way of managing libraries would be completely
changed. It's not completly defined with all details yet, but if anyone is
interested I could share this new concept with the community.


Yes, please! I quite like the way they're being handled currently, and am
curious and a little apprehensive as to what might change...

CU,
Edwin

0

Bummer I sure could use this to create WAR files too, not just EAR and JAR files. It would be also nice to be able to deploy the WAR/EAR/JAR from within IDEA.

0

Valentin Kipiatkov wrote:

I only said that the way of managing libraries would be completely
changed. It's not completly defined with all details yet, but if anyone is
interested I could share this new concept with the community.



Ditto. Please tell us :)

0

Please sign in to leave a comment.