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


0

Ok, I'll describe it briefly.

Along with the set of module roots already described by Eugene eacxh module
will have a set of "libraries". Library is either a simple jar containg
classes of the library, or a directory with classes or a named entity which
groups a few jars/directories together. Also user can associate with a
library one or more jars (or directories) containing source code and one or
more directories or urls with javadoc files. Here is an example structure of
libraries for a module:

Libraries
+-- ! +-- Classes ! +-- c:\jdk1.4.1\jre\lib\rt.jar ! +-- c:\jdk1.4.1\jre\lib\charsets.jar ! ..... +-- Source ! +-- c:\jdk1.4.1\src.zip ! +-- Javadoc +-- http://java.sun.com/j2se/1.4.1/docs/api +--c:\MyProject\lib\mylibrary1.jar ! +--Source ! +--c:\MyProject\lib\src\mylibrary1-src.zip +--Javadoc: (None) +--c:\MyProject\lib\mylibrary2.jar ! +--Source: (None) +--Javadoc: (None) +--MyNamedLibrary +-- Classes ! +-- c:\Libraries\MyNamedLibrary\jar1.jar +-- c:\Libraries\MyNamedLibrary\jar2.jar ! ..... +-- Source +-- c:\Libraries\MyNamedLibrary\src.zip +-- Javadoc +-- c:\Libraries\MyNamedLibrary\javadoc Looks like we should allow a particular named library to be stored either at the module level or at the project level or at the global level. Any feedback is welcome. -- Valentin Kipiatkov JetBrains, Inc http://www.intellij.com "Develop with pleasure!" "Eugene Belyaev" ]]> wrote in message
news:b47pjf$s6a$1@is.intellij.net...

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

Eugene,

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.


I think it's enough to provide some open api which allows one to create a pluggable module.
We will do the rest :)

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.



--
Dmitry Skavish
-


Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com

0

Amnon I. Govrin wrote:

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.


Yes, I totally agree with that. The user should be able to save their
run/debug configurations at whatever level they want. However, what I
was talking about was what the default level is for the different
types of configurations.

Anyway, this horse is quite thoroughly beaten.

Ciao,
Gordon

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

0

(sigh of relief)

Thanks for clarifying that,

Vil.

"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!"



0

Some remarks about the "automatic JAR file creation":
Forte for Java has (had? I didn't use it since I discovered IDEA...) a feature to create a JAR file from within the IDE containing different files out of the current project. After each compilation the modified class files are replaced automatically inside the JAR file.
I know that I can do the same thing with an Ant task, but having some support from IDEA would be great. Maybe by telling IDEA to take the whole content of the output directory and store it in a JAR file, additionally with some help to generate the Manifest file. This would prevent me from generating Ant script files over and over again.

0


Valentin Kipiatkov wrote:


Looks like we should allow a particular named library to be stored either at
the module level or at the project level or at the global level.


And when stored at the project level, the location of the libraries will
be such that they can be checked in CVS? That is why we don't use the
current libraries at all -- because they are stored in a user directory
and cannot be easily shared.

0

Actually we haven't discussed that yet, but seems like it makes sense.

Eugene


"Barry Kaplan" <bkaplan@abwg.com> wrote in message
news:b4840t$ln3$1@is.intellij.net...
>
>

Valentin Kipiatkov wrote:

>

>

Looks like we should allow a particular named library to be stored

either at

the module level or at the project level or at the global level.

>

And when stored at the project level, the location of the libraries will
be such that they can be checked in CVS? That is why we don't use the
current libraries at all -- because they are stored in a user directory
and cannot be easily shared.

>


0

We do generally need to JAR them during development because we have to
deploy some of the JARs to servers. I'd love to have JAR-building (and
RMIC for that matter) built into IDEA, but so long as the code is
compiled to different places, I can do it manually pretty easily.

Regardless, we use Ant a lot for this kind of thing anyway. The thing I
am most worried about isn't compiling or JARing; it's the ability to
have a project set up with a minimum of fuss that properly maps the
dependencies between the projects. The fewer file dialogs I have to see,
the better. ;)


