Minutes from today's contributor call

14 views
Skip to first unread message

Robert D Anderson

unread,
Jun 4, 2015, 12:50:08 PM6/4/15
to dita-...@googlegroups.com

Very active discussion, particularly around the changes in 2.x versus 1.8. Thanks everybody for participating!
https://github.com/dita-ot/dita-ot/wiki/Meeting-minutes-2015-06-04

Once again, please let me know if you'd like to be added to the invite list for future calls. I have to check with George for sure, but if we stay on schedule, the next meeting will be Thursday July 2 at 10 Eastern.

Thanks!

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

Joe Williams

unread,
Jun 4, 2015, 3:27:53 PM6/4/15
to Robert D Anderson, dita-...@googlegroups.com
I agree that startcmd or an equivalent needs to be included in the future. It just makes things so much easier for people getting started. Also, when we configured our build server to run the OT, it provided a way for us to see all in one place how to set things up so it "just worked". Some people like Ant scripts, some like properties files. There are many paths to the waterfall.

--
You received this message because you are subscribed to the Google Groups "DITA-OT Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Robert D Anderson

unread,
Jun 4, 2015, 5:12:42 PM6/4/15
to Joe Williams, dita-...@googlegroups.com

Hi Joe,

I do want to clarify one thing about the idea that startcmd makes things easier.

Early on (first few years of DITA-OT), usage required setting up libraries like Ant, Xalan or Saxon, and so on. This usually involved setting environment variables, which is not something many DITA-OT users do regularly. It also wasn't that well documented. I think everybody can agree - those were the painful years.

The startcmd approach, as part of the "full easy install" delivery, hid the complexity but kept the same approach. You still need those libraries - it's just that this package bundles them, and startcmd sets the variables on a temporary basis. This has been much easier for (I would guess) almost everybody.

From the call today, it seems that a lot of people hear that startcmd is going away, and they assume this means a return to setting variables. I do want to stress that's not the case.

While startcmd hid some complexity, the "dita" command is more of a change in approach. Rather than just hiding complexity, it removes complexity, so that most of what you find in startcmd is no longer necessary.

The new, single package still bundles all the libraries - you always get them with any download. When you call the "dita" command, it uses those libraries, with no need for further setup or environment variables. Also: "dita" is just another way to call ant, with some much simpler parameters; if you want to keep calling Ant, you can do so. If you want to call "dita" and keep your -Dclean.temp=no style parameters, you can do that too.

Clearly there is a lot of work to do here, so I'm not giving anything like a final answer. Here's a likely incomplete list of my thoughts on changes:
1. Plan change - after chatting with Jarno, we'll be keeping startcmd for 2.1 and possibly longer
2. Doc change - need to have better docs about the new command
3. Education - I'd like to help clarify what startcmd does, and why the dita command isn't actually removing function, it's just making that extra "startcmd" step unnecessary.

I'm not sure if #3 is best accomplished in a blog post, a doc page, or some other venue, but it's clear that it's needed. Also, if possible, I'd like anybody who has enough interest to read our meeting minutes to be able to understand (and be happy with) the dita command. It really is an improvement and a simplification, I swear!

Thanks for reading -



Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

Inactive hide details for Joe Williams ---06/04/2015 14:28:01---I agree that startcmd or an equivalent needs to be included in Joe Williams ---06/04/2015 14:28:01---I agree that startcmd or an equivalent needs to be included in the future. It just makes things so m

Reply all
Reply to author
Forward
0 new messages