+1 having a iCLA is a good thing to start ;) LieGrue, strub
> Am 02.02.2018 um 14:43 schrieb Aaron Anderson <[email protected]>: > > 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 > <[email protected]> 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 <[email protected]>: > 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 <[email protected]>: > > > > 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 > > > >
