On May 29, 2012, at 10:13 AM, Vincent Massol wrote:

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

...

Dear community,

I would like to request for a new contrib project to store the Mail Archive application I'm currently writing.

Name: xwiki-application-mailarchive Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

Done: - https://github.com/xwiki-contrib/xwiki-application-mailarchive - JIRA: http://jira.xwiki.org/browse/XCONTRIB/component/12343 Enjoy ;) -Vincent

...

- For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me.

Ok, I'll just create a jira component for you for now.

...

- There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it

You can do that easily locally by configuring a local extension repo, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

...

The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ...

A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :)

:) you have time don't hurry, not sure I will have to push this right-away ... The other good news and why I want this git hub project, is that I just had official answer from my employer, that I can safely publish this project as an open-source project and they don't bother, I wasn't afraid but still it's a very good news :) 2012/5/29 Vincent Massol <[email protected]>:

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

...

Dear community,

I would like to request for a new contrib project to store the Mail Archive application I'm currently writing.

Name: xwiki-application-mailarchive Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

...

- For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me.

Ok, I'll just create a jira component for you for now.

...

- There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it

You can do that easily locally by configuring a local extension repo, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

...

The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ...

A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Tue, May 29, 2012 at 10:22 AM, Jeremie BOUSQUET <[email protected]> wrote:

:) you have time don't hurry, not sure I will have to push this right-away ...

The other good news and why I want this git hub project, is that I just had official answer from my employer, that I can safely publish this project as an open-source project and they don't bother, I wasn't afraid but still it's a very good news :)

Still, always nice to ear :)

2012/5/29 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

...

Dear community,

I would like to request for a new contrib project to store the Mail Archive application I'm currently writing.

Name: xwiki-application-mailarchive Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

...

- For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me.

Ok, I'll just create a jira component for you for now.

...

- There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it

You can do that easily locally by configuring a local extension repo, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

...

The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ...

A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hi Jeremie, On Jun 27, 2012, at 3:49 PM, Jeremie BOUSQUET wrote:

Hello,

...

PS: It's shaping up nicely, that's really cool :)

Thanks :) As I was a bit fed-up with the Java component part,

oh that's a pity, it's so nice to develop java components IMO ;)

I worked a little on nice things like UI look&feel, and revamped the forum view, for me at heart of the app navigation: http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication#HTopics

Nice!

The display adapts to the Color Theme in use, here Mint. I plan to add an admin option to display or not the statistics button, because I think some might want to restrict the user statistics viewing to admins only ... "Edit" is displayed only to persons with admin rights, or to the message author, "Reply" is displayed only for persons with edit rights (anyway reply is not implemented so it's only UI for now). I also plan, if one day I implement the syntax parser for email text/plain content, to by default hide quotes (with a showHide icon) as Gmail does.

@Vincent: I hijacked your avatar from Nabble, I hope you don't mind ;-) (of course if you do mind I'll remove that asap).

I don't mind at all :) Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt? Thanks -Vincent

Thanks, Jeremie

2012/5/29 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

...

Dear community,

I would like to request for a new contrib project to store the Mail Archive application I'm currently writing.

Name: xwiki-application-mailarchive Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

...

- For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me.

Ok, I'll just create a jira component for you for now.

...

- There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it

You can do that easily locally by configuring a local extension repo, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

...

The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ...

A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :)

Holidays: completed ... back on this. I have some requests: * I'd like to add a version in XWiki Contrib JIRA project, but it seems I don't have the right - or I don't know how to do. The version would be "Mail Archive Application 0.1", if someone could help me to add that :) * Do I need to deploy my maven project to your (or any) Nexus repository in order to add the extension to xwiki.org, or can it be done later or never ? Well, not really in order to add the extension, but more to have it installable by the extension manager ... thanks, Jeremie 2012/6/28 Jeremie BOUSQUET <[email protected]>:

Hello,

...

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt?

Why not, I just need to perform some manual tests on basic functionality (mail loading), as I didn't since last refactorings. It will also depend on my bandwith, but I think it'll have to wait till I'm back from holidays (not here next week). Might be better also because this way I'll be available to answer questions, if any.

Also I should then really warn users downloading it, that next versions might reveal incompatibilities and need to purge and reload every loaded mails. I really want to focus on that before publishing a real 1.0, and provide some real automated migration using the mail Store for next versions.

Writing java components is nice, but writing UI is more fun for me ;-)

BR, Jeremie

2012/6/28 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On Jun 27, 2012, at 3:49 PM, Jeremie BOUSQUET wrote:

...

Hello,

...

PS: It's shaping up nicely, that's really cool :)

Thanks :) As I was a bit fed-up with the Java component part,

oh that's a pity, it's so nice to develop java components IMO ;)

...

I worked a little on nice things like UI look&feel, and revamped the forum view, for me at heart of the app navigation: http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication#HTopics

Nice!

...

The display adapts to the Color Theme in use, here Mint. I plan to add an admin option to display or not the statistics button, because I think some might want to restrict the user statistics viewing to admins only ... "Edit" is displayed only to persons with admin rights, or to the message author, "Reply" is displayed only for persons with edit rights (anyway reply is not implemented so it's only UI for now). I also plan, if one day I implement the syntax parser for email text/plain content, to by default hide quotes (with a showHide icon) as Gmail does.

@Vincent: I hijacked your avatar from Nabble, I hope you don't mind ;-) (of course if you do mind I'll remove that asap).

I don't mind at all :)

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt?

Thanks -Vincent

...

Thanks, Jeremie

2012/5/29 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

...

Dear community,

I would like to request for a new contrib project to store the Mail Archive application I'm currently writing.

Name: xwiki-application-mailarchive Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

...

- For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me.

Ok, I'll just create a jira component for you for now.

...

- There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it

You can do that easily locally by configuring a local extension repo, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

...

The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ...

A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :)

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Thanks Jerome, Another thing about this project: I'd like to prepare things, and particularly the user guide part, so it's available when I'll publish the extension. For this particular use-case though, I'd like to extend the user/admin guide part on more than one page, as it may be quite large. Where should I put these pages ? Thanks, Jeremie 2012/8/9 Jerome Velociter <[email protected]>:

On 08/09/2012 03:29 PM, Jeremie BOUSQUET wrote:

...

Holidays: completed ... back on this.

I have some requests:

* I'd like to add a version in XWiki Contrib JIRA project, but it seems I don't have the right - or I don't know how to do. The version would be "Mail Archive Application 0.1", if someone could help me to add that :)

* Do I need to deploy my maven project to your (or any) Nexus repository in order to add the extension to xwiki.org, or can it be done later or never ? Well, not really in order to add the extension, but more to have it installable by the extension manager ...

You need to point the dependency management of your project to our Nexus staging repository. See http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HReleasetheproject

Then you'll need an admin to create you a nexus account.

Jerome

...

thanks,

Jeremie

2012/6/28 Jeremie BOUSQUET <[email protected]>:

...

Hello,

...

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt?

Why not, I just need to perform some manual tests on basic functionality (mail loading), as I didn't since last refactorings. It will also depend on my bandwith, but I think it'll have to wait till I'm back from holidays (not here next week). Might be better also because this way I'll be available to answer questions, if any.

Also I should then really warn users downloading it, that next versions might reveal incompatibilities and need to purge and reload every loaded mails. I really want to focus on that before publishing a real 1.0, and provide some real automated migration using the mail Store for next versions.

Writing java components is nice, but writing UI is more fun for me ;-)

BR, Jeremie

2012/6/28 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On Jun 27, 2012, at 3:49 PM, Jeremie BOUSQUET wrote:

...

Hello,

...

PS: It's shaping up nicely, that's really cool :)

Thanks :) As I was a bit fed-up with the Java component part,

oh that's a pity, it's so nice to develop java components IMO ;)

...

I worked a little on nice things like UI look&feel, and revamped the forum view, for me at heart of the app navigation:

http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication#HTopics

Nice!

...

The display adapts to the Color Theme in use, here Mint. I plan to add an admin option to display or not the statistics button, because I think some might want to restrict the user statistics viewing to admins only ... "Edit" is displayed only to persons with admin rights, or to the message author, "Reply" is displayed only for persons with edit rights (anyway reply is not implemented so it's only UI for now). I also plan, if one day I implement the syntax parser for email text/plain content, to by default hide quotes (with a showHide icon) as Gmail does.

@Vincent: I hijacked your avatar from Nabble, I hope you don't mind ;-) (of course if you do mind I'll remove that asap).

I don't mind at all :)

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt?

Thanks -Vincent

...

Thanks, Jeremie

2012/5/29 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote:

> Dear community, > > I would like to request for a new contrib project to store the Mail > Archive application I'm currently writing. > > Name: xwiki-application-mailarchive > Description: A mailing-list archive application.

I'm handling it. Give me 10 minutes.

> - For now a GitHub project to store sources should be fine. My > username on GitHub is "jbousque". > - For Jira it might be useful to have a project once the application > is released "officially", that is still not the case. Meanwhile the > generic project is ok for me.

Ok, I'll just create a jira component for you for now.

> - There is a specific page in Design space on xwiki.org : > http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , > but for now no extension has been added. I would like if possible to > test my extension (automatic install with dependencies) before > publishing it

You can do that easily locally by configuring a local extension repo, see

http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi...

> The Design page also gives some info about the current state and > progress, and some screenshots. There is many remaining work, but it > begins to look like something usable. The bad side is the lack of > unit > tests most of all ... > > A question : the groupId "org.xwiki.contrib" is to be used, do I have > to use this exact groupId or can there be sublevels if needed ? > If so I would use org.xwiki.contrib.mailarchive as groupId.

You can have as many sublevels as you wish.

Thanks -Vincent

PS: It's shaping up nicely, that's really cool :)

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Peace, ---Jerome

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote:

Humm ... Just thinking I might put that directly inside my app xar ... WDYT ?

I'm a big fan of self-documenting applications. It has the great advantage of always offering documentation matching the version in use. But you might also want to offer the latest released version documentation online. I think there are some extensions that have documentation that spans several pages, but honestly I don't know if this is something we want/we agreed upon. I'll leave it to others to bring more information on this subject. There is the contrib wiki also which could be a candidate. Jerome

2012/8/9 Jeremie BOUSQUET <[email protected]>:

...

Thanks Jerome,

Another thing about this project: I'd like to prepare things, and particularly the user guide part, so it's available when I'll publish the extension. For this particular use-case though, I'd like to extend the user/admin guide part on more than one page, as it may be quite large. Where should I put these pages ?

Thanks, Jeremie

2012/8/9 Jerome Velociter <[email protected]>:

...

On 08/09/2012 03:29 PM, Jeremie BOUSQUET wrote:

...

Holidays: completed ... back on this.

I have some requests:

* I'd like to add a version in XWiki Contrib JIRA project, but it seems I don't have the right - or I don't know how to do. The version would be "Mail Archive Application 0.1", if someone could help me to add that :)

* Do I need to deploy my maven project to your (or any) Nexus repository in order to add the extension to xwiki.org, or can it be done later or never ? Well, not really in order to add the extension, but more to have it installable by the extension manager ...

You need to point the dependency management of your project to our Nexus staging repository. See http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HReleasetheproject

Then you'll need an admin to create you a nexus account.

Jerome

...

thanks,

Jeremie

2012/6/28 Jeremie BOUSQUET <[email protected]>:

...

Hello,

...

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt? Why not, I just need to perform some manual tests on basic functionality (mail loading), as I didn't since last refactorings. It will also depend on my bandwith, but I think it'll have to wait till I'm back from holidays (not here next week). Might be better also because this way I'll be available to answer questions, if any.

Also I should then really warn users downloading it, that next versions might reveal incompatibilities and need to purge and reload every loaded mails. I really want to focus on that before publishing a real 1.0, and provide some real automated migration using the mail Store for next versions.

Writing java components is nice, but writing UI is more fun for me ;-)

BR, Jeremie

2012/6/28 Vincent Massol <[email protected]>:

...

Hi Jeremie,

On Jun 27, 2012, at 3:49 PM, Jeremie BOUSQUET wrote:

> Hello, > >> PS: It's shaping up nicely, that's really cool :) > Thanks :) > As I was a bit fed-up with the Java component part, oh that's a pity, it's so nice to develop java components IMO ;)

> I worked a little > on nice things like UI look&feel, and revamped the forum view, for me > at heart of the app navigation: > > http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication#HTopics Nice!

> The display adapts to the Color Theme in use, here Mint. > I plan to add an admin option to display or not the statistics button, > because I think some might want to restrict the user statistics > viewing to admins only ... "Edit" is displayed only to persons with > admin rights, or to the message author, "Reply" is displayed only for > persons with edit rights (anyway reply is not implemented so it's only > UI for now). > I also plan, if one day I implement the syntax parser for email > text/plain content, to by default hide quotes (with a showHide icon) > as Gmail does. > > @Vincent: I hijacked your avatar from Nabble, I hope you don't mind > ;-) (of course if you do mind I'll remove that asap). I don't mind at all :)

Since it seems to be already well advanced, it could be nice to start publishing a 0.1 version of it on extensions.xwiki.org so that people can start installing it in their wikis to provide feedback to you, wdyt?

Thanks -Vincent

> Thanks, > Jeremie > > 2012/5/29 Vincent Massol <[email protected]>: >> Hi Jeremie, >> >> On May 29, 2012, at 10:07 AM, Jeremie BOUSQUET wrote: >> >>> Dear community, >>> >>> I would like to request for a new contrib project to store the Mail >>> Archive application I'm currently writing. >>> >>> Name: xwiki-application-mailarchive >>> Description: A mailing-list archive application. >> I'm handling it. Give me 10 minutes. >> >>> - For now a GitHub project to store sources should be fine. My >>> username on GitHub is "jbousque". >>> - For Jira it might be useful to have a project once the application >>> is released "officially", that is still not the case. Meanwhile the >>> generic project is ok for me. >> Ok, I'll just create a jira component for you for now. >> >>> - There is a specific page in Design space on xwiki.org : >>> http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , >>> but for now no extension has been added. I would like if possible to >>> test my extension (automatic install with dependencies) before >>> publishing it >> You can do that easily locally by configuring a local extension repo, >> see >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Module#HConfi... >> >>> The Design page also gives some info about the current state and >>> progress, and some screenshots. There is many remaining work, but it >>> begins to look like something usable. The bad side is the lack of >>> unit >>> tests most of all ... >>> >>> A question : the groupId "org.xwiki.contrib" is to be used, do I have >>> to use this exact groupId or can there be sublevels if needed ? >>> If so I would use org.xwiki.contrib.mailarchive as groupId. >> You can have as many sublevels as you wish. >> >> Thanks >> -Vincent >> >> PS: It's shaping up nicely, that's really cool :) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Peace, ---Jerome

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Peace, —Jerome

On 08/09/2012 10:38 AM, Jerome Velociter wrote:

On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote:

...

Humm ... Just thinking I might put that directly inside my app xar ... WDYT ?

I'm a big fan of self-documenting applications. It has the great advantage of always offering documentation matching the version in use.

But you might also want to offer the latest released version documentation online. I think there are some extensions that have documentation that spans several pages, but honestly I don't know if this is something we want/we agreed upon. I'll leave it to others to bring more information on this subject. There is the contrib wiki also which could be a candidate.

I've seen extensions with a lot of documentation on their extension page, and I've seen things documented in several places. Personally, I don't like huge extension pages. So I'd say that: - There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

...

2012/8/9 Jeremie BOUSQUET <[email protected]>:

...

Thanks Jerome,

Another thing about this project: I'd like to prepare things, and particularly the user guide part, so it's available when I'll publish the extension. For this particular use-case though, I'd like to extend the user/admin guide part on more than one page, as it may be quite large. Where should I put these pages ?

Thanks, Jeremie

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Jeremie and all, Back from holidays too :) Cool to see progress on this! Ok I've parsed this thread and here's my take: * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). * Nexus: I'll create an account for you. Is that ok? Thanks -Vincent On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote:

...

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

I think it's the best solution. Since the space I currently use for the main pages of my app is "MailArchive", I would propose to use the same for the documentation space and put pages under: http://contrib.xwiki.org/xwiki/bin/view/MailArchive/

That way publishing the doc online to contrib wiki would be straightforward with selective import.

Br, Jeremie

2012/8/9 Sergiu Dumitriu <[email protected]>:

...

On 08/09/2012 10:38 AM, Jerome Velociter wrote:

...

On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote:

...

Humm ... Just thinking I might put that directly inside my app xar ... WDYT ?

I'm a big fan of self-documenting applications. It has the great advantage of always offering documentation matching the version in use.

But you might also want to offer the latest released version documentation online. I think there are some extensions that have documentation that spans several pages, but honestly I don't know if this is something we want/we agreed upon. I'll leave it to others to bring more information on this subject. There is the contrib wiki also which could be a candidate.

I've seen extensions with a lot of documentation on their extension page, and I've seen things documented in several places. Personally, I don't like huge extension pages.

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

