Menu
▾
▴
eledge-developers — Mailing list to be used be eledge developers and interested parties
You can subscribe to this list here.
| 2004 |
Jan
(4) |
Feb
(6) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lofi D. <de...@gm...> - 2005-01-25 20:12:29
|
Dear All, OpenUSS has been awarded a prize during ObjectWeb Conference '05 in France - Best Use Case, Category Special Jury's Prize. To see the winners of the award please go to: http://wiki.objectweb.org/ObjectWebCon05/Wiki.jsp?page=AwardWinners Best regards, -- --------------------------------------------------- Blasius Lofi Dewanto --------------------------------------------------- OpenUSS - Open University Support System http://openuss.sourceforge.net --------------------------------------------------- E-Mail : de...@un... --------------------------------------------------- |
|
From: <ben...@id...> - 2004-05-25 09:58:41
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Robert Z. <ro...@sc...> - 2004-04-13 18:42:52
|
I am curious as to everyone's thoughts and opinions about possibly changing our license from GPL to the Apache license, version 2.0. The reason for this change... Gnu has declared that ASF 2.0 and the GPL are incompatible licenses. This means that an application containing GPL'ed code cannot be distributed with ASF code. Our current incarnation of eledge doesn't really use apache code (the cvs version uses commons-fileupload, but I don't believe release 3.1 does), but if we do head down the path to using tapestry, the, apache code will be integrated quite a bit into our application. The apache organization has said that they are in contact with the Gnu organization, and both Gnu and apache may release updated versions of their licenses at some point in the future to make them compatible. In the meanwhile, do we wish to change our license? The license incompatibility does /not/ prevent us from using apache and gpl'ed code. What it /does/ do is prevent us from distributing the code together. This means that we would be requiring our users to not only get tomcat/mysql if they don't have them already (acceptable, as we do not wish to lock our users into any particular servlet runner. For that matter, after using cayenne for the db abstraction, we will no longer be locking our users into mysql, either), but also the tapestry framework, and any other libraries we/they might need (cayenne). At some point, the amount of work to get a project built/working overcomes the payoff to do so. That is to say, it would be nice if we could distribute a source package, but also distribute a prebuilt WAR that can be dropped into any servlet 2.3 spec compliant servlet runner and have our users hit the ground running. Please let me know your thoughts on this matter. (Especially Dr. Wight, as this is your creation and you initially chose the GPL license; if you wish to continue releasing it under that license, we will do so). Robert |
|
From: Robert Z. <ro...@sc...> - 2004-04-13 18:29:28
|
After considerable research, and various integrations with smaller applications using various frameworks, I've decided that, rather than Struts, eledge will be moving in the "Tapestry" direction. I realize that this means we may not be able to easily integrate the navigo project into eledge. Given the fact that navigo has now become part of a larger joint venture, I'm not sure that's the best idea for us now, anyway. Granted, the fact that they are IMS compliant already is a nice bonus, but.... ;) I honestly think we can do better. If you are interested in continuing eledge development, I urge you to go to http://jakarta.apache.org/tapestry and start looking over the documentation. Bonuses to using tapestry over struts: Better localization support MUCH better code reuse. (This is a big one for me) Much LESS "overhead" code to use the framework Better/more integrated support for distributed computing. More secure than struts. Better form validation support. Much better support/integration for multiple forms on a page, and multiple submit buttons within a single form. A great templating system that allows for true and complete separation of model from controller from view. The tapestry learning curve is a bit steeper than struts. But, it is certainly worth it. Additionally, after doing yet more research, I have decided that the "cayenne" framework is also going to be used by eledge as the O/R mapping framework. As an example of the effectiveness of these two frameworks in tandem, I would point you to the national hockey league site, which typically receives in the ballpark of 7 million hits a day. They are running tapestry and cayenne. They recently broke an NHL record with 11 million hits (3.6 Million unique users) in an 18 hour time span. Before progressing further into the structural overhaul of eledge, I will be doing more research into the SCORMS and IMS standards. If anybody has already done this and is able to give a brief synopsis of important points for the standards, instead of me having to wade through however many scores of pages of material, that would be great. ;) Robert |
|
From: Richard C.H. L. <ri...@ar...> - 2004-03-12 07:30:28
|
Dear friends: Most of you will now about the big criminal terrorism action at Madrid. = 192 persons has been murdered and 1473 injured. There is going to be three days of official lute. Today we are going to = concentrate in Madrid at 19:00. It would be good if you can make a littl= e=20 expression of support for the victims and for the cease of violence this= =20 evening, maybe lightning a candle or something like that. Thanks rich from Madrid. |
|
From: Robert Z. <ro...@sc...> - 2004-03-05 18:03:42
|
Richard C.Hidalgo Lorite wrote:
>Hi all:
>
>I'm going to continue my Struts advocacy task :-),
>no talking serious, if your main doubt, Robert, about Struts is the jsp
>as view lawyer, forget it because jakarta velocity guys are working good
>to integrate velocity with struts. I've tested without any problem
>stxx+velocity templates at struts framwork.
>
>Anyway, i will look forward to take a time for tapestry.
>
>rich
>
>
It's actually not the jsp view layer at the current moment in time. ;)
I have other... issues with struts. ;)
I'll get back to you on these. ;)
But, one of the nice things about tapestry, is that you don't have to do
clunky stuff like:
$link.setAction("/SomeAction").addQueryData("XXX","xxx").addQueryParameter("XXX","xxx"))
etc. ;)
Anyway... I"m not saying we won't use struts... I'm just saying that I'm
still looking at some other options out there. ;)
Robert
|
|
From: Richard C.H. L. <ri...@ar...> - 2004-03-05 17:30:16
|
Hi all: I'm going to continue my Struts advocacy task :-), no talking serious, if your main doubt, Robert, about Struts is the jsp = as view lawyer, forget it because jakarta velocity guys are working good= =20 to integrate velocity with struts. I've tested without any problem=20 stxx+velocity templates at struts framwork. Anyway, i will look forward to take a time for tapestry. rich =20 |
|
From: Robert Z. <ro...@sc...> - 2004-03-05 17:05:29
|
Hi all,
I'm taking my sweet time starting the refactoring of eledge to use
struts. Part of the reason for this is that I'm still not completely
convinced that struts is "for us".
I realize that the navigo project is using struts, but... given the fact
that struts is an MVC framework, theoretically, we should be able to
utilize the business object of navigo, even if we change frameworks.
Theoretically. If they haven't delved into poor development habbits and
tied their business objects to struts. (Which I doubt).
One framework that I'm taking a much closer look at is tapestry
(http://jakarta.apache.org/tapestry).
Rich, I'd really like to hear some feedback from you on this framework,
when you get the chance.
What I've seen thus far, I /really/ like. I'll let you know more as I
learn more. ;)
Robert
|
|
From: Robert Z. <ro...@sc...> - 2004-02-26 16:23:25
|
Chuck Wight wrote: >I agree that we need to find a way to make Eledge more scalable. Going to >Struts + Velocity is probably a good idea, but Robert and Richard know much >more about this technical end than I. One of the simple things that we can >do is to use existing resources more efficiently. For example, when I >originally created some of the servlets I did not fully understand issues of >JDBC Connections, Statements and ResultSets, so I created many more >Connection objects than was really required. We can economize on this by >reusing Connection objects, and we can utilize Connection pools. Mainly, >this requires setting up some parameters in Tomcat, and going through the >code to make certain that every Connection object is explicitly closed() >when it is no longer needed by the user (and is therefore freed to the pool >for other users). I understand that relying on the Java garbage collector >to do this is not sufficient. > >Chuck > > Definitely true. I've slowly been going through as I rework, debug, add features, etc. and have been trying to explicitly close result sets, statements, and connections. Regarding pooling, that is also very true. There are a variety of "connection pooling" packages out there (several from jakarta.apache.org of varying degrees of sophistication, as well as other packages from other sources). I haven't determined which will be best to incorporate into eledge, but, it's definitely something we want to keep in mind and work into eledge during our refactoring. Robert |
|
From: Chuck W. <Chu...@ut...> - 2004-02-26 16:14:07
|
I agree that we need to find a way to make Eledge more scalable. Going to Struts + Velocity is probably a good idea, but Robert and Richard know much more about this technical end than I. One of the simple things that we can do is to use existing resources more efficiently. For example, when I originally created some of the servlets I did not fully understand issues of JDBC Connections, Statements and ResultSets, so I created many more Connection objects than was really required. We can economize on this by reusing Connection objects, and we can utilize Connection pools. Mainly, this requires setting up some parameters in Tomcat, and going through the code to make certain that every Connection object is explicitly closed() when it is no longer needed by the user (and is therefore freed to the pool for other users). I understand that relying on the Java garbage collector to do this is not sufficient. Chuck -----Original Message----- From: ele...@li... [mailto:ele...@li...]On Behalf Of ele...@li... Sent: Wednesday, February 25, 2004 9:02 PM To: ele...@li... Subject: Eledge-developers digest, Vol 1 #3 - 2 msgs Send Eledge-developers mailing list submissions to ele...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/eledge-developers or, via email, send a message with subject or body 'help' to ele...@li... You can reach the person managing the list at ele...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Eledge-developers digest..." Today's Topics: 1. Re: Eledge Goals (ri...@us...) 2. Re: Eledge Goals (Robert Zeigler) --__--__-- Message: 1 From: ri...@us... Date: Wed, 25 Feb 2004 08:51:41 GMT Subject: Re: [Eledge-developers] Eledge Goals To: ele...@li... Reply-To: ele...@li... >We need to make eledge more scalable, but find a balance with the=20 flexibility. The proposal is that we >use the struts framework, with=20 velocity templates for the view layer, to make the application more=20 >scalable and maintainable. Some serious thought will need to be put int= o=20 the design to ensure a high >degree of flexibility in the end product.=20 Any thoughts? ;) Agree completely with your assert. About Struts + Velocity I've found=20 that stxx (an SF project) is a very valuable piece of the cake, it sits = at the top of struts and take control, if we want to, for transforming=20 xml data taken from the bussines layer with xsl templates at our choice = (we can , for example, determine the user agent for selecting xsl=20 templates). =20 The good new is that it adds support for velocity too in the struts=20 framework. > 2) Somewhere in all our refactoringg, this needs to be done as we= ll.=20 We need to determine who is >going to work on what aspect. I'm waiting for Navigo release as you now (they have said april) to take= =20 it, plug into EJOSA structure and eledgeizing its UI, but i'm a little=20 low of time because a Portal project i'm working for until june. =20 >eledge, etc.) By creating appropriate interfaces and API's, >we can make extension much easier; in the future, to add a type >assignment, for example, would become much easier, and would "fit" >into the framework that eledge would already be providing. I suggest that you inspire yourself in OKI interfaces. Maybe they're=20 going to turn to a standard and its good to leverage their thoughts and = eventually make Eledge OKI compliant in the future. It's not neccesary t= o=20 =93copy=94 their writed methods cause we can make EledgeOKIAdaptors but = it=20 could be good to understand and agree if convenient to their view of use= =20 cases. >grade/rubric calculation. Other ideas, such as tracking >student access, fall within IMS/SCORMS compliance, as well as here. Look at Navigo code, surprisingly (not at all!) they are using stxx to=20 manage native ims/scorm files, they can take that xml and transform it=20 with xsl templates for rendering. It's good to take xml without=20 transforming it (not even to a object model), the thing I don't like is = the eventual growing complexity of xsl templates but...it's really good = to have this working examples. --__--__-- Message: 2 Date: Wed, 25 Feb 2004 08:51:16 -0700 From: Robert Zeigler <ro...@sc...> To: ele...@li... Subject: Re: [Eledge-developers] Eledge Goals Reply-To: ele...@li... ri...@us... wrote: >>We need to make eledge more scalable, but find a balance with the=20 >> =20 >> >flexibility. The proposal is that we >use the struts framework, with=20 >velocity templates for the view layer, to make the application more=20 > =20 > >>scalable and maintainable. Some serious thought will need to be put int= o=20 >> =20 >> >the design to ensure a high >degree of flexibility in the end product.=20 >Any thoughts? ;) > >Agree completely with your assert. About Struts + Velocity I've found=20 >that stxx (an SF project) is a very valuable piece of the cake, it sits=20 >at the top of struts and take control, if we want to, for transforming=20 >xml data taken from the bussines layer with xsl templates at our choice=20 >(we can , for example, determine the user agent for selecting xsl=20 >templates). =20 >The good new is that it adds support for velocity too in the struts=20 >framework. > > =20 > Huh. Interesting. I took a quick look at stxx just now. I'll have to=20 look at it more in depth in a bit. I was originally just planning on using the "velocity tools"=20 extensions to velocity, which add support for struts, including all of struts 1.1 features (with=20 the newest release), including tiles, validation, and more. What do you see are the benefits=20 to using stxx vs. using "straight" struts+velocity+velocity-tools? >> 2) Somewhere in all our refactoringg, this needs to be done as wel= l.=20 >> =20 >> >We need to determine who is >going to work on what aspect. > >I'm waiting for Navigo release as you now (they have said april) to take= =20 >it, plug into EJOSA structure and eledgeizing its UI, but i'm a little=20 >low of time because a Portal project i'm working for until june. > =20 > April, eh? Ok. Well, I'll let you play with the assessment portion, then. I know that's the area that Fred Weber was most interested in... perhaps=20 you could "get together" with him on this... >=20 > =20 > >>eledge, etc.) By creating appropriate interfaces and API's, >>we can make extension much easier; in the future, to add a type >>assignment, for example, would become much easier, and would "fit" >>into the framework that eledge would already be providing. >> =20 >> > >I suggest that you inspire yourself in OKI interfaces. Maybe they're=20 >going to turn to a standard and its good to leverage their thoughts and=20 >eventually make Eledge OKI compliant in the future. It's not neccesary t= o=20 >=93copy=94 their writed methods cause we can make EledgeOKIAdaptors but = it=20 >could be good to understand and agree if convenient to their view of use= =20 >cases. > > =20 > I plan on dling the entire OKI interface specs and going through them in=20 detail. >>grade/rubric calculation. Other ideas, such as tracking >>student access, fall within IMS/SCORMS compliance, as well as here. >> =20 >> > >Look at Navigo code, surprisingly (not at all!) they are using stxx to=20 >manage native ims/scorm files, they can take that xml and transform it=20 >with xsl templates for rendering. It's good to take xml without=20 >transforming it (not even to a object model), the thing I don't like is=20 >the eventual growing complexity of xsl templates but...it's really good=20 >to have this working examples. > > =20 > I see. So... they are using stxx to go straight from IMS xml to xslt? I'm not sure I fully understand... whe you say "that xml" are you=20 referring to information created by their assessment system, stored in IMS compliant=20 xml files? Or are you referring directly to IMS xml specifications? I'll have to=20 look over the navigo project some more. After going through the OKI information, I'll be putting together 2 sets = of tcm diagrams (if you don't have tcm, http://wwwhome.cs.utwente.nl/~tcm/ is the place to get it; on windows, it requires cygwin). The first set will be "where we are" (ie, a general digram depicting classes, relationships, data/event flow, etc. In general, it will be=20 done in a struts-centric way... that is to say, to take eledge as it stands now and put it into struts, here are the actions, actionforms, and 'screens'=20 that we'll need). This first set is primarily to help everyone understand exactly where we=20 are at. (If you don't want to install tcm, I can make it available as an image=20 file or perhaps a pdf. I may also make this available via the docs page on sourceforge) The second set will reflect more of "where we want to go". I hope to get=20 a lot of input from you all on this set, so please note that whatever I send out at=20 first is, at best, a rough draft. This one will likely also be struts-centric; don't expect a true=20 UML diagram. ;) (I will, however, provide a key for understanding relationships, etc.) Robert --__--__-- _______________________________________________ Eledge-developers mailing list Ele...@li... https://lists.sourceforge.net/lists/listinfo/eledge-developers End of Eledge-developers Digest |
|
From: Robert Z. <ro...@sc...> - 2004-02-25 16:00:30
|
ri...@us... wrote: >>We need to make eledge more scalable, but find a balance with the=20 >> =20 >> >flexibility. The proposal is that we >use the struts framework, with=20 >velocity templates for the view layer, to make the application more=20 > =20 > >>scalable and maintainable. Some serious thought will need to be put int= o=20 >> =20 >> >the design to ensure a high >degree of flexibility in the end product.=20 >Any thoughts? ;) > >Agree completely with your assert. About Struts + Velocity I've found=20 >that stxx (an SF project) is a very valuable piece of the cake, it sits=20 >at the top of struts and take control, if we want to, for transforming=20 >xml data taken from the bussines layer with xsl templates at our choice=20 >(we can , for example, determine the user agent for selecting xsl=20 >templates). =20 >The good new is that it adds support for velocity too in the struts=20 >framework. > > =20 > Huh. Interesting. I took a quick look at stxx just now. I'll have to=20 look at it more in depth in a bit. I was originally just planning on using the "velocity tools"=20 extensions to velocity, which add support for struts, including all of struts 1.1 features (with=20 the newest release), including tiles, validation, and more. What do you see are the benefits=20 to using stxx vs. using "straight" struts+velocity+velocity-tools? >> 2) Somewhere in all our refactoringg, this needs to be done as wel= l.=20 >> =20 >> >We need to determine who is >going to work on what aspect. > >I'm waiting for Navigo release as you now (they have said april) to take= =20 >it, plug into EJOSA structure and eledgeizing its UI, but i'm a little=20 >low of time because a Portal project i'm working for until june. > =20 > April, eh? Ok. Well, I'll let you play with the assessment portion, then. I know that's the area that Fred Weber was most interested in... perhaps=20 you could "get together" with him on this... >=20 > =20 > >>eledge, etc.) By creating appropriate interfaces and API's, >>we can make extension much easier; in the future, to add a type >>assignment, for example, would become much easier, and would "fit" >>into the framework that eledge would already be providing. >> =20 >> > >I suggest that you inspire yourself in OKI interfaces. Maybe they're=20 >going to turn to a standard and its good to leverage their thoughts and=20 >eventually make Eledge OKI compliant in the future. It's not neccesary t= o=20 >=93copy=94 their writed methods cause we can make EledgeOKIAdaptors but = it=20 >could be good to understand and agree if convenient to their view of use= =20 >cases. > > =20 > I plan on dling the entire OKI interface specs and going through them in=20 detail. >>grade/rubric calculation. Other ideas, such as tracking >>student access, fall within IMS/SCORMS compliance, as well as here. >> =20 >> > >Look at Navigo code, surprisingly (not at all!) they are using stxx to=20 >manage native ims/scorm files, they can take that xml and transform it=20 >with xsl templates for rendering. It's good to take xml without=20 >transforming it (not even to a object model), the thing I don't like is=20 >the eventual growing complexity of xsl templates but...it's really good=20 >to have this working examples. > > =20 > I see. So... they are using stxx to go straight from IMS xml to xslt? I'm not sure I fully understand... whe you say "that xml" are you=20 referring to information created by their assessment system, stored in IMS compliant=20 xml files? Or are you referring directly to IMS xml specifications? I'll have to=20 look over the navigo project some more. After going through the OKI information, I'll be putting together 2 sets = of tcm diagrams (if you don't have tcm, http://wwwhome.cs.utwente.nl/~tcm/ is the place to get it; on windows, it requires cygwin). The first set will be "where we are" (ie, a general digram depicting classes, relationships, data/event flow, etc. In general, it will be=20 done in a struts-centric way... that is to say, to take eledge as it stands now and put it into struts, here are the actions, actionforms, and 'screens'=20 that we'll need). This first set is primarily to help everyone understand exactly where we=20 are at. (If you don't want to install tcm, I can make it available as an image=20 file or perhaps a pdf. I may also make this available via the docs page on sourceforge) The second set will reflect more of "where we want to go". I hope to get=20 a lot of input from you all on this set, so please note that whatever I send out at=20 first is, at best, a rough draft. This one will likely also be struts-centric; don't expect a true=20 UML diagram. ;) (I will, however, provide a key for understanding relationships, etc.) Robert |
|
From: <ri...@us...> - 2004-02-25 08:57:29
|
>We need to make eledge more scalable, but find a balance with the=20 flexibility. The proposal is that we >use the struts framework, with=20 velocity templates for the view layer, to make the application more=20 >scalable and maintainable. Some serious thought will need to be put int= o=20 the design to ensure a high >degree of flexibility in the end product.=20 Any thoughts? ;) Agree completely with your assert. About Struts + Velocity I've found=20 that stxx (an SF project) is a very valuable piece of the cake, it sits = at the top of struts and take control, if we want to, for transforming=20 xml data taken from the bussines layer with xsl templates at our choice = (we can , for example, determine the user agent for selecting xsl=20 templates). =20 The good new is that it adds support for velocity too in the struts=20 framework. > 2) Somewhere in all our refactoringg, this needs to be done as we= ll.=20 We need to determine who is >going to work on what aspect. I'm waiting for Navigo release as you now (they have said april) to take= =20 it, plug into EJOSA structure and eledgeizing its UI, but i'm a little=20 low of time because a Portal project i'm working for until june. =20 >eledge, etc.) By creating appropriate interfaces and API's, >we can make extension much easier; in the future, to add a type >assignment, for example, would become much easier, and would "fit" >into the framework that eledge would already be providing. I suggest that you inspire yourself in OKI interfaces. Maybe they're=20 going to turn to a standard and its good to leverage their thoughts and = eventually make Eledge OKI compliant in the future. It's not neccesary t= o=20 =93copy=94 their writed methods cause we can make EledgeOKIAdaptors but = it=20 could be good to understand and agree if convenient to their view of use= =20 cases. >grade/rubric calculation. Other ideas, such as tracking >student access, fall within IMS/SCORMS compliance, as well as here. Look at Navigo code, surprisingly (not at all!) they are using stxx to=20 manage native ims/scorm files, they can take that xml and transform it=20 with xsl templates for rendering. It's good to take xml without=20 transforming it (not even to a object model), the thing I don't like is = the eventual growing complexity of xsl templates but...it's really good = to have this working examples. |
|
From: Lofi D. <de...@gm...> - 2004-02-10 20:41:37
|
Hi All, I check-in the first version of ejosa-revo, which supports AndroMDA (Model Driven Architecture) and EJOSA (Sourcecode Centric Development). This version supports JOnAS 3.3.5 (the most up-to-date with Tomcat) and Enhydra 5.1 (also the most up-to-date). To build from CVS you need: - to download the ejosa.revo.beta-ext-libs.zip, which are the external libraries needed (no need to download anything else, everything included!). http://prdownloads.sourceforge.net/ejosa/ejosa.revo.beta-ext-libs.zip?download - if you want to see the UML diagram - I introduced a new directory "model" for those diagrams - please download the community - free edition of PoseidonUML. The diagram is in model/src directory. http://www.gentleware.com I also introduced "apply-all-build.xml" to call every single Ant scripts one by one. This can also be seen as a help to know the whole build process. Another new directory is "src-generated". Everything which are generated (model -> code, code -> Xdoclet) will be saved in this directory. So, please *never* edit those files by hand as they will be overwritten on the next generation cycle.Everything which should not be overwritten, should be written under standard "src" directory. As you can see with the "ejosa-revo/dev-piggybank-swing-enhydra-ejb-hibernate" example, you'll find no specification/src and only specification/ src-generated as all the interfaces can be fully automatically generated from the model! Build Process: 0. dev-cartridges (AndroMDA cartridges for EJOSA) dev-cartridges/build/apply-all-build.xml 1. dev-framework (internal framework needed): dev-framework/business/build/apply-all-build.xml dev-framework/presentation/build/apply-all-build.xml dev-framework/utility/build/apply-all-build.xml 2. dev-xxx (examples): 2.1 model/build/build-andromda.xml 2.2 specification/build/apply-all-build.xml 2.3 business/build/apply-all-build.xml 2.4 presentation/build/apply-all-build.xml 2.5 test/build/apply-all-build.xml Only dev-converter has no "model", because this is too easy ;-) - ejosa-revo/dev-jonas-alarm-jsp-ejb: a JOnAS example which is added with UML model: - model: UML class diagrams. - specification: ejosa-specification-ejb cartridge (*Home, *Object, EJB oriented). - business: no cartridge, EJB 1.1. - presentation: no cartridge, JSP, Servlet with Tomcat. - ejosa-revo/dev-piggybank-swing-enhydra-ejb-hibernate: is the old example with SSB and Hibernate. - model: UML class diagrams. - specification: ejosa-specification-independent cartridge. - business: ejosa-business-ejb-hibernate, EJB 1.1 with Hibernate. - presentation: no cartridge, Enhydra, XMLC. - other examples are following (ejb 1.1 and ejb 2.0). IDE users: - For NetBeans users: you need to use the most up-to-date version (NetBeans 3.6 Beta) to compile the model into the codes, because of classloader problem with the older NetBeans. - For Eclipse users: everything is included (.cvsignore, .classpath, .project), so that all the classpaths will be automatically done for you). To run the example, just as usual use the Ant script on the "bin" directory -> business/bin and presentation/bin. For ejosa-revo/dev-jonas-alarm-jsp-ejb example you can also run the application as a whole under application/bin (don't forget to run the application/build/apply-all-build.xml before). I provide many cartridges AndroMDA cartridges for different purposes: Specification API "specification": ejosa-specification-remote ejosa-specification-independent ejosa-specification-ejb Business Implementation "business": ejosa-business-ejb (with Business Delegate, DTO, PK, DTOFactory) ejosa-business-ejb-hibernate (with Business Delegate) Presentation Implementation "presentation": ejosa-presentation-enhydra-xmlc (not yet finished, coming soon). I'll update the EJOSA documentation a.s.a.p. so that there will be more stuffs to read for the cartridges. Have fun! -- --------------------------------------------------- Blasius Lofi Dewanto --------------------------------------------------- OpenUSS - Open University Support System http://openuss.sourceforge.net --------------------------------------------------- E-Mail : de...@un... ICQ : 39343280 --------------------------------------------------- |
|
From: Robert Z. <ro...@sc...> - 2004-02-07 17:48:56
|
Attached is a plain text file with some of my thoughts and notes for eledge. I actually have a lot more, but, in the interest of everyone's time, I've tried to cut things down a bit. ;) Thanks! Robert |
|
From: Robert Z. <ro...@sc...> - 2004-01-23 14:38:59
|
Ric...@ns... wrote: >>Robert >>I've also got a graphic designer on my team at work, and he is going to >> >> >be working on changing the html out for velocity templates, based on the >current output. He's going to take us away from major table-centric >formatting to using CSS for the formatting, and having external >stylesheets for "skinnableness", etc. ;) >Good! > > >>Anyway, that's where I'm at. How about you? >> >> >Well, I've done hard work learning EJOSA+Struts. Been working in their >sample application PiggyBank in order to make it struts-enabled in the >context of EJOSA. >Think I make some progress but I,ve been collaterally affected by the >fact of tomcat not being especifically supported by EJOSA. Lofi has said >he's working in a new EJOSA version supporting Tomcat and I'm waiting for >that version in order to complet my strut learning with the PiggyBank app >adaptation work. > >About possible next steps in Eledge, this is more or less my >thoughts...I'm interested in start architecture extruding and ims support >for Eledge with Assessment features, then I think it will be worthwile to >wait for Navigo releasing (this months, see their answer to me at their >sf project forum, see sakaiproject too http://www.sakaiproject.org) >-Take EJOSA (tomcat) version. >-End EJOSA+Struts sample. >-Take Navigo Release >-Adapt Navigo to EJOSA >-Eledgeize Navigo UI (and Features if necessary) >-Take for MEDEA any 'framework taste' code (Eledge could be a Learning >Platform that make use of MEDEA framework services). > >What do u think? > > Sounds like a good plan. =) (Especially since navigo is releasing their code soon. ;) I've done quite a bit of struts study, but I confess to not having an enormous amount of ejosa study... when you finish the "strutsization" of the piggybank app, will you please send it my way so I can look it over? Also, I'm currently in the process of writing a document that attempts to describe where we are at, and where I see us going, ways we can improve every faucet of eledge, etc. I'll send it along when it's done/organized/etc. =) Robert |
|
From: Robert Z. <ro...@sc...> - 2004-01-23 14:24:04
|
That's great news! Regarding the demo... currently, the demo runs on a University of Utah server. Dr. White needs to affect changes there. Alternatively, I can talk with my employer and see if they would consider letting me place a publicly accessible demo course on one of our servers. I'll let you know what they say. Robert Richard C.Hidalgo Lorite wrote: >Dear team, Robert: >At last I've received and commited potuguese translation by Yara. >Maybe, it would be good to test and pack it... >one question >It would be possible to modify eledge.sourceforge.net demo putting >country flag icons leading to the localized versions in order to let all >our translators and international public try it on-line? > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Eledge-developers mailing list >Ele...@li... >https://lists.sourceforge.net/lists/listinfo/eledge-developers > > |
|
From: Lofi D. <de...@gm...> - 2004-01-23 14:15:39
|
Hi All, >>Anyway, that's where I'm at. How about you? > > Well, I've done hard work learning EJOSA+Struts. Been working in their > sample application PiggyBank in order to make it struts-enabled in the > context of EJOSA. > Think I make some progress but I,ve been collaterally affected by the > fact of tomcat not being especifically supported by EJOSA. Lofi has said > he's working in a new EJOSA version supporting Tomcat and I'm waiting for > that version in order to complet my strut learning with the PiggyBank app > adaptation work. yes with the new version of EJOSA you'll have a full Tomcat support. It's very nice that Rich used EJOSA, so we all can have a same component structure (presentation, spec, business, data, etc.): -> Easier to adopt -> Easier to reuse -> Standardize the libraries > About possible next steps in Eledge, this is more or less my > thoughts...I'm interested in start architecture extruding and ims support > for Eledge with Assessment features, then I think it will be worthwile to > wait for Navigo releasing (this months, see their answer to me at their > sf project forum, see sakaiproject too http://www.sakaiproject.org) > -Take EJOSA (tomcat) version. > -End EJOSA+Struts sample. > -Take Navigo Release > -Adapt Navigo to EJOSA > -Eledgeize Navigo UI (and Features if necessary) > -Take for MEDEA any 'framework taste' code (Eledge could be a Learning > Platform that make use of MEDEA framework services). Yes, great stuff. We need to exchange components so that we don't have to reinvent the wheel. I'm actually so far with the first version of EJOSA Revolutions. I also completed the upgrade so that we can standardize on Tomcat. I'll check in the first code into CVS a.s.a.p. Stay tune! -- --------------------------------------------------- Blasius Lofi Dewanto --------------------------------------------------- OpenUSS - Open University Support System http://openuss.sourceforge.net --------------------------------------------------- E-Mail : de...@un... ICQ : 39343280 --------------------------------------------------- |
|
From: Richard C.H. L. <ri...@ar...> - 2004-01-23 11:15:05
|
Dear team, Robert: At last I've received and commited potuguese translation by Yara. Maybe, it would be good to test and pack it... one question It would be possible to modify eledge.sourceforge.net demo putting =20 country flag icons leading to the localized versions in order to let all= =20 our translators and international public try it on-line?=20 |
