Please revive "Weekly progress news"

Any chance we can get a periodic progress report from JetBrains on how
things are coming for 4.1 & 4.0.1 (and 5.0 if that is being worked on)?

Thanks,
Jon

30 comments

Jon Steelman wrote:

Any chance we can get a periodic progress report from JetBrains on how
things are coming for 4.1 & 4.0.1 (and 5.0 if that is being worked on)?

Thanks,
Jon


Yeah, why not? :)

As you may know 4.0.1 is bugfix update only release. 1174 which is just anounced provides some critical fixes to XML
support/schema validation (one could happen to have StackOverflowError in 1172 due to this bug). Many reports were fired
against XML indentation behaviour on paste so that is fixed as well. Severe but rarely reproducible bug in make is also
fixed. So, if nothing awful happens 1172 + some help system updates will become 4.0.1 in a couple of days.

As for 4.1 we're mainly working on the following areas:
1. OpenAPI for J2EE. One should be able to provide other application server integration plugins.
Unfortunately we are to redesign and refactor our current j2ee implementation severly.
2. JDK1.5 features: autoboxing/unboxing, foreach syntax, annotations are mostly covered. Enums and <? extends/supers>
extentions are coming.
3. UI Designer: Generate Dialog class wizard. In early progress right now.
4. Make: Lot of changes are to be made in order to handle generics-caused dependencies.
5. Package dependencies: mostly done. Some cosmetic issues yet to be addressed.
6. Ant 1.6: Oh, some refactorings needed there as will. Though IDEA is no longer tightly bound to the specific ANT
version. Its only proper syntax 1.6 highlighting features left.
7. Structured code search is ready. Replace is coming soon. Interface is somewhat preliminary right now though.
8. J2EE Deployment view is mostly done. As well as j2ee module dependencies.

I'm sure I've missed something. Will include in next week's newsletter :)

--
Maxim Shafirov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

One option I think for j2ee integration should definitely be JSR-88, this would work same as the JSR-45 stuff for web. Vendors can have their own plugins if they want, but there's a generic JSR-88 plugin for servers that support it but don't have custom plugins.

0

Any chance that the native file IO watching for OS X might make it in 4.1?

0

A weekly progress letter sounds like a great idea! Is there a topic that I can put a watch on?

0

>1. OpenAPI for J2EE. One should be able to provide other application server integration plugins.
Unfortunately we are to redesign and refactor our current j2ee implementation severly.

Well, this will make Hani happy, if that's not a contradiction in terms.

>2. JDK1.5 features: autoboxing/unboxing, foreach syntax, annotations are mostly covered. Enums and <? extends/supers> extentions are coming.

Cool, I was looking forward to writing some 1.5 inspections. Static imports are definitely a code smell.

>5. Package dependencies: mostly done. Some cosmetic issues yet to be addressed.

Sounds incredibly cool. What is it? Something like Pasta?

>6. Ant 1.6: Oh, some refactorings needed there as will. Though IDEA is no longer tightly bound to the specific ANT
version. Its only proper syntax 1.6 highlighting features left.

Yea!

>7. Structured code search is ready. Replace is coming soon. Interface is somewhat preliminary right now though.

Sounds incredibly cool. What is it? Something like Juliet?

Thanks for the update.

--Dave Griffith


0

5. Package dependencies: mostly done. Some cosmetic issues yet to be
addressed.


A gift from heaven! I've been using pasta and the new optimalj for this.
Its not too bad, and with fileassociations plugin I get to the code
quite quickly. You guys (jetbrains) might want to scan their forum for
all the suggestions I and others have put there.

0

Maxim Shafirov (JetBrains) wrote:

Yeah, why not? :)


Wonderful! And all I had to do was ask.

Severe but rarely reproducible bug in make is also fixed.


