Can anybody build rio-5.0 branch from Git?

[Dawid Loubser]

Hi All,

I am trying to build the latest rio-5.0 branch from Git using:

git clone https://github.com/dreedyman/Rio.git;cd Rio;git checkout
rio-5.0;mvn install

Dennis confirmed being able to build it on his side, but all attempts
on my side have failed - oddly, with two different unit tests failing
based on the environment I build on (my Macbook Pro, or a Linux box).
Maven 3.0 and Java 1.6 in both cases.

Just wanted to find out if anybody else is able to build it? I am
hoping for a fix in the opstring parsing bug that made it impossible
to specify serviceDiscoveryTimeout, which I am hoping to rely on. I am
hesitant to build and use it with forced skipping of the unit tests
(it surely won't function correctly for the same reasons the tests are
failing).

I realise that 5.0 is still an unstable branch, but I am hoping that
by the time we have to start doing some real testing in a month or so,
it will be stable enough for use.


-------------------------------------------------------------------------------
Test set: org.rioproject.watch.WatchDataSourceImplTest
-------------------------------------------------------------------------------
Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.005
sec <<< FAILURE!
testAddCalculable(org.rioproject.watch.WatchDataSourceImplTest) Time
elapsed: 0.263 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:283)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at
org.rioproject.watch.WatchDataSourceImplTest.doTestAddCalculable(WatchDataSourceImplTest.java:
539)
at
org.rioproject.watch.WatchDataSourceImplTest.testAddCalculable(WatchDataSourceImplTest.java:
467)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod
$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:
15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:
41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:
20)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:
79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:
71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:
49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:
53)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:
119)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:
101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.ProviderFactory
$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy22.invoke(Unknown Source)

[Wade Chandler]

I'm using the latest Oracle JDK 6 on Ubuntu 11.04 64-bit 8GB RAM and
Maven 3.0.3. I was able to build without issues using my default mvn
profile (git branch is reporting rio-5.0):
mvn clean; mvn install

Have you tried a clean?

Thanks,

Wade

--

=================
Wade Chandler

Software Engineer and Consultant
NetBeans Contributor
NetBeans Dream Team Member

wadechandler.com
netbeans.org

[Ronald Bowers]

Hi Dawid,

I was able to build twice without any issues. I built it once starting from an empty repository and then again from the repopulated repo. 

My environment 

Mac OS X 10.6.8

Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)

Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)

-Ron

--------

[Wade Chandler]

Pretty sure I tried to send from the wrong address before, so here it is
again:

I'm using the latest Oracle JDK 6 on Ubuntu 11.04 64-bit 8GB RAM and
Maven 3.0.3. I was able to build without issues using my default mvn
profile (git branch is reporting rio-5.0):
mvn clean; mvn install

Have you tried a clean?

Thanks,

Wade

--

=================
Wade Chandler

Software Engineer and Consultant
NetBeans Contributor
NetBeans Dream Team Member

wadechandler.com
netbeans.org

On 02/28/2012 06:12 AM, Dawid Loubser wrote:

[Dawid Loubser]

I am absolutely confused by this - still can't build.
I tried it again: A clean machine (CentOS linux machine provisioned in
Rackspace) setup with:

$ java -version
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) Server VM (build 20.2-b06, mixed mode)

$ mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 19:31:09+0200)
Maven home: /opt/maven
Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
Java home: /usr/java/jdk1.6.0_27/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.18-164.el5", arch: "i386", family:
"unix"

$ git --version
git version 1.7.7.2

I run (to checkout and install):

git clone https://github.com/dreedyman/Rio.git;cd Rio;git checkout
rio-5.0;mvn install

*Note: Clean not necessary on first build, but I tried it in anyway to
appease you lot, no difference :-)

WatchDataSourceImplTest (assertion line 539) consistently fails. Stack
trace same as posted earlier in the thread, and I see the following
output to stdout in Maven:

Running org.rioproject.watch.WatchDataSourceImplTest
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=1, Replicator (LoggingWatchDataReplicator) size=2, expected
size=2
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=1, Replicator (LoggingWatchDataReplicator) size=2, expected
size=2
WDS size=1, Replicator (LoggingWatchDataReplicator) size=3, expected
size=3
WDS size=1, Replicator (LoggingWatchDataReplicator) size=12, expected
size=12
WDS size=0, Replicator (LoggingWatchDataReplicator) size=0, expected
size=0
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=0, Replicator (LoggingWatchDataReplicator) size=0, expected
size=0
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=1, Replicator (LoggingWatchDataReplicator) size=2, expected
size=2
WDS size=1, Replicator (LoggingWatchDataReplicator) size=11, expected
size=11
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=2, Replicator (LoggingWatchDataReplicator) size=2, expected
size=2
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1000,
expected size=1000
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1001,
expected size=1001
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1002,
expected size=1002
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1011,
expected size=1011
WDS size=0, Replicator (LoggingWatchDataReplicator) size=0, expected
size=0
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=999, Replicator (LoggingWatchDataReplicator) size=999,
expected size=999
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1000,
expected size=1000
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1001,
expected size=1001
WDS size=1000, Replicator (LoggingWatchDataReplicator) size=1010,
expected size=1010
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=2, Replicator (LoggingWatchDataReplicator) size=2, expected
size=2
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10000,
expected size=10000
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10001,
expected size=10001
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10002,
expected size=10002
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10011,
expected size=10011
WDS size=0, Replicator (LoggingWatchDataReplicator) size=0, expected
size=0
WDS size=1, Replicator (LoggingWatchDataReplicator) size=1, expected
size=1
WDS size=9999, Replicator (LoggingWatchDataReplicator) size=9999,
expected size=9999
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10000,
expected size=10000
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10001,
expected size=10001
WDS size=10000, Replicator (LoggingWatchDataReplicator) size=10010,
expected size=10010
WDS size=1, Replicator (RemoteWDR) size=0, expected size=1
Feb 29, 2012 12:49:36 PM org.rioproject.watch.QueuedReplicator
$ReplicatorTask run
WARNING: Cannot archive:
java.rmi.ConnectIOException: I/O exception connecting to
BasicObjectEndpoint[236e7d3f-e75a-4604-85c2-
d962cc9ceed5,TcpEndpoint[127.0.0.1:59675]]; nested exception is:
java.io.IOException: interrupt waiting for connection header
at
net.jini.jeri.BasicInvocationHandler.wrapSafeIOException(BasicInvocationHandler.java:
893)
at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:
711)
at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:
659)
at
net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:
528)
at $Proxy25.replicate(Unknown Source)
at
org.rioproject.watch.WatchDataReplicatorProxy.replicate(WatchDataReplicatorProxy.java:
42)
at org.rioproject.watch.QueuedReplicator
$ReplicatorTask.run(QueuedReplicator.java:98)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.io.IOException: interrupt waiting for connection
header
at com.sun.jini.jeri.internal.mux.Mux.start(Mux.java:213)
at net.jini.jeri.connection.ConnectionManager
$OutboundMux.newRequest(ConnectionManager.java:356)
at net.jini.jeri.connection.ConnectionManager
$ReqIterator.next(ConnectionManager.java:630)
at net.jini.jeri.BasicObjectEndpoint$1.next(BasicObjectEndpoint.java:
371)
at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:
708)
... 11 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.sun.jini.jeri.internal.mux.Mux.start(Mux.java:207)
... 15 more
Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.177
sec <<< FAILURE!

Results :

Failed tests:
testAddCalculable(org.rioproject.watch.WatchDataSourceImplTest):

[Wade Chandler]

I am getting issues now. To reproduce in a bash terminal I had to type:
unset RIO_HOME

and too I did:

mkdir ~/.old_m2
mv ~/.m2/repository/org/rioproject ~/.old_m2

So it is related to either the RIO_HOME or the mvn repository and
something in a script or opstring possibly pointing to some other version.

Hope it helps,

Wade

--

=================
Wade Chandler

Software Engineer and Consultant
NetBeans Contributor
NetBeans Dream Team Member

wadechandler.com
netbeans.org

[Dennis Reedy]

Ok, I did exactly what you did Wade, I blew away my .m2 directory and did get one failure:

Running org.rioproject.resolver.ITResolverTest
java.io.FileNotFoundException: /Users/dreedy/.m2/settings.xml (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at org.rioproject.resolver.FileUtils.copy(FileUtils.java:55)

Is this what you saw?

But the test that keeps failing for Dawid always passes, no matter what. I'll keep digging.

Dennis

[Dawid Loubser]

Consistent failure on my side is definitely
org.rioproject.watch.WatchDataSourceImplTest. Tried now in four
different environments. I have tried in environments where RIO_HOME
has been set, and has not been set, so we can probably rule that out.
The only consistency is that I have never built an earlier version
(prior to 5.0 branch from about last week) in any of these
environments, so there will be no older code in the Maven repo.

Dennis, if you'd like a login on my linux box (which has Java, Maven,
Git installed) I'm happy to provide one for you to see for
yourself :-)

> >> git clonehttps://github.com/dreedyman/Rio.git;cdRio;git checkout

[Wade Chandler]

I only moved away my rio maven artifacts, and I did not blow away my entire repository. In bash rc I set up rio home, so in a single terminal window I  unset rio home using unset which blows away the env var for all subprocesses in that term session. I had to leave for a bit, as the build was taking a very long time, and it seemed for me things were failing a lot. Surely I will have a full report when I get back. I will post as soon as I can.

Wade

=================

Wade Chandler
Software Engineer/Consultant
www.wadechandler.com

NetBeans Dream Team Member
NetBeans Contributor
www.netbeans.org

[Dennis Reedy]

On Feb 29, 2012, at 814AM, Dawid Loubser wrote:

> Consistent failure on my side is definitely
> org.rioproject.watch.WatchDataSourceImplTest. Tried now in four
> different environments. I have tried in environments where RIO_HOME
> has been set, and has not been set, so we can probably rule that out.
> The only consistency is that I have never built an earlier version
> (prior to 5.0 branch from about last week) in any of these
> environments, so there will be no older code in the Maven repo.

This shouldnt matter. I've just done several clean runs with an empty (local) maven repository.

Just a quick question, do you use DNS? I see in your log file that the endpoint is bound to 127.0.0.1. Just trying to find out why basic communications using JERI doesnt work in this case.

>
> Dennis, if you'd like a login on my linux box (which has Java, Maven,
> Git installed) I'm happy to provide one for you to see for
> yourself :-)

Maybe, thats certainly an option. Cant do it today though, maybe tomorrow. Great idea.

[Dawid Loubser]

On Feb 29, 3:50 pm, Dennis Reedy <dennis.re...@gmail.com> wrote:
> Just a quick question, do you use DNS? I see in your log file that the endpoint is bound to 127.0.0.1. Just trying to find out why basic communications using JERI doesnt work in this case.

I've tried building when my machine was connected to the network (in
which case, DHCP assigns my personal machine a random Name +IP) as
well as having no network connection. No luck in either case. What
exactly are the networking requirements? JERI communication certainly
works, I can run and deploy example rio apps, and I could do my own
before starting to encounter a weird "ResolverException: Could not
find artifact com.sun.jini:outrigger:jar:2.1 in central (http://
repo1.maven.org/maven2/)" error that I am consistently getting now,
but that's another thread :-)

> > Dennis, if you'd like a login on my linux box (which has Java, Maven,
> > Git installed) I'm happy to provide one for you to see for
> > yourself :-)
>
> Maybe, thats certainly an option. Cant do it today though, maybe tomorrow. Great idea.

I'll send you a login via your personal e-mail, this might clarify
some things yes. It'd be great of you could take a couple of minutes
to participate in such a test.

regards,
Dawid

[Dennis Reedy]

What I find strange is that (and this is my assumption) you have no problems running this test using 4.2. If indeed this is the case, what very strange is that there have been no changes to this test between the two versions.

Can you confirm that you ca run this test using 4.2?

Thanks

Dennis

[Dawid Loubser]

I've never built 4.2 from source, I'll try ASAP.

[Dawid Loubser]

> On Feb 29, 4:19 pm, Dennis Reedy <dennis.re...@gmail.com> wrote:
> > Can you confirm that you ca run this test using 4.2?

No, I cannot run this test when building 4.2 (same failure reason, see
attached log). Tried it in both my Mac and Linux environments, I ran
(fresh checkout):

git clone https://github.com/dreedyman/Rio.git;cd Rio;git checkout

rio-4.2;mvn install

-------------------------------------------------------------------------------
Test set: org.rioproject.watch.WatchDataSourceImplTest
-------------------------------------------------------------------------------

Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.27
sec <<< FAILURE!
testAddCalculable(org.rioproject.watch.WatchDataSourceImplTest) Time
elapsed: 0.436 sec <<< FAILURE!

junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:283)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at
org.rioproject.watch.WatchDataSourceImplTest.doTestAddCalculable(WatchDataSourceImplTest.java:

540)
at
org.rioproject.watch.WatchDataSourceImplTest.testAddCalculable(WatchDataSourceImplTest.java:
468)

59)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:
120)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:
103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at

org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:
350)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:
1021)

[Dennis Reedy]

On Feb 29, 2012, at 944AM, Dawid Loubser wrote:

