Menu
▾
▴
jmove-devel — jmove developer discussions
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2005 |
Jan
(4) |
Feb
(3) |
Mar
|
Apr
(8) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2006 |
Jan
(8) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Axel T. <ax...@sp...> - 2015-01-01 19:52:02
|
Hi Micha, hi Christian, nice to see that jmove is still alive! A happy new year, Axel Am 27.12.2014 um 19:22 schrieb Michael Jürgens <mj...@we...>: > Hi folks, > > the jmove sources are available via git! See details at https://sourceforge.net/p/jmove/git/ > > Currently the CVS repository is also available, but it should not be written anymore. > You may copy the original CVS repository via > > rsync -av rsync://jmove.cvs.sourceforge.net/cvsroot/jmove/* mylocalcvsroot/ > > to your local machine. I made my copy for historical reasons (to remember the good old times with discussions and several coding events). :-) > > I want to delete the cvs repository at the end of january. > > Best regards, > Micha > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: Christian N. <Chr...@we...> - 2014-12-31 02:06:52
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <p class="p1">Old time indeed - initial check in June 2002...</p> <p class="p1">OK for me to delete the CVS.</p> <p class="p1">HNY,<br/> <span style="line-height: 1.6em;">christian</span></p> <div class="gmail_quote" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; line-height: normal;">On Sat, Dec 27, 2014 at 7:22 PM, Michael Jürgens <span dir="ltr"><<a href="mailto:mj...@we..." style="color: rgb(17, 85, 204);" target="_blank">mj...@we...</a>></span> wrote: <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; padding-left: 1ex;"> <div style="word-wrap: break-word;">Hi folks, <div> </div> <div>the jmove sources are available via git! See details at <font color="#4787ff"><u><a href="https://sourceforge.net/p/jmove/git/" style="color: rgb(17, 85, 204);" target="_blank">https://sourceforge.net/p/<wbr/>jmove/git/</a></u></font></div> <div> </div> <div>Currently the CVS repository is also available, but it should not be written anymore. </div> <div>You may copy the original CVS repository via</div> <div> </div> <div>rsync -av <a style="color: rgb(17, 85, 204);">rsync://jmove.cvs.sourceforge.<wbr/>net/cvsroot/jmove/*</a> mylocalcvsroot/</div> <div> </div> <div>to your local machine. I made my copy for historical reasons (to remember the good old times with discussions and several coding events). :-) </div> <div> </div> <div>I want to delete the cvs repository at the end of january.</div> <div> </div> <div>Best regards,</div> <div>Micha</div> <div> </div> <div> </div> <div> </div> </div> <br/> ------------------------------<wbr/>------------------------------<wbr/>------------------<br/> Dive into the World of Parallel Programming! The Go Parallel Website,<br/> sponsored by Intel and developed in partnership with Slashdot Media, is your<br/> hub for all things parallel software development, from weekly thought<br/> leadership blogs to news, videos, case studies, tutorials and more. Take a<br/> look and join the conversation now. <a href="http://goparallel.sourceforge.net/" style="color: rgb(17, 85, 204);" target="_blank">http://goparallel.sourceforge.<wbr/>net</a><br/> ______________________________<wbr/>_________________<br/> Jmove-devel mailing list<br/> <a href="mailto:Jmo...@li..." style="color: rgb(17, 85, 204);">Jmo...@li....<wbr/>net</a><br/> <a href="https://lists.sourceforge.net/lists/listinfo/jmove-devel" style="color: rgb(17, 85, 204);" target="_blank">https://lists.sourceforge.net/<wbr/>lists/listinfo/jmove-devel</a><br/> </blockquote> </div> </div></div></body></html> |
|
From: Michael J. <mj...@we...> - 2014-12-29 07:50:56
|
Hi folks, the jmove sources are available via git! See details at https://sourceforge.net/p/jmove/git/ <https://sourceforge.net/p/jmove/git/> Currently the CVS repository is also available, but it should not be written anymore. You may copy the original CVS repository via rsync -av rsync://jmove.cvs.sourceforge.net/cvsroot/jmove/* <rsync://jmove.cvs.sourceforge.net/cvsroot/jmove/*> mylocalcvsroot/ to your local machine. I made my copy for historical reasons (to remember the good old times with discussions and several coding events). :-) I want to delete the cvs repository at the end of january. Best regards, Micha |
|
From: <mj...@we...> - 2007-03-29 18:22:10
|
Hi Axel, hast Du schon meinen Kommentar zu dem Bug schon gelesen? Ich denke, =20 das ich den Test nicht zum Laufen bringen kann. Vielmehr halte ich =20 die aktuelle Implementierung f=FCr richtig: Der Parser kann keine Typ-=20= Abh=E4ngigkeit erzeugen, wenn er den Typ nicht feststellen kann. Und =20 das wiederum geht nicht in jedem Fall eindeutig (siehe Kommentar). =20 Ich kann mir allerdings vorstellen, dass der Compiler, diese =20 Typinformation erzeugt hat und die Byte-Code-Analyse die Abh=E4ngigkeit =20= erzeugen kann. Gru=DF Michael= |
|
From: <mj...@we...> - 2006-06-24 22:15:27
|
Hi, often meta information is held in javadoc tags, so we can use source code analysis to parse and bind these meta information to our model now. But these information is not exported to XMI yet. I would set the priority for this task to a lower level. Concretely I would add an implementation for an extended XMI export only on demand. What do you think? Ahoi, Michael |
|
From: Christian N. <chr...@we...> - 2006-04-23 19:50:19
|
mj___ schrieb: > ... using IzPack 3.8.1, see > > * project.properties > * releasebuild.xml > * src/installer > > for details. Which jmover icon in src/installer/resources do you like most? > > Michael > > PS: Do you recognize the image in the installer dialog? It took some time, but then I recognized it. And it remind me on some rainy days :-) BTW: If it's still helpful; jmover.ico is good. christian |
|
From: mj___ <mj...@we...> - 2006-04-13 21:21:11
|
... using IzPack 3.8.1, see * project.properties * releasebuild.xml * src/installer for details. Which jmover icon in src/installer/resources do you like most? Michael PS: Do you recognize the image in the installer dialog? |
|
From: Axel T. <ax...@sp...> - 2006-01-28 21:17:10
|
Hi, Am 23.01.2006 um 19:58 schrieb Christian Neumann: > Ja, das weiss ich noch!!! > > Es gibt im Gruppen-verzeichnis (/home/groups/j/jm/jmove) auf dem =20 > SSH-Shell-Server (shell.sf.net) ein Skript (update_website.sh), =20 > welches den aktuellsten Stand aus dem CVS holt und ins =20 > Verzeichnis ./htdocs/test stellt (mit DocBook-Transformation). > > Dort kann mit www.jmove.org/test geguckt werden, ob es stimmt und =20 > dann ggf. einfach eine Ebene h=F6her kopiert werden. > > Dummerweise passen die Default-UMask-Rechte nicht; die Gruppe hat =20 > keine schreibrechte. Meine Versuche, dies im Shell-Skript zu =20 > setzen, waren bisher nicht erfolgreich. Kurzum, der letzte, der das =20= > Skript aufgerufen hat, erzeugt u.U. Files, die von den anderen =20 > nicht =FCberschrieben werden k=F6nnen. > > Dies ist grad der Fall, Axel, entweder m=FCsstest du die Web-Site =20 > aktualisieren oder die Rechte im Gruppenverzeichnis zur=FCcksetzen. Ja, beim bereitstellen von 0.9.3 habe ich auch die Website =20 aktualisiert was auch gut geklappt hat - bis auf die Rechte... Ich =20 werd die Tage mal nachgucken und die Rechte korrigieren und/oder die =20 Website aktualisieren. > > Oder ich m=FCsste ein paar Minuten, Sourceforge zu hacken um mir =20 > kurzerhand mal Root-Rechte zu besorgen... > > Michael J=FCrgens schrieb: >> Hi Christian, >> auch Dir ein frohes neues Jahr (ist glaube ziemlich sp=E4t daf=FCr, =20= >> doch auf jeden Fall ehrlich gemeint)! Ich habe die neue Version =20 >> 0.94 bereitgestellt. Allerdings habe ich die Web-Site noch nicht =20 >> aktualsiert (es fehlt noch die neue Version PDF-Version von =20 >> analsis.xml). Weisst Du noch, wie das Web-Site Update funktioniert? >> Gru=DF >> Michael >> Beste Gr=FC=DFe aus der Mitte von Herne und Dortmund, >> Michael >> Am Freitag, 6. Januar 2006 09:33 schrieb Christian Neumann: >>> ...=E4h...ja...nun...also... >>> >>> Also ich kann jetzt nach Silvester auch so langsam wieder klar >>> denken. >>> >>> Ich stehe an der Bande und feuer euch an. Und vielleicht kann ich >>> dabei einem von euch noch die Stirn abtrocknen. >>> >>> Obwohl, wie ich schon gesehen habe, ists selbst daf=FCr schon etwas >>> zu sp=E4t... >>> >>> Und ich k=F6nnte noch ein "Guets Neus" w=FCnschen; zu mehr reicht = bei >>> mir nicht. >>> >>> christian >>> >>> >>> ______________________________________________________________ >>> Verschicken Sie romantische, coole und witzige Bilder per SMS! >>> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=3D021193 >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through >>> log files for problems? Stop! Download the new AJAX search engine >>> that makes searching your log files as easy as surfing the web. =20 >>> DOWNLOAD SPLUNK! >>> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick >>> _______________________________________________ >>> Jmove-devel mailing list >>> Jmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/jmove-devel >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20= >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD =20 >> SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642 >> _______________________________________________ >> Jmove-devel mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmove-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through =20 > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD =20 > SPLUNK! > http://sel.as-us.falkag.net/sel?=20 > cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D121642 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: Axel T. <ax...@sp...> - 2006-01-28 21:10:29
|
Sorry for the late answer - Yes a textual representation would be helpful... Axel > hi, > > I think about a report representation of the alarm view. In example I > think of textual representation of cycle in the from > > package x.y.z depends on > a.b.d > x.y.z > > Do you think it's helpful? > > Regards, > Michael > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: Christian N. <chr...@we...> - 2006-01-23 18:58:40
|
Ja, das weiss ich noch!!! Es gibt im Gruppen-verzeichnis (/home/groups/j/jm/jmove) auf dem SSH-Shell-Server (shell.sf.net) ein Skript (update_website.sh), welches den aktuellsten Stand aus dem CVS holt und ins Verzeichnis ./htdocs/test stellt (mit DocBook-Transformation). Dort kann mit www.jmove.org/test geguckt werden, ob es stimmt und dann ggf. einfach eine Ebene höher kopiert werden. Dummerweise passen die Default-UMask-Rechte nicht; die Gruppe hat keine schreibrechte. Meine Versuche, dies im Shell-Skript zu setzen, waren bisher nicht erfolgreich. Kurzum, der letzte, der das Skript aufgerufen hat, erzeugt u.U. Files, die von den anderen nicht überschrieben werden können. Dies ist grad der Fall, Axel, entweder müsstest du die Web-Site aktualisieren oder die Rechte im Gruppenverzeichnis zurücksetzen. Oder ich müsste ein paar Minuten, Sourceforge zu hacken um mir kurzerhand mal Root-Rechte zu besorgen... Michael Jürgens schrieb: > Hi Christian, > > auch Dir ein frohes neues Jahr (ist glaube ziemlich spät dafür, doch > auf jeden Fall ehrlich gemeint)! Ich habe die neue Version 0.94 > bereitgestellt. Allerdings habe ich die Web-Site noch nicht > aktualsiert (es fehlt noch die neue Version PDF-Version von > analsis.xml). Weisst Du noch, wie das Web-Site Update funktioniert? > > Gruß > Michael > > Beste Grüße aus der Mitte von Herne und Dortmund, > Michael > > Am Freitag, 6. Januar 2006 09:33 schrieb Christian Neumann: > >>...äh...ja...nun...also... >> >>Also ich kann jetzt nach Silvester auch so langsam wieder klar >>denken. >> >>Ich stehe an der Bande und feuer euch an. Und vielleicht kann ich >>dabei einem von euch noch die Stirn abtrocknen. >> >>Obwohl, wie ich schon gesehen habe, ists selbst dafür schon etwas >>zu spät... >> >>Und ich könnte noch ein "Guets Neus" wünschen; zu mehr reicht bei >>mir nicht. >> >>christian >> >> >>______________________________________________________________ >>Verschicken Sie romantische, coole und witzige Bilder per SMS! >>Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through >>log files for problems? Stop! Download the new AJAX search engine >>that makes searching your log files as easy as surfing the web. >>DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click >>_______________________________________________ >>Jmove-devel mailing list >>Jmo...@li... >>https://lists.sourceforge.net/lists/listinfo/jmove-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel > |
|
From: Michael <mj...@we...> - 2006-01-21 23:12:42
|
Hi Christian, auch Dir ein frohes neues Jahr (ist glaube ziemlich sp=E4t daf=FCr, doch=20 auf jeden Fall ehrlich gemeint)! Ich habe die neue Version 0.94=20 bereitgestellt. Allerdings habe ich die Web-Site noch nicht=20 aktualsiert (es fehlt noch die neue Version PDF-Version von=20 analsis.xml). Weisst Du noch, wie das Web-Site Update funktioniert? Gru=DF Michael Beste Gr=FC=DFe aus der Mitte von Herne und Dortmund, Michael Am Freitag, 6. Januar 2006 09:33 schrieb Christian Neumann: > ...=E4h...ja...nun...also... > > Also ich kann jetzt nach Silvester auch so langsam wieder klar > denken. > > Ich stehe an der Bande und feuer euch an. Und vielleicht kann ich > dabei einem von euch noch die Stirn abtrocknen. > > Obwohl, wie ich schon gesehen habe, ists selbst daf=FCr schon etwas > zu sp=E4t... > > Und ich k=F6nnte noch ein "Guets Neus" w=FCnschen; zu mehr reicht bei > mir nicht. > > christian > > > ______________________________________________________________ > Verschicken Sie romantische, coole und witzige Bilder per SMS! > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=3D021193 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files for problems? Stop! Download the new AJAX search engine > that makes searching your log files as easy as surfing the web.=20 > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: Michael <mj...@we...> - 2006-01-21 23:03:59
|
hi, I think about a report representation of the alarm view. In example I think of textual representation of cycle in the from package x.y.z depends on a.b.d x.y.z Do you think it's helpful? Regards, Michael |
|
From: Christian N. <Chr...@we...> - 2006-01-06 08:33:21
|
...=E4h...ja...nun...also... Also ich kann jetzt nach Silvester auch so langsam wieder klar denken. Ich stehe an der Bande und feuer euch an. Und vielleicht kann ich dabei ei= nem von euch noch die Stirn abtrocknen.=20 Obwohl, wie ich schon gesehen habe, ists selbst daf=FCr schon etwas zu sp=E4t.= .. Und ich k=F6nnte noch ein "Guets Neus" w=FCnschen; zu mehr reicht bei mir nich= t. christian =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/=3Fmc=3D021193 |
|
From: Michael <mj...@we...> - 2006-01-03 08:12:27
|
Hi Axel, let me please checkin the userguide before releasing 0.9.3. Regards, Michael Am Montag, 2. Januar 2006 17:39 schrieb ax...@sp...: > Hi all, > > the junit tests do not fail anymore. So i think it is time for a > release 0.9.3. > > I will build the release during this week if i have a little bit > time. > > Axel > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files for problems? Stop! Download the new AJAX search engine > that makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: <ax...@sp...> - 2006-01-02 16:39:31
|
Hi all, the junit tests do not fail anymore. So i think it is time for a release 0.9.3. I will build the release during this week if i have a little bit time. Axel |
|
From: Michael <mj...@we...> - 2005-12-29 14:02:40
|
Hi,
ich habe es nur kurz =C3=BCberflogen, aber es sieht erstmal okay aus! Wobei=
=20
Ich zugeben muss, dass ich noch nicht =C3=BCber die Auswirkungen=20
nachgedacht habe ("Dies macht auf der einen Seite einige Analysef=C3=A4lle=
=20
komplizierter ....").=20
Gru=C3=9F
Michael
Am Mittwoch, 28. Dezember 2005 14:01 schrieb ax...@sp...:
> Hallo,
>
> ich habe die letzten Tage etwas =C3=BCber die Handhabung von 'Inner
> Types' in jmove gegr=C3=BCbelt. Ursache der Gr=C3=BCbelei waren die
> Unit-Tests, die ich f=C3=BCr den Test der Loader geschrieben habe, durch
> die definiert werden soll, wie innere Typen in einem jmove-Modell
> repr=C3=A4sentiert werden sollen. Je nach Betrachtungswinkel kann man da
> zu unterschiedlichen Auffassungen kommen. Bei dem Beispiel der
> anonymen Klassen sind die folgenden beiden Argumentationen durchaus
> berechtigt:
>
> 1. Man mu=C3=9F anonyme Klassen nicht in das Modell aufnehmen, da sie
> nur ein Implementierungsdetail einer Methode darstellen und ihre
> Abh=C3=A4ngigkeiten zu anderen Klassen k=C3=B6nnen auf die umgebende Klas=
se
> =C3=BCbertragen werden.
>
> 2. Eine anonyme Klasse implementiert immer ein oder mehrere
> Interfaces oder erbt von einer Klassen. Die Information =C3=BCber die
> Vererbungsbeziehung ist wichtig, da sie zum erkennen der Rollen von
> Instanzen in verschiedenen Entwurfsmustern dienen kann (z.B.
> Delegate-Interface).
>
> Evtl. gibt es schon bez=C3=BCglich der anonymen Klassen noch weitere
> Argumentationsm=C3=B6glichkeiten. Bei 'Nested Types' und vor allem
> Member-Klassen gibt es noch mehr Varianten wie man sie in ein
> Modell abbilden k=C3=B6nnte und f=C3=BCr alle Varianten gibt es jeweils g=
ute
> Gr=C3=BCnde. Leider wiedersprechen sich viele Anforderungen und ich habe
> lange dar=C3=BCber nachgedacht alles unter einen Hut zu bringen und bin
> zu keinem zufriedenstellenden Ergebnis gekommen. Ich glaube, da=C3=9F
> dies nicht sinnvoll und wahrscheinlich auch nicht m=C3=B6glich ist.
>
> Die Ursache f=C3=BCr die Widerspr=C3=BCche liegt meiner Meinung nach dari=
n,
> da=C3=9F ein Modell einfach unterschiedlichen Zwecken dienen kann. Und
> der Zweck definiert die ben=C3=B6tigten Informationen und die passendste
> Struktur. Offensichtlich ist dies, wenn man die Analyse von
> Package-Abh=C3=A4ngigkeiten der Analyse von Typ-Abh=C3=A4ngigkeiten
> gegen=C3=BCberstellt. Es sind jeweils unterschiedliche Modellelemente
> und Informationen (z.B. Metriken) relevant. Au=C3=9Ferdem handelt es
> sich bei den Package-Abh=C3=A4ngigkeiten um 'abgeleitete' Informationen,
> die aus den Typ-Abh=C3=A4ngigkeiten berechnet werden. Es handelt sich
> also um eine Vereinfachung.
>
> Wir haben keine gro=C3=9Fen Probleme bei der Koexistenz von Package- und
> Typ-Abh=C3=A4ngigkeiten da sie in dem Modell leicht unterscheidbar sind.
> Bei genauerer Betrachtung arbeitet man aber mit zwei
> unterschiedlichen Modellen, da Menge der jeweils relevanten
> Modellelemente weitgehend disjunkt sind. Sind die
> Package-Abh=C3=A4ngigkeiten einmal bekannt, dann werden im Prinzip die
> Informationen =C3=BCber die Typ-Abh=C3=A4ngigkeiten nicht mehr ben=C3=B6t=
igt und
> umgekehrt ben=C3=B6tigt man die Package-Abh=C3=A4ngigkeiten nicht zur Ana=
lyse
> der Typ-Abh=C3=A4ngigkeiten.
>
> Bei den Typ-Abh=C3=A4ngigkeiten vermischen wir momentan jedoch
> abgeleitete und 'native' Abh=C3=A4ngigkeiten. So wird die Abh=C3=A4ngigke=
it
> eines inneren Typen grunds=C3=A4tzlich auf den umgebenden Typ
> =C3=BCbertragen. Es werden also abgeleitete Abh=C3=A4ngigkeiten hinzugef=
=C3=BCgt.
> Hingegen werden einige 'native' Abh=C3=A4ngigkeiten nicht
> ber=C3=BCcksichtigt. Die Typabh=C3=A4ngigkeiten sind also momentan unter =
der
> Perspektive eines bestimmten Analysezwecks umgesetzt.
>
> Nun kann man folgendes beobachten:
>
> 1. Bei einer detaillierteren Betrachtung der verschiedenen inneren
> Typen m=C3=BC=C3=9Fte man die Abbildung auf das jmove-Modell differenzier=
ter
> umsetzen.
>
> 2. Man kann mit einem Modell nicht allen Analysezwecken gerecht
> werden.
>
> 3. Man kann/sollte jmove nicht auf einen einzelnen Analysezweck
> festlegen.
>
> 4. Eine Vereinfachung des Abh=C3=A4ngigkeits-Modells (z.B. Ersetzen von
> nativen Abh=C3=A4ngigkeiten durch abgeleitete) f=C3=BChrt zu einem
> Informationsverlust, der die Verwendbarkeit eines Modell f=C3=BCr einen
> Zweck der die Informationen ben=C3=B6tigt ausschlie=C3=9Ft.
>
> 5. Die Ableitung von Informationen ist immer auf eine spezielle
> Zweckklasse ausgerichtet. Unterschiedliche Zwecke k=C3=B6nnen
> unterschiedliche Ableitungen erfordern.
>
>
> Daher denke ich, da=C3=9F eine Vermischung von abgeleiteten und nativen
> Abh=C3=A4ngigkeiten keine gute Idee ist und da=C3=9F man unterschiedliche
> Modelle f=C3=BCr unterschiedliche Zwecke ben=C3=B6tigt. Diesen Schlu=C3=
=9F kann
> auch bei der Diskussion einer Fragestellung gezogen werden =C3=BCber die
> wir schon h=C3=A4ufiger gesprochen haben:
>
> Welche Packages/Typen geh=C3=B6ren zu meinem Modell und welche nicht?
>
> Eigentlich m=C3=BC=C3=9Fte die Frage lauten:
>
> Welche Packages/Typen sind f=C3=BCr einen speziellen Zweck relevant?
>
>
> Zur=C3=BCck zu den inneren Typen - diese kann man als Idiome betrachten,
> die eine stark vereinfachte Definition von verschiedenen
> Implementierungsmustern erm=C3=B6glichen. Auch bei inneren Typen handelt
> es sich nur um Java-Typen, die zus=C3=A4tzlichen Constraints bez=C3=BCgli=
ch
> Abh=C3=A4ngigkeiten und Sichtbarkeit unterliegen. Daher schlage ich
> folgenden Umgang f=C3=BCr das n=C3=A4chste Release vor:
>
> - Innere Typen werden in das Modell aufgenommen.
> - Es existiert eine Containment-Beziehung zwischen innerem und
> umschlie=C3=9Fenden Typ. - Die 'nativen' Abh=C3=A4ngigkeiten zwischen inn=
erem
> und umschlie=C3=9Fendem Typ werden so in das Modell aufgenommen, wie sie
> auch zur Laufzeit existieren. Es werden keine 'nativen'
> Abh=C3=A4ngigkeiten weggelassen. - Es werden KEINE abgeleiteten
> Typ-Abh=C3=A4ngigkeiten in das Modell aufgenommen.
>
> Dieses Modell enth=C3=A4lt also keine Vereinfachungen auf Typ-Ebene.
> Dies macht auf der einen Seite einige Analysef=C3=A4lle komplizierter,
> erlaubt auf der anderen Seite aber eine differenziertere
> Betrachtung. In dem n=C3=A4chsten Release (2.0) sollte dann eine
> Unterst=C3=BCtzung f=C3=BCr abgeleitete Modelle existieren und durchg=C3=
=A4ngig
> genutzt werden. So sollten auch die abgeleiteten
> Package-Abh=C3=A4ngigkeiten in ein eigenes Modell existieren.
>
>
> Was haltet ihr davon?
>
>
> Gru=C3=9F,
>
> Axel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files for problems? Stop! Download the new AJAX search engine
> that makes searching your log files as easy as surfing the web.=20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick
> _______________________________________________
> Jmove-devel mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmove-devel
|
|
From: <ax...@sp...> - 2005-12-28 13:01:20
|
Hallo, ich habe die letzten Tage etwas =C3=BCber die Handhabung von 'Inner Types' = in jmove gegr=C3=BCbelt. Ursache der Gr=C3=BCbelei waren die Unit-Tests, di= e ich f=C3=BCr den Test der Loader geschrieben habe, durch die definiert we= rden soll, wie innere Typen in einem jmove-Modell repr=C3=A4sentiert werden= sollen. Je nach Betrachtungswinkel kann man da zu unterschiedlichen Auffas= sungen kommen. Bei dem Beispiel der anonymen Klassen sind die folgenden bei= den Argumentationen durchaus berechtigt: 1. Man mu=C3=9F anonyme Klassen nicht in das Modell aufnehmen, da sie nur e= in Implementierungsdetail einer Methode darstellen und ihre Abh=C3=A4ngigke= iten zu anderen Klassen k=C3=B6nnen auf die umgebende Klasse =C3=BCbertrage= n werden. 2. Eine anonyme Klasse implementiert immer ein oder mehrere Interfaces oder= erbt von einer Klassen. Die Information =C3=BCber die Vererbungsbeziehung = ist wichtig, da sie zum erkennen der Rollen von Instanzen in verschiedenen = Entwurfsmustern dienen kann (z.B. Delegate-Interface). Evtl. gibt es schon bez=C3=BCglich der anonymen Klassen noch weitere Argume= ntationsm=C3=B6glichkeiten. Bei 'Nested Types' und vor allem Member-Klassen= gibt es noch mehr Varianten wie man sie in ein Modell abbilden k=C3=B6nnte= und f=C3=BCr alle Varianten gibt es jeweils gute Gr=C3=BCnde. Leider wiede= rsprechen sich viele Anforderungen und ich habe lange dar=C3=BCber nachgeda= cht alles unter einen Hut zu bringen und bin zu keinem zufriedenstellenden = Ergebnis gekommen. Ich glaube, da=C3=9F dies nicht sinnvoll und wahrscheinl= ich auch nicht m=C3=B6glich ist. =20 Die Ursache f=C3=BCr die Widerspr=C3=BCche liegt meiner Meinung nach darin,= da=C3=9F ein Modell einfach unterschiedlichen Zwecken dienen kann. Und der= Zweck definiert die ben=C3=B6tigten Informationen und die passendste Struk= tur. Offensichtlich ist dies, wenn man die Analyse von Package-Abh=C3=A4ngi= gkeiten der Analyse von Typ-Abh=C3=A4ngigkeiten gegen=C3=BCberstellt. Es si= nd jeweils unterschiedliche Modellelemente und Informationen (z.B. Metriken= ) relevant. Au=C3=9Ferdem handelt es sich bei den Package-Abh=C3=A4ngigkeit= en um 'abgeleitete' Informationen, die aus den Typ-Abh=C3=A4ngigkeiten bere= chnet werden. Es handelt sich also um eine Vereinfachung.=20 Wir haben keine gro=C3=9Fen Probleme bei der Koexistenz von Package- und Ty= p-Abh=C3=A4ngigkeiten da sie in dem Modell leicht unterscheidbar sind. Bei = genauerer Betrachtung arbeitet man aber mit zwei unterschiedlichen Modellen= , da Menge der jeweils relevanten Modellelemente weitgehend disjunkt sind. = Sind die Package-Abh=C3=A4ngigkeiten einmal bekannt, dann werden im Prinzip= die Informationen =C3=BCber die Typ-Abh=C3=A4ngigkeiten nicht mehr ben=C3= =B6tigt und umgekehrt ben=C3=B6tigt man die Package-Abh=C3=A4ngigkeiten nic= ht zur Analyse der Typ-Abh=C3=A4ngigkeiten. Bei den Typ-Abh=C3=A4ngigkeiten vermischen wir momentan jedoch abgeleitete = und 'native' Abh=C3=A4ngigkeiten. So wird die Abh=C3=A4ngigkeit eines inner= en Typen grunds=C3=A4tzlich auf den umgebenden Typ =C3=BCbertragen. Es werd= en also abgeleitete Abh=C3=A4ngigkeiten hinzugef=C3=BCgt. Hingegen werden e= inige 'native' Abh=C3=A4ngigkeiten nicht ber=C3=BCcksichtigt. Die Typabh=C3= =A4ngigkeiten sind also momentan unter der Perspektive eines bestimmten Ana= lysezwecks umgesetzt.=20 Nun kann man folgendes beobachten: 1. Bei einer detaillierteren Betrachtung der verschiedenen inneren Typen m= =C3=BC=C3=9Fte man die Abbildung auf das jmove-Modell differenzierter umset= zen. 2. Man kann mit einem Modell nicht allen Analysezwecken gerecht werden. 3. Man kann/sollte jmove nicht auf einen einzelnen Analysezweck festlegen. 4. Eine Vereinfachung des Abh=C3=A4ngigkeits-Modells (z.B. Ersetzen von nat= iven Abh=C3=A4ngigkeiten durch abgeleitete) f=C3=BChrt zu einem Information= sverlust, der die Verwendbarkeit eines Modell f=C3=BCr einen Zweck der die = Informationen ben=C3=B6tigt ausschlie=C3=9Ft. 5. Die Ableitung von Informationen ist immer auf eine spezielle Zweckklasse= ausgerichtet. Unterschiedliche Zwecke k=C3=B6nnen unterschiedliche Ableitu= ngen erfordern. Daher denke ich, da=C3=9F eine Vermischung von abgeleiteten und nativen Abh= =C3=A4ngigkeiten keine gute Idee ist und da=C3=9F man unterschiedliche Mode= lle f=C3=BCr unterschiedliche Zwecke ben=C3=B6tigt. Diesen Schlu=C3=9F kann= auch bei der Diskussion einer Fragestellung gezogen werden =C3=BCber die w= ir schon h=C3=A4ufiger gesprochen haben:=20 =09Welche Packages/Typen geh=C3=B6ren zu meinem Modell und welche nicht?=20 Eigentlich m=C3=BC=C3=9Fte die Frage lauten: =20 =09 =09Welche Packages/Typen sind f=C3=BCr einen speziellen Zweck relevant? =09 Zur=C3=BCck zu den inneren Typen - diese kann man als Idiome betrachten, di= e eine stark vereinfachte Definition von verschiedenen Implementierungsmust= ern erm=C3=B6glichen. Auch bei inneren Typen handelt es sich nur um Java-Ty= pen, die zus=C3=A4tzlichen Constraints bez=C3=BCglich Abh=C3=A4ngigkeiten u= nd Sichtbarkeit unterliegen. Daher schlage ich folgenden Umgang f=C3=BCr da= s n=C3=A4chste Release vor: - Innere Typen werden in das Modell aufgenommen. - Es existiert eine Containment-Beziehung zwischen innerem und umschlie=C3= =9Fenden Typ. - Die 'nativen' Abh=C3=A4ngigkeiten zwischen innerem und umschlie=C3=9Fende= m Typ werden so in das Modell aufgenommen, wie sie auch zur Laufzeit existi= eren. Es werden keine 'nativen' Abh=C3=A4ngigkeiten weggelassen. - Es werden KEINE abgeleiteten Typ-Abh=C3=A4ngigkeiten in das Modell aufgen= ommen. Dieses Modell enth=C3=A4lt also keine Vereinfachungen auf Typ-Ebene. Dies m= acht auf der einen Seite einige Analysef=C3=A4lle komplizierter, erlaubt au= f der anderen Seite aber eine differenziertere Betrachtung. In dem n=C3=A4c= hsten Release (2.0) sollte dann eine Unterst=C3=BCtzung f=C3=BCr abgeleitet= e Modelle existieren und durchg=C3=A4ngig genutzt werden. So sollten auch d= ie abgeleiteten Package-Abh=C3=A4ngigkeiten in ein eigenes Modell existiere= n. Was haltet ihr davon? Gru=C3=9F, Axel |
|
From: mj___ <mj...@we...> - 2005-07-27 20:18:27
|
Hi Axel, the ui looks fine with the additional icon. Model dependencies for = selected element is cool, because narrowing the module overview make much sense = in bigger projects. I found one possible error in search results and one in dependency view of LoadAction. Finally don't worry about projects with more than 5000 types, they need professional toolkits! ;-) Michael -----Urspr=FCngliche Nachricht----- Von: jmo...@li... [mailto:jmo...@li...] Im Auftrag von ax...@sp... Gesendet: Freitag, 22. Juli 2005 12:10 An: jmo...@li... Betreff: [Jmove-devel] Integrated search ... Hi, i have integrated the search into the jmover. The search now allows searching model elements of type 'Type' 'JPackage' and 'Module' and = opens the dependency view of the selected element when 'ENTER' is pressed. The side effect is that now there are also dependency view of modules next = to the module overview. We have not had them before. And the best is - i = coded no line of code for that it simple worked :-). Because it is not only a type search i renamed the menu entry to 'Go To | Model Element' with the shortcut 'Ctrl G'.=20 By the way i redesigned the search ui a little bit - perhaps you like it more than the old one - at least i do ;-).=20 So please take a look at it and test it. There is one thing i am not = totally happy with. I create the search index each time a search activity is = started by the user. This makes sure that the index is up to date but may be a little bit inefficient in general. The reason for this is that we have = no simple appropiate update mechanism for search indices which listens to = model changes. Building up the search index for smaller models is not = noticeable to the user. I used a model with 800 indexed elements and building up = the index took about 50 ms on my machine. But with bigger models ( > 5000 ) = the user will notice a delay. Axel ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Jmove-devel mailing list Jmo...@li... https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: <ax...@sp...> - 2005-07-22 10:17:10
|
Hi, i have integrated the search into the jmover. The search now allows searching model elements of type 'Type' 'JPackage' and 'Module' and opens the dependency view of the selected element when 'ENTER' is pressed. The side effect is that now there are also dependency view of modules next to the module overview. We have not had them before. And the best is - i coded no line of code for that it simple worked :-). Because it is not only a type search i renamed the menu entry to 'Go To | Model Element' with the shortcut 'Ctrl G'. By the way i redesigned the search ui a little bit - perhaps you like it more than the old one - at least i do ;-). So please take a look at it and test it. There is one thing i am not totally happy with. I create the search index each time a search activity is started by the user. This makes sure that the index is up to date but may be a little bit inefficient in general. The reason for this is that we have no simple appropiate update mechanism for search indices which listens to model changes. Building up the search index for smaller models is not noticeable to the user. I used a model with 800 indexed elements and building up the index took about 50 ms on my machine. But with bigger models ( > 5000 ) the user will notice a delay. Axel |
|
From: Axel T. <ax...@sp...> - 2005-06-06 19:37:35
|
... Great .... :-) Axel > Hi, > > I extended the example for code statistcs. Here are the values for > jmove by source code: > > #packages: 47 > #types: 425 > #classes: 392 > #abstract classes: 11 > #inner classes: 150 > #interfaces: 33 > #inner interfaces: 0 > #methods: 1991 > #lines: 21541 > Max type count for packages: 52 > Max line count for types: 676 > Max line count for methods: 183 > Avg. line count for types: 50.0 > Avg. line count for methods: 10.0 > Avg. type count for packages: 9.042553191489361 > Avg. RCMartin distance: 0.15708107686295525 > Avg. inheritance level: 0.7011764705882353 > > > I hope the values are correct, an average rcmarting distance of 0.15 > seems to be pretty good in my opinion. It would be interesting to > compare this values with famous open source projects like tomcat. > > While we calculate rcmartin metrics on packages, it would be > interesting to build analogous values for modules and then guessing > the the type of modules: technical framework or application. > Furthermore for example we could possible define instability for > modules as dependency on external modules or references. > > I'll integrate a more verbose html version of this values as report to > jmover. > > Regards, > Michael > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can > you shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel > |
|
From: Michael <mj...@we...> - 2005-06-05 19:39:14
|
Hi, I extended the example for code statistcs. Here are the values for jmove by source code: #packages: 47 #types: 425 #classes: 392 #abstract classes: 11 #inner classes: 150 #interfaces: 33 #inner interfaces: 0 #methods: 1991 #lines: 21541 Max type count for packages: 52 Max line count for types: 676 Max line count for methods: 183 Avg. line count for types: 50.0 Avg. line count for methods: 10.0 Avg. type count for packages: 9.042553191489361 Avg. RCMartin distance: 0.15708107686295525 Avg. inheritance level: 0.7011764705882353 I hope the values are correct, an average rcmarting distance of 0.15 seems to be pretty good in my opinion. It would be interesting to compare this values with famous open source projects like tomcat. While we calculate rcmartin metrics on packages, it would be interesting to build analogous values for modules and then guessing the the type of modules: technical framework or application. Furthermore for example we could possible define instability for modules as dependency on external modules or references. I'll integrate a more verbose html version of this values as report to jmover. Regards, Michael |
|
From: <ax...@sp...> - 2005-05-31 06:59:05
|
Hi Michael,
>grunds=C3=A4tzlich teile ich deine Pr=C3=A4ferenzen f=C3=BCr B und D. Aufg=
rund=20
>unserer Planungen w=C3=BCrde ich allerdings das aufwand=C3=A4rmere D=20
>bevorzugen. Die Idee "Projektdatei" finde ich klasse, denn dadurch=20
>wird nichts vorgegaukelt. Mein Vorschlag f=C3=BCr die konkrete Benennung:
>* load/save module compilation
>* load/save module set
"load/save project" ?
>Wir sollten unser Men=C3=BCstruktur daf=C3=BCr weiter standardisieren. Wie=
w=C3=A4re=20
>es mit=20
ja - sollten wir tun...
>
>Model
>=09New
>=09Add module
>=09-----------------
>=09Load module compilation
>=09Save module compilation
>=09-----------------
>=09Export XMI
>=09-----------------
>=09Quit
>
>View
>=09Search types
>=09//Create diagram
>=09//Create report
ich finde die IntelliJ/IDEA Men=C3=BCstruktur ganz sch=C3=B6n (- ja ich bin=
schon ziemlich stark gepr=C3=A4gt... ). Speziell das "Go to" Men=C3=BC. =
Denn das "Search types" entspricht eigentlich sehr dem "Go to/Class". Man k=
ann dann noch andere Navigations-Aktionen dort eintragen:
=20
- Go to
- Class
=09- Package
- Alarms
- Package Overview
---------------
- Contaner
- Details
---------------
- Next
- Previous
....
>Help
>=09Contents
>=09About
>
>
>Bzgl. der mittelfristigen Variante B w=C3=BCrde ich in der Tat ein=20
>textbasierte Format (gerne XML) verwenden, dann sind Fehler leichter=20
>nachvollziehbar und mit entsprechender Komprimierung sollte auch=20
>Speicherplatz weniger ein Problem sein.=20
Ok - wenn das effizienter wird als Byte-Code laden, dann ist mir das recht =
;-).=20
>Prinzipiell halte ich XMI f=C3=BCr=20
>zu =C3=BCberfrachtet, unser schmales Kernmodell bietet sicherlich eine=20
>effizientere Serialisierungsm=C3=B6glichkeit. Allerdings wenn wir auch=20
>Diagramme ablegen wollen...
Ich weiss nicht genau wie Diagramme in XMI dargestellt werden. Ich vermute=
aber mal, dass es da um UML-Diagramme geht. Unsere Diagramme kann man wohl=
nur begrenzt als UML-Diagramme auffassen.
>
>Apropos Diagramme: Es w=C3=A4re super, wenn man Diagramme selbst best=C3=
=BCcken=20
>k=C3=B6nnte: neues Diagramm anlegen, Packages in das Diagramm ziehen,=20
>Abh=C3=A4ngigkeiten werden eingetragen, das Diagramm kann gedruckt=20
>werden....megacool! ;-)
JA!!! :-) - aber nicht f=C3=BCr 1.0 :-(=20
>
>
>Gru=C3=9F
>Michael
>
>
>
>
>Am Montag, 30. Mai 2005 11:31 schrieb ax...@sp...:
>> Hi Michael,
>>
>> da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest
>> etwas Zeit gefunden deine Sachen auszubrobieren. Den Stack-Overflow
>> habe ich allerdings noch nicht gefunden - nun ist es aber doch
>> raus... ;-)
>>
>> >Hi,
>> >
>> >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz
>> > die die Standard-Java-Serialisierung verwendet. Dabei ist mir
>> > Folgendes aufgefallen:
>> >
>> >* Viel "implements Serializable"
>> >* Einige Attribute auf "transient" umgestellt
>> >* StackOverflowError bei Abspeichern des jmove-source-Modells
>> >
>> >Strukturell ist mir aufgefallen, dass unsere abgespeicherten
>> > Modelle nicht transportf=C3=A4hig sind, da assozierte Locations nach
>> > einem Laden nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und so=
mit
>> > Funktionalit=C3=A4t wie Source-Code-Edit nicht funktionieren.
>> >
>> >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen:
>> >
>> >A. StackOverflow beheben: Schwierig, weil die Stelle nicht
>> > verraten wird: ist es einfach die Menge oder erkennt der
>> >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das
>> >Abspeichern und Laden von Byte-Code-Modellen?
>> >
>> >B. Eigene Implementierung der Serialisierung: aufwendig aber
>> >sicherlich passend
>> >
>> >C: Nutzung von XStream einer Bibliothek (250KB) zur
>> > Serialisierung: einfach zu verwenden, aber erzeugte Datenvolumen
>> > =C3=BCbersteigt wesentlich die Standard-Java-Serialisierung (12MB
>> > statt 150KB f=C3=BCr Junit), gestiegene Memory-Anforderungen durch
>> > DOM-Ansatz
>> >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab)
>> >
>> >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und
>> > erneutes Parsen beim Laden, wenig Aufwand aber schlechte
>> > Performanz
>> >
>> >Was denkt Ihr?
>>
>> Also ich denke B + D oder D + B w=C3=A4re Klasse. Ich habe ein bisschen
>> hin und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor:
>>
>> - serialisierte Modellinformationen sind immer dann sinnvoll, wenn
>> jemand Zeit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist. Beis=
piel:
>> jemand untersucht einen Release-Stand oder mit jedem Build wird ein
>> serialisiertes (vorverdautes) Modell erzeugt.
>>
>> - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf
>> dem Source- oder Bytecode.
>>
>> - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern =
und
>> Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen
>> Anforderungen an die Aktualit=C3=A4t konfrontiert.
>>
>> Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung
>> vorstellen:
>>
>> - Eine Modelldatei enth=C3=A4lt nur die Modulpfade - also D. Ich w=C3=
=BCrde
>> dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher
>> mit einer Projektdatei einer IDE vergleichbar.
>>
>> - ein serialisiertes Modell kann genauso als Modul betrachtet
>> werden wie ein Source-/Bytecode - Jar/Verzeichnis. Es handelt sich
>> also nur um eine andere Modulform (und w=C3=BCrde evtl. einen eigenen
>> Loader erfordern) .
>>
>> - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes
>> Modul umzuwandeln.
>>
>> - Source-(Byte-)Code-Modul + serialisiertes Modul +
>> Synchronisierung k=C3=B6nnte ein "cached module" sein.
>>
>> - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise
>> nennen?!?
>>
>> Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung
>> von B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere
>> Gr=C3=BCnde gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch =
nicht so
>> recht in die Betrachtung passen, da meine Annahmen ja davon
>> ausgehen, dass man Zeit und Speicherplatz sparen m=C3=B6chte.
>> Grunds=C3=A4tzlich habe ich nichts gegen textbasierte Formate wenn sie
>> die Anforderung grunds=C3=A4tzlich erf=C3=BCllen. Ein XML-basiertes Form=
at
>> kann einem sicherlich die Implementierung erleichtern, wenn es
>> allerdings dadurch zu geschw=C3=A4tzig wird nutzt uns das auch nichts.
>> Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=A4tzlichen Vorteile =
aus
>> einem XML-Format ziehen. Speziell ein XMI-Modul w=C3=A4re zwar auch sehr
>> attraktiv, w=C3=BCrde uns aber im Rahmen dieser Diskussion nicht weiter
>> bringen.
>>
>> Ok - das reicht erst mal. Was meint ihr dazu?
>>
>> Ahoi
>>
>> Axel
>>
>> >Gru=C3=9F
>> >Michael
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.Net email is sponsored by Yahoo.
>> >Introducing Yahoo! Search Developer Network - Create apps using
>> > Yahoo! Search APIs Find out how you can build Yahoo! directly
>> > into your own Applications - visit
>> > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005
>> > _______________________________________________
>> >Jmove-devel mailing list
>> >Jmo...@li...
>> >https://lists.sourceforge.net/lists/listinfo/jmove-devel
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Yahoo.
>> Introducing Yahoo! Search Developer Network - Create apps using
>> Yahoo! Search APIs Find out how you can build Yahoo! directly into
>> your own Applications - visit
>> http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005
>> _______________________________________________
>> Jmove-devel mailing list
>> Jmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/jmove-devel
>
>
|
|
From: Michael <mj...@we...> - 2005-05-30 18:40:20
|
Hi Axel, grunds=C3=A4tzlich teile ich deine Pr=C3=A4ferenzen f=C3=BCr B und D. Aufgr= und=20 unserer Planungen w=C3=BCrde ich allerdings das aufwand=C3=A4rmere D=20 bevorzugen. Die Idee "Projektdatei" finde ich klasse, denn dadurch=20 wird nichts vorgegaukelt. Mein Vorschlag f=C3=BCr die konkrete Benennung: * load/save module compilation * load/save module set Wir sollten unser Men=C3=BCstruktur daf=C3=BCr weiter standardisieren. Wie = w=C3=A4re=20 es mit=20 Model New Add module ----------------- Load module compilation Save module compilation ----------------- Export XMI ----------------- Quit View Search types //Create diagram //Create report =09 Help Contents About Bzgl. der mittelfristigen Variante B w=C3=BCrde ich in der Tat ein=20 textbasierte Format (gerne XML) verwenden, dann sind Fehler leichter=20 nachvollziehbar und mit entsprechender Komprimierung sollte auch=20 Speicherplatz weniger ein Problem sein. Prinzipiell halte ich XMI f=C3=BCr= =20 zu =C3=BCberfrachtet, unser schmales Kernmodell bietet sicherlich eine=20 effizientere Serialisierungsm=C3=B6glichkeit. Allerdings wenn wir auch=20 Diagramme ablegen wollen... Apropos Diagramme: Es w=C3=A4re super, wenn man Diagramme selbst best=C3=BC= cken=20 k=C3=B6nnte: neues Diagramm anlegen, Packages in das Diagramm ziehen,=20 Abh=C3=A4ngigkeiten werden eingetragen, das Diagramm kann gedruckt=20 werden....megacool! ;-) Gru=C3=9F Michael Am Montag, 30. Mai 2005 11:31 schrieb ax...@sp...: > Hi Michael, > > da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest > etwas Zeit gefunden deine Sachen auszubrobieren. Den Stack-Overflow > habe ich allerdings noch nicht gefunden - nun ist es aber doch > raus... ;-) > > >Hi, > > > >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz > > die die Standard-Java-Serialisierung verwendet. Dabei ist mir > > Folgendes aufgefallen: > > > >* Viel "implements Serializable" > >* Einige Attribute auf "transient" umgestellt > >* StackOverflowError bei Abspeichern des jmove-source-Modells > > > >Strukturell ist mir aufgefallen, dass unsere abgespeicherten > > Modelle nicht transportf=C3=A4hig sind, da assozierte Locations nach > > einem Laden nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und som= it > > Funktionalit=C3=A4t wie Source-Code-Edit nicht funktionieren. > > > >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen: > > > >A. StackOverflow beheben: Schwierig, weil die Stelle nicht > > verraten wird: ist es einfach die Menge oder erkennt der > >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das > >Abspeichern und Laden von Byte-Code-Modellen? > > > >B. Eigene Implementierung der Serialisierung: aufwendig aber > >sicherlich passend > > > >C: Nutzung von XStream einer Bibliothek (250KB) zur > > Serialisierung: einfach zu verwenden, aber erzeugte Datenvolumen > > =C3=BCbersteigt wesentlich die Standard-Java-Serialisierung (12MB > > statt 150KB f=C3=BCr Junit), gestiegene Memory-Anforderungen durch > > DOM-Ansatz > >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) > > > >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und > > erneutes Parsen beim Laden, wenig Aufwand aber schlechte > > Performanz > > > >Was denkt Ihr? > > Also ich denke B + D oder D + B w=C3=A4re Klasse. Ich habe ein bisschen > hin und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor: > > - serialisierte Modellinformationen sind immer dann sinnvoll, wenn > jemand Zeit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist. Beisp= iel: > jemand untersucht einen Release-Stand oder mit jedem Build wird ein > serialisiertes (vorverdautes) Modell erzeugt. > > - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf > dem Source- oder Bytecode. > > - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern u= nd > Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen > Anforderungen an die Aktualit=C3=A4t konfrontiert. > > Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung > vorstellen: > > - Eine Modelldatei enth=C3=A4lt nur die Modulpfade - also D. Ich w=C3=BC= rde > dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher > mit einer Projektdatei einer IDE vergleichbar. > > - ein serialisiertes Modell kann genauso als Modul betrachtet > werden wie ein Source-/Bytecode - Jar/Verzeichnis. Es handelt sich > also nur um eine andere Modulform (und w=C3=BCrde evtl. einen eigenen > Loader erfordern) . > > - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes > Modul umzuwandeln. > > - Source-(Byte-)Code-Modul + serialisiertes Modul + > Synchronisierung k=C3=B6nnte ein "cached module" sein. > > - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise > nennen?!? > > Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung > von B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere > Gr=C3=BCnde gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch n= icht so > recht in die Betrachtung passen, da meine Annahmen ja davon > ausgehen, dass man Zeit und Speicherplatz sparen m=C3=B6chte. > Grunds=C3=A4tzlich habe ich nichts gegen textbasierte Formate wenn sie > die Anforderung grunds=C3=A4tzlich erf=C3=BCllen. Ein XML-basiertes Format > kann einem sicherlich die Implementierung erleichtern, wenn es > allerdings dadurch zu geschw=C3=A4tzig wird nutzt uns das auch nichts. > Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=A4tzlichen Vorteile a= us > einem XML-Format ziehen. Speziell ein XMI-Modul w=C3=A4re zwar auch sehr > attraktiv, w=C3=BCrde uns aber im Rahmen dieser Diskussion nicht weiter > bringen. > > Ok - das reicht erst mal. Was meint ihr dazu? > > Ahoi > > Axel > > >Gru=C3=9F > >Michael > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using > > Yahoo! Search APIs Find out how you can build Yahoo! directly > > into your own Applications - visit > > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005 > > _______________________________________________ > >Jmove-devel mailing list > >Jmo...@li... > >https://lists.sourceforge.net/lists/listinfo/jmove-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using > Yahoo! Search APIs Find out how you can build Yahoo! directly into > your own Applications - visit > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
|
From: <ax...@sp...> - 2005-05-30 09:31:36
|
Hi Michael,=20 da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest etwas Z= eit gefunden deine Sachen auszubrobieren. Den Stack-Overflow habe ich aller= dings noch nicht gefunden - nun ist es aber doch raus... ;-) >Hi, > >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz di= e=20 >die Standard-Java-Serialisierung verwendet. Dabei ist mir Folgendes=20 >aufgefallen: > >* Viel "implements Serializable" >* Einige Attribute auf "transient" umgestellt >* StackOverflowError bei Abspeichern des jmove-source-Modells > >Strukturell ist mir aufgefallen, dass unsere abgespeicherten Modelle=20 >nicht transportf=C3=A4hig sind, da assozierte Locations nach einem Laden= =20 >nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und somit Funktionalit= =C3=A4t=20 >wie Source-Code-Edit nicht funktionieren.=20 > >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen: > >A. StackOverflow beheben: Schwierig, weil die Stelle nicht verraten=20 >wird: ist es einfach die Menge oder erkennt der=20 >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das=20 >Abspeichern und Laden von Byte-Code-Modellen? > >B. Eigene Implementierung der Serialisierung: aufwendig aber=20 >sicherlich passend > >C: Nutzung von XStream einer Bibliothek (250KB) zur Serialisierung:=20 >einfach zu verwenden, aber erzeugte Datenvolumen =C3=BCbersteigt=20 >wesentlich die Standard-Java-Serialisierung (12MB statt 150KB f=C3=BCr=20 >Junit), gestiegene Memory-Anforderungen durch DOM-Ansatz=20 >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) > >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und erneutes=20 >Parsen beim Laden, wenig Aufwand aber schlechte Performanz > >Was denkt Ihr? Also ich denke B + D oder D + B w=C3=A4re Klasse. Ich habe ein bisschen hi= n und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor: - serialisierte Modellinformationen sind immer dann sinnvoll, wenn jemand Z= eit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist. Beispiel: jeman= d untersucht einen Release-Stand oder mit jedem Build wird ein serialisiert= es (vorverdautes) Modell erzeugt. - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf de= m Source- oder Bytecode. - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern und= Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen An= forderungen an die Aktualit=C3=A4t konfrontiert. Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung vorstell= en: - Eine Modelldatei enth=C3=A4lt nur die Modulpfade - also D. Ich w=C3=BCrd= e dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher mit e= iner Projektdatei einer IDE vergleichbar. - ein serialisiertes Modell kann genauso als Modul betrachtet werden wie ei= n Source-/Bytecode - Jar/Verzeichnis. Es handelt sich also nur um eine ande= re Modulform (und w=C3=BCrde evtl. einen eigenen Loader erfordern) .=20 - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes Modul u= mzuwandeln. - Source-(Byte-)Code-Modul + serialisiertes Modul + Synchronisierung k=C3= =B6nnte ein "cached module" sein. - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise nennen?!?= =20 Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung von= B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere Gr=C3=BCnd= e gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch nicht so rech= t in die Betrachtung passen, da meine Annahmen ja davon ausgehen, dass man = Zeit und Speicherplatz sparen m=C3=B6chte. Grunds=C3=A4tzlich habe ich nich= ts gegen textbasierte Formate wenn sie die Anforderung grunds=C3=A4tzlich e= rf=C3=BCllen. Ein XML-basiertes Format kann einem sicherlich die Implementi= erung erleichtern, wenn es allerdings dadurch zu geschw=C3=A4tzig wird nutz= t uns das auch nichts. Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3= =A4tzlichen Vorteile aus einem XML-Format ziehen. Speziell ein XMI-Modul w= =C3=A4re zwar auch sehr attraktiv, w=C3=BCrde uns aber im Rahmen dieser Dis= kussion nicht weiter bringen.=20 Ok - das reicht erst mal. Was meint ihr dazu? Ahoi Axel > > >Gru=C3=9F >Michael > > > >------------------------------------------------------- >This SF.Net email is sponsored by Yahoo. >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >Search APIs Find out how you can build Yahoo! directly into your own >Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q220= 05 >_______________________________________________ >Jmove-devel mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmove-devel > |
|
From: Michael <mj...@we...> - 2005-05-29 15:41:03
|
Hi, f=FCr das Speichern und Laden von Modellen habe ich im ersten Ansatz die=20 die Standard-Java-Serialisierung verwendet. Dabei ist mir Folgendes=20 aufgefallen: * Viel "implements Serializable" * Einige Attribute auf "transient" umgestellt * StackOverflowError bei Abspeichern des jmove-source-Modells Strukturell ist mir aufgefallen, dass unsere abgespeicherten Modelle=20 nicht transportf=E4hig sind, da assozierte Locations nach einem Laden=20 nicht an der gleichen Stelle liegen m=FC=DFen und somit Funktionalit=E4t=20 wie Source-Code-Edit nicht funktionieren.=20 Im Prinzip sehe ich 4 M=F6glichkeiten den Problemen zu begegnen: A. StackOverflow beheben: Schwierig, weil die Stelle nicht verraten=20 wird: ist es einfach die Menge oder erkennt der=20 Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das=20 Abspeichern und Laden von Byte-Code-Modellen? B. Eigene Implementierung der Serialisierung: aufwendig aber=20 sicherlich passend C: Nutzung von XStream einer Bibliothek (250KB) zur Serialisierung:=20 einfach zu verwenden, aber erzeugte Datenvolumen =FCbersteigt=20 wesentlich die Standard-Java-Serialisierung (12MB statt 150KB f=FCr=20 Junit), gestiegene Memory-Anforderungen durch DOM-Ansatz=20 (Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) D: Pseudo-Serialisierung: Serialisierung der Modulpfade und erneutes=20 Parsen beim Laden, wenig Aufwand aber schlechte Performanz Was denkt Ihr? Gru=DF Michael |
