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. >>>>>> >>>>>> >>>> >>>> >>> >> >> > > >
