Hi there. Today let’s take a quick look in some few steps to Dockernizing Meteor apps.

In the last few days I’ve been playing with this and found some different solutions, even a variation of MeteorUp to deploy Docker containers carrying Meteor apps but there were not so suitable for me, I have some SSL restrictions some customizations to do so, I decided to do it by myself and guess what? Was not that hard, both Meteor and Docker do a great job to do our lives easier.

The build process

The build process to create a bundle from a meteor app is quite simple, four lines and the bundle is ready, this the script that I’ve been using in the root of my project.


meteor build --architecture=os.linux.x86_64 ../dashboard-build
cd ../dashboard-build && tar -zxvf dashboard.tar.gz
cd ../dashboard

The unique detail here that differ from a regular build process is the –architecture=os.linux.x86_64 parameter, I’d to use it because my host OS is a MacOS.

After these lines will notice that you have a directory called bundle inside dashboard-build, this is the exploded gzip file.

The containerization process

Here I’ve created another file in the root of my project, a docker-compose.yml with all the instructions necessary to build and start my Meteor app.

  image: node:4.4.7
    - ${PWD}/../dashboard-build/bundle:/bundle
    - "3000:3000"
    - mongo
    - MONGO_URL=mongodb://mongo/dashboard
    - ROOT_URL=http://something.some
    - PORT=3000
    - NODE_ENV=production
  command: >
    bash -c "cd /bundle/programs/server && 
           npm install && 
           npm install fibers &&
           npm install bcrypt"
  command: node /bundle/main.js
  image: mongo:latest
     - "27017:27017"

With this small file in hands, the last bit is to execute Docker and watch the magic happen.

docker-compose up

Done, you’ll see the logs going through your console. Now, just go to your browser and take a look at your beauty http://localhost:3000


Few days ago the Public Review Ballot of JSR 367 was refused by Java community, basically because of a lack of final consensus on few outstanding issues. Does it mean that Jigsaw will be delayed again to some future version of Java? Not necessarily, the spec group have 30 days to re-submit the specification and revert some negative votes.

Below you can see the result, votes and comments as well. Let’s see what happen.

Oracle voted Yes with no comment.

On 2017-04-28 IBM voted No with the following comment:

IBM’s vote reflects our position that the JSR is not ready at this time to move beyond the Public Review stage and proceed to Proposed Final Draft. The JSR 376 Expert Group and the public have raised a number of reasonable issues and concerns with the current public review draft of the specification that warrant further discussion and resolution. We advocate work continuing amongst all members of the Expert Group to address the issues documented on the mailing lists. IBM would like to see closer consensus amongst the entire Expert Group before this specification proceeds to the next step.

Intel Corp. voted Yes with no comment.

NXP Semiconductors voted Yes with no comment.

Werner voted No with the following comment:

I understand IBM’s and others reason for their “No” vote and heard many similar concerns by e.g. the OSGi community or contributors behind major build systems like Maven, Gradle or Ant. Most of their concerns are still unanswered by the EG or Spec Leads, which at this point I does not make this JSR seem ready yet.

Hazelcast voted No with the following comment:

From our point of view the lack of consensus inside the EG is a dangerous sign, that either not all issues are clarified the way they have to or that certain issues were marked solved from a single point of view. Overall, we acknowledge, that the state made big progress over the last months and a lot of issues were addressed with the community but it seems that the state for a public review ballot is not yet right.

In addition, problems with popular build tools don’t seem like a good starter. Our understanding of the EC is, that part of the work is to prevent the Java ecosystem from harm and in the current state the JSR376 cannot be seen as ready for that matter.

Red Hat voted No with the following comment:

Red Hat is voting NO on this JSR. The Red Hat middleware team, other members of the EC and Java community members, have mentioned publicly and in more detail our concerns (here

https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns and here

https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR376.pdf). We have also discussed with our own OpenJDK team, which made good counter arguments to several of the concerns, but in the end we believe a NO vote is the correct course of action. In previous votes and comments on the EG list we have articulated the view that from a middleware/SE developer perspective we believe that Jigsaw does not fulfil its original goals of being a module system which can be used by the likes of Java EE. We understand that after inception the original goals of the EG were initially changed to try to focus it on a module system to be used solely to modularise the JVM and that caused some architecture and implementation approaches which made it difficult for it to be a module system to be used by SE and EE developers. Unfortunately during the lifetime of the EG the goal appeared to switch back to trying to make it a module system for Java developers but previous implementation decisions appear not to have been revisited or could not be changed and as a result the expectations around Jigsaw have not been met by the implementation. Therefore, we are worried about the impact of the current implementation on the wider Java community, particularly existing projects and products including, but also beyond, Java EE. We have raised several issues within the EG list to try to rectify a few of these things in what we believe would have been a minimally invasive manner but they have been rejected. Furthermore, we believe that there has been insufficient consensus in the EG for a series of changes so dramatic to the JVM and which could have an equally dramatic impact on the Java communities, as well as a lack of openness on receiving and discussing community input. We believe that a more considered evaluation of all input and consensus gathering should not take too much time and would result in something which would be better received by the entire Java ecosystem.

