Use something like clover, you don't need idea specific integration, and a plugin for it exists anyway, and it's available for free for open source projects.
I don't know how good this is, but I once thought about Code coverage tool with the help as AspectJ.
We insert Logging like statements in some predefined format, which gets saved into a global file (or data structure) and then there will be a tool to process it and tell about the statistics :)
I know, and I'm saying that use to justify AspectJ or AOP in idea is not another use, since well it's better served by existing tools, and like others have said Plugins which exist, or don't and should be simply written.
So I think you're making the case for non integration so far :)
Use something like clover, you don't need idea specific integration, and a plugin for it exists anyway, and it's available for free for open source projects.
Are you suggesting that we can all start using clover for free if we pretend we are doing open source development. Cause, only a minority of software developers are earning a living doing open source development.
It seems to me that Anki's suggestion is a pretty good one. And it can provide a very simple solution when you don't need a 100 diffferent reports on code coverage... you just want a simple mehode-used/not-used kind of report.
Plus work-flow wise using clover adds a lot of overhead while using an AOP solution would be very easy to turn on/off before running unit tests or doing some other use-case testing.
> Are you suggesting that we can all start using clover for > free if we pretend we are doing open source development.
I was just about to ask the same thing since I don't recall Anki ever mentioning he was working in open source.
It's not that easy anyway, you can't simply tell the Clover team you are doing open source if you aren't. You are expected to prove it and generally they won't give you an open source license if you don't already have some history working on previously released open source versions of either your current or another project.
Well, instead of Clover, you could use the GPL version of JCoverage. We use it on our project and it's providing us with excellent coverage reports for free:
Plus work-flow wise using clover adds a lot of overhead while using an AOP
solution would be very easy to turn on/off before running unit tests or doing some other use-case testing.
You should be careful with statements like that, you're just asking to be flamed :)
Trying to defend a would-be, waporware AOP-based coverage solution against a well established, solid and efficient coverage tool such as Clover doesn't seem to be the best way to promote AOP integration in IDEA.
Trying to defend a would-be, waporware AOP-based coverage solution against a well established, solid and efficient coverage tool such as Clover doesn't seem to be the best way to promote AOP integration in IDEA.
we are just having discussion... this is what i don't get... I am not a salesman... And I refuse the idea that in these forums we can not just talk about subjects that interest us and explore the possibilities.
To many people are taking this way to seriously... and I have also gotten all wound up by these arguments and gotten way to serious as well.
In my experience you need both established tools like clover and flexible tools for very directed and specific tasks like AOP can provide.
on the subject of vapour-ware... it isn't I have used AOP not to generate code wide coverage... but to identify usage across specific use cases.
and here is a link to a cookbook that shows that much other than logging can be done with aspects. Please bare with me... it is an AspectJ specific site :)
I don't mean to drag jetbrains into this, they've kept out of it, and probably rightfully so... Didn't JetBrains use AspectJ at one point IN idea to create it? Are they still doing this? What has the experience been like?
Let's find out from the source, and from a project which is as serious and complex as one can get.
I don't mean to drag jetbrains into this, they've kept out of it, and probably rightfully so... Didn't JetBrains use AspectJ at one point IN idea to create it? Are they still doing this? What has the experience been like?
Let's find out from the source, and from a project which is as serious and complex as one can get.
R
We haven't done anything other than what is currently covered with Dependency Analysis rules validation. The latter shows up as a little bit more convinient tool for that task.
>you will not use it for an final project, ain't you?
Actually I seriously tried to create one for J2ME, but couldn't spend enough time to know more about AspectJ and WTK internals (which files needs to be weaved etc...)
And finally gave-up, becuase there are more things to do :)
Actually I seriously tried to create one for J2ME, but couldn't spend enough time to know more about AspectJ and WTK internals (which files needs to be weaved etc...)
No way.
1. In J2ME the reflection is practically non existant. 2. The cldc spec doesnt allow multiple jars and dynamic classloading. 3. Most often your whole app has to fit in 30-50k jar.
Nope it is possible, but there are some limitations like thisJointPoint can not be used, which is the most important to get signature. As you said thisJointPoint uses reflection.
I actually tried other way i.e, don't weave the MIDlet because it might increases the size, instead weave all MIDP Jars (I guess we can do this) of WTK, which I am not able to . Seems that jars under WTK\lib are not used while running. I checked this by totally removing these jar files from lib folder.
>2. The cldc spec doesnt allow multiple jars and dynamic classloading.
If we build correctly then final jar file includes all required calss files from all 3rd party jars (usually we keep them under lib folder of out project folder while using WTK)
>3. Most often your whole app has to fit in 30-50k jar. Strictly speaking we crossed this limitation these days with all new phones. Ofcourse production quality jars still needs to run on most of the devices, so they maintain smaller sizes. BUT 30-50K is gone. 60-110 (even more bigger) also acceptable by latest phones as long as you have enough memory.
Just sharing the info as I am involved in J2ME development :)
Are you talking aspects on the emulator or aspects on the phone?
What I meant is that since we can't load external jars, we have no way to hook a custom classloader, so we can't do dynamic instrumentation.
You can do static weaving, which is somewhat cool, but you can do it with AspectWerkz as well (and as somebody pointed out you don't need IDE support to use it.)
// offtopic: while I don't see value in aspects for MIDP, I would kill for mock MIDP environment which would allow me to run my code in normal JUnit on normal JVM.
Use something like clover, you don't need idea specific integration, and a
plugin for it exists anyway, and it's available for free for open source
projects.
Next.
R
On 12/8/04 5:23 PM, in article
29340060.1102544595973.JavaMail.itn@is.intellij.net, "Anki"
<no_mail@jetbrains.com> wrote:
Just mentioned another use of AspectJ ;).
Not an alternate to existing coverage tools.
I know, and I'm saying that use to justify AspectJ or AOP in idea is not
another use, since well it's better served by existing tools, and like
others have said Plugins which exist, or don't and should be simply written.
So I think you're making the case for non integration so far :)
Friendly,
R
On 12/8/04 5:41 PM, in article
1193592.1102545708112.JavaMail.itn@is.intellij.net, "Anki"
<no_mail@jetbrains.com> wrote:
I guess, not very good, because it's already possible without AOP. And, of
course, you will not use it for an final project, ain't you?
Tom
Are you suggesting that we can all start using clover for free if we pretend we are doing open source development. Cause, only a minority of software developers are earning a living doing open source development.
It seems to me that Anki's suggestion is a pretty good one. And it can provide a very simple solution when you don't need a 100 diffferent reports on code coverage... you just want a simple mehode-used/not-used kind of report.
Plus work-flow wise using clover adds a lot of overhead while using an AOP solution would be very easy to turn on/off before running unit tests or doing some other use-case testing.
Florian
Florian Hehlen
> Are you suggesting that we can all start using clover for
> free if we pretend we are doing open source development.
I was just about to ask the same thing since I don't recall Anki ever mentioning he was working in open source.
It's not that easy anyway, you can't simply tell the Clover team you are doing open source if you aren't. You are expected to prove it and generally they won't give you an open source license if you don't already have some history working on previously released open source versions of either your current or another project.
Well, instead of Clover, you could use the GPL version of JCoverage. We use it on our project and it's providing us with excellent coverage reports for free:
http://www.jcoverage.com/
Patrick
solution would be very easy to turn on/off before running unit tests or
doing some other use-case testing.
You should be careful with statements like that, you're just asking to be
flamed :)
Trying to defend a would-be, waporware AOP-based coverage solution against a
well established, solid and efficient coverage tool such as Clover doesn't
seem to be the best way to promote AOP integration in IDEA.
Vince.
we are just having discussion... this is what i don't get... I am not a salesman... And I refuse the idea that in these forums we can not just talk about subjects that interest us and explore the possibilities.
To many people are taking this way to seriously... and I have also gotten all wound up by these arguments and gotten way to serious as well.
In my experience you need both established tools like clover and flexible tools for very directed and specific tasks like AOP can provide.
on the subject of vapour-ware... it isn't I have used AOP not to generate code wide coverage... but to identify usage across specific use cases.
and here is a link to a cookbook that shows that much other than logging can be done with aspects. Please bare with me... it is an AspectJ specific site :)
http://www.aspectcookbook.net/moin.cgi/AspectCookbook
Florian Hehlen
I don't mean to drag jetbrains into this, they've kept out of it, and probably rightfully so... Didn't JetBrains use AspectJ at one point IN idea to create it? Are they still doing this? What has the experience been like?
Let's find out from the source, and from a project which is as serious and complex as one can get.
R
Robert S. Sfeir wrote:
We haven't done anything other than what is currently covered with
Dependency Analysis rules validation. The latter shows up as a little
bit more convinient tool for that task.
--
Maxim Shafirov
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
>you will not use it for an final project, ain't you?
Actually I seriously tried to create one for J2ME, but couldn't spend enough time to know more about AspectJ and WTK internals (which files needs to be weaved etc...)
And finally gave-up, becuase there are more things to do :)
Thanks Max for answering...
So now, folks, you see one use for this... and then again, how many people would need it for that?
Come on... tank that sucker and let's move on.
R
Anki wrote:
No way.
1. In J2ME the reflection is practically non existant.
2. The cldc spec doesnt allow multiple jars and dynamic classloading.
3. Most often your whole app has to fit in 30-50k jar.
Nope it is possible, but there are some limitations like thisJointPoint can not be used, which is the most important to get signature. As you said thisJointPoint uses reflection.
I actually tried other way i.e, don't weave the MIDlet because it might increases the size, instead weave all MIDP Jars (I guess we can do this) of WTK, which I am not able to . Seems that jars under WTK\lib are not used while running. I checked this by totally removing these jar files from lib folder.
>2. The cldc spec doesnt allow multiple jars and dynamic classloading.
If we build correctly then final jar file includes all required calss files from all 3rd party jars (usually we keep them under lib folder of out project folder while using WTK)
>3. Most often your whole app has to fit in 30-50k jar.
Strictly speaking we crossed this limitation these days with all new phones. Ofcourse production quality jars still needs to run on most of the devices, so they maintain smaller sizes. BUT 30-50K is gone. 60-110 (even more bigger) also acceptable by latest phones as long as you have enough memory.
Just sharing the info as I am involved in J2ME development :)
cheers
Anki.N
Are you talking aspects on the emulator or aspects on the phone?
What I meant is that since we can't load external jars, we have no way
to hook a custom classloader, so we can't do dynamic instrumentation.
You can do static weaving, which is somewhat cool, but you can do it
with AspectWerkz as well (and as somebody pointed out you don't need IDE
support to use it.)
// offtopic: while I don't see value in aspects for MIDP, I would kill
for mock MIDP environment which would allow me to run my code in normal
JUnit on normal JVM.