-tests are for actual test implementations, not a core testing framework like WicketTester. This would also get a -1 from me. It would be the same as putting junit.framework in a -tests.
On Aug 17, 2011, at 1:02 PM, Martijn Dashorst wrote: > I am really not a fan of those -tests jars. I've seen maven struggle > with them, and I definitely don't want wicket tester in -tests. that > would be a -1 from me. > > Martijn > > On Wed, Aug 17, 2011 at 11:30 AM, Martin Grigorov <[email protected]> > wrote: >> I just removed the dependency to JUnit in wicket-util. >> The licence mini-framework and XML well formed test are moved to >> wicket-util/src/test and all other projects have new dependency to >> wicket-util with scope 'test' and classifier 'tests'. >> >> Now I think the only dependency in runtime to JUnit is for >> WicketTester in -core. But I believe this should not be a problem for >> OSGi because the dependency scope is 'provided', i.e. Maven doesn't >> bring it as transitive dependency but the user should provide it >> herself if she wants to use WicketTester at runtime (e.g. for email >> generation). >> Am I correct or there is something that I miss for OSGi needs ? >> >> On Wed, Aug 17, 2011 at 10:33 AM, Andreas Pieber <[email protected]> wrote: >>> No, the plan is to provide an easy way to review patches. We do not want to >>> sidestep the asf here and we'll sqash the changes for simplicity and provide >>> them as patches attached to a jira issue once we decide that they are ready >>> >>> Kind regards Andreas >>> On Aug 17, 2011 9:10 AM, "Martin Grigorov" <[email protected]> wrote: >>>> As you know Wicket officially is still in Apache SVN. >>>> GitHub is a mirror of Apache's Git repo which is read-only. >>>> >>>> Pull Requests will make it easier for the (Git) users but then I have >>>> to extract the patch and apply it in SVN... >>>> If this step is easy to automate then it will be usable. >>>> >>>> On Wed, Aug 17, 2011 at 1:04 AM, Eelco Hillenius >>>> <[email protected]> wrote: >>>>> Did you guys consider working with pull requests on github? Works very >>>>> well in my experience. >>>>> >>>>> Eelco >>>>> >>>>> On Mon, Aug 15, 2011 at 9:08 AM, Brian Topping <[email protected]> >>> wrote: >>>>>> Yes, that will create a patch of the whole branch, which is already >>> there. >>>>>> >>>>>> On Aug 15, 2011, at 11:58 AM, Martin Grigorov wrote: >>>>>> >>>>>>> git diff myBranch..master > some.patch >>>>>>>> >>>>>>>> On Aug 15, 2011, at 11:46 AM, Igor Vaynberg wrote: >>>>>>>> >>>>>>>>> can we have a patch that changes those places to use Args.*? :) >>>>>>>>> >>>>>>>>> -igor >>>>>>>>> >>>>>>>>> On Mon, Aug 15, 2011 at 7:50 AM, Brian Topping <[email protected]> >>> wrote: >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> Just to provide some personal perspective and it's somewhat >>> off-topic... there's always a lot of things we can work around here (code >>> can always be compensated for with more code), but I think there is a >>> responsibility with all code to "leave it cleaner than you found it". To >>> say it differently, to me, any amount of effort today to keep things clean >>> is worth it, because tomorrow (with additional code thrown on), it may take >>> twice as long to undo it and we may not have options to work around the >>> problem any longer (thus forcing that we cannot avoid cleaning it up with >>> twice the investment). >>>>>>>>>> >>>>>>>>>> When I looked at the actual usages of JUnit, it was primarily on >>> junit.framework.Assert in about three or four random files, when in fact the >>> standing pattern is to use o.a.w.util.lang.Args or throw an >>> IllegalStateException if there is a problem with incomplete initialization. >>>>>>>>>> >>>>>>>>>> In this case, removing JUnit as a dependency from util in fact >>> improves the code, and in the process does not bury a dependency even >>> deeper. In fact, there was a comment in one of the POMs alluding to the >>> question of why JUnit was a runtime dependency. I don't think I am alone in >>> believing that it should have been removed. This doesn't answer to >>> o.a.w.util.tester.WicketTester, but that's better answered in Martin's >>> email. >>>>>>>>>> >>>>>>>>>> Cheers and thanks, >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> On Aug 15, 2011, at 2:44 AM, Andreas Pieber wrote: >>>>>>>>>> >>>>>>>>>>> Hey guys, >>>>>>>>>>> >>>>>>>>>>> I just want to jump in here. While I think it a good idea to check >>> license >>>>>>>>>>> headers via a plugin instead of a junit tests this is not a "no-go" >>> for the >>>>>>>>>>> osgification. There are various libs out there importing >>> org.junit... in the >>>>>>>>>>> compile phase instead of the test-phase (although not required). At >>>>>>>>>>> Servicemix such libs are typically wrapped using the >>> ;optional:=true >>>>>>>>>>> attribute. Since junit is not required at runtime I think we can go >>> the same >>>>>>>>>>> way for wicket here. >>>>>>>>>>> >>>>>>>>>>> WDYT? >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Andreas >>>>>>>>>>> >>>>>>>>>>> On Sun, Aug 14, 2011 at 22:24, Brian Topping <[email protected]> >>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi guys, thanks for the responses. The repository issue (as well >>> as an >>>>>>>>>>>> unknown about outside plugins) was a concern, part of why I >>> started a custom >>>>>>>>>>>> plugin. But if folks are comfortable with it, I think it's the >>> right way to >>>>>>>>>>>> go. It's used in Brix and it's been very robust and convenient. >>>>>>>>>>>> >>>>>>>>>>>> I created a branch at >>>>>>>>>>>> https://github.com/topping/wicket/tree/myclila-plugin containing >>> the >>>>>>>>>>>> changes. There are a lot of them and it took most of the day to >>> get it >>>>>>>>>>>> right. The plugin expects the license header to be formatted >>> slightly >>>>>>>>>>>> differently (for instance using "/**" instead of "/*" to start a >>> Java >>>>>>>>>>>> header). Their site suggests using <aggregation>, but that >>> results in all >>>>>>>>>>>> the configuration being in the parent POM, something that isn't >>> very good >>>>>>>>>>>> encapsulation of configuration. So I broke it out between >>> projects so it's >>>>>>>>>>>> easier to maintain. >>>>>>>>>>>> >>>>>>>>>>>> As for the specific excludes, I may not have precisely the same >>> excludes >>>>>>>>>>>> that the old test cases had. I started by copying them to the >>> best of my >>>>>>>>>>>> perception, then tuned them for the tests (which seems to be the >>> most >>>>>>>>>>>> sensitive aspect). Can anyone review the patch to see if there >>> are any >>>>>>>>>>>> obvious mistakes? >>>>>>>>>>>> >>>>>>>>>>>> If not, it would be very helpful for the OSGi effort if we could >>> get this >>>>>>>>>>>> patch applied. Removing the dependency on JUnit from wicket-util >>> is pretty >>>>>>>>>>>> important to the effort, and I think this provides benefits to the >>> project >>>>>>>>>>>> moving forward as well. >>>>>>>>>>>> >>>>>>>>>>>> Please let me know what I can do to facilitate. >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, Brian >>>>>>>>>>>> >>>>>>>>>>>> On Aug 14, 2011, at 9:05 AM, jcgarciam wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The problem with >>> com.mycila.maven-license-plugin:maven-license-plugin >>>>>>>>>>>>> as far as i remember is that is not yet published in central >>> maven >>>>>>>>>>>>> repository, so it cannot be used without adding their repo. in >>> the >>>>>>>>>>>> pom.xml >>>>>>>>>>>>> which is a problem if you are trying to get your project deployed >>> in OSS >>>>>>>>>>>>> Sonatype. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Aug 14, 2011 at 4:54 AM, Martin Grigorov-4 [via Apache >>> Wicket] < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The main user of JUnit in production is WicketTester. >>>>>>>>>>>>>> >>>>>>>>>>>>>> About ApacheLicenceTest - Jeremy tried to replace it with >>>>>>>>>>>>>> com.mycila.maven-license-plugin:maven-license-plugin in 1.4.x >>> but >>>>>>>>>>>>>> didn't finish it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Aug 14, 2011 at 6:04 AM, Brian Topping <[hidden email]< >>>>>>>>>>>> http://user/SendEmail.jtp?type=node&node=3742539&i=0>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> oic, there's a ApacheLicenseHeaderTest in every project. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm in the process of isolating the junit.framework package to >>> a test >>>>>>>>>>>>>> dependency so JUnit is not a dependency in production code. If >>> it were >>>>>>>>>>>> made >>>>>>>>>>>>>> into a plugin, the instances of per-project ApacheLicenseHeader >>>>>>>>>>>>>> configuration would need to come from the POM. That's kind of >>> where it >>>>>>>>>>>>>> belongs (it's part of the build, after all), but it could easily >>> be made >>>>>>>>>>>>>> into a configuration file that resides in each project to keep >>> the POMs >>>>>>>>>>>>>> clean. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Failing that, creating a separate module to contain >>> o.a.w.util.license >>>>>>>>>>>>>> that is a test scope dependency would be a last resort. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm going to go ahead and create a plugin that reads a >>> configuration >>>>>>>>>>>> file >>>>>>>>>>>>>> in each project. Some of the configurations are lengthy >>>>>>>>>>>>>> (org.apache.wicket.util.license.ApacheLicenceHeaderTest). That >>> would be >>>>>>>>>>>> a >>>>>>>>>>>>>> mess in the pom. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 13, 2011, at 10:09 PM, Brian Topping wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does anyone know why org.apache.wicket.util.license is in >>>>>>>>>>>> wicket-util's >>>>>>>>>>>>>> production source directory? I'm guessing it has something to >>> do with >>>>>>>>>>>> the >>>>>>>>>>>>>> desire to get the license plugin to fire every time a build is >>> made, but >>>>>>>>>>>> if >>>>>>>>>>>>>> that's the case, it would be better handled as a Maven plugin. >>> It's not >>>>>>>>>>>> a >>>>>>>>>>>>>> test and it's not a part of any public API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm happy to create a plugin if that's the case, please let me >>> know. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, Brian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Martin Grigorov >>>>>>>>>>>>>> jWeekend >>>>>>>>>>>>>> Training, Consulting, Development >>>>>>>>>>>>>> http://jWeekend.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> If you reply to this email, your message will be added to the >>> discussion >>>>>>>>>>>>>> below: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>> http://apache-wicket.1842946.n4.nabble.com/o-a-w-util-license-package-in-production-source-folder-tp3742291p3742539.html >>>>>>>>>>>>>> To start a new topic under Apache Wicket, email >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> To unsubscribe from Apache Wicket, click here< >>>>>>>>>>>> >>> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY= >>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> JC >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> View this message in context: >>>>>>>>>>>> >>> http://apache-wicket.1842946.n4.nabble.com/o-a-w-util-license-package-in-production-source-folder-tp3742291p3742824.html >>>>>>>>>>>>> Sent from the Forum for Wicket Core developers mailing list >>> archive at >>>>>>>>>>>> Nabble.com. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com >
