Documentation

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Documentation

Lukasz Lenart
Hi,

I would like to move our docs (or some part of it) to Markdown and put
them next to our website's source. Existing mechanism of exporting
docs is rather not the best approach, also it isn't possible to engage
community to improve it (as with the core and PRs via GitHub).

My first idea was to export everything from Confluence and convert to
MD but this not the best approach after all - we still need a place to
restrict access for some pages, i.e. security bulletins and so on,
also some pages are to detailed to be part of so common user guides.

So instead of migrating things I think it would be better to start
writing/copy/pasting some parts from wiki directly to website and
create a new/based on old guides. Confluence will be still used for
more detailed explanations of core elements and to manage releases and
so on.

I want to start with
https://cwiki.apache.org/confluence/display/WW/Getting+Started

or more generally with
https://cwiki.apache.org/confluence/display/WW/Tutorials

wdyt?


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Christoph Nenning
Hi,

sounds like a good idea!

But also sounds like a lot of work. It will take probably plenty of time
until it is finished. Every journey starts with a first step :)


Regards,
Christoph


>
> Hi,
>
> I would like to move our docs (or some part of it) to Markdown and put
> them next to our website's source. Existing mechanism of exporting
> docs is rather not the best approach, also it isn't possible to engage
> community to improve it (as with the core and PRs via GitHub).
>
> My first idea was to export everything from Confluence and convert to
> MD but this not the best approach after all - we still need a place to
> restrict access for some pages, i.e. security bulletins and so on,
> also some pages are to detailed to be part of so common user guides.
>
> So instead of migrating things I think it would be better to start
> writing/copy/pasting some parts from wiki directly to website and
> create a new/based on old guides. Confluence will be still used for
> more detailed explanations of core elements and to manage releases and
> so on.
>
> I want to start with
> https://cwiki.apache.org/confluence/display/WW/Getting+Started
>
> or more generally with
> https://cwiki.apache.org/confluence/display/WW/Tutorials
>
> wdyt?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

This Email was scanned by Sophos Anti Virus
Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
2017-01-31 10:43 GMT+01:00 Christoph Nenning <[hidden email]>:
> Hi,
>
> sounds like a good idea!
>
> But also sounds like a lot of work. It will take probably plenty of time
> until it is finished. Every journey starts with a first step :)

Not really a plenty of work as I want to just copy paste existing
Getting Started ;-) And then improved it over the time :)


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Stefaan Dutry
Hello,

I like the idea.
I wouldn't mind helping with migrating the documentation.

I would need at least 1 page as an example, and to know the exact
location where you want the documentation to be placed.

Regards,

Stefaan Dutry
(sdutry)

Op 31 jan. 2017 10:45 a.m. schreef "Lukasz Lenart" <[hidden email]>:

>
> 2017-01-31 10:43 GMT+01:00 Christoph Nenning <[hidden email]>:
> > Hi,
> >
> > sounds like a good idea!
> >
> > But also sounds like a lot of work. It will take probably plenty of time
> > until it is finished. Every journey starts with a first step :)
>
> Not really a plenty of work as I want to just copy paste existing
> Getting Started ;-) And then improved it over the time :)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Ken McWilliams
Anything that makes document contribution easier is good!

A traditional wiki in my opinion would be most ideal. Just as it works for
Wikipedia (backed by mediawiki) you'll find that very few people will cause
an issue with documentation. It is also very beneficial if people can
create new pages/links too. All wikis have security to restrict certain
pages to certain users, so security bulletins etc. can be trusted. It is
really nice when you find a spelling error to just fix it then and there. A
wiki I like is Xwiki it's Java based and it happily cooperates with most
any DB. Both these wiki's are _very_ easy to set up. I think Xwiki uses
Struts... I think v2...It is a pretty nice and useful product (FLOSS).

A plausible option would be to create a wiki and export it's pages into the
main site. Not sure about that sort of flow but for the paranoid it would
allow an official checked version to exist, as well as a faster evolving
version. At the worst move the content with copy and paste.



On Tue, Jan 31, 2017 at 5:04 AM, Stefaan Dutry <[hidden email]>
wrote:

> Hello,
>
> I like the idea.
> I wouldn't mind helping with migrating the documentation.
>
> I would need at least 1 page as an example, and to know the exact
> location where you want the documentation to be placed.
>
> Regards,
>
> Stefaan Dutry
> (sdutry)
>
> Op 31 jan. 2017 10:45 a.m. schreef "Lukasz Lenart" <
> [hidden email]>:
> >
> > 2017-01-31 10:43 GMT+01:00 Christoph Nenning <
> [hidden email]>:
> > > Hi,
> > >
> > > sounds like a good idea!
> > >
> > > But also sounds like a lot of work. It will take probably plenty of
> time
> > > until it is finished. Every journey starts with a first step :)
> >
> > Not really a plenty of work as I want to just copy paste existing
> > Getting Started ;-) And then improved it over the time :)
> >
> >
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Sent from my C64 using a 300 baud modem
Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Aleksandr Mashchenko
In reply to this post by Lukasz Lenart
+1

Can we export some of the pages from Confluence to MD?

---
Regards,
Aleksandr

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
In reply to this post by Stefaan Dutry
2017-01-31 13:04 GMT+01:00 Stefaan Dutry <[hidden email]>:
> Hello,
>
> I like the idea.
> I wouldn't mind helping with migrating the documentation.
>
> I would need at least 1 page as an example, and to know the exact
> location where you want the documentation to be placed.

The website's source is here https://github.com/apache/struts-site and
I want to start adding pages to it, it can be in the root folder


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
In reply to this post by Ken McWilliams
2017-01-31 18:29 GMT+01:00 Ken McWilliams <[hidden email]>:

> Anything that makes document contribution easier is good!
>
> A traditional wiki in my opinion would be most ideal. Just as it works for
> Wikipedia (backed by mediawiki) you'll find that very few people will cause
> an issue with documentation. It is also very beneficial if people can
> create new pages/links too. All wikis have security to restrict certain
> pages to certain users, so security bulletins etc. can be trusted. It is
> really nice when you find a spelling error to just fix it then and there. A
> wiki I like is Xwiki it's Java based and it happily cooperates with most
> any DB. Both these wiki's are _very_ easy to set up. I think Xwiki uses
> Struts... I think v2...It is a pretty nice and useful product (FLOSS).
>
> A plausible option would be to create a wiki and export it's pages into the
> main site. Not sure about that sort of flow but for the paranoid it would
> allow an official checked version to exist, as well as a faster evolving
> version. At the worst move the content with copy and paste.

ASF is using Confluence [1] or MoinMoin Wiki [2] - these are the only
options we have ;-) I would like to use git [3] for
version-controlling and for easy maintenance and contributions - you
don't have to clone a fork locally, you can edit markdown files
directly in a browser and create PRs. Also using git allow us to use
Jenkins to automatically deploy a new version of website & docs.

Right now I'm using this [4] to export all the pages from Confluence
and put them inside a website production repo [5] - it's a bit painful
and cumbersome process ;-)

[1] cwiki.apache.org/confluence/display/WW/
[2] https://wiki.apache.org/general/
[3] https://github.com/apache/struts-site
[4] https://github.com/apache/struts-site/blob/master/pom.xml#L27-L46
[5] https://svn.apache.org/repos/infra/websites/production/struts/content/


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
In reply to this post by Aleksandr Mashchenko
2017-02-01 18:01 GMT+01:00 Aleksandr Mashchenko <[hidden email]>:
> +1
>
> Can we export some of the pages from Confluence to MD?

More or less we can use this [1] but it will still produce a html
content, I'm playing with settings locally but a lot of things is
hardcoded inside the SiteExporter

[1] https://github.com/apache/struts-site/blob/master/pom.xml#L27-L46


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Aleksandr Mashchenko
In reply to this post by Lukasz Lenart
Maybe this can help: http://www.viaboxx.de/code/confluence2md/

