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 <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-02-02 14:43 GMT+01:00 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 > > > > >
