Ha ha - Subversion leads over AspectJ

Hmm - bad form to write "ha ha" in the title - sorry for that folks. I didn't mean to make efun of anyone who feel that AspectJ is important.

I do however feel that Subversion integration is sufficiently requested in order to be considered for Pallada...

Best regards,
Lars Ugleberg

Lars Ugleberg wrote:

Hmm - bad form to write "ha ha" in the title - sorry for that folks. I didn't mean to make efun of anyone who feel that AspectJ is important.

I do however feel that Subversion integration is sufficiently requested in order to be considered for Pallada...

Best regards,
Lars Ugleberg

The folks at Tigris are already doing that. It's in active development
and usable... ha ha :)

http://svnup.tigris.org/

R

Thanks for mentioning this initiative.

It just confirms that it might be within reach to actually build in a Svn integration in Pallada without JetBrains having to do too much groundwork to get it done.

I don't want to mess around with plugins - if Svn catches on big time, other vendors will offer built-in integration similar to their current CVS integrations, and JetBrains will probably follow suit. I would just love to see JetBrains make a preemptive strike and be among the first, obviously since IDEA is my favorite tool.

Svn looks promissing but unless IDEA (in Pallada9 happens to provides a smooth path of transition I'll just continue to use CVS inspite of its shortcomings.

Best regards,
Lars Ugleberg

Too bad that svnup is still... hmm... suboptimal to say at least.

This reminds me of a request to open some parts of the CVS plugin source code so we can use it as an example to write other VCS plugins. Alright, now I'm not an open source moron or something like that: I'd just like to get a fully documented documented OpenAPI, but while we don't get that, some source code sure helps.

Marcus Brito wrote:

Too bad that svnup is still... hmm... suboptimal to say at least.

This reminds me of a request to open some parts of the CVS plugin source code so we can use it as an example to write other VCS plugins. Alright, now I'm not an open source moron or something like that: I'd just like to get a fully documented documented OpenAPI, but while we don't get that, some source code sure helps.

Marcus, I think they're opening that up in Pallada, at least last I heard.

R

Funnily enough, the 'ha ha' is actually very appropriate. All the fuss and hassle over aspectJ turned out to be a hugely vocal tiny minority who artificially pushed up the vote count for it. You're unlikely to find more than a handful of people who think that 4.0 not having aspectJ is a bad thing. Most people, you'll find, couldn't possibly care less about aspectJ (even various AOP zealots, since aspectJ is outdated and archaic and generally anyone with a clue will use something more modern).

The exact same thing applies to subversion. I'm all for the openAPI allowing for subversion plugins to be written (to be fair, the existing subversion plugins are laughably bad, it's actually surprising how bad they are). Let the IDEA developers stick to what they do best; innovation and ensuring we can all develop with some degree of pleasure, instead of wasting their time pandering to a bunch of fashion sluts with the attention span of a guppy.

The exact same thing applies to subversion. I'm all
for the openAPI allowing for subversion plugins to be
written (to be fair, the existing subversion plugins
are laughably bad, it's actually surprising how bad
they are). Let the IDEA developers stick to what they
do best; innovation and ensuring we can all develop
with some degree of pleasure, instead of wasting
their time pandering to a bunch of fashion sluts with
the attention span of a guppy.

The question is: is the current direction IDEA is taking the "right" direction for innovation? These days I'm particularly bugged by the fact that idea's support to web development activities using JSP, HTML, JS and so on is ... uhm... less extraordinary than the one for "normal" java development. I find frustrating that nearly all the effort for 4.1 is concentrated on something else, and particularly features which I'm not sure are really important, such as "find duplicates when extracting method". I agree that the voting system has done a bad job in the past, but completely abandoning consideration of user feedback will not lead IDEA very far, in these days of harsh competition...

"Find Duplicates When Extracting Method" looks to be a happy freebie feature based off the work for the (extremely innovative, very valuable) "Duplicate Code Detection" functionality. Given the choice between an IDEA that helps me improve and understand my application's overall design, and one that gives me some assistance on the presentation layer, I'll take the design assistence avery time. Particularly since the presentation assistance is likely to be very weak, due the crudeness of the technologies involved.

--Dave Griffith

Given the choice between
an IDEA that helps me improve and understand my
application's overall design, and one that gives me
some assistance on the presentation layer, I'll take
the design assistence avery time. Particularly since
the presentation assistance is likely to be very
weak, due the crudeness of the technologies involved.

That's a reasonable opinion. Mine is that the effort required to develop the "extremely innovative, very valuable" feature is likely to be much, much, much more demanding than, for example, adding "ctrl-q" description popup for custom tags.

I agree those are "crude" technologies, and it's for this reason that idea should make them less crude. If "find duplicate code" costs 100 in development time, and "popup description" costs 1, I simply don't understand why jetbrains doesn't implement both: I don't think that anyone could choose IDEA over eclipse because once in a lifetime he has the chance to spot duplicate code, while I am sure that apparently "minor" functionalities that would be used nearly every 10 minutes could change the situation.

Hear hear ....

I agree with your analysis, but if you're only anticipate spotting duplicate code once in a lifetime, you're either a far better coder than I or a far worse one. Duplicate code is either the worst or second worse design smell (after dead code). I anticipate automating it's discovery and repair will greatly alter my day-to-day workflow and increase my productivity.

(Not to set the bar too high, Maxim...)

--Dave Griffith

Uhm. I'm surely not a better developer than you, but I'm obsessed with redundancy destruction, and I simply refactor everything that smells similar to something I've already done in the past. But I agree this can not be such a common behaviour, and a tool like that one can be useful as a quality assurance tool for a project involving many developers.