...

...

2012/8/9 Jeremie BOUSQUET <[email protected]>:

...

Thanks Jerome,

Another thing about this project: I'd like to prepare things, and particularly the user guide part, so it's available when I'll publish the extension. For this particular use-case though, I'd like to extend the user/admin guide part on more than one page, as it may be quite large. Where should I put these pages ?

Thanks, Jeremie

On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote:

...

Hi Jeremie and all,

Back from holidays too :) Cool to see progress on this!

Ok I've parsed this thread and here's my take:

* JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it

ok, Thomas is doing it ATM, should be ready real soon :)

Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the rights to do pretty much anything in this project.

...

* Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). * Nexus: I'll create an account for you.

I see you already have a user, cool.

Thanks -Vincent

...

Is that ok?

Thanks -Vincent

On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote:

...

...

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

I think it's the best solution. Since the space I currently use for the main pages of my app is "MailArchive", I would propose to use the same for the documentation space and put pages under: http://contrib.xwiki.org/xwiki/bin/view/MailArchive/

That way publishing the doc online to contrib wiki would be straightforward with selective import.

Br, Jeremie

2012/8/9 Sergiu Dumitriu <[email protected]>:

...

On 08/09/2012 10:38 AM, Jerome Velociter wrote:

...

On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote:

...

Humm ... Just thinking I might put that directly inside my app xar ... WDYT ?

I'm a big fan of self-documenting applications. It has the great advantage of always offering documentation matching the version in use.

But you might also want to offer the latest released version documentation online. I think there are some extensions that have documentation that spans several pages, but honestly I don't know if this is something we want/we agreed upon. I'll leave it to others to bring more information on this subject. There is the contrib wiki also which could be a candidate.

I've seen extensions with a lot of documentation on their extension page, and I've seen things documented in several places. Personally, I don't like huge extension pages.

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

...

...

2012/8/9 Jeremie BOUSQUET <[email protected]>: > > Thanks Jerome, > > Another thing about this project: I'd like to prepare things, and > particularly the user guide part, so it's available when I'll publish > the extension. > For this particular use-case though, I'd like to extend the user/admin > guide part on more than one page, as it may be quite large. > Where should I put these pages ? > > Thanks, > Jeremie

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hi Jeremie, On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote:

Thanks Vincent & Sergiu,

So, is it ok if I put docs to http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation (and others in same space) ?

By now I've almost finished writing first versions of: * MailArchive.Documentation (home page) * MailArchive.UserGuide * MailArchive.AdminGuide * MailArchive.OperationsGuide * MailArchive.TroubleShooting

Actually all extensions go in the Extension space. So I'd go for: Extension.Mail+Archive (home page) Extension.Mail+Archive+User+Guide Extension.Mail+Archive+Admin+Guide Extension.Mail+Archive+Operations+Guide Extension.Mail+Archive+Troubleshooting (troubleshooting is a single word AFAIK) The "+" represents a white space. Thanks -Vincent

I should be able to release 0.1 soon ...

Br, Jeremie

2012/8/13 Thomas Mortagne <[email protected]>:

...

On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

...

On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote:

...

Hi Jeremie and all,

Back from holidays too :) Cool to see progress on this!

Ok I've parsed this thread and here's my take:

* JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it

ok, Thomas is doing it ATM, should be ready real soon :)

Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the rights to do pretty much anything in this project.

...

...

* Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). * Nexus: I'll create an account for you.

I see you already have a user, cool.

Thanks -Vincent

...

Is that ok?

Thanks -Vincent

On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote:

...

...

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

I think it's the best solution. Since the space I currently use for the main pages of my app is "MailArchive", I would propose to use the same for the documentation space and put pages under: http://contrib.xwiki.org/xwiki/bin/view/MailArchive/

That way publishing the doc online to contrib wiki would be straightforward with selective import.

Br, Jeremie

2012/8/9 Sergiu Dumitriu <[email protected]>:

...

On 08/09/2012 10:38 AM, Jerome Velociter wrote: > > On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >> >> Humm ... Just thinking I might put that directly inside my app xar ... >> WDYT ? > > > I'm a big fan of self-documenting applications. It has the great > advantage of always offering documentation matching the version in use. > > But you might also want to offer the latest released version > documentation online. I think there are some extensions that have > documentation that spans several pages, but honestly I don't know if > this is something we want/we agreed upon. I'll leave it to others to > bring more information on this subject. There is the contrib wiki also > which could be a candidate. >

I've seen extensions with a lot of documentation on their extension page, and I've seen things documented in several places. Personally, I don't like huge extension pages.

So I'd say that:

- There should be some documentation on the extension page, at least a description of the project, some usage scenarios, some screenshots, and a list of the features - I agree that the full documentation should be included in the application itself - The same full documentation should also be available online, and the contrib wiki seems to be the right place (in a dedicated space)

> >> >> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>> >>> Thanks Jerome, >>> >>> Another thing about this project: I'd like to prepare things, and >>> particularly the user guide part, so it's available when I'll publish >>> the extension. >>> For this particular use-case though, I'd like to extend the user/admin >>> guide part on more than one page, as it may be quite large. >>> Where should I put these pages ? >>> >>> Thanks, >>> Jeremie

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, I saw that, no problem I'll update the groupId before doing the release :) Br, Jeremie 2012/8/16 Vincent Massol <[email protected]>:

Hi Jeremie,

In case you haven't followed we've updated the contrib rule for the maven group id, see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome

It would be great if you could update your groupid before you do the first release :)

Thanks -Vincent

On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote:

...

Thanks Vincent & Sergiu,

So, is it ok if I put docs to http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation (and others in same space) ?

By now I've almost finished writing first versions of: * MailArchive.Documentation (home page) * MailArchive.UserGuide * MailArchive.AdminGuide * MailArchive.OperationsGuide * MailArchive.TroubleShooting

I should be able to release 0.1 soon ...

Br, Jeremie

2012/8/13 Thomas Mortagne <[email protected]>:

...

On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

...

On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote:

...

Hi Jeremie and all,

Back from holidays too :) Cool to see progress on this!

Ok I've parsed this thread and here's my take:

* JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it

ok, Thomas is doing it ATM, should be ready real soon :)

Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the rights to do pretty much anything in this project.

...

...

* Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). * Nexus: I'll create an account for you.

I see you already have a user, cool.

Thanks -Vincent

...

Is that ok?

Thanks -Vincent

On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote:

...

> So I'd say that: > > - There should be some documentation on the extension page, at least a > description of the project, some usage scenarios, some screenshots, and a > list of the features > - I agree that the full documentation should be included in the application > itself > - The same full documentation should also be available online, and the > contrib wiki seems to be the right place (in a dedicated space)

I think it's the best solution. Since the space I currently use for the main pages of my app is "MailArchive", I would propose to use the same for the documentation space and put pages under: http://contrib.xwiki.org/xwiki/bin/view/MailArchive/

That way publishing the doc online to contrib wiki would be straightforward with selective import.

Br, Jeremie

2012/8/9 Sergiu Dumitriu <[email protected]>: > On 08/09/2012 10:38 AM, Jerome Velociter wrote: >> >> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>> >>> Humm ... Just thinking I might put that directly inside my app xar ... >>> WDYT ? >> >> >> I'm a big fan of self-documenting applications. It has the great >> advantage of always offering documentation matching the version in use. >> >> But you might also want to offer the latest released version >> documentation online. I think there are some extensions that have >> documentation that spans several pages, but honestly I don't know if >> this is something we want/we agreed upon. I'll leave it to others to >> bring more information on this subject. There is the contrib wiki also >> which could be a candidate. >> > > I've seen extensions with a lot of documentation on their extension page, > and I've seen things documented in several places. Personally, I don't like > huge extension pages. > > So I'd say that: > > - There should be some documentation on the extension page, at least a > description of the project, some usage scenarios, some screenshots, and a > list of the features > - I agree that the full documentation should be included in the application > itself > - The same full documentation should also be available online, and the > contrib wiki seems to be the right place (in a dedicated space) > > >> >>> >>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>> >>>> Thanks Jerome, >>>> >>>> Another thing about this project: I'd like to prepare things, and >>>> particularly the user guide part, so it's available when I'll publish >>>> the extension. >>>> For this particular use-case though, I'd like to extend the user/admin >>>> guide part on more than one page, as it may be quite large. >>>> Where should I put these pages ? >>>> >>>> Thanks, >>>> Jeremie

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET <[email protected]> wrote:

Hi Community,

I'm trying to release my contrib project to nexus staging but having difficulties.

Couldn't manage to "git push" correctly from maven to github (though "git push" command-line works), so I use "-DpushChanges=false" during release:prepare and release:perform, and do a "git push" manually after release:prepare.

You sure you <scm> is right ? I see you indicated the https in <developerConnection>, you should probably use the ssh one instead.

Now getting that during release:perform (***** were added, it's a correct path behind) :

[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists())

Of course javadoc does not exist at this level, as I'm trying to release from root aggregator. What I don't understand is why the enforcer rule fails ? Aggregator is of type "pom" as expected.

My command-line was:

mvn release:perform -DpushChanges=false -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git -Dtag=xwiki-contrib-mailarchive-0.1

Thanks, Jeremie

2012/8/17 Jeremie BOUSQUET <[email protected]>:

...

Hi Vincent,

I saw that, no problem I'll update the groupId before doing the release :)

Br, Jeremie

2012/8/16 Vincent Massol <[email protected]>:

...

Hi Jeremie,

In case you haven't followed we've updated the contrib rule for the maven group id, see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome

It would be great if you could update your groupid before you do the first release :)

Thanks -Vincent

On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote:

...

Thanks Vincent & Sergiu,

So, is it ok if I put docs to http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation (and others in same space) ?

By now I've almost finished writing first versions of: * MailArchive.Documentation (home page) * MailArchive.UserGuide * MailArchive.AdminGuide * MailArchive.OperationsGuide * MailArchive.TroubleShooting

I should be able to release 0.1 soon ...

Br, Jeremie

2012/8/13 Thomas Mortagne <[email protected]>:

...

On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

...

On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote:

> Hi Jeremie and all, > > Back from holidays too :) Cool to see progress on this! > > Ok I've parsed this thread and here's my take: > > * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it

ok, Thomas is doing it ATM, should be ready real soon :)

Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the rights to do pretty much anything in this project.

...

> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). > * Nexus: I'll create an account for you.

I see you already have a user, cool.

Thanks -Vincent

> Is that ok? > > Thanks > -Vincent > > On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: > >>> So I'd say that: >>> >>> - There should be some documentation on the extension page, at least a >>> description of the project, some usage scenarios, some screenshots, and a >>> list of the features >>> - I agree that the full documentation should be included in the application >>> itself >>> - The same full documentation should also be available online, and the >>> contrib wiki seems to be the right place (in a dedicated space) >> >> I think it's the best solution. >> Since the space I currently use for the main pages of my app is >> "MailArchive", I would propose to use the same for the documentation >> space and put pages under: >> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >> >> That way publishing the doc online to contrib wiki would be >> straightforward with selective import. >> >> Br, >> Jeremie >> >> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>> >>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>> >>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>> WDYT ? >>>> >>>> >>>> I'm a big fan of self-documenting applications. It has the great >>>> advantage of always offering documentation matching the version in use. >>>> >>>> But you might also want to offer the latest released version >>>> documentation online. I think there are some extensions that have >>>> documentation that spans several pages, but honestly I don't know if >>>> this is something we want/we agreed upon. I'll leave it to others to >>>> bring more information on this subject. There is the contrib wiki also >>>> which could be a candidate. >>>> >>> >>> I've seen extensions with a lot of documentation on their extension page, >>> and I've seen things documented in several places. Personally, I don't like >>> huge extension pages. >>> >>> So I'd say that: >>> >>> - There should be some documentation on the extension page, at least a >>> description of the project, some usage scenarios, some screenshots, and a >>> list of the features >>> - I agree that the full documentation should be included in the application >>> itself >>> - The same full documentation should also be available online, and the >>> contrib wiki seems to be the right place (in a dedicated space) >>> >>> >>>> >>>>> >>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>> >>>>>> Thanks Jerome, >>>>>> >>>>>> Another thing about this project: I'd like to prepare things, and >>>>>> particularly the user guide part, so it's available when I'll publish >>>>>> the extension. >>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>> guide part on more than one page, as it may be quite large. >>>>>> Where should I put these pages ? >>>>>> >>>>>> Thanks, >>>>>> Jeremie >

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Progressing but still failing ... ... it's like a nightmare. I gave up pushing to github from maven, I think there's something wrong with windows/mysysgit/cygwin somehow. Now trying to release tag "xwiki-contrib-mailarchive-0.1": - it's pushed on github - if I download the related zip (in "tag" tab on github), it's complete - if I "release:perform" from maven, target/checkout folder contains everything except pom.xml files ... of course release fails How can my pom.xml files be deleted when running "git checkout xwiki-contrib-mailarchive-0.1", while I can see them in my local history and on github ??? 2012/8/31 Jeremie BOUSQUET <[email protected]>:

I tried both, but not tried exhaustively possible combinations (ssh/https, maven/git conf, and my network proxy that comes in the way ...) BTW I'm not sure about how credentials for github should be fed to maven depending on SSH/HTTPS url connection used. Authentication with keys works from git command-line to push to github, but I think I miss some configuration maven-side. Actually from maven "git push" time-outs, or freezes forever, depending on protocol used.

2012/8/31 Thomas Mortagne <[email protected]>:

...

On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hi Community,

I'm trying to release my contrib project to nexus staging but having difficulties.

Couldn't manage to "git push" correctly from maven to github (though "git push" command-line works), so I use "-DpushChanges=false" during release:prepare and release:perform, and do a "git push" manually after release:prepare.

You sure you <scm> is right ? I see you indicated the https in <developerConnection>, you should probably use the ssh one instead.

...

Now getting that during release:perform (***** were added, it's a correct path behind) :

[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists())

Of course javadoc does not exist at this level, as I'm trying to release from root aggregator. What I don't understand is why the enforcer rule fails ? Aggregator is of type "pom" as expected.

My command-line was:

mvn release:perform -DpushChanges=false -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git -Dtag=xwiki-contrib-mailarchive-0.1

Thanks, Jeremie

2012/8/17 Jeremie BOUSQUET <[email protected]>:

...

Hi Vincent,

I saw that, no problem I'll update the groupId before doing the release :)

Br, Jeremie

2012/8/16 Vincent Massol <[email protected]>:

...

Hi Jeremie,

In case you haven't followed we've updated the contrib rule for the maven group id, see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome

It would be great if you could update your groupid before you do the first release :)

Thanks -Vincent

On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote:

...

Thanks Vincent & Sergiu,

So, is it ok if I put docs to http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation (and others in same space) ?

By now I've almost finished writing first versions of: * MailArchive.Documentation (home page) * MailArchive.UserGuide * MailArchive.AdminGuide * MailArchive.OperationsGuide * MailArchive.TroubleShooting

I should be able to release 0.1 soon ...

Br, Jeremie

2012/8/13 Thomas Mortagne <[email protected]>: > On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >> >> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >> >>> Hi Jeremie and all, >>> >>> Back from holidays too :) Cool to see progress on this! >>> >>> Ok I've parsed this thread and here's my take: >>> >>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >> >> ok, Thomas is doing it ATM, should be ready real soon :) > > Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the > rights to do pretty much anything in this project. > >> >>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>> * Nexus: I'll create an account for you. >> >> I see you already have a user, cool. >> >> Thanks >> -Vincent >> >>> Is that ok? >>> >>> Thanks >>> -Vincent >>> >>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>> >>>>> So I'd say that: >>>>> >>>>> - There should be some documentation on the extension page, at least a >>>>> description of the project, some usage scenarios, some screenshots, and a >>>>> list of the features >>>>> - I agree that the full documentation should be included in the application >>>>> itself >>>>> - The same full documentation should also be available online, and the >>>>> contrib wiki seems to be the right place (in a dedicated space) >>>> >>>> I think it's the best solution. >>>> Since the space I currently use for the main pages of my app is >>>> "MailArchive", I would propose to use the same for the documentation >>>> space and put pages under: >>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>> >>>> That way publishing the doc online to contrib wiki would be >>>> straightforward with selective import. >>>> >>>> Br, >>>> Jeremie >>>> >>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>> >>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>> >>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>> WDYT ? >>>>>> >>>>>> >>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>> advantage of always offering documentation matching the version in use. >>>>>> >>>>>> But you might also want to offer the latest released version >>>>>> documentation online. I think there are some extensions that have >>>>>> documentation that spans several pages, but honestly I don't know if >>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>> bring more information on this subject. There is the contrib wiki also >>>>>> which could be a candidate. >>>>>> >>>>> >>>>> I've seen extensions with a lot of documentation on their extension page, >>>>> and I've seen things documented in several places. Personally, I don't like >>>>> huge extension pages. >>>>> >>>>> So I'd say that: >>>>> >>>>> - There should be some documentation on the extension page, at least a >>>>> description of the project, some usage scenarios, some screenshots, and a >>>>> list of the features >>>>> - I agree that the full documentation should be included in the application >>>>> itself >>>>> - The same full documentation should also be available online, and the >>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>> >>>>>>>> Thanks Jerome, >>>>>>>> >>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>> the extension. >>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>> Where should I put these pages ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jeremie >>> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Wow, eventually, it worked ... Had to switch to using maven-release-plugin last version (2.3.2) instead of the one from xwiki. Now I'm ... back to the initial issue with the enforcer : [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado c.jar").exists()) [INFO] ------------------------------------------------------------------------ Grrrr ! 2012/9/1 Jeremie BOUSQUET <[email protected]>:

