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
Please sign in to leave a comment.
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...
>
>
>
>
a
be
directly
me
but
this
>
>
Eugene,
I think it's enough to provide some open api which allows one to create a pluggable module.
We will do the rest :)
--
Dmitry Skavish
-
Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com
Amnon I. Govrin wrote:
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"
(sigh of relief)
Thanks for clarifying that,
Vil.
"Valentin Kipiatkov" <valentin@intellij.com> wrote in message
news:b47lk7$hp2$1@is.intellij.net...
changed.
interested
>
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.
Valentin Kipiatkov wrote:
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.
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...
>
>
>
either at
>
>
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:
On Thu, 06 Mar 2003 11:55:29 -0500, Gordon Tyler wrote:
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?
On Thu, 06 Mar 2003 15:39:10 +0300, Valentin Kipiatkov wrote:
Will the different modules have different version control settings?
Valentin Kipiatkov wrote:
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.
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...
>
>
>
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...
>
either
>
store
>
>
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...
>
>
is
>
behavioral
UI
example
>
>
are
>
dependency
project.
(while
settings
>
test
better
>
a
>
>
>
>
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...
within
>
>
>
are
apps
set
module
own
various
new
Any
path.
also
in
>
>
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...
often
>
>
>
that
roots
>
>
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
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...
>
>
>
IDEA
Doing
out
projects
own
its
java
separate
a
containing
things
>
>
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.
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.
refactorings over several modules.
Yes, it should work (given all affected modules are in your project).
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...
refactorings over several modules. This would make me already very happy
since I wouldn't have to use Eclipse for this sort of operations.
>
(or plattform if you want to call it that way) to modularize our
applications.
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 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.
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...
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.
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...
that I'm getting in my e-mail notifications for this thread.
>
>
because this is the only thread that I'm watching that isn't associated with a bug report.
>
In article <b45509$6jo$1@is.intellij.net>,
"Eugene Belyaev" <beg@intellij.com> wrote:
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.)
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