Groovy Users Group First Meetup Tomorrow!

The first meetup of the Groovy Users Group will be held tomorrow 7pm at the Orange and Bronze office in Makati.

Topics to be presented:

1. Intro to Groovy by Michael Mallete
2. Grails + Acegi walkthrough by Melvin Dave Vivas

For more details, visit groups.google.com/group/philippine-groovy-users/browse_thread/thread/a835c5c84b6f9679

See you there!

Posted on Jul 13.08 by oching.    Add a Comment.   

Maven @ the POSS

 Last June 23-24, the Philippine Open Source Summit (POSS) was held in Cebu and I got to do a technical session about Maven. For those who didn’t get to attend, here’s a short summary of what was presented and discussed in the session =) 

1. What is Maven?
   • It is a software project management and comprehension tool that can manage a project’s build, reporting and documentation from a central piece of information.
2. Before Maven was around you need to..
   • Compile your project (dependencies, source classes)
   • Package your project
   • Test your project
   • Document your project
   • Deploy/publish your project
3. Life with Maven.. Maven does it ALL!
   • Building a project with Maven is demonstrated (from compiling your project up to deployment), showing the Maven build life cycle.
   • A diagram of how Maven works
   • 
4. Definition of Terms:
   • Repository (remote and local) - where artifacts are contained
   • Artifact - a jar, war, ear, zip, tar, etc. file
   • POM (Project Object Model) - the central piece of information; xml configuration file where all info (build, reporting, resources, etc.) regarding the project is located
   • Dependency - an artifact which is needed by your project in order to build or run it
   • Build - steps for preparing your project for deployment (compile, test, package, deploy, etc.)
5. The Power of Maven (reference: maven.apache.org/maven-features.html)
   • Simple project setup that follows best practices
   • Consistent usage across all projects means no ramp up time for new developers coming onto a project
   • Superior dependency management
   • Support for multi-module projects
   • Extensible (you can create your own plugins!)
   • Coherent site of project information
   • Release management and distribution publication
6. Related Tools:
   • Apache Archiva – Build Artifact Repository Manager
   • Apache Continuum – Continuous Integration Server
7. Features of Archiva:
   • can be used as proxy cache of artifacts
   • manage repositories (deploy/upload artifacts, search, cleanup)
   • provides reports (repository health)
   • security (for your repositories)
8. Features of Continuum:
   • scheduled builds (m2, m1, ant and shell projects)
   • build notification (mail, irc, IM clients)
   • has support for build environments
   • web UI for releasing a project
   • security (across project groups)
9. Resources:
   • Maven website - maven.apache.org
   • Books on Maven:
     • Better Builds With Maven - repo.exist.com/dist/maestro/
     • Maven: The Definitive Guide -  www.sonatype.com/book/#
   • Archiva website - archiva.apache.org
   • Continuum website - continuum.apache.org

Posted on Jul 04.08 by oching.    Add a Comment.   

Interested in Open Source Software Development? Here’s How You Can Get Involved..

Below are some pointers which I think can be a starting point for people who want to get involved or contribute in open source software development These are just based on my personal experience and nothing formal.. 

1. The usual jumping point here are those technologies that you’re already using. There might be a bug or a feature you want fixed or added, or you’re just basically interested in the project.

2. Start reading the project documentation. This is available on the project’s site or wiki.

3. Subscribe to the project’s mailing lists and start reading up on the discussions happening. You could also join the official IRC channel of the project and be able to see what’s happening there. Don’t be intimidated in participating in discussions, the community would value your opinion

3. Checkout the source code, browse through it and familiarize yourself.

4. Take a look at the issues in the project’s bug tracking system and look for things which you’d like to work on. Don’t be afraid to ask for directions or help in the dev list if you’re working on a bug fix. And if you’re working on a new feature for the project, make sure to involve the community in your design. You could do this  by starting a thread in the developer’s mailing list. 

5. Implement the fix or design of the feature that was agreed on between you and the community in #4 (Don’t forget to write unit tests!).

6. After you’ve finished the fix, create a patch and submit it (may be by attaching it to the issue or mailing it to the dev list). 