I eventually was able to use push to git from maven with release plugin (had to reinstall git with more preservative options).

But previous issue is still there: when checking-out my tag from local clone in target/checkout, pom.xml files are not there so there's nothing to build for maven ...

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Progressing but still failing ...

... it's like a nightmare.

I gave up pushing to github from maven, I think there's something wrong with windows/mysysgit/cygwin somehow.

Now trying to release tag "xwiki-contrib-mailarchive-0.1": - it's pushed on github - if I download the related zip (in "tag" tab on github), it's complete - if I "release:perform" from maven, target/checkout folder contains everything except pom.xml files ... of course release fails

How can my pom.xml files be deleted when running "git checkout xwiki-contrib-mailarchive-0.1", while I can see them in my local history and on github ???

2012/8/31 Jeremie BOUSQUET <[email protected]>:

...

I tried both, but not tried exhaustively possible combinations (ssh/https, maven/git conf, and my network proxy that comes in the way ...) BTW I'm not sure about how credentials for github should be fed to maven depending on SSH/HTTPS url connection used. Authentication with keys works from git command-line to push to github, but I think I miss some configuration maven-side. Actually from maven "git push" time-outs, or freezes forever, depending on protocol used.

2012/8/31 Thomas Mortagne <[email protected]>:

...

On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hi Community,

I'm trying to release my contrib project to nexus staging but having difficulties.

Couldn't manage to "git push" correctly from maven to github (though "git push" command-line works), so I use "-DpushChanges=false" during release:prepare and release:perform, and do a "git push" manually after release:prepare.

You sure you <scm> is right ? I see you indicated the https in <developerConnection>, you should probably use the ssh one instead.

...

Now getting that during release:perform (***** were added, it's a correct path behind) :

[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists())

Of course javadoc does not exist at this level, as I'm trying to release from root aggregator. What I don't understand is why the enforcer rule fails ? Aggregator is of type "pom" as expected.

My command-line was:

mvn release:perform -DpushChanges=false -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git -Dtag=xwiki-contrib-mailarchive-0.1

Thanks, Jeremie

2012/8/17 Jeremie BOUSQUET <[email protected]>:

...

Hi Vincent,

I saw that, no problem I'll update the groupId before doing the release :)

Br, Jeremie

2012/8/16 Vincent Massol <[email protected]>: > Hi Jeremie, > > In case you haven't followed we've updated the contrib rule for the maven group id, see > http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome > > It would be great if you could update your groupid before you do the first release :) > > Thanks > -Vincent > > On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: > >> Thanks Vincent & Sergiu, >> >> So, is it ok if I put docs to >> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >> (and others in same space) ? >> >> By now I've almost finished writing first versions of: >> * MailArchive.Documentation (home page) >> * MailArchive.UserGuide >> * MailArchive.AdminGuide >> * MailArchive.OperationsGuide >> * MailArchive.TroubleShooting >> >> I should be able to release 0.1 soon ... >> >> Br, >> Jeremie >> >> 2012/8/13 Thomas Mortagne <[email protected]>: >>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>> >>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>> >>>>> Hi Jeremie and all, >>>>> >>>>> Back from holidays too :) Cool to see progress on this! >>>>> >>>>> Ok I've parsed this thread and here's my take: >>>>> >>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>> >>>> ok, Thomas is doing it ATM, should be ready real soon :) >>> >>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>> rights to do pretty much anything in this project. >>> >>>> >>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>> * Nexus: I'll create an account for you. >>>> >>>> I see you already have a user, cool. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Is that ok? >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>> >>>>>>> So I'd say that: >>>>>>> >>>>>>> - There should be some documentation on the extension page, at least a >>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>> list of the features >>>>>>> - I agree that the full documentation should be included in the application >>>>>>> itself >>>>>>> - The same full documentation should also be available online, and the >>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>> >>>>>> I think it's the best solution. >>>>>> Since the space I currently use for the main pages of my app is >>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>> space and put pages under: >>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>> >>>>>> That way publishing the doc online to contrib wiki would be >>>>>> straightforward with selective import. >>>>>> >>>>>> Br, >>>>>> Jeremie >>>>>> >>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>> >>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>> >>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>> WDYT ? >>>>>>>> >>>>>>>> >>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>> >>>>>>>> But you might also want to offer the latest released version >>>>>>>> documentation online. I think there are some extensions that have >>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>> which could be a candidate. >>>>>>>> >>>>>>> >>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>> huge extension pages. >>>>>>> >>>>>>> So I'd say that: >>>>>>> >>>>>>> - There should be some documentation on the extension page, at least a >>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>> list of the features >>>>>>> - I agree that the full documentation should be included in the application >>>>>>> itself >>>>>>> - The same full documentation should also be available online, and the >>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> >>>>>>>>>> Thanks Jerome, >>>>>>>>>> >>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>> the extension. >>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>> Where should I put these pages ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jeremie >>>>> >>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

(groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts xwiki-contrib-mail, xwiki-contrib-mailarchive-api, xwiki-contrib-mailarchive-ui) 2012/9/2 Jeremie BOUSQUET <[email protected]>:

So after selectively deactivating execution of "enforce-javadoc-exists" for my root pom, and configuration of gpg, I could successfully deploy mail archive artifacts to nexus staging !

Would someone kindly promote it ? :)

Thanks, Jeremie

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Wow, eventually, it worked ... Had to switch to using maven-release-plugin last version (2.3.2) instead of the one from xwiki.

Now I'm ... back to the initial issue with the enforcer :

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado c.jar").exists()) [INFO] ------------------------------------------------------------------------

Grrrr !

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

I eventually was able to use push to git from maven with release plugin (had to reinstall git with more preservative options).

But previous issue is still there: when checking-out my tag from local clone in target/checkout, pom.xml files are not there so there's nothing to build for maven ...

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Progressing but still failing ...

... it's like a nightmare.

I gave up pushing to github from maven, I think there's something wrong with windows/mysysgit/cygwin somehow.

Now trying to release tag "xwiki-contrib-mailarchive-0.1": - it's pushed on github - if I download the related zip (in "tag" tab on github), it's complete - if I "release:perform" from maven, target/checkout folder contains everything except pom.xml files ... of course release fails

How can my pom.xml files be deleted when running "git checkout xwiki-contrib-mailarchive-0.1", while I can see them in my local history and on github ???

2012/8/31 Jeremie BOUSQUET <[email protected]>:

...

I tried both, but not tried exhaustively possible combinations (ssh/https, maven/git conf, and my network proxy that comes in the way ...) BTW I'm not sure about how credentials for github should be fed to maven depending on SSH/HTTPS url connection used. Authentication with keys works from git command-line to push to github, but I think I miss some configuration maven-side. Actually from maven "git push" time-outs, or freezes forever, depending on protocol used.

2012/8/31 Thomas Mortagne <[email protected]>:

...

On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET <[email protected]> wrote: > Hi Community, > > I'm trying to release my contrib project to nexus staging but having > difficulties. > > Couldn't manage to "git push" correctly from maven to github (though > "git push" command-line works), so I use "-DpushChanges=false" during > release:prepare and release:perform, and do a "git push" manually > after release:prepare.

You sure you <scm> is right ? I see you indicated the https in <developerConnection>, you should probably use the ssh one instead.

> > Now getting that during release:perform (***** were added, it's a > correct path behind) : > > [INFO] --- maven-enforcer-plugin:1.0.1:enforce > (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- > [WARNING] Rule 0: > org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with > message: > Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" > && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) > > Of course javadoc does not exist at this level, as I'm trying to > release from root aggregator. What I don't understand is why the > enforcer rule fails ? Aggregator is of type "pom" as expected. > > My command-line was: > > mvn release:perform -DpushChanges=false > -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git > -Dtag=xwiki-contrib-mailarchive-0.1 > > > Thanks, > Jeremie > > > 2012/8/17 Jeremie BOUSQUET <[email protected]>: >> Hi Vincent, >> >> I saw that, no problem I'll update the groupId before doing the release :) >> >> Br, >> Jeremie >> >> 2012/8/16 Vincent Massol <[email protected]>: >>> Hi Jeremie, >>> >>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>> >>> It would be great if you could update your groupid before you do the first release :) >>> >>> Thanks >>> -Vincent >>> >>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>> >>>> Thanks Vincent & Sergiu, >>>> >>>> So, is it ok if I put docs to >>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>> (and others in same space) ? >>>> >>>> By now I've almost finished writing first versions of: >>>> * MailArchive.Documentation (home page) >>>> * MailArchive.UserGuide >>>> * MailArchive.AdminGuide >>>> * MailArchive.OperationsGuide >>>> * MailArchive.TroubleShooting >>>> >>>> I should be able to release 0.1 soon ... >>>> >>>> Br, >>>> Jeremie >>>> >>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>> >>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>> >>>>>>> Hi Jeremie and all, >>>>>>> >>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>> >>>>>>> Ok I've parsed this thread and here's my take: >>>>>>> >>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>> >>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>> >>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>> rights to do pretty much anything in this project. >>>>> >>>>>> >>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>> * Nexus: I'll create an account for you. >>>>>> >>>>>> I see you already have a user, cool. >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> Is that ok? >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>> >>>>>>>>> So I'd say that: >>>>>>>>> >>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>> list of the features >>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>> itself >>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>> >>>>>>>> I think it's the best solution. >>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>> space and put pages under: >>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>> >>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>> straightforward with selective import. >>>>>>>> >>>>>>>> Br, >>>>>>>> Jeremie >>>>>>>> >>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>> >>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>> >>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>> WDYT ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>> >>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>> which could be a candidate. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>> huge extension pages. >>>>>>>>> >>>>>>>>> So I'd say that: >>>>>>>>> >>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>> list of the features >>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>> itself >>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>> >>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>> the extension. >>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jeremie >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

BTW, any comments on question below ? 2012/9/3 Jeremie BOUSQUET <[email protected]>:

Hi again

Another thing, I'd like to selectively import the mailarchive ui xar, to create the documentation pages on xwiki.org (Extensions.Mail+Archive+Documentation and so on...), but of course admin rights are needed for that.

Any recommendations ? I'd like to avoid recreating the pages by copy / paste (most of all because of the numerous screenshots attached). I could copy/paste into wysiwyg editor, but I'd prefer something more straightforward to get a copy of the documentation pages from the application xar.

Br, Jeremie

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

(groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts xwiki-contrib-mail, xwiki-contrib-mailarchive-api, xwiki-contrib-mailarchive-ui)

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

So after selectively deactivating execution of "enforce-javadoc-exists" for my root pom, and configuration of gpg, I could successfully deploy mail archive artifacts to nexus staging !

Would someone kindly promote it ? :)

Thanks, Jeremie

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Wow, eventually, it worked ... Had to switch to using maven-release-plugin last version (2.3.2) instead of the one from xwiki.

Now I'm ... back to the initial issue with the enforcer :

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado c.jar").exists()) [INFO] ------------------------------------------------------------------------

Grrrr !

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

I eventually was able to use push to git from maven with release plugin (had to reinstall git with more preservative options).

But previous issue is still there: when checking-out my tag from local clone in target/checkout, pom.xml files are not there so there's nothing to build for maven ...

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Progressing but still failing ...

... it's like a nightmare.

I gave up pushing to github from maven, I think there's something wrong with windows/mysysgit/cygwin somehow.

Now trying to release tag "xwiki-contrib-mailarchive-0.1": - it's pushed on github - if I download the related zip (in "tag" tab on github), it's complete - if I "release:perform" from maven, target/checkout folder contains everything except pom.xml files ... of course release fails

How can my pom.xml files be deleted when running "git checkout xwiki-contrib-mailarchive-0.1", while I can see them in my local history and on github ???

2012/8/31 Jeremie BOUSQUET <[email protected]>: > I tried both, but not tried exhaustively possible combinations > (ssh/https, maven/git conf, and my network proxy that comes in the way > ...) > BTW I'm not sure about how credentials for github should be fed to > maven depending on SSH/HTTPS url connection used. > Authentication with keys works from git command-line to push to > github, but I think I miss some configuration maven-side. > Actually from maven "git push" time-outs, or freezes forever, > depending on protocol used. > > > 2012/8/31 Thomas Mortagne <[email protected]>: >> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >> <[email protected]> wrote: >>> Hi Community, >>> >>> I'm trying to release my contrib project to nexus staging but having >>> difficulties. >>> >>> Couldn't manage to "git push" correctly from maven to github (though >>> "git push" command-line works), so I use "-DpushChanges=false" during >>> release:prepare and release:perform, and do a "git push" manually >>> after release:prepare. >> >> You sure you <scm> is right ? I see you indicated the https in >> <developerConnection>, you should probably use the ssh one instead. >> >>> >>> Now getting that during release:perform (***** were added, it's a >>> correct path behind) : >>> >>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>> [WARNING] Rule 0: >>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>> message: >>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>> >>> Of course javadoc does not exist at this level, as I'm trying to >>> release from root aggregator. What I don't understand is why the >>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>> >>> My command-line was: >>> >>> mvn release:perform -DpushChanges=false >>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>> -Dtag=xwiki-contrib-mailarchive-0.1 >>> >>> >>> Thanks, >>> Jeremie >>> >>> >>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>> Hi Vincent, >>>> >>>> I saw that, no problem I'll update the groupId before doing the release :) >>>> >>>> Br, >>>> Jeremie >>>> >>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>> Hi Jeremie, >>>>> >>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>> >>>>> It would be great if you could update your groupid before you do the first release :) >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>> >>>>>> Thanks Vincent & Sergiu, >>>>>> >>>>>> So, is it ok if I put docs to >>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>> (and others in same space) ? >>>>>> >>>>>> By now I've almost finished writing first versions of: >>>>>> * MailArchive.Documentation (home page) >>>>>> * MailArchive.UserGuide >>>>>> * MailArchive.AdminGuide >>>>>> * MailArchive.OperationsGuide >>>>>> * MailArchive.TroubleShooting >>>>>> >>>>>> I should be able to release 0.1 soon ... >>>>>> >>>>>> Br, >>>>>> Jeremie >>>>>> >>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>> >>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>> >>>>>>>>> Hi Jeremie and all, >>>>>>>>> >>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>> >>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>> >>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>> >>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>> >>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>> rights to do pretty much anything in this project. >>>>>>> >>>>>>>> >>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>> >>>>>>>> I see you already have a user, cool. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Is that ok? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>> >>>>>>>>>>> So I'd say that: >>>>>>>>>>> >>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>> list of the features >>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>> itself >>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>> >>>>>>>>>> I think it's the best solution. >>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>> space and put pages under: >>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>> >>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>> straightforward with selective import. >>>>>>>>>> >>>>>>>>>> Br, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>> WDYT ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>> >>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>> huge extension pages. >>>>>>>>>>> >>>>>>>>>>> So I'd say that: >>>>>>>>>>> >>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>> list of the features >>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>> itself >>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jeremie >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> devs mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Mortagne >>>>>>> _______________________________________________ >>>>>>> devs mailing list >>>>>>> [email protected] >>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

I could successfully deploy mail archive artifacts to nexus staging !

Would someone kindly promote it ? :)

