Morning folks,
I've had a rummage though the archives, but couldn't say I picked up on anything for definite that might sway me more one way than another on this issue ...
Are there any real-world gotchas that would prevent one from moving to using Architect as a plug-in within an existing Eclipse 3.5 environment, rather than being shackled to whatever older Eclipse release is bundled with a given OE release?
I have the 10.1C Architect (seemingly) happily running within Eclipse 3.5, but am just a little edgy about switching all our developers over to suddenly discover down the line that it was common knowledge that you can't syntax check, compile or run your programs when you try to work like this
Experiences and war stories gratefully received.
Cheers, Stu
There is a known issue with OEA and T4BL not working at all with newer version than what shipped with 10.1C, due to changes in EMF.
The current release of OpenEdge 10.2A ships with Eclipse 3.4.
I had to actually go and search to find out what T4BL was ("Tools for Business Logic" for any curious viewers out there) and having done so, I don't think we'll be losing any sleep over it not being available, to be honest
Not all our developers are pure-4GL (oh, sorry "ABL") and the fact that new releases of plug-ins for other development languages want the latest Eclipse release is the main driver behind our being able to successfully use Architect as "just another plug-in" in an overall development environment.
Any more for any more?
I can fully understand that T4BL is no reason not to upgrate the Eclipse version... I started as a nice try and has never evolved since then (except different variations of compile-errors in the generated code).
I haven't tried that but earlier in this forum there was a discussion related to the Visual Designer (GUI for .NET in OpenEdge 10.2A) and different versions of Eclipse. If I'm nont mistaking that Visual Designer has a close dependency on the Eclipse or Java version. Did you try that or is that releavant for you?
Hmm, that would be a bit of a bugger. I've only been looking at 10.1C/Eclipse 3.5 compatability at the minute as that is what our overlords have decided is the current path of righteousness, however, as we will be moving onto 10.2 and .Net GUI at some point in the future that would indeed be an issue.
I'll create another virtual environment and give it a go...
Well, the Architect for 10.2A01 is now running inside Eclipse 3.5. The Visual Designer's up and running and I'm pointing and clicking at it like a mad man and it doesn't seem to have any obvious failings.
Heck, even T4BL seems to be running - though I'm unsure what I'm meant to do with it.
If anyone out there's waiting to rain on my parade, now's the time to do it ...
10.2A01 will probably work fine with 3.5 although me saying this is no guarantee. 10.2A is completely untested on 3.5 since it wasn't available when 10.2a shipped. You will run into problems with this config if you are using a mixed oea sonic environment.
What is it about 3.5 that you need? Does it include something that is unavailable with 3.4?
It's not a particular need for Eclipse 3.5, more a desire to integrate with a "more modern version" than the 3.2 that's shipped with 10.1C.
If we're going through the process of moving all developers (who may or may not be Progress developers) to a common (centrally managed) development environment, it needs to be within a version of Eclipse that supports the development environments suitable for all of those guys, be they working on Java, JavaScript, PHP, XML, .Not, Crystal Reports, Sonic or even Progress. I still don't know if our Progress developers would be moving to using Architect with 10.1 or 10.2, thus the need to explore the possible alternatives.
I haven't even thought about Sonic yet