emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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
>

  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).