Hi Antoine Thanks for your feedback. > Niklaus, > > it's good to hear you got something working.
> > I would recommend you start a plugin from a clean slate, creating tests > each step of the way. It is the most challenging approach though. I therefore opted for the time being on reworking my example. What do you mean when you say plugin? Fork buildr4osgi and add a module under lib/buildr4osgi/eclipse, eg. pde_test.rb? Or a separate gem? Running PDE tests is vital for me, therefor I am willing to invest some more hours. But it might be, that I will work on my own build issues and try to get a better picture of all the problems involved. > Any of the other approaches you mention are ok too - keep in mind you're > doing the work, you're in charge :) > I would also look around for the guys behind the buildr bnd integration. > They may have use for this code too. That would be great. Do I have to post to another mailing list? Which one? > > 1) Yes, definitely an issue for OSGi plugins. The way Maven approaches this > is by defining those test projects as integration tests. I think that's the > way to go. I added compiling the jars via integration.setup. This works fine. > > 2) That can resolve itself if you use integration tests, I think. Worth > playing with. I added a custom junitreport of all the PDEtest, generating a HTML report into reports/PDE_test using integration.teardown. I will dig into howto add a new TestFramework late. You suggest that I should add a new TestFramework inheriting Buildr::TestFramework, e.g. similar to buildr/java/bdd.rb od buildr/java/tests.rb is the best way to go? > > 3) You shell out to java instead of using the built-in java capabilities of > Buildr. Your code is not tested and is assuming paths use slashes, which is > not true on Windows (File.join is the right way, or File.expand_path). Corrected now. The test runs now also under Windows-7. > You have a very big task to run the whole test - I would look at getting > used to Rake's mind mangling decomposing and create a graph of > dependencies. Partly done. Best regards Niklaus > > Good luck! > > Antoine > > On Thu, Jan 12, 2012 at 08:35, Niklaus Giger > > <[email protected]>wrote: > > Hi > > > > I published under > > https://github.com/ngiger/buildr-examples/tree/master/pde_tests > > the necessary buildfile to run Eclipse PDE tests for the > > PhonebookExample. > > > > If theres is an interest in the community I would invest some further > > work to > > transform it into an more accessible feature. > > > > Could you advise me, how I should submit it. As a git fork with a new > > feature > > extension? As a task? Based on buildr? or buildr4osgi? Or create a new > > buildr > > plug-in? Pointers to a good example would be wonderful. > > > > Also I am also unsure about fixing the following problems: > > > > 1) Eclipse does not easily support nesting project, see > > * https://bugs.eclipse.org/bugs/show_bug.cgi?id=245412 > > * > > http://wiki.eclipse.org/Top_Ten_Architectural_Problems_in_all_of_Eclipse > > Therefore many developers will have a separate test project in order to > > run their tests from an eclipse workbench. Fiddeling round with the > > layout I managed to merge two eclipse projects (aka directories) into > > one buildr project. Is may usage of path_to(:target,:test, :classes) > > correct or should it > > be path_to(:target,:test, :java, :classes)? > > > > 2) How to I add the resulting TEST*.xml via a junitreport to a common > > HTML report of all tests run? > > Is my way of deactivating the junit tests via "path_to(:target,:test, > > > > :classes)" correct? > > > > 3) Are there other weaknesses in my code? > > > > Any feedback would be welcome. Thanks in advance for your advice. > > > > Best regards > > > > -- > > Niklaus Giger -- Niklaus Giger Wieshoschet 6 CH-8753 Mollis +41 (0)55 612 20 54 P +41 (0)77 473 02 59 Mobil
