Source

Is there a link by which one can just download the source?

Not currently. The installer will install the source for you too, though (that'd be your "setup" file). I don't think the installer is too intrusive (doesn't require a reboot, for instance), but I can certainly appreciate the desire for a source-only option.

I find that finding AutoEdge stuff is far from easy. The front page

of PSDN still has 1.0.5, not 1.0.6 and

Is that a proper link (as opposed to a 'most recent' or discussion or similar) ? I couldn't see one but if there is one, I'll get it pointed to the right place.

the links seem to be to either docs or to some kind of setup file ... but I don't want to set it up,

I just want to get the source.

Source-only is not there yet; it's on the to-do list. When you say "source" do you mean just the ABL source? The Savvion models too?

-- peter

See http://communities.progress.com/pcom/community/psdn/openedge?view=overview where there are explicit links to 1.0.4 and 1.0.5, but not 1.0.6.

Ideally, I would like to have the source treated like a library so that I could download any reasonable subset.   I don't know whether I will have an interest in the Savvion models at some point, but right now it is just the ABL source I want.  But, it would be nice to be able to do things like only download the infrastructure stuff, if that is what one wanted to look at.

tamhas schrieb:
See http://communities.progress.com/pcom/community/psdn/openedge?view=overview where there are explicit links to 1.0.4 and 1.0.5, but not 1.0.6.
Ideally, I would like to have the source treated like a library so that I could download any reasonable subset.   I don't know whether I will have an interest in the Savvion models at some point, but right now it is just the ABL source I want.  But, it would be nice to be able to do things like only download the infrastructure stuff, if that is what one wanted to look at.

I must say, that I like the current approach using the installer. Did you run it? It allows you to choose which packages (source or executable) you'd like to have. Much better for those that want to see a lot than having to pick from a large number of individual libraries with the risk of missing something that is a prerequisite for what one wants.

Are you scared your disk may run full?

Maybe a source only installer is a good alternative?

See > http://communities.progress.com/pcom/community/psdn/openedge?view=over

view where there are explicit links to 1.0.4 and 1.0.5, but not 1.0.6.

Ah. Was a missing tag on the 1.0.6 getting started page; thanks for spotting that.

-- peter

mikefe wrote:
I must say, that I like the current approach using the installer. Did you run it? It allows you to choose which packages (source or executable) you'd like to have. Much better for those that want to see a lot than having to pick from a large number of individual libraries with the risk of missing something that is a prerequisite for what one wants.

It's sometime more convenient to have the installer and for AutoEdge looks like the best choice since they are doing a showcase there... however it was discussed before if some parts of AutoEdge could be packed as individual components that one can use as-is or build from, having the ABL 'framework' extracted and available as source code won't justify the need of an installer... well, if it's a Java based one that I can use on Linux might be fine but otherwise a plain and stupid zip file would do it

Good thing you mentioned the 'risk of missing something'... maybe it's time we start thinking about something like package manager with dependencies analyzer, maybe using a Maven repository would be better in that case.

Good thing you mentioned the 'risk of missing something'... maybe it's time we start thinking about something like package manager with dependencies analyzer, maybe using a Maven repository would be better in that case.

Good point - but it should be a comfortable Windows program, maybe like the Cygwin installer. Not a cryptical to use thing that only few people ever get to run on Windows (and since last week we know, this is the only platform for the OpenEdge IDE).

mikefe wrote:
I must say, that I like the current approach using the installer. Did you run it? It allows you to choose which packages (source or executable) you'd like to have. Much better for those that want to see a lot than having to pick from a large number of individual libraries with the risk of missing something that is a prerequisite for what one wants.
Maybe a source only installer is a good alternative?

Source-only option on the installer is certainly one option. Probably the easiest one, since the installer already knows the dependencies.

Another option might be something integrated into the IDE ... some kind of automated download off the Welcome page maybe. Anyone have any thoughts on that?

Maven sounds like a lot - would it be worth it for a small project like AutoEdge? Would it have additional value in terms of showing how-to for other projects?

-- peter

Source-only option on the installer is certainly one option. Probably the easiest one, since the installer already knows the dependencies.
Another option might be something integrated into the IDE ... some kind of automated download off the Welcome page maybe. Anyone have any thoughts on that?
Maven sounds like a lot - would it be worth it for a small project like AutoEdge? Would it have additional value in terms of showing how-to for other projects?
-- peter

Other things we're trying to figure out is how to make code and code paths (ie how does a data request flow through the code) more clear. Working sets in Eclipse is one potential way. Anyone else have any thoughts on how best to do that?

-- peter

An option in PDSOE would be wonderful, especially if it included the project setup ... and wasn't so obscure to find that no one ever found it.

Sounds like a problem in partitioning.  Clear subsystems make that sort of thing very clear, particularly if one is provided with some appropriate diagrams.  AutoEdge seems like a great place to introduce people to using UML to convey understanding.

pjudge wrote:
Source-only option on the installer is certainly one option. Probably the easiest one, since the installer already knows the dependencies.
Another option might be something integrated into the IDE ... some kind of automated download off the Welcome page maybe. Anyone have any thoughts on that?
Maven sounds like a lot - would it be worth it for a small project like AutoEdge? Would it have additional value in terms of showing how-to for other projects?
-- peter
Other things we're trying to figure out is how to make code and code paths (ie how does a data request flow through the code) more clear. Working sets in Eclipse is one potential way. Anyone else have any thoughts on how best to do that?
-- peter

Peter, that might sound like a lot for a small project but as you said AutoEdge is more that a bunch of ABL source code and seems to be quite a few dependencies in place... but again, imho this would be more useful in simply opening the idea of integrated build environments. Mind you I did not used Maven as I was happy with ANT and Hudson so far but it certainly looks like something that could add value.

Project dependencies in Eclipse (well in Architect) does not help much in that regard, one have to download each project manually and figure out the dependencies while this is what Maven does by design

If need help with that I could spend some time trying to figure it out how this can be integrated in OEA... only if planed Linux support is not completelly droped

only if planed Linux support is not completelly droped

Sounds a bit like blackmail ...

tamhas wrote:
only if planed Linux support is not completelly droped 
Sounds a bit like blackmail ... 

Wasn't meant to sound like... but to be a real one

Now more seriously, I think there still is hope and eventually Sunil and he's team would make it a reality. Not to offend Mike in any way but still it's a pity to build an windows only environment on top of Eclipse, be it that the GUI development won't be supported... although Mono support won't make Mike unhappy I guess

encouragement, I'd say

On 13 December 2011 18:50, Thomas Mercer-Hursh

tamhas wrote:
Sounds like a problem in partitioning.  Clear subsystems make that sort of thing very clear, particularly if one is provided with some appropriate diagrams.  AutoEdge seems like a great place to introduce people to using UML to convey understanding.

I'm not really talking about program flows insidea single (sub)system, rather one that flows from UI to DB and back again. This isn't really addressed but better/worse/other partitioning IMO.

Some would argue that UML itself does not make things particularly clear. But in principle, agree that we could do with more complete UML and other documentation.

-- peter

If one has clear UI, BL, and DA subsystems ... and quite possibly subsystems within those based on subject matter, then by good OO principles, the linkage between subsystems should be minimal compared with the linkage internally and it is often considered good design, in fact, to funnel that linkage through a single communication channel in order to make the connection between the subsystems really, really, clear.

E.g., in the architecture design I am working on, a BL component which needs some data is not going to invoke a method on a relevant DA object directly, but rather will send a message with the data request to a facade object.  One might have a separate facade for the BL and for the DA or they might be combined into one bridge object.  The BL side notes the message and possibly keeps track of something like the message ID, who sent it, and whether a response is expected ... possibly even a time stamp.  The DA side inspects the message type and routes it to the correct DA object to fulfill that kind of message.   On the return trip, the BL side looks up who the response should go to and forwards the message.  The facade doesn't pay attention to the contents of the message beyond type and id.   There are half a dozen ways to do something similar.

If one does that sort of thing ... which is, after all, merely good OO practice ... then the interface becomes very clear.  One can, amoung other things, present a diagram of the message traffic summarized at the subsystem level and know that all of that traffic passes through the facade(s).

Now more seriously, I think there still is hope and eventually Sunil and he's team would make it a reality. Not to offend Mike in any way but still it's a pity to build an windows only environment on top of Eclipse, be it that the GUI development won't be supported... although Mono support won't make Mike unhappy I guess 

Marian, you may be surprised now... but I'm sad as well, that OEA doesn't make it on Linux. Our framework has a backend as well and from time to time I need to test that on a Linux machine to make sure that no nice .NET code is making it's way into the backend. I always have a Suse VM with me for that purpose...