exampleJava failure

[mrkraimer]

The jenkins build for exampleJava shows a failure when it is trying to build the javadoc.

exampleJava has the directory structure

exampleJava/
arrayPerformance // first example
...
serviceAPI //last example

exampleJava has no code but only a parent pom for each example.
Thus it has no javadoc.

Each example does have code and thus needs javadoc.
The javadoc of each example should go into the target/apidocs of the example

[anjohnson]

Hi Marty,

Our Cloudbees builds are all run by executing scripts inside the jenkins/ subdirectory of each project. Please take the time to look at those scripts for your exampleJava project; you should learn how to edit those scripts yourself, rather than relying on Ralph to edit them for you for this kind of thing (it's usually much faster to do it yourself anyway).

• Andrew

[ralphlange]

No, Marty is right.
This is about Java/Maven - the doc upload is part of the Jenkins-job (via a scriptlet).
The exampleJava project is the first multi-module Maven project in our zoo, that's why so many things break.

Doing the upload via scriptlet in Jenkins was wrong and a shortcut that now backfires. The upload should of course be done inside the Maven project - I will have to find out how.

[ralphlange]

@Marty:
The Javadoc of each example is in target/apidocs of the example.
The question is: what should the destination structure on the web look like?

[anjohnson]

@mrkraimer My apologies then.

[ralphlange]

For the C++ projects your statement is entirely true, of course.

[mrkraimer]

On 03/31/2016 04:20 PM, Ralph Lange wrote:

@Marty https://github.com/Marty:
The Javadoc of each example is in target/apidocs of the example.
The question is: what should the destination structure on the web look
like?

I am not sure how to answer this.

I see that for pvDatabaseJava it is:
http://epics-pvdata.sourceforge.net/docbuild/pvDatabaseJava/tip/documentation/html/index.html

So for exampleJava/database it might be.
http://epics-pvdata.sourceforge.net/docbuild/exampleJava/database/tip/html/*

What is in the html directory is l what "mvn package" produces in
target/apidocs

mrk> pwd
/home/epicsv4/master/exampleJava/database/target/apidocs
mrk> ls -R
.:
allclasses-frame.html constant-values.html help-doc.html index.html
overview-tree.html script.js
allclasses-noframe.html deprecated-list.html index-all.html
org package-list stylesheet.css

./org:
epics

./org/epics:
exampleJava

./org/epics/exampleJava:
exampleDatabase

./org/epics/exampleJava/exampleDatabase:
class-use ExampleHelloRecord.html package-frame.html
package-tree.html
ExampleDatabase.html ExampleHelloRPC.html package-summary.html
package-use.html

./org/epics/exampleJava/exampleDatabase/class-use:
ExampleDatabase.html ExampleHelloRecord.html ExampleHelloRPC.html

Marty

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#17 (comment)

[ralphlange]

That's not what I mean.

This is a multi-module project. Every sub-module's target/apidocs is a complete website.
We can't overlay them, as their structure is the same.
Question:
Where should the sub-modules go in the
.../docbuild/pvDatabaseJava/tip/documentation/html/...
structure?
As sub-directories (one per sub-module), or as top level directories?
Do the sub-modules inherit their version numbers from the multi-module project? Always, by definition?

With the recent merge you introduced a new concept (Maven multi-modules) without doing a proper specification for the use of such multi-modules (in the scope of our V4 context) first. Now it's on me to "fix" the implementation without knowing what exactly your intentions are.

[mrkraimer]

On 04/01/2016 07:55 AM, Ralph Lange wrote:

That's not what I mean.

This is a multi-module project. Every sub-module's target/apidocs is a
complete website.
We can't overlay them, as their structure is the same.
Question:
Where should the sub-modules go in the
.../docbuild/pvDatabaseJava/tip/documentation/html/...
structure?
As sub-directories (one per sub-module), or as top level directories?
Do the sub-modules inherit their version numbers from the multi-module
project? Always, by definition?

With the recent merge you introduced a new concept (Maven
multi-modules) without doing a proper specification for the use of
such multi-modules (in the scope of our V4 context) first. Now it's on
me to "fix" the implementation without knowing what exactly your
intentions are.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#17 (comment)

Looking again at
http://epics-pvdata.sourceforge.net/literature.html

And then under
Development Modules
Java Implementation
pvData Java Module Documentation: Reference, JavaDoc
...
pvDatabase

I would suggest that exampleJava be
exampleJava Module Documentation
arrayPerformance Reference, JavaDoc
database Reference, JavaDoc
...

Marty

  Development Module


         Java Implementation

[ralphlange]

OK.
What about my other question (re: version numbers)?

[gregoryraymondwhite]

On Apr 1, 2016, at 5:23 AM, Ralph Lange notifications@github.com wrote:

OK.
What about my other question (re: version numbers)?

I suggest as you wrote, "sub-modules inherit their version numbers from the multi-module project. Always, by definition."

Keeps it simple, and we don’t have to do even more version management.

greg

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[mrkraimer]

On 04/01/2016 08:23 AM, Ralph Lange wrote:

OK.
What about my other question (re: version numbers)?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#17 (comment)

I see in exampleJava/pom.xml
4.2.0-SNAPSHOT

and in all the examples no version for the example.
I think this means that the version is taken from the parent.
But not sure.

So I ask You what should the version number be?

Also in my last message I said

I would suggest that exampleJava be
exampleJava Module Documentation
arrayPerformance Reference, JavaDoc
database Reference, JavaDoc
...

I would suggest the this be changed to

I would suggest that exampleJava be
exampleJava Module Documentation: Reference
arrayPerformance: Reference, JavaDoc
database: Reference, JavaDoc

The reason is that exampleJava does have a
documentation/exampleJava.html file.

Also not all of the examples have a documentation/EXAMPLENAME.html file.
Each should have such a file.
Do you want me to add them before you make the cloudbees changes?
Or do you want to make the cloudbees changes first and then I can see
what the console output shows?

Also in each of the EXAMPLENAME.html files what should the version say?
Should each be Release 4.2 ?

Marty

         ...

[ralphlange]

OK, will find out about the numbering. Aim: sub-modules inherit from parent.

Destination web space structure for specific doc and Javadoc, master and released version:

.../docbuild/exampleJava/tip/sub-module<n>/documentation/sub-module<n>.html
.../docbuild/exampleJava/4.2.0/sub-module<n>/documentation/sub-module<n>.html

.../docbuild/exampleJava/tip/sub-module<n>/documentation/html/...
.../docbuild/exampleJava/4.2.0/sub-module<n>/documentation/html/...

The number to use inside the sub-module.html specific doc was half-specified in an AI, iirc. I adopted the -SNAPSHOT notation from the module name for pvaSrv, and Dave found that useful. I think it should be the full number, nut just the branch. For clarity.

(In Maven projects, the version could be taken from the POM and inserted in the doc. That must be set up, though. Opening an issue or creating an AI would be good ways to start such a change.)