**Note: Be aware of the guidelines and conventions of the community regarding patches. These are usually listed on the project site.

7. Notify the dev list that you have submitted a patch for the issue so that they could apply it.

8. Get involved continuously. 

That’s about it  Looking forward to seeing more contributors in the open source community!

Posted on May 15.08 by oching.    3 Comments.   

IP in Opensource - a Case Study

Last Thursday, I was given the opportunity to do and present a case study on Intellectual Property (IP) in Opensource for the PSIA — Philippine Software Industry Association. My subject was the Apache Software Foundation. I thought I’d give a summary of my presentation here.. enjoy! ;-)  (I’d also like to take this opportunity to thank Mykol and my Exist family for all their support at the PSIA event Cheers to everyone!)

What is the ASF?

"We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users" –that is the motto of the ASF. The Apache Software Foundation is a 501(c)3 non-profit and community-centric entity whose aim is to be the ideal environment in the development of open source projects.

Short History of the ASF

Everything started with the HTTPD server, when its users started patching and fixing the server after the original developers lost interest in the project. They’ve setup a mailing list where they conducted their discussions regarding issues that they are encountering in the project. After some time, other users also began participating in the list and were contributing fixes and patches. These group of users called themselves the Apache Group, with the term Apache coming from the Apache tribe of the Native American Indians which were known for their superior skills in warfare strategy. As time went by, the group began hosting other projects and the need for a more formal and legal entity became obvious. Thus, in 1999 the ASF was born.

The ASF Structure

The ASF structure is divided into two sections — the administrative side and the development side. The administrative side is focused on the overall welfare of the foundation, while the development side is more focused on the welfare of their respective projects in the foundation. The administrative side are the board, the officers and the members of the ASF. The development side is composed of the PMC members, the committers, the contributors and the users.

ASF Licensing

1. Distribution Licenses
   • Apache License 1.0 - specifies that the copyright text and the conditions list must be retained or indicated in each file of the project. It should also be acknowledged in the documentation and advertising materials that the the project uses an ASF license. It also restricts the project or product from using the term ‘Apache’ in its name.
   • Apache License 1.1 - is the same as version 1.0, except that it is no longer required to attribute in their advertising materials that the project is using an ASF license.
   • Apache License 2.0 - revised and more detailed version of 1.1. With 2.0 though, it is no longer required that the copyright licenses and conditions list be specified in each file, but instead just have them referenced so as to prevent alterations or modifications in existing sources. It also aims to move comments regarding Apache and other inherited attribution licenses to a Notice file.
   • The ASF also has this rule that all projects under the ASF license cannot include a library that has a more restrictive license than the ASF license in the project distributions. We had this issue in Apache Archiva a couple of months ago. The project is using jasper reports which has a more restrictive license than the ASF license therefore we couldn’t include that in the distribution. What the project team did was to just give out instructions to the users on how to build the project from source if they want to use that reporting api with Archiva. Another workaround the team has been considering was switching to an ASF licensed api instead.
2. Contributor License Agreement (CLAs)
   • Individual CLA. This is the agreement for an individual contributor, meaning the contributor gives the foundation permission to distribute their contributions, modify it or add something to it.
   • Corporate CLA. This covers the whole company. For example, a company has a set of developers whose working on an open source project in the foundation. This agreement assures the foundation that the company’s developers has the company’s permission to contribute their code to the community. Each of these developers must also have an individual CLA, aside from the corporate CLA.
3. Software Grants
   • This is the agreement when a company donates software to the ASF. It just means that a company is giving the ASF permission to redistribute the software, modify it, add new features to it, etc. One good example of this is the OpenJPA, which was donated by BEA to the foundation in 2006 and has officially became a top level project in 2007.

Open Source Software Licenses

Here are a couple of open source software licenses that are commonly used:

