Re: Maven build

OK, I just updated RIVER-300 with the details that should allow this to build. Basically there were some details that didn't get captured in the original patch due to the way SVN creates patches, which I wasn't familiar with. Sorry, I'm so used to d

Re: Maven build

My local copy builds (well, compiles anyway), but it looks like a change or two I made did not get propagated to the http://svn.apache.org/repos/asf/river/jtsk/modules branch. I may have missed something in creating my patch. I'll go back and check and see what's different and either send a patch t

Re: Maven build

That's correct, it's not at a stage where it's building yet. On 7/7/2020 1:50 AM, Dennis Reedy wrote: I'm wondering if I'm missing a step here. This is what I've done: 1. svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules 2. cd modules/modularize/apache-river 3. mvn package [INFO]

Re: Maven build

I'm wondering if I'm missing a step here. This is what I've done: 1. svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules 2. cd modules/modularize/apache-river 3. mvn package [INFO] Scanning for projects... [ERROR] [ERROR] Some problems were encountered while processing the POMs: [WARN

Re: Maven build

Hi Phil, I've solved this circular dependency problem once before with JGDMS, there were also circular package dependencies I wanted to avoid for OSGi users, so it will be a good opportunity to take another look at this problem, so we've got the best possible solution. I'm familiar with the

Re: Maven build

On Sun, Jul 5, 2020 at 8:07 AM Peter Firmstone wrote: > > Hi Phil, > > I've been going through your patch, you've got a lot of work done in a > short time. :) > > I've just committed your changes. > > I'll have a look at the circular dependencies and see what I can do in > the coming week. Sounds

Re: Maven build

Hi Phil, I've been going through your patch, you've got a lot of work done in a short time. :) I've just committed your changes. I'll have a look at the circular dependencies and see what I can do in the coming week. Cheers, Peter. On 7/5/2020 3:46 AM, Phillip Rhodes wrote: Hi Phil, Wo

Re: Maven build

> > Hi Phil, > > Wow, you're really getting into the code, thank you. > > It's late here, I'll post again in the morning, just some quick > clarifications, the discovery providers depend on the platform, but the > platform shouldn't depend on the discovery providers, try removing that > dependency

Re: Maven build

Hi Phil, Wow, you're really getting into the code, thank you. It's late here, I'll post again in the morning, just some quick clarifications, the discovery providers depend on the platform, but the platform shouldn't depend on the discovery providers, try removing that dependency from the pla

Re: Maven build

OK, here's the latest: The good news: I just managed to run "mvn clean compile package" and see (almost) everything run through successfully. I say almost because I commented out the groovy-config module, and all references to the gmaven plugin for now. This is because the Groovy and gmaven-plugin

Re: Maven build

OK, for the sake of my own edification if nothing else, I've been plowing ahead with making the various changes needed to get all of this stuff to compile. I'm pretty close (in relative terms anyway) to having everything compiling, but now I've hit something that I think I need to get everyone else

Re: Maven build

OK, sounds good. Another question: it looks like some packing renaming / code restructuring has gone on as part of this effort, unless I'm missing something. I see things like class DestroySharedGroup having a package statement at the top like package org.apache.river.start; but it's physical lo

Re: Maven build

d. I was working on the wrong branch before, so that explains some of the issues I was seeing. I think. :-) I checked out http://svn.apache.org/repos/asf/river/jtsk/modules and am trying to make the Maven build work. I found a few small issues, for which I can submit patches if you folks would like.

Maven build

Moving this to a new thread. I was working on the wrong branch before, so that explains some of the issues I was seeing. I think. :-) I checked out http://svn.apache.org/repos/asf/river/jtsk/modules and am trying to make the Maven build work. I found a few small issues, for which I can submit

Re: Failure in the existing Maven build due to non-existent repository

OK, for what it's worth, it appears that that class is now part of the com.boundary.high-scale-libs dependency, so I just took out that non-existent repository, bumped the reference to high-scale-libs to what appears to be the latest (1.0.6) and commented out the custard-apple reference. The build

Failure in the existing Maven build due to non-existent repository

