openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Desktop Meecrowave extension contribution
Date Fri, 02 Feb 2018 13:53:01 GMT
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 <
>> 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
> main/java/org/apache/openejb/loader/provisining/ and
> openejb-loader/src/main/java/org/apache/openejb/loader/
> provisining/ - 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

View raw message