On Aug 17, 2011, at 4:22 PM, Martijn Dashorst wrote: > I'm talking about putting WicketTester in a -tests classified jar. It > is a 100% core functionality that has to be in the default, normal > distribution without having to resort to include yet another jar file > in your pom.
Yep, me too. I am agreeing that this should not be a <type>test-jar</type>, which is used for tests. No disagreement at all. Apologies if that's not the impression I was giving. > > Don't get me wrong, I like the fact that -util, -core and -request are > merged into one jar. I am not fan of feature jar-itis where each > class/package gets its own jar. As an observer, there needs to be better criteria of what functionality gets a jar and what functionality does not and have that criteria applied consistently. I appreciate "you're not a fan of" is not an outright prohibition on it, but the ambiguity around whether the team will or will not accept a patch is challenging to deal with, and only gets more challenging when there are two or three others that have different positions. If this position were made absolute, you would have no room to accept -request and -util being split out, right? :-) My criteria: 1) Does it cause packaging problems 2) Should given functionality be excludable or swappable 3) Does it introduce unwanted transitives. You guys have a fourth criteria of "can we use it to keep developers from doing dumb things", which my position isn't really relevant on, though it's on a completely different decision axis that dramatically reduces the solution space when it's invoked. > > As for removing Assert.* from our code base, or from WicketTester and > replacing them with Args: this removes the IDE support for catching > the special JUnit messages and makes them become plain errors instead > of failures: the exceptions will not get the special treatment that > makes Java development so nice. I've never taken the position that Assert.* should be removed from test code, only production code. It's an antipattern to have Assert.* or assert() in production code, explicit exceptions should be thrown instead. Once Assert.* is removed from the production code, removing the unwanted dependency on junit is simple if WicketTester (a test, not production code dependency) is not bundled in -core. > > Martijn > > On Wed, Aug 17, 2011 at 7:07 PM, Andreas Pieber <[email protected]> wrote: >> Are you talking about the wicket tester or the maven test scope? >> >> Kind regards Andreas >> On Aug 17, 2011 7:03 PM, "Martijn Dashorst" <[email protected]> >> 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-plugincontaining >>>>> 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 >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com >
