Hi David & co,
I had a little luck last night and figured out what was going wrong, but would appreciate to know if this is expected behavior....
A little background... With Eclipse 3.4, MTJ 0.9 & Floggy we had a number of reports of infinite build loops when build automatically was enabled. To get around this we put in a check to only do byte code weaving if a change was detected in a source folder.
What I'm now seeing is that just before a midlet is launched a build is initiated... The Java builder compile the code, but since the build delta doesn't contain a source code change floggy's builder doesn't do anything. The preverification builder and package builder then pickup the new class file (that doesn't contain the floggy woven code) and launches... end result is that the class doesn't contain the additional bytecode needed to work.
To test this I removed the condition in the floggy builder and hey-presto it all worked. I didn't get an infinite build loop, however it didn't always happen in the past, so am a little concerned about leaving this out. I could change the conditional build, say to only build if a change to the output is detected but am thinking that things other than class files may be here also... I guess I could change to build only if a class file changes in the bin directory, since the preverfication builder outputs to the .mtj temp directory I should be safe from java->floggy->preverify->floggy loops (?)
So, a couple of Qs...
1) I'm assuming this extra build before launching is intended... is this right ?
2) Is there something about the build I could detect, or hints on how to know if I need to re-build ?
3) Any other advice :)
Thanks in advance,
2009/10/29 Dan Murphy <dgemurphy@xxxxxxxxx>
Hi David, thanks for the info. I'll have another try with the build.properties. When I tried manually changing this file it didn't seem to work. However that was with the 1.0 release so things may have changed since then.
All the best,
----- Sent on the hoof from my phone ! -----
The last builder for an MTJ project is the PackageBuilder. This builder is responsible to filter the content on the bin/ directory and package only the files/folders that match any 'include' entry within the build.properties. As soon as the generated classes are copied into the bin/ folder before the package builder is run and an entry like net/sourceforge/floggy/ is in the include part of the build.properties it should work :)
David MarquesMobile Software Platforms
=============================================================Eclipse Mobile Industry Working Group - http://www.eclipse.org/pulsar/
Eclipse Mobile Tools for the Java Platform - http://www.eclipse.org/dsdp/mtj/
From: Dan Murphy
To: Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>
Sent: Thu, October 29, 2009 5:22:57 AM
Subject: Re: [dsdp-mtj-dev] PackageBuilder ignoring generated classes
The reason I went for the jar approach was that creating stubs seemed likey to result in the stubs being stored in the users scm system, which I thought was best avoided.
With the latest trunk, the weaver customised impl classes are being jar'd and copied. The problem is that the weaver persistable classes are not being copied from the floggy temp directory back into the project bin directory... Either that or the bin directory needs a refresh.. Whatever the cause, the woven data classes are not apppearing in the jar used by the emulator.
I'll continue to have a look over lunch today
----- Sent on the hoof from my phone ! -----
I would like bring this thread back to live: http://dev.eclipse.org/mhonarc/lists/dsdp-mtj-dev/msg01298.html. We still didn't fix it so I'm here to ask more questions.
David, how can I build stubs like you said in your last comment? I made a search and found the below reference of stubs and pde, it is related to what you meant ? http://www.techq.com/source/java/Eclipse-PDE/3.4.2/org/eclipse/pde/api/tools/internal/provisional/stubs/Converter.html
Let me explain a little more how Floggy works, so maybe you guys can give us a better feedback
1º compiler finish its process
2º Floggy weaver start to analyze the bytecodes
3º Floggy weaver will for each class that implements Persistable add methods and fields in the class.
4º Floggy weaver will drop off predefined classes into bin folder to the package net.sourceforge.floggy.persistence.impl. These classes doesn't have a java file pair.
Until the third step everything works fine since we have a correlated .java file for each .class file.
The problem is MTJ does not embedded the classes from the fourth step!
Any help is appreciated. Thanks in advance.