Hi, just to recall that to you ... :) (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag… -Vincent

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

(groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts xwiki-contrib-mail, xwiki-contrib-mailarchive-api, xwiki-contrib-mailarchive-ui)

Thanks, Jeremie

...

...

Thanks, Jeremie

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Wow, eventually, it worked ... Had to switch to using maven-release-plugin last version (2.3.2) instead of the one from xwiki.

Now I'm ... back to the initial issue with the enforcer :

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado c.jar").exists()) [INFO] ------------------------------------------------------------------------

Grrrr !

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

I eventually was able to use push to git from maven with release plugin (had to reinstall git with more preservative options).

But previous issue is still there: when checking-out my tag from local clone in target/checkout, pom.xml files are not there so there's nothing to build for maven ...

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Progressing but still failing ...

... it's like a nightmare.

I gave up pushing to github from maven, I think there's something wrong with windows/mysysgit/cygwin somehow.

Now trying to release tag "xwiki-contrib-mailarchive-0.1": - it's pushed on github - if I download the related zip (in "tag" tab on github), it's complete - if I "release:perform" from maven, target/checkout folder contains everything except pom.xml files ... of course release fails

How can my pom.xml files be deleted when running "git checkout xwiki-contrib-mailarchive-0.1", while I can see them in my local history and on github ???

2012/8/31 Jeremie BOUSQUET <[email protected]>: > I tried both, but not tried exhaustively possible combinations > (ssh/https, maven/git conf, and my network proxy that comes in the way > ...) > BTW I'm not sure about how credentials for github should be fed to > maven depending on SSH/HTTPS url connection used. > Authentication with keys works from git command-line to push to > github, but I think I miss some configuration maven-side. > Actually from maven "git push" time-outs, or freezes forever, > depending on protocol used. > > > 2012/8/31 Thomas Mortagne <[email protected]>: >> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >> <[email protected]> wrote: >>> Hi Community, >>> >>> I'm trying to release my contrib project to nexus staging but having >>> difficulties. >>> >>> Couldn't manage to "git push" correctly from maven to github (though >>> "git push" command-line works), so I use "-DpushChanges=false" during >>> release:prepare and release:perform, and do a "git push" manually >>> after release:prepare. >> >> You sure you <scm> is right ? I see you indicated the https in >> <developerConnection>, you should probably use the ssh one instead. >> >>> >>> Now getting that during release:perform (***** were added, it's a >>> correct path behind) : >>> >>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>> [WARNING] Rule 0: >>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>> message: >>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>> >>> Of course javadoc does not exist at this level, as I'm trying to >>> release from root aggregator. What I don't understand is why the >>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>> >>> My command-line was: >>> >>> mvn release:perform -DpushChanges=false >>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>> -Dtag=xwiki-contrib-mailarchive-0.1 >>> >>> >>> Thanks, >>> Jeremie >>> >>> >>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>> Hi Vincent, >>>> >>>> I saw that, no problem I'll update the groupId before doing the release :) >>>> >>>> Br, >>>> Jeremie >>>> >>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>> Hi Jeremie, >>>>> >>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>> >>>>> It would be great if you could update your groupid before you do the first release :) >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>> >>>>>> Thanks Vincent & Sergiu, >>>>>> >>>>>> So, is it ok if I put docs to >>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>> (and others in same space) ? >>>>>> >>>>>> By now I've almost finished writing first versions of: >>>>>> * MailArchive.Documentation (home page) >>>>>> * MailArchive.UserGuide >>>>>> * MailArchive.AdminGuide >>>>>> * MailArchive.OperationsGuide >>>>>> * MailArchive.TroubleShooting >>>>>> >>>>>> I should be able to release 0.1 soon ... >>>>>> >>>>>> Br, >>>>>> Jeremie >>>>>> >>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>> >>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>> >>>>>>>>> Hi Jeremie and all, >>>>>>>>> >>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>> >>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>> >>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>> >>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>> >>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>> rights to do pretty much anything in this project. >>>>>>> >>>>>>>> >>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>> >>>>>>>> I see you already have a user, cool. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Is that ok? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>> >>>>>>>>>>> So I'd say that: >>>>>>>>>>> >>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>> list of the features >>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>> itself >>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>> >>>>>>>>>> I think it's the best solution. >>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>> space and put pages under: >>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>> >>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>> straightforward with selective import. >>>>>>>>>> >>>>>>>>>> Br, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>> WDYT ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>> >>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>> huge extension pages. >>>>>>>>>>> >>>>>>>>>>> So I'd say that: >>>>>>>>>>> >>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>> list of the features >>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>> itself >>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jeremie

I guess the next step is to create the extension page on e.x.o. That'll be awesome and I'll start testing it when it's there! :) Thanks -Vincent On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>:

...

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

...

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

I could successfully deploy mail archive artifacts to nexus staging !

Would someone kindly promote it ? :)

Hi, just to recall that to you ... :) (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag…

-Vincent

...

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

(groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts xwiki-contrib-mail, xwiki-contrib-mailarchive-api, xwiki-contrib-mailarchive-ui)

Thanks, Jeremie

...

...

Thanks, Jeremie

2012/9/1 Jeremie BOUSQUET <[email protected]>:

...

Wow, eventually, it worked ... Had to switch to using maven-release-plugin last version (2.3.2) instead of the one from xwiki.

Now I'm ... back to the initial issue with the enforcer :

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message: Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado c.jar").exists()) [INFO] ------------------------------------------------------------------------

Grrrr !

2012/9/1 Jeremie BOUSQUET <[email protected]>: > I eventually was able to use push to git from maven with release > plugin (had to reinstall git with more preservative options). > > But previous issue is still there: when checking-out my tag from local > clone in target/checkout, pom.xml files are not there so there's > nothing to build for maven ... > > 2012/9/1 Jeremie BOUSQUET <[email protected]>: >> Progressing but still failing ... >> >> ... it's like a nightmare. >> >> I gave up pushing to github from maven, I think there's something >> wrong with windows/mysysgit/cygwin somehow. >> >> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >> - it's pushed on github >> - if I download the related zip (in "tag" tab on github), it's complete >> - if I "release:perform" from maven, target/checkout folder contains >> everything except pom.xml files ... of course release fails >> >> How can my pom.xml files be deleted when running "git checkout >> xwiki-contrib-mailarchive-0.1", while I can see them in my local >> history and on github ??? >> >> >> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>> I tried both, but not tried exhaustively possible combinations >>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>> ...) >>> BTW I'm not sure about how credentials for github should be fed to >>> maven depending on SSH/HTTPS url connection used. >>> Authentication with keys works from git command-line to push to >>> github, but I think I miss some configuration maven-side. >>> Actually from maven "git push" time-outs, or freezes forever, >>> depending on protocol used. >>> >>> >>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>> <[email protected]> wrote: >>>>> Hi Community, >>>>> >>>>> I'm trying to release my contrib project to nexus staging but having >>>>> difficulties. >>>>> >>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>> release:prepare and release:perform, and do a "git push" manually >>>>> after release:prepare. >>>> >>>> You sure you <scm> is right ? I see you indicated the https in >>>> <developerConnection>, you should probably use the ssh one instead. >>>> >>>>> >>>>> Now getting that during release:perform (***** were added, it's a >>>>> correct path behind) : >>>>> >>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>> [WARNING] Rule 0: >>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>> message: >>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>> >>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>> release from root aggregator. What I don't understand is why the >>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>> >>>>> My command-line was: >>>>> >>>>> mvn release:perform -DpushChanges=false >>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>> >>>>> >>>>> Thanks, >>>>> Jeremie >>>>> >>>>> >>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>> Hi Vincent, >>>>>> >>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>> >>>>>> Br, >>>>>> Jeremie >>>>>> >>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>> Hi Jeremie, >>>>>>> >>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>> >>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>> >>>>>>>> Thanks Vincent & Sergiu, >>>>>>>> >>>>>>>> So, is it ok if I put docs to >>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>> (and others in same space) ? >>>>>>>> >>>>>>>> By now I've almost finished writing first versions of: >>>>>>>> * MailArchive.Documentation (home page) >>>>>>>> * MailArchive.UserGuide >>>>>>>> * MailArchive.AdminGuide >>>>>>>> * MailArchive.OperationsGuide >>>>>>>> * MailArchive.TroubleShooting >>>>>>>> >>>>>>>> I should be able to release 0.1 soon ... >>>>>>>> >>>>>>>> Br, >>>>>>>> Jeremie >>>>>>>> >>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>> >>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>> >>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>> >>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>> >>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>> >>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>> >>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>> >>>>>>>>>> I see you already have a user, cool. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>>> Is that ok? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Vincent >>>>>>>>>>> >>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>> >>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>> >>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>> list of the features >>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>> itself >>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>> >>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>> space and put pages under: >>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>> >>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>> >>>>>>>>>>>> Br, >>>>>>>>>>>> Jeremie >>>>>>>>>>>> >>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>> >>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>> >>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>> list of the features >>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>> itself >>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Jeremie

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;) Thanks -Vincent

2012/9/13 Vincent Massol <[email protected]>:

...

I guess the next step is to create the extension page on e.x.o.

That'll be awesome and I'll start testing it when it's there! :)

Thanks -Vincent

On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>:

...

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

...

2012/9/2 Jeremie BOUSQUET <[email protected]>: > I could successfully deploy mail archive artifacts to nexus staging ! > > Would someone kindly promote it ? :)

Hi, just to recall that to you ... :) (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag…

-Vincent

...

2012/9/2 Jeremie BOUSQUET <[email protected]>:

...

(groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts xwiki-contrib-mail, xwiki-contrib-mailarchive-api, xwiki-contrib-mailarchive-ui)

Thanks, Jeremie

...

> > Thanks, > Jeremie > > 2012/9/1 Jeremie BOUSQUET <[email protected]>: >> Wow, eventually, it worked ... Had to switch to using >> maven-release-plugin last version (2.3.2) instead of the one from >> xwiki. >> >> Now I'm ... back to the initial issue with the enforcer : >> >> [WARNING] Rule 0: >> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >> message: >> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >> c.jar").exists()) >> [INFO] ------------------------------------------------------------------------ >> >> >> Grrrr ! >> >> >> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>> I eventually was able to use push to git from maven with release >>> plugin (had to reinstall git with more preservative options). >>> >>> But previous issue is still there: when checking-out my tag from local >>> clone in target/checkout, pom.xml files are not there so there's >>> nothing to build for maven ... >>> >>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>> Progressing but still failing ... >>>> >>>> ... it's like a nightmare. >>>> >>>> I gave up pushing to github from maven, I think there's something >>>> wrong with windows/mysysgit/cygwin somehow. >>>> >>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>> - it's pushed on github >>>> - if I download the related zip (in "tag" tab on github), it's complete >>>> - if I "release:perform" from maven, target/checkout folder contains >>>> everything except pom.xml files ... of course release fails >>>> >>>> How can my pom.xml files be deleted when running "git checkout >>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>> history and on github ??? >>>> >>>> >>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>> I tried both, but not tried exhaustively possible combinations >>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>> ...) >>>>> BTW I'm not sure about how credentials for github should be fed to >>>>> maven depending on SSH/HTTPS url connection used. >>>>> Authentication with keys works from git command-line to push to >>>>> github, but I think I miss some configuration maven-side. >>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>> depending on protocol used. >>>>> >>>>> >>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>> <[email protected]> wrote: >>>>>>> Hi Community, >>>>>>> >>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>> difficulties. >>>>>>> >>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>> after release:prepare. >>>>>> >>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>> >>>>>>> >>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>> correct path behind) : >>>>>>> >>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>> [WARNING] Rule 0: >>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>> message: >>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>> >>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>> release from root aggregator. What I don't understand is why the >>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>> >>>>>>> My command-line was: >>>>>>> >>>>>>> mvn release:perform -DpushChanges=false >>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Jeremie >>>>>>> >>>>>>> >>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>> Hi Vincent, >>>>>>>> >>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>> >>>>>>>> Br, >>>>>>>> Jeremie >>>>>>>> >>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>> Hi Jeremie, >>>>>>>>> >>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>> >>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>> >>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>> >>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>> (and others in same space) ? >>>>>>>>>> >>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>> >>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>> >>>>>>>>>> Br, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>> >>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>> >>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>> >>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>> >>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>> >>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>> >>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> -Vincent >>>>>>>>>>>> >>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Vincent >>>>>>>>>>>>> >>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Br, >>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi again Jeremie, I'm curious to understand the difference between Operations Guide and User Guide or Admin Guide. On platform.xwiki.org we provide only 3 guides: User, Developer, Admin. Since you've defined a 4th category, I'm curious to see if we're missing something :) Thanks -Vincent On Sep 14, 2012, at 1:54 PM, Vincent Massol <[email protected]> wrote:

Hi Jeremie,

Re images you add, it would be nice if you could use the {{image}} macro. We use it everywhere and that allows us to have consistency in images we publish.

Thanks -Vincent

On Sep 14, 2012, at 9:15 AM, Vincent Massol <[email protected]> wrote:

...

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;)

Thanks -Vincent

...

2012/9/13 Vincent Massol <[email protected]>:

...

I guess the next step is to create the extension page on e.x.o.

That'll be awesome and I'll start testing it when it's there! :)

Thanks -Vincent

On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>:

...

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>> I could successfully deploy mail archive artifacts to nexus staging ! >>> >>> Would someone kindly promote it ? :) > > Hi, just to recall that to you ... :) > (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on > my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag…

-Vincent > > 2012/9/2 Jeremie BOUSQUET <[email protected]>: >> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >> xwiki-contrib-mailarchive-ui) >> > > Thanks, > Jeremie > >>> >>> Thanks, >>> Jeremie >>> >>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>> Wow, eventually, it worked ... Had to switch to using >>>> maven-release-plugin last version (2.3.2) instead of the one from >>>> xwiki. >>>> >>>> Now I'm ... back to the initial issue with the enforcer : >>>> >>>> [WARNING] Rule 0: >>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>> message: >>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>> c.jar").exists()) >>>> [INFO] ------------------------------------------------------------------------ >>>> >>>> >>>> Grrrr ! >>>> >>>> >>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>> I eventually was able to use push to git from maven with release >>>>> plugin (had to reinstall git with more preservative options). >>>>> >>>>> But previous issue is still there: when checking-out my tag from local >>>>> clone in target/checkout, pom.xml files are not there so there's >>>>> nothing to build for maven ... >>>>> >>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>> Progressing but still failing ... >>>>>> >>>>>> ... it's like a nightmare. >>>>>> >>>>>> I gave up pushing to github from maven, I think there's something >>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>> >>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>> - it's pushed on github >>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>> everything except pom.xml files ... of course release fails >>>>>> >>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>> history and on github ??? >>>>>> >>>>>> >>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>> ...) >>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>> Authentication with keys works from git command-line to push to >>>>>>> github, but I think I miss some configuration maven-side. >>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>> depending on protocol used. >>>>>>> >>>>>>> >>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>> <[email protected]> wrote: >>>>>>>>> Hi Community, >>>>>>>>> >>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>> difficulties. >>>>>>>>> >>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>> after release:prepare. >>>>>>>> >>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>> >>>>>>>>> >>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>> correct path behind) : >>>>>>>>> >>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>> [WARNING] Rule 0: >>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>> message: >>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>> >>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>> >>>>>>>>> My command-line was: >>>>>>>>> >>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jeremie >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> Hi Vincent, >>>>>>>>>> >>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>> >>>>>>>>>> Br, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>> Hi Jeremie, >>>>>>>>>>> >>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>> >>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Vincent >>>>>>>>>>> >>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>> >>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>> >>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>> >>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>> >>>>>>>>>>>> Br, >>>>>>>>>>>> Jeremie >>>>>>>>>>>> >>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>> >>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>> >>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2012/9/14 Vincent Massol <[email protected]>:

Hi Jeremie,

Re images you add, it would be nice if you could use the {{image}} macro. We use it everywhere and that allows us to have consistency in images we publish.

Thanks -Vincent

Vincent, do you have some sample uses of this {{image}} macro ? I randomly picked some extensions, and they were all using the [[image]] syntax ...

On Sep 14, 2012, at 9:15 AM, Vincent Massol <[email protected]> wrote:

...

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;)

Thanks -Vincent

...

2012/9/13 Vincent Massol <[email protected]>:

...

I guess the next step is to create the extension page on e.x.o.

That'll be awesome and I'll start testing it when it's there! :)

Thanks -Vincent

On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>:

...

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>> I could successfully deploy mail archive artifacts to nexus staging ! >>> >>> Would someone kindly promote it ? :) > > Hi, just to recall that to you ... :) > (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on > my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag…

-Vincent > > 2012/9/2 Jeremie BOUSQUET <[email protected]>: >> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >> xwiki-contrib-mailarchive-ui) >> > > Thanks, > Jeremie > >>> >>> Thanks, >>> Jeremie >>> >>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>> Wow, eventually, it worked ... Had to switch to using >>>> maven-release-plugin last version (2.3.2) instead of the one from >>>> xwiki. >>>> >>>> Now I'm ... back to the initial issue with the enforcer : >>>> >>>> [WARNING] Rule 0: >>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>> message: >>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>> c.jar").exists()) >>>> [INFO] ------------------------------------------------------------------------ >>>> >>>> >>>> Grrrr ! >>>> >>>> >>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>> I eventually was able to use push to git from maven with release >>>>> plugin (had to reinstall git with more preservative options). >>>>> >>>>> But previous issue is still there: when checking-out my tag from local >>>>> clone in target/checkout, pom.xml files are not there so there's >>>>> nothing to build for maven ... >>>>> >>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>> Progressing but still failing ... >>>>>> >>>>>> ... it's like a nightmare. >>>>>> >>>>>> I gave up pushing to github from maven, I think there's something >>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>> >>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>> - it's pushed on github >>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>> everything except pom.xml files ... of course release fails >>>>>> >>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>> history and on github ??? >>>>>> >>>>>> >>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>> ...) >>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>> Authentication with keys works from git command-line to push to >>>>>>> github, but I think I miss some configuration maven-side. >>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>> depending on protocol used. >>>>>>> >>>>>>> >>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>> <[email protected]> wrote: >>>>>>>>> Hi Community, >>>>>>>>> >>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>> difficulties. >>>>>>>>> >>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>> after release:prepare. >>>>>>>> >>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>> >>>>>>>>> >>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>> correct path behind) : >>>>>>>>> >>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>> [WARNING] Rule 0: >>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>> message: >>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>> >>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>> >>>>>>>>> My command-line was: >>>>>>>>> >>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jeremie >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> Hi Vincent, >>>>>>>>>> >>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>> >>>>>>>>>> Br, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>> Hi Jeremie, >>>>>>>>>>> >>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>> >>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Vincent >>>>>>>>>>> >>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>> >>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>> >>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>> >>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>> >>>>>>>>>>>> Br, >>>>>>>>>>>> Jeremie >>>>>>>>>>>> >>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>> >>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>> >>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 12/07/2012 08:52 AM, Jeremie BOUSQUET wrote:

Hello,

2012/9/14 Vincent Massol <[email protected]>

...

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;)

Thanks -Vincent

Back to this, since I didn't see that recommendation, at that time I created 3 extension pages for the 3 modules (and not only for UI): (UI) http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application (mail api) http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module (mail archive api) http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

As the last 2 do not really need to be materialized in extensions.xwiki.org, and lead to more maintenance from my side, and more confusion on users side, I would like to remove these 2 pages from extensions.xwiki.org, and move some of their content to the Design page related to the MailArchive Application.

Since those 2 were already published, from users point of view it means 2 extensions will "disappear" from the catalog. So I wanted to check with you if it's not a bad practice to do that, and if I can safely remove those 2 extensions (according to the fact, also, that the whole thing is tagged as "BETA").

I think it's OK to remove them, but Thomas should know what happens if someone already installed them using the extension manager. -- Sergiu Dumitriu http://purl.org/net/sergiu

Ok I removed them. Thought about something, is that main problem is if someone wants to install it manually, ie without the Extension Manager, he would have to retrieve the transitive dependencies "by hand". But as my target is XE 4.X, I'm wondering if it's useful anyway to allow users installing such extension manually, as it's faaar more easy using EM. 2012/12/7 Thomas Mortagne <[email protected]>

On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < [email protected]

...

wrote:

...

Hello,

2012/9/14 Vincent Massol <[email protected]>

...

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <

[email protected]>

...

wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;)

Thanks -Vincent

Back to this, since I didn't see that recommendation, at that time I created 3 extension pages for the 3 modules (and not only for UI): (UI)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

(mail api)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

(mail archive api) http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

As the last 2 do not really need to be materialized in extensions.xwiki.org, and lead to more maintenance from my side, and more confusion on users side, I would like to remove these 2 pages from extensions.xwiki.org, and move some of their content to the Design page related to the MailArchive Application.

Since those 2 were already published, from users point of view it means 2 extensions will "disappear" from the catalog. So I wanted to check with you if it's not a bad practice to do that, and if I can safely remove those 2 extensions (according to the fact, also, that the whole thing is tagged as "BETA").

There is no official practice on this yet. IMO you can do this is you think it's the cleaner like this.

It's not going to break anything for users unless there is other extensions depending of these extensions in which case they won't be able to install them of course.

...

Thanks, Jeremie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Jeremie, On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET <[email protected]> wrote:

Hello devs,

Please could you promote release 0.2 of mail archive app in your nexus repository ?

Cool :) Seen that you had some issues to release it? Anything we can help with?

groupId: org.xwiki.contrib.mailarchive artifactIds: xwiki-contrib-mail xwiki-contrib-mailarchive-api xwiki-contrib-mailarchive-ui mstor

I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs? Thanks -Vincent

Thanks !

BR, Jeremie

2012/12/13 Jeremie BOUSQUET <[email protected]>

...

Ok I removed them. Thought about something, is that main problem is if someone wants to install it manually, ie without the Extension Manager, he would have to retrieve the transitive dependencies "by hand". But as my target is XE 4.X, I'm wondering if it's useful anyway to allow users installing such extension manually, as it's faaar more easy using EM.

2012/12/7 Thomas Mortagne <[email protected]>

...

On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < [email protected]

...

wrote:

...

Hello,

2012/9/14 Vincent Massol <[email protected]>

...

On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET <

[email protected]>

...

wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

No don't create one per artifact. To start with I'd suggest just one for the UI module. The other artifacts are already in an extension repository since they're in maven.xwiki.org ;)

Thanks -Vincent

Back to this, since I didn't see that recommendation, at that time I created 3 extension pages for the 3 modules (and not only for UI): (UI)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

(mail api)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

(mail archive api) http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

As the last 2 do not really need to be materialized in extensions.xwiki.org, and lead to more maintenance from my side, and more confusion on users side, I would like to remove these 2 pages from extensions.xwiki.org, and move some of their content to the Design page related to the MailArchive Application.

Since those 2 were already published, from users point of view it means 2 extensions will "disappear" from the catalog. So I wanted to check with you if it's not a bad practice to do that, and if I can safely remove those 2 extensions (according to the fact, also, that the whole thing is tagged as "BETA").

There is no official practice on this yet. IMO you can do this is you think it's the cleaner like this.

It's not going to break anything for users unless there is other extensions depending of these extensions in which case they won't be able to install them of course.

...

Thanks, Jeremie

On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET <[email protected]> wrote:

Hi Vincent,

2013/2/3 Vincent Massol <[email protected]>

...

Hi Jeremie,

On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hello devs,

Please could you promote release 0.2 of mail archive app in your nexus repository ?

Cool :)

Seen that you had some issues to release it? Anything we can help with?

Nothing, except by me some better brains, so I don't forget my GPG passphrase next time ;-)

:)

...

...

groupId: org.xwiki.contrib.mailarchive artifactIds: xwiki-contrib-mail xwiki-contrib-mailarchive-api xwiki-contrib-mailarchive-ui mstor

I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs?

See discussion http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlzt... Basically, I need mstor library to create a Javamail store (to backup/reload emails), but this library comes with extra transitive dependencies, that conflict with XE. I solved that by publishing that lib along my project, without the conflicting (and useless) transitive deps.

I've read the discussion again and still didn't understand why you needed to publish that artifact under your own groupid vs publishing it with a proper groupid. Anyway I've promoted and released your artifacts. The nexus config looks very complex now and I don't master it (I had to close, promote and release which sounds like a lot of steps!)… We also need to give you direct permissions to do that IMO but I don't know the config well enough to do that now. Maybe Sergiu knows since I think he configured that? Thanks -Vincent

...

Thanks -Vincent

...

Thanks !

BR, Jeremie

2012/12/13 Jeremie BOUSQUET <[email protected]>

...

Ok I removed them. Thought about something, is that main problem is if someone wants to install it manually, ie without the Extension Manager, he would have to retrieve the transitive dependencies "by hand". But as my target is XE 4.X, I'm wondering if it's useful anyway to allow users installing such extension manually, as it's faaar more easy using EM.

2012/12/7 Thomas Mortagne <[email protected]>

...

On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < [email protected]

...

wrote:

...

Hello,

2012/9/14 Vincent Massol <[email protected]>

> > On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < [email protected]> > wrote: > >> I guess I have to create an extension page for each artifact ? (mail >> extension, mailarchive api extension, mail archive ui extension) >> Didn't had time to test within extension repository manager locally, >> so I hope it'll work ! :) > > No don't create one per artifact. To start with I'd suggest just one for > the UI module. The other artifacts are already in an extension repository > since they're in maven.xwiki.org ;) > > Thanks > -Vincent > > Back to this, since I didn't see that recommendation, at that time I created 3 extension pages for the 3 modules (and not only for UI): (UI)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

...

(mail api)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

...

(mail archive api)

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

...

As the last 2 do not really need to be materialized in extensions.xwiki.org, and lead to more maintenance from my side, and more confusion on users side, I would like to remove these 2 pages from extensions.xwiki.org,

and

...

move some of their content to the Design page related to the MailArchive Application.

Since those 2 were already published, from users point of view it means 2 extensions will "disappear" from the catalog. So I wanted to check with you if it's not a bad practice to do that, and if I can safely remove those 2 extensions (according to the fact, also, that the whole thing is tagged as "BETA").

There is no official practice on this yet. IMO you can do this is you think it's the cleaner like this.

It's not going to break anything for users unless there is other extensions depending of these extensions in which case they won't be able to install them of course.

...

Thanks, Jeremie

I just tested installation from EM from xwiki.org repository, and it seems to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully. 2013/2/3 Jeremie BOUSQUET <[email protected]>

Thanks Vincent !

Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While "my" version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case.

Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion.

Thanks again, Jeremie

2013/2/3 Vincent Massol <[email protected]>

...

On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hi Vincent,

2013/2/3 Vincent Massol <[email protected]>

...

Hi Jeremie,

On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hello devs,

Please could you promote release 0.2 of mail archive app in your nexus repository ?

Cool :)

Seen that you had some issues to release it? Anything we can help with?

Nothing, except by me some better brains, so I don't forget my GPG passphrase next time ;-)

:)

...

...

...

groupId: org.xwiki.contrib.mailarchive artifactIds: xwiki-contrib-mail xwiki-contrib-mailarchive-api xwiki-contrib-mailarchive-ui mstor

I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs?

See discussion

http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlzt...

...

Basically, I need mstor library to create a Javamail store (to backup/reload emails), but this library comes with extra transitive dependencies, that conflict with XE. I solved that by publishing that lib along my project, without the conflicting (and useless) transitive deps.

I've read the discussion again and still didn't understand why you needed to publish that artifact under your own groupid vs publishing it with a proper groupid.

Anyway I've promoted and released your artifacts. The nexus config looks very complex now and I don't master it (I had to close, promote and release which sounds like a lot of steps!)… We also need to give you direct permissions to do that IMO but I don't know the config well enough to do that now. Maybe Sergiu knows since I think he configured that?

Thanks -Vincent

...

...

Thanks -Vincent

...

Thanks !

BR, Jeremie

2012/12/13 Jeremie BOUSQUET <[email protected]>

...

Ok I removed them. Thought about something, is that main problem is if someone wants to install it manually, ie without the Extension Manager, he would have to retrieve the transitive dependencies "by hand". But as my target is XE 4.X, I'm wondering if it's useful anyway to allow users installing such extension manually, as it's faaar more easy using EM.

2012/12/7 Thomas Mortagne <[email protected]>

> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < > [email protected] >> wrote: > >> Hello, >> >> >> 2012/9/14 Vincent Massol <[email protected]> >> >>> >>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < >> [email protected]> >>> wrote: >>> >>>> I guess I have to create an extension page for each artifact ? (mail >>>> extension, mailarchive api extension, mail archive ui extension) >>>> Didn't had time to test within extension repository manager locally, >>>> so I hope it'll work ! :) >>> >>> No don't create one per artifact. To start with I'd suggest just one > for >>> the UI module. The other artifacts are already in an extension > repository >>> since they're in maven.xwiki.org ;) >>> >>> Thanks >>> -Vincent >>> >>> >> Back to this, since I didn't see that recommendation, at that time I >> created 3 extension pages for the 3 modules (and not only for UI): >> (UI) >> >> >

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

...

...

>> (mail api) >> >> >

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

...

...

>> (mail archive api) >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

...

...

...

>> >> As the last 2 do not really need to be materialized in >> extensions.xwiki.org, >> and lead to more maintenance from my side, and more confusion on users >> side, I would like to remove these 2 pages from extensions.xwiki.org, > and >> move some of their content to the Design page related to the MailArchive >> Application. >> >> Since those 2 were already published, from users point of view it means > 2 >> extensions will "disappear" from the catalog. >> So I wanted to check with you if it's not a bad practice to do that, > and if >> I can safely remove those 2 extensions (according to the fact, also, > that >> the whole thing is tagged as "BETA"). >> > > There is no official practice on this yet. IMO you can do this is you > think > it's the cleaner like this. > > It's not going to break anything for users unless there is other > extensions > depending of these extensions in which case they won't be able to install > them of course. > > >> Thanks, >> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, Thanks for feedbacks ! Le 7 févr. 2013 18:53, "Vincent Massol" <[email protected]> a écrit :

Hi Jeremie,

I'm trying to use version 0.2. Some comments:

* When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin,

Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under "MailArchivePrefs" space, and add an object of type "MailArchiveCode.ServerSettingsClass" to define a server.

* On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) Grrrr... :-)

If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :)

Imap or any protocol supported by javamail... But you're right, the app acts as a "mail sniffer", and stores mails sent to configured account(s) into wiki pages. What is planned of course is an "import" feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course. If there are other possibilities I'm missing, I'm open to any comment :-) Br, Jeremie

Thanks -Vincent

On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET <[email protected]>

wrote:

...

I just tested installation from EM from xwiki.org repository, and it

seems

...

to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully.

2013/2/3 Jeremie BOUSQUET <[email protected]>

...

Thanks Vincent !

Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While "my" version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case.

Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion.

Thanks again, Jeremie

2013/2/3 Vincent Massol <[email protected]>

...

On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET <

[email protected]>

...

wrote:

...

Hi Vincent,

2013/2/3 Vincent Massol <[email protected]>

...

Hi Jeremie,

On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET < [email protected]> wrote:

> Hello devs, > > Please could you promote release 0.2 of mail archive app in your nexus > repository ?

Cool :)

Seen that you had some issues to release it? Anything we can help with?

Nothing, except by me some better brains, so I don't forget my GPG passphrase next time ;-)

:)

...

...

> groupId: > org.xwiki.contrib.mailarchive > artifactIds: > xwiki-contrib-mail > xwiki-contrib-mailarchive-api > xwiki-contrib-mailarchive-ui > mstor

I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs?

See discussion

http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlzt...

...

...

Basically, I need mstor library to create a Javamail store (to backup/reload emails), but this library comes with extra transitive dependencies, that conflict with XE. I solved that by publishing that lib along my project, without the conflicting (and useless) transitive deps.

I've read the discussion again and still didn't understand why you needed to publish that artifact under your own groupid vs publishing it with a proper groupid.

Anyway I've promoted and released your artifacts. The nexus config looks very complex now and I don't master it (I had to close, promote and release which sounds like a lot of steps!)… We also need to give you direct permissions to do that IMO but I don't know the config well enough to do that now. Maybe Sergiu knows since I think he configured that?

Thanks -Vincent

...

...

Thanks -Vincent

> Thanks ! > > BR, > Jeremie > > > 2012/12/13 Jeremie BOUSQUET <[email protected]> > >> Ok I removed them. >> Thought about something, is that main problem is if someone wants to >> install it manually, ie without the Extension Manager, he would have to >> retrieve the transitive dependencies "by hand". >> But as my target is XE 4.X, I'm wondering if it's useful anyway to allow >> users installing such extension manually, as it's faaar more easy using EM. >> >> >> 2012/12/7 Thomas Mortagne <[email protected]> >> >>> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < >>> [email protected] >>>> wrote: >>> >>>> Hello, >>>> >>>> >>>> 2012/9/14 Vincent Massol <[email protected]> >>>> >>>>> >>>>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < >>>> [email protected]> >>>>> wrote: >>>>> >>>>>> I guess I have to create an extension page for each artifact ? (mail >>>>>> extension, mailarchive api extension, mail archive ui extension) >>>>>> Didn't had time to test within extension repository manager locally, >>>>>> so I hope it'll work ! :) >>>>> >>>>> No don't create one per artifact. To start with I'd suggest just one >>> for >>>>> the UI module. The other artifacts are already in an extension >>> repository >>>>> since they're in maven.xwiki.org ;) >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> >>>> Back to this, since I didn't see that recommendation, at that time I >>>> created 3 extension pages for the 3 modules (and not only for UI): >>>> (UI) >>>> >>>> >>>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

...

...

>>>> (mail api) >>>> >>>> >>>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

...

...

>>>> (mail archive api) >>>>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

...

...

...

>>>> >>>> As the last 2 do not really need to be materialized in >>>> extensions.xwiki.org, >>>> and lead to more maintenance from my side, and more confusion on users >>>> side, I would like to remove these 2 pages from extensions.xwiki.org, >>> and >>>> move some of their content to the Design page related to the MailArchive >>>> Application. >>>> >>>> Since those 2 were already published, from users point of view it means >>> 2 >>>> extensions will "disappear" from the catalog. >>>> So I wanted to check with you if it's not a bad practice to do that, >>> and if >>>> I can safely remove those 2 extensions (according to the fact, also, >>> that >>>> the whole thing is tagged as "BETA"). >>>> >>> >>> There is no official practice on this yet. IMO you can do this is you >>> think >>> it's the cleaner like this. >>> >>> It's not going to break anything for users unless there is other >>> extensions >>> depending of these extensions in which case they won't be able to install >>> them of course. >>> >>> >>>> Thanks, >>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Feb 8, 2013, at 8:55 AM, Vincent Massol <[email protected]> wrote:

