nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JavaDoc?

Robert_Davies_(unlondonadmin_-_(deleted))

Hi.I was just wondering where the JavaDoc documentation is for the Java version of LAPI..?Best regards/matt.

Find more posts tagged with

Comments

Simone_Oettinger_(SOettinger_(Delete)_177592)

At this point there are no plans to provide JavaDoc. It doesn't make much sense to us, since LAPI is supported in various programming languages.Simone

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Simone.I appreciate your point, LAPI does run on more than just Java, but I don't see that as a reason for lumping all the documentation together the way you have. That way you don't serve anyone properly.There is an important project in world-wide Higher Education (HE) called the Instructional Management System (IMS) project (www.imsproject.org). This has buy in from a huge number of organizations: Microsoft, Oracle, IBM, publishing companies, academic institutions, and so on. We are one of the founder members of the UK ims group.IMS standards/protocols are based on XML and the protocols are implemented in Java. We see Java, XML and LDAP being tied closely together throughout the industry. We think Java is very important. If you aren't prepared to properly support Java developers then I think you should just say so!Of the Java side of the LAPI; I am about at my wits end with it: poor documentation, awful example (note non plural), conceptually incoherent, heavy weight, etc...Your response to this question is disappointing.Best regards/matt.

Simone_Oettinger_(SOettinger_(Delete)_177592)

I take your point about the "awful example", but could you expand on "conceptually incoherent" and "heavy weight"?ThanksSimone

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Simone.I don't claim to be an O-O expert, but here are my comments anyways. These are slightly off the cuff, but I think you'll get the general idea.1) LAPI doesn't seem to me to be an O-O API. You have a few huge, monolithic "do everything" objects, one per chunk of functionality.This goes against the fine grained "interface-per-service" approach that I believe is part of good O-O design methodology.One consequence of this is that your objects aren't cohesive, i.e. it is not obvious what they do.2) You seem to have invented your own value-objects and collections, completely ignoring the excellent ObjectSpace Java Generic Library, or Java1.2 collections API. This makes coding for Livelink even more non-standard, and LAPI even bigger.Why did you invent your own collections?3) Exception handling is unclear. In any system, for it to be robust, the error handling must be right. Your error handling seems to be inconsistent.Of course with such poor documentation I could be wrong and not realize it !-) 4) Parts of LAPI are too low level.For example:The ListUsers function returns a RecArray, containing data columns?I am querying a document management system, if I wanted columns I would talk to the Oracle database underneath.You are returning user information: So define interfaces to represent the 'user concept' and return a standard collection of these.I could go on with these examples but it's late and I want to go home. I don't want to be unfair, but I believe LAPI compares very poorly in design & execution to similar types of API from other vendors, e.g. Sun's Java Naming & Directory Interface (JNDI).Oh and JNDI predictably has JavaDoc documentation like *every* other Java API - expect LAPI - I have ever come across.This is perhaps unsurprising since the tools to generate JavaDoc's are FREE, work from the Java source code, and are of benefit to user and developer alike.So once more, do you want to support Java developers?Best regards/matt.

Simone_Oettinger_(SOettinger_(Delete)_177592)

Hi Matt,It seems I'll be spending my entire maternity leave replying to your postings ;-)Your comments are very valid. Most of your complaints originate in the fact that LAPI is not really an Object Oriented API. You will be glad to know that some things in your list are being considered for the future (in particular, better error handling, and perhaps even an OO API).It seems that you are the customer doing the most Java LAPI developement that I'm aware of (the C folks are probably more used to this type of API). As I said before, I'll be glad to have a serious, lenghy discussion with you about LAPI and the Builder when I'm back in the office.Simone

Michael_Pate_(aflacadmin_-_(deleted))

I have started developing to LAPI in the last few weeks and am amazed at how low-level much of it is. My biggest complaint so far is the example you mentioned. Namely, A list of users is returned as a RecArray. I'm coding in VB (required by my employer) and generally expect to be able to pass standard VB types to an API. VB Collections and Recordsets, for example might map closely to Assoc's and RecArrays. Why not have a function that allows me to pass a recordset, or at least an ordinary array?No reply needed here, I just wanted you to know there are other voices out here, too.

Sari_Mustakallio

Your reply was posted in 1999. Is JavaDoc still NOT available?

Barbara__Melick__(aberadmin(expired))

To all Java developers:Maybe if enough LL application developers request JavaDoc documentation OpenText will take a few minutes to generate it. Make your voices heard. We are the customers, after all.Loren PettijohnATCAberdeen Proving Grounds

eLink User

Message from Sean M Alderman via eLinkI concur! I'd like to see some javadoc too.On Thu, 2001-12-27 at 16:49, eLink Discussion: LAPI Discussion wrote:> Sigh! Still no JavaDoc.> Posted by AberAdmin on 12/27/2001 04:45 PM> > To all Java developers:> > Maybe if enough LL application developers request JavaDoc documentation OpenText will take a few minutes to generate it. Make your voices heard. We are the customers, after all.> > Loren Pettijohn> ATC> Aberdeen Proving Grounds> > > > > [To reply to this thread, use your normal e-mail reply function.]> > ============================================================> > Topic: JavaDoc?> https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=1742069&objAction=view> > Discussion: LAPI Discussion> https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&objAction=view> > Livelink Server:> https://knowledge.opentext.com/knowledge/livelink.exe> > -- Sean M. AldermanITRACK Systems AnalystPACE/NCI - NASA Glenn Research Center(216) 433-2795Calling a windowed operating system "Windows" is like naming anautomobile "Wheels."

Jeff_Etrick