~Mike

"Valentin Kipiatkov" <valentin@intellij.com> wrote in
news:b47eu0$sqj$1@is.intellij.net:

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

0

On Thu, 06 Mar 2003 11:55:29 -0500, Gordon Tyler wrote:

talking about was what the default level is for the different types of
configurations.


Whilst we're talking about changes to the project manager and stuff, could
project-level libraries be defined?

We store along with our projects all the required libs in CVS, it would be
good if we could define a local project level library that points
(relativity) to these libs.

Currently, these get defined and setup on each developers install. I
believe JBuilder has this?

0

On Thu, 06 Mar 2003 15:39:10 +0300, Valentin Kipiatkov wrote:

The concept of modules is not only applicable to J2EE development. For
example, you might have two or more projects using the same framework.


Will the different modules have different version control settings?

0

Valentin Kipiatkov wrote:

Looks like we should allow a particular named library to be stored either
at the module level or at the project level or at the global level.


Yes please, and while you're at it could you please add the ability to store
such a library at the user level?

An example of where this might come in handy is in an academic environment
(school). I teach a course in Java at a University where we have computer
rooms with "public" computers. A student has access to a network drive
that is their personal storage area. When a student works on a project it
is very possible that he would like to store common libraries (such as
JUnit) on their network drive and point to it in many different projects.
This is where user level library definitions would come in handy... The
student could define a library (i.e. JUnit) in their home directory and
would always have access to it, no matter which computer they used and
upgrading JUnit would be a breeze since they can just upgrade one library
definition and it would automatically propagate to all their projects.

Kind regards, Stefan Freyr.

0

Yes, sure. Each module have its own version control settings so e.g.
different modules can even be stored in different version control systems.

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

"Mark Derricutt" <pinhead@satinism.org> wrote in message
news:pan.2003.03.06.23.30.17.7730@satinism.org...

On Thu, 06 Mar 2003 15:39:10 +0300, Valentin Kipiatkov wrote:

>

The concept of modules is not only applicable to J2EE development. For
example, you might have two or more projects using the same framework.

>

Will the different modules have different version control settings?

>


0

Why don't you simply point IDEA's 'config' directory into the user home
directory (BTW this is done automatically by default)? This should solve
this problem.

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

"Stef?n Freyr Stef?nsson" <stefan_freyr_stefansson@hotmail.com> wrote in
message news:b49m7c$hv3$1@is.intellij.net...

Valentin Kipiatkov wrote:

>

Looks like we should allow a particular named library to be stored

either

at the module level or at the project level or at the global level.

>

Yes please, and while you're at it could you please add the ability to

store

such a library at the user level?

>

An example of where this might come in handy is in an academic environment
(school). I teach a course in Java at a University where we have computer
rooms with "public" computers. A student has access to a network drive
that is their personal storage area. When a student works on a project it
is very possible that he would like to store common libraries (such as
JUnit) on their network drive and point to it in many different projects.
This is where user level library definitions would come in handy... The
student could define a library (i.e. JUnit) in their home directory and
would always have access to it, no matter which computer they used and
upgrading JUnit would be a breeze since they can just upgrade one library
definition and it would automatically propagate to all their projects.

>

Kind regards, Stefan Freyr.



0

As you revamp this make sure you treat all project related files (ipr,
iml,...) as regular files and use the VCS/VFS to access them so from within
the idea, we can check them in and out of source control.
Especially fire ModificationAttemptEvent so the files can be checked out
automatically. We checkin the project in in most of our projects.

Thanks

Jacques

"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

The fundamental problem with implementing such functionality is that IDEA
cannot reload project file (as well as module file) when it changes. Doing
this would require all internal components to be reinitialized that is often
rather problematic.

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


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:b4aae1$r4e$1@is.intellij.net...

As you revamp this make sure you treat all project related files (ipr,
iml,...) as regular files and use the VCS/VFS to access them so from