---
Regards,
Aleksandr

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
Can you review this section?
http://struts.apache.org/submitting-patches.html#contributing-with-github

Is it clear how to prepare a repo, add fork and create branch/PR?


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2017-02-02 20:32 GMT+01:00 Aleksandr Mashchenko <[hidden email]>:

> Maybe this can help: http://www.viaboxx.de/code/confluence2md/
>
>
> ---
> Regards,
> Aleksandr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Greg Huber
How would one resync the github fork with the struts orignal version?



On 3 February 2017 at 14:22, Lukasz Lenart <[hidden email]> wrote:

> Can you review this section?
> http://struts.apache.org/submitting-patches.html#contributing-with-github
>
> Is it clear how to prepare a repo, add fork and create branch/PR?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> 2017-02-02 20:32 GMT+01:00 Aleksandr Mashchenko <[hidden email]>:
> > Maybe this can help: http://www.viaboxx.de/code/confluence2md/
> >
> >
> > ---
> > Regards,
> > Aleksandr
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
2017-02-03 16:06 GMT+01:00 Greg Huber <[hidden email]>:
> How would one resync the github fork with the struts orignal version?

You don't have to :) You are always starting off the master from origin


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Stefaan Dutry-2
Personaly i can understand everything in there.

However i tend to do things differently myself.

How i usualy work:
* I use clone with https way

1. Fork the repository to my own account
2. clone the repository localy, making my fork 'origin' (git clone
<https-url (of the fork)>)
3. add the original repository as a remote with the name upstream (git
remote add https://github.com/apache/struts.git)
4. create a branch for changes
5. do changes localy
6. add changed files   (git add <changed files>)
7. commit changes localy   (git commit -m "my comment explaining what changed")
8. push to origin (being my fork)  (git push origin <branchname>)
9. create pull request

Reasons for using own fork as origin:
* When looking up commands i tend to always come across commands that
push to origin
* It tends to make it more awkward to accidently try to push to the
original git repo

Spotted typo:
  Do you changes and commit them...
=> Do your changes and commit them ...

I'm not saying either way is better, just thought i'd mention this
slightly different approach.

Regards,

Stefaan Dutry (sdutry)

2017-02-03 16:15 GMT+01:00 Lukasz Lenart <[hidden email]>:

> 2017-02-03 16:06 GMT+01:00 Greg Huber <[hidden email]>:
>> How would one resync the github fork with the struts orignal version?
>
> You don't have to :) You are always starting off the master from origin
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
2017-02-03 20:19 GMT+01:00 Stefaan Dutry <[hidden email]>:
> Personaly i can understand everything in there.

Cool, thanks :)

> However i tend to do things differently myself.
>
> How i usualy work:
> * I use clone with https way

Why?

> 1. Fork the repository to my own account
> 2. clone the repository localy, making my fork 'origin' (git clone
> <https-url (of the fork)>)
> 3. add the original repository as a remote with the name upstream (git
> remote add https://github.com/apache/struts.git)
> 4. create a branch for changes
> 5. do changes localy
> 6. add changed files   (git add <changed files>)
> 7. commit changes localy   (git commit -m "my comment explaining what changed")
> 8. push to origin (being my fork)  (git push origin <branchname>)
> 9. create pull request

How do you update your fork with changes from origin to avoid a merge commit?

> Reasons for using own fork as origin:
> * When looking up commands i tend to always come across commands that
> push to origin
> * It tends to make it more awkward to accidently try to push to the
> original git repo

Pushing just once with git push -u solves the problem but I understand
and that's why I'm preferring Github as the Apache Struts mirror is
readonly, you won't be able to push anything there :)

> Spotted typo:
>   Do you changes and commit them...
> => Do your changes and commit them ...
>
> I'm not saying either way is better, just thought i'd mention this
> slightly different approach.

With proposed approach you are always starting off the master with up
to date version of source code, you don't have to update your fork and
there is no more merge commits. These are the advantages with proposed
flow but I'm open for discussion.


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Stefaan Dutry-2
I would like to start by saying that i didn't claim my way was better.

-) why https way
  No need to set up ssh keys. (so basicaly just lazyness from my part)