So this thread is a couple of years old, as any of the LAPI problems been addressed?

Knowledge_Center_Administrator

Good afternoon,There are no plans to include support for Javadoc in any known future release of LAPI for the following reasons:? There is already HTML enabled LAPI documentation for C++, VB and Java. For 9.1 SP3, which will be coming out shortly, this documentation has been added directly to the LAPI installation image under the doc directory. ? Also for 9.1 SP3, the table of contents that is displayed in the left frame has been enhanced to improve the navigation within the documentation.? Open Text is developing documentation for multiple OS platforms (Windows, HP, Solaris) and languages (C++, VB6, Java, .Net languages). Javadoc only supports one language, Java. Enhancements and extensions to the current documentation need occur in only one place for all our platforms under the current deliverable.? The LAPI client portion of the RPC mechanism is only a thin stub layer that is generated code. When LAPI functions are added to Livelink, the code is written in OScript and the appropriate stubbers generate the client code. There is no human generated documentation in these stubs. Auto generated documentation is not very useful given the dynamic LLValue parameters passed into and out of LAPI functions.? Rework of the server-side LAPI code base to include the necessary code for Javadoc would be extensive and redundant.? The LAPI development team needs to focus on exposing more of the core Livelink functionality. There is still much work to be done in support of Workflow access and other new technologies.Regards,Dave___________________________________________O P E N T E X T C O R P O R A T I O NDavid Slimmon, M.L.I.S.Knowledge Managerhttps://knowledge.opentext.comdslimmon@opentext.com

GuardeonicUser1_(Delete)_2954266

Hi, ye millions of Java developers using LAPI (and hi Loren)The very large numbers of replies to your demand (I am the second, am I ?), to make our voices heard, encourages me to join this huge community.YES I ALSO WANT TO HAVE A JAVADOC DOCUMENTATIONApart from the reason that I am used to it (this applies to most Java developers) there are lot of format problems with the current LAPI documentation. Lots of text passageshave one line per word which makes the documentation almost unreadable.Don't give up the hope that there will be a JavaDoc documentation in future (perhaps when JDK 5.1 is released)Mathias GropplerFaktum Softwareentwicklung Mainz GermanyA Guardeonic Solutions Company

Rory_Lampert_(xomaca01admin_-_(deleted))

I understand the need to keep redundancy out of any process, however, the software development community relies on STANDARDS to ensure that a project is developed in a timely and cost effective manner. By not supporting Java developers with the STANDARD for API documentation you are seriously crippling a develpers ability to quickly get up to speed. Perhaps you are not serious in your support of Java as a develpment tool for Livelink? You cannot expect any SERIOUS developer to utilize your API if they can't even make sense of it. As an engineer with many years of C++/Java development experience your shotgun approach to documentation is more hindrance than help.Craig GarzaSoftware EngineerXOMA (US) LLC

Magnus_Salgo_(IDNordicAdmin_(Delete)_2300172)

Yes We need to get better support for developing in Livelink.When you asked OT representatives at Livelink up in Paris you get an answer what you find is what we have.When you ask about a recommended test environment when yoiu deliver a function using the builder you get the answer nothing is there ...Please take this serious

Prakash_Joshi

Javadocs should be part of OpenText's coding standard for java. Javadocs are desperately needed by java developers. The HTML docs provided for C++, VB, Java are horrible and neary incomprehensible. YES I ALSO WANT TO HAVE A JAVADOC DOCUMENTATION

Adam_Myatt

Yes I concur. Need Javadoc. I understand OT's position that maintaining multiple sets of documentation is time consuming, but Javadoc is a standard offering for Java API. Make developers frustrated with poor documentation and they will not work with product and cause other's to not want to work with it.

Jonathan_Wolf

I'll add my two cents as a new developer trying to integrate Maximo with LiveLink via Java.

1. JavaDocs are a must.

2. Any documentation to the API seem to be very difficult to find (I still haven't found the HTML that everyone is talking about).

3. From what I have seen in the API and gotten to work, the methods are convoluted and don't clearly indicate what they actual will do. Thus the need for the JavaDocs.

End point. If you have a Java API then JavaDocs are the way to support it. By properly documenting the code created you can just generate the JavaDocs and thus this shouldn't be an issue.

Jim_Brezina

The online documentation can be found here on the Knowledge Center:

https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/16060242/llesapi/v090701/llesapi-pgd/docovw.xml

I hope that this is helpful…

Best Regards,

Jim

--
================================
Jim Brezina
Senior Technical Consultant,
NA Technical Services Division
Open Text Corporation
Lincolnshire, IL USA
mailto:jimb@opentext.com
http://www.opentext.com
ITIL Certified
================================

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Friday, March 18, 2011 4:04 AM
To: eLink Recipient
Subject: Agreed - Need Javadoc

Agreed - Need Javadoc

Posted by jawolf@jawolfconsulting.com (Wolf, Jonathan ) On 2011/03/17 10:51

I'll add my two cents as a new developer trying to integrate Maximo with LiveLink via Java.

1. JavaDocs are a must.

2. Any documentation to the API seem to be very difficult to find (I still haven't found the HTML that everyone is talking about).

3. From what I have seen in the API and gotten to work, the methods are convoluted and don't clearly indicate what they actual will do. Thus the need for the JavaDocs.

End point. If you have a Java API then JavaDocs are the way to support it. By properly documenting the code created you can just generate the JavaDocs and thus this shouldn't be an issue.

[To post a comment, use the normal reply function]
Topic:	JavaDoc?
Forum:	LAPI Forum
Livelink Server:	knowledge-wlweb01