mercredi oct. 19, 2011

How to build a successful Java User Groups (JUG)

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

JUG's are an increasingly important part of the larger Java community (see recent JCP elections) and yet only a fraction of Java developers attend regular meetings (as we found out at JavaOne).

Before I start I probably should say that while I don't have hard data to back this up, I've seen a large number of JUG's be created in the past 2-3 years, more than 10 years after Java was first introduced, accounting for maybe as much as half of today's active JUGs. In France alone, there is more than a dozen active JUGs that were created, all in the last 3-4 years. There doesn't seem to be a shortage of interest for Java, quite the opposite.

I don't run a JUG nor am I really active in one but I've been visiting many of them in the past few years (they tend to be the format that I like best), I've seen a good number of them take off, some crash, and I interact with several JUG leaders on a regular basis, so I thought I'd share the ingredients that I believe are key to a successful JUG.

First, you need to have a venue. It may sound obvious but the lack of a regular (hopefully free-of-charge) room for your meetings is often the reason for JUG activity going down or simply disappearing. Universities seems to be the best solution after company meeting rooms.

Second, you need sponsors. While this can cover for Pizza & Beer (or Wine & Cheese, you decide), maybe more importantly this should help you cover for your speakers expenses (travel + hotel). While those speakers employed by large companies should be able to expense their entire travel, you don't want to miss out on the independent consultants. Another option is to have formal JUG members paying a yearly fee. This works well once you have a well established set of events, including maybe a yearly (international) conference.

Third, last, and not least - you need good content. This is content that addresses your JUG's interests and it doesn't have to be always about bleeding edge technology of the latest and greatest JVM language. Some folks take JUG's as a training, others mostly as a get-together, and probably also a good chunk as a way to stay on top of what's new in the Java ecosystem. You need to balance different topics but my recommendation would be to have a small set of folks decide on the agenda. Voting or large groups of folks deciding don't usually work too well.

While all of the above probably applies for any technology user group, JUG's are a bit special because they are loosely federated by mailing lists and interactions are facilitated by Sun initially and now by Oracle. If you are starting a JUG, you probably want to read about it on this all-in-one page, be listed on java-user-groups and start chatting with fellow JUG leaders, they are a great bunch and will most certainly have tips for you.

I should of course not forget to mention that you'll need energy and passion to keep a JUG running. Lot's of it!

mardi août 10, 2010

GlassFish community meeting + party, 2010 Edition

Just in case you haven't seen this on TheAquarium, we \*are\* going to have both a community event (similar to previous years unconferences) and a party at this year's JavaOne. Here are the relevant entries:

GlassFish Community Meeting During JavaOne
GlassFish Party at JavaOne

Both events require registration and some sort of conference pass.
Sign up here:
See you there!

mardi juin 08, 2010

GlassFish Community Update - June 2010

Following the recent release of Milestone 1 of GlassFish 3.1, it's time for a new Community Update today @ 9am PT (18:00 for most of Europe). Simply point your browser to Further details here.

