Re: Ivy old docs removed - documentation now resides under asciidoc

[Gintautas Grigelionis]

I converted them, and they're dev-related. You can read them directly on
GitHub :-)

Gintas

2018-03-13 16:06 GMT+01:00 Jan Matèrne (jhm) :

> May /docs-to-convert ;)
>
> A directory /doc makes the expectation to find (actual) documentation.
>
>
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > Gesendet: Dienstag, 13. März 2018 10:14
> > An: Ant Developers List
> > Betreff: Re: Ivy old docs removed - documentation now resides under
> > asciidoc
> >
> > There is some documentation that has not been converted to asciidoc (eg
> > ideas.txt or conflict-solving-algo.html).
> > I will put them into dev, or does anyone have a better idea?
> >
> > Gintas
> >
> > 2018-03-07 11:49 GMT+01:00 Jaikiran Pai :
> >
> > > A while back we moved Ivy's documentation to Asciidoc. That automated
> > > migration, thanks mainly to Nicolas, went off fine and we fixed
> > > whatever issues we discovered in the migrated docs over a period of
> > > time. At this point, the previous HTML and xooki based documentation
> > is no longer needed.
> > > So I went ahead and pushed a commit which removes that directory from
> > > our repo. I don't expect it to be needed any more, but if we do need
> > > it for reference, we can always go back to this commit and check it
> > out.
> > >
> > > Going forward, the asciidoc based docs in the "asciidoc" directory of
> > > the repo, is the place where documentation for the project resides.
> > >
> > > -Jaikiran
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > > commands, e-mail: dev-h...@ant.apache.org
> > >
> > >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

AW: Ivy old docs removed - documentation now resides under asciidoc

[jhm]

May /docs-to-convert ;)

A directory /doc makes the expectation to find (actual) documentation.


Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Dienstag, 13. März 2018 10:14
> An: Ant Developers List
> Betreff: Re: Ivy old docs removed - documentation now resides under
> asciidoc
> 
> There is some documentation that has not been converted to asciidoc (eg
> ideas.txt or conflict-solving-algo.html).
> I will put them into dev, or does anyone have a better idea?
> 
> Gintas
> 
> 2018-03-07 11:49 GMT+01:00 Jaikiran Pai :
> 
> > A while back we moved Ivy's documentation to Asciidoc. That automated
> > migration, thanks mainly to Nicolas, went off fine and we fixed
> > whatever issues we discovered in the migrated docs over a period of
> > time. At this point, the previous HTML and xooki based documentation
> is no longer needed.
> > So I went ahead and pushed a commit which removes that directory from
> > our repo. I don't expect it to be needed any more, but if we do need
> > it for reference, we can always go back to this commit and check it
> out.
> >
> > Going forward, the asciidoc based docs in the "asciidoc" directory of
> > the repo, is the place where documentation for the project resides.
> >
> > -Jaikiran
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> >
> >


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: User implementations of custom interfaces can have access to Task instance?

[Stefan Bodewig]

On 2018-03-13, Jaikiran Pai wrote:

> I'm looking for some suggestion on whether it's a good/bad idea to
> expose a method to custom user defined classes which takes a "Task"
> object. This is in context of the JUnitLauncher task that I recently
> added. It allows custom report formatters/listeners to be implemented
> and the expectation is that such classes will implement the
> TestResultFormatter interface that is (newly) part of Ant. This
> interface exposes:

> void setTask(Task currentExecutingTask)

> so the implementations of this class have access to the current task
> that's running. Right now, the only reason I exposed that Task
> instance was to allow such implementation to issue log messages from
> within the implementation like:

In that case I'd prefer the formatter implementation to extend
ProjectConponent or just provide a setProject(Project) method.

When your formatter is created by Ant - for example as a nested element
- something like

public void addConfiguredFormatter(TestFormatter f)

then IntrospectionHelper will see the setProject method and invoke it
with a reference to the current project.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy old docs removed - documentation now resides under asciidoc

[Gintautas Grigelionis]

There is some documentation that has not been converted to asciidoc (eg
ideas.txt or conflict-solving-algo.html).
I will put them into dev, or does anyone have a better idea?

Gintas

2018-03-07 11:49 GMT+01:00 Jaikiran Pai :

> A while back we moved Ivy's documentation to Asciidoc. That automated
> migration, thanks mainly to Nicolas, went off fine and we fixed whatever
> issues we discovered in the migrated docs over a period of time. At this
> point, the previous HTML and xooki based documentation is no longer needed.
> So I went ahead and pushed a commit which removes that directory from our
> repo. I don't expect it to be needed any more, but if we do need it for
> reference, we can always go back to this commit and check it out.
>
> Going forward, the asciidoc based docs in the "asciidoc" directory of the
> repo, is the place where documentation for the project resides.
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

User implementations of custom interfaces can have access to Task instance?

[Jaikiran Pai]

I'm looking for some suggestion on whether it's a good/bad idea to 
expose a method to custom user defined classes which takes a "Task" 
object. This is in context of the JUnitLauncher task that I recently 
added. It allows custom report formatters/listeners to be implemented 
and the expectation is that such classes will implement the 
TestResultFormatter interface that is (newly) part of Ant. This 
interface exposes:


void setTask(Task currentExecutingTask)

so the implementations of this class have access to the current task 
that's running. Right now, the only reason I exposed that Task instance 
was to allow such implementation to issue log messages from within the 
implementation like:


task.getProject().log(, level);

I have been looking into other such cases where we allow custom 
implementations and documentation, but haven't found a guideline or 
anything that says whether it's good idea to give access to the Task 
instance to such custom implementations.


For now, I would like to avoid it if possible (logging is the only 
reason I use this instance for now). However, if there are no real 
concerns of letting custom implementations of the interface have access 
to this, then I will just go ahead and expose it without worrying about it.


P.S: I realize in fork mode, the Task instance won't be available and 
I'll be taking that into account, but this question is more a general 
guideline I'm looking for.


-Jaikiran




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org