Folks: I was trying to get the existing Maven build working, for my own edification, regardless of what eventually happens with the initiative to create a Gradle build. But I found a problem that I think will impact a Gradle build (or anything that relies on pulling dependencies from remote

Maven Build and OSGi Platform Support

As most are probably aware, we are progressing with the Maven build of River, all packages have been moved and now it's time to commence moving the junit tests to their maven modules. The maven build structure is based on the work we've done in JGDMS, but there's no java code

Re: OSGi [PREVIOUSLY]Re: Maven Build

Thanks Gregg, those are very good points. Cheers, Peter. On 2/10/2017 10:35 PM, Gregg Wonderly wrote: I like the constructor argument mechanism as it becomes thread local detail, rather than VM level detail. Too many “platform” things in Java have ended up being “service type platform” lik

Re: OSGi [PREVIOUSLY]Re: Maven Build

I like the constructor argument mechanism as it becomes thread local detail, rather than VM level detail. Too many “platform” things in Java have ended up being “service type platform” like, instead of multiple services platform like. Keeping things thread of execution specific helps us suppo

Re: OSGi [PREVIOUSLY]Re: Maven Build

I'm considering api that may be required for improved OSGi support. In order for an OSGi environment to deserialize a proxy, it needs to first install a bundle for the proxy and resolve any dependencies. For OSGi a ProxyPreparer must first locally marshall (create a MarshalledInstance) a java

Re: OSGi [PREVIOUSLY]Re: Maven Build

Yes, I've been thinking about it. My current thoughts; ServiceUI can be accessed through net.jini.lookup.ServiceAttributesAccessor, so you can unmarshall ServiceUI objects, without unmarshalling the service itself. However I haven't given much consideration to locating codebases for ServiceU

Re: OSGi [PREVIOUSLY]Re: Maven Build

Yes that's correct. Sun chose to use the ClassLoader to represent the service's pincipal, dynamically granting permission after proxy verification. So that's what we have available on the call stack to use when performing authorisation permission checks: 1. Client's Principal. (Principal

Re: OSGi [PREVIOUSLY]Re: Maven Build

Hi Peter, In reading your missive I'm not sure I understand when you say "Maven will present a new alternative of maximum sharing, where different service principals will share the same identity.", or "Maven class resolution". Are you referring to an approach where a service may declare it's code

Re: OSGi [PREVIOUSLY]Re: Maven Build

Do you have anything planned around ServiceUI? I really use ServiceUI as a discovery mechanism to find services which export a UI that a user can interact with. What can happen at registration time, besides Entry specification to help with codebase where ServiceUI bits are at? Are you just re

OSGi [PREVIOUSLY]Re: Maven Build

Some updates on thoughts about OSGi: 1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar), ServiceDiscoveryManager and ProxyPreparer allow provisioning of OSGi bundles for Jini services. 2. SafeServiceRegistrar lookup results contain only instances of java.lang.reflect.

Re: Maven Build

Peter wrote: This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_ source=email&utm_medium=notification All modules are also OSGi bundles, no split packages, no circular dependencies. Yeah even phoenix is still there, no longer dependant on the

Re: Maven Build

dreedyman/apache-river-example). If you'd like >> I could work with you and see what a Gradle version of JGDMS would look >> like, IMO it will simplify the project greatly. >> >> HTH >> >> Regards >> >> Dennis >> >> Sent from my iP

Re: Maven Build

gt; >> Regards >> >> Dennis >> >> Sent from my iPhone >> >>> On Jun 23, 2017, at 7:50 AM, Peter wrote: >>> >>> This is what a Maven Build looks like: >>> >>> https://travis-ci.org/pfirmstone/JGDMS/builds/24615885

Re: Maven Build

an/apache-river-example). If you'd like I could work with you and see what a Gradle version of JGDMS would look like, IMO it will simplify the project greatly. HTH Regards Dennis Sent from my iPhone On Jun 23, 2017, at 7:50 AM, Peter wrote: This is what a Maven Build looks like: h

Re: Maven Build

e On Jun 23, 2017, at 7:50 AM, Peter wrote: This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email&utm_medium=notification All modules are also OSGi bundles, no split packages, no circular dependencies. Yeah even phoenix is still

Re: Maven Build

github.com/dreedyman/apache-river-example). If you'd like I could work with you and see what a Gradle version of JGDMS would look like, IMO it will simplify the project greatly. HTH Regards Dennis Sent from my iPhone On Jun 23, 2017, at 7:50 AM, Peter wrote: This is what a Maven Build lo

Re: Maven Build

27;d like I could > work with you and see what a Gradle version of JGDMS would look like, IMO it > will simplify the project greatly. > > HTH > > Regards > > Dennis > > Sent from my iPhone > >> On Jun 23, 2017, at 7:50 AM, Peter wrote: >> >

Re: Maven Build

simplify the project greatly. HTH Regards Dennis Sent from my iPhone > On Jun 23, 2017, at 7:50 AM, Peter wrote: > > This is what a Maven Build looks like: > > https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email&utm_medium=notification > > All mod

Re: Maven Build

ls much clearer to me. Haven’t found a single “copy source/class file” yet. ;) Very nice! -Dan From: Peter Subject: Maven Build Date: June 23, 2017 at 7:50:36 AM EDT To: "" This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=emai

Re: Maven Build

! -Dan From: Peter Subject: Maven Build Date: June 23, 2017 at 7:50:36 AM EDT To: "" This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email&utm_medium=notification All modules are also OSGi bundles, no split package

Maven Build

This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email&utm_medium=notification All modules are also OSGi bundles, no split packages, no circular dependencies. Yeah even phoenix is still there, no longer dependant on the Sun

