Please upload OpenOffice.org Java/Uno JARs 2.1.0

Details

  • Type: Task Task
  • Status: Closed Closed
  • Resolution: Fixed
  • Labels:
    None

Description

OpenOffice.org includes some JARs that can be used in a standalone Java app to connect to a running OpenOffice.org instance.

The OpenOffice.org team agreed to distributing those JARs through Maven 2 and assigned the task to myself

  http://www.openoffice.org/issues/show_bug.cgi?id=71358

Please find the bundles here

  http://jooreports.sourceforge.net/m2/openoffice.org-juh-2.1.0-bundle.jar
  http://jooreports.sourceforge.net/m2/openoffice.org-jurt-2.1.0-bundle.jar
  http://jooreports.sourceforge.net/m2/openoffice.org-ridl-2.1.0-bundle.jar
  http://jooreports.sourceforge.net/m2/openoffice.org-unoil-2.1.0-bundle.jar

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Tran added a comment -
I happened to glance thru the request, here are my comments.

The dependencies use version = ${project.version}. You need change to the the official version 2.1

why ?

  <groupId>org.openoffice</groupId>
  <artifactId>openoffice.org-jurt</artifactId>


is it better if

  <groupId>org.openoffice</groupId>
  <artifactId>jurt</artifactId>

since we need both groupId and artifactId to identify the jar. may be we dont need to repeat
the groupId in the artifactId.


Show
Dan Tran added a comment - I happened to glance thru the request, here are my comments. The dependencies use version = ${project.version}. You need change to the the official version 2.1 why ?   <groupId>org.openoffice</groupId>   <artifactId>openoffice.org-jurt</artifactId> is it better if   <groupId>org.openoffice</groupId>   <artifactId>jurt</artifactId> since we need both groupId and artifactId to identify the jar. may be we dont need to repeat the groupId in the artifactId.
Hide
Permalink
Mirko Nasato added a comment -
I used ${project.version} to ensure that dependencies are in sync with the current jar version; other projects use the same practice e.g. spring-web

  http://mirrors.ibiblio.org/pub/mirrors/maven2/org/springframework/spring-web/2.0.2/spring-web-2.0.2.pom

Incidentally I used "2.1.0" as the version and not simply "2.1" because that's the more accurate scheme used by installation packages and in the code.

As for using "openoffice.org" in the artifactId, I agree that it is an arguable choice. However, "juh" "jurt" "ridl" and "unoil" alone are very non-descriptive names. Imagine looking in the WEB-INF/lib of a webapp that includes tens of different JARs, as is frequently the case: it would be very difficult to tell what "juh" is and what "ridl" is, and even that they are at all related. If you see "openoffice.org-juh" and "openoffice.org-ridl" at least you immediately know they are for OpenOffice.org. It's similar to using "commons-*" or "spring-*".
Show
Mirko Nasato added a comment - I used ${project.version} to ensure that dependencies are in sync with the current jar version; other projects use the same practice e.g. spring-web   http://mirrors.ibiblio.org/pub/mirrors/maven2/org/springframework/spring-web/2.0.2/spring-web-2.0.2.pom Incidentally I used "2.1.0" as the version and not simply "2.1" because that's the more accurate scheme used by installation packages and in the code. As for using "openoffice.org" in the artifactId, I agree that it is an arguable choice. However, "juh" "jurt" "ridl" and "unoil" alone are very non-descriptive names. Imagine looking in the WEB-INF/lib of a webapp that includes tens of different JARs, as is frequently the case: it would be very difficult to tell what "juh" is and what "ridl" is, and even that they are at all related. If you see "openoffice.org-juh" and "openoffice.org-ridl" at least you immediately know they are for OpenOffice.org. It's similar to using "commons-*" or "spring-*".
Hide
Permalink
Dan Tran added a comment -
my bad using ${project.version} woks

how about the name, how about openoffice-juh,? lots of projects use this convention like you have mentioned.

Show
Dan Tran added a comment - my bad using ${project.version} woks how about the name, how about openoffice-juh,? lots of projects use this convention like you have mentioned.
Hide
Permalink
Mirko Nasato added a comment -
Quoting from http://www.openoffice.org/about_us/summary.html

  Because of trademark issues, OpenOffice.org must insist that all public communications refer to the project and software as "OpenOffice.org" or "OpenOffice.org 1.x," and not "OpenOffice" or "Open Office."

That's why all Linux packages are also named "openoffice.org-*".

If the dot is a problem then "openofficeorg-juh", or maybe just "uno-juh" (although less descriptive)?
Show
Mirko Nasato added a comment - Quoting from http://www.openoffice.org/about_us/summary.html   Because of trademark issues, OpenOffice.org must insist that all public communications refer to the project and software as "OpenOffice.org" or "OpenOffice.org 1.x," and not "OpenOffice" or "Open Office." That's why all Linux packages are also named "openoffice.org-*". If the dot is a problem then "openofficeorg-juh", or maybe just "uno-juh" (although less descriptive)?
Hide
Permalink
Dan Tran added a comment -
ah, it is clear now ;-)
Show
Dan Tran added a comment - ah, it is clear now ;-)
Hide
Permalink
Carlos Sanchez added a comment -
by convention artifactId is set to the name of the jar, so it should be juh, jurt,... They will be under org.openoffice so there will be no clashes
Show
Carlos Sanchez added a comment - by convention artifactId is set to the name of the jar, so it should be juh, jurt,... They will be under org.openoffice so there will be no clashes

People

  • Assignee:
    Carlos Sanchez
    Reporter:
    Mirko Nasato
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: