Hi Thomas, On Apr 16, 2012 7:16 PM, "Thomas Calmant" <[email protected]> wrote: > > Hi, > > I'm not a Felix developer, but I'm also working on an integration of > iPOJO in Eclipse. > It seems that you manipulate the whole build directory each time, > while you could bypass the problem by manipulating only re-compiled > (fresh) class files, using a JDT compilation participant. > I'm using ipojo-ant task indeed. Not everything is under my control unfortunately.
> If you want to see the code, the project git repository is here : > http://gitorious.ow2.org/ow2-chameleon/eclipse-ipojo-builder > The project is under Apache Sofware License v2. > Ohh! I was planning to write a ipojo-builder, didn't see it before. It is absolutely what I need. Bug still must be fixed though. Jdt extension is way better than attaching ant builder. > Let me know if you would like some support to work that way. Yeah sure. I'll give it a look. I'll ping you for when further support is needed. Thanks, Göktürk > > Regards, > Thomas. > > Le 16 avril 2012 17:42, Göktürk Gezer <[email protected]> a écrit : > > Hi Devs, > > > > Sorry for pressuring but this is blocker for us in ApacheDS. Could some one > > please evaluate the issue and the patch? We really need to know whether > > it'll be fixed or not? > > > > Thanks, > > Gokturk > > > > On Sun, Apr 15, 2012 at 1:11 AM, Göktürk Gezer <[email protected]> wrote: > > > >> Hi Everyone, > >> > >> As i was trying to integrate IPojo manipulation into eclipse environment, > >> i noticed re-manipulation without cleaning corrupts the MANIFEST file even > >> though it does not brake manipulated class files. Re-manipulated MANIFEST > >> is lacking some handler declarations and "manipulation" section contains > >> entries for fields and methods those are IPojo generated ones, which brakes > >> down everything. > >> > >> I created a jira: https://issues.apache.org/jira/browse/FELIX-3461with a > >> patch to fix. > >> > >> I will document the fix here briefly, so that you guys can tell me if > >> anything brakes some part of code that i don't know. > >> > >> * First problem is ManipulatedMetadataFilter class which is simply > >> ignoring elements if some of their attributes contain manipulation headers. > >> This behavior ends up in ignoring elements whose values are dependent on > >> methods like transition callbacks(Validate-Invalidate), since the > >> re-manipulation process will read methods with their mangled names. And > >> filter was also missing some manipulation headers too, causing manipulation > >> section to contain extra entries. I removed the filter logic from code and > >> injected a ManipulationMetadataFixer which is called before any > >> manipulation medata <Element> is rendered. It fixes the mangled method > >> names and performs a structered clean-up on manipulation elements. > >> > >> * After using Fixer there were two main problems left: > >> -> Bind/Unbind/Modified metadatas were being lost and @Property on methods > >> were lacking property names after re-manipulation :: Solved by adding > >> necessary checks into BindAnnotationsParser and PropertyAnnotationParser > >> classes's visitEnd() methods. > >> -> Constructor injection parameters were being assigned wrong class types > >> after re-manipulation :: While generating new constructor based on existing > >> one argument annotations were being transferred to new one without changing > >> their index. While this is valid action, it falsify the fetched type of > >> injection annotations at re-manipulation. At ClassChecker i added an > >> exception for @Property and @Requires annotation types to remain attached > >> to original constructor, also overrided visitParameterAnnotation() method > >> in ConstructorCodeAdaptor class to forbid those two annotation to go into > >> generated constructor. > >> > >> > >> Tested those changes against an IPojo component containing all current > >> ipojo annotations + custom annotations to produce same MANIFEST after > >> multiple manipulation attempts. > >> > >> > >> Regards, > >> Gokturk > >>