1. Apache Licenses. Code can be redistributed, modified, changed or charge a fee for these changes. You just have to acknowledge that you’re using an ASF licensed project and retain or reproduce the copyright notices and conditions list if redistributing the project.
2. BSD (Berkeley Software Distribution). This has the same conditions as the Apache License, just different in wordings. You have to acknowledge that you’re using a BSD licensed project and retain or reproduce the copyright notices if redistributing a BSD licensed project.
3. EPL/MPL (Eclipse Plugin Licenses/Mozilla Plugin Licenses). A project under an EPL can be redistributed, modified and changed, but the part which is covered by the EPL must be retained under an EPL license. Only the parts that have been changed or added can be applied under a different license. A project under MPL, on the other hand, must always be under MPL even those parts that you’ve modified or added.
4. GPL and LGPL (General Public License and Lesser GPL). A project under the GPL can be re-distributed, modified or you could even charge fees for the modifications but you have to keep everything open sourced. This means that it cannot be used in proprietary software because you cannot close source it. A LGPL licensed project, on the other hand, can be used in proprietary software, meaning it’s for proprietary developers.

For more details about the above licenses and the other open source software licenses, please visit opensource.org/licenses

Leveraging Open Source Software

Below are some of the rewards and obstacles that I’ve personally experienced while doing open source development work

Rewards:

• Wide variety of people involved. People from all over the world are involved in the community, so there are lots of different ideas, opinions and approaches on how to tackle things. Everyone is willing to give and share their opinions and suggestions specially on critical things that would affect the project.
• Quality of code. As mentioned in the previous point, there are a wide variety of people involved therefore there are more sets of eyes that looks out for the quality of code. Aside from this, since it’s open source and everyone can see your code.. some developers tend to be more careful or meticulous in their coding.
• More people can pitch in the development. Everyone in the community is ready to lend a helping hand. Just ask, and people will be happy to give their feedback and if you have a blocker that’s preventing you from moving forward to what you’re doing, the community is there to help out.
• Driving the development in the community. When a private company develops a certain feature of the project and donates or contributes it back to the community, it benefits both the community and the company.

Obstacles:

• Scheduling the roadmap. The community has their own roadmap schedule and a company developing a product from that open source project also has their own set of scheduled deliverables to their clients. It’s hard reconciling these schedules since open source projects are not really time-boxed. The project gets released whenever it is ready to be released, while a commercial product is time-boxed and has a client waiting for deliverables of the product.
• In community vs. what the client wants. Since the community has it’s own roadmap and the client has their own set of deliverables that they are expecting, it’s hard to reconcile what gets included in the actual deliverables. Of course, what the client needs is still the priority so what can happen is a compromise to the client that not everything listed in the community roadmap might be included given their required deliverables and the time restriction.
• Technology used. It’s the community that decides what technologies to be used in the project. So if you’re building a commercial product from that open source software, you don’t have much control over what technologies to use. You could make suggestions in the community, but it’s still the community which makes the decision.

Some Real Life Examples

• MySql - MySql
• Jboss - Jboss
• Redhat - Redhat
• Gluecode - Gluecode Joe (Geronimo/Jetty/Jasper/ActiveMQ/Pluto/Derby)
• LogicBlaze - ActiveMQ/Service Mix
• Maestro - Maven/Continuum/Archiva/Redback
• q4e - Eclipse IDE for Maven

Posted on Apr 28.08 by oching.    2 Comments.   

Tinkering Around with Elgg..

A few weeks back, our company started using a new application called Elgg. Elgg  is an open source social platform aimed to provide an environment for interaction and collaboration amongst individuals. It has some nice features like: blogging, file repositories, RSS support, podcast support and of course, social networking. What I liked most about it is its "Community" feature, where in users can create communities (complete with interaction tools like blogs, forums, etc.) and people of the same interest can discuss in that space. This is especially useful in our case, since we’re in the software dev’t industry where discussions are always bound to happen. Another neat feature Elgg has is that it’s pluggable. Anyone can develop a new plugin which can be used within the application. These are a couple of the interesting plugins that are already available:

• Google Search
• Chat Integration (PhpFreeChat)
• Twitter Integration
• OpenID Client
• Captcha
• Upcoming Events
• Draft Posts

I found the last plugin really handy. This was one of the things I found lacking when I first tried out Elgg. For the complete list of available plugins, just visit their site: elgg.org/

There are also some things that I think can still be improved though..

