From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On
Behalf Of Eugene Kuleshov
Sent: August 21, 2005 7:09 AM
To: Mylar developer discussions
Subject: Re: [mylar-dev] Stand
alone bug tracking
Mik Kersten wrote:
Could you elaborate what you mean by
“Eclipse Way”? They’re not being exploited much in
Eclipse yet because APT integration and JavaModel support for annotations
won’t really be there until 3.2. I think that annotations are a
great mechanism for specifying metadata that should be inline with the source
and consumable by compiler, VM, or IDE tool. For example, one annotation
that we use internally is @MylarWebRef, which brings web pages into your degree
of interest, e.g. if you got an example from a doc source or blog.
Another is to be able to explicitly state that something is of landmark
interest no matter what context it’s in. But this is still very
experimental, and won’t expose any of these annotations mechanisms until
the mechanism for having a workspace-wide aggregate context is there, since
there is overlap. And we will soon be able to do the web ref stuff
implicitly by monitoring Internal Browser navigation. Either way, thanks
to the fact that backport175 is starting to work really well (my experience
from AspectJ) we will be able to support any annotation stuff with 1.4 syntax
transparently.
Mik, you are right that there is not really
much of de facto standards in this area. However if you think about it, it is
more dev-time only metadata. Since there are lot of code that can't use java5
annotations for one or another reason it doesn't really make sense to use
annotatations just yet. Note that backport175 intended to be used to produce run-time
annotations, so they would only available in the code and I guess only in case
if code does not have any build errors, which is potentially big
limitation.
So, it seems that special java-doc based annotations for pre-Java 5
targets is a way to go, but Mylar should work with AST directly and do own
source scanning for annotations. Shouldn't be that difficult. because Alex's
backport175 plugin already does all the work, you just need to hook-up Mylar's
monitor in there. And in case of Java 5 project you can use standard AST
processing tool (e.g. Sun's or Eclipse plugin from BEA that just released
recently).
Regarding other Java5 features, we only
rely on them to ease development. I just counted and we have thousands of
generic type usages, and so we haven’t seen a ClassCastExceptoin for
months. We also have dozens of enums. These and the other
small Java 5 features save us substantial development and defect time, and some
I’m hoping that the retroweaver approach will mean that we can avoid
lowering the quality of the code in the process of supporting 1.4.
We’ll know soon!
Right. It is just with
retroweaver you are making Mylar build more complicated. You are saying it
worth it...
regards,
Eugene
Mik Kersten wrote:
In the near-term my main concern is that
1.5 only compatibility will prevent some from contributing to Mylar. In
the longer term yes, this tool should not be limited to the masses who are
still stuck on 1.4. Also, the fact that there is no 1.5-based free
software stack bothers me.
Next week we’ll try to set up a 1.4
compatible retroweaver/backport build and document progress on https://bugs.eclipse.org/bugs/show_bug.cgi?id=104601.
Also, removing the 1.5 stuff from mylar.tasklist and mylar.bugzilla is
not out of the question if that results in contribution to those components,
but since that will be a pain we’ll wait to see what happens with
Retroweaver.
Mik, you've
mentioned another day that you are using annotation to specify degree of
interest. I think that it is not exactly an "Eclipse way" isn't it?
Is there are any other Java5 features besides annotations that actually
important for Mylar?
Thanks
Eugene
_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev