Re: [flux-dev] Headless JDT in Spring application?

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey Yoann,

more comments inline…


> Interesting. I don't have a good understanding of OSGi and Eclipse Plugin Development so it's nice to hear the actual challenges. It's not very encouraging though especially when I found out that Spring stopped releasing Spring OSGi bundles. Also I'm not a big fan of being forced to build an OSGi component just because I want to reuse another OSGi component.
> 
> But Mike mentioned the Virgo project which I didn't know about and it seems maintained. I'll look into it.

I agree with Mike, Virgo is probably the best way to integrate Spring with OSGi.
On the other hand, you could also try to use Spring as it is and try to re-use parts of JDT without running that on top of OSGi (depending on the parts of JDT that you would like to use). More on that below.


> Where I was getting at, and I think it follows the philosophy of Flux where we should reuse existing programming tools to build cloud services, is that JDT is definitely a powerful piece of technology when it comes to dealing with Java projects and it would be a shame if it was difficult to build a cloud service with it. 
> 
> The success of Flux will depend, among a lot of other things, on its ecosystem of services. I understand that a Flux service doesn't necessarily have to do anything with the code but I feel like most of the important services do: build, code quality, documentation, navigation, refactoring, content assist, debugging, tests, visualization, etc. Also I'm sure that a lot of Eclipse plugins use some parts of JDT. How would you go about porting them to a cloud Flux service? This is why I said I wish JDT was easy to reuse.

I am not an expert on JDT, so you might wanna take a look and ask the JDT experts on the JDT mailing list for advice how to use JDT without running it on top of OSGi. From what I know many parts of JDT are build for an IDE and not a headless service running somewhere. That is why it depends not only on OSGi, but also on an Eclipse project definition, classpath setup, etc. So it highly depends on what you would like to do and what parts to JDT are necessary for that.


> I want to build a code visualization service. It's basically a web application which allows users to interact with a visual and interactive map of the code. The goal is to help developers better understand code, and faster. The map can be controlled from the IDE. And the IDE can be controlled from the map. I would like to connect my service to Flux to benefit from the integration with IDEs. This way I don't have to create one plugin per IDE, and I think it's a good idea to already be in the cloud since you said that's where all the other development services are. In order to build and keep updated a map that matches the underlying code I need to interact with the code through concepts like bytecode/AST/Java model. This is where JDT comes in.
> 
> I am very reluctant to make my Spring web application an OSGi component. Therefore I will consider the 2 other options I can think of.
> 	• Use JDT in a very thin service. Delegate most of the business logic to the Spring web application (or other Spring microservices). Both communicate with a messaging system.
> 		• Looks good but I need to assess if I can meet performance goals
> 	• Do not use JDT
> 		• OSGi is out of the equation

I know that you can re-use the JDT compiler without running OSGi, so maybe all you need can be obtained from that setting? Again, not sure about the JDT internals, but I would at least take a look at that.

HTH,
Martin