I get this error when I simply run
mvn install
from the command line using the master branch.
My toolchains.xml looks like:
<?xml version="1.0" encoding="UTF8"?>
<toolchains>
<!-- JDK toolchains -->
<toolchain>
<type>jdk</type>
<provides>
<version>1.7</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>/usr/lib/jvm/java-7-openjdk-amd64</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<version>1.8</version>
<vendor>sun</vendor>
</provides>
<configuration>
<jdkHome>/usr/lib/jvm/java-8-oracle</jdkHome>
</configuration>
</toolchain>
</toolchains>
Maybe it's a problem with OpenJDK. (Only reason I use OpenJDK 7, is the
fact, that it was still installed and before using toolchains I was not
in the need of a JDK 7).
Joachim
On 08/31/2015 07:39 PM, Martin Grigorov wrote:
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