Goldman Sachs & Co. voted Yes with no comment.

Software AG voted No with the following comment:

Software AG is concerned about the lack of a healthy consensus among the members of the Expert Group. Although we understand that a perfect consensus and zero outstanding issues may be unachievable, we believe that a healthier consensus is possible.We also believe that such a consensus would result in a healthier Java ecosystem and a smoother industry transition to a modular Java world.

Assuming the ‘No’ vote carries, we hope the specification lead would take advantage of the 30 days afforded under the JCP process to attempt to form a healthier consensus within the EG. We would appreciate specific attention being paid to the migration path for existing software in a modular world and on the co-existence of the specification with existing established Java practices and build systems (#ModuleNameInManifest, #CyclicDependences, #AutomaticModuleNames, #AvoidConcealedPackageConflicts, #MultiModuleJARs)

We look forward to being able to vote ‘Yes’ on a draft that has stronger backing from its EG in a future ballot.

Azul Systems, Inc. voted Yes with no comment.

MicroDoc voted Yes with no comment.

Gemalto M2M GmbH voted Yes with no comment.

Credit Suisse voted No with the following comment:

SAP SE voted No with the following comment:

We absolutely recognize the tremendous achievements and the great work that has been carried out until now – by the expert group members as well as (and especially) by the spec lead himself. While the JPMS is in pretty good shape for the modularisation of the Java platform itself, we think that there are still some rough edges for libraries and frameworks outside the Java platform which should be addressed and agreed upon before the final approval of the specification.

We acknowledge the open development of the JPMS in the context of the “Project Jigsaw” within the OpenJDK. But we are at the same time concerned about the growing tension between the OpenJDK JEP and the JCP JSR processes. During the development and up to now it has not always been clear what in the development of the JPMS/Jigsaw is considered an implementation detail and what will be part of the standard specification. Features like the binary format of modules and runtime images, the jlink tool and new class attributes like hashes and versions are examples for non-standardised implementation details.

What we are especially concerned about however, is the lack of direct communication within the expert group. Assuming this JSR won’t be approved with the required two-thirds majority, we would expect the expert group and spec lead to use the additional 30 days for regular meetings in order to sort out the remaining issues and come up with a new, more sustainable and forward looking proposal. While we’re aware that it won’t be possible to remedy all concerns, we think that the last days have clearly demonstrated that good compromises are still possible (e.g. the “automatic modules issue”) and we’re confident that the additional time could be used to submit a better specification for the reconsideration vote.

Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!

London Java Community voted No with the following comment:

We echo SAP’s comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.

The LJC is voting “No” on the spec *as it was submitted* at the start of the voting period. During the 14 day voting period, great progress was made by the Spec Lead and the EG to reach consensus on some very difficult issues such as #AutomaticModuleNames. However, there are still on going conversations on some of those issues and there simply has not been enough time spent by the ecosystem to discuss some of the new designs in enough depth or enough time spent implementing and testing prototypes based on the latest spec, e.g. The Eclipse ejc compiler or the latest Automatic Module Naming design in Maven.

If required, we very much look forward to being able to vote ‘YES’ in <= 30 days on a version that has had that little bit of extra time for the EG (and the ecosystem) to discuss / implement / test some of these difficult spec items. Certainly the last 14 days have shown that consensus can be reached even when viewpoints have started in opposing corners, and we think another short time period to really bed in the last sticking points is needed.

V2COM voted Yes with the following comment:

V2COM shares other EC members’ concerns, but we believe that all major concerns can be addressed between this ballot and the next ballot.

Grimstad, Ivar voted No with the following comment:

I am voting “No” on the specification as it was submitted at the start of the voting period. The discussion during the 14 day voting period has been very good, and I applaud the progress being made by the Spec Lead and EG in this period. Especially the latest Automatic Module Naming proposal.

With continued discussion and these changes incorporated in spec, I look forward to vote “Yes” in a potential reconsideration ballot.

Twitter, Inc. voted No with the following comment:

We see the introduction of the Java Platform Module System (JPMS) in Java 9 as a desirable and worthwhile addition to the Java platform. We also appreciate the enormous and difficult task it has been to retrofit a mature and widely-used language like Java with a module system 20 years later. And we are thankful to the JSR lead, the Expert Group (EG), and everyone involved for their dedication and all the hard work it has taken to make it a reality.

Our main concern is that it is likely that this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system. We are worried that this will delay wide-scale adoption of this important technology. We hope that if the JPMS accomplishes some of its original goals more comprehensively (in particular, collisions in non-exported package names are arguably incompatible with the “non-interference” and “strong encapsulation” goals) it can address real pain points that Java developers have today (e.g., dealing with multiple copies of the same package by hiding them as non-exported packages). This would encourage more developers to rapidly adopt modular development.

Finally, we think broader consensus among the JSR lead and the EG members is necessary for such an important JSR.

SouJava voted Yes with the following comment:

SouJava votes YES for the Java Platform Module System specification.

As others have said, we agree there has been a tremendous achievement in this effort by the team, in something many believed would never succeed. But the uneasiness of a specification that was not agreed by the EG it was ready for public review led the discussions inside SouJava towards a NO vote.

The movement of the Spec Lead in the last few weeks changed the general sentiment, and we are thankful for the effort of solving the issues.

We agree with the London Java Community and others that the specification AS WAS SUBMITTED for public review is lacking. We understand that the Spec Lead should focus on an initial release that will be improved later, and we were even willing to accept some compromising on the tooling issues.

But if the specification does not support independent implementations, it’s a bigger problem. Independent implementations are the primary objective of the JCP, and we do not intend to keep the yes vote if the situation persists.


Fujitsu Limited voted Yes with the following comment:

There are a lot of concerns, but we hope EG members will resolve them by the next ballot.

Eclipse Foundation, Inc voted No with the following comment:

Like LJC, the Eclipse Foundation is voting “No” on the spec *as it was submitted* at the start of the voting period. The Eclipse Foundations looks forward to a revised specification which will enable independent implementations. The recent conversations have been very positive, and we feel that the expert group is moving into the right direction. However, the draft spec that are have been asked to vote on do contain a number of serious deficiencies, as documented by the recent conversations on the various mailing lists. We feel that the spec will be significantly improved by an opportunity to complete those conversations and include them in a revised draft.


Hewlett Packard Enterprise voted No with the following comment:

While recognizing progress made by expert group and lead, Hewlett Packard enterprise prefers to allow expert group to address inputs, resolve open issues and come up with updated draft.

Tomitribe voted No with the following comment:

Tomitribe’s no vote is tempered with a concern the specification does in fact make it through the JCP process successfully. The risk of passing this JSR through to the next stage is that should it fail the Final Approval Ballot, the spec lead and EG have only 30 days to resolve all issues or the specification fails permanently per JCP rules.

We echo sentiments of other voters in applauding the progress in the last 14 days. While the 30 days window afforded by a No vote will not gain a perfect consensus, we do believe it will help significantly. It allows time for the dust to settle; with all the changes in the last 2 weeks, what exactly will be presented for a final vote is in some ways less clear.

We see positives in opting for a 30 fixed window for feedback to and from the EC as it keeps pressure which is critical for momentum. JSR-299 (CDI 1.0) went 9 months between its Public Review Ballot and Final Approval Ballot, delaying Java EE 5 significantly. We would not want to see the same happen here. The 30 day window applies both to the spec lead and essentially to the EG who knows we’ll be voting immediately after.

Though a No vote feels like rejection we ultimately believe it is the most supportive vote for gaining a greater level of consensus we believe is necessary from a JSR, while still keeping time pressure.



Hello there! This post is to talk a little about PlantUML.

PlantUML is an open-source tool allowing users to create UML diagrams from a plain text language. The language of PlantUML is an example of a Application Specific Language.[3] It uses Graphviz software to lay out its diagrams. It has been used to allow blind students to work with UML.[4][5]PlantUML also helps blind software engineers to design and read UML diagrams.

Ok, maybe you’re blind, maybe not, but the thing is that I’ve seen people using this tool around and looks interesting, 1 is free, 2 once you learn the syntax it becomes easier than drag’n drop icons here and there. Really, give it a try next time you need to create diagrams.

Under the hoods, PlantUML uses Graphviz to generate the diagrams besides you can use a wide range of tools to help you with that, like plugins for IDEs like PlantUML Integration for IntelliJ.

Particularly I have a preference for PlantText, is online, free and make it easy to create and export your diagrams. In the beginning, you’ll probably need some reference, I suggest the official documentation, you can find other tutorials and posts about it but most of you need is there already, just navigate through the main menu “above” and you’ll probably figure out quick how to do what you need.

Today I was scratching something about Docker for a future post.

[Docker Repository] as Repository
[Docker File] as File
[Docker Dir] as Dir
[Text Editor] as Editor

Editor -up-> File : edits
File -left-> Dir : contained in
Dir -up-> Image : docker build
Image -left-> Container : docker run
Image -right-> Repository : docker push
Container --> Image : docker commit
Repository --> Image : docker pull
Repository --> File : imported by Dockerfile "from" statement

And this is the result.

Nothing fancy here but you can create some complex ones for all types of diagrams that you need.

Another interesting thing about this approach is that how it generate diagrams from text, you can easily integrate with other tools, let’s imagine that you have a huge system, confusing and hard to understand just reading the code, you can integrate or extend a code analysis tool to output diagrams to give you an idea from a big picture perspective view.

Yes, quite nice, give it a try, may you have some nice ideas to use it beyond the diagrams.

Hello there! Probably today most of us are aware of the power that Docker bring to us, how it make easy and clean tasks that before could take time, resource and sometimes, cause some headaches too. I’ve been playing with Docker and I would like to write down some basic points that I think could clarify the whole thing, starting by Terminology.

I have no intention of cover everything, just touch those most common parts when using Docker. So, let’s start with a simple diagram. “I think I’m the visual kind, I love figures :)”

