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

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

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

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:

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.

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,

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

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

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

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

Re: Maven build

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 coming in from

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”

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

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

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

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

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

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

Re: Maven Build

b.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

Re: Maven Build

gt; >> Regards >> >> Dennis >> >> Sent from my iPhone >> >>> On Jun 23, 2017, at 7:50 AM, Peter<j...@zeus.net.au> wrote: >>> >>> This is what a Maven Build looks like: >>> >>> https://travis-ci.org/pfirmston

Re: Maven Build

-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<j...@zeus.net.au> wrote: This is what a Maven Build looks like:

Re: Maven Build

iPhone On Jun 23, 2017, at 7:50 AM, Peter<j...@zeus.net.au> wrote: This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email_medium=notification All modules are also OSGi bundles, no split packages, no circular dependencies. Yeah

Re: Maven Build

/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<j...@zeus.net.au> wrote: This is what a Maven Build look

Re: Maven Build

er-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 <j...@zeu

Maven Build

This is what a Maven Build looks like: https://travis-ci.org/pfirmstone/JGDMS/builds/246158857?utm_source=email_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 JVM

Re: Maven build

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

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 party

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

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 <michal.klec...@xpro.biz> Sent: 16/11/2016 06:07:54 pm To: dev@river.apache.org <dev@river.apache.org> Subject: Re: Maven Build While non-hierarchical class loadin

Re: Maven Build

.@paremus.com> Sent: 16/11/2016 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

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

st domain. So if there are > >>> two companies, code from each remains isolated and communicates only > >> using > >>> common api. No unintended code versioning conflicts. > >>>> > >>>> This choice would not prevent or exclude o

Re: Maven Build

; communication, >>> the service, even if isolated within it's own process will still >>> communicate remotely over the network using JERI, JSON etc. This is >>> orthogonal to and independant of remote communication protocols. >>>> >

Re: Maven Build

ntended 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 remotely over the network using JERI, JSON etc.

Re: Maven Build

twork using JERI, JSON etc. This is >>> orthogonal to and independant 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, b

Re: Maven Build

t; > orthogonal to and independant 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 identit

Re: Maven Build

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.)" <michal.klec.

Re: Maven Build

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 > ---- Original message > From: "Mic

Re: Maven Build

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.)" <michal.klec...@xpro.biz> Sent: 15/11/2016 10:30:29 pm To: dev@river.apache.org Subject: Re: Maven Build While I also t

Re: Maven Build

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 Project SUCCESS [0.689s] Module :: River Policy ...

Re: Maven Build

ites 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 Project SUCCESS [0.689s] Module :: River Po

Re: Maven Build

st 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 Project .