Update: a replay is now available (we did have some technical difficulties but it's easier to skip through those).

vendredi mai 21, 2010

GlassFish : Open to Participation, ask Serli!

"Open" can mean a lot of different things, including in the context of GlassFish. In this entry, I'd like to discuss being open to participation.

The GlassFish community welcomes all sorts of participation. It probably starts with people asking questions and sharing their experience on the mailing lists or forum. The level of activity and response time there varies quite a bit. The engineering team is now crazy busy with the releases of 3.0.1 and 3.1 and as such this is a slower month than usual (with previous ones showing on the contrary record trafic). The other participation activity we'd like to encourage is filling bugs. It's often much better than trying to fix problems via email (permalink, artifacts, status, priority, etc...) and the bar isn't really high, in particular we don't require you to read GlassFish source code or suggest fixes (of course we like patches too!). Reproducible steps are on the other hand pretty much required.

Of course we also like it when people engage with the community to write books that leverage GlassFish one way or another (like this one, that one, and that other one to mention a few) or simply when users write blog entries about their GlassFish experience, good and bad (I personally like "bad but constructive" more than good...). In fact we like it when people take the time to share Java EE feedback as well, as we believe that more platform adoption results in more GlassFish adoption.

Finally there's the "ultimate" participation stage which is contributing to the development effort and we've actually seen an increase recently in the number of people offering help. In particular, this is what a small team of engineers from French company Serli have started doing for the past few months on the application version feature slatted for the 3.1 version. GlassFish is a massive codebase and it can be a challenge to integrate "external" contributors to a core component but this worked out so far very well. I think both parties are excited about this collaboration and you'll hear more about them (and what they get out of this work) in a podcast soon as well as during the next community event for the Milestone 1 release. In the meantime, thanks guys & keep it going! :)

mercredi avr. 22, 2009

Different strategies for building different packages (for GlassFish v3)

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

In my previous two posts (related to building packages for GlassFish), I covered the basics of the Update Center for GlassFish v3 and the underlying IPS/pkg(5) technology and what it takes to build a Hibernate package for GlassFish v3.

One key part that is still missing is the process (or social) side of things - how does one get to commit to the glassfish-repo project, and maybe more importantly, how does a community package make its way to the repository that is wired into every single GlassFish v3 distribution? This part needs a little more fine tuning and I will cover it soon in a dedicated post. In the mean time, I encourage you to join the glassfish-repo project as a developer.

In this post I'll cover the different possible natures for GlassFish v3 packages beyond the (rather simple) Hibernate example described earlier and available here to study. As you will see the spectrum of packages for GlassFish can be quite large.

1/ Frameworks and libraries
Examples include web frameworks, JDBC drivers, and any other technology that simply requires a set of JAR files to be available from the application running in GlassFish. Such JAR libraries should be placed into GLASSFISH_HOME/glassfish/lib. There is no need to restart GlassFish unless this is a new version of a library with the same JAR file name (individual applications may need to be restarted though). Note it is recommended that you do not touch the default GLASSFISH_HOME/glassfish/domains/domain1 domain. This is because putting any IPS-controlled file in that directory and having GlassFish (or the developer) modify or remove it will show up as a "partially installed" package.
This package use-case is the simple approach discussed in the previous Hibernate use-case.

2/ Applications running in GlassFish
Assuming an application packaged in a WAR, JAR, or EAR has no external resource dependency (connection pool, JMS queue, etc..), the IPS package can simply place the artifact in the autodeploy directory of a domain. As stated above the issue is that there is no guaranty that domain1 exists. One approach is to create IPS packages with a dependency on another IPS package responsible for creating a generic "updatecenter" domain (name TBD) thus installing that package/domain if it's not already there. This would also avoid each application shipping with its own domain causing unnecessary space to be used, additional admin tasks to manage the domains, and potential port conflicts. Notable exceptions would be packages requiring considerable setup of the domain (specific jvm options, data-sources or other resources pre-configured, etc.). In this case, shipping the application with a pre-configured domain actually makes more sense.

With the approach of placing the application in the updatecenter/autodeploy directory, removing the package will delete the archive from the autodeploy directory and thus cause the application to be undeployed. Removing the "updatecenter" package will cause the applications depending on it to be no longer available as the domain directory would be deleted. Ideally the domain needs to be stopped first.

3/ Applications independent of GlassFish
Applications running in a separate process can be installed as top level directories and thus be quite independent from the GlassFish v3 runtime bits. Sample packages include monitoring applications, tools, databases, etc. In this case, laying out files at the root of the target/stage staging area will result in a top level install sitting next to GlassFish, similar to JavaDB in the current GlassFish v3 builds. Such a tool can then reference the glassfish v3 install using ../glassfish. You may also want to add binaries to glassfish/bin referencing your application or tool. In the case of JavaDB, there is even an additional ../glassfish/bin/asadmin command (start-database) and that takes us to the next type of GlassFish packages: extensions to the runtime and admin tools.

4/ GlassFish extensions (HK2/OSGi components)
Being modular in its own right, GlassFish supports placing JAR files under the glassfish/modules directory. Of course the artifacts placed there need to adhere to certain rules fairly well documented in the Add-On Component Development Guide (especially the "Writing HK2 Components" and "Adding Container Capabilities" sections). Note you can also extend the admin console, the CLI, and add monitoring capabilities. All of these tasks are quite orthogonal to the (rather lightweight) effort of producing the actual IP package placing the artifacts into the GlassFish modules directory (check the above "Frameworks and libraries" section for how to drop files into a specific directory).

A word on (post-)install scripts
As you can see in the discussion above, it's all about laying out files on disk. GlassFish/IPS packages cannot start/stop processes or run scripts during or after time install by default (if you really need pre/post actions, read this and this). Of course you can (and are actually encouraged) to provide instructions in the package description (in the prototype file), a README.txt file that remains on disk after install, and possibly scripts to be manually executed after the install (to pass some asadmin commands) or prior to some uninstall (like stopping a domain). Remember though that factory configs are best (albeit not always possible).

You should note that the above are merely suggestions for how to build packages for GlassFish v3, not quite best practices at this point, so we're more than happy receiving feedback and suggestions! As you can see the spectrum of packages for GlassFish can be quite large.

There should be at least two more part to this series: how to get your package into the public contrib/ repository and a more complex package example requiring a domain (and thus a dependency on another IPS package).

vendredi avr. 11, 2008

GlassFish un-conference on May 4th 2008 (Pre-JavaOne)

I've sent the following to the "advocacy" alias of the GlassFish community, but thought people could also read and comment here:

Hi all,
We're lucky to have access to a room in the Moscone Center on the Sunday before CommunityOne/JavaOne (May 4th) and would like to take this opportunity to run an un-conference with the GlassFish community.

I'd love to get your feedback on our current thinking:
- Parallel sessions with content based on the people who show up and their interest
- Sessions are discussions much more than they are formal presentations but we do need a leader for each
- My job would be to track/secure at minimum set of people able to run such sessions.
- Event starting around (no earlier than) 3pm
- Total event time would about 3 hours starting with a 30-minute agenda planning session.
- Potential topics based on early discussion and people who've said to be likely in town on the Sunday:
    - scaling & clustering techniques (different approaches, real-life usage)
    - making money with GlassFish, how can Sun help (partner program, co-marketing, ...)
    - teaching Java EE 5 with GlassFish
    - packaging technologies (which one to use when)
    - real-life GlassFish experiences
    - dynamic languages for GlassFish v2, v3
    - GlassFish v3 architecture
    - community and GAP (how to grow the community, status on GAP)
    - performance
    - JSF, Ajax, Web 2.0 marketplace
    - [your choice here]
- The number of // tracks would depend on the number of people showing up (no point in having 2-people session).
- One-hour session should probably be the default

Some technical details/constraints :
- Room set up with a bunch of round tables
- Power and network connectivity provided
- No beamer/projector

If there's enough interest, we could also try to have a "GlassFish porting fest" with people working/hacking on GlassFish and their application throughout the event in a dedicated part of the room

PS: I hear talks about a party at the end of that day (Sunday), but this may just be rumors ;)

