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
