Code Name Game

Hello everyone,

Looks like it's time to pick the codename for the 6.5 release. We haven't
yet made an official choice, so, unlike last time, we'll give you a chance
to suggest something that we may actually use. :)

Suggestions?

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
49 comments


Looks like the chosen name is "Selena" (apparently a
variant of "Selene", the Moon goddess).

May a fortunate Moon shine over the Selena release
(and her EAP as well).

Best Regards,
Jens

0

I hope this doesn't mean we're only going to get EAP builds once a month!
R

0

Two suggestions:

Hera: from the Greek Mythology. The wife of Zeus and queen of Heaven.

Juno: from the Roman Mythology. The wife of Jupiter and queen of the gods.

0

Out of curiousity (and at the risk of hijacking this thread), what features do you think the idea folks would add to the testng support than the current plugin doesn't have?

It can easily be on a par with the junit support, the limitations we ran into time and time again is that the junit support is baked in and uses a bunch of stuff that isn't part of the openAPI, so the testng plugin cannot make use of the same calls.

As for naming, my only wish is that it's easily (and obviously) pronouncable, so I can verbally urge people to switch to it (or curse it when it breaks, more likely).

0

I am fairly happy with the plugin -- I wish it were bundled rather than an add-on.

The difference is psychological only, to be sure, but the same can be said for the other bundled plugins such as application server support.

I do find myself, however, sometimes running the tests on the command line just so I can see the console output from System.out, which doesn't seem to show up in the IDEA test runner window. That might be ignorance on my part as to how to see the output.

0

Hmmm, System.out content should be displayed... Do you not see anything like:

