RE: [mylar-dev] support for Spring IDE

["Mik Kersten" <beatmik@xxxxxxx>]

So it sounds like we should focus our future XML efforts on WTP.  This means
that Mylar will have separate structure bridges for the following XML
content types:
- plugin.xml: PDE bridge
- build.xml: Ant bridge
- *.xml: WTP bridge

Since WTP is not part of the SDK this will probably result in an optional
feature that you can choose to download/update.  This will likely get
scheduled sometime after 0.4 is released.  Bug is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=111700

Thanks for outlining those Spring searches of interest.  Regarding whose job
it is to do Spring searches... I see this being analogous to how we treat
Java searches: Mylar's job is to give you convenient access to existing
searches in Active Search (e.g. the 6 kinds of Java search JDT provides),
and to make it trivial for developers to create a new Active Search provider
bridging another plug-ins search with Active Search.  But that's not to say
that additional search heuristics can't be layered on in Mylar if the
plug-in is missing valuable search facilities.  I've created a new report
for the Spring-specific active searches and marked it as "helpwanted":
https://bugs.eclipse.org/bugs/show_bug.cgi?id=111698 

Mik 

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
...
>    I believe that Spring IDE for eclipse only support XML editor from
> WTP (including enriched outline and Spring-aware code completion). So,
> it would be great if Mylar could filter out interest degree for that
> view as well as for Spring Beans view specific for Spring IDE.
> 
>    It would be also cool if Active Search would find references
> to/from Spring application context (I just not sure if it is a job for
> Spring IDE or for Mylar):
> 
> -- references declared in Spring context
> -- dynamic lookups trough BeanFactory subclasses
> -- dynamic lookups without obtaining instance of BeanFactory. E.g.
> static ServiceLocator.getBean(name). This could be quite tricky
> because some hardcoded mappings could be used, like creating
> ClassPathXmlApplicationContext manually or with
> ContextSingletonBeanFactoryLocator.getInstance() (even indirectly from
> convenience EJB classes)
> 
>    regards,
>    Eugene
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev