That's what I found, collected and provided in a cookbook format:
1) Download a fresh copy of Eclipse 3.4 / Ganymede. I've used the EE release, but the others should work, too.
2) Follow this cook book for the subversion part.
3) Install the Maven 2 plugin from this site: http://m2eclipse.sonatype.org/update/
4) Test it with a subversion based project, e.g. my favourite is CAS. m2eclipse is officially supported by that project. However, you have to activate the "Include Modules" property in the project to get rid of initial errors. I've reported this on the CAS mailing list.
13 December 2008
30 November 2008
Java on Ubuntu Server 8.10
Here's some in-a-nutshell information on how to deal with Java on Ubuntu server 8.10:
To find out what's on an Ubuntu system for Java:
$ update-java-alternatives -l
Running
$ java -version
shows that the OpenJRE 6 is installed by default. Aha, it's a JRE. To install and probably run Glassfish, however, you need a JDK. Off we go and install it with:
$ sudo apt-get install sun-java6-jdk
(and get demo, doc, source, too, while you're at it)
Ok, but now, how to make this JDK the default Java on the machine. Some tools are available, fortunately, and without much background research, we make use of them to make the switch:
$ sudo update-java-alternatives -s java-6-sun
Now, calling
$ java -version
shows Sun's java to be active.
Now you can download Glassfish, install and configure it. That's very well documented already.
To find out what's on an Ubuntu system for Java:
$ update-java-alternatives -l
Running
$ java -version
shows that the OpenJRE 6 is installed by default. Aha, it's a JRE. To install and probably run Glassfish, however, you need a JDK. Off we go and install it with:
$ sudo apt-get install sun-java6-jdk
(and get demo, doc, source, too, while you're at it)
Ok, but now, how to make this JDK the default Java on the machine. Some tools are available, fortunately, and without much background research, we make use of them to make the switch:
$ sudo update-java-alternatives -s java-6-sun
Now, calling
$ java -version
shows Sun's java to be active.
Now you can download Glassfish, install and configure it. That's very well documented already.
11 May 2008
Tidy Up, please tidy up here!
I've switched from Windows to Mac OS X about 2 years ago, at least at home, where I have enough influence to change things on a small scale. I've converted my mother's computer from Windows 95 to Mac a couple of years ago. We've upgraded from our PowerBook to the latest MacBook Pro four weeks ago. We have iPods, and soon the touchable version of it. We also own a Nano. We love Apple and the software on it. With one exception: Tidy Up! It's that program that makes me crazy. It's my fourth test run to clean up my iTunes library with it. Everything on a Mac is easy. TidyUp is not. I bought the full version because I believed the reviews in the Internet. That must all be great marketing talk from Hyperbolic Software, because it just does not work for me. It's not Tidy Up, it's Tidy Down!
04 May 2008
Thoughts on Technology Domains
So I have a plan: I want to start categorizing that huge pile of technologies in my company. Where do I start? How should I partition it? What has been done before me? Are there best practices already in the field of technology architecture management?
Separating the vast field of technologies in "buckets" helps to do the following:
Strategies for such domain structure differ between companies. Some might need a rigorous reduction to a small number of products, others might need a larger diversification to make sense to business. And here's the top down approach again - it is finally a call from business to define which domains are important to a company and how those domains need to be organized and managed.
Separating the vast field of technologies in "buckets" helps to do the following:
- Apply ownership and responsibilities to groups of technologies
- Provide a governance framework based on these buckets, to foster standardization, reuse and provide the necessary processes to handle exceptions
- Provide detailed "cost per topic" views (e.g. database technology costs, application server costs, etc.)
- Create the basis for technology lifecycle management (e.g. decommissioning/phasing out of products, moving to new technologies, etc.)
- Base Infrastructure: Server and workplace hardware and operating systems, network components and services
- Database: DBMS, Document Management Sytems
- Middleware: Application servers, workflow and messaging infrastructure
- Workplace: Laptop or desktop platform including hardware, operating system(s), and tools, with a focus on business users
- Application and Service: Buy and inhouse developed applications including internal and external services, including all around integration and software development
- Information Exchange: Most companies of today need a well managed platform to copy data between the applications.
- Business Process & Workflow: Platforms and tools to provide process and workflow management features to either directly to users or to the applications
- Information Exploitation: Platforms and tools to identify added value from our own data. Often, this is integrated in the Database domain
- Security: Mechanisms to protect and properly access applications, services and their data
- Systems Management: Domain crossing tools and platforms to manage Swiss Re's runtime components
Strategies for such domain structure differ between companies. Some might need a rigorous reduction to a small number of products, others might need a larger diversification to make sense to business. And here's the top down approach again - it is finally a call from business to define which domains are important to a company and how those domains need to be organized and managed.
05 April 2008
Mapping Web 2.0 to Enterprises
I've recently read the Web 2.0 article from Tim O'Reilly. I fully agree to everything he writes there, and it is definitely true for the Internet as a whole, I don't have the slightest doubt about that.
In my role as an architect within a large enterprise, I then asked myself: Do these principles hold true in the smaller "Web ecosystems" in companies like mine? Are there scaling effects that make those principles only apply to the large as for the overall Internet? I think that some of the principles still apply, others might not, especially those where the number of users must be large to work. I will now go through the principles and validate this.
1. The Web As (a) Platform
Since around 2000, the Browser got accepted as the main application "delivery channel" for off-the-shelf and inhouse developed applications. The main reason for this, though, was that this kind of application removed the burden of deployment from the IT departments. Deployment was, and still is, a difficult topic, so being able to remove this from the list of problems had high priority. But "The Web As a Platform" principle is a much broader concept. Technically, it is about
Typically, Enterprises today are working on this topic by approaching it via the SOA (Service Oriented Architecture). Because there is potentially more control within an Enterprise, all inhouse developed applications should adhere to the pre-defined API standards. My believe here is, that the more light-weight this technology stack will be, the more successful this approach will be. As a side remark: Don't use an ESB.
2. Harnessing Collective Intelligence
Tim refers here to the following features: Hyperlinking, search, collective content ownership, enrichment content by users. This principle also applies to Enterprise IT.
Easy hyperlinking is key here. It must be easy to pick a link to a content element x and put it into another content element y. Hence, links must be stable, and easy to understand.
Search must be easy to use and it must reveal the expected results. Search must be available in different context that make sense to the different user groups. I.e. a single company wide search returns too broad results. If people want to search on certain contexts, they should be able to.
Now for content, the story might be different in Enterprises. Job descriptions and organizational hierarchies do not forsee something like Wikipedia in Enterprises. Goals in your "Management by Objectives" documents do not foster collective content creation at all. Companies try to optimize their knowhow and their intelligence on the level of who they hire. Cross organizational knowhow exchange is still not widely adopted, often it is not wanted. Here's a need of a change of mind on top management, if they want people to accept that others might enhance and improve their content. In most companies, the employees are asked to focus on their tasks, and they should not "wander around and help others" to improve their work. Otherwise, you just might have missed the right job, and a change might be a good thing.
Blogging is a candidate to replace most internal communication channels in the future. However, Enterprises need to have the "push" model available, so Blogs would need to be configured in a way that the target group gets an e-mail when a new post arrived, if it is about "mandatory" information for everybody. Not very Web 2.0-ish, I guess.
3. Data is the next Intel Inside
Leveraging data is also key within Enterprises. I think that Enterprises do not think about their data as an additional source for Internet based use. The famoust use case for this is connecting your own data with geographical information systems like Google Maps. Tim refers to the example of housingmaps.com. The key question here probably is how to make money out of this? Do you create a B2B solution? Do you create a platform with your data, again providing APIs to others to integrate your data with other use cases? If you provide access to your data for free, adding content-related advertisement to your page.
4. End of the Software Release Cycle
Enterprises will like this one. Hey, no weekend deplyoment nightmares anymore? You're welcome. However, for this to happen within an Enterprise, a lot needs to change first. People are afraid that something breaks outside of their control. APIs are changed, so others that depend on those APIs might fail to run. That's difficult to explain to business users. Deplyoment has to be handled most professionally to be successful. That makes Enterprises get much more involved in IT business than they actually would like to. You need an excellent staff to handle this. You probably won't do this for every single application in your portfolio, but just for the core applications.
5. Lightweight Programming Models
This actually reads like a wish-list of probably most Enterprise's CTOs:
6. Software Above the Level of a Single Device
Tim refers to the example of iTunes. I don't think that this makes sense within a single Enterprise. I guess, only a small number of Enterprises have use cases to provide channels with mixed technologies to the outside world. In a broader sense, I imagine that external facing Web sites and applications will need to be designed to run on different devices in the future. Welcome, all you Black Berries and iPhones, do you want to see our content in a sensible way? Remember WAP? Something like this, only the Web 2.0 style.
7. Rich User Experiences
Business users within Enterprises are used to Gmail, Flickr, YouTube, etc. and they ask themselves, why is our IT folks not able to create applications like these. Internal IT departments are acting on this already, standardizing on one or more AJAX frameworks. However, there is a lot to learn for developers and user interface designers when this technolgoy enters the game. We will see a lot of AJAX-enabled applications that do not improve user experiences.
Summary
Most of the principles apply to Enterprises, too. Most IT departments do not react on this yet, however. Most Web applications are still built old school, and those built with new Web 2.0 technologies look like old school applications with some additional AJAX thrown in. Let's hope for an improvement. And for those who are in the position to change something: Let's try.
In my role as an architect within a large enterprise, I then asked myself: Do these principles hold true in the smaller "Web ecosystems" in companies like mine? Are there scaling effects that make those principles only apply to the large as for the overall Internet? I think that some of the principles still apply, others might not, especially those where the number of users must be large to work. I will now go through the principles and validate this.
1. The Web As (a) Platform
Since around 2000, the Browser got accepted as the main application "delivery channel" for off-the-shelf and inhouse developed applications. The main reason for this, though, was that this kind of application removed the burden of deployment from the IT departments. Deployment was, and still is, a difficult topic, so being able to remove this from the list of problems had high priority. But "The Web As a Platform" principle is a much broader concept. Technically, it is about
- simple, yet powerful protocols
- providing end user applications
- providing and using services (web services in "mashup" and other integration szenarios)
- continuous deployment
Strategic positioning: The Web as a platformTo realize this, this means that inhouse developed applications need to provide their data over an API to others inside the company. Hence, besides the regular user interface URL, the developers should add separate SOAP or REST based URLs to their application, making it possible to integrate with the applications very easily. This can then happen on the server side, or on the client side, via "mashups".
User positioning: You control your own data
Core Competencies:
- Services, not packaged software
- Architecture of participation
- Cost-effective scalability
- Remixable data source and data transformations
- Software above the level of a single device
- Harnessing collective intelligence
Typically, Enterprises today are working on this topic by approaching it via the SOA (Service Oriented Architecture). Because there is potentially more control within an Enterprise, all inhouse developed applications should adhere to the pre-defined API standards. My believe here is, that the more light-weight this technology stack will be, the more successful this approach will be. As a side remark: Don't use an ESB.
2. Harnessing Collective Intelligence
Tim refers here to the following features: Hyperlinking, search, collective content ownership, enrichment content by users. This principle also applies to Enterprise IT.
Easy hyperlinking is key here. It must be easy to pick a link to a content element x and put it into another content element y. Hence, links must be stable, and easy to understand.
Search must be easy to use and it must reveal the expected results. Search must be available in different context that make sense to the different user groups. I.e. a single company wide search returns too broad results. If people want to search on certain contexts, they should be able to.
Now for content, the story might be different in Enterprises. Job descriptions and organizational hierarchies do not forsee something like Wikipedia in Enterprises. Goals in your "Management by Objectives" documents do not foster collective content creation at all. Companies try to optimize their knowhow and their intelligence on the level of who they hire. Cross organizational knowhow exchange is still not widely adopted, often it is not wanted. Here's a need of a change of mind on top management, if they want people to accept that others might enhance and improve their content. In most companies, the employees are asked to focus on their tasks, and they should not "wander around and help others" to improve their work. Otherwise, you just might have missed the right job, and a change might be a good thing.
Blogging is a candidate to replace most internal communication channels in the future. However, Enterprises need to have the "push" model available, so Blogs would need to be configured in a way that the target group gets an e-mail when a new post arrived, if it is about "mandatory" information for everybody. Not very Web 2.0-ish, I guess.
3. Data is the next Intel Inside
Leveraging data is also key within Enterprises. I think that Enterprises do not think about their data as an additional source for Internet based use. The famoust use case for this is connecting your own data with geographical information systems like Google Maps. Tim refers to the example of housingmaps.com. The key question here probably is how to make money out of this? Do you create a B2B solution? Do you create a platform with your data, again providing APIs to others to integrate your data with other use cases? If you provide access to your data for free, adding content-related advertisement to your page.
4. End of the Software Release Cycle
Enterprises will like this one. Hey, no weekend deplyoment nightmares anymore? You're welcome. However, for this to happen within an Enterprise, a lot needs to change first. People are afraid that something breaks outside of their control. APIs are changed, so others that depend on those APIs might fail to run. That's difficult to explain to business users. Deplyoment has to be handled most professionally to be successful. That makes Enterprises get much more involved in IT business than they actually would like to. You need an excellent staff to handle this. You probably won't do this for every single application in your portfolio, but just for the core applications.
5. Lightweight Programming Models
This actually reads like a wish-list of probably most Enterprise's CTOs:
- Support lightweight programming models that allow for loosely coupled systems.
- Think syndication, not coordination.
- Design for "hackability" and remixability
6. Software Above the Level of a Single Device
Tim refers to the example of iTunes. I don't think that this makes sense within a single Enterprise. I guess, only a small number of Enterprises have use cases to provide channels with mixed technologies to the outside world. In a broader sense, I imagine that external facing Web sites and applications will need to be designed to run on different devices in the future. Welcome, all you Black Berries and iPhones, do you want to see our content in a sensible way? Remember WAP? Something like this, only the Web 2.0 style.
7. Rich User Experiences
Business users within Enterprises are used to Gmail, Flickr, YouTube, etc. and they ask themselves, why is our IT folks not able to create applications like these. Internal IT departments are acting on this already, standardizing on one or more AJAX frameworks. However, there is a lot to learn for developers and user interface designers when this technolgoy enters the game. We will see a lot of AJAX-enabled applications that do not improve user experiences.
Summary
Most of the principles apply to Enterprises, too. Most IT departments do not react on this yet, however. Most Web applications are still built old school, and those built with new Web 2.0 technologies look like old school applications with some additional AJAX thrown in. Let's hope for an improvement. And for those who are in the position to change something: Let's try.
Subscribe to:
Posts (Atom)