From user-return-1401-archive-asf-public=cust-asf.ponee.io@openwebbeans.apache.org Fri Feb 2 14:53:35 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 8669F180608 for ; Fri, 2 Feb 2018 14:53:35 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 7540E160C49; Fri, 2 Feb 2018 13:53:35 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 46D84160C41 for ; Fri, 2 Feb 2018 14:53:34 +0100 (CET) Received: (qmail 51783 invoked by uid 500); 2 Feb 2018 13:53:33 -0000 Mailing-List: contact user-help@openwebbeans.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@openwebbeans.apache.org Delivered-To: mailing list user@openwebbeans.apache.org Received: (qmail 51773 invoked by uid 99); 2 Feb 2018 13:53:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2018 13:53:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 7A96FC4157 for ; Fri, 2 Feb 2018 13:53:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id f7Kv6YpD5aaV for ; Fri, 2 Feb 2018 13:53:30 +0000 (UTC) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 4D0645F1EE for ; Fri, 2 Feb 2018 13:53:29 +0000 (UTC) Received: by mail-yw0-f176.google.com with SMTP id t201so13208958ywf.1 for ; Fri, 02 Feb 2018 05:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hxlqWj8CbEVjTAnqt1ltuPwQ6gQrzNIR5O+F/GBHJsA=; b=UosbH8ImKkDRWt6P/JcwynL0zGRonEjdvEwwk2+1lYYTQ9mKguRUUpCQcrb6QXyIyt BCIYh7k0fKgO7kQVsqtmBngVLJCV4bc8SCKhMFf+Dlan6tK5uHq/vsPnZuPnSQFjpx7J tvN99KVyvOvtO6hzs9HVb77EPVYxCFhNv+CrlDobKnwFma1rCuD8DyX6vNeR79Yljixd ck/qnMDSXMEH7+FmMpnFqtxl0ngiblvkHqemxQt2oYB4unwPhHB0yGzuAGt6R8Abnb1J sLU2FtQ6NhjFNgQ4TgYj8E1ik6D3q10ILqYPbkJ+jlNsUWbii/W9MwNeAE72aQ4Etf/1 A1/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hxlqWj8CbEVjTAnqt1ltuPwQ6gQrzNIR5O+F/GBHJsA=; b=Pv38u2mKNPp2dpDQqmn8okbXrxibpvoh+FBsi4J+kkiMMW+WYvmepvDvLYU6NVJ7Sa 2Bo+G9WZi6oFmz8Jn5STdlsDoEoQzcpUD/4PD9zXFbjfe2Hm0Q3wmw2AQuYWsV9142z1 I9BvMjMtFdfKHnM7cwGouDTbQTpmPAF0MPEDWvBKaiC/Ol+I8EEpgraWD/Pn0p2JQBsr dmwei3rxAF2DkphJJi08Q9bm7x85mI5137zdgLuwChyzgZ18v3DxJwNnbG+kr/wlgSsE qBF+F+hC7oeaup6wHl5Q1zsuCLT9wCiePei5n8s51E1Yq6J0dPnhrqZE3k6E9knk8rXn AnZA== X-Gm-Message-State: AKwxyter7zhzhMCSiX2b6IfvOXSFZviXwi9pWUEnVDolh/WYKhKVGL6T BrGvLba15CxHDR8vfh57nNmgQxi13Tc471f3wOw= X-Google-Smtp-Source: AH8x224lq8BckSdirnZssfhS5F9hVDiMeSHnAvuOqw1NCD5X9TXZu54BIYbPYmtZeYjgaF0C2p235Zl93KLuHIhWAXk= X-Received: by 10.13.203.138 with SMTP id n132mr26861088ywd.39.1517579601974; Fri, 02 Feb 2018 05:53:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.48.132 with HTTP; Fri, 2 Feb 2018 05:53:01 -0800 (PST) In-Reply-To: <386588827.1948788.1517579019939@mail.yahoo.com> References: <322461138.1039859.1517465953890.ref@mail.yahoo.com> <322461138.1039859.1517465953890@mail.yahoo.com> <57658B89-83C7-405C-86BA-AD47F5C4A8D1@yahoo.de> <386588827.1948788.1517579019939@mail.yahoo.com> From: Romain Manni-Bucau Date: Fri, 2 Feb 2018 14:53:01 +0100 Message-ID: Subject: Re: Desktop Meecrowave extension contribution To: user@openwebbeans.apache.org, Aaron Anderson Content-Type: multipart/alternative; boundary="001a114e6f00181b8b05643b09c0" --001a114e6f00181b8b05643b09c0 Content-Type: text/plain; charset="UTF-8" quick advice: maybe start by the already agreed parts and do it iteratively instead of putting it all at once, will allow to merge faster ;) side note: we are in the process of planning a release, not sure it can be in but dont worry if not we can release later without issues Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book 2018-02-02 14:43 GMT+01:00 Aaron Anderson : > Hi Mark and Romain, > > I will go ahead and create a github fork of meecrowave and commit my > current work there. I was looking for affirmation that this contribution > could possibly be accepted before I went through the effort of renaming all > of the packages. If the contribution is accepted that will be great > otherwise it will be available on my fork for others to publicly access. > > I previously contributed to the Apache ODE project so my Apache Individual > Contributor License Agreement should still be on file. > > Once my fork is ready for review I will create a new thread on the > development list. > > Regards, > > Aaron > > > On Friday, February 2, 2018 2:25 AM, Romain Manni-Bucau < > rmannibucau@gmail.com> wrote: > > > I see, my fear about desktop API is it doesn't work well (browse() worked > 50% of the times on the computers I got in the last 5 years for instance, I > didnt set it up, right, but also not a great default). That said we can > easily replace it by an exec with config + good default guess algorithm. > > The system tray is interesting for me and I'm happy to test it on ubuntu > again. > > I'm less convinced by the 3 but I can need to see the code to be more > accurate, for now it looks overkill for me but can be a "mail reading" > issue. > > 4 clearly belongs to CXF directly for me. > > the update is very cool and I'm fine with Mark saying we do it here then > maybe generify it. > > the resolution should however clearly be maven friendly for me since it is > the mainstream and the way to be the most usable. Resolution is very easy > without maven stack or any dependency and with no dep: grab > https://github.com/apache/tomee/blob/master/container/openejb-loader/src/ > main/java/org/apache/openejb/loader/provisining/MavenResolver.java and > https://github.com/apache/tomee/blob/master/container/ > openejb-loader/src/main/java/org/apache/openejb/loader/ > provisining/HttpResolver.java - code dependencies are easy to import, it > is mainly sugar utilities we can copy over and it is a few code. I see i a > bit like OSGi features.xml, you get a list of artifact (your manifest) and > then grab it from coordinates (http, mvn, local filesystem?, ...). Don't > get me wrong, I'm not against supporting s3: as an optional extension but > 1. it shouldn't require any dependency (no aws sdk) by default, and 2. it > should be compatible with a plain maven repo (httpd proxy) to be usable by > most people. > > Hope it makes sense. > > 2018-02-02 9:17 GMT+01:00 Mark Struberg : > > Hi Aaron! > > This sounds like extremely useful work! > I hope you enjoyed digging into OWB and Meecrowave and of course we do > highly welcome your contributions back to the project :) > > Is the code available anywhere already? > Looking forward to work with you! > > @Romain incubator whould be an overkill for now I think. > I agree that such an update mechanism might become more generic in the end. > But I'd still start with it over here and then if it works fine we can > extract it out into a component and make it more reusable. > > >> 6) Finally I built a simple CLI release manager that queries the local > maven repository for version > >> information and then injects version manifest files into a copy of the > selected artifacts, jar signs them, > >> and then uploads them to a central server. Currently my release manager > uploads the update files > >> to an AWS S3 bucket that my server application reads from but I can > adjust it to publish to an SFTP server. > > > > Guess we will stick to maven/nexus/artifactory for this kind of things > to avoid a custom > > implementation and costly one (s3 is quickly too expensive) > > Yes, using something like Nexus or Archiva might be perfectly fine. > But I'd be not so quick judging before knowing Aarons exact use case. > > > > Just to make sure we are on the same page I am proposing that this > desktop extension would > > be packaged like the other component extensions, distributed in a > separate jar > > +1 > > > While Maven artifacts are a good fit for build management artifact > resolution it is very complex and > > requires a large number of dependencies making it less than ideal for > software asset provisioning > > Yes, Maven is surely more complex than needed for just file serving. > Otto it's a standard infrastructure item which doesn't require any > maintenance. > Btw re Maven: we might enhance our meecrowave-maven-plugin to package up > and deploy such a 'release'. > Regardless whether this is handled as attached-artifacts in a Maven repo > or done via scp, sftp, etc. > Again: would need to dig deeper to understand the exact need and solution. > > > > txs and LieGrue, > strub > > > > Am 01.02.2018 um 07:19 schrieb Aaron Anderson : > > > > Hi Meecrowave developers and users, > > > > I am nearly finished working on a Meecrowave extension for enhancing > Meecrowave to be a desktop platform. Here is some background on my work: > > > > For some time I have been working on a desktop application that manages > very sensitive data. The data it manages must be encrypted at rest and > requires password authentication to start it. The application cannot be > Cloud based. The application will be used by several dozen users so it > needs to have an update mechanism where I can push out updates. I can't > make the application purely JavaScript/Browser base since I need to use > some Java libraries to access and manipulate the data. > > > > I am familiar with Applets and Java WebStart but those are now dead > technologies. I actually built out an application using e(fx)clipse which > is based on JavaFX and the eclipse RCP platform but my update libraries are > behind an oauth protected web site and it took a tremendous amount of work > to get the update site feature to work. It was also laborious for me to > build the UI in JavaFX since that requires specialized knowledge that I > don't use day to day. > > > > This brings me to Meecrowave. In the past I have used several commercial > Windows applications that actually ran Tomcat as a service to render their > presentation view for their application. I am also working on a server side > application as well so using the same UI framework (Polymer) on both the > client and server is appealing to me. > > > > I started to build my client application using WildFly-Swarm but the > file size (130mb) was a little extreme considering I wanted support > frequent updates. Meecrowave addressed all of my concerns with cutting edge > API support, quick startup times, and small dependency sizes (25mb for my > runner and 11mb for my application). > > > > Now getting to my potential contribution, I have added several features > to Meecrowave to make it more desktop friendly: > > > > 1) System Tray - If one runs the Meecrowave jar as a java application it > runs in the background and there is visible cue it is accessible. I used > the Java AWT system tray to add an icon with a shutdown option to cleanly > shutdown the server. > > > > 2 Browser launch - Again I used the AWT desktop API provided with Java > to launch a browser instance to open the applications home page once the > application is started. > > > > 3) Interactive Authentication with Derby - As I mentioned my application > requires local authentication in order to decrypt the data. I built several > Java swing forms for password creation, change, and authentication. These > credentials are used to create or start an embedded Apache Derby database > using AES 256 encryption. > > > > 4) OAuth Client Support - My application updates and remote resources > are protected by an OIDC OAuth IDP so I built in a local OAuth JAX-RS > client that manages refresh tokens in the Apache derby database. There are > several examples of using CXF as an OAuth server but there is hardly any > documentation on using CXF with a pure JAX-RS 2.0 client to interact with > OAuth systems. > > > > 5) Update support - I built an update process that can independently > update the runner jar and application war. It performs several actions like > checking the local versions, fetching a version manifest file from a remote > protected HTTPS server, downloading updated jar files, and rendering > several Java swing forms to display the update status in real time. > > > > 6) Finally I built a simple CLI release manager that queries the local > maven repository for version information and then injects version manifest > files into a copy of the selected artifacts, jar signs them, and then > uploads them to a central server. Currently my release manager uploads the > update files to an AWS S3 bucket that my server application reads from but > I can adjust it to publish to an SFTP server. > > > > > > I have tested these enhancements on both Linux and Windows. The system > tray doesn't work on my Linux system very well but everything else does. I > also had contributing this code in mind when I developed it so I tried to > make everything plugable and configurable. > > > > Please let me know if there is any interest in having these features > contributed to the Meecrowave project as an extension. If so I can start to > work on a github pull request. > > > > Regards, > > > > Aaron > > > > > --001a114e6f00181b8b05643b09c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
quick advice: maybe start by the already agreed parts and = do it iteratively instead of putting it all at once, will allow to merge fa= ster ;)