1. The "Invites" feature — it would be nice to be able to send multiple invites instead of having to click ‘Invite’ for each person you’d like to invite.
2. A user can have no username and Name defined, therefore when you look at the list of users.. there are people w/o names and you won’t know who they are.
3. Its a little hard to navigate around. Its hard to find where to set the FullName (its in Account Settings, wherein you’d first think that it is in the Your Profile page).

Anyway, these are just some of my thoughts.. Still got to play with it more =)

Posted on Feb 20.08 by oching.    Add a Comment.   

Archiva 1.0.1 Released!

Archiva 1.0.1 has just been released!

JPOX was upgraded from 1.1.7 to 1.1.9. Other changes for this release include an improvement for maven 1 artifact resolution, validation in the legacy artifact mapping form and revisions in the documentation.

To download, visit http://maven.apache.org/archiva 

Short background on Archiva:

Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It has features like repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. Aside from these, it can also act as a nearby (proxy) cache of popular global repositories.

Posted on Feb 04.08 by oching.    3 Comments.   

Archiva’s Big 1.0!

After two years of hard work from the Maven Archiva team, Archiva 1.0 is finally out (with a cool new site to boot) =) It’s now readily available here:

maven.apache.org/archiva/

Cheers to everyone! =)

Posted on Nov 27.07 by oching.    7 Comments.   

The Hype About Repository Managers

Repositories have become an essential part of software development nowadays. Great importance are being given to the use of repositories, and because of this, a lot of open source tools for managing them are now available. As an Archiva developer, I wanted to compare the features that each has (even if I may be biased).

Archiva

Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It can act as a nearby (proxy) cache of popular global repositories. It has other features such as repository purge (of snapshots), repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. The version I’ve used here is 1.0-beta-3. Below are the features of Archiva:

• Easy to run. Just unpack the binaries, cd to /bin/linux-x86-32 and execute ‘run.sh console’ (the last two steps depends on the OS you’re using). You could also opt to just execute ‘plexus.sh’ or ‘plexus.bat’ in /bin.

• Proxy and cache. Allows hosting of private repositories (managed) and proxying of other repositories (remote). Proxying is one of the major features of Archiva. It makes use of the concept of proxy connectors. Proxy connectors are configuration for connecting a managed repository to proxy a remote repository. Archiva allows proxy configuration of blacklist and whitelist patterns as well as download policies.

• Repository configuration. Configuration is stored in the archiva.xml file. The configuration can be edited via the webapp. Items which are configurable are: repositories, repository scanning, database scanning, proxy connectors, network proxies and consumers. Remote and managed (local) repositories have separate configurations so it is easy to identify one from the other. Repository scanning, where indexing and repository purging happens, can be executed per repository. This can be scheduled or explicitly triggered in the Configuration page.

• Repository purge. If enabled, Archiva performs automatic removal or deletion of old snapshots in the repositories during repository scanning. You can choose from these 2 criteria: either by the number of days old or by retention count. Deletion of released snapshots can also be enabled by checking the ‘Delete Released Snaphots’ checkbox in the repository configuration page.

• Reports. Archiva uses Jasper Reports for reporting. The reporting is currently limited to a report of defective or problematic artifacts in the repositories. You can configure the number of rows per page to be displayed in the report.

• Search and repository browse. You can search artifacts in Archiva as well as browse the repository. The bad side about this is there is no separation among the different repositories. All the artifacts are in the Browse page. The good side is that the artifact info is very informative and useful, which I think definitely compensates the bad side. You could browse each repository anyway via the webdav. A webdav url is available in the repository configuration page which you can just click and be able to browse that repo in the web browser. The artifacts can also be downloaded, though it cannot be deleted via the Repository Browse.

• Finding artifacts. You can find artifacts in the repository via the checksums. You can either input the checksum manually OR browse for the unknown artifact itself and Archiva will calculate its checksum and search for it in the repo.

• User interface. Archiva uses Webwork for the user interface. The UI is simple and organized, though load time of pages could still be improved.

• Deploying artifacts. Archiva has support for artifact deployment via webdav.

