Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGL Development Tools » Set compiler options in EGL New Package wizard(Anyone considered this?)
Set compiler options in EGL New Package wizard [message #895409] Thu, 12 July 2012 18:29 Go to next message
Dan Darnell is currently offline Dan Darnell
Messages: 145
Registered: November 2011
Location: Arkansas
Senior Member
Some of you know that one of my (very few) pet peeves about EGL is the way in which generation targets are indicated. I would rather be able to indicate with an annotation in the source code that Java, JavaScript, LanguageX generation is called for than to do this via Properties settings. I believe that generation target settings are the #1 thing that trips up developers (not just new ones either -- I still get bitten).

One way or another, this needs to be addressed. When EGL was used by people who targeted ONE environment (COBOL and then, later, Java) it wasn't a big deal to have the generation target set behind the scenes. Heck, I'm sure most people set it at the global level and never thought about it again. Now that we are routinely in a two-language generation environment (Java and JavaScript) it doesn't work any more to have these crucial settings acting invisibly behind the scenes. Imagine where we are going to be when we have single EGL projects that target three or more languages...we'll constantly be clicking around to figure out how a given source part is going to compile.

It's Enterprise Generation Language but the "generation" settings are the one thing that the EDT (and RBD) tools manage very poorly.

I am wondering if the team thinks it would be possible to add the EGL Compiler options to the New EGL XXXXXXXX wizards? A great start would be the addition of compiler options to the New EGL Package wizard. (These options are already available at the Project level.) From there, heck yeah, add the compiler options to the other New EGL XXXXXX wizards where applicable.

While the issue is being addressed, why not list the selected generators in the Eclipse Properties view (the tab that show properties in a read-only mode) so that we can easily see as we click on resources (without a right-click->Properties on each resource) the generation targets?

From there, how about something in the editor itself? If that isn't possible, at least list the generation targets in the Eclipse Outline view. Heck, just create a new "EGL Generation" view that appears by default in the EGL perspective along with the Outline and EGL Data views. Even if this view just lists the Generation targets in a read-only mode we'll be ahead of the game. Imagine a world where it is obvious to the developer how a source part is going to compile, at a glance, without any digging into Properties dialogs -- that's where we need to be!

--Dan

[Updated on: Thu, 12 July 2012 18:29]

Report message to a moderator

Re: Set compiler options in EGL New Package wizard [message #895429 is a reply to message #895409] Thu, 12 July 2012 21:08 Go to previous messageGo to next message
Richard Moulton is currently offline Richard Moulton
Messages: 92
Registered: August 2011
Location: Devon, UK
Member
Hi Dan,

I must confess I'm still stuck in the early stages with EGL/EDT and so I've yet to complete and deploy an EGL application to a live environment. As such I don't have the experience you've had; needing to deploy to multiple tiers and using many different languages.

Whilst using EDT I have come to realise that the (default) client, common and server packages dictate whether the generator will generate and compile just javascript (client), javascript and java (common) or just java (server) code.

Now that I understand that fact (yes, it took me a while to realise the underlying significance of these default package names) I kinda like that and in the simple two language environment I'm currently comfortable with I think that will work for me.

It's difficult for me to see past the two language environment and visualise the difficulties a third or fourth language might present, but the fact that it took me a while (although I'm getting on a bit now) for it to dawn on me that the package names were dictating the compiler options, does support your argument. It just wasn't obvious to me how EDT was deciding what to generate and compile, I only stumbled on the fact when looking at a forum question Nathan had posed.

I like your idea of the compiler information being available in the outline view, with some indication where the setting is picked up from (the part, package, project) but I'm not sure that I'd want to embed this in the code itself. However, like I said, I've not been out there implementing EGL applications so (at the moment) I'm not hitting the same challenges that you are.

Well, that's my two-penneth worth.

Richard
Re: Set compiler options in EGL New Package wizard [message #895433 is a reply to message #895429] Thu, 12 July 2012 21:35 Go to previous messageGo to next message
Theresa Ramsey is currently offline Theresa Ramsey
Messages: 62
Registered: July 2009
Location: research triangle park, n...
Member
Hi Dan and Richard,
Thanks for your comments. The project type (and default structure) does control the compiler options, though you can change it for any level of the project.

I would be interesting to make the options chosen more obvious. We'll take this into consideration for a future version.

Thanks for the ideas!
Theresa

[Updated on: Thu, 12 July 2012 21:38]

Report message to a moderator

Re: Set compiler options in EGL New Package wizard [message #895436 is a reply to message #895429] Thu, 12 July 2012 21:42 Go to previous messageGo to next message
Dan Darnell is currently offline Dan Darnell
Messages: 145
Registered: November 2011
Location: Arkansas
Senior Member
Hi Richard.

I think it is people like you (who are picking up EGL/EDT for the first time) that have the most to offer with regard to what struggles are found there and what can be done better. So...great feedback!

This comment of yours struck me as interesting: "...the fact that it took me a while for it to dawn on me that the package names were dictating the compiler options, does support your argument."

That the client, server, and common packages support particular generation targets is a function of the new project wizard setting those options at a package level. I just wanted to clarify that the package names are not actually playing a role. In other words, the "server" package COULD generate client code if you were to change the package setting or you created that package yourself and forgot to go in and adjust the generation target settings.

In a very small and simple project I'm working with right now in RBD I have the following packages:
com.xxxxxx.viewer.data
com.xxxxxx.viewer.ui
com.xxxxxx.viewer.ui.common
com.xxxxxx.viewer.ui.widgets
com.xxxxxx.viewer.services
com.xxxxxx.viewer.util

...and this project references others with their own package structures.

I think the EDT team was genuinely trying to help things with the client, server, and common package structure generated by the wizard but they really just kicked the can down the road a short distance because, before long, a developer does of necessity end up with more complex package structures and that is when the generation target hassle hits and package and source part naming does not necessarily indicate much about a target environment.

Anyway, again, great feedback! Keep it coming...

--Dan

[Updated on: Thu, 12 July 2012 21:49]

Report message to a moderator

Re: Set compiler options in EGL New Package wizard [message #895437 is a reply to message #895433] Thu, 12 July 2012 21:51 Go to previous messageGo to next message
Dan Darnell is currently offline Dan Darnell
Messages: 145
Registered: November 2011
Location: Arkansas
Senior Member
Thanks, for the note, Teresa. But again, it isn't just about making the settings more obvious after the fact -- it's also about making it easier to set the settings! (For example, by letting us specify the options on the New EGL Package wizard.)

--Dan
Re: Set compiler options in EGL New Package wizard [message #895440 is a reply to message #895436] Thu, 12 July 2012 22:17 Go to previous messageGo to next message
Richard Moulton is currently offline Richard Moulton
Messages: 92
Registered: August 2011
Location: Devon, UK
Member
Dan Darnell wrote on Thu, 12 July 2012 22:42
That the client, server, and common packages support particular generation targets is a function of the new project wizard setting those options at a package level. I just wanted to clarify that the package names are not actually playing a role. In other words, the "server" package COULD generate client code if you were to change the package setting or you created that package yourself and forgot to go in and adjust the generation target settings.


Absolutely. The default package names that are generated aren't playing a role. You could change the 'server' package to generate java, javascript or any other compiler you might have.

Also, when you create a new package, such as 'client.widget' then this will adopt the compiler settings from the 'client' package.

You're right, when creating a new package you need to think about the compiler settings you want as there's no prompt or reminder.

As it stands you could use the base package as the determining factor for the compiler settings, so 'com.xxx.client' will generate javascript, 'com.xxx.server' will generate java, etc. and then all sub-packages would generate according to their parent package.

Richard
Re: Set compiler options in EGL New Package wizard [message #895916 is a reply to message #895440] Mon, 16 July 2012 13:43 Go to previous message
Nathan Reed is currently offline Nathan Reed
Messages: 74
Registered: June 2012
Member
Dan:

I am a proponent of abstracting the complication. EGL does this for much of the tooling and does it pretty well. I hope for more of this with regard to DB.

But I like your idea of compile directives at the source level. On several very large as/400 projects we wrote a CL compile option for every program to remember how to compile. And even then someone would compile an unchanged program with the standard compile during distribution and then errors gets thrown during production.

Later releases of iseries gave us a pretty good bank of source level compile directives and that cleared up a lot of the problem.

Like Richard, I am still trying to get a grip on this egl thing. Am not practiced enough with regard to managing packaging to speak intelligently but....... In anticipation of language issues not yet thought of....... Default directives at the package level with override directives at the source level make sense to me (caution: lot of ignorance here).

Good topic.

Thx,

Nathan Reed
Previous Topic:IBM i Program Call under 0.81 M3
Next Topic:document.location gives nullpointerexception
Goto Forum:
  


Current Time: Fri Oct 24 20:31:53 GMT 2014

Powered by FUDForum. Page generated in 0.02572 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software