Which make bug would that be? I have a friend who is evaluating IDEA 4
for his company on a project with just under 2000 java files but he
cannot get a build to work. This plain java project will apparently
build from the command line or inside of Eclipse. He wants to give IDEA
a fair shake, but I'm not able to isolate the problem for him as I can't
gain access to the source other than looking at his laptop over lunch
where the the simple though large project appeared to be setup properly.
Strangely, the compilation problem has some of the same symptoms as when
you try to do an explicit compile and other classes/packages haven't yet
been compiled. However, in this case the problem manifests when he
Builds the entire project. Needless to say, the compilation issue is a
show stopper for his even conducting a fair evaluation. I wish there
were something I could do to have this addressed.

Thank you for the newsletter.

Jon

0

The bug was that make sometimes did not recompile subclasses if certain methods were added to the base class.
From your description it looks like the problem is not related to the bug fixed. I might assume that it has something to do with the
project configuration.
Could you please describe the problm in detail?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Jon Steelman" <jon@cc.gatech.edu> wrote in message news:c2m9lb$lvr$1@is.intellij.net...

Maxim Shafirov (JetBrains) wrote:

Yeah, why not? :)

>

Wonderful! And all I had to do was ask.

>

Severe but rarely reproducible bug in make is also fixed.

>

Which make bug would that be? I have a friend who is evaluating IDEA 4
for his company on a project with just under 2000 java files but he
cannot get a build to work. This plain java project will apparently
build from the command line or inside of Eclipse. He wants to give IDEA
a fair shake, but I'm not able to isolate the problem for him as I can't
gain access to the source other than looking at his laptop over lunch
where the the simple though large project appeared to be setup properly.
Strangely, the compilation problem has some of the same symptoms as when
you try to do an explicit compile and other classes/packages haven't yet
been compiled. However, in this case the problem manifests when he
Builds the entire project. Needless to say, the compilation issue is a
show stopper for his even conducting a fair evaluation. I wish there
were something I could do to have this addressed.

>

Thank you for the newsletter.

>

Jon



0

I'm sure I've missed something. Will include in next
week's newsletter :)


hi Maxim,

a clear statement would be nice if aspectj support has been completely dropped or not. AFAIK, aspectj support has been planned for 4.1

/björn


0

The aspectJ support is neither completely dropped nor planned for 4.1.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"bkueb" <no_mail@jetbrains.com> wrote in message news:22447747.1078904536920.JavaMail.itn@is.intellij.net...

I'm sure I've missed something. Will include in next
week's newsletter :)


hi Maxim,

a clear statement would be nice if aspectj support has been completely dropped or not. AFAIK, aspectj support has been planned for
4.1

/björn




0

Michael Werle wrote:

Any chance that the native file IO watching for OS X might make it in 4.1?

Definetely yes. It's just not the thing we're woring on right now.

--
Maxim Shafirov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Hani Suleiman wrote:

One option I think for j2ee integration should definitely be JSR-88, this would work same as the JSR-45 stuff for web. Vendors can have their own plugins if they want, but there's a generic JSR-88 plugin for servers that support it but don't have custom plugins.


I'm not in the stream right now so, mmm, a stupid question: what application servers do support JSR-88 for the moment?

--
Maxim Shafirov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Hm, no word on JSP 2.0 feature support in 4.1 so far?

regards
Michael

0

Michael J wrote:

Hm, no word on JSP 2.0 feature support in 4.1 so far?

regards
Michael

I'm affraid no. This is going to be addressed in 5.0

--
Maxim Shafirov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Unfortunately I don't have access to the IDEA project or java source. My
friend works for another company and was only able to show it to me on a
laptop briefly. That's what is so frustrating - all I had the time to do
was confirm that the project appeared to be setup correctly.
Furthermore, a contractor at the company uses IDEA 3.0 and has the same
java source setup in a project on 3.0 and it compiles without a hitch.
It is aggravating me that I can't isolate this problem for him. I even
asked if he could send me all the source with the guts of all the
methods hollowed out so that I didn't have the source, just the skeleton
as such, but he can't do it.

Jon

Eugene Zhuravlev wrote:

The bug was that make sometimes did not recompile subclasses if certain methods were added to the base class.
From your description it looks like the problem is not related to the bug fixed. I might assume that it has something to do with the
project configuration.
Could you please describe the problm in detail?

0

JSR-88 is required for J2EE 1.4 compliance, so any server that claims to support that spec has to support JSR-88. Basically you would just require the user to pick the server plugin jar that specifies the deployment factory, then call the appropriate API to deploy/configure/undeploy a web/client/app module, or check running stattus etc.

0

In article <c2mljf$mcr$1@is.intellij.net>,
"Maxim Shafirov (JetBrains)" <max@intellij.com> wrote:

Michael Werle wrote:

Any chance that the native file IO watching for OS X might make it in 4.1?

Definetely yes. It's just not the thing we're woring on right now.


This is something I would sure like to see.

Scott

0

Not sure if it's the same situation, but here's a problem I've encountered at some point that looks similar to your friend's.

My project is a mirror of an Eclipse project. I've hacked some code to convert the Eclipse modules into IDEA modules, so not to be afraid I miss some settings when I set up the project. And, as in your case (or your friend's I should say), the whole thing compiles fine from ant and Eclipse.

However, IDEA failed to build it (although no errors where shown on the class that failed to compile). The problem I found was related to the modules structure and the way the dependencies are not transitive between them. Here's the structure:

module1: ClassA
module2: ClassB extends ClassA. Module2 depends on module1.
module3: ClassC code uses ClassB from module2 (and, obviously, module3 depends on module2).

Now, when I try to build this with IDEA, ClassC fails to compile, saying it cannot find ClassB. Now ClassB is definitely OK, and the editor does not have a problem with it, but I suspect IDEA is confused about ClassB extending ClassA, which module3 does not have direct connection with (since module3 does not depend on module1). Somehow, even after ClassB's module is compiled, IDEA still complains about not being able to get to ClassB when it builds. And it complains about ClassB, not ClassA (which would be a fairly straight hint), on top of not showing any errors in the editor.

The workaround is to add module1 to module3's dependencies list. So look for this type of class hierarchies spanning multiple modules and the dependencies between those modules, you might have the same problem.

HTH,
Andrei

I wasn't sure if this was a bug or part of the known modules dependencies limitations, but now that I put it in words I might as well fill in a bug report and see what JetBrains say. :)


JS> Which make bug would that be? I have a friend who is evaluating IDEA
JS> 4 for his company on a project with just under 2000 java files but
JS> he cannot get a build to work. This plain java project will
JS> apparently build from the command line or inside of Eclipse. He
JS> wants to give IDEA a fair shake, but I'm not able to isolate the
JS> problem for him as I can't gain access to the source other than
JS> looking at his laptop over lunch where the the simple though large
JS> project appeared to be setup properly. Strangely, the compilation
JS> problem has some of the same symptoms as when you try to do an
JS> explicit compile and other classes/packages haven't yet been
JS> compiled. However, in this case the problem manifests when he
JS> Builds the entire project. Needless to say, the compilation issue is
JS> a show stopper for his even conducting a fair evaluation. I wish
JS> there were something I could do to have this addressed.
JS>
JS> Thank you for the newsletter.
JS>
JS> Jon
JS>

0

This is not a defect, but I'd say this behaviour is "by design".
Are there any serious reasons why sources physically should be stored on disk in one source root? What's the problem if they were
stored in a different source roots and each of them were included into a separate module? It doesn't prevent one to have the same
package present in different source rtoots, so the package structure of the application remains the same. I don't see any problems
in breaking one source root into several roots. Moreover, this approach has an advantage that the modular structure of the whole
project becomes more explicit.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

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

Any chance that defect 20491 (http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) will be dealt with?

>

(please)



0

The workaround is to add module1 to module3's dependencies list. So look for this type of class hierarchies spanning multiple

modules and the dependencies >between those modules, you might have the same problem.

Or another workaround is to have module's output paths point to the same directory.
Sure the problem exists, we'll think about the solution.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



"Andrei Oprea" <andrei.oprea@rogers.com> wrote in message news:c2o2s8$kt1$1@is.intellij.net...

