No need to even build from the command line.
Just don't import the shaded module in Eclipse. Or for that matter, any
of the non-java modules like parent, top or top of JDBC etc.
For any dependency that is not a project in Eclipse, Eclipse will do the
maven thing and download the jars from the snapshot repo (which should
be setup in your global maven settings).
It is only at the point the RM bumps the version number does this need
something slightly different - it's nice if the RM kicks off a rebuild
on the central jenkins server rather than wiat for the overnight dev build.
Or you can "mvn install" like Adam says as well. "mvn -Pbootstrap" to
do it the fast way - it does the parent and shaded guava. Then the fast
local build of the core modules "mvn "-Pdev" works.
Andy
On 02/12/16 12:31, A. Soroka wrote:
This is not a solution, it is a workaround, but I do a full build (at the CLI)
before importing. Then I just leave the Jena module project closed in Eclipse.
Then Eclipse tries to resolve it for the other projects like any other Maven
dependency, which works because I already built it and it is available from my
local repo.
I agree that the whole thing is a bit odd, at best. At some point Rob had a
similar problem and I asked on-list why we shade Guava and it was explained:
https://lists.apache.org/thread.html/8fb52fc8f9d4cbdaa17853a07f8fcc16fcaaf7ef5d5cee07e38b6556@1433424160@%3Cdev.jena.apache.org%3E
It is to avoid conflict with a transitive dependency on earlier versions of
Guava from Hadoop.
https://issues.apache.org/jira/browse/HADOOP-10101
looks like it last got a comment in October, when someone suggested that Hadoop
start shading _its_ archaic Guava, which (I think) would be both polite and
useful. There doesn't seem to be any action on that front, but I am not at all
involved with Hadoop.
Another alternative was discussed in our thread above: managing and releasing
our shaded Guava independently of the main release. I think that as long as we
have to deal with the transitive issue, that is still a good idea. But as Andy
points out in that thread, it would create more work for a release manager. I'm
now a committer (which I was not then) so I can and do heartily volunteer for
that work for a shaded Guava subproject!
---
A. Soroka
The University of Virginia Library
On Dec 2, 2016, at 6:15 AM, Claude Warren <[email protected]> wrote:
I know that Rob commented on something similar about a year ago but I am
wondering if there is a common solution to the following problem:
I do a gig clone of the Jean repository.
I do an eclipse import existing maven from the root Jena directory.
Eclipse gets stuck in a null pointer loop during the build. (Maven builds
fine).
jena-arq fails to build and continiously loops.
If I build the shaded guava first and force the eclipse build to point to
the jar it seems to solve the problem.
Other packages will not compile because they have references to the shaded
package names but the shaded jar is not on the classpath.
Seems to me we need a way to make sure the shaded jar appears in the maven
dependencies so that it will be included in the pom. However, I think that
since the shaded guava does not have any source eclipse does not run it and
so does not build the jar that is needed by the other projects. I am not
certian this is the case.
Anybody have a solution to making Jena compile in Eclipse directly after
doing a git clone?
Thx,
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
