Long awaited Demetra roadmap
can be found at http://www.jetbrains.net/confluence/display/IDEADEV/Demetra+Roadmap
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Please sign in to leave a comment.
Wow! Some of this is REALLY cool, even to a cynical angry jaded bitter old man like me!
Does this mean that IDEA will now have a central server component, that all instances can connect to to perform some of this stuff? (CI, serverside analysis, etc)
If this is the case, I'm hoping you make sure that offline support works flawlessly, given how many people code on the move.
As the developer of the tesng plugin, I think putting too many resources into junit4 support is a bit early, given that it's not released yet and is being developed in secret. Much nicer instead to refactor the existing junit support to make it more reusable.
This all looks cool although I'd like to see more focus on editor and
refactoring, as they are and will always be the core of modern Java editing. I
also think enhancement of nullable/notnull would be important for productivity
(special highlighting for nullability of a value in the editor, completion
popup, ctrl+p, etc).
You should make sure the continuous build and build server integration is
implemented 100% using OpenAPI. We use a huge custom build and continuous
testing platform and we're not going to switch to your system, but we would
probably like to use the integration and we would probably be willing to develop
custom plugin for it.
It's also important to us to integrate code reviews. We use perforce command
line tools for this now, but we'd like to use IDEA for it.
Hello Hani,
Glad to please you :)
Quite right.
Sure. If I recall correctly these kind of things are known to be the most
significant problem with stuff like maven so we'll try to avoid stepping
in their shoes.
Yep, that's true. But that will most probably be released before Demetra
release so we'll experience a great pressure on that. On the other hand having
another test runner developed internally we'll get an infrastructure open
enough to plug TestNG more flawlessly as well, right?
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Hello Keith,
No doubts we'll do it. It's just too obvious and there too many small items
there to mention in road map.
I'm not sure any particular API no matter how full is that will be able to
carry out everything possible here.
If you'd describe in a few words what your custom build is we'd try to make
sure it can embed easily into our build system.
Well, that's fine but we're lack of real use cases here thus it's hard to
decide what exactly this feature should do.
Again, it would be nice to hear from you on this.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Keith Lea wrote:
+1
I think however that basic enhancements of functionality and usability are covered, even
though they're not explicitly listed.
+10
This stuff is so extremely cool that there should definitely be some automated help for
introducing and maintaining those annotations based on code analysis of what can be null,
can not be null and must not be null.
http://www.jetbrains.net/jira/browse/IDEA-2002
+1
I also don't think a proprietary build system will have any chance. Most build setups are
wickedly complicated using Ant, Maven, etc. and can not be moved to something else without
major hassle. This absolutely has to be pluggable.
Sascha
Hello Sascha,
First of all we do support plain ant builds and will most probably support
maven.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> I also think enhancement of nullable/notnull would be important for
>> productivity (special highlighting for nullability of a value in
>> the editor, completion popup, ctrl+p, etc).
>
+10 from me too. And there are probably quite a few other things that
can be done in this area to improve static inspections. For example,
when using lazy initialization there can be fields and variables that
can only go from null to non-null, never the other way around. Having
an annotation for this would mean getting rid of a number of false
warnings. Nullness of array elements or container contents is also not
covered in the current version.
Maybe have code reviews work like code coverage (see the clover plugin), where it's possible for a reviewer to mark off bits of code as being reviewed, and then having a toggle to show review bars.
Another feature that I've been hoping for since 3.0 is incremental background compilation. IDEA already knows so much about the structure of sources, so why not just go the final step and spit it out into bytecode on the fly?
Wow! Incredibly ballsy. If you can even pull 75% of this off, it'll be industry-changing. In particular, stuff like
>Code Coverage Integration
>Incremental test run. Rerun only tests that execute changed code
>Project wide error highlighting
>Separate dependencies for module interface, implementation, and test parts
>Instant messaging including code pointers,
>P2P sources sync
should truly rule.
All your little languages are belong to us.
My eyes glazed over on Project portal until I saw
>Share project-wide configurations
>Server-side code analysis results
You wouldn't happen to be looking for a metrics tool to go with that? Managers love pretty numbers on web sites!
And finally, gloriously
>Global Inspection API
If you'll all excuse me, I think I need a cigarette.
--Dave Griffith
Hello Hani,
Indeed, nothing prevents us from implementing this but performance considerations.
As we're planning to implement "project wide error highlighting" feature
we'll be forced to solve those performance issues that we'll most probably
have background compilation in Demetra.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Maxim,
>> Most build setups are wickedly complicated using Ant, Maven, etc. and
That's great to hear, but the roadmap does not really imply that. I made that assumption
because currently IDEA's build and packaging lacks a lot of flexibility and some features
like the deployment of j2ee modules fundamentally rely on it.
Sorry for jumping the gun on this.
Cheers,
Sascha
Hello Sascha,
Pardon, I'll correct this.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Very interesting.
What about extending support for JavaScript?
What about integrating 'going-back' technology so that when a problem
happens one can go back (there's a product that does that, don't
remember what is its name).
The server component is surely a very important piece of Demetra, though
I am concerned it will add complexity to managing IntelliJ and offline
work, which is why it may be a good idea to support using IDEA even
without the server component available (I'm sure you thought about all
of that, so disregard if so).
Thanks for sharing,
Amnon
Hello Amnon,
It's there on the last line of the map.
Would you please explain in a bit more details. I'm affraid I do not follow.
We sincerely hope for exactly opposite!
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>Would you please explain in a bit more details. I'm affraid I do not follow.
Omnicore's "Back in Time" debugger, perhaps? Technically very cool, but I've never heard anyone say it was a killer app.
After the improvements in Irida, it looks like they've decided that the debugger is basically completed functionality. Can't say I disagree.
--Dave Griffith
Hello Maxim,
MS> can be found at
MS> http://www.jetbrains.net/confluence/display/IDEADEV/Demetra+Roadmap
AWESOME! personally I can't wait to use the continuous testing and the seemingly
MUCH improved testing framework support.
Way to go.
R
Dave Griffith wrote:
>>What about integrating 'going-back' technology
>>Would you please explain in a bit more details. I'm affraid I do not follow.
Yeah, I guess you're right. Can't say I ever needed it so much even to
trial it, though I came close a couple of times :)
Amnon
Maxim Shafirov (JetBrains) wrote:
>> What about extending support for JavaScript?
Oops, I guess I looked for it in the wrong place.
>> What about integrating 'going-back' technology
What Dave G says is correct, I did mean that.
>> it will add complexity to managing IntelliJ
Back in time is handy! Another nice addition to the debugger would be being able to set a breakpoint in the middle of a line, vs a specific line, for example:
blah.doSomething(new Foo())
I'd like the breakpoint to be set at 'doSomething', which means that when it's hit, new Foo() has already been called.
Note that this IS different from just setting a breakpoint at doSomething in the Blah class, since that would be called for every invocation, not just when new Foo() is passed in.
Maxim Shafirov (JetBrains) wrote:
>> more focus on editor and refactoring
Cool, I'm excited about it
>> You should make sure the continuous build and build server integration
>> is implemented 100% using OpenAPI.
I don't know technical details about most of the build system, but I know it is
old, actively developed & supported, and complex. As long as the user can have a
similarly friendly and useful experience with our build system as with your
build server, I will feel good about it. I plan to stay involved in these
features and let you know how it looks as things develop.
>> It's also important to us to integrate code reviews.
No code can be submitted here until a Perforce CL is created, then it must be
reviewed and approved. Here, you choose who you want (or need) to get approval
from, and an email is sent to them. They run some command line diff tools to get
a basic idea of how the code works. When you receive an approval email, you
commit using p4 commit -c xx -a xx.
1. The code to be reviewed is never built or run or even checked for syntax
errors because we use a simple diff tool and not IDEA. It would be wonderful for
IDEA to be able to treat the code as real code, allowing navigation, etc.
2. Communication is not its best. Integration with the new idetalk stuff would
be cool and useful, but probably only used 10% of the time here. Usually we walk
over and ask about something, or for more structured feedback we send an email.
Sascha Weinreuter wrote:
>>You should make sure the continuous build and build server integration is
>>implemented 100% using OpenAPI. We use a huge custom build and continuous
>>testing platform and we're not going to switch to your system, but we would
>>probably like to use the integration and we would probably be willing to
>>develop
>>custom plugin for it.
I think a proprietary build system that allows for hacky shell scripts and
collections of ant builds and enhances the process, without requiring extra
work or imposing its own standards and restrictions, will be very popular.
Many times lately I've wanted back in time debugger, considering how
asynchronous things like OpenAPI are.
Dave Griffith wrote:
>>What about integrating 'going-back' technology
>>Would you please explain in a bit more details. I'm affraid I do not follow.
Hani Suleiman wrote:
I guess that at least some of the time you could get away with a
conditional breakpoint in 'doSomething', but I guess not always.
It would be a bit tricky to convey to the user where exactly the
breakpoint is, but I guess it could be done with refined highlighting
(not the full line) and the tooltip when hovering above the breakpoint
icon in the gutter.
Amnon
Tell me more about "Delayed commit: build and commit if successful". Does that mean I can setup the version control commit process so that attempted developer commits will be immediately rejected (with feedback?) if the project doesn't build on the server so the current head will always be in a buildable state?
Are you really planning on accomplishing all of the features in this huge list in one big 6.0 release instead of some smaller interim releases? The feature list is so extensive that I worry 6 will be years in the making.
Jon
Hello Amnon,
This is not only presentation problem but JPDA API only allows setting breakpoints
on per-line basis.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Back in time is handy! Another nice addition to the debugger would be
>> being able to set a breakpoint in the middle of a line, vs a specific
>> line, for example:
>>
>> blah.doSomething(new Foo())
>>
>> I'd like the breakpoint to be set at 'doSomething', which means that
>> when it's hit, new Foo() has already been called.
>>
>> Note that this IS different from just setting a breakpoint at
>> doSomething in the Blah class, since that would be called for every
>> invocation, not just when new Foo() is passed in.
>>
Hello Jon,
Yep, you understood quite right.
At least we'll try. As the matter of fact there were so many nice ideas that
didn't get into the list. We have to limit ourselves.
Well, of course there will be EAP for the thing and we're hope we will be
able to keep the things usable from the very beginning so you may count it
as intermediate releases.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
It requires a custom compiler which embeds false line numbers for each expression.
Maxim Shafirov (JetBrains) wrote:
>> Hani Suleiman wrote:
>>
>>> Back in time is handy! Another nice addition to the debugger would be
>>> being able to set a breakpoint in the middle of a line, vs a specific
>>> line, for example:
>>>
>>> blah.doSomething(new Foo())
>>>
>>> I'd like the breakpoint to be set at 'doSomething', which means that
>>> when it's hit, new Foo() has already been called.
>>>
>>> Note that this IS different from just setting a breakpoint at
>>> doSomething in the Blah class, since that would be called for every
>>> invocation, not just when new Foo() is passed in.
>>>
>> I guess that at least some of the time you could get away with a
>> conditional breakpoint in 'doSomething', but I guess not always.
>>
>> It would be a bit tricky to convey to the user where exactly the
>> breakpoint is, but I guess it could be done with refined highlighting
>> (not the full line) and the tooltip when hovering above the breakpoint
>> icon in the gutter.
>>
>> Amnon
>>
>
That's fantastic! I've been lusting for this since at least IDEA 3 but wondered if it would ever happen since it requires a server-side component that thankfully you are adding as a key aspect of Demetra.
Jon
The "Delayed commit: build and commit if successful" brings up other questions. Will we be able to tie this 'commit if successful' to server-side code inspections so that the commit can be rejected if it doesn't pass project-mandated inspections?
Can a project-wide code reformatting be applied to the code on the server side as it is committed?
Thanks,
Jon
Maxim Shafirov (JetBrains) wrote:
Hmm... Could it be implemented behind the scenes by IntelliJ like
conditional breakpoints are implemented? i.e. if user sets a breakpoint
like the example in this thread, IDEA will do the necessary extra steps
to make it happen.
Since currently on the example stepping into on the normal breakpoint
will first go into the Foo constructor, IDEA can do that behind the
scene, step out of it, and then give the control to the user.
That way IJ won't need a custom compiler, just be smart about what it
does when the more coarse full-line breakpoint occurs.
Amnon