side note: we are in the process of planning a r= elease, not sure it can be in but dont worry if not we can release later wi= thout issues

<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">
=
=

Romain Manni= -Bucau
@rmannibucau | =C2=A0Blog=C2=A0| Old Blog |=C2=A0Github=C2=A0| LinkedIn=C2=A0| B= ook

2018-02-02 14:43 GMT+01:00 Aaron Anderson <aaronanderson@acm.org>:
Hi Mark an= d Romain,

I will go ahead and create= a github fork of meecrowave and commit my current work there. I was lookin= g for affirmation that this contribution could possibly be accepted before = I went through the effort of renaming all of the packages. If the contribut= ion is accepted that will be great otherwise it will be available on my for= k for others to publicly access.

I previously contributed to the Apache ODE project so my Apache In= dividual Contributor License Agreement should still be on file.

Once my fork is ready for review I = will create a new thread on the development list.

Regards,

Aaron


On Friday, Februa= ry 2, 2018 2:25 AM, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
<= /div>

I see, my fear about desktop API is it doesn't work we= ll (browse() worked 50% of the times on the computers I got in the last 5 y= ears for instance, I didnt set it up, right, but also not a great default).= That said we can easily replace it by an exec with config + good default g= uess algorithm.

The system tray is = interesting for me and I'm happy to test it on ubuntu again.
=
I'm less convinced by the 3 but I can nee= d to see the code to be more accurate, for now it looks overkill for me but= can be a "mail reading" issue.