Not sure if it's the same situation, but here's a problem I've encountered at some point that looks similar to your friend's.

>

My project is a mirror of an Eclipse project. I've hacked some code to convert the Eclipse modules into IDEA modules, so not to be

afraid I miss some settings when I set up the project. And, as in your case (or your friend's I should say), the whole thing
compiles fine from ant and Eclipse.
>

However, IDEA failed to build it (although no errors where shown on the class that failed to compile). The problem I found was

related to the modules structure and the way the dependencies are not transitive between them. Here's the structure:
>

module1: ClassA
module2: ClassB extends ClassA. Module2 depends on module1.
module3: ClassC code uses ClassB from module2 (and, obviously, module3 depends on module2).

>

Now, when I try to build this with IDEA, ClassC fails to compile, saying it cannot find ClassB. Now ClassB is definitely OK, and

the editor does not have a problem with it, but I suspect IDEA is confused about ClassB extending ClassA, which module3 does not
have direct connection with (since module3 does not depend on module1). Somehow, even after ClassB's module is compiled, IDEA still
complains about not being able to get to ClassB when it builds. And it complains about ClassB, not ClassA (which would be a fairly
straight hint), on top of not showing any errors in the editor.
>

The workaround is to add module1 to module3's dependencies list. So look for this type of class hierarchies spanning multiple

modules and the dependencies between those modules, you might have the same problem.
>

HTH,
Andrei

>

I wasn't sure if this was a bug or part of the known modules dependencies limitations, but now that I put it in words I might as

well fill in a bug report and see what JetBrains say. :)
>
>

JS> Which make bug would that be? I have a friend who is evaluating IDEA
JS> 4 for his company on a project with just under 2000 java files but
JS> he cannot get a build to work. This plain java project will
JS> apparently build from the command line or inside of Eclipse. He
JS> wants to give IDEA a fair shake, but I'm not able to isolate the
JS> problem for him as I can't gain access to the source other than
JS> looking at his laptop over lunch where the the simple though large
JS> project appeared to be setup properly. Strangely, the compilation
JS> problem has some of the same symptoms as when you try to do an
JS> explicit compile and other classes/packages haven't yet been
JS> compiled. However, in this case the problem manifests when he
JS> Builds the entire project. Needless to say, the compilation issue is
JS> a show stopper for his even conducting a fair evaluation. I wish
JS> there were something I could do to have this addressed.
JS>
JS> Thank you for the newsletter.
JS>
JS> Jon
JS>

>


0

Eugene Zhuravlev wrote:

This is not a defect, but I'd say this behaviour is "by design".
Are there any serious reasons why sources physically should be stored on disk in one source root?

History. You might have a project that was started before developers
discovered the marvel that was Idea and so it doesn't necessarily follow
Idea's recommended structure... and if you're using CVS it is really
painful to create a new module and move all the files there since you
lose the history.

What's the problem if they were
stored in a different source roots and each of them were included into a separate module? It doesn't prevent one to have the same
package present in different source rtoots, so the package structure of the application remains the same. I don't see any problems
in breaking one source root into several roots. Moreover, this approach has an advantage that the modular structure of the whole
project becomes more explicit.

Sure this might be the correct way to do it if you're starting from
scratch, but that's not always possible.

Robbie

0

Are there any serious reasons why sources physically should be stored on disk in one source root?


I agree with you (we have different source roots for different modules),
but I guess, there are IDEA users, who want to use different modules and
do not have the possibility to store them in different source roots
(e.g. because they are "just small developers in a large company")?

Tom

0

Eugene,

Yes, I'd agree this behaviour is "by design" but I believe that this design is incorrect. This design does not take into account the many projects that are already in existence that do not follow your source directory convention.

As other people have stated, moving lots of source files around in a multi user project (and probably changing Ant scripts) just because the IDE requires it is not an attractive proposition nor a compelling argument for the use of IntelliJ throughout the organization.

FYI, this issue has been discussed many times in many threads:
http://www.intellij.net/forums/thread.jsp?forum=22&thread=51598
http://www.intellij.net/forums/thread.jsp?forum=22&thread=55047
http://www.intellij.net/forums/thread.jsp?forum=22&thread=64781
http://www.intellij.net/forums/thread.jsp?forum=22&thread=73699

0

I actually prefer a single source root. Each directory should be able to be
assigned to a different module. Actually, each file should be able to
override the directory module setting.

Some of the advantages are:

- Prevents different modules from having the same class name, including
package structure, with different content.
If not prevented, this is a ticking time bomb. Even IDEA's debugger
cannot properly handle this.

- Encourages code reuse.
If everyone sees the same package structure, they are more likely to
discover classes that can be reused between modules.
Once they are discovered, it is only a module/ant configuration change to
make them shared, not a version control nightmare.

- Simplifies version control storage and retrieval.
I don't have to go to multiple VC roots to pull the latest version of my
entire project source code.

- Legacy code and/or Management mandates.
I don't always have control over the physical storage of the source
files, so this is always a possibility.
This can usually be overcome by creative use of your version control
systems get/checkout mapping functionality,
but this can also be a real headache.

- Enhancing the first impression of new IDEA users.
If IDEA is to be marketed to new users, it should adapt to their current
source code layout, not the other way around.
First impressions can make or break the decision to switch to IDEA.

I'm sure that there are other advantages and reasons for allowing a single
source root to be shared among multiple modules.

Please consider implementing this enhancement ASAP.

Thanks,

Tim Haley
Principal Consultant
Keane, Inc. - Carolinas Branch

"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:c2p8ou$and$1@is.intellij.net...

This is not a defect, but I'd say this behaviour is "by design".
Are there any serious reasons why sources physically should be stored on

disk in one source root? What's the problem if they were

stored in a different source roots and each of them were included into a

separate module? It doesn't prevent one to have the same

package present in different source rtoots, so the package structure of

the application remains the same. I don't see any problems

in breaking one source root into several roots. Moreover, this approach

has an advantage that the modular structure of the whole

project becomes more explicit.

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>

"David Macklem" <no_mail@jetbrains.com> wrote in message

news:5034653.1078939440605.JavaMail.itn@is.intellij.net...

Any chance that defect 20491

(http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) will be dealt
with?

>

(please)

>
>


0

