From: Buddy Butterfly <buddy.butterfly@web.de>
To: emacs-orgmode@gnu.org
Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing
Date: Mon, 01 Apr 2013 22:59:24 +0200 [thread overview]
Message-ID: <5159F52C.60006@web.de> (raw)
In-Reply-To: <5159F480.3030100@web.de>
Correction, see below...
Am 01.04.2013 22:56, schrieb Buddy Butterfly:
> Hi,
>
> regarding your example
>
> ** Milestones :M:
> *** Task
> :PROPERTIES:
> :task_id: M2
> :depends: T8
> :END:
>
> ** Technical :T:
> :PROPERTIES:
> :task_id: T
> :END:
> *** Task
> :PROPERTIES:
> :task_id: T8
> :duration: 1d
> :END:
>
>
> I would like to discus what I mean with a prefix.
> At the moment oex tries to mirror some functionality of
> tj to org mode. From an architectural point of view I
> would do this only for few selected functionalities.
> Otherwise you developers have to always adapt code to
> tj. If you would implement generic tj properties that
> will be exported as is, then one could easily write
> the tj stuff itself.
>
> The problem becomes obvious with your example above.
> Herr you expect that T8 would be unique across all
> tasks. If there are some other task paths with a task of
> T8 then this will not work. You will always run after
> tj implementing what they have implemented. Why not
> write:
>
> :depends: !!T.T8
>
> directly? This is what should be done. Leave the tj
> logic to tj and do not try to map it to org-mode.
> The more you map the more difficult to maintain, etc.
>
> Also, you will likely only implement subsets of tj
> properties.
>
> For example, there are properties missing like
>
> :workinghours:
>
> Lets look at an example. Suppose
> we would prefix all taskjuggler properties with "tj_"
> and org-mode would export tj_ properties as is.
> People then would directly code the dependency
> themself.
>
> Your example would look like
> (if directly replaced)
>
> ** Milestones :M:
> *** Task
> :PROPERTIES:
> :tj_task_id: M2
> :tj_depends: !!T.T8
> :END:
>
> ** Technical :T:
> :PROPERTIES:
> :tj_task_id: T
> :END:
> *** Task
> :PROPERTIES:
> :tj_task_id: T8
> :tj_duration: 1d
> :END:
>
> Also, properties to the project tag should go into the
> project task. With the functionality above, it would be easy to:
>
> * Project :taskjuggler_project:
> :tj_workinhours: mon - fri 08:00 - 17:00
>
> Or give a flag:
>
>
> ** Technical :T:
> :PROPERTIES:
> :tj_task_id: T
> :END:
> *** Task
> :PROPERTIES:
> :tj_task_id: T8
> :tj_duration: 1d
> :tj_flag: tech8flag
> :END:
>
>
> I have some other points to discuss. Will create a separate thread for it.
>
> Cheers,
> Matt
>
>
>
> Am 01.04.2013 18:57, schrieb John Hendy:
>> On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>> John Hendy <jw.hendy@gmail.com> writes:
>>>
>>>> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>>>> John Hendy <jw.hendy@gmail.com> writes:
>>>>>
>>>>>> I still have the issue of depending on a task not in the current
>>>>>> subtree, but perhaps I'm just not using the exporter correctly:
>>>>> There was indeed a bug in the dependencies formatting. It should now be
>>>>> fixed in master. Could you confirm it?
>>>>>
>>>>>> *** Task
>>>>>> :PROPERTIES:
>>>>>> :task_id: M2
>>>>>> :depends: ??? what goes here to depend on T.T8 ???
>>>>> It should be :depends: T8
>>>>>
>>>>> Thank you for the feedback.
>>>>>
>>>> That *would* work, but ox-taskjuggler has to correct for the fact that
>>>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>>>
>>>>
>>>> #+begin_src TJ
>>>> task M2 "Task" {
>>>> depends !T8
>>>> milestone
>>>> }
>>>> #+end_src
>>> I cannot reproduce it. With:
>>>
>>> * Project :taskjuggler_project:
>>>
>>> ** Milestones :M:
>>> *** Task
>>> :PROPERTIES:
>>> :task_id: M2
>>> :depends: T8
>>> :END:
>>>
>>> ** Technical :T:
>>> :PROPERTIES:
>>> :task_id: T
>>> :END:
>>> *** Task
>>> :PROPERTIES:
>>> :task_id: T8
>>> :duration: 1d
>>> :END:
>>>
>>> I get:
>>>
>>> task project "Project" {
>>> purge allocate
>>> allocate nicolas
>>> task milestones "Milestones" {
>>> task M2 "Task" {
>>> depends !!T.T8
>>> milestone
>>> }
>>> }
>>> task T "Technical" {
>>> task T8 "Task" {
>>> duration 1d
>>> }
>>> }
>>> }
>>>
>>> which looks correct. Did you reload Org properly after update?
>> Process:
>> - Save your patch to ~/Downloads/patch.patch
>> - cd ~/.elisp/org.git
>> - git branch tj-test
>> - git checkout tj-test
>> - patch -p1 < ~/Downloads/patch.patch
>> - make clean && make
>> - start fresh Emacs session
>>
>> What perplexes me is that the id's mostly work (showing that the patch
>> definitely changed from the master branch behavior), but not the same
>> as you. With no task_id for Milestones, I'm getting:
>>
>> task nil "Milestones" {
>>
>> and you're getting
>>
>> task milestones "Milestones" {
>>
>> I'm also not getting the resolving of non-sibling depends attributes
>> (getting just !T8 instead of !!T.T8).
>>
>> Did I not apply the patch or rebuild org properly? I'm pretty bad with
>> git, and it surprises me that `git status` shows that ox-taskjuggler
>> is modified when I switch back to master. I would have expected that
>> my master branch would be oblivious to the changes I made on the
>> tj-test branch (with `git branch tj-test && git checkout tj-test`).
>>
>>
>> Thanks,
>> John
>>
>>> Regards,
>>>
>>> --
>>> Nicolas Goaziou
>
next prev parent reply other threads:[~2013-04-01 20:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 0:04 Item task_id not being used in taskjuggler export John Hendy
2013-04-01 0:16 ` John Hendy
2013-04-01 0:44 ` John Hendy
2013-04-01 14:21 ` Nicolas Goaziou
2013-04-01 14:53 ` John Hendy
2013-04-01 15:20 ` Nicolas Goaziou
2013-04-01 16:00 ` John Hendy
2013-04-01 16:38 ` Nicolas Goaziou
2013-04-01 16:57 ` John Hendy
2013-04-01 17:05 ` Nicolas Goaziou
2013-04-02 3:27 ` John Hendy
2013-04-01 20:56 ` Item task_id not being used in taskjuggler export & tj prefixing Buddy Butterfly
2013-04-01 20:59 ` Buddy Butterfly [this message]
2013-04-01 21:53 ` John Hendy
2013-04-01 22:01 ` Nicolas Goaziou
2013-04-02 3:24 ` John Hendy
2013-04-25 7:52 ` Christian Egli
2013-04-04 13:59 ` Buddy Butterfly
2013-04-24 20:09 ` Christian Egli
2013-04-24 19:51 ` Christian Egli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5159F52C.60006@web.de \
--to=buddy.butterfly@web.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).