4 clearly belongs to CXF directly for me.

the update is very cool and I'm fine with Mark saying we = do it here then maybe generify it.

= the resolution should however clearly be maven friendly for me since it is = the mainstream and the way to be the most usable. Resolution is very easy w= ithout maven stack or any dependency and with no dep: grab=C2=A0https://github.com/apache/tom= ee/blob/master/container/openejb-loader/src/main/java/org/apache/= openejb/loader/provisining/MavenResolver.java and=C2=A0https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apa= che/openejb/loader/provisining/HttpResolver.java - code dependenci= es are easy to import, it is mainly sugar utilities we can copy over and it= is a few code. I see i a bit like OSGi features.xml, you get a list of art= ifact (your manifest) and then grab it from coordinates (http, mvn, local f= ilesystem?, ...). Don't get me wrong, I'm not against supporting s3= : as an optional extension but 1. it shouldn't require any dependency (= no aws sdk) by default, and 2. it should be compatible with a plain maven r= epo (httpd proxy) to be usable by most people.

Hope it makes sense.
<= /div>

2018-02-02 9:17 GMT+01:00 Mark Struberg <struberg@yahoo.de>:
Hi Aaron!

This sounds like extremely useful work!
I hope you enjoyed digging into OWB and Meecrowave and of course we do high= ly welcome your contributions back to the project :)