within

the idea, we can check them in and out of source control.
Especially fire ModificationAttemptEvent so the files can be checked out
automatically. We checkin the project in in most of our projects.

>

Thanks

>

Jacques

>

"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 would suggest this problem isn't your problem. Right now if the project
files change (on this hypothetic check out for example) while IDEA is
running they get overwritten right?
What would be the difference here?
In addition most of the advanced VCSes I know will not change the current
content on check out (CVS edit, clearcase checkout,...). They will instead
force the merge at check in time.

Just my 2 cents obviously

Jacques

"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b4afuo$7ig$1@is.intellij.net...

The fundamental problem with implementing such functionality is that IDEA
cannot reload project file (as well as module file) when it changes. Doing
this would require all internal components to be reinitialized that is

often

rather problematic.

>

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

>
>

"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:b4aae1$r4e$1@is.intellij.net...

As you revamp this make sure you treat all project related files (ipr,
iml,...) as regular files and use the VCS/VFS to access them so from

within

the idea, we can check them in and out of source control.
Especially fire ModificationAttemptEvent so the files can be checked out
automatically. We checkin the project in in most of our projects.

>

Thanks

>

Jacques

>

"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

Hi Eugene,

This sounds great, and I'll find it immediatly usefull. One thing though, please try to keep it lightweight, simple, and unobtrusive. Provide a fast-track project setup, for special-case simple projects, and a simplified project view for simple projects too.

Cheers,

Bryan

PS: Good luck with it

0

I would suggest this problem isn't your problem. Right now if the project
files change (on this hypothetic check out for example) while IDEA is
running they get overwritten right?


IDEA will silently overwrite it on the next save...

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


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:b4btja$vpj$1@is.intellij.net...

I would suggest this problem isn't your problem. Right now if the project
files change (on this hypothetic check out for example) while IDEA is
running they get overwritten right?
What would be the difference here?
In addition most of the advanced VCSes I know will not change the current
content on check out (CVS edit, clearcase checkout,...). They will instead
force the merge at check in time.

>

Just my 2 cents obviously

>

Jacques

>

"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b4afuo$7ig$1@is.intellij.net...

The fundamental problem with implementing such functionality is that

IDEA

cannot reload project file (as well as module file) when it changes.

Doing

this would require all internal components to be reinitialized that is

often

rather problematic.

>

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

>
>

"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:b4aae1$r4e$1@is.intellij.net...

As you revamp this make sure you treat all project related files (ipr,
iml,...) as regular files and use the VCS/VFS to access them so from

within

the idea, we can check them in and out of source control.
Especially fire ModificationAttemptEvent so the files can be checked

out

automatically. We checkin the project in in most of our projects.

>

Thanks

>

Jacques

>

"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

Whilst we're talking about changes to the project
manager and stuff, could
project-level libraries be defined?

We store along with our projects all the required
libs in CVS, it would be
good if we could define a local project level library
that points
(relativity) to these libs.

That would be a great idea. I'm not using libraries anymore because of this. I want a project to be an independent unit that I can transfer on my notebook and work on it while I am away from my home base. The concept of libraries as it is currently implemented, makes this difficult.

0

One of the most important features would be the ability to do big refactorings over several modules. This would make me already very happy since I wouldn't have to use Eclipse for this sort of operations.

Another thing is that we use the Eclipse plugin concept and the framework (or plattform if you want to call it that way) to modularize our applications.
For this it would be nice to be able to specify what a module exports - which packages, classes and libs - and naturallily what modules it imports. So we would know if we accidentally use a class that isn't exported before the deployment. Even better we wouldn't do such a mistake since IDEA would complain that it cannot find such a class.

0

One of the most important features would be the ability to do big

refactorings over several modules.

Yes, it should work (given all affected modules are in your project).

For this it would be nice to be able to specify what a module exports -

which packages, classes and libs - and naturallily what modules it imports.
So we would know if we accidentally use a class that isn't exported before
the deployment. Even better we wouldn't do such a mistake since IDEA would
complain that it cannot find such a class.