/home/amrk/app/jdk1.5.0_03/bin/java -ea -javaagent:/home/amrk/app/idea-6111/lib/emma-agent.jar=-f com/bulletinwireless/* -o /home/amrk/.IntelliJIdea60/system/coverage/bulletinmail$testng-coverage.dat.es -Didea.launcher.port=7533 ..... /home/amrk/.IntelliJIdea60/system/bulletinmail_EJB_Test_Suite_f00099ad.xml
EMMA: collecting runtime coverage data ...
EMMA: runtime controller started on port
Running:
/home/amrk/.IntelliJIdea60/system/bulletinmail_EJB_Test_Suite_f00099ad.xml

Creating integration testing database...
JDBC Base is jdbc:postgresql:


being displayed in the "output" tab of the results window? I certainly see System.out.println() stuff...

0

Hi Hani,

TeamCity team is using testng plugin at the moment ant there are at least 2
features we're missing in comparison with IDEA junit support:
1) Possibility to run all tests in a specified package (from the
ProjectView)
2) "Click here to view the difference" link when test fails with comparison
failure

Junit related problems were avoided after removing TestCase as super class
for our test classes.
So now we're happy with the plugin. Thanks a lot!

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Hani Suleiman" <hani@formicary.net> wrote in message
news:16898246.1164676018140.JavaMail.itn@is.intellij.net...

Out of curiousity (and at the risk of hijacking this thread), what
features do you think the idea folks would add to the testng support than
the current plugin doesn't have?

>

It can easily be on a par with the junit support, the limitations we ran
into time and time again is that the junit support is baked in and uses a
bunch of stuff that isn't part of the openAPI, so the testng plugin cannot
make use of the same calls.

>

As for naming, my only wish is that it's easily (and obviously)
pronouncable, so I can verbally urge people to switch to it (or curse it
when it breaks, more likely).



0

1) Possibility to run all tests in a specified
package (from the
ProjectView)


Yep, I remember trying to add this, but unfortunately IDEA's API made this impossible. I'll have another look to see if that's changed.

2) "Click here to view the difference" link when test
fails with comparison
failure

Yeah, also part of JUnit's internals, so hard to reuse! I'll have another look though

0

Further update:

1) Possibility to run all tests in a specified
package (from the
ProjectView)


Nagged people from the IDEA team to help us enable this, The problem is that I don't know of a way to get a callback on package right click. The callback works fine for leaf nodes, but not packages.

2) "Click here to view the difference" link when test
fails with comparison
failure

Implemented this, it'll be in the next version. It should handle the equality assertions in org.testng.Assertions. Nag in the plugins forum if you have situations where it doesn't work!

0

IIRC, you want something like

PsiPackage getSelectedPackage()
{
final PsiElement element = (PsiElement) dataContext.getData(DataConstants.PSI_ELEMENT);
if (element == null) {
return null;
}

final PsiDirectory selectedDirectory =
PsiTreeUtil.getParentOfType(element, PsiDirectory.class, false);
if (selectedDirectory != null) {
return selectedDirectory.getPackage();
}
return null;
}

You may need to tweak that a bit, but I think the basics are there.

--Dave Griffith

0

Yeah that bit isn't the issue, the problem I'm having is how to pick up on the right click at all. I'm using LocatableConfigurationType.createConfigurationByLocation(Location location) and that is called back correctly for right clicks on classes, but I cant figure out what to do for packages.

Once something tells me a right click has happened on a node in project/whatever view, then I can easily go from that to the actual package.

0

Just add an action to the ProjectViewPopupMenu, yes? Apologies in advance, but I must be missing something.

--Dave Griffith

0

The action I want only shows up conditionally, so I can't just a global action that way (at least, not unless there's a way of getting asked whether to include it or not before it's shown!)

Basically, it looks like IDEA hardcodes the JUnit context items, it reads in com.intellij.execution.junit.JUnitConfigurationProducer.PROTOTYPES and adds them in, but there's no way of hooking into that mechanism. ConfigurationContext calls PreferedProducerFind (note the typo, incidentally!) which adds in the junit list, and nobody else gets to play!

0

Well, the conditionality is easy. Just overriding the actions "update" method, including something like

event.getPresentation().setVisible(false);
event.getPresentation().setEnabled(false);

if you are in a package with no TestNG classes. Checking whether there are TestNG test cases in a package is just a clever AnnotatedMembersSearch, I would imagine (although you might want to cache some of those answers for performance reasons).

--Dave Griffith

0

If you allow me hijack this already hijacked thread...
Speaking of AnnotatedMemberSearch, performance and caching:
Is there a way to reliably do that? Cache result and get events when annotations are added/modified/deleted?

Dave Griffith wrote:

Well, the conditionality is easy. Just overriding the actions "update" method, including something like

event.getPresentation().setVisible(false);
event.getPresentation().setEnabled(false);

if you are in a package with no TestNG classes. Checking whether there are TestNG test cases in a package is just a clever AnnotatedMembersSearch, I would imagine (although you might want to cache some of those answers for performance reasons).

--Dave Griffith

0

Hello Stephen,

SK> Speaking of AnnotatedMemberSearch, performance and caching:
SK>
SK> Is there a way to reliably do that? Cache result and get events when
SK> annotations are added/modified/deleted?

It's cached already - it uses the repository indexes, rather than scan the
classes directly.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Dmitry Jemerov wrote:

It's cached already - it uses the repository indexes, rather than scan
the classes directly.


I noticed that it's very fast, but still in my seam plugin I'd like to show a
list of all components. Currently I have to pull the information every second
or so and search for all @Name, @Role, @Roles, @DataModel, ...
This simply does not feel right. Also my inspection rely on having a current
list of seam components, but if I use the AnnotatedMemberSearch each and every
time I inspect a member or class it would maybe really cost performance.

0

Mild rehijacking (with a pinch of ontopic hijack hijack)

1) Thanks Dave! I have my action showing up and doing its thing....mostly. The last hurdle is figuring out how to get my RunnerAndConfigurationSettings object into its rightful place. I can create it within my action, and what I'd like to do next is tell IDEA about it, and have it show a popup dialog to edit the generated run settings.

2) Are there any docs for AnnotatedMembersSearch(er)? It looks like it could be useful, but of course it's cryptic enough that it's not quite obvious how it could be useful! I'd like to be able to do stuff like project wide (or module wide) annotation searches, both on class level and method level. Right now it's all done manually in a fairly unpleasant way in http://testng-idea.googlecode.com/svn/trunk/src/com/theoryinpractice/testng/util/TestNGUtil.java

0

2) Are there any docs for AnnotatedMembersSearch(er)?
It looks like it could be useful, but of course it's
cryptic enough that it's not quite obvious how it
could be useful! I'd like to be able to do stuff like
project wide (or module wide) annotation searches,
both on class level and method level.


AnnotatedMembersSearch and other searches are a great new API to do searches easier and with less code than with PsiSearchHelper.

Example:

 query =
                AnnotatedMembersSearch.search(annotationClass,
                        GlobalSearchScope.allScope(annotationClass.getProject()));
        // 1: just iterate over the result
        for (PsiMember annotatedMember : query) {
            // do (conditionally) something with each member
            // breaking from the loop stops the search, which might 
            // otherwise be lenghty
        }
        
        // 2: or only test for the presence of a annotated member 
        final PsiMember member = query.findFirst();
        if (member == null) {
            // no annotated members are present.
        }
        
        // 3: or do all searching before processing:
        final Collection allFoundAnnotatedMembers = query.findAll();
]]>


Hope that helps,
Bas

0

Please sign in to leave a comment.