자바 커뮤니티 프로세스(Java Community Process, 약자 JCP)는 1998년에 설립되어, 이해관계자간에 자바 플랫폼의 향후 버전 및 기능에 대한 정의에 관여하는 표준화 과정이다.

JCP 과정에는 자바 스펙 요구서(Java Specification Request, 약자 JSR)을 이용하는데 JSR은 자바 플랫폼에 추가된 사양 및 기술을 기술하는 공식 문서이다. JSR의 공식 공개 리뷰는 JSR이 확정되기 전에 실행하고 JCP의 최상위 커뮤니티에서 투표를 한다. 최종판은 소스코드 형식의 기술에 관련되어 자유롭게 구현이 가능하도록 참조구현과 API 규격을 확인하는 기술호환 장치를 제공한다.

[편집]JSR

자바 스펙 요구서(Java Specification Request,JSR)은 자바 플랫폼에 추가된 사양 및 기술을 기술하는 공식 문서이다. 현재 JSR은 다음과 같다.

[편집]바깥고리

• Java Community Process home page
• List of all JSRs rated final
• List of all JSRs

[편집]주석

1. ↑ JSR 3 originally specified the JMX 1.0 release. Two subsequent "final" releases have provided JMX 1.1 and JMX 1.2. JMX 2.0 is specified by JSR 255.
2. ↑ JSR 52 originally specified the JSTL 1.0 release. A subsequent maintenance release provided JSTL 1.1.
3. ↑ JSR 56 originally specified the JNLP 1.0 release. A subsequent "final" release[1] provided JNLP 1.5, which was primarily a maintenance release. As of February, 2006, the JNLP 6.0 maintenance release has been completed but not finalized.
4. ↑ JSR 63 originally specified the JAXP 1.1 release. A subsequent maintenance release of JSR 63 provided the JAXP 1.2 specification.[2] JAXP 1.3 is specified by JSR 206.
5. ↑ JSR 127 originally specified the JSF 1.0 release. A subsequent maintenance release provided the JSF 1.1 specification.[3] JSF 1.2 is specified by JSR 252.
6. ↑ JSR 154 originally specified the Java Servlet 2.4 release. As of February, 2006 a maintenance draft of the 2.5 servlet specification is under review, scheduled to close on March 20, 2006.
7. ↑ JSR 913 originally specified JCP 2.0. It was subsequently amended by various changes to voting rules to produce version 2.1 and then further changed by licensing rules, policy, and processes to get to version 2.5. JCP 2.6 is defined by JSR 215.[4]
8. ↑ JSR 924 originally specified changes to the JVM to support changes in J2SE 5.0. As of 2006 a maintenance update to support changes proposed by JSR 202 is underway.

웹 접근성(web accessibility)은 장애를 가진 사람과 장애를 가지지 않은 사람 모두가 웹사이트를 이용할 수 있게 하는 방식을 가리킨다. 사이트가 올바르게 설계되어 개발되고 편집되어 있을 때 모든 사용자들은 정보와 기능에 동등하게 접근할 수 있다.

웹 접근성에는 다음의 사항들을 고려하여야 한다:

• 시각: 실명, 색각 이상, 다양한 형태의 저시력을 포함한 시각 장애
• 이동성: 파킨슨병, 근육병, 뇌성마비, 뇌졸중과 같은 조건으로 인한 근육 속도 저하, 근육 제어 손실로 말미암아 손을 쓰기 어렵거나 쓸 수 없는 상태
• 청각: 청각 장애
• 발작: 깜박이는 효과나 시각적인 스트로보스코프를 통해 일어나는 간질성 발작
• 인지: 문제 해결과 논리 능력, 집중력, 기억력에 문제가 있는 정신 지체 및 발달 장애, 학습 장애 (난독증, 난산증 등)

[편집]웹 브라우징에 쓰이는 보조공학

웹 브라우징을 할 수 있게 하거나 도움을 주는 등을 목적으로 보조공학을 이용할 수 있다.

• 스크린 리더 소프트웨어
• 화면 확대 도구
• 음성 인식
• 키보드 오버레이

DOMscript 란 무엇일까요?

웹 표준에 대한 관심이 고조된 지금 웹문서를 제작하는데 필요한 기술 중 하나라고 이해하시면 쉽게 와 닿으실 겁니다. 보통 웹문서(Document)를 구성하는 기본 골격은 html/xhtml이 이룹니다. 그 위에 외부 스타일시트(CSS: Cascading Style Sheet)가 골격에 살을 붙이는 디자인 파트의 영역을 이룬다고 볼 수 있습니다. 그리고 최종적으로 웹 문서에 동적인 컨테츠 및 구현을 담당하는 것이 바로 DOM(Document Object Model) Script라고 할 수 있습니다. ‘돔’이라는 말로 인해 어렵게 느껴지시는 분들은 ‘자바스크립트’라고 말씀드리면 보다 쉽게 이해되시겠죠. 즉, 결론은 “웹 표준을 준수한 자바스크립트” 라는 것에 도달할 수 있습니다.

