| RE: [mylar-dev] Stand alone bug tracking |
|
Yes, these kinds of annotations are interesting since they are development-time entities, and for that reason they’re actually in a ..mylar.dt library package. Btw, does anyone know of any other examples of similar development-time annotations, that affect the tool/display rather and not the runtime or a checker? VS.NET’s #region directives are somewhat similar, and I think of them as saying “this is uninteresting enough to always be folded by default”.
Regarding the mechanism, yes, there wouldn’t be anything fundamentally hard about plugging in backport175 support and Javadoc syntax annotations would be fine for us. But for the long run I really hope that 3.2 supports annotations in the Java Model (https://bugs.eclipse.org/bugs/show_bug.cgi?id=79112), and that should will make resolution eagerly updated and tolerant to compiler errors.
Mik
From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On
Behalf Of Eugene Kuleshov
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. 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... From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Kuleshov
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?
_______________________________________________mylar-dev mailing listmylar-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/mylar-dev
|