I'm not sure why all this effort is going into something that works really well for us, and has worked for years. I don't see any benefit from using an obscure maven plugin, while we have a test framework setup that works. Sounds like make work to me.
As far as the junit dependency: wicket tester requires it, and we ship wicket tester in core. I don't want wicket tester going to a different JAR as I consider it an essential tool in Wicket development. Especially since OSGi should have some way of excluding junit should you want to do that. I don't have an objection to marking junit optional though. I don't see an argument that we should make life for 99% of wicket users more difficult, as well as our own lives, for just one OSGi dependency. Martijn On Mon, Aug 15, 2011 at 9:39 AM, Brian Topping <[email protected]> wrote: > Thanks for the feedback, Martin. > > I also ran into the issues around .js testing and the dynamic .html expected > output. In the latter case, I didn't dive deeper to realize that's what I > was looking at, but I didn't pursue it either. > > Regarding the test jar(s), there is also > o.a.w.extensions.ajax.markup.html.AjaxLazyLoadPanelTester and may be others I > haven't gotten to yet. It seems like the right thing to do is to create a > wicket-extensions-test (which has a dependency on wicket-test). This is not > an ideal pattern, but part of the issue with the module structure of > extensions not being in core. And if wicket-extensions were a standalone > project somewhere else on the internet, we'd still need a > wicket-extensions-test, so I don't think this is a degenerate case. > > I'll build out the latter with two test modules and we can take a look at it. > > Back to the topic of the license work, is there anything I can do to help > prove / disprove the work I've done? I'm happy to do deeper research > anywhere it's necessary, the bulk of the work on that is already done so it > doesn't make sense to slow down now. > > On Aug 15, 2011, at 12:10 PM, Martin Grigorov wrote: > >> Hi Brian, >> >> By unknown rules I meant whether there are some expectations by >> official Apache tools. I remember a tool named RAT which was used in >> 1.2.x and early 1.3.x releases but I know nothing more about it. >> >> .html files in test/java can be dynamic, i.e. WicketTestCase can save >> the output for a component/page and use it as "expected" result for >> future runs. >> So it is not possible to put the licence in all .html files. >> >> Another exception is usage of third party .js/.css files in >> wicket-examples - e.g. JQuery, Prototype.js >> >> I also like the idea of wicket-test.jar but a problem I see is that >> wicket-extensions also have **TesterHelper for LazyLoadPanel, and >> maybe wicket-test module will have to depend on -extensions ... >> >> Recently I tried to revive Matej's work on Wicket-Ajax NG and I tried >> to put all Ajax stuff in wicket-ajax.jar. It almost works but there >> were some problems which I have written somewhere but this is off >> topic here. >> >> On Mon, Aug 15, 2011 at 6:13 PM, Brian Topping <[email protected]> wrote: >>> Hi Martin, comments inline. >>> >>> On Aug 15, 2011, at 3:50 AM, Martin Grigorov wrote: >>> >>>> Is it possible to configure the plugin to fail on unknown files ? >>> >>> There are no limitations of what we can do, even if we need to fork the >>> mycila plugin to do it. :-) But if you mean "can the plugin as written >>> deal with unknown files, the only way to do that would be to include >>> everything (<include>**</include>) and then write an exclude that matches >>> every file that should not be included. This will catch new files that are >>> unknown in the way you mentioned. I didn't come to believe that the old >>> system did this though, just that it handled the six or so types (java, js, >>> xml, vm, css, and a couple others I don't remember ATM). >>> >>>> E.g. currently it excludes 'target/' folder and checks files with >>>> extensions .java, .xml, .html, .properties, .js, .css and .vm. Is it >>>> possible to add some global excludes for images and configure it to >>>> fail the verification if an unknown file is found. I.e. if there is >>>> src/main/java/org/apache/wicket/SomeFile.blah and it is not explicitly >>>> excluded then fail >>> >>> My experience with the old method of using unit tests to test that the >>> source code had headers was not an exact process either. I had seen many >>> files that did not have headers for no apparent reason. What I tried to do >>> was find a "best fit" to the existing rules. With as many files as there >>> are in the system, it would require an automated test rig to ensure that >>> every file was being managed exactly like the old system did, and given >>> that the old system had holes caught on visual inspection, it didn't seem >>> that was time well-spent. >>> >>>> >>>> Additionally can you add some comments around why some resources are >>>> excluded ? >>>> I just saw wicket-core/pom.xml has: >>>> <plugin> >>>> 83 >>>> + <groupId>com.mycila.maven-license-plugin</groupId> >>>> 84 >>>> + <artifactId>maven-license-plugin</artifactId> >>>> 85 >>>> + <configuration> >>>> 86 >>>> + >>>> <header>${project.parent.basedir}/licenses/asf-license-header.txt</header> >>>> 87 >>>> + <excludes> >>>> 88 >>>> + >>>> <exclude>src/main/java/org/apache/wicket/**/*.properties</exclude> >>>> >>>> and I wonder why line 88 is there. >>> >>> Yes, line 88 is probably incorrect. I'll take a look at it. >>> >>>> I know current JUnit based tests also have some exclusions but I'm not >>>> sure whether they have explanation "why". >>> >>> The issue is with test data. For instance, a .html file in the test tree >>> may not actually be used in the compilation of a test, it may be just for >>> comparison that WicketTester created the final output that is correct. >>> Adding a header to a file like that would cause the comparison (and the >>> test) to fail. >>> >>> We could add that header to both the test input and test output, but I was >>> trying to take the path of least impact. >>> >>>> >>>> On Mon, Aug 15, 2011 at 10:06 AM, Martin Grigorov <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> The change at >>>>> https://github.com/topping/wicket/commit/8f08c2082f90fcd54a7e4734b892d13e610a47bf >>>>> looks OK to me but I'm not quite familiar with the unit test based >>>>> solution (the current one). I'm not sure whether there are some >>>>> (unknown for me) rules like specific formatting which may become >>>>> broken now. >>> >>> This doesn't seem to be the case. I'm committed to supporting the change >>> that I made here though, so whatever minor changes are necessary, I'm happy >>> to have issues assigned to me. >>> >>>>> >>>>> I guess Andreas' solution will be needed at least for wicket-core >>>>> because as I said (Base)WicketTester depends on JUnit - both compile >>>>> and runtime. >>> >>> Yes, the best practice in this case is to have a test module containing >>> test code that has a runtime dependency on a library such as JUnit. There >>> was a huge amount of changes to get this in, and I overlooked that >>> o.a.w.util.tester is in core. Having it remain that way would cause the >>> entire body of work to be pretty, but not very useful to it's original end. >>> >>> Are there practical reasons that o.a.w.util.tester is in core? >>> >>> <snip/> >>> >>> Cheers, Brian >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