-) How do you update your fork with changes from origin to avoid a merge commit?
  Thanks for pointing this out.
  This is something i didn't take into account (and have probably
pushed a merge commit a couple of times)
  There is a way using the --rebase option during the pull command though

-) The readonly setting does indeed solve the accidental commits.

-) Won't you have the same merge commits if there's been a lot of
changes since you created your branch and want to pull in those
changes before creating a pull request?

-) When making a branch you could always create it from any chosen remote:
   git fetch -p upstream
   git checkout -b testupstreambranch upstream/master
(where upstream is the remote you forked from)


But you're right.
Your suggested approach surely has some advantages, thanks for
explaining them to me.

Regards,
Stefaan Dutry (sdutry)

2017-02-04 7:43 GMT+01:00 Lukasz Lenart <[hidden email]>:

> 2017-02-03 20:19 GMT+01:00 Stefaan Dutry <[hidden email]>:
>> Personaly i can understand everything in there.
>
> Cool, thanks :)
>
>> However i tend to do things differently myself.
>>
>> How i usualy work:
>> * I use clone with https way
>
> Why?
>
>> 1. Fork the repository to my own account
>> 2. clone the repository localy, making my fork 'origin' (git clone
>> <https-url (of the fork)>)
>> 3. add the original repository as a remote with the name upstream (git
>> remote add https://github.com/apache/struts.git)
>> 4. create a branch for changes
>> 5. do changes localy
>> 6. add changed files   (git add <changed files>)
>> 7. commit changes localy   (git commit -m "my comment explaining what changed")
>> 8. push to origin (being my fork)  (git push origin <branchname>)
>> 9. create pull request
>
> How do you update your fork with changes from origin to avoid a merge commit?
>
>> Reasons for using own fork as origin:
>> * When looking up commands i tend to always come across commands that
>> push to origin
>> * It tends to make it more awkward to accidently try to push to the
>> original git repo
>
> Pushing just once with git push -u solves the problem but I understand
> and that's why I'm preferring Github as the Apache Struts mirror is
> readonly, you won't be able to push anything there :)
>
>> Spotted typo:
>>   Do you changes and commit them...
>> => Do your changes and commit them ...
>>
>> I'm not saying either way is better, just thought i'd mention this
>> slightly different approach.
>
> With proposed approach you are always starting off the master with up
> to date version of source code, you don't have to update your fork and
> there is no more merge commits. These are the advantages with proposed
> flow but I'm open for discussion.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
2017-02-04 8:26 GMT+01:00 Stefaan Dutry <[hidden email]>:
> I would like to start by saying that i didn't claim my way was better.

Yes, I know that, don't get me wrong I just want to know if I am
missing something and maybe there is a better way :)

> -) why https way
>   No need to set up ssh keys. (so basicaly just lazyness from my part)

Fair point, I will add optional https use

> -) How do you update your fork with changes from origin to avoid a merge commit?
>   Thanks for pointing this out.
>   This is something i didn't take into account (and have probably
> pushed a merge commit a couple of times)
>   There is a way using the --rebase option during the pull command though

But --rebase do a lot more harm when working with a remote branch,
it's a good option when used locally, but since you've pushed out your
branch you should avoid it
https://github.com/apache/struts/pull/58/commits

> -) The readonly setting does indeed solve the accidental commits.

That's why I prefer this way when working on large things, even if I
can push directly to Apache :)

> -) Won't you have the same merge commits if there's been a lot of
> changes since you created your branch and want to pull in those
> changes before creating a pull request?

You don't have till your branch doesn't have conflicts with "master",
if you do have conflicts you must reverse merge "master" anyway. I
think this is the same with both approaches.

