Community
Participate
Working Groups
It would be nice to allow users greater contol over advice markers. On a per- aspect basis users should be allowed to select an icon for the advice for that aspect, or decide that markers should not be created for that aspect. This should be persisted, possibly in the .settings directory. We should provide a simple UI to configure this for a given project and a default set of icons.
I am just throwing some ideas I have. If we assume that the META-INF/aop.xml is in the end fully supported by AJDT, that might be a nice place to have such "extra" configuration: - turn off gutter (but not aspect behavior / aspect weaving to the apps) - control gutter rendering on a perAspect basis (and perhaps some more widget things) the nice thing to have it in the aop.xml is that you could ship an aspect library and have it rendered with its own icons.. the missing thing is that you may want to turn off gutters from an aspect library aspect (for which u don't have write control on the aop.xml file => still needs specific screens and project setting for such). (that looks like old JavaBean spec isn' it ?) Alex
I think that it could be very confusing for users if this was controllable on a per-aspect basis. It would be easy to get into a state where you don't know if the marekers aren't showing up because of the configuration or because there's no advice. This is really a UI thing. Seems better to have preference page option for where advice markers show up: - left ruler (gutter) - right ruler - task list (definitely off by default) Check Eclispe the 3.1m4+ options for text editor Annotations. I think that our UI could be very similar, and possibly just re-use that UI. If you declare your marker an annotation it shows up there. Here's some sample plugin.xml code that will cause that view to get populated with the given marker. <extension point="org.eclipse.ui.editors.annotationTypes"> <type name="ca.ubc.mylar.ui.landmark.annotation" markerType="ca.ubc.mylar.ui.landmark"/> </extension> <extension point="org.eclipse.ui.editors.markerAnnotationSpecification"> <specification annotationType="ca.ubc.mylar.ui.landmark.annotation" label="Mylar Landmark" icon="icons/structure/landmark-small.gif" textPreferenceKey="landmarkIndication" textPreferenceValue="false" highlightPreferenceKey="landmarkHighlighting" highlightPreferenceValue="true" contributesToHeader="true" overviewRulerPreferenceKey="landmarkIndicationInOverviewRuler" overviewRulerPreferenceValue="true" verticalRulerPreferenceKey="landmarkIndicationInVerticalRuler" verticalRulerPreferenceValue="true" colorPreferenceKey="landmarkIndicationColor" colorPreferenceValue="255,255,255" presentationLayer="4" showInNextPrevDropdownToolbarActionKey="showLandmarkInNextPrevDropdownT oolbarAction" showInNextPrevDropdownToolbarAction="true" /> </extension>
Mik, Personally, I don't like the all-or-nothing aproach and think the benefits of fine-grained control are worth the cost. Having a visual indication is useful when dealing with most pointcuts and is arguably essential for intertype declarations. But things like tracers or loggers are just annotation spam and drown out any information. We can't just disable these aspects, because they are so useful as development aspects. The good news is that there will likely be relatively few of these aspects. If you are really set against fine-grained control, maybe there are other solutions. For instance, maybe we can easily tag the few cross-application aspects as load-time aspects and globally enable/disable LTW annotations. That would help this problem, and it might speed compile by removing the worst offenders. Not being much of an expert on the tooling, and never having used LTW, I don't know if this is viable right now, but I'd like to find some way to make the annotations useable and still support the high-value but low-interest aspects.
Adrian, this is great feedback, and clearly my earlier suggestions don't do a good enough job of addressing your issue of "annotation spam". Is still think that we need to avoid confusion and complexity, and configuring this in a place that's 'far' from the UI or code (e.g. .xml config file, deep in prefs setting). So how about this idea: - Each *aspect* can have an annotation on it, to the effect of: CrosscuttingAnnotationImportance(<int level 1..5>) - This level causes the *severity* of any crosscutting markers originating from advice and ITDs in the aspects to be set according to the level specified. - There's a really convenient place in the UI to set the "filter crosscutting annotation" level to be the desired one. For example, as an extra button/filter in the Outline and Package Explorer. - Now you set your tracers and loggerst to be 1, and everything else to be higher. I think it's very important that the filtering works consisntently across all views. So you also won't see these the decorators or outline view links for those either. That way you can trust all the views to show you crosscutting information consistently.
Mik, That sounds like it would satisfy everything we're looking for: it can be shared, it is clear and obvious, it is simple to maintain, it would apply to library aspects as well as new development, and it provides fine-grained control. To play the devil's advocate for a moment, is tagging aspects with annotations that the tooling is aware of a shared direction? Will other IDE tools be doing this? Will this be the only AJDT annotation, or is this the first of many? If this is the direction of other tools (I suspect it is), then we're visionaries instead of hacks :) If we go down this path, we'll also need to provide some guidance around the significance of the different levels. Just looking at the filter on severity and task status in the JDT Problems View, they are using three levels (error, warn, info). Can we come up with something similar here to prevent confusion, even if it is just a naming convention? Is there a possibility of adding some rough intelligence to this filtering process by assigning defaults to the advice? E.g.: intertype declarations as a '1', around advice as a '2', before/after as a '3', declare warn/declare error as a '4', and reserve '5' for programmers to set as a broad disable? That way, we can chose to add in markers for aspects with decreasing importance to the program flow. Just some brainstorming...
> - Each *aspect* can have an annotation on it, to the effect of: > CrosscuttingAnnotationImportance(<int level 1..5>) By annotation are we talking Java 5 annotation? It seems to me that it could be a long while before many of our users on able to make that switch to Java5 and utilise its features and yet this kind of filtering will be useful to all our users. So are we talking about also supporting whatever equivalent there is on older levels (javadoc embedded tags or something). <just brainstorming> We have talked a bit about this kind of thing before, and even extending it so that the annotation picks an icon you want for your aspect - a padlock for your security aspect ... </just brainstorming>
Adrian: yes, this idea has applicability beyond AspectJ. I think of C#'s #region folding directive as a sort of IDE UI annotation that tells the tool what you want it to do. These sorts of marker annotations fall into the same category. And yes, you might want to enum them. The cool thing is that the enum could be in the annotation class itself. Andy: Yup, if we went down this road we would need to support the 1.4 style as well. But with something like Jonas and Alex's backport175 the AJDT would care which you used. And that padlock idea is pretty cool :) I could see an aspect library providing it's own icons in this way. Most users shouldn't have to care about this mechanism. But with people like Adrian starting to use aspects more heavily I can see how it would be useful
*** Bug 96245 has been marked as a duplicate of this bug. ***
I like the idea of using Java 5 annotations to configure advice markers but I'm wondering where the definition of the annotation should live. It seems wrong to ask users to add another dependency to their projects just to be able to configure the UI. I could imagine adding something like SuppressAjInfo to aspectjrt.jar, which, when applied to an aspect, would suppress all 'information' for that aspect at the compiler level, including weaveinfo. However I'm not sure about putting anything more fine-grained than that in aspectjrt, especially anything to do with icons. Perhaps that might fit better in an aspect library or done purely through the UI? Any thoughts? Thanks.
- I think this customization belongs in AJDT not AspectJ. It makes a lot of assumptions about how cross-cutting is shown. Another IDE would not automatically be able to use it. - Whether markers appear should be decided by the affected source owner and not the aspect writer: how can they decide in advance how "important" an aspect is to a consumer? As recently as the JavaOne AspectJ SIG I was fielding requests for old style “source generation” for advice invocation. While I do not support this view it is still vital that new users can see what is happening to there code. - As originally suggested settings should persist and be shared (through a repository like compiler warning suppression) but not imposed, requiring source code changes to be modified. As Andy suggests we should not rely on Java 5 support and the use of annotations brings a whole host of new problems like standards and packaging. Also we still need a UI to configure what is shown so they seem redundant. I have suggested in the past (although I cannot find a Bugzilla report) that we enhance the role of the existing “Visualiser Menu”. This shows which aspects are affecting a particular project and unchecking one could easily remove the accompanying advice markers as it removes lines from the Visualier. Also there is an opportunity to show and allow the user to customize an icon for each aspect. Settings could be persisted in the project.
As a user I don't want to write a specification just to hide things. To me the best UI would be (a) to right-click the marker and get a menu item to hide advised-by markers for this advise or aspect; and (b) a view/dialog tree listing aspects and their advise with a view checkbox. (It would also be nice to be able to highlight the associated markers, like search highlight.) To show markers hidden by (a) would require using (b). I agree this filtering would tend to be more bound to the view than the aspect, but can imagine another checkbox for scope (this project v. all projects, with per-project choice dominating). Eventually, the same UI could associate user-specified colors or icons and permit both direct and typepattern reference (TypePattern{.[before|after|around{|annotation}} - yet another GUI reason to name advice). wrt state, it would be nice to persist across Eclipse sessions, but I'm less convinced of the value of sharing across users and would be reluctant to support a user-editable form (sync, validation, backwards compatibility, etc.). But I would start with a (developer-editable) text file "adjt-configuration" and be alert for other view-session properties, to let savvy users share and sync manually at their own risk. Obviously, I don't like annotations for this and would caution against polluting aop.xml with AJDT-specific features. Both are engineering-driven solutions for a UI issue. I should also say this is a very nice problem to have!
*** Bug 116378 has been marked as a duplicate of this bug. ***
I have added this feature to the 1.4 release stream in the following build: BUILD COMPLETE - build.57 Date of build: 03/03/2006 06:46:46 Time to build: 18 minutes 2 seconds Last changed: 03/03/2006 06:31:46 Last log entry: 86106: Allow users greater control over advice markers (tests and docs included)
