On Sun, Aug 30, 2015 at 7:57 PM, Joachim Rohde <[email protected] > wrote:
> Thanks for the effort, Martin. This makes things *really* easier. > > But just two small issues I encountered while compiling > > 1) I hadn't had toolchains configured on my machine so I was not able to > compile the project at first. I added a short paragraph in the Wiki ( > https://github.com/wicketstuff/core/wiki#toolchains) to point this out. > > What I haven't updated is the wiki entry about the release process ( > https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process > ) > > 2) I needed to set ${javadoc.disabled} to true, to compile everything, > else the JavaDoc plugin would fail: > > Failed to execute goal > org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadoc) > on project wicketstuff-annotation: MavenReportException: Error while > generating Javadoc: > Exit code: 1 - > /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/mount/MountPath.java:36: > error: reference not found > * {@link > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#getMountEncoder(org.apache.wicket.IRequestTarget)} > ^ > /home/jr/NetBeansProjects/wicketstuff-newfolderstruct/core/annotation/src/main/java/org/wicketstuff/annotation/scan/AnnotatedMountScanner.java:126: > warning: no @param for pattern > public List<Class<?>> getPackageMatches(String pattern) > ^ > How exactly I could reproduce this? I've tried with Java 8 but m-toolchains-p correctly uses Java 7 for compiling and for javadoc and there are no errors here. > [...] > > > Is this on purpose? Or should we work-around it (solutions can be found > here: > http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete > ) > > > Joachim > > > On 08/22/2015 05:03 PM, Martin Grigorov wrote: > >> Done. >> It should be easier to port changes now! >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Sat, Aug 22, 2015 at 8:47 AM, Martin Grigorov <[email protected]> >> wrote: >> >> I start working on this. >>> Please do not push to WicketStuff 6.x and master until I'm ready. >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> https://twitter.com/mtgrigorov >>> >>> On Sun, Aug 16, 2015 at 7:23 PM, Martin Grigorov <[email protected]> >>> wrote: >>> >>> +1 for toolchains! >>>> >>>> I think we should start by introducing m-toolchains-p in the current >>>> POMs. Just to make sure that running "mvn clean package" on the parent >>>> project builds successfully all modules. >>>> Then the second step is to remove jdk-1** middle modules and make the >>>> flat hierarchy. >>>> >>>> @Joachim: do you want to do this yourself? Otherwise I may have the time >>>> next week >>>> >>>> Martin Grigorov >>>> Wicket Training and Consulting >>>> https://twitter.com/mtgrigorov >>>> >>>> On Wed, Aug 12, 2015 at 3:16 PM, Martijn Dashorst < >>>> [email protected]> wrote: >>>> >>>> For Wicket proper we now have toolchains support to switch between jdk >>>>> 6, 7 [and possibly 8]. There's no reason to not use this for wicket >>>>> stuff IMO. >>>>> >>>>> Martijn >>>>> >>>>> On Thu, May 7, 2015 at 8:21 AM, Martin Grigorov <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Joachim, >>>>>> >>>>>> The reason to use two separate folders is that at deploy time we use >>>>>> >>>>> [1]: >>>>> >>>>>> $ cd jdk-1.6.x; JAVA_HOME=$JAVA_6_HOME mvn deploy .... >>>>>> $ cd ../jdk-7.x; JAVA_HOME=$JAVA_7_HOME mvn deploy .... >>>>>> $ cd ../jdk-8.x; JAVA_HOME=$JAVA_8_HOME mvn deploy .... >>>>>> >>>>>> With your approach we could just use JAVA_8_HOME for all of them. >>>>>> m-compiler-p's settings will set the appropriate -target for each >>>>>> >>>>> module. >>>>> >>>>>> But this is not enough - we have to use something like >>>>>> http://mojo.codehaus.org/animal-sniffer-maven-plugin/ to make sure >>>>>> >>>>> that jdk >>>>> >>>>>> 1.6/7.x modules do not use feature from a newer JDK, because >>>>>> compiler's >>>>>> -target won't help. >>>>>> >>>>>> I think it should work. >>>>>> Do you want to try it out? >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> >>>>> https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process#steps-to-create-new-version >>>>> >>>>>> >>>>>> Martin Grigorov >>>>>> Wicket Training and Consulting >>>>>> https://twitter.com/mtgrigorov >>>>>> >>>>>> On Wed, May 6, 2015 at 11:50 PM, Joachim Rohde < >>>>>> >>>>> [email protected] >>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>> Hi, >>>>>>> As I already mentioned the other day I was porting some changes from >>>>>>> master branch to the wicket-6.x branch ( >>>>>>> >>>>>>> >>>>> http://apache-wicket.1842946.n4.nabble.com/wicketstuff-Need-help-with-cherry-picking-td4670615.html >>>>> ) >>>>> >>>>>> and had some trouble doing so, since Git was not able to cherry-pick >>>>>>> >>>>>> my >>>>> >>>>>> changes due to a different folder structure. Since this was really a >>>>>>> >>>>>> pain >>>>> >>>>>> in the neck (and quite erroneous) I would like to know if we cannot >>>>>>> >>>>>> get rid >>>>> >>>>>> of the distinction between different JDK versions in the folder >>>>>>> >>>>>> structure. >>>>> >>>>>> >>>>>>> At the moment all projects on the master branch are located in the >>>>>>> jdk-1.7-parent folder (since no project requires Java 8 yet, the >>>>>>> jdk-1.8-parent folder is empty). Most of those projects reside in the >>>>>>> jdk-1.6-parent folder on the wicket-6.x branch, making it impossible >>>>>>> >>>>>> to >>>>> >>>>>> simply downport changes via cherry-picking. Only difference between >>>>>>> >>>>>> the >>>>> >>>>>> POMs in those folders are the source- and target-level for the Maven >>>>>>> compiler plugin. >>>>>>> >>>>>>> Can't we just put everything in one folder and override source- and >>>>>>> target-level in the project specific POM if a project needs a higher >>>>>>> version than the default one? The only drawback I see at the moment >>>>>>> >>>>>> is the >>>>> >>>>>> fact, that you cannot recognize at a first glance if a project needs a >>>>>>> higher Java version. Or do I overlook here something? >>>>>>> >>>>>>> To be honest: I don't know if I would downport bigger changes on a >>>>>>> >>>>>> project >>>>> >>>>>> when myself only needs those changes on the master branch (since I'm >>>>>>> already using Wicket 1.7) and downporting is such a hassle. >>>>>>> >>>>>>> Joachim >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>>> >>>>> >>>> >>>> >>> >>