Basic docker workflow

Here things happen when you start do edit a Dockerfile that is a recipe which describes the files, environment, and commands that make up an image, usually this file is contained in a directory, at first directory looks meaningless but you’ll forward (not in this post) that Docker uses the name of the directory to create containers when we use docker-compose.

After defining your Dockerfile is time to build the image that will be created on your local machine and will be used as a base definition for the containers that we’ll create using it. Confusing? You can think about images as classes and containers as instances.

Once you have your image you can run it to do whatever you want, just like you use to do on your own machine eg.

docker run --rm -it debian bash

Here, we’re executing bash in a container created based on debian image.

  • –rm tells docker that this container should be deleted when it exits
  • -it basically means that the container should be executed in interactive mode

Cool, let’s suppose that you made some changes in this container while you were using it and you want to keep these changes, the way to do this is committing your changes, then Docker will create a new layer on top of the image that you already have and next time when you run this image, the container created will have your changes.

Now if you want, you can share your changes, pushing them to the Repository that is basically a network/internet connected service that contains images and in the same fashion, you can update images “pull” with changes from somebody else.

To not make it too long I’ll break terminologies in more than one post, but hope that this short one gave you some basic idea for the daily basis.

See ya!


Inspired by some tutorials about how to configure JAVA_HOME on Linux/MacOs I’ll show here how to quickly change JDK versions on Linux/MacOs.