We already thought about this. BTW, do you think it makes sense for a module
to export its libraries ever? (We know Eclipse supports this but is there
any usecases?)

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

"Robert F. Beeger" <jiveadmin@jetbrains.com> wrote in message
news:33321625.1047216161918.JavaMail.javamailuser@localhost...

One of the most important features would be the ability to do big

refactorings over several modules. This would make me already very happy
since I wouldn't have to use Eclipse for this sort of operations.
>

Another thing is that we use the Eclipse plugin concept and the framework

(or plattform if you want to call it that way) to modularize our
applications.

For this it would be nice to be able to specify what a module exports -

which packages, classes and libs - and naturallily what modules it imports.
So we would know if we accidentally use a class that isn't exported before
the deployment. Even better we wouldn't do such a mistake since IDEA would
complain that it cannot find such a class.


0

We already thought about this. BTW, do you think it
makes sense for a module
to export its libraries ever? (We know Eclipse
supports this but is there
any usecases?)

We have a module that is used by all other modules because of its utility classes. In this module we also have the junit.jar which is exported.
But you are right, JUnit should itself be a module. So I don't have any real usecases for this.
As I think of it, it would be a better design not to export libs. It would make the clients of the module independent of what libs the module uses to realize its functionality.
I think the reason why Eclipse plugins allow the export of libs is that you can only export the contents of jars. Most often those exported jars will contain the classes of the module itself.

0

The other thing that the introduction of Modules will cause: explosion of the number of source roots.
In order to make the source view still user friendly we need to merge all source roots. In other words we really need a real package views not just a directory view that understand java packages.
I opened this request http://www.intellij.net/tracker/idea/viewSCR?publicId=10163

Just for kicks here are some related SCRs:
http://www.intellij.net/tracker/idea/viewSCR?publicId=3132: filter to remove empty packages
http://www.intellij.net/tracker/idea/viewSCR?publicId=3657: project dependency management
http://www.intellij.net/tracker/idea/viewSCR?publicId=4960: independent settings of package flattening between project and source view
http://www.intellij.net/tracker/idea/viewSCR?publicId=7304: split test and tested paths
http://www.intellij.net/tracker/idea/viewSCR?publicId=7710: Allow sourcepath url entries in a library
http://www.intellij.net/tracker/idea/viewSCR?publicId=9549: multiple cvs roots in the source path
http://www.intellij.net/tracker/idea/viewSCR?publicId=4691: file template per projects -> It should be per module now.
http://www.intellij.net/tracker/idea/viewSCR?publicId=4157: (option to) merge code source trees before code inspection
http://www.intellij.net/tracker/idea/viewSCR?publicId=9769: Exclude source from Version Control

Jacques

"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

This one's a bit unrelated to the actual discussion but does anybody know (or have the same problem) why I can't use the link that I'm getting in my e-mail notifications for this thread.

The link that I get at the bottom of each e-mail regarding this thread is:
http://www.intellij.net/tracker/viewSCR?threadId=23952
The link that I had to use to actually get in here is:
http://www.intellij.net/forums/thread.jsp?forum=22&thread=23952

This seems to be the only thread that I'm watching that is having this problem. Is anybody else experiencing that? It might be because this is the only thread that I'm watching that isn't associated with a bug report.

Kind regards,
Stefan Freyr.

0

URL sent in watch notification mail was working properly only for tracker related forums.
This is fixed and link ( /tracker/viewSCR?threadId=23952 ) will be redirected to proper forum thread view.
The fix will be effective sometime by tomorrow morning...

Regards,
--
Tibor Mlynarik
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Stefan Freyr Stefansson" <stefan_freyr_stefansson@hotmail.com> wrote in message
news:10467510.1047287577006.JavaMail.jrun@is.intellij.net...

This one's a bit unrelated to the actual discussion but does anybody know (or have the same problem) why I can't use the link

that I'm getting in my e-mail notifications for this thread.
>

