Thread: [Embedlets-dev] Re: ANT and the Graphical Wiring tool...
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 16:28:46
|
Ted: > One reason is because using Ant or not makes a significant impact on how > the Wiring Tool is designed. If we make the decision to go with Ant then > I can see how the Wiring Tool could heavily leverage Ant's capabilities > for everything from application assembly to packaging and deployment. It > would be much easier to start laying out the architecture of the Wiring > Tool if this decision were made up front. I envisioned the Wiring tool as just being responsible for the specification of how an Outpost application was wired together (which embedlets, device drivers/JAPLs, adapters), and would simply generate the XML Config file declaration that represents this wiring. Then it would only call the regular (non-graphical) build process upon request (which might be an ANT build, but that is just calling a java process like almost any other). The actual code generation (if needed), compiles and packaging would be done by the build process, not the Wiring tool. There is good reason to keep the build process decoupled from the wiring process in this way. As for deployment, that will almost always be application specific, as in your multiple controller/PDA/etc. example. It gets more complicated since some of our target platforms will not easily support dynamic reconfig/redeployment (think about a JStamp....you need a JTag connection to load/burn new code). I think that application-specific deployment will not be something that we should/can tackle early on (if ever) in the Embedlets project. Admittedly, the deployer (put your high-paid consultant hat on, Ted! ;-) ), could probably create automated deployment capabilities using Ant, but they would be custom to each implementation. Brill adds: > I assume the application does not need Ant to work. That is correct....the runtime will not require Ant, just the build/assembly/packaging process. > however I don't think the XML file > format *has* to be the Ant format... in fact I could think of some arguments > against it (also for it but thats another thing) starting with separation of > usage (which I think is a good idea in this case). The intention is that both the Container (Outpost) and Component (embedlet) XML config files will NOT be Ant format. They will be more akin to the Tomcat server.xml and servlet web.xml files. The Ant build.xml file would be a separate file, and would/could use the config files in the various stages of the build as appropriate (eg. for code generation of static application "glue/wiring" logic for very constrainted platforms). What this means is that the build process can be automated with Ant, but all the "ingredients" that specify the final Outpost app could be built with a different tool using the individual container config, component configs, wiring specification, classes, etc. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-02-06 22:11:50
|
Andrzej, >I envisioned the Wiring tool as just being responsible >for the specification of how an Outpost application was >wired together (which embedlets, device drivers/JAPLs, >adapters), and would simply generate the XML Config file >declaration that represents this wiring. Then it would >only call the regular(non-graphical) build process upon >request (which might be an ANT build, but that is just >calling a java process like almost any other). My vision for the Wiring Tool is for it to be able to do everything you have laid out here because I agree that they are important to the project. I will call this the Wiring Tool's 'specification' mode. But I also want it to go beyond these capabilities. The Wiring Tool will have a mode where it will host a live Embedlet Container and as Embedlets are dragged from a pallet and dropped into the container they are instantiated and completely functional. I will call this the Wiring Tool's 'live wiring' mode. In live wiring mode, the JAPL pallet will contain a selection of JAPL peripherals on it that can be dropped into the wiring area and then attached to the sides of the Embedlet Container just as you have shown in the Architecture document. These JAPL interfaces can then be implemented by simulated I/O modules (which are wired to the implementation side of the JAPL peripheral) or by physical PnP modules that are attached to the workstation. As the Embedlet based application is wired together, its functionality can be continuously tested by sending live events to the Embedlets using a dialog in the Wiring Tool or by triggering the simulated JAPL I/O module or by triggering the physical I/O module. I also think that perhaps something like JUnit tests could also be generated for both sides of the JAPL interfaces so that the application can be continuously tested from outside the Embedlet container and the I/O modules could be tested from the inside. The ID tags on the I/O modules can also be read or configured at this time so that when the I/O circuit is detached from the workstation and moved over to the target embedded system the application has already had its bindings made with the I/O modules. The application is manipulated until it is running as desired. No compilation occurs during this process and none is needed because all of the Embedlets used in this mode have already been pre-compiled. At this point one has a complete Embedlet object graph that is configured and wired together as desired and all of the configuration file information that can be specified in specification mode already exists in this live object graph. One now has the following choices that can be made: 1) Have all of the configuration files for all of the Embedlets and JAPL peripherals automatically generated from this object graph. This can be done by either a) analyzing the object graph in memory and converting it into the XML configuration file formats or by b) using the Long Term Persistence API to serialize the object graph into an XML file format which can then be used to generate the needed XML files. 2) The object graph represents the application exactly as we want to have it running on the target system so we serialize this object graph, send it to the target system using whatever method method is appropriate and then deserialize it into the target system's Embedlet Container. Of course, each Embedlet's .class file will also need to be sent to the target system but I am hoping that something like a BAR file could accommodate not only .class files and other needed resources, but a serialized object graph if desired too. TINI/TStik already have deserialization capabilities and I have tested this idea on a TINI and it works just fine. As soon as Ajile releases their CDC implementation JStamp/JStik will have deserialization capabilities too. James has said that muivum could also accomodate this technique if needed. The reason that I like the idea of leveraging Ant is that operations that would have been built into the Wiring Tool (and thus dependent on it) could be moved into Ant. For example, the generation of Embedlet configuration files from a serialized object graph could be done in Ant so that this operation can be used by the Wiring Tool and by any other entity that is capable of using Ant. So again, I am committed to giving the Wiring Tool a specification mode that will operate any way you and others think is appropriate for generating Embedlet configuration files but I am going to attempt to give the Wiring Tool a live wiring mode too. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-02-07 05:45:49
|
Ted, can you (or have you already?) create a CVS module for the JAPL stuff please (I'm assuming you are the fellow to talk to about this). I've started this by creating a UML class diagram to help get my head straight around what is needed... BTW - if anyone is interested, I'm using ArgoUML, but I'll provide everything as graphics everyone should be able to view them, and they can be included in the various documentation. FYI - if anyone has a specific package they would like to use, speak now ;) I am currently using "javae.japl" as in "java embedded" and as opposed to "javax, java extension", which I chose so as not to confuse it with java or javax but to give it a more standards based name. Anyway, its not immutable... so suggestions would be good. I will eventually port Cork to the package structure we use here... as in "javae.cork" (or javam.cork?). - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Ted K. <tk...@ya...> - 2003-02-07 08:55:07
|
Brill, > Ted, can you (or have you already?) create a CVS module for the JAPL stuff > please (I'm assuming you are the fellow to talk to about this). Yes, it is src/org/japl but this is just an experimental directory structure so start putting stuff in there and we can always refactor the directory structure later if needed. > > I've started this by creating a UML class diagram to help get my head > straight around what is needed... Well, this is good! I am a big fan of UML and I think others on this list are too (I assume that since Andrzej lists Together as his top end IDE that this is the case with him too?). Brill states: > FYI - if anyone has a specific package they would like to use, speak now ;) And Gregg adds: >Well, technically, we should be using a reversed, registered >domain name. We perhaps should find a short and concise one >and register it. I have already taken the liberty to register the following domain names on behalf of the project: 'embedlet.org' for the embedlets code base. 'embedlets.org' for the embedlets main web site. 'japl.org' for the japl code base. And I was really hoping these names would stick so that my investment would not be lost! ;-) I would be happy to pass the ownership of these domain names over to the project if we could figure out the proper way to do this. The only difficulty might be that japl should probably be a separate entity in its own right (apart from Embedlets and Cork) because developers might want to use these interfaces apart from either of these projects. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-02-07 10:07:37
Attachments:
JAPLClassDiagram.gif
|
> > Ted, can you (or have you already?) create a CVS module for the JAPL stuff > > please (I'm assuming you are the fellow to talk to about this). > > Yes, it is src/org/japl but this is just an experimental directory structure so > start putting stuff in there and we can always refactor the directory structure > later if needed. If its not too much trouble, I thought a separate module would be a good idea... it could then have its own build environment and documentation... at the moment there is no source, I just wanted a place to put any docs I write so that if I drop off the face of the earth, its all saved... and people can see how its progressing. > > I've started this by creating a UML class diagram to help get my head > > straight around what is needed... > > Well, this is good! I am a big fan of UML and I think others on this list are > too (I assume that since Andrzej lists Together as his top end IDE that this is > the case with him too?). heh... its pretty sparse at the moment... I've only now had time to sit down and do some thinking. Anyway, I've attached a GIF of the structure (hopefully you can read it) that I've come up with so far (only a few hours today) but it will likely change quite a bit. One thing I quickly realized is that its at the JAPL level that some form of persistance or serialization ability must be integrated... or at least the contract to do it, if not the actual act of doing it. Anyway, I've left that part fairly "light" at this point with a "Storable" interface (named so to differentiate from "Serializable", which is not exactly what is going on). The methods for it take a simple InputStream or OutputStream, so that the actual impl can store it any way that makes sense later (such as XML, or binary etc). The Storable stuff is not set in stone of course and we can look at the way it should actually be done later... I just wanted to add a "placeholder" now with the bare minimum. > I have already taken the liberty to register the following domain names on > behalf of the project: > > 'embedlet.org' for the embedlets code base. > 'embedlets.org' for the embedlets main web site. > 'japl.org' for the japl code base. > > And I was really hoping these names would stick so that my investment would not > be lost! ;-) <choke>, <choke> I guess that sort of define the domains we'll be working under ;) however I don't think the package names have to be domain names in this case (see my previous post). > I would be happy to pass the ownership of these domain names over to the > project if we could figure out the proper way to do this. The only difficulty > might be that japl should probably be a separate entity in its own right (apart > from Embedlets and Cork) because developers might want to use these interfaces > apart from either of these projects. This is true, although cork will likely become part of whatever standard the JAPL becomes, because really Cork is an impl of the JAPL... (although written first, it has a lot of aspects of what JAPL will become). For the moment, cork is its own entity, but I plan to update it to conform to the JAPL as soon as there is something to conform to... in fact I was thinking that along side JAPL could be put JHAL (Java Hardware Abstraction Layer) which Cork has tried to do in providing a common hardware layer so that the same code runs on a JStamp, uVM or a TINI. I expect Outpost will help define the JHAL as the JAPL will have to implement on top of it, and it will be required to run Outpost. It may be that JAPL and JHAL are really the same, the processor is after all a device the same as the JAPL defines, its just not a peripheral. Sheesh... getting complicated! I'd love it if anyone on the list would like to help define the JHAL standard... the number of processors I've used is fairly limited (only about 5 or 6 different ones, and only a few run java). Anyway, for now its just a matter of getting started, so a place to drop documents would be good ;) - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Ted K. <tk...@ya...> - 2003-02-07 10:43:36
|
Brill, > <choke>, <choke> > I guess that sort of defines the domains we'll be working under ;) however I > don't think the package names have to be domain names in this case (see my > previous post). Aside from leveraging the domain name system, how else does one assure that one's packages are globally unique? How do we know that someone in Russia right now is not working on a project that uses 'cork' as its top level package name? > This is true, although cork will likely become part of whatever standard the > JAPL becomes, because really Cork is an impl of the JAPL... But what if someone else wants to develop their own implementation of the JAPL interfaces? If JAPL were its own separate entity then it would be easier for multiple implementations of JAPL to be made and other projects besides Embedlets would also be more likely to use them. > I was > thinking that along side JAPL could be put JHAL (Java Hardware Abstraction > Layer) which Cork has tried to do in providing a common hardware layer so > that the same code runs on a JStamp, uVM or a TINI. This is an interesting idea and I am going to need do some thinking on it... In the mean time, I just checked at godaddy.com and jhal.org is available for $8.95/year if you are interested. ;-) > a place to drop documents would be good ;) Hmmm. As a developer I think you are able to create folders in the CVS? Anyway, I added a 'japl' directory inside of the dev_docs directory so go ahead and start placing your materials here. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-02-07 14:46:55
|
> > <choke>, <choke> > > I guess that sort of defines the domains we'll be working under ;) however I > > don't think the package names have to be domain names in this case (see my > > previous post). > > Aside from leveraging the domain name system, how else does one assure that > one's packages are globally unique? How do we know that someone in Russia > right now is not working on a project that uses 'cork' as its top level package > name? how does the fellow in Russia avoid naming conflicts with the java. package? We're attempting to develop a standard here, that runs on embedded devices where control over the device is important, rather than the "haphazard" way desktop and server software is used... not only that, but Outpost is supposed to remove the nececity of programming the chips. My point is, I think we're safe from accidental naming conflicts, whatever we decide to name the packages. > > This is true, although cork will likely become part of whatever standard the > > JAPL becomes, because really Cork is an impl of the JAPL... > > But what if someone else wants to develop their own implementation of the JAPL > interfaces? If JAPL were its own separate entity then it would be easier for > multiple implementations of JAPL to be made and other projects besides > Embedlets would also be more likely to use them. Oh, I don't mean add cork to the JAPL library... I'm talking about a reference impl the same way Tomcat is a reference impl for the Servlet spec. Still separate, but made for each other ;) > > I was > > thinking that along side JAPL could be put JHAL (Java Hardware Abstraction > > Layer) which Cork has tried to do in providing a common hardware layer so > > that the same code runs on a JStamp, uVM or a TINI. > > This is an interesting idea and I am going to need do some thinking on it... Yah, it's a "fuzzy" area where the JAPL is concerned, because the processor itself could be considdered a "Peripheral" that can be controlled and configured in its own right. Originally cork was supposed to abstract the devices (what the JAPL will do) but the second implemntation has tried to abstract not only the devices, but the runtime environment, so that I can write a "cork" app, and drop it into a TINI or a JStamp, and it works the first time. > In the mean time, I just checked at godaddy.com and jhal.org is available for > $8.95/year if you are interested. ;-) Na, already got a domain I never use ;) > > a place to drop documents would be good ;) > > Hmmm. As a developer I think you are able to create folders in the CVS? > Anyway, I added a 'japl' directory inside of the dev_docs directory so go ahead > and start placing your materials here. Don't know, didn't try, I thought it should be "cleared" with the project manager first, in case you had some special configuration you wanted to implement. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-07 23:57:00
|
> Topic tags:[AR][GW][DO][HW][PM] > _______________________________________________ > > Ted, can you (or have you already?) create a CVS module for the JAPL stuff > please (I'm assuming you are the fellow to talk to about this). > > I've started this by creating a UML class diagram to help get my head > straight around what is needed... > > BTW - if anyone is interested, I'm using ArgoUML, but I'll provide > everything as graphics everyone should be able to view them, and > they can be > included in the various documentation. I just started using it and it looks pretty good. I was disappointed to see that it does not use an XML file format. Oh Well. > > FYI - if anyone has a specific package they would like to use, > speak now ;) > I am currently using "javae.japl" as in "java embedded" and as opposed to > "javax, java extension", which I chose so as not to confuse it > with java or > javax but to give it a more standards based name. Anyway, its not > immutable... so suggestions would be good. > I will eventually port Cork to the package structure we use here... as in > "javae.cork" (or javam.cork?). > The only issue would be the inclusion of java in the namespace - Sun is still pretty protective of that trade name. > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-08 14:39:39
|
[...] > > BTW - if anyone is interested, I'm using ArgoUML, but I'll provide [...] > I just started using it and it looks pretty good. I was disappointed to see > that it does not use an XML file format. Oh Well. Yah, is a little, but Argo was started long before the XML craze. > The only issue would be the inclusion of java in the namespace - Sun is > still pretty protective of that trade name. Yes, I know... I think we're going with "org.japl" for the package. Frankly I'm a little perturbed by it because it was part of Cork, but I guess there is no reason why it can't be separated out in a usage sense. Some thinking will need to go into how it works interfacing with the hardware layer, as its getting a little too separate and independent, where it shouldn't be... however I'm sure it will be worked out. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-07 23:57:02
|
Very nicely stated Ted. This does, however, require a dynamic configuration interface on the container/embedlet side! A static configuration system would involve: 1. Set up your wiring diagram 2. Compile/process - embedlet code generation??? 3. Deploy code with vendors' tools 4. Test with a JMX compliant tool 5. Repeat if not correct Very cumbersome and time consuming. I do see great value in a JAR like packaging system. Very clean, consistent and self contained. > Topic tags:[AR][GW][DO][HW][PM] > _______________________________________________ > > Andrzej, > > >I envisioned the Wiring tool as just being responsible > >for the specification of how an Outpost application was > >wired together (which embedlets, device drivers/JAPLs, > >adapters), and would simply generate the XML Config file > >declaration that represents this wiring. Then it would > >only call the regular(non-graphical) build process upon > >request (which might be an ANT build, but that is just > >calling a java process like almost any other). > > My vision for the Wiring Tool is for it to be able to do > everything you have > laid out here because I agree that they are important to the > project. I will > call this the Wiring Tool's 'specification' mode. > > But I also want it to go beyond these capabilities. The Wiring > Tool will have > a mode where it will host a live Embedlet Container and as Embedlets are > dragged from a pallet and dropped into the container they are > instantiated and > completely functional. I will call this the Wiring Tool's 'live > wiring' mode. > > In live wiring mode, the JAPL pallet will contain a selection of JAPL > peripherals on it that can be dropped into the wiring area and > then attached to > the sides of the Embedlet Container just as you have shown in the > Architecture > document. These JAPL interfaces can then be implemented by simulated I/O > modules (which are wired to the implementation side of the JAPL > peripheral) or > by physical PnP modules that are attached to the workstation. > > As the Embedlet based application is wired together, its > functionality can be > continuously tested by sending live events to the Embedlets using > a dialog in > the Wiring Tool or by triggering the simulated JAPL I/O module or > by triggering > the physical I/O module. I also think that perhaps something > like JUnit tests > could also be generated for both sides of the JAPL interfaces so that the > application can be continuously tested from outside the Embedlet > container and > the I/O modules could be tested from the inside. > > The ID tags on the I/O modules can also be read or configured at > this time so > that when the I/O circuit is detached from the workstation and > moved over to > the target embedded system the application has already had its > bindings made > with the I/O modules. > > The application is manipulated until it is running as desired. > No compilation > occurs during this process and none is needed because all of the > Embedlets used > in this mode have already been pre-compiled. > > At this point one has a complete Embedlet object graph that is > configured and > wired together as desired and all of the configuration file > information that > can be specified in specification mode already exists in this live object > graph. One now has the following choices that can be made: > > 1) Have all of the configuration files for all of the Embedlets and JAPL > peripherals automatically generated from this object graph. This > can be done > by either a) analyzing the object graph in memory and converting > it into the > XML configuration file formats or by b) using the Long Term > Persistence API to > serialize the object graph into an XML file format which can then > be used to > generate the needed XML files. > > 2) The object graph represents the application exactly as we want > to have it > running on the target system so we serialize this object graph, > send it to the > target system using whatever method method is appropriate and > then deserialize > it into the target system's Embedlet Container. Of course, each > Embedlet's > .class file will also need to be sent to the target system but I > am hoping that > something like a BAR file could accommodate not only .class files > and other > needed resources, but a serialized object graph if desired too. > TINI/TStik > already have deserialization capabilities and I have tested this > idea on a TINI > and it works just fine. As soon as Ajile releases their CDC > implementation > JStamp/JStik will have deserialization capabilities too. James > has said that > muivum could also accomodate this technique if needed. > > > The reason that I like the idea of leveraging Ant is that > operations that would > have been built into the Wiring Tool (and thus dependent on it) > could be moved > into Ant. For example, the generation of Embedlet configuration > files from a > serialized object graph could be done in Ant so that this > operation can be used > by the Wiring Tool and by any other entity that is capable of using Ant. > > > So again, I am committed to giving the Wiring Tool a > specification mode that > will operate any way you and others think is appropriate for generating > Embedlet configuration files but I am going to attempt to give > the Wiring Tool > a live wiring mode too. > > > Ted > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