• Source code. The source code is designed very well. The modules are properly organized into components, which makes it easy to plug new features as well as to disable one. Below is Archiva’s source structure:
  • archiva-base - contains the core modules of Archiva, which are the configuration, model, converters, repositories, indexing, proxies, policies and utility modules.
  • archiva-cli
  • archiva-database - the module which deals with the database processes.
  • archiva-reporting - the module for Archiva’s reporting mechanism.
  • archiva-scheduled - the module which handles the scheduling and execution of specific tasks.
  • archiva-site - contains the information for Archiva’s web site.
  • archiva-web - contains the modules for the web component.

Artifactory

According to its website, Artifactory is a Maven 2 enterprise repository which offers advanced proxying, caching and security facilities to provide for a robust, reproducible and independent build environment using Maven 2. The version I used for this comparison is 1.2.2. Below are the features of Artifactory:

• Easy to run. Artifactory includes an embedded Jetty server in its binaries, so the user can opt to use the embedded server instead of deploying it to a different application server. The only thing I can see that may be a hassle is that you still needs to set the ARTIFACTORY_HOME environment variable. If you don’t set it, there’ll be problems starting up the server and you won’t even know what is wrong unless you read the documentation.

• Repository configuration. Currently, there is no user interface for configuration. In order to add a repository, you need to add a <localRepository> entry in the artifactory.config.xml file itself and restart Artifactory. It has a feature for importing a repository from a local file system into a local repository in Artifactory. Having no UI for the configuration, you need to have access to the configuration file to know whether the Artifactory repository (where you want to import the artifacts) supports snapshots or releases only, or both. For example, I tried importing a repository containing both snapshots and released artifacts into the default Artifactory repository ‘libs-releases’ and I couldn’t get past importing the repository only to find out that snapshots are not handled in that repo by looking at the config file. A plus for the repository import mechanism is that it has validation checks for the repository paths, you cannot import a repository which has a problem.

• Proxy and cache. The proxying was easy to configure and easy to use. Just set the repositories you want to use in your settings.xml file and it would proxy the remote repositories you’ve set in Artifactory.

• Search and repository browse. Good separation of repositories in the browse. Fast too The artifacts can be downloaded and removed from the repo via the Repository Browse.

• User interface. Artifactory leverages AJAX for it’s user interface, resulting to faster loading of pages. It also has a nice look and feel in comparison with the other repository managers.

• Deploying artifacts. Artifacts can be deployed in an Artifactory repository via the UI.

• Source code. The codebase is small, but not very well-structured. I tried building the source and I couldn’t build it because of some dependencies not being found (tried the profiles but still couldn’t build it). Below is its source structure:
  • core - contains all the core classes such as the proxying, caching, security, scheduling, configuration, search, utility classes, etc.
  • site
  • standalone - the standalone application module (where binary files are assembled)
  • wagon - contains only a class (specific implementation of HttpWagon)
  • webapp - the web app component

DSMP (Dead Simple Maven Proxy)

DSMP is simply just a proxy. As excerpted from its site, it can be used as a repository server but it’s main purpose is to act as a filter when Maven accesses the internet. The version I used here is 1.1.

• Easy to run. A shell script ‘dsmp.sh’ is included in the bundle. But in order to execute the script, you need to update it and set the DSMP_HOME variable to the DSMP installation.

• Proxy. Just redirects request to a proxy repository (thus the name). DSMP does not support hosting a proxy repository. Redirection of proxies can be set through this configuration:

             <redirect from="[PROXIED REPO URL]" to="[PROXY REPO URL]"/>
   
              ex.

<redirect from="http://m2.safehaus.org/org/aopalliance" to="http://maven.sateh.com/maven2/aopalliance" />

• Configuration. The configuration is simple — configuration related to proxies only. In addition to the proxy configuration mentioned above, there is also the concept of "allow" and "deny". Downloading of specific artifacts can be controlled by specifying the URLs or paths which can or cannot be downloaded from a repository. Network proxies can also be set in the configuration if direct connection is not allowed.

• Cache and patches. Caches everything downloaded as well as all failed downloads. DSMP makes use of the concept of patches. It can be configured to look into a specific directory for patches and when it sees a patch for the artifact then it would use that instead of the cached one. Failed downloads are kept in status files, so when DSMP sees these files it would no longer attempt to download the artifact.