> -) When making a branch you could always create it from any chosen remote:
>    git fetch -p upstream
>    git checkout -b testupstreambranch upstream/master
> (where upstream is the remote you forked from)

Yes, that's true but you must remember about these extra params, with
my way "master" is always upstream/origin and branches are "forks"

> But you're right.
> Your suggested approach surely has some advantages, thanks for
> explaining them to me.

Cool, thanks for reviewing it and making fair points :)


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Christoph Nenning
Hi,


so far I used Stefaan's aproach, too. I was not aware of the
pulling/rebasing/merge-commit issues. Lukasz, would you add your
explanation to the html page?

IMHO seting up ssh keys is a big hurdle for newbies. I would recommend
usage of https urls and just mention that there is the option to use ssh.


Regards,
Christoph


> From: Lukasz Lenart <[hidden email]>
> To: Struts Developers List <[hidden email]>,
> Date: 04.02.2017 10:02
> Subject: Re: Documentation
>
> 2017-02-04 8:26 GMT+01:00 Stefaan Dutry <[hidden email]>:
> > I would like to start by saying that i didn't claim my way was better.
>
> Yes, I know that, don't get me wrong I just want to know if I am
> missing something and maybe there is a better way :)
>
> > -) why https way
> >   No need to set up ssh keys. (so basicaly just lazyness from my part)
>
> Fair point, I will add optional https use
>
> > -) How do you update your fork with changes from origin to avoid a
> merge commit?
> >   Thanks for pointing this out.
> >   This is something i didn't take into account (and have probably
> > pushed a merge commit a couple of times)
> >   There is a way using the --rebase option during the pull command
though

>
> But --rebase do a lot more harm when working with a remote branch,
> it's a good option when used locally, but since you've pushed out your
> branch you should avoid it
> https://github.com/apache/struts/pull/58/commits
>
> > -) The readonly setting does indeed solve the accidental commits.
>
> That's why I prefer this way when working on large things, even if I
> can push directly to Apache :)
>
> > -) Won't you have the same merge commits if there's been a lot of
> > changes since you created your branch and want to pull in those
> > changes before creating a pull request?
>
> You don't have till your branch doesn't have conflicts with "master",
> if you do have conflicts you must reverse merge "master" anyway. I
> think this is the same with both approaches.
>
> > -) When making a branch you could always create it from any chosen
remote:

> >    git fetch -p upstream
> >    git checkout -b testupstreambranch upstream/master
> > (where upstream is the remote you forked from)
>
> Yes, that's true but you must remember about these extra params, with
> my way "master" is always upstream/origin and branches are "forks"
>
> > But you're right.
> > Your suggested approach surely has some advantages, thanks for
> > explaining them to me.
>
> Cool, thanks for reviewing it and making fair points :)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

This Email was scanned by Sophos Anti Virus
Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
In reply to this post by Aleksandr Mashchenko
2017-02-02 20:32 GMT+01:00 Aleksandr Mashchenko <[hidden email]>:
> Maybe this can help: http://www.viaboxx.de/code/confluence2md/

Thanks, I was able to use it but it exports everything directly into
one file :\ but I can still used to start working on new Getting
started guide :)


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation

Lukasz Lenart
2017-02-15 21:00 GMT+01:00 Lukasz Lenart <[hidden email]>:
> 2017-02-02 20:32 GMT+01:00 Aleksandr Mashchenko <[hidden email]>:
>> Maybe this can help: http://www.viaboxx.de/code/confluence2md/
>
> Thanks, I was able to use it but it exports everything directly into
> one file :\ but I can still used to start working on new Getting
> started guide :)

This tool isn't perfect but at least it allows to start with something ;-)
I have exported the Getting started guide [1] and adjusted one page
[2] to see how it works. Let me know what do you think?

[1] http://struts.apache.org/getting-started/
[2] http://struts.apache.org/getting-started/how-to-create-a-struts2-web-application.html


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123