Opened 9 years ago

Closed 9 years ago

#10517 closed defect (fixed)

dojox.atom missing from api.xml

Reported by: Adam Peller Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.5
Component: BuildSystem Version: 1.4.0
Keywords: Cc: Jared Jurkiewicz, Tom Trenka, phiggins
Blocked By: Blocking:

Description

This package is completely missing from api.xml. Perhaps it has to do with the fact that it contains only subdirectories? Drupal picks up the subdirs, but doesn't apply the top-level project description from _modules.js

Change History (14)

comment:1 Changed 9 years ago by Adam Peller

Component: Doc parserBuildSystem
Owner: changed from Neil Roberts to dante

Pete, the file in our source control seems to be missing a lot of what Tom has generated for his tool (Tom's api.xml has dojox.atom)

Where's the script that generates this? We should make sure it's the same and regenerate this for 1.4.1.

comment:2 Changed 9 years ago by Tom Trenka

A quick note: we seem to have some encoding issues with the XML generation; got an encoding error from the summary docs in dojox/date/HebrewNumerals.js, in getDayHebrewNumerals.

comment:3 Changed 9 years ago by Adam Peller

I'm going to open a separate ticket for the above... see #10665

comment:4 Changed 9 years ago by Adam Peller

it looks like the checked in copy of api.xml, which is out of date, is getting into the build. Perhaps build_release.sh should be deleting api.* before running generate.php?

comment:5 Changed 9 years ago by Adam Peller

Owner: changed from dante to Jared Jurkiewicz

comment:6 Changed 9 years ago by Jared Jurkiewicz

Er, what are people expecting me to do here? I have no idea how/what api.xml is generated.

comment:7 Changed 9 years ago by Jared Jurkiewicz

Peller gave me some pointers to running the docs tools. I'll see what I can figure out.

comment:8 Changed 9 years ago by Jared Jurkiewicz

Cc: phiggins added

I ran generate.php and it produced a new api.xml and api.json file in the cache/ dir of docscripts. Both files include the atom docs. So ... I'm assuming this means the files checked in are just out of date? The api.xml file that is checked in is dated March, 2009.

Should I check in these files? They're like 3x bigger than what is currently there.

Tom, Pete,

Input?

comment:9 Changed 9 years ago by Jared Jurkiewicz

Follow-up.

Anyone? I think the checked in files are out of date and just need to be updated, as generate.php did generate the dojox.atom content into the xml. IF that's all that needs to be done, I'll do it, I just need confirmation. Thanks.

comment:10 Changed 9 years ago by dante

Yep - I think this all revolves around a bad parse and a commit back to the codebase. I'm not sure I see the value in having api.xml in SVN/head/trunk, it will likely just get out of date. I suggest a 0-byte file named api.xml in trunk that is replaced in release and branch tags with a parsed api.* for the tree.

comment:11 Changed 9 years ago by Adam Peller

Agreed. See also #10754. What is the right place for this?

comment:12 Changed 9 years ago by Jared Jurkiewicz

Followup,

Pete, Tom, etc,

What do we need to do to get this closed? :-) 0 byte file? Commit in a rebuild api.xml?

comment:13 Changed 9 years ago by dante

Milestone: 1.4.21.5

0 byte file. we'll run the runner and backcommit to branch upon release. api.xml should not appear in trunk with bytes.

comment:14 Changed 9 years ago by Jared Jurkiewicz

Resolution: fixed
Status: newclosed

(In [21477]) Zero-byting the api.* files as they are out of date and should be 0 byte in trunk. fixes #10517

Note: See TracTickets for help on using tickets.