The link that I get at the bottom of each e-mail regarding this thread is:
http://www.intellij.net/tracker/viewSCR?threadId=23952
The link that I had to use to actually get in here is:
http://www.intellij.net/forums/thread.jsp?forum=22&thread=23952

>

This seems to be the only thread that I'm watching that is having this problem. Is anybody else experiencing that? It might be

because this is the only thread that I'm watching that isn't associated with a bug report.
>

Kind regards,
Stefan Freyr.



0

In article <b45509$6jo$1@is.intellij.net>,
"Eugene Belyaev" <beg@intellij.com> wrote:

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.


This sounds like the solution to some of our problems. Thus far, only
Eclipse has been able to handle our project design without serious pain,
but it sounds like this will enable IDEA to handle it just as easily.

We have the following structure, with a dozen libs and a hundred
projects:

build
-build.xml (knows how to build persist, persist_jdbc, dbwriter, dbdesign)
libraries
-log4j.jar
metagraph
-persistence
--persist
--persist_jdbc (depends persist, log4j)
-application
--dbwriter (depends persist, persist_jdbc, log4j)
--dbdesign (depends persist)
products
-persist.jar
-persist_jdbc.jar
-dbwriter.jar
-dbdesign.jar

a single project, such as persist, is laid out as:
source
-org
--metagraph
---persistence
-


persist
-


someSource.java
source-generated (optional)
jar-resources (optional)
ant_build
eclipse_build

From what I hear you saying, we would have eclipse projects in each
directory.

The persist project would have just one java module
The persist_jdbc project would have two modules, one for persist_jdbc,
and one for persist. (Or would it be three - one more for the log4j
library?)
The dbwriter project would have modules for persist, persist_jdbc, and
its own code
The dbdesign project would have modules for persist and its own code

Obviously, this will make it a lot easier to move a class from one
package to another within a project, or between projects, just by
carefully selecting which module I apply the 'move' refactoring to.
Usually, when that happens, we also change the package, but there is no
reason why this has to be one step. (The most common time for this is
when some code moves from a closed source project to one of the more
fundemental open source projects we run.)

Obvious questions:

Is it possible to have just one module definition file for persist, that
every other project will depend on?

Will this make opening projects that have twenty dependencies slow?

Will it be easy to find the places a depended-on project is used? A
single project like persist may be used in 25 or thirty seperate
applications, and likely they all should not be in the same overall
project. If nothing else, it would be a truly immense project with
thousands and thousands of classes.

Put another way: if I change a class in persist, I would really like to
know whether this will break something in dbwriter or dbdesign. If I
was working on persist, I may not have dbdesign or dbwriter open.

All in all, this looks like an effective change to IDEA, so I am in
favor of it. Any idea when this will end up implemented well enough to
start testing? (We will be generating the project files via xslt, so a
spec is more important than the ui.)

0

Although it is hard to read this thread at this stage (I haven't read EAP quite some time) here a few comments related to EAR/WAR/EJB-JAR issues:

1. Please don't assume that a J2EE project is made up of WAR/EJB-JAR components only. There are certain "components" which are just regular java libraries which need to be deployed to a J2EE application. Depending on the application server they might be a simple Manifest.MF entry or need to be deployed to all J2EE components (WAR -> lib/ or extracted to ejb-jar file)

2. WEB-INF/ META-INF location.
Please allow to specify a top level dir which contains a WEB-INF/META-INF directory, since some application servers use top level deployment descriptors (e.g. pramati server). During deployment the content of this directory needs to be part of the J2EE module. PLEASE DON'T assume a regular WAR/EJB archive for modules. Don't get me wrong, but I believe the typical EJB/WAR layout is nothing more than a toy.

3. J2EE means component reuse
Please consider some support for existing EJB modules. In most cases you need to adjust the app server specific deployment descriptor in an already existing EJB Archive only.

4. XDoclet
More and more people use XDoclet. This could break a descriptor based concept.

Just my 2 Cent.
Jens

0

请先登录再写评论。