On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hi Vincent,

Thanks for feedbacks !

Le 7 févr. 2013 18:53, "Vincent Massol" <[email protected]> a écrit :

...

Hi Jeremie,

I'm trying to use version 0.2. Some comments:

* When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin,

Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under "MailArchivePrefs" space, and add an object of type "MailArchiveCode.ServerSettingsClass" to define a server.

...

* On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) Grrrr... :-)

If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :)

Imap or any protocol supported by javamail... But you're right, the app acts as a "mail sniffer", and stores mails sent to configured account(s) into wiki pages. What is planned of course is an "import" feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course.

There are different options but the simplest IMO is to parse/import mailman's mbox archive files.

Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :) Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers. - http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/ap... - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/or... - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/ap... Thanks -Vincent

Here's the format: * http://en.wikipedia.org/wiki/Mbox * http://tools.ietf.org/html/rfc4155

Thanks -Vincent

...

If there are other possibilities I'm missing, I'm open to any comment :-)

Br, Jeremie

...

Thanks -Vincent

On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET <[email protected]>

wrote:

...

...

I just tested installation from EM from xwiki.org repository, and it

seems

...

...

to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully.

2013/2/3 Jeremie BOUSQUET <[email protected]>

...

Thanks Vincent !

Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While "my" version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case.

Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion.

Thanks again, Jeremie

2013/2/3 Vincent Massol <[email protected]>

...

On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET <

[email protected]>

...

wrote:

> Hi Vincent, > > > 2013/2/3 Vincent Massol <[email protected]> > >> Hi Jeremie, >> >> On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET < [email protected]> >> wrote: >> >>> Hello devs, >>> >>> Please could you promote release 0.2 of mail archive app in your nexus >>> repository ? >> >> Cool :) >> >> Seen that you had some issues to release it? Anything we can help with? >> >> > Nothing, except by me some better brains, so I don't forget my GPG > passphrase next time ;-)

:)

>>> groupId: >>> org.xwiki.contrib.mailarchive >>> artifactIds: >>> xwiki-contrib-mail >>> xwiki-contrib-mailarchive-api >>> xwiki-contrib-mailarchive-ui >>> mstor >> >> I was about to do it when I noticed mstor. What is this? If this is a 3rd >> party lib why publish it with the org.xwiki.contrib.mailarchive groupid >> instead of using its own groupid as we do for other 3rd paty libs? >> >> > See discussion >

http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlzt...

...

> Basically, I need mstor library to create a Javamail store (to > backup/reload emails), but this library comes with extra transitive > dependencies, that conflict with XE. > I solved that by publishing that lib along my project, without the > conflicting (and useless) transitive deps.

I've read the discussion again and still didn't understand why you needed to publish that artifact under your own groupid vs publishing it with a proper groupid.

Anyway I've promoted and released your artifacts. The nexus config looks very complex now and I don't master it (I had to close, promote and release which sounds like a lot of steps!)… We also need to give you direct permissions to do that IMO but I don't know the config well enough to do that now. Maybe Sergiu knows since I think he configured that?

Thanks -Vincent

>> Thanks >> -Vincent >> >>> Thanks ! >>> >>> BR, >>> Jeremie >>> >>> >>> 2012/12/13 Jeremie BOUSQUET <[email protected]> >>> >>>> Ok I removed them. >>>> Thought about something, is that main problem is if someone wants to >>>> install it manually, ie without the Extension Manager, he would have to >>>> retrieve the transitive dependencies "by hand". >>>> But as my target is XE 4.X, I'm wondering if it's useful anyway to allow >>>> users installing such extension manually, as it's faaar more easy using >> EM. >>>> >>>> >>>> 2012/12/7 Thomas Mortagne <[email protected]> >>>> >>>>> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < >>>>> [email protected] >>>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> 2012/9/14 Vincent Massol <[email protected]> >>>>>> >>>>>>> >>>>>>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < >>>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I guess I have to create an extension page for each artifact ? (mail >>>>>>>> extension, mailarchive api extension, mail archive ui extension) >>>>>>>> Didn't had time to test within extension repository manager locally, >>>>>>>> so I hope it'll work ! :) >>>>>>> >>>>>>> No don't create one per artifact. To start with I'd suggest just one >>>>> for >>>>>>> the UI module. The other artifacts are already in an extension >>>>> repository >>>>>>> since they're in maven.xwiki.org ;) >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>> >>>>>> Back to this, since I didn't see that recommendation, at that time I >>>>>> created 3 extension pages for the 3 modules (and not only for UI): >>>>>> (UI) >>>>>> >>>>>> >>>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

>>>>>> (mail api) >>>>>> >>>>>> >>>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

>>>>>> (mail archive api) >>>>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

...

>>>>>> >>>>>> As the last 2 do not really need to be materialized in >>>>>> extensions.xwiki.org, >>>>>> and lead to more maintenance from my side, and more confusion on users >>>>>> side, I would like to remove these 2 pages from extensions.xwiki.org, >>>>> and >>>>>> move some of their content to the Design page related to the >> MailArchive >>>>>> Application. >>>>>> >>>>>> Since those 2 were already published, from users point of view it >> means >>>>> 2 >>>>>> extensions will "disappear" from the catalog. >>>>>> So I wanted to check with you if it's not a bad practice to do that, >>>>> and if >>>>>> I can safely remove those 2 extensions (according to the fact, also, >>>>> that >>>>>> the whole thing is tagged as "BETA"). >>>>>> >>>>> >>>>> There is no official practice on this yet. IMO you can do this is you >>>>> think >>>>> it's the cleaner like this. >>>>> >>>>> It's not going to break anything for users unless there is other >>>>> extensions >>>>> depending of these extensions in which case they won't be able to >> install >>>>> them of course. >>>>> >>>>> >>>>>> Thanks, >>>>>> Jeremie

Many thanks Vincent, that's great ! :) Actually I just checked, and the Javamail store I use (mstor) supports MBox format natively [1]. It's what I currently use to allow archiving emails on filesystem, so there's a kind of logic using it to do the reverse operation for import ... Note: you could ask why I archive mails both in xwiki pages and on FS. Idea is that in MBox format I can keep exhaustive content of emails, and be able to re-load them if necessary (migrations are a possible use-case), while in xwiki pages only a subset of email information is kept. Putting emails in the store is an option though, so it can be switched off if needed. [1] http://wiki.modularity.net.au/mstor/index.php?title=Mbox 2013/2/8 Vincent Massol <[email protected]>

On Feb 8, 2013, at 9:03 AM, Vincent Massol <[email protected]> wrote:

...

On Feb 8, 2013, at 8:55 AM, Vincent Massol <[email protected]> wrote:

...

On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET <

[email protected]> wrote:

...

...

...

Hi Vincent,

Thanks for feedbacks !

Le 7 févr. 2013 18:53, "Vincent Massol" <[email protected]> a écrit :

...

Hi Jeremie,

I'm trying to use version 0.2. Some comments:

* When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin

,

...

...

Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under "MailArchivePrefs" space, and add an object of type "MailArchiveCode.ServerSettingsClass" to define a server.

...

* On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) Grrrr... :-)

If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :)

Imap or any protocol supported by javamail... But you're right, the app acts as a "mail sniffer", and stores mails sent to configured account(s) into wiki pages. What is planned of course is an "import" feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course.

There are different options but the simplest IMO is to parse/import mailman's mbox archive files.

Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :)

Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers.

- http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/ap... - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/or... - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/ap...

Example: http://ieugen.blogspot.fr/2012/06/java-mbox-parsing-with-apache-james.html

Thanks -Vincent

...

Thanks -Vincent

...

Here's the format: * http://en.wikipedia.org/wiki/Mbox * http://tools.ietf.org/html/rfc4155

Thanks -Vincent

...

If there are other possibilities I'm missing, I'm open to any comment

:-)

...

...

...

Br, Jeremie

...

Thanks -Vincent

On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET <

[email protected]>

...

wrote:

...

...

I just tested installation from EM from xwiki.org repository, and it

seems

...

...

to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully.

2013/2/3 Jeremie BOUSQUET <[email protected]>

> Thanks Vincent ! > > Maybe I'm wrong, but I didn't want to use the original groupId of this > mstor artifact, because its dependencies are slightly modified compared to > the original. I think it would introduce the false impression of relying on > the original artifact, while it's not really the case. > If someone depends on it, thinking it's the original, in a standalone > environment, it might not work as expected. While "my" version with > different transitive dependencies, is the only one that works without > conflicting with XE. > For these complex cases, might be nice that EM manages maven exclusions, > though maybe it's a big work for not so frequent use-case. > > Nexus config can be somewhat tricky ;-) I know it a little but not pro > features as staging and promotion. > > Thanks again, > Jeremie > > > 2013/2/3 Vincent Massol <[email protected]> > >> >> On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET < [email protected]> >> wrote: >> >>> Hi Vincent, >>> >>> >>> 2013/2/3 Vincent Massol <[email protected]> >>> >>>> Hi Jeremie, >>>> >>>> On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET < >> [email protected]> >>>> wrote: >>>> >>>>> Hello devs, >>>>> >>>>> Please could you promote release 0.2 of mail archive app in your nexus >>>>> repository ? >>>> >>>> Cool :) >>>> >>>> Seen that you had some issues to release it? Anything we can help with? >>>> >>>> >>> Nothing, except by me some better brains, so I don't forget my GPG >>> passphrase next time ;-) >> >> :) >> >>>>> groupId: >>>>> org.xwiki.contrib.mailarchive >>>>> artifactIds: >>>>> xwiki-contrib-mail >>>>> xwiki-contrib-mailarchive-api >>>>> xwiki-contrib-mailarchive-ui >>>>> mstor >>>> >>>> I was about to do it when I noticed mstor. What is this? If this is a >> 3rd >>>> party lib why publish it with the org.xwiki.contrib.mailarchive groupid >>>> instead of using its own groupid as we do for other 3rd paty libs? >>>> >>>> >>> See discussion >>> >>

http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlzt...

...

...

...

>>> Basically, I need mstor library to create a Javamail store (to >>> backup/reload emails), but this library comes with extra transitive >>> dependencies, that conflict with XE. >>> I solved that by publishing that lib along my project, without the >>> conflicting (and useless) transitive deps. >> >> I've read the discussion again and still didn't understand why you needed >> to publish that artifact under your own groupid vs publishing it with a >> proper groupid. >> >> Anyway I've promoted and released your artifacts. The nexus config looks >> very complex now and I don't master it (I had to close, promote and release >> which sounds like a lot of steps!)… We also need to give you direct >> permissions to do that IMO but I don't know the config well enough to do >> that now. Maybe Sergiu knows since I think he configured that? >> >> Thanks >> -Vincent >> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks ! >>>>> >>>>> BR, >>>>> Jeremie >>>>> >>>>> >>>>> 2012/12/13 Jeremie BOUSQUET <[email protected]> >>>>> >>>>>> Ok I removed them. >>>>>> Thought about something, is that main problem is if someone wants to >>>>>> install it manually, ie without the Extension Manager, he would have >> to >>>>>> retrieve the transitive dependencies "by hand". >>>>>> But as my target is XE 4.X, I'm wondering if it's useful anyway to >> allow >>>>>> users installing such extension manually, as it's faaar more easy >> using >>>> EM. >>>>>> >>>>>> >>>>>> 2012/12/7 Thomas Mortagne <[email protected]> >>>>>> >>>>>>> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < >>>>>>> [email protected] >>>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> 2012/9/14 Vincent Massol <[email protected]> >>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < >>>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I guess I have to create an extension page for each artifact ? >> (mail >>>>>>>>>> extension, mailarchive api extension, mail archive ui extension) >>>>>>>>>> Didn't had time to test within extension repository manager >> locally, >>>>>>>>>> so I hope it'll work ! :) >>>>>>>>> >>>>>>>>> No don't create one per artifact. To start with I'd suggest just >> one >>>>>>> for >>>>>>>>> the UI module. The other artifacts are already in an extension >>>>>>> repository >>>>>>>>> since they're in maven.xwiki.org ;) >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>> >>>>>>>> Back to this, since I didn't see that recommendation, at that time >> I >>>>>>>> created 3 extension pages for the 3 modules (and not only for UI): >>>>>>>> (UI) >>>>>>>> >>>>>>>> >>>>>>> >>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application

...

...

...

>>>>>>>> (mail api) >>>>>>>> >>>>>>>> >>>>>>> >>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module

...

...

...

>>>>>>>> (mail archive api) >>>>>>>> >>>> >>

http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module

...

...

...

>>>>>>>> >>>>>>>> As the last 2 do not really need to be materialized in >>>>>>>> extensions.xwiki.org, >>>>>>>> and lead to more maintenance from my side, and more confusion on >> users >>>>>>>> side, I would like to remove these 2 pages from >> extensions.xwiki.org, >>>>>>> and >>>>>>>> move some of their content to the Design page related to the >>>> MailArchive >>>>>>>> Application. >>>>>>>> >>>>>>>> Since those 2 were already published, from users point of view it >>>> means >>>>>>> 2 >>>>>>>> extensions will "disappear" from the catalog. >>>>>>>> So I wanted to check with you if it's not a bad practice to do >> that, >>>>>>> and if >>>>>>>> I can safely remove those 2 extensions (according to the fact, >> also, >>>>>>> that >>>>>>>> the whole thing is tagged as "BETA"). >>>>>>>> >>>>>>> >>>>>>> There is no official practice on this yet. IMO you can do this is >> you >>>>>>> think >>>>>>> it's the cleaner like this. >>>>>>> >>>>>>> It's not going to break anything for users unless there is other >>>>>>> extensions >>>>>>> depending of these extensions in which case they won't be able to >>>> install >>>>>>> them of course. >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Jeremie

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Oh shame on me, I guess I should have read the answer before proceeding ... :/ Well, it's almost done and should be downloadable, I just have to import the documentation pages. 2012/9/14 Thomas Mortagne <[email protected]>:

On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

Actually since it's released on maven repository you can import it and then complete the description.

...

2012/9/13 Vincent Massol <[email protected]>:

...

I guess the next step is to create the extension page on e.x.o.

That'll be awesome and I'll start testing it when it's there! :)

Thanks -Vincent

On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>:

...

On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >> I could successfully deploy mail archive artifacts to nexus staging ! >> >> Would someone kindly promote it ? :)

Hi, just to recall that to you ... :) (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on my side, just want to avoid moving too deep in the mailing-list)

Done! Sorry for the lag…

-Vincent

...

2012/9/2 Jeremie BOUSQUET <[email protected]>: > (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts > xwiki-contrib-mail, xwiki-contrib-mailarchive-api, > xwiki-contrib-mailarchive-ui) >

Thanks, Jeremie

>> >> Thanks, >> Jeremie >> >> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>> Wow, eventually, it worked ... Had to switch to using >>> maven-release-plugin last version (2.3.2) instead of the one from >>> xwiki. >>> >>> Now I'm ... back to the initial issue with the enforcer : >>> >>> [WARNING] Rule 0: >>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>> message: >>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>> c.jar").exists()) >>> [INFO] ------------------------------------------------------------------------ >>> >>> >>> Grrrr ! >>> >>> >>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>> I eventually was able to use push to git from maven with release >>>> plugin (had to reinstall git with more preservative options). >>>> >>>> But previous issue is still there: when checking-out my tag from local >>>> clone in target/checkout, pom.xml files are not there so there's >>>> nothing to build for maven ... >>>> >>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>> Progressing but still failing ... >>>>> >>>>> ... it's like a nightmare. >>>>> >>>>> I gave up pushing to github from maven, I think there's something >>>>> wrong with windows/mysysgit/cygwin somehow. >>>>> >>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>> - it's pushed on github >>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>> everything except pom.xml files ... of course release fails >>>>> >>>>> How can my pom.xml files be deleted when running "git checkout >>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>> history and on github ??? >>>>> >>>>> >>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>> I tried both, but not tried exhaustively possible combinations >>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>> ...) >>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>> maven depending on SSH/HTTPS url connection used. >>>>>> Authentication with keys works from git command-line to push to >>>>>> github, but I think I miss some configuration maven-side. >>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>> depending on protocol used. >>>>>> >>>>>> >>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>> <[email protected]> wrote: >>>>>>>> Hi Community, >>>>>>>> >>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>> difficulties. >>>>>>>> >>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>> after release:prepare. >>>>>>> >>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>> >>>>>>>> >>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>> correct path behind) : >>>>>>>> >>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>> [WARNING] Rule 0: >>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>> message: >>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>> >>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>> >>>>>>>> My command-line was: >>>>>>>> >>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jeremie >>>>>>>> >>>>>>>> >>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>> Hi Vincent, >>>>>>>>> >>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>> >>>>>>>>> Br, >>>>>>>>> Jeremie >>>>>>>>> >>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>> Hi Jeremie, >>>>>>>>>> >>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>> >>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>> >>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>> >>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>> (and others in same space) ? >>>>>>>>>>> >>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>> >>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>> >>>>>>>>>>> Br, >>>>>>>>>>> Jeremie >>>>>>>>>>> >>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>> >>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>> >>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>> >>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Vincent >>>>>>>>>>>>> >>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2012/9/14 Thomas Mortagne <[email protected]>:

