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

[yoann buch <yoann.buch@xxxxxxxxx>]

Thank you Martin and Mike!

Hey Yoann,


> I want to build a cloud service with Spring and connect it to Flux.

That alone is definitely not very complicated, since cloud services in Flux are extremely decoupled from each other. Basically all you need is a connection to the messaging bus and you are ready to go.

Of course your service would have to understand those messages (and probably react to them in a meaningful way), but that is part of the job of a cloud service in Flux.
And since Flux doesn’t requite a specific language or environment for cloud services, you can use whatever technology and language you prefer, including Java and Spring, of course.

Totally agree with you :)

 

> I would like to leverage JDT as part of this service (for the incremental compiler, AST, java model, etc.). You already have created a headless version of JDT (or.eclipse.flux.jdt.service) so it seems feasible. However I am not familiar with OSGi and I'm a little bit confused about how I can use JDT in the context of a Spring application.
>
> Can I simply add JDT jars as dependencies of my Spring app? I don't think so. Am I missing something? What would you recommend?

Hmm… JDT in the way that we are using it at the moment (for the headless JDT service) is running as a set of OSGi components and requires an OSGi runtime to do so - and it is not that hard to get that working. This is what we have done for the headless JDT service.

Combining that with Spring sounds a lot more complicated, since you would have to use Spring in an OSGi environment, which is not that trivial. It is possible, but it is far from trivial as far as I remember. And it depends a bit on how you would like to use Spring. If you would like to use Spring inside a single OSGi component, embedding everything (all the necessary Spring JARs) into the OSGi bundle that is using that could work, but that would end up being a big chunk of coupled code in the end.

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 think it's fair to say that JDT will be very important to build Java cloud services. It would therefore be nice to make it really easy to reuse.

Flux doesn’t prefer any specific library or component for building language services that are running in the cloud. The Java service that we built is re-using JDT, but theoretically you should also be able to use any other library, depending on that you would like to build.

Agree. And I don't even have to use Java to build a Java Flux service.

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.

But you're right JDT is probably not the only library of its kind. Do you know other similar libraries with features like incremental compilation, read and write code through AST/Java model, compilation errors, refactoring, debugging? I can only think of low level libraries/tools like JavaCC or ANTLR. The best I found was SSLR.

 

Maybe sharing some more details about the “why” would shed some light on your problem and help people on this list to provide more guidance.

I hope what I previously wrote helps in that regard. And here I'll explain a little bit more what I'm trying to achieve. 

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

Thanks,

Yoann

 

HTH,
Martin


_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev