On 5/12/18 9:28 am, Juan Pablo Santos Rodríguez wrote:
Hi,
f***.
cleaned my tomcat work directory and then I see the same issues reported by
Harry :-( I also see some ClassCastException stacktraces on stdout related
to those issues so I'm changing my vote to a -1.
At a first glance, seems [#1] is when at least one of the stacktraces was
introduced. I'll look on the next days into a way of having back functional
tests again, so this things don't happen anymore..
@Brian, the mvn test not doing the full build is due to Maven way of
resolving dependencies on multimodule builds. The dependencies are usually
resolved from your maven repo, *except* for those dependencies which happen
to be part of the reactor (in maven world, the reactor is the concrete
execution of a build, which is made up of the modules which take part on
that specific build). The reasoning behind that is that reactor
dependencies are supposed to be "fresher" than anything you have on your m2
repo.
In jspwiki-portable we try to unpack another jspwiki module so, when you do
the whole build, it tries to resolve the dependency from the reactor
instead of from your maven repo, that's why you get a failure with anything
less than mvn package. OTOH, if you've done a whole mvn install, you can go
to jspwiki-portable and execute mvn test there and it will succeed: your
reactor will be made up of one module (jspwiki-portable), so when trying to
unpack, it resolves the dependency from your maven repo
Yes, that worked OK for me.
However.... no matter which mvn target I run, the following messages are
emitted very early in the process:-
brian@schizo:~/sandboxApache/jspwiki-2-11-0-M1-RC1/jspwiki$ cd
jspwiki-portable/
brian@schizo:~/sandboxApache/jspwiki-2-11-0-M1-RC1/jspwiki/jspwiki-portable$
mvn test
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$1
(file:/usr/share/maven/lib/guice.jar) to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Is it just me, or do you all simply ignore them?
Brian
br,
juan pablo
[#1]:
https://github.com/apache/jspwiki/commit/87bf9b941fdff55fe4e80a031269d19bc39363a7#diff-71de8c033afbea8be078f02ec7f141a9R145
On Tue, Dec 4, 2018 at 11:09 PM Brian Burch <br...@pingtoo.com> wrote:
On 5/12/18 5:40 am, Juan Pablo Santos Rodríguez wrote:
Hi Brian,
just've updated the dead links on "Building from source code" page,
thanks
for pointing them out. As for cheat-sheet.md, I've look through it and
it's
a bit outdated, we'll have to keep it more up to date for next releases.
I refreshed the Building from Source Code page and now the url is
resolved properly for the mvn cheat sheet.
I agree with your observation about it being out-dated. It says "mvn
install" is the appropriate target, and makes no mention of "mvn package".
Anyway, anything less than mvn package is bound to give you the error you
see at jspwiki-portable. That module expects the main war to be at least
packaged/installed by the build (so it's picked by the reactor build, or
through a maven repo, local or remote), because it needs it to build the
portable artifacts. So it's an expected behaviour, for a complete build
you
should at least mvn (clean) package.
Thanks for the tip. "mvn package" worked perfectly for me this time. I'm
puzzled because /after/ a successful "mvn package", "mvn test" fails the
same way as before.
Anyway, I won't worry about that now - I'm sorry to say I have a backlog
of urgent tasks and this particular problem doesn't seem to be
significant enough to vote -1.
Also, I don't have a current tomcat development server that I can test
M1 on, because /that/ is also on my task list (brain slips seamlessly
into thoughts about recursion)!
I was feeling a bit guilty that I might not have time to test M1-RC1
within the voting window, given more than 1 day has elapsed already.
However, after reading Harry's report and his tentative -1 vote this
morning (SE Queensland time), I am tempted to vote +1/2, if such a thing
exists!
I've never been comfortable about "just throwing" 2.11.0.M1 into my
2.10.3-snapshot production system, particularly as something small but
significant was broken by an external change. I'll go back to lurking
while I raise my own priority to set up a proper testbed and see where
that takes me. I have a valid RC1 jspwiki-war/target/JSPWiki.war, so
that can be my starting point.
I'm a "glass half full" person, so well done and thanks for all the hard
work. As Arnie used to say... I'll be back!
Best wishes,
Brian
HTH,
juan pablo
On Tue, Dec 4, 2018 at 10:10 AM Brian Burch <br...@pingtoo.com> wrote:
On 4/12/18 6:01 am, Juan Pablo Santos Rodríguez wrote:
[X] +1 Approve the release
(please note that
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
has a curated changelog far more complete than the jira link; will also
add
it for future release votes)
Sorry to be a pain, but I get a 404 from the hyperlink on this page:-
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Building%20from%20source%20code
to this page:-
https://git-wip-us.apache.org/repos/asf?p=jspwiki.git;a=blob_plain;f=mvn_cheat-sheet.md
So, in the absence of direct guidance, I kicked off my "usual"
belt-and-braces sequence of:-
mvn clean (completed OK);
mvn compile failed with this:-
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack
(unpack-jspwiki-war) on project jspwiki-portable: Artifact has not been
packaged yet. When used on reactor artifact, unpack should be executed
after packaging: see MDEP-98. -> [Help 1]
mvn install (completed OK - that surprised me!);
mvn test failed on project jspwiki-portable just like the compile
lifecycle phase.
... running under:-
openjdk version "10.0.2" 2018-07-17
... on:-
Linux schizo 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Is this the expected result? I don't want to waste time trying to deploy
JSPWiki.war on tomcat if the build wasn't satisfactory.
Brian
cheers,
juan pablo
On Mon, Dec 3, 2018 at 8:56 PM Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:
This is a release vote for Apache JSPWiki, version 2.11.0.M1. The vote
will be open for at least 72 hours from now.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732&version=12343348
Note that we are voting upon the source (tag), binaries are provided
for
convenience.
Everybody is encouraged to vote.
Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.11.0.M1-rc1
Nexus staging repo:
https://repository.apache.org/content/repositories/orgapachejspwiki-1007
The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.11.0.M1-RC1
JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS
*** Please download, test and vote:
[ ] +1 Approve the release
[ ] 0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)