Is the code available anywhere already?
Looking forward to work with you!

@Romain incubator whould be an overkill for now I think.
I agree that such an update mechanism might become more generic in the end.=
But I'd still start with it over here and then if it works fine we can = extract it out into a component and make it more reusable.

>> 6) Finally I built a simple CLI release manager that queries the l= ocal maven repository for version
>> information and then injects version manifest files into a copy of= the selected artifacts, jar signs them,
>> and then uploads them to a central server. Currently my release ma= nager uploads the update files
>> to an AWS S3 bucket that my server application reads from but I ca= n adjust it to publish to an SFTP server.
>
> Guess = we will stick to maven/nexus/artifactory for this kind of things to avoid a= custom
> implementation and costly one (s3 is quickly too expensive)

Yes, using something like Nexus or Archiva might be perfectly fine.<= br clear=3D"none"> But I'd be not so quick judging before knowing Aarons exact use case.

> Just to make sure we are on the same page I am proposing that this des= ktop extension would
> be packaged like the other component extensions, distributed in a sepa= rate jar

+1

> While Maven artifacts are a good fit for build management artifact res= olution it is very complex and
> requires a large number of dependencies making it less than ideal for = software asset provisioning

Yes, Maven is surely more complex than needed for just file serving.=
Otto it's a standard infrastructure item which doesn't require any = maintenance.
Btw re Maven: we might enhance our meecrowave-maven-plugin to package up an= d deploy such a 'release'.
Regardless whether this is handled as attached-artifacts in a Maven repo or= done via scp, sftp, etc.
Again: would need to dig deeper to understand the exact need and solution.<= br clear=3D"none">


