You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(6) |
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Tobias G. <gut...@fz...> - 2004-05-11 08:54:51
|
Hi everyone! I cleaned up the folder "NewTestSuite". I renamed every script file so that they start with a capital letter, so now there's consistent naming. If you can't do a CVS-update, just delete your NewTestSuite and download it completely again. Note that since the folder "source" is now "src", the j2ee.jar has to be downloaded again. Cheers, Tobias |
From: Thomas G. <Tho...@fz...> - 2004-03-19 17:30:01
|
Hi all, I just checked in my changes which included some additions to our testsuite. Unfortunately, in order to be compilable, one of the test projects needs j2ee.jar which is a rather big blob (6MB). So be prepared: it takes a while to download. I will try to come up with a more or less representative testsuite next week (by adding some of the larger case studies of my phd). From then on, policy is that only code that passes the testsuite shall be committed to cvs. Have a nice weekend, Thomas -- ----------------------------------------- Thomas Genssler (Tho...@fz...) Tel./Fax: +49-721-9654-602/-603 Forschungszentrum Informatik - Research Center for Information Technologies Programmstrukturen - Program Structures (http://www.fzi.de/prost) Haid-und-Neu-Strasse 10-14 76131 Karlsruhe GERMANY |
From: Thomas G. <Tho...@fz...> - 2004-02-17 14:29:18
|
Hi, thanks for using Inject/J. You should, however, consider switching to the CVS version (Version 0.5) as both 0.4.2 and 0.4.3 are no longer supported. Version 0.5 can be fetched via anonymous CVS from cvs.sourceforge.net:/cvsroot/injectj (connection type: pserver). InjectJ 0.5 comes with a lot of bugfixes, improvements (mostly analysis and transformation functionality) and a new (more intuitive) scripting language (there are tons of examples in the CVS and a prelimenary language spec at http://prdownloads.sourceforge.net/injectj/injectj-tutorial-1.0.pdf?download) Once downloaded, you can build Inject/J using the included ANT buildfile (the easiest way is probably to load the code as Ecplipse project and build it from there). Anyway, your specific problem sounds like a wrong parameter to the VM (you are probably using a different VM): Try java -Xmx128M -jar <jar file> instead of java -Xmx128MB -jar <jar file> Regards, Thomas Helen wrote: > hi, > > I tried both 0.4.3 and 0.4.2. > > For 0.4.3, I don't know why after I made configuration file as tutorial, > when I pushed the finish button, i saw "type utility dependency..." > error. Anyone could clarify what to do? > > For 0.4.2, I can install successfully, but when I ran startInjectJ.jar, > some error msg like "VM initialiation error:-Xmx128MB.......". Do I need > to set Java VM? > > > > Hope anyone familiar with this could give me a hand. > > Thank you very much. > > Regards. > Helen.H. > > > ____________________________________________________ > <http://www.incredimail.com/redir.asp?ad_id=309&lang=9> /IncrediMail/ - > *Email has finally evolved* - *_Click Here_* > <http://www.incredimail.com/redir.asp?ad_id=309&lang=9> |
From: Thomas G. <Tho...@fz...> - 2003-10-09 15:57:58
|
This is to announce the release of the Inject/J Eclipse Editor plugin. The Plugin can be downloaded from https://sourceforge.net/projects/injectj/. See release notes for hints how to install the plugin. The plugin should work with Eclipse 2.1. The plugin supports syntax highlighting and code completion according to the new language syntax. Both features can be customized via the config.xml file in the plugin directory - usually something like ECLIPSE_ROOT\plugins\de.fzi.injectj.frontend.eclipse.InjectJEditor_1.0.5 (or any other directory you choose in Eclipse\Window\Preferences\InjectJ Editor). The file is rather self explaining. Regards, Thomas -- Thomas Genssler (Tho...@fz...) Tel./Fax: +49-721-9654-602/-603 Forschungszentrum Informatik - Research Center for Information Technologies Programmstrukturen - Program Structures (http://www.fzi.de/prost) Haid-und-Neu-Strasse 10-14 76131 Karlsruhe GERMANY |
From: Sven L. <Sve...@we...> - 2003-08-04 11:49:43
|
Hello, i will change the injectj code to more java conform code. Therefore I'll change the simple injectj self-made logging mechanism to the java.util.logging mechanism. Furthermore I'll use the java.util.prefs API for the global settings. But this change adds a restriction to the Global Settings. Currently it is possible to use several, different files for the Global Settings. After the change it's only possible to use the global settings from one source, the registry. Does anybody use several files for the global settings? Did you agree this changes? Regards Sven |
From: Tobias G. <gut...@fz...> - 2003-08-01 14:20:23
|
Hi! While making ask() a global function rather than a statement, I observed what strange usage ask() used to have: It required 2 or 3 parameters. Param 1: A string, the question ask (so far so well) usage no 1: Param 2: A VariableDeclaration. Depending on it's type, the user would be ask for "true/false", an integer value, and so on. The variable's content would then be overwritten. usage no 2: Param 2: A list to choose from. Param 3: A string (!) which contains the name of a variable that is used as the default return value. The chosen return value would then be stored in this variable's content. e.g.: a = classes; b = a.getElement(0); ask("What class do you want to delete?", a, "b"); // the return value is now stored in b. My suggestions: - Do not store the return value in the 2nd (or 3rd) parameter; rather have ask() return the result; - as second parameter, pass either an integer value defining the type to ask for, or a list to choose an element from - as an optional third parameter, pass the element selected by default if second element is a list If there are no objections/improvements, I'll implement it this way. Have a nice weekend everyone! Tobias |
From: Sven L. <Sve...@we...> - 2003-05-09 01:54:31
|
Hallo zusammen, =20 so es ist also soweit. Die Release Entwicklung ist fertig und alle Release Schritte werden automatisch durchgef=FChrt. Somit ist es nun m=F6glich eine InjectJ Release innerhalb von 20 Minuten durchzuf=FChren. = Im Rahmen der Release Erstellung musste ich noch viele Fehler ausbauen. Durch die teilweise recht gro=DFen =C4nderungen haben sich im Laufe der = Zeit viele Fehler eingeschlichen und diese fielen erst bei der Release Erstellung auf. Dies f=FChrte dazu, dass es derma=DFen lange gedauert = hat. Von den drei Referenzbeispielen konnte lediglich eines auf anhieb ausgef=FChrt werden. Besonders hartn=E4ckig war das Observerbeispiel. = Hier war mittlerweile jede zwei Zeile fehlerbehaftet. Die Beispiele laufen nun komplett durch obwohl noch einige Warnungen ausgegeben werden.=20 =20 Besonders viele Fehler haben wir uns durch die Property Umstellung eingefangen. Die Beispiele nutzten viele Properties die nicht mehr oder noch nicht existierten. Teilweise reagierten die Properties mittlerweile auch anders. Ebenfalls recht beliebt war es bei dem Aufruf der Properties Methoden keine R=FCckgabewerte zur=FCckzugeben. Die Methoden wurde einfach als void Methoden implementiert aber h=E4tten eigentlich = als Methoden mit R=FCckgabewert implementiert werden m=FCssen. Ich denke in Zukunft ist dies weiterhin eine m=F6gliche Fehlerquelle da ich sicher = noch nicht alle Fehlerquellen gefunden habe.=20 =20 Im Source Code ist mir aufgefallen, dass einige Stellen mit = =84//@Removed=93 gekennzeichnet wurden. Dies ist auf jeden Fall hilfreich bei der Fehlersuche da man wei=DF dass der Quellcode bewusst entfernt wurde. = Noch besser w=E4re jedoch eine kurze Beschreibung hinzuzuf=FCgen warum und = von wem der Code auskommentiert wurde. Ich w=FCrde mich freuen wenn wir in Zukunft uns diese M=FChe machen. =20 Die Versionsnummer wird f=FCr die Zukunft dreistellig und nur numerisch verwaltet. (major.minor.revision) Es war notwendig sich auf einen ausreichend niedrigen Level zu einigen damit die Versionsnummer = =FCberall (Console, Wizard, Plugin, Installer) gleich gepflegt werden kann. Die Quelle f=FCr die Versionsnummer ist die Datei version.properties. Diese wird beim Erzeugen automatisch aktualisiert. Dar=FCber hinaus wird die Versionsnummer automatisch in die Datei Plugin.xml und in den Generator f=FCr die Installationsdateien =FCbertragen. Wichtig ist hierbei, dass = die Versionsnummer nicht manuell ver=E4ndert werden darf! Weder in der Plugin.xml noch in dem Installer File! =20 Ich habe mich dar=FCber gefreut, dass die Kommentare beim Committen = aktiv benutzt werden. Ich bitte Euch dies weiterhin zu tun, da ich aus diesen Eintr=E4gen in naher Zukunft ein ChangeLog File erzeugen und warten = werde. Dies ist die einfachste M=F6glichkeit die Ver=E4nderungen im Quellcode nachzuvollziehen.=20 =20 Eine sicher sinnvolle Erweiterung w=E4re eine Debug M=F6glichkeit f=FCr = die InjectJ Skripte. Teilweise ist es recht schwierig die genauen Fehlerpositionen zu erkennen. Was meint ihr? Eine ganz einfache Implementierung k=F6nnte doch immer die n=E4chste Skriptzeile ausgeben = und dann auf eine Tastaturbest=E4tigung warten. Dies w=FCrde das Debuggen erheblich verbessern. =20 Dar=FCber hinaus gibt es jetzt zwei Verzeichnisse f=FCr Beispiele. Zum = Einen das Verzeichnis examples und zum Anderen das Verzeichnis TestSuite. Der Unterschied bei den Verzeichnissen liegt darin, dass die TestSuite nicht ausgeliefert wird. Das Verzeichnis examples ist dagegen Bestandteil der Auslieferung. Ich bitte um entsprechende Vorsicht bei =C4nderungen in diesem Verzeichnis! =20 Die Auslieferung besteht aus verschiedenen Dateien. Dies habe ich gemacht damit ungewollte Abh=E4ngigkeiten aufgesp=FCrt werden konnte. = Und wie h=E4tte es anderes sein k=F6nnen: Es gab wirklich noch = ungew=FCnschte Abh=E4ngigkeiten zwischen den entsprechenden Dateien. Im Detail gibt es jetzt folgende Dateien: - injectj-console.jar (Nur die Konsolendateien) - injectj-wizard.jar (Nur die Assistenzdateien) - injectj-eclipse-plugin.jar (Nur die Eclipse Front end Dateien) - injectj-backend.jar (Nur die allgemeinen Backendend Dateien) - injectj-backend-recoder.jar (Nur die recoder spezifischen Backend Dateien) =20 Die Dateien injectj-console.jar und injectj-wizard.jar sind direkt ausf=FChrbar. Hierzu kann der Aufruf java =96jar injectj-console.jar = oder java =96jar injectj-wizard.jar genutzt werden. Die entsprechenden Abh=E4ngigkeiten zwischen den Dateien sind in dem sogenannten Manifest File definiert. Somit ist es nicht notwendig den Classpath entsprechend anzugeben. Dar=FCber hinaus sind alle jar Files mit einem entsprechend generierten Schl=FCssel signiert worden damit diese Dateien auch f=FCr = den Webstart benutzt werden k=F6nnen.=20 =20 So ich hoffe jetzt nichts vergessen zu haben und w=FCnsche Euch noch ein sch=F6nes Wochenende.=20 =20 Bis dann =20 Sven Luzar Wasserstra=DFe 23 48565 Steinfurt =20 Tel: +49 (2551) 862250 Fax: +49 (89) 2443 68746 Email: Sve...@we... =20 |
From: Tobias G. <gut...@fz...> - 2003-04-30 12:44:05
|
Hi all! As planned, named model elements should implement the interface NamedModelElement, which declares the two methods getName() and getShortName(). However, in Recoder, the interface ProgramModelElement declares the two methods getName() and getFullName(), where getName() would be our getShortName(), and getFullName() our getName(). I think it might become a little confusing looking at some source code like this: public String getName() { return myElement.getFullName(); } public String getShortName() { return myElement.getName(); } What do you think about following the naming of recoder? bye Tobias |
From: Sven L. <Sve...@we...> - 2003-04-11 16:15:37
|
Hello InjectJ Devels, =20 please Note: =20 The recoder transformation class supports static and not static methods for attachments, detachments and replacements at the java syntax tree. The static methods have got no prefix. The non static methods have got the prefix =93do=94. =20 But the static methods are only for the internal use at the recoder, so that we must use the methods with the prefix =93do*=94. That=92s very important! Some of the static methods are running fine but some other aren=92t running fine and you can=92t find the error easily because the error messages are very misleading. =20 Mit freundlichem Gru=DF =20 Sven Luzar Wasserstra=DFe 23 48565 Steinfurt =20 Tel: +49 (2551) 862250 Fax: +49 (89) 2443 68746 Email: Sve...@we... =20 |
From: Sven L. <Sve...@we...> - 2003-04-11 09:44:47
|
Hello Inject/J Fans, =20 I have created a new Branch without the changes from April 9th. I think these changes were the first changes at the script parser. The Branch has the name =93v0_4_3_RC1=94. =20 If you would make changed at this Branch you can use the great features from Eclipse. At the project tree node you can use the right mouse button and than you must go to the submenu =93Replace with->Branch or Version=85=94. Now you can select the desired branch.=20 =20 Attention:=20 If you call a commit, after the previous actions, you will commit the changes to the Branch. I you will develop at the main CVS Tree you must call =93Replace with -> Latest From Repository=94 previously. =20 Mit freundlichem Gru=DF =20 Sven Luzar Wasserstra=DFe 23 48565 Steinfurt =20 Tel: +49 (2551) 862250 Fax: +49 (89) 2443 68746 Email: Sve...@we... =20 |
From: Thomas G. <Tho...@fz...> - 2003-03-27 08:37:06
|
Hi *, hmm, I don't know. Dead code analysis is either very conservative (i.e., the statically observable control flow is analysed and some very rough estimations are made) or very costly (in case you use abstract interpretation; it basically boils down to points-to analysis which is undecidable in general and can thus only yield approximations). Thus i don't really see what we would gain here. We either end up having the same functionality as the java compiler (in fact we already have this kind of stuff: "before exit" requires a control flow analysis as well as the check whether a fragment (the parameter to before/after operations) is valid, i.e., does not produce dead code). Or we need to integrate a sophisticated points-to analysis (in fact we have this analysis readily available: Holger Bär has built it for his PhD) which runs in the order of hours to produce decent results for a small-to-medium sized system. A general-purpose trafo does not really make sense for my point of view (see the aforementioned problems). We could however add a heuristic function to the, say, methods and classes like "boolean containsDeadCodeBlocks(...)" or even "markDeadCodeBlocks" to put comments around code which is proven to be "dead". Question is what the advantages are (or: do the advantages outweigh the disadvantages?) The disadvantages I see: - we need to be able to analyse dead code not only on the basis of static control flow (scf) approximations (i.e., the way of the java compiler). If we would only do scf analysis we either end up with no "hits" (given our pre-requisite -- the Java code is compilable before transformation -- still holds). Or (again with scf analysis) we drop this pre-requisite (i.e., if there is statically observable dead code in the program, it would never have made it through the compiler thus it is not correct) which I personally do not like either. - Analysing the "dynamic" control flow is *very* costly. We would need to restrict ourselves to heuristics which are easy (and fast) to compute and still accurate enough to be of any use. If the belowmentioned tool can do this -- fine! If not I'd say let's drop this by now. Cheers, Thomas P.S.: Don't drink to many B52's :-) Sven Luzar wrote: > Hello together, > > > > the following webside presents an analyse Tool to detect dead code an so on. > > > > http://pmd.sourceforge.net/ > > > > I think it’s a nice addition for Inject/J to use a tool like this. > > We can use it for our own code and / or we can > > support this information by Inject/J. > > My idea is a transformation like this: > > > > “Detect all dead code lines and add a comment for this lines.” or > > “Detect all dead code lines and remove this lines.” > > > > What do you think about it? > > > > Mit freundlichem Gruß > > > > Sven Luzar > > Wasserstraße 23 > > 48565 Steinfurt > > > > Tel: +49 (2551) 862250 > > Fax: +49 (89) 2443 68746 > > Email: Sve...@we... > > > -- Thomas Genssler (Tho...@fz...) Tel./Fax: +49-721-9654-602/-603 Forschungszentrum Informatik - Research Center for Information Technologies Programmstrukturen - Program Structures (http://www.fzi.de/prost) Haid-und-Neu-Strasse 10-14 76131 Karlsruhe GERMANY |
From: Sven L. <Sve...@we...> - 2003-03-23 11:51:06
|
Hello together, =20 the following webside presents an analyse Tool to detect dead code an so on. =20 http://pmd.sourceforge.net/ =20 I think it=92s a nice addition for Inject/J to use a tool like this.=20 We can use it for our own code and / or we can=20 support this information by Inject/J. My idea is a transformation like this: =20 =93Detect all dead code lines and add a comment for this lines.=94 or =93Detect all dead code lines and remove this lines.=94 =20 What do you think about it? =20 Mit freundlichem Gru=DF =20 Sven Luzar Wasserstra=DFe 23 48565 Steinfurt =20 Tel: +49 (2551) 862250 Fax: +49 (89) 2443 68746 Email: Sve...@we... =20 |
From: Tobias G. <Tob...@gm...> - 2003-02-14 00:07:17
|
Sven Luzar wrote: > Hello, > > http://jfcunit.sourceforge.net/ > > here you can get a JUnit test frame work for Swing and Eclipse Guis. > > I think it’s a nice Extension to create tests for the front end packages. > > Bis dann > > Sven Luzar > > Schneidemühler Straße 16a > > 76139 Karlsruhe > > Tel: +49 (721) 3549823 > > Fax: +49 (89) 2443 68746 > > Email: Sve...@we... > > Homepage: http://Sven.Luzar.home.pages.de > <http://sven.luzar.home.pages.de/> > Ok, sounds to be a job for me... I'll let you know when I implemented it! Have a nice weekend.... Tobias |
From: Sven L. <Sve...@we...> - 2003-02-14 00:03:47
|
Hello, =20 http://jfcunit.sourceforge.net/ =20 here you can get a JUnit test frame work for Swing and Eclipse Guis. I think it=92s a nice Extension to create tests for the front end packages. =20 Bis dann =20 Sven Luzar Schneidem=FChler Stra=DFe 16a 76139 Karlsruhe =20 Tel: +49 (721) 3549823 Fax: +49 (89) 2443 68746 Email: Sve...@we... Homepage: http://Sven.Luzar.home.pages.de <http://sven.luzar.home.pages.de/>=20 =20 |
From: Sven L. <Lu...@fz...> - 2003-02-13 11:20:44
|
Hello, =20 I have created a schedule of responsibilities. =20 <http://injectj.sourceforge.net/phpwiki/index.php/WhoDoesWhat> http://injectj.sourceforge.net/phpwiki/index.php/WhoDoesWhat =20 Feel free to edit the page.=20 I would be wonderful if you catch one of the open Jobs for you: =20 =20 Bis dann =20 Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe =20 EMail: <mailto:lu...@fz...> lu...@fz... Homepage: <http://www.fzi.de/> http://www.fzi.de =20 |
From: Sven L. <Lu...@fz...> - 2003-02-10 11:20:28
|
Hello,=20 =20 It's not really great to add the junit jar file from Elipse.=20 If someone has another Elipse or junit version=20 the compilation process will not run. =20 Therefore I have added the junit jar file=20 to the lib path at the injectj project root. =20 Bis dann =20 Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe =20 EMail: <mailto:lu...@fz...> lu...@fz... Homepage: <http://www.fzi.de/> http://www.fzi.de =20 |
From: Sven L. <Lu...@fz...> - 2003-02-04 18:29:50
|
Hello,=20 The Inject J swing front end shows sometimes the following error.=20 It's a current error at the swing implementation of the Virtual Machine. = For more Information see t <http://developer.java.sun.com/developer/bugParade/bugs/4759963.html> he = bug description: http://developer.java.sun.com/developer/bugParade/bugs/4759963.html=20 java.lang.NullPointerException at javax.swing.LayoutComparator.compare(LayoutComparator.java:61) at java.util.Arrays.mergeSort(Arrays.java:1237) at java.util.Arrays.sort(Arrays.java:1185) at java.util.Collections.sort(Collections.java:151) at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocu= sTr aversalPolicy.java:117) at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTra= ver salPolicy.java:331) at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTrave= rsa lPolicy.java:143) at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusT= rav ersalPolicy.java:391) at java.awt.FocusTraversalPolicy.getInitialComponent(FocusTraversalPolicy.ja= va: 131) at java.awt.Window.getMostRecentFocusOwner(Window.java:1251) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusMa= nag er.java:268) at java.awt.Component.dispatchEventImpl(Component.java:3468) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Window.dispatchEventImpl(Window.java:1585) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.SequencedEvent.dispatch(SequencedEvent.java:91) at java.awt.EventQueue.dispatchEvent(EventQueue.java:448) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread= .ja va:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.j= ava :150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at = java.awt.EventDispatchThread.run(EventDispatchThread.java:99) =20 =20 Bis dann =20 Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe =20 EMail: <mailto:lu...@fz...> lu...@fz... Homepage: <http://www.fzi.de/> http://www.fzi.de =20 |
From: Sven L. <Lu...@fz...> - 2003-02-03 16:11:19
|
Hello, =20 the recoder version 0.72 has integrated successfully. =20 The recoder.jar file contains the current binary file and the recoder.zip contains the current source files so that you can also debug into the recoder sources. =20 At the future we can directly use the new recoder versions without any own changes. =20 Bis dann =20 Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe =20 EMail: <mailto:lu...@fz...> lu...@fz... Homepage: <http://www.fzi.de/> http://www.fzi.de =20 |
From: Sven L. <Lu...@fz...> - 2002-12-12 18:52:40
|
Hello Developers, We have reorganized the package Names: de.fzi.injectj.model.* -> contains everything concerning the real Inject = J model de.fzi.injectj.script.* ->contains everything concerning the Inject J = script (model, parser, *) Bis dann Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe EMail: lu...@fz... Homepage: http://www.fzi.de |
From: Sven L. <Sve...@we...> - 2002-12-08 13:13:51
|
Hello, If the Mop provider wasn't found a default initialisation was used now. The information messages on the console are: Starting Inject/J v0.4.3-alpha (build 3)... Can't use class fzi.injectj.access.recoder.RecoderAccess as Meta Object Protocol Provider!=20 Try to get Recoder as default Meta Object Protocol Provider! ... with success! Bis dann Sven Luzar Schneidem=FChler Stra=DFe 16a 76139 Karlsruhe Tel: +49 (721) 3549823 Fax: +49 (89) 2443 68746 Email: Sve...@we... Homepage: http://Sven.Luzar.home.pages.de |
From: Sven L. <Lu...@fz...> - 2002-11-20 12:48:47
|
Hello, the Bugs 638356 forward button, directly finish=20 638359 Update the java source parse progress frame 638358 Savable Log Files=20 638357 OK button press able =20 are removed. Bis dann Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe EMail: lu...@fz... Homepage: http://www.fzi.de |
From: Sven L. <Lu...@fz...> - 2002-11-19 17:02:01
|
Hello, Now the Kernel supports a new type of version control. The File fzi/backend/version.properties contains the following = properties: #Tue Nov 19 16:44:11 GMT+01:00 2002 version.date=3D2002/11/19 16\:44 version.build=3D1.003 version.number=3Dv0.4.3 alpha The static variable VERSION in the Kernel contains the version.number = and version.build from the file. The Properties version.date and version.build will change automatically = by using ant with the build file build.xml. You can use ant file with the parameter javac or javadoc. Javac creates a new build number, a new = build date, copies the resources and compiles the java files. The Javadoc parameter reads the version file and creates a new Documentation.=20 Bis dann Sven Luzar Stiftung Forschungszentrum f=FCr Informatik Haid und Neu Stra=DFe 10-14 76131 Karlsruhe EMail: lu...@fz... Homepage: http://www.fzi.de |
From: Thomas G. <Tho...@fz...> - 2002-09-11 11:09:15
|
Hi, the history: webinjectj is a web-based frontend for inject/j. It was the result of a diploma thesis on how to 'web-ify' existing applications. We intended to use it as a part of the online tutorial. However, it never reached the required level of stability (which was primarily not due to the student not being bright enough but due to the fact that recoder was not re-entrant - a killer argument for a web application). I would suggest to move this stuff to a sub-project (if possible) to prevent these annoying compilation problems. -- TG Tobias Gutzmann wrote: > Hi! > > I wonder if we could remove fzi.webinjectj.* from the project for now. > It doesn't compile anymore anyway because of the changes within the > backend/frontend structure. e.g., it relies on fzi.injectj.config. > Probably nobody noticed as online a rebuild-all causes these packages to > be recompiled. > > Tobias > > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > Injectj-devel mailing list > Inj...@li... > https://lists.sourceforge.net/lists/listinfo/injectj-devel -- Contact information: Thomas Genssler (gen...@fz..., http://www.fzi.de/genssler.html) FZI Research Center for Information Technologies Tel./Fax: +49-721-9654-602/-603 Inject/J: http://injectj.fzi.de |
From: Tobias G. <Tob...@gm...> - 2002-09-11 11:02:16
|
Hi! I wonder if we could remove fzi.webinjectj.* from the project for now. It doesn't compile anymore anyway because of the changes within the backend/frontend structure. e.g., it relies on fzi.injectj.config. Probably nobody noticed as online a rebuild-all causes these packages to be recompiled. Tobias |
From: Sven L. <Sve...@we...> - 2002-09-02 17:14:13
|
Hello, a new java conform multi language support has committed.=20 The logic is the same like the logic in the PropertyResourceBundle.=20 The java locale class has used for the localisation. For an easy usage you can use the class code mapper. ------------------------------------------------------------------------ --- The following files have deleted: fzi.injectj.language.Deutsch fzi.injectj.language.ErrorCode fzi.injectj.language.LabelCode fzi.injectj.language.English ------------------------------------------------------------------------ --- The following files have added: fzi.injectj.language.injectj.properties (en support) fzi.injectj.language.injectj_de.properties (de support) fzi.injectj.language.LocaleChangeListener fzi.injectj.language.LocaleChangeEvent ------------------------------------------------------------------------ --- The following paths have moved: fzi.injectj.doc.Deutsch -> fzi.injectj.doc.de fzi.injectj.doc.English -> fzi.injectj.doc.en ------------------------------------------------------------------------ --- If you want to support another language, create only a new text file like this=A0: fzi.injectj.language.injectj_{ language code}_{ country code }.properties=20 The country code is optional. Now an example for France: fzi.injectj.language.injectj_fr.properties=20 ------------------------------------------------------------------------ --- To create a new Help support use the language code at the end of the path: An example for france: fzi.injectj.doc.fr ------------------------------------------------------------------------ --- Bis dann Sven Luzar Schneidem=FChler Stra=DFe 16a 76139 Karlsruhe Tel: +49 (721) 3549823 Fax: +49 (89) 2443 68746 Email: Sve...@we... Homepage: http://Sven.Luzar.home.pages.de |