>> Are there any serious reasons why sources physically should be stored
>> on disk in one source root?
>>
TS> I agree with you (we have different source roots for different
TS> modules), but I guess, there are IDEA users, who want to use
TS> different modules and do not have the possibility to store them in
TS> different source roots (e.g. because they are "just small
TS> developers in a large company")?
TS>


Or because they prefer to use IDEA in a project where everybody else is using another IDE (which dictates the standard directory structure). This used to be one of IDEA's selling points, that it didn't force its way upon you, it worked however you wanted it to. And it was a very strong one, I managed to convince lots of people to try it out (and they, eventually, switched to it) only because it was almost painless for them to use it "in parallel" for a while.

This kind of sales pitch is visibly harder these days. I'd hate to see IDEA's popularity result in inflexibility, after all that was one of the reasons people left other IDEs and found their home here.

My 2c,
Andrei

0

Eugene, I must agree with the vocal majority. Idea should not impose a
physical structure on projects. It will just hinder the ability to
inject idea into organizations.


Eugene Zhuravlev wrote:

This is not a defect, but I'd say this behaviour is "by design".
Are there any serious reasons why sources physically should be stored on disk in one source root? What's the problem if they were
stored in a different source roots and each of them were included into a separate module? It doesn't prevent one to have the same
package present in different source rtoots, so the package structure of the application remains the same. I don't see any problems
in breaking one source root into several roots. Moreover, this approach has an advantage that the modular structure of the whole
project becomes more explicit.


--
Barry Kaplan
Integrated Trading Solutions
bkaplan@integratedtrading.com

0

+1000 Especially for code reuse.

Frankly, I don't see any serious advantages with different source roots,
but I do see serious potential problems with it. I totally agree that having
different source roots with duplicated package structure is a time bomb
and must be considered as a malpractice. If you have groups of classes
which get used separately in different modules they must form different
packages.
As a matter of fact, my experience shows the opposite (to the IDEA's
module paradigm) tendency. The code gets reused more and more,
so more and more differents projects tend to be located under the
same source root and share the same code base. So I'm much more
interested in ability to exclude some packages/files from my current
project build (but not from my IDEA workspace!) rather than in
ability to include some files from other places. So my source code
structure tends to look like the following:

src/
package1/
Class11
Class12
Class13
package2/
Class21
Class22
Class23
main
Project1MainClass (uses Class12, Class22)
Project2MainClass (uses Class12, Class23)

Please note that while working on different projects I still can refactor
their common codebase. Having all of them "under one roof" allows me
to do it safely and efficiently. The only problem with this approach is
that when you have to ship the application you may end up with
some unnesessary classes included with your shipment. For example
jar for Project2 may include Class11 which is not used.

In other words, the ideal project paradigm for me would include
one (or more if you like) source roots reflecting package structure
and an ability to create multiple views on this same structure rather
than physically separate files into different places.

BTW can you just prepend source path with the project or module name?
For example
Project1/src/ or Project1:src/ or some other syntax
Project2/src/ or Project2:src/
With such a small modification you can reuse your current project mashinery and
solve all the problems since you would get literally different source roots
pointed to the same source path (i.e. src/).

--Oleg

"Tim Haley" <ymaraner@yahoo.com> wrote in message news:c2pssj$7ub$1@is.intellij.net...

I actually prefer a single source root. Each directory should be able to be
assigned to a different module. Actually, each file should be able to
override the directory module setting.

>

Some of the advantages are:

>

- Prevents different modules from having the same class name, including
package structure, with different content.
If not prevented, this is a ticking time bomb. Even IDEA's debugger
cannot properly handle this.

>

- Encourages code reuse.
If everyone sees the same package structure, they are more likely to
discover classes that can be reused between modules.
Once they are discovered, it is only a module/ant configuration change to
make them shared, not a version control nightmare.

>

- Simplifies version control storage and retrieval.
I don't have to go to multiple VC roots to pull the latest version of my
entire project source code.

>

- Legacy code and/or Management mandates.
I don't always have control over the physical storage of the source
files, so this is always a possibility.
This can usually be overcome by creative use of your version control
systems get/checkout mapping functionality,
but this can also be a real headache.

>

- Enhancing the first impression of new IDEA users.
If IDEA is to be marketed to new users, it should adapt to their current
source code layout, not the other way around.
First impressions can make or break the decision to switch to IDEA.

>

I'm sure that there are other advantages and reasons for allowing a single
source root to be shared among multiple modules.

>

Please consider implementing this enhancement ASAP.

>

Thanks,

>

Tim Haley
Principal Consultant
Keane, Inc. - Carolinas Branch

>

"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:c2p8ou$and$1@is.intellij.net...

This is not a defect, but I'd say this behaviour is "by design".
Are there any serious reasons why sources physically should be stored on

disk in one source root? What's the problem if they were

stored in a different source roots and each of them were included into a

separate module? It doesn't prevent one to have the same

package present in different source rtoots, so the package structure of

the application remains the same. I don't see any problems

in breaking one source root into several roots. Moreover, this approach

has an advantage that the modular structure of the whole

project becomes more explicit.

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>

"David Macklem" <no_mail@jetbrains.com> wrote in message

news:5034653.1078939440605.JavaMail.itn@is.intellij.net...

Any chance that defect 20491

(http://www.intellij.net/tracker/idea/viewSCR?publicId=20491) will be dealt
with?

>

(please)

>
>

>
>


0

Sounds like you need a real VCS ;)

0

I make use of various opensource projects. Sometimes I'd like to have them in my project so the source is easily browsable. Sometimes, I want to remove them. Why should I have to bring them under some root project tree in order to do this?

+100000 for not imposing this arbitrary restriction on me like eclipse does.

0

Please sign in to leave a comment.