Ole Ersoy wrote:
John,
I think you are my type of dud :-)
You know that last eclipse newsgroup post in your
mail?
http://dev.eclipse.org/newslists/news.eclipse.technology.ecp/msg00089.html
This is the type of platform I'm targeting.
Except for Tuscany DAS's (Pure ones hopefully,
independent of Hibernate, although Hibernate is really
good).
When When When ???
Did you notice how they talked about JSF? I wrote a
client side JS Framework on Top of Dojo Toolkit (And
donated it to myfacers), so that Server Side and
Client Side can be very much decoupled and only pass
JSON strings back and forth.
Check it:
http://people.apache.org/~matzew/dojo.presentation.zip
http://www.mail-archive.com/[email protected]/msg18916.html
This way the client side Javascript components and the
server side components can be generated and will
mirror eachother.
Yep saw that. Must admit that I am not a javascript guy, but it
provides the functionality needed now. I'm betting on XForms and XQuery
to pull out in the stretch.
OH - Documentation generation:
If you had a chance to look at the Contributor Guide
eclipse plugin you'll see there's a lot of symmetry
between the recipes and the checklists.
It's loaded and I have looked at it. Nice documentation vehicle.
Right now I'm writing a Maven plugin to generate the
whole guide...driving it off of a checklist.xml
document. This way it requires minimal maintenance
and it's just a matter of adding more content, and
everyhting else is generated.
As far as content, I type in XML (is there a schema?) and it transforms
to XHTML with CSS?
Eclipse Infocenter TOC's can then be used to stitch
together many non-primary TOC's to form a whole book.
I'm hoping to have the plugin done by the end of
today. Then it can be a starting point for
documentation and code generation at the same time.
The Ecore Model Editor is pretty good once you get
used to it though. It's strictly for the model part
of a
Presentation - Application - Business - Integration -
Persistance Layered architecture.
I think so too - to build the models once one if familiar with it they
would just do it by hand with the editor. I just wanted the Graphics
for documenting the model with a standard UML look and feel.
Which reminds me of something else, (knowing your a man of many
languages and are fond of documentation - and 'automation maniac'. :-)
I have recently experimented with a tool called Guess.
http://graphexploration.cond.org/
When I worked for what is now called Nortel Networks I managed a team of
programmer consultants that used tools like Guess (Those tools were not
free then and had less functionality than Guess.) to map large ISP
networks. I am now interested in turning a tool like this inward to
give us a way to display and potentially explore coupling problems
between ADS subprojects.
Can you help me with this one question: Is this a stupid idea? (If true
-> I will proceed to the beer camp to immediately prune contaminated
brain cells.)
Could be more friendly in terms of describing what
each StructuralFeature on each ecore element is for...
For the most part though - I think my favorite camp is
"The Beer Camp". :-)
Has to be German beer though,
John
Cheers,
- Ole
--- "John E. Conlon" <[EMAIL PROTECTED]> wrote:
Ole Ersoy wrote:
I think this may have some:
http://www.andromda.org/
>From the description it's my wet dream in
cyberspace.
I started drooling uncontrollably when I saw it.
Then there's this:
http://amateras.sourceforge.jp/cgi-bin/fswiki_en/wiki.cgi?page=AmaterasUML
I've only skimmed though...
And this:
http://wiki.eclipse.org/index.php/GMF_New_and_Noteworthy
Bingo GMF!
http://www.eclipse.org/gmf/gallery/index.php
Okay here is the process:
Service Requirements -> Design -> Artifact
(component) creation->
Warehousing (Repos) -> Deployment -> Component
dependency matrix
->Execution -> Service fulfillment!
The big problem is documentation. It is needed
throughout the chain.
Needed to always answer the archetypical question -
WTF?
But when is doco created? Before or after the
artifact is built, stored,
deployed or run? We need it up front and through
out the lifecycle and
it can't get stale. Artifact with out docs is no
good, can't be
maintained. Doc without artifact, what's the point?
One school of
thought is to do the documentation then the code,
second school says the
code then the documentation, third school says
generate docs from code,
and forth says generate code from docs. (Fifth
school drinks beer.)
Fun times! The third and the forth camps are
converging, and the gap is
closer (touching?) now than ever.
When standard metadata is used properly we can do a
lot with industry
standard tools. (We can even send information
through wires. ;-) )
When documentation is precise enough it becomes
machine readable. (Is a
computer language, like Java just human readable
metadata, or
documentation? Its both.)
Unfortunately the EMF model editor does not do
enough visually to
communicate the ideas behind the model. (The
modeled ideas.) But the
graphics modeling framework GMF stuff does. (A
friend from TogetherJ
told me about this stuff but I forgot.)
Wouldn't it be nice to have one tool that does it
all? With EMF and GMF
I think we do.
Look at this viewpoint of a Eclipse plugin (ie-OSGi
bundle) component
environment.
http://www.eclipse.org/gmf/gallery/pde.png
It is a view of the component dependency matrix!
That is THE documentation picture one needs to
present to application
administrators. Remember -> WTF? (ie - What is The
Function. ;-) ) It
is made possible because all artifacts within the
dependency matrix are
using standard containers. OSGi Bundles, Jars,
Zips,Files, Bits. The
difference between each in this artifact container
hierarchy is
metadata. I can do more with the higher level
artifact containers than I
can with the lower ones because of it.
I had a container conversation recently with someone
and I mentioned
that most projects are using many different kinds of
containers. They
are used so often the developers don't give them a
second thought.
Even this email thread started out with the issue of
container (class)
testing. Interesting you also combined it with
container (aka artifact)
design documentation as well.
Your interest in JPackage and APT/YUM for container
deployment and
dependency matrix support is also an example.
If one adheres to standard containers, one can take
advantage of all the
work being done on those containers. It's the
network effect.
Maven is a managed container (repo) of containers.
The maven folks are
now working to better leverage the new metadata now
available in OSGi
bundles - not only for the automatic metadata
creation at package time
but within the distribution repos as well. One
track of research is
OBR. OBR is the equivalent to APT/YUM but for OSGi
bundles.
http://cwiki.apache.org/FELIX/osgi-bundle-repository-obr.html
Let's face it - the final destination for our
containers is another one
- the JVM container. But we need something in
between that though to
handle the dependency matrix. Two ways to approach
it - we either build
it ourselves or use a standard container.
Eclipse is moving into the enterprise. Friendly
competition I think
(With LDAPStudio ApacheDS is moving to the desktop).
Check out this guy's email thread (and the one that
follows it up one)
I saw them today while looking through the links
that you sent.
I think they really summarize the 'generic'
enterprise requirements
fairly well.
http://dev.eclipse.org/newslists/news.eclipse.technology.ecp/msg00089.html
thanks for all the insights,
warm regards,
John
I see class diagram pictures in there that appear
to
be the diagram equivalent of the ecore
editor...but
have only skimmed...
--- "John E. Conlon" <[EMAIL PROTECTED]> wrote:
No graphics drawing tools with UML like symbols?
Ole Ersoy wrote:
Sorry...at the beginning it should say:
If you open the .ecore model
in a
TEXT/XML
editor you can strip out
all the EClassifiers.
--- Ole Ersoy <[EMAIL PROTECTED]> wrote:
John,
If you open the .ecore model
in an editor you can strip out
all the EClassifiers.
Then you are just left with an EPackage.
This is what the New Ecore Model wizard will
=== message truncated ===
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