jeudi mars 08, 2007

Réunion d'un groupe d'utilisateurs GlassFish Community le 21 mars 2007

Dans le cadre des Sun Tech Days à Paris dans deux semaines, nous aurons quelques événements supplémentaires (pas encore annoncées dans l'agenda).

En particulier, ce sera l'occasion de tenir un premier GlassFish User Group (GUG?) le Mercredi 21 Mars 2007 de 11h00 à 13h00 dont voici un agenda préliminaire:

- "Vous avez dit Communauté GlassFish?" - Alexis Moussine-Pouchkine
- "OpenDS, l'annuaire LDAP Java de prochaine génération" - Ludovic Poitou, David Ely
- "Les conditions du succès pour un GlassFish hébergé" - Jean-Baptiste Bugeau
- "Outillage Eclipse pour GlassFish" - Ludovic Champenois
- "GlassFish v3, un coup d'oeil sur le futur serveur d'application modulaire" - Alexis Moussine-Pouchkine
- Fin et déjeuner de discussions - Tous

Cette session est ouverte à tous. Il suffit d'être inscrit aux Tech Days (gratuit) pour participer à cette session.

Community Events @ Paris Tech Days

As part of the upcoming Sun Tech Days in Paris, we'll have the following community ancillary events on Wednesday 21st (they have yet to be added to the official agenda):

- FOSSDay with Silicon Sentier featuring a round-table discussing (in French) the merits of having languages run on a virtual machine for the Web 2.0 future ahead of us. There'll be speakers for Ruby, JavaScript/ActionScript, Java, Groovy, PHP, and Python.

- OSSGTP (Open Source Get Together Paris) session with Groovy, XWiki, Exo, and Nuxeo leaders discussing their projects and experience to show the value of both using and contributing to Open Source.

- GlassFish Community User Group with a preliminary agenda featuring: a quick recap on GlassFish v2 and presentation of GlassFish v3, a OpenDS (next-generation LDAP server) update by the engineering team, a "What GlassFish needs to be successful in Hosting environments" presentation by community member Jean-Baptiste Bugeaud, and (yet to be confirmed) some OpenSSO/OpenFM (federation) coverage. The goal is to have a fast-paced short format with breaking the opportunity to continue the discussion during lunch.

See you there!


This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« avril 2014

No bookmarks in folder


No bookmarks in folder