Using HTTP-based Subversion Repository for Local Maven 2 Repository

Maven 2 repository could be exposed to public using several protocols. The protocol will be reflected by how we access the repository. The popular ones are HTTP, HTTPS, Subversion, and of course direct file system access which should be reflected by URIs:

• http://repo1.maven.org/maven2
  
• https://localmaven.jugi.or.id
  
• svn://kutukupret
  
• file:///opt/maven2/repo
  

Subversion which is a source code management (SCM) software could also be exposed to public through HTTP/HTTPS protocol. 

Because most developers should have at least read only access to the source code base of the SCM software, any SCM software that is exposed through HTTP/HTTPS protocol could be easily tuned to be Maven 2 local repository as well. I will show the way to use SCM as Maven 2 repository using Subversion  but the principles will apply to any HTTP/HTTPS based SCMs.

Here is how we do it.

When you look to Maven 2 repositories such as http://repo1.maven.org/maven2, the structure is quite simple.

Grab the example the resource specified in this URL: 

http://repo1.maven.org/maven2/org/apache/openjpa/openjpa/1.2.0/openjpa-1.2.0.jar 

We need to break down this URL into these fields:

• artifactId: openjpa
• groupId: org.apache.openjpa
• version: 1.2.0
• Maven 2 repository root URL: http://repo1.maven.org/maven2/

First Step on JDeveloper 11g TP4

Oracle has launched the Technology Preview 4 of the JDeveloper 11g IDE suite.

This version requires JDK 1.5.0 and only guaranteed to work on JDK 1.5.0. It supports and encourage developer to use Servlet 2.5 API, the latest specification of Java Servlet.

I downloaded the JDeveloper 11g Technical Preview 4 from here, and see what's we have in this latest preview version. Click "Accept" if you agree with the terms and conditions.

I will be using the "Base Install" version, which ship without the JDK.

Download and unzip the files to folder of your choice. Mine is [d:\opt\env\jdevstudiobase1111].

Execute the file [jdeveloper.exe].

Select the "Default Role" here. Click "OK" button.

I was using the JDK 1.5.0_13 but the system still prompted me this (it's a tech preview anyway - this 'feature' is not guaranteed to be available on the release version). Just click on the "Yes" button.

I just want to associate JDeveloper Workspace and JDeveloper Project with this tool.

Click "OK" button.

Here it goes, the Oracle JDeveloper 11g Technology Preview 4!

On Migration Problem from WebLogic 8.1 to 10.0

Somebody posted a question on an old entry of my blog, asking about the problem they have when migrating from WebLogic 8.1 to WebLogic 10.0. I pasted the question that was asked so that everyone could easily referred to it.

In order to be able to answer to your question I need more specific things:

• What kind of WebLogic project are you using (is it a WebLogic Workflow Project or plain J2EE application), it will help me to identify what kind of 'compiling' is going on


• If what BEA support asserted is correct (it was merely caused by the Sun JDK bug with zip file), you have an option to migrate to use the JRockIt! virtual machine instead; you have an option to set your JVM to JRockIt! when you are setting your domain

In the past, WebLogic Server is known only to work on certain version of Sun JDK which usually is not the latest one (may contain bugs that has already been fixed in the later version). I found out that the later version of WebLogic Server such as 10.x seems to be more compatible with the Sun JDK; means I have successfully run WebLogic Server on  the  latest version of JDK 1.6.0 which was not the case with 8.1 and 9.2 version.

On the later version such as 10.x, BEA (now Oracle) suggested to use JRockIt! JVM even for development. Previously BEA suggested to use Sun JDK for development and only use JRockIt! on production.

Using Sun JVM  you will experience java.lang.OutOfMemory caused by PermGenSpace is full (this is a normal and expected behavior), but you will have much faster deployment cycle (JRockIt! needs to precompile to native binaries for every things that are deployed, while Sun JVM only compiles to native part that is used often).

I guess that your problem happens while you are compiling EJB using the WebLogic Workshop IDE?

Anonymous said...

Hi,
I am trying to get information about Weblogic 10.0. 
So far, we have had a very hard time trying to migrate from Weblogic 8.1 to Weblogic 10.0. 
Do you know of anybody with experience on doing this migration? What type of problems did they found and how they got resolved?

We keep having OutOfMemory Exceptions when compiling EJBs...and servers not even start. We migrated from 8.1 all applications using Weblogic's domain upgrade utility. The configuration is preserved, and the applications are deployed, but when it tries to start, it is not able to do it. If it starts then it keeps finding OutOfMemory exceptions.

I am told from BEA support that this is caused by SUN JDK bug with zip files... What are my options?

 

 

 

 

Reiterate JavaFX Again

Today our servers being physically transported to the new office site. Initially I planned to fix things before leaving to Bangkok, but the moving coincide with my planned date. 

So today I spend my half day in the morning exploring JavaFx again.

I went back to my NetBeans 6.1 installation which is a bit dusty because I haven't touched it for a such long time.

I followed the JavaFX Clock application step by step and it works as advertised. For a Java developer the learning curve for JavaFX is not steep. Even considering the vast number of open source Java libraries lying around, it is an advantage!

I still am able to use the whole java.lang.* while using the javafx.application.* packages.

Before using the NetBeans version, I followed the Chuk Mun Lee's tutorial on the recent Sun Developers' Network 2008, which was using JavaFXPad. JavaFXPad is ok, only the code formatting and cut-and-paste feature is pretty much limiting. NetBeans has much better support as an IDE, you could even start to develop your JavaFX application.

Learn Java from Scratch

Yesterday I talked with a freshman from one of the local (Singapore) private university. Now he starts learning Java language. The curriculum required him to learn Java very fast with the small amount of introductory material. It translate to he has to do considerable amount of individual unsupervised work.

It good though that the university requires him to learn the Java language the hard way. Use text editor only and command line.

Next after they learn Object Oriented Application Development, they will be allowed to use sophisticated commercial development tools, such as IntelliJ IDEA which is available at his campus.

I still believe and support the idea that a better fundamental will be shaped when students learn Java the hard way, that is start from the command line compiler and the command line JVM invocation.

ItsNat: Java based Comet framework

Java based framework that supports Comet out of the box are out there right now. At least we have 3 now: Dojo, IceFaces, and now ItsNat!

http://itsnat.sourceforge.net/

It is dual licensed, GNU Affero GPL v3 or commercial license for closed source project.

This framework has it's own client/server both at the browser. The server communicate with the Java server, and the server communicates with the client side.