왜?! DOMscript를 알아야 할까요?

웹이 태생하고 암흑시기가 있었습니다. 사람들은 이것을 “웹 브라우저 전쟁”이라고 불렀죠. 그 렇습니다. 넷스케이프(Netscape_사의 네비게이터와 마이크로소프트(Microsoft)사의 인터넷 익스플로러 간의 격돌이었죠. 웹에 표준이 없던 시절……. 양 사는 서로의 브라우저에서만 제공되는 메서드(Method)등을 양산하게 됩니다. 이로 인해 웹 관련 종사자들은 이루 말할 수 없는 고충을 겪게 되었던 것이죠. 물론, 지금의 시대는 웹 표준시대로 이 같은 문제가 더 이상 생기지 않도록 표준안이 생겼습니다. 그것이 바로 W3C에서 제정된 표준안을 준수한 DOM(문서객체모델)을 지키는 자바스크립트의 탄생인 것이죠.

표 준의 중요성이 대두되는 당금의 시장에 표준을 준수한 자바스크립트 개발은 시장을 선점하는 효과를 낳을 수 있습니다. Cross-OS(Operation System), Cross-Browsing을 통한 시장 저변확대가 기대되니 말입니다. “웹 표준을 준수한 문서를 제작 한다.” “하지만 그것은 정적인 문서일 뿐, 동적인 연동 고려를 위해서는 돔 스크립트를 필요로 한다.” 라고 볼 수 있는 것이죠.

웹 퍼블리셔(web Publisher)?! 그게 뭐지?

퍼 블리셔는 웹 관련 종사자들은 누구나 알고 있는 코더(Coder)를 높이는 말이라고 보셔도 됩니다. 하지만, 그것만이라고 생각하시면 안 됩니다. 이유는 퍼블리셔의 역할을 제대로 알고 수행하는 인력은 코더와 비교되어 분류, 평가되어야 하기 때문입니다. 퍼블리셔의 역할이 중요하게 인식되는 이유는 웹 표준으로 인하여 발생되는 브라우저간의 문제점 구조화의 분석을 통한 소스의 최적화 등 디자인에서 개발로 넘어가기 전 디자이너의 의도에 맞게!, 개발 쪽의 의도에 맞게! 이슈를 최소화하여 작업에 보다 쉽고 관리가 용이하게 해주는 없어서는 안 될 역할이 기 때문입니다. 그리고 또 다른 이유가 바로 W3C에서 주창하는 “웹을 사용하는 모든 이들에게 동일한 사용 환경을 제공해야 한다.” 웹 접근성 향상에 기여하는 부분이 많기 때문입니다. 이처럼 단순히 기존의 Table 코딩에서 DIV 코딩으로 변화한 것이 아닌, 보다 전문적인 직종으로 발돋움하기 위해 퍼블리셔가 갖추어야 할 요건이 많이 생겼기 때문입니다.

웹 퍼블리셔(web Publisher)역할은 알았는데? 영역은?

코 더의 역할을 벗어나 기획, 디자인, 개발까지 의견을 반영하고 접근성 및 표준을 순수할 수 있게 해주는 중요한 포지션(Position)에 위치한 것이 퍼블리셔라고 앞에서도 말씀드렸습니다. 퍼블리셔의 영역은 [표준과 접근성]이 주된 일이기 때문에 디자인 영역과는 90% 이상 관계가 없습니다. 물론, 100% 디자인과 연관이 없는 것은 아니기 때문에 퍼포먼스가 큰 유동적인 페이지는 디자이너의 합의하에 조율을 할 수 있는 것입니다. 그리고 Flash 등을 활용한 비 접근성적인 디자인이 나온다 하더라도 충분히 퍼블리셔는 커버의 역할이 가능합니다. Flash 쪽에서 로딩(Loading) 완료시, 일정 값(value)을 스크립트(Script)로 주고, 그것이 확인되면 Flash를 호출하고, 그렇지 않을 경우 이미지(image)로 처리하게 도와주면 되는 것이죠. 결론은 표준 작업시 특정 이슈에 고나한 것은 디자인 쪽과 조율을 하되 그 이상은 관여하지 않는 것이 디자인 영역에 대한 퍼블리셔의 영역입니다.

그 럼 개발영역에 대한 퍼블리셔의 영역은 무엇일까요? 개발자와 일하는 퍼블리셔가 고려해야될 상황은 웹 표준 및 DocType을 인지하지 못한 개발자와 작업하는 경우입니다. 퍼블리셔는 개발 도중 이거 안 되고, 저거 안 되고 하는 것보다 미리 간단한 WSG를 만들어 개발자에게 배포/교육 후 프로젝트에 들어가면 문제가 발생되는 것을 미리에 방지하는 것이죠.

예를들어 스크립트 부분에서 IE, FF, Safari 등 특정 스크립트만 인식하는 부분과 그렇지 않은 부분, 태그(Tag) 사용법 등을 미리 선정하여 문제를 방지하는 것입니다.

여지껏 이야기를 정리하자면, “퍼블리셔는 서포터의 역할을 수반하는 직종이다.”라고 볼 수 있겠죠. 즉 이거 아냐, 저거 아냐가 아니고 최대한 디자인을 살린! 최대한 개발 영역을 넓혀주는 역할을 하는 것이 바로 퍼블리셔의 영역인 것입니다.

퍼블리셔가 디자이너에게_

“가능한 서포트 해드릴 테니 마음껏 디자인 하세요. 정 안되면 말씀드릴게요. ^-^ ”

퍼블리셔가 개발자에게_

“일단 저희가 준 WSG를 최대한 참고하시고, 개발 완료시점 때 미팅을 하면서 변경하죠.”

그렇습니다. 최고의 퍼블리셔는 틀이 아닌, 두 개의 직종을 무한대로 확장시켜주는 서포터인 것입니다.

- 정리 by yamoo9

  <참고> DOM스크립트(에이콘출판사), 서정민님의 웹 퍼블리셔에 대한 글.

Apache Jakarta Project (아파치 자카르타 프로젝트) Apache 소프트웨어 재단 에서 운영되고있는 오픈 소스 소프트웨어 개발 프로젝트 중 하나입니다. 프로그래밍 언어 Java 를위한 라이브러리 , 프레임 워크 등을 개발하고있다. 2011 년 10 월 26 일 에 모든 하위 프로젝트를 졸업했다.

썬마 이크로 시스템즈 가 Java Servlet / JavaServer Pages (JSP)의 레퍼런스 구현 이다 JSWDK (JavaServer Web Development Kit)를 Apache 소프트웨어 재단에 기부한 것을 계기로 발족. 그리고이 JSWDK을 기반으로 Apache Tomcat 의 초기 버전이 개발되었다 ^[1] .

Jakarta 이름은 Jakarta와 매우 관계가 깊은 프로그래밍 언어 Java 그 이름을 딴 자바 에있는 도시 자카르타 를 유래하고있다.

하위 프로젝트 [ 편집 ]

Apache 소프트웨어 재단의 최상위 프로젝트로 승격 프로젝트 [ 편집 ]

• Ant
• Commons
  • BCEL
  • BSF
• DB
• Forrest
• Gump
• HiveMind
• James
• JMeter
• Lucene
• Maven
• POI
• Struts
• Tapestry
• Tomcat
• Turbine
• Velocity
• Watchdog

은퇴 · 휴지 또는 다른 마이 그 레이션 프로젝트 [ 편집 ]

• Apache Avalon
• Alexandria
• Agila
• ECS
• JCS
• ORO
• Regexp
• Slide
• Taglibs
• Cactus

각주 [ 편집 ]

1. ^ Apache Tomcat 5.5.12-alpha 릴리스 노트 에 따르면, 2005 년 9 월 23 일 에 Apache Tomcat 은 Apache 소프트웨어 재단의 최상위 프로젝트로 승격했다.

자카르타 프로젝트에서는 자바 플랫폼을 위한 오픈 소스 소프트웨어를 만들고 정비하고 있다. 자카르타 프로젝트는 아파치 소프트웨어 재단의 원조 아래 마치 우산을 씌운듯한 포괄적인 프로젝트 형태로 수행되고 있고, 모든 자카르타 프로젝트의 제품들은 아파치 라이선스 하에 공개되고 있다.

[편집]

하위 프로젝트

도구와 라이브러리와 프레임워크를 포함한 자카르타 프로젝트의 주된 성과물들은 다음과 같다.

• BCEL - 자바 바이트 코드를 다루는 라이브러리
• BSF - 자바 애플리케이션에서 스크립트 언어를 지원하기 위한 프레임워크
• Cactus - 서버사이드의 자바 클래스 유닛 테스트 프레임워크
• ECS - 다양한 마크업 언어의 요소들을 생성해주는 자바 API. (The Element Construction Set)
• JCS - 자바로 제작된 분산 캐싱 시스템
• JMeter - 서버에의 부하와 스트레스를 테스트
• ORO - Perl5 호환 정규식 지원 자바 클래스
• Regexp - 순수 자바 언어 정규식 지원 API
• Taglibs - JSP 커스텀 태그 라이브러리(JSTL)

다음 프로젝트들은 초기에 자카르타 프로젝트의 아래에서 시작되었으나 독립된 프로젝트로 운영되고 있다.

• 앤트 - 빌드 도구
• 메이븐 - 프로젝트의 빌드와 관리 도구
• 스트럿츠 - 웹 애플리케이션 개발 프레임워크
• 톰캣 - JSP/서블릿 컨테이너
• 태피스트리 - 자바로 다양하고 다이나믹하고 범용성있는 웹 애플리케이션을 만들기 위한 프레임워크. 자바빈즈 프로퍼티 기반의 컴포넌트 오브젝트 모델이다.
• Hivemind - 서비스이자 환경설정 마이크로커널.
• 커먼즈 - 자바 표준 라이브러리를 보완하기 위한 유용한 클래스 모음
• HttpComponents- 하이퍼텍스트 전송 프로토콜
• POI - 마이크로소프트의 대중적인 파일 포맷을 접근하게 해주는 API
• 터빈 - 빠른 개발을 목표로 하는 웹 애플리케이션 프레임워크
• 벨로시티 - 웹 템플릿 엔진

다음 프로젝트는 철수하여 더이상 지원되지 않고 있다.

• Slide - WebDAV를 사용하는 콘텐츠 저장소

[편집]

바깥 링크

• 자카르타 홈페이지
• 자카르타 서울 프로젝트 홈페이지 - 자카르타 프로젝트 홈페이지의 한글화 프로젝트
• 아파치 소프트웨어 재단 공식 홈페이지
• 아파치 소프트웨어 재단 한국 공식 홈페이지
• Metrics - 자카르타 프로젝트의 변동사항 제공

Jakarta Project는 Apache project중 자바기반의 오픈소스 솔루션을 만들고 유지 배포하는 프로젝트 입니다.

여러분들이 잘 알고있는 톰캣이나 최근 가장 많이 사용하고 있는 프레임 워크로 스트러츠 같은 것들이 자카르타 프로젝트 제품들입니다.http://jakarta.apache.org 에서 자카르타 프로젝트 정보들을 상세히 알 수 있으며 이 사이트에서는 이 사이트를 참고하여 실제로 유용하게 사용되는 모듈들을 소개하고자 합니다.

1. Jakarta 제품들

Jakarta 는 일반적으로 3개의 분류로 나뉘어져 있습니다.

 -. Libraries, Tools, and APIs( 라이브러리, 도구, API)

 -. Frameworks and Engines

 -. Server Applications

2. 자카르타 관련 프로젝트

 -. Apache Ant Project  (아파치 앤트 프로젝트)

 -. Apache Avalon Project (아파치 아바론 프로젝트)

 -. Apache Cocoon Project  (아파치 코쿤 프로젝트)

 -. Apache DB Project  (아파치 DB 프로젝트)

 -. Apache Excalibur Project (아파치 엑스칼리버 프로젝트) -_-;

 -. Apache Geronimo Project (아파치 제로니모 프로젝트)

 -. Apache Gump Project  (아파치 검프 프로젝트)

 -. Apache HTTP WebServer Project  (아파치 HTTP 웹서버 프로젝트)

 -. Apache Incubator Project  (아파치 인큐베이터 프로젝트)

 -. Apache James Project  (아파치 제임스 프로젝트)

 -. Apache Logging Services Project  (아파치 로깅 서비스 프로젝트)

 -. Apache Maven Project  (아파치 메이븐 프로젝트)

 -. Apache Portals Project  (아파치 포털 프로젝트)

 -. Apache Struts Project  (아파치 스트러츠 포르젝트)

 -. Apache WebServices Project  (아파치 웹서비스 프로젝트)

 -. Apache XML Project  (아파치 XML 프로젝트)

 -. Apache XMLBeans Project  (아파치 XML빈즈 프로젝트)

3. 참여방법

모든 Jakarta 제품의 지원은 부속프로젝트의 메일링 리스트를 통해서 제공됩니다.

http://jakarta.apache.org/site/mail2.html

http://www.mail-archive.com/

http://jakarta.apache.org/site/cvsindex.html

From http://http://jakarta.apache-korea.org

원본글 : http://www.jakartaproject.com/