+1 having a iCLA is a good thing to start ;)

LieGrue,
strub


> Am 02.02.2018 um 14:43 schrieb Aaron Anderson <aaronander...@acm.org>:
> 
> 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 
> <rmannibu...@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 <strub...@yahoo.de>:
> 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 <aaronander...@acm.org>:
> >
> > 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
> 
> 
> 
> 

Reply via email to