txs and LieGrue,
strub


> Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aaro= nanderson@acm.org>:
>
> Hi Meecrowave developers and users,
>
> I am nearly finished working on a Meecrowave extension for enhancing M= eecrowave to be a desktop platform. Here is some background on my work:
>
> For some time I have been working on a desktop application that manage= s very sensitive data. The data it manages must be encrypted at rest and re= quires password authentication to start it. The application cannot be Cloud= based. The application will be used by several dozen users so it needs to = have an update mechanism where I can push out updates.=C2=A0 I can't ma= ke the application purely JavaScript/Browser base since I need to use some = Java libraries to access and manipulate the data.
>
> I am familiar with Applets and Java WebStart=C2=A0 but those are now d= ead technologies. I actually built out an application using e(fx)clipse whi= ch is based on JavaFX and the eclipse RCP platform but my update libraries = are behind an oauth protected web site and it took a tremendous amount of w= ork to get the update site feature to work. It was also laborious for me to= build the UI in JavaFX since that requires specialized knowledge that I do= n't use day to day.
>
> This brings me to Meecrowave. In the past I have used several commerci= al Windows applications that actually ran Tomcat as a service to render the= ir presentation view for their application. I am also working on a server s= ide application as well so using the same UI framework (Polymer) on both th= e client and server is appealing to me.
>
> I started to build my client application using WildFly-Swarm but the f= ile size (130mb) was a little extreme considering I wanted support frequent= updates. Meecrowave addressed all of my concerns with cutting edge API sup= port, quick startup times, and small dependency sizes (25mb for my runner a= nd 11mb for my application).
>
> Now getting to my potential contribution, I have added several feature= s to Meecrowave to make it more desktop friendly:
>
> 1) System Tray - If one runs the Meecrowave jar as a java application = it runs in the background and there is visible cue it is accessible. I used= the Java AWT system tray to add an icon with a shutdown option to cleanly = shutdown the server.
>
> 2 Browser launch - Again I used the AWT desktop API provided with Java= to launch a browser instance to open the applications home page once the a= pplication is started.
>
> 3) Interactive Authentication with Derby - As I mentioned my applicati= on requires local authentication in order to decrypt the data. I built seve= ral Java swing forms for password creation, change, and authentication. The= se credentials are used to create or start an embedded Apache Derby databas= e using AES 256 encryption.
>
> 4) OAuth Client Support - My application updates and remote resources = are protected by an OIDC OAuth IDP so I built in a local OAuth JAX-RS clien= t that manages refresh tokens in the Apache derby database. There are sever= al examples of using CXF as an OAuth server but there is hardly any documen= tation on using CXF with a pure JAX-RS 2.0 client to interact with OAuth sy= stems.
>
> 5) Update support - I built an update process that can independently u= pdate the runner jar and application war. It performs several actions like = checking the local versions, fetching a version manifest file from a remote= protected HTTPS server, downloading updated jar files, and rendering sever= al Java swing forms to display the update status in real time.
>
> 6) Finally I built a simple CLI release manager that queries the local= maven repository for version information and then injects version manifest= files into a copy of the selected artifacts, jar signs them, and then uplo= ads them to a central server. Currently my release manager uploads the upda= te files to an AWS S3 bucket that my server application reads from but I ca= n adjust it to publish to an SFTP server.
>
>
> I have tested these enhancements on both Linux and Windows. The system= tray doesn't work on my Linux system very well but everything else doe= s. I also had contributing this code in mind when I developed it so I tried= to make everything plugable and configurable.
>
> Please let me know if there is any interest in having these features c= ontributed to the Meecrowave project as an extension. If so I can start to = work on a github pull request.
>
> Regards,
>
> Aaron


<= /div>


--001a114e6f00181b8b05643b09c0--