On Fri, Sep 14, 2012 at 12:57 PM, Jeremie BOUSQUET Note that the id are wrong (one of the reason to use the import UI instead of creating from scratch ;)). You can change it in edit object, it's important have the same id that the one on maven repository which mean org.xwiki.contrib.mailarchive:xwiki-contrib-mailarchive-ui for the ui for example otherwise Extension Manager will see two different extensions in extensions.xwiki.org and maven repositories while it's actually exactly the same thing.

This is fixed, thanks ! That "import" button, I noticed it, and still can't understand why I didn't click on it ! :D

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

Actually since it's released on maven repository you can import it and then complete the description.

...

2012/9/13 Vincent Massol <[email protected]>:

...

I guess the next step is to create the extension page on e.x.o.

That'll be awesome and I'll start testing it when it's there! :)

Thanks -Vincent

On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Thanks ! No problem ...

2012/9/13 Vincent Massol <[email protected]>: > > On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote: > >>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>> I could successfully deploy mail archive artifacts to nexus staging ! >>>> >>>> Would someone kindly promote it ? :) >> >> Hi, just to recall that to you ... :) >> (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on >> my side, just want to avoid moving too deep in the mailing-list) > > Done! Sorry for the lag… > > -Vincent >> >> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >>> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >>> xwiki-contrib-mailarchive-ui) >>> >> >> Thanks, >> Jeremie >> >>>> >>>> Thanks, >>>> Jeremie >>>> >>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>> Wow, eventually, it worked ... Had to switch to using >>>>> maven-release-plugin last version (2.3.2) instead of the one from >>>>> xwiki. >>>>> >>>>> Now I'm ... back to the initial issue with the enforcer : >>>>> >>>>> [WARNING] Rule 0: >>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>> message: >>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>>> c.jar").exists()) >>>>> [INFO] ------------------------------------------------------------------------ >>>>> >>>>> >>>>> Grrrr ! >>>>> >>>>> >>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>> I eventually was able to use push to git from maven with release >>>>>> plugin (had to reinstall git with more preservative options). >>>>>> >>>>>> But previous issue is still there: when checking-out my tag from local >>>>>> clone in target/checkout, pom.xml files are not there so there's >>>>>> nothing to build for maven ... >>>>>> >>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>> Progressing but still failing ... >>>>>>> >>>>>>> ... it's like a nightmare. >>>>>>> >>>>>>> I gave up pushing to github from maven, I think there's something >>>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>>> >>>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>>> - it's pushed on github >>>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>>> everything except pom.xml files ... of course release fails >>>>>>> >>>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>>> history and on github ??? >>>>>>> >>>>>>> >>>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>>> ...) >>>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>>> Authentication with keys works from git command-line to push to >>>>>>>> github, but I think I miss some configuration maven-side. >>>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>>> depending on protocol used. >>>>>>>> >>>>>>>> >>>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Hi Community, >>>>>>>>>> >>>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>>> difficulties. >>>>>>>>>> >>>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>>> after release:prepare. >>>>>>>>> >>>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>>> correct path behind) : >>>>>>>>>> >>>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>> message: >>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>>> >>>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>>> >>>>>>>>>> My command-line was: >>>>>>>>>> >>>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>> Hi Vincent, >>>>>>>>>>> >>>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>>> >>>>>>>>>>> Br, >>>>>>>>>>> Jeremie >>>>>>>>>>> >>>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>>> Hi Jeremie, >>>>>>>>>>>> >>>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>>> >>>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> -Vincent >>>>>>>>>>>> >>>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>>> >>>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>>> >>>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>>> >>>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>>> >>>>>>>>>>>>> Br, >>>>>>>>>>>>> Jeremie >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Jeremie

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Fri, Sep 14, 2012 at 3:04 PM, Jeremie BOUSQUET <[email protected]> wrote:

I was almost sure I would make a mistake, and I did... In the documentation embedded in the .xar, the user guide is not correct, because it has screenshots coming from the app as used in my organization ... Not that there are things so confidential, but still not something I'm fond of.

Do you think it would be possible to either: - replace delivered 0.1 with a new 0.1 version with fixed documentation ? (hideously ugly, but as it impacts only documentation ...) - deliver a new 0.2 and remove 0.1 from nexus ?

It's not yet Maven central rules ( ;) ) so we can remove things if you absolutely need to. Note that it also mean delete the current 0.1 tag from git. As you prefer, it's recent enough to be deleted even if it's a pain on your side to do.

Anyway for sure I will not put the same on e.x.o ...

Br, Jeremie

2012/9/14 Jeremie BOUSQUET <[email protected]>:

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 12:57 PM, Jeremie BOUSQUET Note that the id are wrong (one of the reason to use the import UI instead of creating from scratch ;)). You can change it in edit object, it's important have the same id that the one on maven repository which mean org.xwiki.contrib.mailarchive:xwiki-contrib-mailarchive-ui for the ui for example otherwise Extension Manager will see two different extensions in extensions.xwiki.org and maven repositories while it's actually exactly the same thing.

This is fixed, thanks ! That "import" button, I noticed it, and still can't understand why I didn't click on it ! :D

...

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

I guess I have to create an extension page for each artifact ? (mail extension, mailarchive api extension, mail archive ui extension) Didn't had time to test within extension repository manager locally, so I hope it'll work ! :)

Actually since it's released on maven repository you can import it and then complete the description.

...

2012/9/13 Vincent Massol <[email protected]>: > I guess the next step is to create the extension page on e.x.o. > > That'll be awesome and I'll start testing it when it's there! :) > > Thanks > -Vincent > > On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote: > >> Thanks ! >> No problem ... >> >> 2012/9/13 Vincent Massol <[email protected]>: >>> >>> On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote: >>> >>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>> I could successfully deploy mail archive artifacts to nexus staging ! >>>>>> >>>>>> Would someone kindly promote it ? :) >>>> >>>> Hi, just to recall that to you ... :) >>>> (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on >>>> my side, just want to avoid moving too deep in the mailing-list) >>> >>> Done! Sorry for the lag… >>> >>> -Vincent >>>> >>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >>>>> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >>>>> xwiki-contrib-mailarchive-ui) >>>>> >>>> >>>> Thanks, >>>> Jeremie >>>> >>>>>> >>>>>> Thanks, >>>>>> Jeremie >>>>>> >>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>> Wow, eventually, it worked ... Had to switch to using >>>>>>> maven-release-plugin last version (2.3.2) instead of the one from >>>>>>> xwiki. >>>>>>> >>>>>>> Now I'm ... back to the initial issue with the enforcer : >>>>>>> >>>>>>> [WARNING] Rule 0: >>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>> message: >>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>>>>> c.jar").exists()) >>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> Grrrr ! >>>>>>> >>>>>>> >>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>> I eventually was able to use push to git from maven with release >>>>>>>> plugin (had to reinstall git with more preservative options). >>>>>>>> >>>>>>>> But previous issue is still there: when checking-out my tag from local >>>>>>>> clone in target/checkout, pom.xml files are not there so there's >>>>>>>> nothing to build for maven ... >>>>>>>> >>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>> Progressing but still failing ... >>>>>>>>> >>>>>>>>> ... it's like a nightmare. >>>>>>>>> >>>>>>>>> I gave up pushing to github from maven, I think there's something >>>>>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>>>>> >>>>>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>>>>> - it's pushed on github >>>>>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>>>>> everything except pom.xml files ... of course release fails >>>>>>>>> >>>>>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>>>>> history and on github ??? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>>>>> ...) >>>>>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>>>>> Authentication with keys works from git command-line to push to >>>>>>>>>> github, but I think I miss some configuration maven-side. >>>>>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>>>>> depending on protocol used. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Hi Community, >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>>>>> difficulties. >>>>>>>>>>>> >>>>>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>>>>> after release:prepare. >>>>>>>>>>> >>>>>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>>>>> correct path behind) : >>>>>>>>>>>> >>>>>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>>>> message: >>>>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>>>>> >>>>>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>>>>> >>>>>>>>>>>> My command-line was: >>>>>>>>>>>> >>>>>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jeremie >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>> Hi Vincent, >>>>>>>>>>>>> >>>>>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>>>>> >>>>>>>>>>>>> Br, >>>>>>>>>>>>> Jeremie >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>>>>> Hi Jeremie, >>>>>>>>>>>>>> >>>>>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Jeremie > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hum, thanks ... As it's not a so big issue I think what I'll prefer to do, is fastly deliver a new 0.2 version with fixed page, and leave the 0.1 as it is, or ask for its deletion later. 2012/9/14 Thomas Mortagne <[email protected]>:

On Fri, Sep 14, 2012 at 3:04 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

I was almost sure I would make a mistake, and I did... In the documentation embedded in the .xar, the user guide is not correct, because it has screenshots coming from the app as used in my organization ... Not that there are things so confidential, but still not something I'm fond of.

Do you think it would be possible to either: - replace delivered 0.1 with a new 0.1 version with fixed documentation ? (hideously ugly, but as it impacts only documentation ...) - deliver a new 0.2 and remove 0.1 from nexus ?

It's not yet Maven central rules ( ;) ) so we can remove things if you absolutely need to. Note that it also mean delete the current 0.1 tag from git. As you prefer, it's recent enough to be deleted even if it's a pain on your side to do.

...

Anyway for sure I will not put the same on e.x.o ...

Br, Jeremie

2012/9/14 Jeremie BOUSQUET <[email protected]>:

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 12:57 PM, Jeremie BOUSQUET Note that the id are wrong (one of the reason to use the import UI instead of creating from scratch ;)). You can change it in edit object, it's important have the same id that the one on maven repository which mean org.xwiki.contrib.mailarchive:xwiki-contrib-mailarchive-ui for the ui for example otherwise Extension Manager will see two different extensions in extensions.xwiki.org and maven repositories while it's actually exactly the same thing.

This is fixed, thanks ! That "import" button, I noticed it, and still can't understand why I didn't click on it ! :D

...

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET <[email protected]> wrote: > I guess I have to create an extension page for each artifact ? (mail > extension, mailarchive api extension, mail archive ui extension) > Didn't had time to test within extension repository manager locally, > so I hope it'll work ! :)

Actually since it's released on maven repository you can import it and then complete the description.

> > 2012/9/13 Vincent Massol <[email protected]>: >> I guess the next step is to create the extension page on e.x.o. >> >> That'll be awesome and I'll start testing it when it's there! :) >> >> Thanks >> -Vincent >> >> On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote: >> >>> Thanks ! >>> No problem ... >>> >>> 2012/9/13 Vincent Massol <[email protected]>: >>>> >>>> On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote: >>>> >>>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>>> I could successfully deploy mail archive artifacts to nexus staging ! >>>>>>> >>>>>>> Would someone kindly promote it ? :) >>>>> >>>>> Hi, just to recall that to you ... :) >>>>> (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on >>>>> my side, just want to avoid moving too deep in the mailing-list) >>>> >>>> Done! Sorry for the lag… >>>> >>>> -Vincent >>>>> >>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >>>>>> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >>>>>> xwiki-contrib-mailarchive-ui) >>>>>> >>>>> >>>>> Thanks, >>>>> Jeremie >>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Jeremie >>>>>>> >>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>> Wow, eventually, it worked ... Had to switch to using >>>>>>>> maven-release-plugin last version (2.3.2) instead of the one from >>>>>>>> xwiki. >>>>>>>> >>>>>>>> Now I'm ... back to the initial issue with the enforcer : >>>>>>>> >>>>>>>> [WARNING] Rule 0: >>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>> message: >>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>>>>>> c.jar").exists()) >>>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> Grrrr ! >>>>>>>> >>>>>>>> >>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>> I eventually was able to use push to git from maven with release >>>>>>>>> plugin (had to reinstall git with more preservative options). >>>>>>>>> >>>>>>>>> But previous issue is still there: when checking-out my tag from local >>>>>>>>> clone in target/checkout, pom.xml files are not there so there's >>>>>>>>> nothing to build for maven ... >>>>>>>>> >>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> Progressing but still failing ... >>>>>>>>>> >>>>>>>>>> ... it's like a nightmare. >>>>>>>>>> >>>>>>>>>> I gave up pushing to github from maven, I think there's something >>>>>>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>>>>>> >>>>>>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>>>>>> - it's pushed on github >>>>>>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>>>>>> everything except pom.xml files ... of course release fails >>>>>>>>>> >>>>>>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>>>>>> history and on github ??? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>>>>>> ...) >>>>>>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>>>>>> Authentication with keys works from git command-line to push to >>>>>>>>>>> github, but I think I miss some configuration maven-side. >>>>>>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>>>>>> depending on protocol used. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> Hi Community, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>>>>>> difficulties. >>>>>>>>>>>>> >>>>>>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>>>>>> after release:prepare. >>>>>>>>>>>> >>>>>>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>>>>>> correct path behind) : >>>>>>>>>>>>> >>>>>>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>>>>> message: >>>>>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>>>>>> >>>>>>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>>>>>> >>>>>>>>>>>>> My command-line was: >>>>>>>>>>>>> >>>>>>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Jeremie >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>> Hi Vincent, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Br, >>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>>>>>> Hi Jeremie, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Jeremie >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, That's really nice, and I wanted to add it anyway, but now it's traced :) : http://jira.xwiki.org/browse/XMAILARCH-12 BTW, I've started feeding the issues I plan to correct in 0.2 in JIRA. Br, Jeremie 2012/9/18 Vincent Massol <[email protected]>:

Hi Jeremie,

For the next version of the MailArchive app you may want to add a Application Panel UIExtension object so that the mailarchive application appears in the new Application panel automagically when it's installed. It would be very nice.

See http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise...

Note that it requires XWiki 4.2M3+ but if the XClass isn't there it's not going to fail on older XWiki versions (it just won't do anything).

Thanks -Vincent

On Sep 14, 2012, at 4:16 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hum, thanks ... As it's not a so big issue I think what I'll prefer to do, is fastly deliver a new 0.2 version with fixed page, and leave the 0.1 as it is, or ask for its deletion later.

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 3:04 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

I was almost sure I would make a mistake, and I did... In the documentation embedded in the .xar, the user guide is not correct, because it has screenshots coming from the app as used in my organization ... Not that there are things so confidential, but still not something I'm fond of.

Do you think it would be possible to either: - replace delivered 0.1 with a new 0.1 version with fixed documentation ? (hideously ugly, but as it impacts only documentation ...) - deliver a new 0.2 and remove 0.1 from nexus ?

It's not yet Maven central rules ( ;) ) so we can remove things if you absolutely need to. Note that it also mean delete the current 0.1 tag from git. As you prefer, it's recent enough to be deleted even if it's a pain on your side to do.

...

Anyway for sure I will not put the same on e.x.o ...

Br, Jeremie

2012/9/14 Jeremie BOUSQUET <[email protected]>:

...

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 12:57 PM, Jeremie BOUSQUET Note that the id are wrong (one of the reason to use the import UI instead of creating from scratch ;)). You can change it in edit object, it's important have the same id that the one on maven repository which mean org.xwiki.contrib.mailarchive:xwiki-contrib-mailarchive-ui for the ui for example otherwise Extension Manager will see two different extensions in extensions.xwiki.org and maven repositories while it's actually exactly the same thing.

This is fixed, thanks ! That "import" button, I noticed it, and still can't understand why I didn't click on it ! :D

...