Re: Maven build

This is a nice looking tool! Gregg Sent from my iPhone > On Jan 7, 2017, at 4:56 AM, Peter wrote: > > Neat little tool that generates vulnerability reports on dependencies during > a maven build. N.B. the following aren't actual dependencies of Phoenix. > > org.o

Maven build

Neat little tool that generates vulnerability reports on dependencies during a maven build. N.B. the following aren't actual dependencies of Phoenix. org.owasp dependency-check-maven Cheers, Pete. Dependency-Check is an open source tool performing a best effort analysis of 3rd

River maven build - initial testing with Rio

So far building Rio against the River maven build, there are 3 test failures. I've added compatibility layer to River of com.sun.jini classes that extend theirorg.apache.rivercounterparts to provide a backward compatible subset of deprecated com.sun.jini namespace (only the parts o

Re: Maven Build

rts.  You can also implement your own.  A ClassLoader may contain multiple ProtectionDomains. Regards, Peter. Sent from my Samsung device.     Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" Sent: 17/11/2016 08:38:45 pm To: dev@river.apac

Re: Maven Build

Indeed - it is possible to specify your dependencies as tightly as you want in OSGi. The issue is that: 1) It defeats one of the main purposes of OSGi in the first place 2) Nobody does that which would mean the only objects you can send over the wire would be instances of classes from specially

Re: Maven Build

. Regards, Peter. Sent from my Samsung device.     Include original message Original message From: Michał Kłeczek Sent: 16/11/2016 06:07:54 pm To: dev@river.apache.org Subject: Re: Maven Build While non-hierarchical class loading is crucial, OSGI with its non-deterministic dependency

Re: Maven Build

11:15:05 pm To: dev@river.apache.org Subject: Re: Maven Build I’d encourage the active River committers to review the OSGi Alliance RS / RSA specifications. These specifications don’t deal with dynamic code download at present - but no reason why they should in future - if there is a compelling

Re: Maven Build

On Wed, Nov 16, 2016 at 8:43 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > 3. My comment about OSGi being "non-deterministic" in resolving dependencies means that the > same bundle installed in two different environments is going to be linked with different dependent

Re: Maven Build

trust domain (even a later version of River could be provisioned using > >>> Maven). A subprocess would exist for each trust domain. So if there are > >>> two companies, code from each remains isolated and communicates only > >> using > >>> common api.

Re: Maven Build

common api. No unintended code versioning conflicts. >>>> >>>> This choice would not prevent or exclude other methods of >> communication, >>> the service, even if isolated within it's own process will still >>> communicate r

Re: Maven Build

d be provisioned using >>>> Maven). A subprocess would exist for each trust domain. So if there are >>>> two companies, code from each remains isolated and communicates only >>> using >>>> common api. No unintended code versioning conflicts. >>&g

Re: Maven Build

onflicts. >>>> >>>> This choice would not prevent or exclude other methods of >> communication, >>> the service, even if isolated within it's own process will still >>> communicate remotely over the network using JERI, JSON etc. This is >&g

Re: Maven Build

dant of remote communication protocols. > > > > > > OSGi would of course be an alternative option, if one wished to execute > > incompatible versions of libraries etc within one process, but different > > trust domains will have a shared identity, again this may no

Re: Maven Build

may not matter > depending on the use case. > > > > Cheers, > > > > Peter. > > > > ESent from my Samsung device. > > > > Include original message > > Original message > > From: "Michał Kłeczek (XPro Sp. z o. o.)" >

Re: Maven Build

ible versions of libraries etc within one process, but different > trust domains will have a shared identity, again this may not matter > depending on the use case. > > Cheers, > > Peter. > > ESent from my Samsung device. > > Include original message > Origina

Re: Maven Build

ay not matter depending on the use case. Cheers, Peter. ESent from my Samsung device.     Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" Sent: 15/11/2016 10:30:29 pm To: dev@river.apache.org Subject: Re: Maven Build While I also thought

Re: Maven Build

ularise the codebase, I haven't run the test suites against it and it isn't generating stubs yet, and I'll need to modify the platform modules for the IoT effort after the conversion is complete. Here's the output of the River maven build: Reactor Summary: River-Internet P

Re: Maven Build

dy's script to modularise the codebase, I haven't run the test suites against it and it isn't generating stubs yet, and I'll need to modify the platform modules for the IoT effort after the conversion is complete. Here's the output of the River maven build: Reactor Summary

Re: Maven Build

run the > test suites against it and it isn't generating stubs yet, and I'll > need to modify the platform modules for the IoT effort after the > conversion is complete. > > Here's the output of the River maven build: > > Reactor Summary: > > River-Internet

Maven Build

t after the conversion is complete. Here's the output of the River maven build: Reactor Summary: River-Internet Project SUCCESS [0.689s] Module :: River Policy SUCCESS [8.395s] Module :: River Resources . SUCCESS [0.