[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [mylar-dev] support for Spring IDE
|
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