>> On Feb 29, 4:19 pm, Dennis Reedy <dennis.re...@gmail.com> wrote:
>>> Can you confirm that you ca run this test using 4.2?
>
>
> No, I cannot run this test when building 4.2 (same failure reason, see
> attached log). Tried it in both my Mac and Linux environments, I ran
> (fresh checkout):
>

Okay, thanks. At least its reproducable for you :|

[Dawid Loubser]

Alright, this is officially weird (although somehow supported by the
inconsistent behaviour reported by others earlier in this thread). I
deleted (on my Linux server) both the local maven repo, and the
project, re-checked out rio-5.0.

* I tried to build it, and all tests passed!! (after noticing that the
build downloaded all manner of rio-5.0.SNAPSHOT maven metadata files
from the Rio maven repo)
* I tried it again, and there are many failures (almost all
integration tests fail with:
Mar 1, 2012 9:36:15 AM net.jini.discovery.LookupDiscovery
$UnicastDiscoveryTask run
INFO: exception occurred during unicast discovery to localhost:40704
with constraints InvocationConstraints[reqs: {}, prefs: {}]
java.lang.ClassNotFoundException:
com.sun.jini.reggie.ConstrainableRegistrarProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:434)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:
620)
at org.rioproject.rmi.ResolvingLoader.loadClass(ResolvingLoader.java:
60)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138)
at
net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:
296)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:
1574)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:
1495)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:
1731)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
at
com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:
397)
at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:
3327)
at java.security.AccessController.doPrivileged(Native Method)
at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:
3324)
at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:
3355)
at net.jini.discovery.LookupDiscovery.access
$3900(LookupDiscovery.java:696)
at net.jini.discovery.LookupDiscovery
$UnicastDiscoveryTask.run(LookupDiscovery.java:1744)
at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:
331)

* I delete the local maven repo and try again, but no luck (no it
fails again on the usual org.rioproject.watch.WatchDataSourceImplTest)
* I try again, and now consistently it fails with the above-mentioned
java.lang.ClassNotFoundException:
com.sun.jini.reggie.ConstrainableRegistrarProxy. The build never
completes, and I have not managed to build it ever again. None of the
tests ever seem to discover a service registrar.

Still nothing I do can make it build on my local Mac (which is much
slower than the Linux server I'm building it on. I wonder if this
"random" behaviour is not caused by some time-based constraint, i.e.
things not happening quickly enough? (delayed either by slower CPU, or
more likely poor network, since I am in South Africa - we have no
broadband that can be called that).

Anybody else have similar experiences? I am concerned. I don't really
want to be build rio-5.0 in anyway, I want to be building my software
which uses rio-5.0-snapshot :-) When was the last snapshot pushed to
the Rio maven repo?

regards,
Dawid

[Dennis Reedy]

The artifact missing issue you are running into is related to local maven meta data conflicting with locally installed artifact. I'm trying to get the precise order to reproduce this issue. What happens in 'normal' Rio startup is that Rio check to see if it's client (download) artifacts are installed in the local maven repository. If the artifact are not installed Rio will install them.

When lookup starts, it has as it's codebase artifact:com.sun.jini/reggie-dl/2.1 (transposes to com.sun.jini:reggie-dl:2.1), the Rio RMIClassLoaderSPI implementation looks to resolve that artifact and uses maven to do so. The underlying Aether resolver determines that the artifact should indeed be checked against a repository, and that check fails (becasueit's not in central).

Whats messed up is that if you check your local repository you'll see the artifact in question (com.sun.jini:reggie-dl:2.1), but it has meta data in the _maven_repositories file that looks to point to central. And there are no Jini jars in central.

So I'm trying to fix this, I hope to have the cross-wiring setup correctly.

As for the snapshot being pushed, once I get the above figured out I will push the snapshot.

Thanks for your patience

Dennis

[Dawid Loubser]

Ah, that clarifies things! Good luck in resolving this subtle one,
Dennis.
No need to thank me for patience, thank *you* for your incredibly
prompt responses to these issues! I can go on fine for the moment -
I'm building rio-5.0 without unit tests and hoping for the best :-)
It's working out so far :-)

Dawid

[Dennis Reedy]

Okay, making progress here, but not enough to publish a snapshot yet. I'm planning on pushing commits tomorrow, I need a few more tests and iterations before I do that though.

Once that gets done, I'm still gating the snapshot for deployment. I need to get the weirdness of the WatchDataSourceImplTest case solved, and there seems to be a stubborn integration test (ScalingServiceTest) that works just fine when run by itself, but when run with all the other tests, it fails. I hope to have these issues resolved soon.

Dennis