• Source code. Very small codebase, a single-module project.

Proximity

Proximity is a Maven proxy for company-wide use. From its website, it is described as basically a "fetch-and-cache engine with various extra capabilities like indexing". The version I’ve used here is 1.0.0-RC9. Below are the features of Proximity:

• Easy to run. Deploying and running the war bundle was easy to do. But this was a little different with the jetty bundle. It would be better if it was specified in the documentation for deploying proximity that JETTY_HOME needs to be set before starting it up. I assumed that all that was needed to run proximity is just to unpack the bundle then start it up by executing the shell script ‘jetty.sh’ included (as specified in the website docs). I also encountered a problem with starting up the jetty bundle, a directory was missing ([PROXIMITY]/bin/logs) so the application couldn’t successfully start up. Manually creating the directory solves the the problem.

• Proxy and cache. The proxying works nicely. What I liked about the proxy feature in Proximity is the repository grouping. Proxy repositories which has the same group ids (for example, group id is ‘public’) are grouped together. This group of repositories can be accessed via a specific URLhttp://localhost:8080/proximity/repository/[GROUP ID] (so it would be http://localhost:8080/proximity/repository/public from the example). You could use this group repository URL in your settings.xml file to tell Maven to download from this group of repositories instead of having to specify each repository URL.

• Repository configuration. Very complex way of configuring repositories, you need to update an xml file and a properties file just to add a new repository.

• Reports/Statistics. Proximity keeps track of the following statistics during run-time (in memory): last 10 served artifacts, where the last 10 requests came from, last 10 local hits, last 10 remote hits, last 10 deployments and where they came from.

• Search and Repository Browse. There are two ways to browse a repository — one is via Browse Artifacts and the other one is via Browse Files. In the Browse Artifacts page, the artifacts are not divided by repository but there are ‘Group’ and ‘Origin’ identifiers to indicate which repository the artifact came from. On the other hand, the artifacts are grouped by repository in the Browse Files page. Specific details such as the directory/file size, md5 and sha1 checksums and URLs are displayed via tool tips when browsing. You can search an artifact across all repositories, by repository or by repository group. There is also a search using Lucene specific queries, examples for this type of queries are available in Proximity’s Search page.

• User interface. The user interface needs more improvement especially the repositories page. It looks a little too crowded and confusing — there’s no separation between the hosted and proxied repositories, only a header of ‘Hosted repository’ or ‘Proxied repository’ identifies which is which.

• Deploying artifacts. Proximity has support for artifact deployment via webdav.

• Maintenance. There are two tasks that are scheduled to be executed at specific times by proximity: re-indexing and repository purge. The actual code for purging the repositories is not yet implemented though. You could see these tasks via the Maintenance page. There is also an option for running re-indexing on a specific repository only (but this is only manually triggered, not scheduled).

• Web services. Services for re-indexing and search.

• Source code. Proximity heavily uses IoC which makes it easy to configure and to plug/unplug components. Below is Proximity’s source structure:
  • px-core - the core module
  • px-core-it - contains integration tests for the core module
  • px-core-maven - contains maven specific functionality
  • px-core-scheduler - contains the task scheduler
  • px-core-ws - module for web services
  • px-webapp-base - contains web controller and utlity classes used by the different webapp ‘flavours’
  • px-webapp-base-it - contains integration tests for the webapp base module
  • px-webapp-default - contains the front-end of the webapp
  • px-webapp-demosite - specific webapp module for the demo site
  • px-webapp-pmaster - specific webapp module for the "master" in Proximity chaining
  • px-webapp-pslave - specific webapp module for the "slave" in Proximity chaining
  • px-webapp-webdav - webdav extension

Features Matrix Comparison

Conclusion

From the matrix above, you can see the differences among these applications and deciding on which one to use really depends on your needs. But setting aside my being an Archiva developer, I think I would still go with Archiva after having tried all of them. With the exception of web services it matches the features of all the others and has a number of features unique to itself, while at the same time it remains one of the easiest to use and has recently become much more stable - so we’re really excited for the 1.0 release this month