> > 2012/9/14 Thomas Mortagne <[email protected]>: >> On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET >> <[email protected]> wrote: >>> I guess I have to create an extension page for each artifact ? (mail >>> extension, mailarchive api extension, mail archive ui extension) >>> Didn't had time to test within extension repository manager locally, >>> so I hope it'll work ! :) >> >> Actually since it's released on maven repository you can import it and >> then complete the description. >> >>> >>> 2012/9/13 Vincent Massol <[email protected]>: >>>> I guess the next step is to create the extension page on e.x.o. >>>> >>>> That'll be awesome and I'll start testing it when it's there! :) >>>> >>>> Thanks >>>> -Vincent >>>> >>>> On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote: >>>> >>>>> Thanks ! >>>>> No problem ... >>>>> >>>>> 2012/9/13 Vincent Massol <[email protected]>: >>>>>> >>>>>> On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote: >>>>>> >>>>>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>>>>> I could successfully deploy mail archive artifacts to nexus staging ! >>>>>>>>> >>>>>>>>> Would someone kindly promote it ? :) >>>>>>> >>>>>>> Hi, just to recall that to you ... :) >>>>>>> (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on >>>>>>> my side, just want to avoid moving too deep in the mailing-list) >>>>>> >>>>>> Done! Sorry for the lag… >>>>>> >>>>>> -Vincent >>>>>>> >>>>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>>>> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >>>>>>>> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >>>>>>>> xwiki-contrib-mailarchive-ui) >>>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Jeremie >>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jeremie >>>>>>>>> >>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> Wow, eventually, it worked ... Had to switch to using >>>>>>>>>> maven-release-plugin last version (2.3.2) instead of the one from >>>>>>>>>> xwiki. >>>>>>>>>> >>>>>>>>>> Now I'm ... back to the initial issue with the enforcer : >>>>>>>>>> >>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>> message: >>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>>>>>>>> c.jar").exists()) >>>>>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Grrrr ! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>> I eventually was able to use push to git from maven with release >>>>>>>>>>> plugin (had to reinstall git with more preservative options). >>>>>>>>>>> >>>>>>>>>>> But previous issue is still there: when checking-out my tag from local >>>>>>>>>>> clone in target/checkout, pom.xml files are not there so there's >>>>>>>>>>> nothing to build for maven ... >>>>>>>>>>> >>>>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>> Progressing but still failing ... >>>>>>>>>>>> >>>>>>>>>>>> ... it's like a nightmare. >>>>>>>>>>>> >>>>>>>>>>>> I gave up pushing to github from maven, I think there's something >>>>>>>>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>>>>>>>> >>>>>>>>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>>>>>>>> - it's pushed on github >>>>>>>>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>>>>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>>>>>>>> everything except pom.xml files ... of course release fails >>>>>>>>>>>> >>>>>>>>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>>>>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>>>>>>>> history and on github ??? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>>>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>>>>>>>> ...) >>>>>>>>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>>>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>>>>>>>> Authentication with keys works from git command-line to push to >>>>>>>>>>>>> github, but I think I miss some configuration maven-side. >>>>>>>>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>>>>>>>> depending on protocol used. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> Hi Community, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>>>>>>>> difficulties. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>>>>>>>> after release:prepare. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>>>>>>>> correct path behind) : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>>>>>>> message: >>>>>>>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My command-line was: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>> Hi Vincent, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>>>>>>>> Hi Jeremie, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> Jeremie >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

The download link was wrong, just fixed it. On Wed, Sep 19, 2012 at 4:17 PM, Vincent Massol <[email protected]> wrote:

Hi Jeremie,

Should I start testing your mailarchive app? I see on http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application that it's not installable with the EM. Is that "normal"?

Thanks -Vincent

On Sep 18, 2012, at 11:11 AM, Vincent Massol <[email protected]> wrote:

...

Hi Jeremie,

For the next version of the MailArchive app you may want to add a Application Panel UIExtension object so that the mailarchive application appears in the new Application panel automagically when it's installed. It would be very nice.

See http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise...

Note that it requires XWiki 4.2M3+ but if the XClass isn't there it's not going to fail on older XWiki versions (it just won't do anything).

Thanks -Vincent

On Sep 14, 2012, at 4:16 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hum, thanks ... As it's not a so big issue I think what I'll prefer to do, is fastly deliver a new 0.2 version with fixed page, and leave the 0.1 as it is, or ask for its deletion later.

2012/9/14 Thomas Mortagne <[email protected]>:

...

On Fri, Sep 14, 2012 at 3:04 PM, Jeremie BOUSQUET <[email protected]> wrote:

...

I was almost sure I would make a mistake, and I did... In the documentation embedded in the .xar, the user guide is not correct, because it has screenshots coming from the app as used in my organization ... Not that there are things so confidential, but still not something I'm fond of.

Do you think it would be possible to either: - replace delivered 0.1 with a new 0.1 version with fixed documentation ? (hideously ugly, but as it impacts only documentation ...) - deliver a new 0.2 and remove 0.1 from nexus ?

It's not yet Maven central rules ( ;) ) so we can remove things if you absolutely need to. Note that it also mean delete the current 0.1 tag from git. As you prefer, it's recent enough to be deleted even if it's a pain on your side to do.

...

Anyway for sure I will not put the same on e.x.o ...

Br, Jeremie

2012/9/14 Jeremie BOUSQUET <[email protected]>:

...

2012/9/14 Thomas Mortagne <[email protected]>: > On Fri, Sep 14, 2012 at 12:57 PM, Jeremie BOUSQUET > Note that the id are wrong (one of the reason to use the import UI > instead of creating from scratch ;)). You can change it in edit > object, it's important have the same id that the one on maven > repository which mean > org.xwiki.contrib.mailarchive:xwiki-contrib-mailarchive-ui for the ui > for example otherwise Extension Manager will see two different > extensions in extensions.xwiki.org and maven repositories while it's > actually exactly the same thing.

This is fixed, thanks ! That "import" button, I noticed it, and still can't understand why I didn't click on it ! :D

> >> >> 2012/9/14 Thomas Mortagne <[email protected]>: >>> On Fri, Sep 14, 2012 at 9:13 AM, Jeremie BOUSQUET >>> <[email protected]> wrote: >>>> I guess I have to create an extension page for each artifact ? (mail >>>> extension, mailarchive api extension, mail archive ui extension) >>>> Didn't had time to test within extension repository manager locally, >>>> so I hope it'll work ! :) >>> >>> Actually since it's released on maven repository you can import it and >>> then complete the description. >>> >>>> >>>> 2012/9/13 Vincent Massol <[email protected]>: >>>>> I guess the next step is to create the extension page on e.x.o. >>>>> >>>>> That'll be awesome and I'll start testing it when it's there! :) >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> On Sep 13, 2012, at 1:39 PM, Jeremie BOUSQUET <[email protected]> wrote: >>>>> >>>>>> Thanks ! >>>>>> No problem ... >>>>>> >>>>>> 2012/9/13 Vincent Massol <[email protected]>: >>>>>>> >>>>>>> On Sep 13, 2012, at 10:13 AM, Jeremie BOUSQUET <[email protected]> wrote: >>>>>>> >>>>>>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>> I could successfully deploy mail archive artifacts to nexus staging ! >>>>>>>>>> >>>>>>>>>> Would someone kindly promote it ? :) >>>>>>>> >>>>>>>> Hi, just to recall that to you ... :) >>>>>>>> (I know, seems a bit of a rush on 4.2 cycle and there is no urgency on >>>>>>>> my side, just want to avoid moving too deep in the mailing-list) >>>>>>> >>>>>>> Done! Sorry for the lag… >>>>>>> >>>>>>> -Vincent >>>>>>>> >>>>>>>> 2012/9/2 Jeremie BOUSQUET <[email protected]>: >>>>>>>>> (groupId : org.xwiki.contrib.mailarchive, version : 0.1, artifacts >>>>>>>>> xwiki-contrib-mail, xwiki-contrib-mailarchive-api, >>>>>>>>> xwiki-contrib-mailarchive-ui) >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jeremie >>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jeremie >>>>>>>>>> >>>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>> Wow, eventually, it worked ... Had to switch to using >>>>>>>>>>> maven-release-plugin last version (2.3.2) instead of the one from >>>>>>>>>>> xwiki. >>>>>>>>>>> >>>>>>>>>>> Now I'm ... back to the initial issue with the enforcer : >>>>>>>>>>> >>>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>>> message: >>>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>>> && new java.io.File("C:\PRIVATE\Dropbox\MAILARCHIVE\target\checkout\target/xwiki-contrib-mailarchive-0.1-javado >>>>>>>>>>> c.jar").exists()) >>>>>>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Grrrr ! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>> I eventually was able to use push to git from maven with release >>>>>>>>>>>> plugin (had to reinstall git with more preservative options). >>>>>>>>>>>> >>>>>>>>>>>> But previous issue is still there: when checking-out my tag from local >>>>>>>>>>>> clone in target/checkout, pom.xml files are not there so there's >>>>>>>>>>>> nothing to build for maven ... >>>>>>>>>>>> >>>>>>>>>>>> 2012/9/1 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>> Progressing but still failing ... >>>>>>>>>>>>> >>>>>>>>>>>>> ... it's like a nightmare. >>>>>>>>>>>>> >>>>>>>>>>>>> I gave up pushing to github from maven, I think there's something >>>>>>>>>>>>> wrong with windows/mysysgit/cygwin somehow. >>>>>>>>>>>>> >>>>>>>>>>>>> Now trying to release tag "xwiki-contrib-mailarchive-0.1": >>>>>>>>>>>>> - it's pushed on github >>>>>>>>>>>>> - if I download the related zip (in "tag" tab on github), it's complete >>>>>>>>>>>>> - if I "release:perform" from maven, target/checkout folder contains >>>>>>>>>>>>> everything except pom.xml files ... of course release fails >>>>>>>>>>>>> >>>>>>>>>>>>> How can my pom.xml files be deleted when running "git checkout >>>>>>>>>>>>> xwiki-contrib-mailarchive-0.1", while I can see them in my local >>>>>>>>>>>>> history and on github ??? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/8/31 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>> I tried both, but not tried exhaustively possible combinations >>>>>>>>>>>>>> (ssh/https, maven/git conf, and my network proxy that comes in the way >>>>>>>>>>>>>> ...) >>>>>>>>>>>>>> BTW I'm not sure about how credentials for github should be fed to >>>>>>>>>>>>>> maven depending on SSH/HTTPS url connection used. >>>>>>>>>>>>>> Authentication with keys works from git command-line to push to >>>>>>>>>>>>>> github, but I think I miss some configuration maven-side. >>>>>>>>>>>>>> Actually from maven "git push" time-outs, or freezes forever, >>>>>>>>>>>>>> depending on protocol used. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2012/8/31 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>>> On Fri, Aug 31, 2012 at 9:17 AM, Jeremie BOUSQUET >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> Hi Community, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm trying to release my contrib project to nexus staging but having >>>>>>>>>>>>>>>> difficulties. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Couldn't manage to "git push" correctly from maven to github (though >>>>>>>>>>>>>>>> "git push" command-line works), so I use "-DpushChanges=false" during >>>>>>>>>>>>>>>> release:prepare and release:perform, and do a "git push" manually >>>>>>>>>>>>>>>> after release:prepare. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You sure you <scm> is right ? I see you indicated the https in >>>>>>>>>>>>>>> <developerConnection>, you should probably use the ssh one instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now getting that during release:perform (***** were added, it's a >>>>>>>>>>>>>>>> correct path behind) : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [INFO] --- maven-enforcer-plugin:1.0.1:enforce >>>>>>>>>>>>>>>> (enforce-javadoc-exists) @ xwiki-contrib-mailarchive --- >>>>>>>>>>>>>>>> [WARNING] Rule 0: >>>>>>>>>>>>>>>> org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with >>>>>>>>>>>>>>>> message: >>>>>>>>>>>>>>>> Couldn't evaluate condition: ("pom" != "jar") || ("pom" == "jar" >>>>>>>>>>>>>>>> && new java.io.File("C:\*****\target\checkout\target/xwiki-contrib-mailarchive-0.1-javadoc.jar").exists()) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course javadoc does not exist at this level, as I'm trying to >>>>>>>>>>>>>>>> release from root aggregator. What I don't understand is why the >>>>>>>>>>>>>>>> enforcer rule fails ? Aggregator is of type "pom" as expected. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My command-line was: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> mvn release:perform -DpushChanges=false >>>>>>>>>>>>>>>> -DconnectionUrl=scm:git:https://github.com/xwiki-contrib/xwiki-application-mailarchive.git >>>>>>>>>>>>>>>> -Dtag=xwiki-contrib-mailarchive-0.1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/8/17 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>> Hi Vincent, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I saw that, no problem I'll update the groupId before doing the release :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/8/16 Vincent Massol <[email protected]>: >>>>>>>>>>>>>>>>>> Hi Jeremie, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In case you haven't followed we've updated the contrib rule for the maven group id, see >>>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It would be great if you could update your groupid before you do the first release :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Aug 16, 2012, at 9:50 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks Vincent & Sergiu, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So, is it ok if I put docs to >>>>>>>>>>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/MailArchive/Documentation >>>>>>>>>>>>>>>>>>> (and others in same space) ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> By now I've almost finished writing first versions of: >>>>>>>>>>>>>>>>>>> * MailArchive.Documentation (home page) >>>>>>>>>>>>>>>>>>> * MailArchive.UserGuide >>>>>>>>>>>>>>>>>>> * MailArchive.AdminGuide >>>>>>>>>>>>>>>>>>> * MailArchive.OperationsGuide >>>>>>>>>>>>>>>>>>> * MailArchive.TroubleShooting >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I should be able to release 0.1 soon ... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2012/8/13 Thomas Mortagne <[email protected]>: >>>>>>>>>>>>>>>>>>>> On Mon, Aug 13, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Aug 13, 2012, at 3:17 PM, Vincent Massol wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Jeremie and all, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Back from holidays too :) Cool to see progress on this! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Ok I've parsed this thread and here's my take: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> * JIRA: I'll create a dedicated JIRA project since the project seems large enough to warrant it >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ok, Thomas is doing it ATM, should be ready real soon :) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Done, http://jira.xwiki.org/browse/XMAILARCH. You should have the >>>>>>>>>>>>>>>>>>>> rights to do pretty much anything in this project. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> * Documentation: our rule is currently to have pages on extensions.xwiki.org and if the project becomes too large to create a dedicated wiki for it, as we've done for rendering.xwiki.org, commons.xwiki.org, enterprise, etc for example (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome). IMO it's ok ATM to have several pages on e.x.o for the MailArchive application and we can decide later on to move it to its own wiki (after we have a 1.0 released IMO). >>>>>>>>>>>>>>>>>>>>>> * Nexus: I'll create an account for you. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I see you already have a user, cool. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Is that ok? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Aug 10, 2012, at 9:51 AM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think it's the best solution. >>>>>>>>>>>>>>>>>>>>>>> Since the space I currently use for the main pages of my app is >>>>>>>>>>>>>>>>>>>>>>> "MailArchive", I would propose to use the same for the documentation >>>>>>>>>>>>>>>>>>>>>>> space and put pages under: >>>>>>>>>>>>>>>>>>>>>>> http://contrib.xwiki.org/xwiki/bin/view/MailArchive/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> That way publishing the doc online to contrib wiki would be >>>>>>>>>>>>>>>>>>>>>>> straightforward with selective import. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Br, >>>>>>>>>>>>>>>>>>>>>>> Jeremie >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Sergiu Dumitriu <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>>> On 08/09/2012 10:38 AM, Jerome Velociter wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 08/09/2012 04:34 PM, Jeremie BOUSQUET wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Humm ... Just thinking I might put that directly inside my app xar ... >>>>>>>>>>>>>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I'm a big fan of self-documenting applications. It has the great >>>>>>>>>>>>>>>>>>>>>>>>> advantage of always offering documentation matching the version in use. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> But you might also want to offer the latest released version >>>>>>>>>>>>>>>>>>>>>>>>> documentation online. I think there are some extensions that have >>>>>>>>>>>>>>>>>>>>>>>>> documentation that spans several pages, but honestly I don't know if >>>>>>>>>>>>>>>>>>>>>>>>> this is something we want/we agreed upon. I'll leave it to others to >>>>>>>>>>>>>>>>>>>>>>>>> bring more information on this subject. There is the contrib wiki also >>>>>>>>>>>>>>>>>>>>>>>>> which could be a candidate. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I've seen extensions with a lot of documentation on their extension page, >>>>>>>>>>>>>>>>>>>>>>>> and I've seen things documented in several places. Personally, I don't like >>>>>>>>>>>>>>>>>>>>>>>> huge extension pages. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So I'd say that: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - There should be some documentation on the extension page, at least a >>>>>>>>>>>>>>>>>>>>>>>> description of the project, some usage scenarios, some screenshots, and a >>>>>>>>>>>>>>>>>>>>>>>> list of the features >>>>>>>>>>>>>>>>>>>>>>>> - I agree that the full documentation should be included in the application >>>>>>>>>>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>>>>>>>> - The same full documentation should also be available online, and the >>>>>>>>>>>>>>>>>>>>>>>> contrib wiki seems to be the right place (in a dedicated space) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/9 Jeremie BOUSQUET <[email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Jerome, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Another thing about this project: I'd like to prepare things, and >>>>>>>>>>>>>>>>>>>>>>>>>>> particularly the user guide part, so it's available when I'll publish >>>>>>>>>>>>>>>>>>>>>>>>>>> the extension. >>>>>>>>>>>>>>>>>>>>>>>>>>> For this particular use-case though, I'd like to extend the user/admin >>>>>>>>>>>>>>>>>>>>>>>>>>> guide part on more than one page, as it may be quite large. >>>>>>>>>>>>>>>>>>>>>>>>>>> Where should I put these pages ? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> Jeremie >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs