It seems you can only add classes to a library that you create on the Libraries tab of the Main Module properties. If you try to add an application library or a project library (via the respective buttons on the Order tab of the Main Module properties), there is no way to add classes to the libraries. No way that I can find, anyway. :-/
>
Go to "Add Project Library" dialog, and choose "Configure". Application and Project libraries cannot be configured in module libraries tab. Is this ugly or confusing? Better ideas?
Yeah ultra confusing. I'd hate to say this, but when someone click a button to add a library, there should be an option to go through some kind of wizard. If you don't do that, I think the second option is to provide more than just a library name, you need to popup a window with lib name, file browser, and other things you need so we can do it all right away, now have to click in a zillion places to set things up.
I also think that there should be no differentiation between Project libs and module libs from the stand point of setting it up. You should just have 2 check boxes to make the libs module or project libs, or perhaps even both. The point is, do everything from one place.
R
>
>
Also, the libraries that you create in the Library tab don't show up in the list of application libraries or the list of project libraries. Are they intended to be module specific libraries, or is this just something that's not working properly yet?
>
These are module specific libraries.
>
Friendly, Dmitry
>
-- Dmitry Lomov IntelliJ Labs / JetBrains Inc. http://www.intellij.com "Develop with pleasure!"
True, but I didn't explain myself well. With the option to add jars in directory I also meant sub dirs.
For example, I have a directory called Libraries, and in there I have a whole bunch of directories organizing various jar files I use. I would love to be able to point to the Libraries folder and then have it dig down and pull all the jars out for me. Just like I can choose the Ant directory inside the Library directory and have it pull all the jars available for use with Ant.
>>I would imagine this coudl be extended to possibly detect test paths as >>well.
That we didn't think about yet. Any ideas how it should be done?
>
Well, I assume you detect source paths by looking at the file extensions in the path. Perhaps if you saw Java files in the path, you could go one step further to see whether they extend any of the interesting JUnit classes, at which point the path would be a good candidate for being in the "Test Paths" folder. Other cues might be if the folder is called something common, like "test" or "tests" or "junit" and appears to have a valid package structure below it.
I agree, I think previous versions would give you the ability to confirm the paths that were auto-selected (at least for source folder auto-detection). I would not want it to automatically add to the project for me.
Peter
Valentin Kipiatkov wrote:
That's possible to implement, just not sure that it will give correct results all the time.
I agree, but if we can combine auto select with a preview of what it picked up on, then we can add what ever it missed, if it missed anything.
I say give it a shot, and see what happens, it's definitely more productive to have IDEA fetch the jars it thinks we're intending to get. Of course if a library ends with .zip it might miss it if you're looking for jar files specifically, or add a zip file which is not intended to be an archive of interest.
I agree, I think previous versions would give you the ability to confirm the paths that were auto-selected (at least for source folder auto-detection). I would not want it to automatically add to the project for me.
>
Peter
>
Valentin Kipiatkov wrote:
That's possible to implement, just not sure that it will give correct results all the time.
What you see in "Main module" tab is in fact a configuration of one
module.
Currently we have one module per project, but this will change in a near future. As soon as this changes, we will have an "Add Module" button.
THIS should have been the first thing said in the faq.
I (and it seems everyone else) thought that each added "Content" was a module.
So, what we are testing here is only ONE module parametrization/integration. It clears some problems I was seeing with the libs - project libs - application libs.
"Add Folder" should be context sensitive: selection is in the source
tree
-> add sources, etc.
>
If you do not have a source folder, you do not know what is a source tree
:)
A new Content automatically has "Source Folders" entry, so how can you not have a source tree?
We have a better idea for content editing: when you add a content for a mdoule, you get a view with its subdirs, then you mark some of them as source folders, and exclusde others.
Seems good.
What's a project library? Why is it different than an entry in the libraries tab?
>
The point is that those libraries are stored on project level (shared between modules) or on application level (shared between projects)
Knowing that this entire panel is just one module in (a future) multi module panel clears this problem.
More wackiness: there's another thread going on at the moment about a new "Package" view along with/instead of the current "Project", "Sourepath" and "Classpath" views. The above list I've described is begining to sound a lot like these views combined. Would it be possible to just do all the editing I've described above out in the project sidebar? It all seems so much the same it could possibly be "refactored" all together.
This is beginning to sound a little like the way Forte used to work (I don't know if it still works this way), where you "mount" file systems on the left side, which comprise the whole structure of your project.
I don't know if that's good or bad. I remember being very confused by this at the time, but I don't really remember why :$
This is going to be a question of deployment versus development, but...
With the new "Application" libraries, and "Module" libraries, I'm left a bit concerned about developing a project using IDEA and Ant.
For example, I'm moving to a process whereby I can have my CVS repository accessible either by IDEA, or by Ant, such that a simple checkout of the build script can fully build any version, or IDEA itself can do it.
So this gets a bit confusing with "Application" libraries, because I don't know if they are stored, or should be stored, along with the project. I mean, what's the point of having them if you can't deploy them, or vice versa, if you have to include the .jar plus the source for EVERY project, why have them called "Application" libraries at all?
I guess where I'm headed with this is to really evaluate how to use IDEA as part of build management. I regularly compile all my code in IDEA, but when I use my build script in Ant (also through IDEA) I can address questions of deployment, recompiling, etc. And the same goes with tests, too: IDEA can run JUnit tests, and so can Ant. But how do libraries fit in to the module concept of IDEA, and what should I do about it with respect to the Ant build script?
>>The point is that those libraries are stored on project >>level (shared between modules) or on application level >>(shared between projects)
This is the first definition of "application level" I've seen. Prior to reading this I had no idea what was meant or intended. I was thinking it referred to libraries for the application I was working on.
If an "Application Library" is shared between projects, why not label it "Cross Project Libraries". I envision things like struts.jar or junit.jar in here. It would also be helpful to include a label in the Select Libraries window to suggest things which might be appropriate things to include here (such as struts, junit, log4j, etc.)
I might have missed it so I'll keep reading and/or re-read the posts in this thread, but my next mission is to figure out
---what is a "module"? ---what is the true meaning of "project" library? (granted these libraries are shared between "modules", so I am back to square one: what is a "module"?
:)
I like where they are headed with this...it just needs some polish.
JBuilder calls them User Libraries, which makes sense since they're specific to a single user of the application rather than all users. This is only going to be noticable in multi-user installations, obviously. Unless I'm mistaken and these libraries really are going to be available to every user of a particular IDEA installation, I'd vote to have them called User Libraries.
Vil.
Carlos Costa e Silva wrote:
"Application Libraries" doesn't convey any meaning: what is an application?
Some suggestions:
Global Libraries Common Libraries Local Libraries Idea Libraries Installed Libraries
>>The point is that those libraries are stored on project >>level (shared between modules) or on application level >>(shared between projects)
> >
This is the first definition of "application level" I've seen. Prior to
reading this I had no idea what was meant or intended. I was thinking it referred to libraries for the application I was working on. >
If an "Application Library" is shared between projects, why not label it
"Cross Project Libraries". I envision things like struts.jar or junit.jar in here. It would also be helpful to include a label in the Select Libraries window to suggest things which might be appropriate things to include here (such as struts, junit, log4j, etc.) >
I might have missed it so I'll keep reading and/or re-read the posts in
this thread, but my next mission is to figure out >
---what is a "module"? ---what is the true meaning of "project" library? (granted these
libraries are shared between "modules", so I am back to square one: what is a "module"? > >
:)
>
I like where they are headed with this...it just needs some polish.
>> What you see in "Main module" tab is in fact a configuration of one
module.
>> Currently we have one module per project, but this will change in a near >> future. As soon as this changes, we will have an "Add Module" button.
THIS should have been the first thing said in the faq.
I (and it seems everyone else) thought that each added "Content" was a module.
True. But the guys here told me: "don't worry, they will figure this out by themselves" :).
>> > "Add Folder" should be context sensitive: selection is in the source
tree
>> > -> add sources, etc. >> >> If you do not have a source folder, you do not know what is a source tree
:)
A new Content automatically has "Source Folders" entry, so how can you not have a source tree?
Well, the "source folder" is a root of your Java code (that is, your packages start from there)/icons/configuration XMLs etc. It is not always possible to say whether given folder in content is a source folder (otherwise we won't need this config). Or am I missing something?
>> between modules) or on application level (shared between projects)
Yup, it was stupid of us to name them "Application level libraries". (For those of you who know enough OpenAPI, application libraries are stored in application level component, hence the weird name). Will be fixed soon ("Cross-project library" is a good name, IMHO)
Cheers, Dmitry
-- Dmitry Lomov IntelliJ Labs / JetBrains Inc. http://www.intellij.com "Develop with pleasure!"
"Cross-project libraries" as suggested by Michael Morrett in other thread sounds good to me. What would you say?
Friendly, Dmitry
Vilya Harvey wrote:
JBuilder calls them User Libraries, which makes sense since they're specific to a single user of the application rather than all users. This is only going to be noticable in multi-user installations, obviously. Unless I'm mistaken and these libraries really are going to be available to every user of a particular IDEA installation, I'd vote to have them called User Libraries.
Vil.
Carlos Costa e Silva wrote:
>> "Application Libraries" doesn't convey any meaning: what is an >> application? >> >> Some suggestions: >> >> Global Libraries >> Common Libraries >> Local Libraries >> Idea Libraries >> Installed Libraries >> >> >> More ideas anyone? >> >> Carlos
-- Dmitry Lomov IntelliJ Labs / JetBrains Inc. http://www.intellij.com "Develop with pleasure!"
Really, as long as I know what they are, I don't really mind what they're called. There are definitely more important things to worry about! :)
Vil.
Dmitry Lomov wrote:
"Cross-project libraries" as suggested by Michael Morrett in other thread sounds good to me. What would you say?
Friendly, Dmitry
Vilya Harvey wrote:
>>JBuilder calls them User Libraries, which makes sense since they're >>specific to a single user of the application rather than all users. This >>is only going to be noticable in multi-user installations, obviously. >>Unless I'm mistaken and these libraries really are going to be available >>to every user of a particular IDEA installation, I'd vote to have them >>called User Libraries. >> >>Vil. >> >>Carlos Costa e Silva wrote: >> >>>"Application Libraries" doesn't convey any meaning: what is an >>>application? >>> >>>Some suggestions: >>> >>>Global Libraries >>>Common Libraries >>>Local Libraries >>>Idea Libraries >>>Installed Libraries >>> >>> >>>More ideas anyone? >>> >>>Carlos >> >>
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.
>>Really, as long as I know what they are, I don't really mind what they're >>called. There are definitely more important things to worry about! :)
Namely?
I was thinking of larger issues like sorting out the general usability issues with the module/content/library UI when I wrote that. That and the GUI builder, of course: can't wait to give that a try! :)
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.
True. But the guys here told me: "don't worry, they will figure this out
by
themselves" :).
Ah, as part of the user comunity I'm very sorry to have failed your expectations ;)
>> > "Add Folder" should be context sensitive: selection is in the source
tree
>
Well, the "source folder" is a root of your Java code (that is, your packages start from there)/icons/configuration XMLs etc. It is not always possible to say whether given folder in content is a source folder (otherwise we won't need this config). Or am I missing something?
The "context sensitive" part applied to the Content panel, not to the directory dialog. When you add a Content, an empty "Source Folders" entry is automatically added -> when this "Source Folders" entry is selected and the "Add..." button is pressed, the context is defined.
But in the meantime the customized add panel mentioned on another thread (ability to add mutiple folders and define folder type in the add directory panel) will probably make this point obsolete.
You touch on a question that I've been thinking about for a while. In our project we use ant build files to authoritatively express library dependencies (and build/deploy structure, etc). But of course IDEA needs to know what these dependencies are, so I have to maintain them through the project's properties as well.
It sure would be nice if IDEA could somehow glean from our ant build files what libraries were needed for a given subproject/module. Then the library dependencies could defined once and only once.
There's some overlap between ant an IDEA that has to be kept in sync manually.
I am using build #823 and am having a problem resolving classes in referenced jar files (e.g. rt.jar). When I add a jar to the Libraries tab intellij resolves the package names but is unable to resolve the actual class. For instance I have class foo in package a.b.c. foo will be red but a.b.c. is black. What am I doing wrong?
I found my problem. This was caused by a poorly structured project and migrating from pre-Aurora. The project previously built to sources and then attempted to use the "ignore files and folders" on the IDE - General Setting Tab to exclude *.class. This was done in hopes of not seeing the class files in the project pane. This had no effect pre-Aurora however in Auroa the outcome is as I describe.
"Dmitry Lomov" <dsl@intellij.com> wrote in message
news:ba0iu8$btr$1@is.intellij.net...
>
>
Yeah ultra confusing. I'd hate to say this, but when someone click a button
to add a library, there should be an option to go through some kind of
wizard. If you don't do that, I think the second option is to provide more
than just a library name, you need to popup a window with lib name, file
browser, and other things you need so we can do it all right away, now have
to click in a zillion places to set things up.
I also think that there should be no differentiation between Project libs
and module libs from the stand point of setting it up. You should just have
2 check boxes to make the libs module or project libs, or perhaps even both.
The point is, do everything from one place.
R
>
>
>
>
"Dmitry Peshehonov" <dyoma@intellij.com> wrote in message
news:ba0ms8$lej$1@is.intellij.net...
/
>
>
it
How about Add...?
Also it would be good to have the option when we add JARs to choose a
directory and have IDEA add all the jars in a directory.
>
>
>
Multiple selection is enabled when adding jars (if not it is bug). It seems
enough since adding many jars is far from everyday task.
--
Best regards,
Dmitry Peshehonov
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Robert S. Sfeir" <robert@codepuccino.com> wrote in message
news:ba2p04$br8$1@is.intellij.net...
>
Application
Libraries
>
>
>
>
>
True, but I didn't explain myself well. With the option to add jars in
directory I also meant sub dirs.
For example, I have a directory called Libraries, and in there I have a
whole bunch of directories organizing various jar files I use. I would love
to be able to point to the Libraries folder and then have it dig down and
pull all the jars out for me. Just like I can choose the Ant directory
inside the Library directory and have it pull all the jars available for use
with Ant.
R
"Dmitry Peshehonov" <dyoma@intellij.com> wrote in message
news:ba2qat$g8u$1@is.intellij.net...
seems
>
>
will
>
>
That's possible to implement, just not sure that it will give correct
results all the time.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Peter Mularien" <pmularien@dNeOpSlPoAyM.com> wrote in message
news:ba2ogn$a08$1@is.intellij.net...
>
>
>
I agree, I think previous versions would give you the ability to confirm
the paths that were auto-selected (at least for source folder
auto-detection). I would not want it to automatically add to the project
for me.
Peter
Valentin Kipiatkov wrote:
I agree, but if we can combine auto select with a preview of what it picked
up on, then we can add what ever it missed, if it missed anything.
I say give it a shot, and see what happens, it's definitely more productive
to have IDEA fetch the jars it thinks we're intending to get. Of course if
a library ends with .zip it might miss it if you're looking for jar files
specifically, or add a zip file which is not intended to be an archive of
interest.
R
"Peter Mularien" <pmularien@dNeOpSlPoAyM.com> wrote in message
news:ba2vai$tcs$1@is.intellij.net...
>
>
>
module.
THIS should have been the first thing said in the faq.
I (and it seems everyone else) thought that each added "Content" was a
module.
So, what we are testing here is only ONE module parametrization/integration.
It clears some problems I was seeing with the libs - project libs -
application libs.
tree
>
:)
A new Content automatically has "Source Folders" entry, so how can you not
have a source tree?
Seems good.
>
Knowing that this entire panel is just one module in (a future) multi module
panel clears this problem.
Carlos
This is beginning to sound a little like the way Forte used to work (I don't know if it still works this way), where you "mount" file systems on the left side, which comprise the whole structure of your project.
I don't know if that's good or bad. I remember being very confused by this at the time, but I don't really remember why :$
"Application Libraries" doesn't convey any meaning: what is an application?
Some suggestions:
Global Libraries
Common Libraries
Local Libraries
Idea Libraries
Installed Libraries
More ideas anyone?
Carlos
Carlos Costa e Silva wrote:
Public Libraries? :)
R
This is going to be a question of deployment versus development, but...
With the new "Application" libraries, and "Module" libraries, I'm left a bit concerned about developing a project using IDEA and Ant.
For example, I'm moving to a process whereby I can have my CVS repository accessible either by IDEA, or by Ant, such that a simple checkout of the build script can fully build any version, or IDEA itself can do it.
So this gets a bit confusing with "Application" libraries, because I don't know if they are stored, or should be stored, along with the project. I mean, what's the point of having them if you can't deploy them, or vice versa, if you have to include the .jar plus the source for EVERY project, why have them called "Application" libraries at all?
I guess where I'm headed with this is to really evaluate how to use IDEA as part of build management. I regularly compile all my code in IDEA, but when I use my build script in Ant (also through IDEA) I can address questions of deployment, recompiling, etc. And the same goes with tests, too: IDEA can run JUnit tests, and so can Ant. But how do libraries fit in to the module concept of IDEA, and what should I do about it with respect to the Ant build script?
Carlos Costa e Silva wrote:
+1
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919
>>The point is that those libraries are stored on project
>>level (shared between modules) or on application level
>>(shared between projects)
This is the first definition of "application level" I've seen. Prior to reading this I had no idea what was meant or intended. I was thinking it referred to libraries for the application I was working on.
If an "Application Library" is shared between projects, why not label it "Cross Project Libraries". I envision things like struts.jar or junit.jar in here. It would also be helpful to include a label in the Select Libraries window to suggest things which might be appropriate things to include here (such as struts, junit, log4j, etc.)
I might have missed it so I'll keep reading and/or re-read the posts in this thread, but my next mission is to figure out
---what is a "module"?
---what is the true meaning of "project" library? (granted these libraries are shared between "modules", so I am back to square one: what is a "module"?
:)
I like where they are headed with this...it just needs some polish.
JBuilder calls them User Libraries, which makes sense since they're specific
to a single user of the application rather than all users. This is only
going to be noticable in multi-user installations, obviously. Unless I'm
mistaken and these libraries really are going to be available to every user
of a particular IDEA installation, I'd vote to have them called User Libraries.
Vil.
Carlos Costa e Silva wrote:
--
__
o| . / \|o. _ _ ._ _ ._ _ |
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
The term "Application" got into the UI by mistake. It should be "Global" or
something like that.
--
Eugene Belyaev, CTO
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Michael Morett" <michaelmorett@yahoo.com> wrote in message
news:4688464.1053121741944.JavaMail.jrun@is.intellij.net...
>
>
reading this I had no idea what was meant or intended. I was thinking it
referred to libraries for the application I was working on.
>
"Cross Project Libraries". I envision things like struts.jar or junit.jar
in here. It would also be helpful to include a label in the Select
Libraries window to suggest things which might be appropriate things to
include here (such as struts, junit, log4j, etc.)
>
this thread, but my next mission is to figure out
>
libraries are shared between "modules", so I am back to square one: what is
a "module"?
>
>
>
Carlos Costa e Silva wrote:
>> What you see in "Main module" tab is in fact a configuration of one
>> Currently we have one module per project, but this will change in a near
>> future. As soon as this changes, we will have an "Add Module" button.
True. But the guys here told me: "don't worry, they will figure this out by
themselves" :).
>> > "Add Folder" should be context sensitive: selection is in the source
>> > -> add sources, etc.
>>
>> If you do not have a source folder, you do not know what is a source tree
Well, the "source folder" is a root of your Java code (that is, your
packages start from there)/icons/configuration XMLs etc. It is not always
possible to say whether given folder in content is a source folder
(otherwise we won't need this config). Or am I missing something?
>> between modules) or on application level (shared between projects)
Yup, it was stupid of us to name them "Application level libraries". (For
those of you who know enough OpenAPI, application libraries are stored in
application level component, hence the weird name). Will be fixed soon
("Cross-project library" is a good name, IMHO)
Cheers,
Dmitry
--
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
"Cross-project libraries" as suggested by Michael Morrett in other thread
sounds good to me. What would you say?
Friendly,
Dmitry
Vilya Harvey wrote:
>> "Application Libraries" doesn't convey any meaning: what is an
>> application?
>>
>> Some suggestions:
>>
>> Global Libraries
>> Common Libraries
>> Local Libraries
>> Idea Libraries
>> Installed Libraries
>>
>>
>> More ideas anyone?
>>
>> Carlos
--
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
"Interproject Libraries"?
Tom
On Mon, 19 May 2003 11:10:24 +0400, Dmitry Lomov <dsl@intellij.com> wrote:
>
Really, as long as I know what they are, I don't really mind what they're
called. There are definitely more important things to worry about! :)
Vil.
Dmitry Lomov wrote:
>>JBuilder calls them User Libraries, which makes sense since they're
>>specific to a single user of the application rather than all users. This
>>is only going to be noticable in multi-user installations, obviously.
>>Unless I'm mistaken and these libraries really are going to be available
>>to every user of a particular IDEA installation, I'd vote to have them
>>called User Libraries.
>>
>>Vil.
>>
>>Carlos Costa e Silva wrote:
>>
>>>"Application Libraries" doesn't convey any meaning: what is an
>>>application?
>>>
>>>Some suggestions:
>>>
>>>Global Libraries
>>>Common Libraries
>>>Local Libraries
>>>Idea Libraries
>>>Installed Libraries
>>>
>>>
>>>More ideas anyone?
>>>
>>>Carlos
>>
>>
--
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/
DisclaimerThis 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.
Vilya Harvey wrote:
Namely?
--
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
Dmitry Lomov wrote:
>>Really, as long as I know what they are, I don't really mind what they're
>>called. There are definitely more important things to worry about! :)
I was thinking of larger issues like sorting out the general usability
issues with the module/content/library UI when I wrote that. That and the
GUI builder, of course: can't wait to give that a try! :)
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/
DisclaimerThis 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.
"Dmitry Lomov" <dsl@intellij.com> wrote in message
news:baa03v$e00$1@is.intellij.net...
>
by
Ah, as part of the user comunity I'm very sorry to have failed your
expectations ;)
>
The "context sensitive" part applied to the Content panel, not to the
directory dialog. When you add a Content, an empty "Source Folders" entry is
automatically added -> when this "Source Folders" entry is selected and the
"Add..." button is pressed, the context is defined.
But in the meantime the customized add panel mentioned on another thread
(ability to add mutiple folders and define folder type in
the add directory panel) will probably make this point obsolete.
Carlos
You touch on a question that I've been thinking about for a while. In our project we use ant build files to authoritatively express library dependencies (and build/deploy structure, etc). But of course IDEA needs to know what these dependencies are, so I have to maintain them through the project's properties as well.
It sure would be nice if IDEA could somehow glean from our ant build files what libraries were needed for a given subproject/module. Then the library dependencies could defined once and only once.
There's some overlap between ant an IDEA that has to be kept in sync manually.
I am using build #823 and am having a problem resolving classes in referenced jar files (e.g. rt.jar). When I add a jar to the Libraries tab intellij resolves the package names but is unable to resolve the actual class. For instance I have class foo in package a.b.c. foo will be red but a.b.c. is black. What am I doing wrong?
/Luke
I found my problem. This was caused by a poorly structured project and migrating from pre-Aurora. The project previously built to sources and then attempted to use the "ignore files and folders" on the IDE - General Setting Tab to exclude *.class. This was done in hopes of not seeing the class files in the project pane. This had no effect pre-Aurora however in Auroa the outcome is as I describe.