FYI: You can use this trick to swap between any kind of configuration that you need, I’ll use Java as an example just because.

The problem

Sometimes you’re working with wide versions of the same technology, that use the same environment variables but are in different places in the file system, a good example is JDK.

Some guys go back to .bashrc or .bash_profile every time and set different values to the same variables to work properly with whatever they need.

Time and patience are required and worse, is repetitive.


Defining functions that can be executed anywhere, this is part of my .bash_profile to handle Java versions.

export DEV_TOOLS=/Users/allandequeiroz/dev


function j7 {
        export JAVA_HOME=$JAVA7
        export MAVEN_HOME=$DEV_TOOLS/apache-maven-2.2.1
        export PATH=$JAVA_HOME/bin:$PATH 
        export PATH=$MAVEN_HOME/bin:$PATH

function j8 {
        export JAVA_HOME=$JAVA8
        export MAVEN_HOME=$DEV_TOOLS/apache-maven-3.3.9
        export PATH=$JAVA_HOME/bin:$PATH 
        export PATH=$MAVEN_HOME/bin:$PATH

function j9 {
        export JAVA_HOME=$JAVA8
        export MAVEN_HOME=$DEV_TOOLS/apache-maven-3.3.9
        export PATH=$JAVA_HOME/bin:$PATH 
        export PATH=$MAVEN_HOME/bin:$PATH

We can define environment variables inside functions, so if I’m working now with java 9 and for some reason, I need to compile some code in Java 7, all that have to do is


Now I’m on JDK 7 and Maven 2 :’(

Moving to 8


That’s it. There are more interesting things like alias for example, where you can define guess what? Aliases to complex or long commands, but let’s see it in another post, see ya!