Posted on Nov 05.07 by oching.    16 Comments.   

Archiva 1.0 Beta 1.. released!

Finally..

After a few weeks of preparation, we have released Archiva 1.0 Beta 1 (yay! to the Maven Archiva team).  This was the first release I’ve ever done, and what can I say.. it was fun!

There were a lot of preparation on my part (had to generate my key pair and have them signed, then setup configuration for the release, etc.). But thanks to everyone’s help and participation, the release went smoothly and was a success.

The only thing that needs to be improved on was the upload of the jars to the repositories. I think it took me a good three hours or so to deploy them.. and trust me, there were a lot of jars! The problem probably was in the net connection, so my advice is if you’re going to do a release..make sure you’re connection is really fast.

Btw, you can take a peek at Archiva here:
maven.apache.org/archiva/

That’s all folks! ‘Til the next release again.

P.S.
Special thanks to Wendy for her notes and Brett for his real-time help desk =)

Posted on Aug 11.07 by oching.    Add a Comment.   

‘Lami Ah’ Cebu.. / Danggit Bai, Mango Bai,...

    A couple of days ago, a group of us from Exist were sent to Cebu for a training program. I was really excited to go there since I haven’t been to Cebu yet. (Actually what excited me the most was the food.) The city is famous for its delicious food and aside from that, its really really cheap!

And so the day came when we arrived in Cebu..

    Our first stop was the ‘SuToKil‘. This was a restaurant amidst a wet market. You get to choose from the stalls in the market which seafood you want prepared for you and they’ll cook it then and there. There were 3 ways on how they cook fish: SUgba (grilled), TUwa  (soup) and KILaw (pickled in vinegar), thus the name =) We tried all of this and the food was sinfully delicious! I just wanted to stay there and eat all day.. *sigh*
  

   After our pig-out session, we dropped by Shang-ri La Mactan where we checked out the beach. The sand was pristine white and the water was so clear.. you’d be tempted to take a dip even at the middle of the day when the sun is at its hottest. We just shuffled about the hotel perimeter then we’re off to the Plantation Bay.

    The Plantation Bay’s another tourist spot in Cebu were you can stay and relax for a few days. There are lots of activities that you can do there, like swimming, wall climbing, tennis.. and just partying and dancing the night away!

   On our second day, we got to see downtown Cebu. This time we went shopping in the dry market for some pasalubong. Lots of dried fish and other kinds of dried seafood piled high in baskets cluttered the whole street. It was fun choosing which to buy because you have so many choices =)

  We then had our lunch (yeah, food again) at the Golden Cowrie. It’s a restaurant that offers eat-all-you-can rice. They also have a variety of dishes from Cebuano to Filipino and even Bicolano food. I enjoyed the baked scallops that we had here, it was very addictive.

  After the hearty lunch, we stopped by the Exist office in Cebu to do some work for the training the following day and then we went to the mall to buy more pasalubong. We had our dinner there too at Tequila Joe’s (which we also have here in Manila).

  The next day was a Monday and I was scheduled to lecture for the ECC (Exist Code Camp). There were 12 participants in all and one of them has the same name as my former teammate Allan Ramirez =) The students were a friendly bunch and I’m glad that they were all enjoying and learning so much from the ECC training.

  We had our lunch that day on one of the restaurants at the Exist office building. We had some soup and pochero Cebu style. Before, my concept of pochero was just beef with tomatoes.. but after having my pochero in Cebu, it became totally different. Their pochero there was sizzling beef shanks with gravy, which was definitely way better than what I had in mind (*grin*).

  Dinner that night was simple, we just had some ramen (noodles with soup) at one of their Japanese restaurants. It was also good and their servings were really big. We retired early that night to prepare our things because the following day, we’ll be going home.

  We were scheduled to fly back to Manila on Tuesday afternoon, so we still went to the office in the morning for work and more ECC training. Saying goodbye to everyone was sad, but we were also looking forward to going back to Manila..because there’s still no place like home.. =)

Posted on May 24.07 by oching.    Add a Comment.