[xwiki-devs] [Proposal] Setting Maven <url> elements
Hi devs, Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value. Sergiu pointed to me that currently our website <url> are wrong. This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids. For example for Commons Component API this gives us: <url>http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api</url> which is not pointing to anything valid. I see 2 ways of fixing this: Solution 1 ======== Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>. Pros: - Easy and we can point to wherever the documentation is located Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken Solution 2 ======== Set the top level URL to something like: <url>http://xwiki.org/documentation?id=</url> For example for Commons Component API this will generate: <url>http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api</url> Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with. Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain. Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available. So I'm definitely for 2, WDYT? Thanks -Vincent
On Nov 17, 2011, at 9:57 AM, Vincent Massol wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
ah found one cons: - When we change the maven directory structure, we'll need to update the ModuleDocumentation page to update the mappings. -Vincent
So I'm definitely for 2, WDYT?
Thanks -Vincent
+1 for 2 definitely, this is more flexible and extensible On Thu, Nov 17, 2011 at 10:00, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 9:57 AM, Vincent Massol wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
<url> http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-componen... </url>
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url> http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url> http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module </url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
<url> http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwiki... </url>
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
ah found one cons:
- When we change the maven directory structure, we'll need to update the ModuleDocumentation page to update the mappings.
-Vincent
So I'm definitely for 2, WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ======== Set the top level URL to something like: <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion). And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map. Pros: - same as Solution 2 plus no need to maintain a map ;) Cons: - the URL is not very nice
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information. We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right? Thanks -Vincent
Thanks -Vincent
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Assuming the artifactid is always unique and no other contrib extensions has a common part after ":" in its id. This solution is about resolving the page instead of having to maintain a static map, for the guy who will have to maintain this map it's very different :) No need to maintain a static Map for common documentations, better creating page on extensions.xwiki.org for them and redirect or put a link to the central right page. It's also possible to search for "xwiki-commons-component" when "xwiki-commons-component-api" can't be found, then try "xwiki-commons" etc. since this should work for most of them right now and for all of them when maven folder/id refactoring proposal from Sergiu will be implemented (because of the "s" we have sometimes in parent ids).
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information.
We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right?
Did not tried but I don't see why it would be the only place where maven variables don't work the same way.
Thanks -Vincent
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Nov 17, 2011, at 11:34 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Assuming the artifactid is always unique and no other contrib extensions has a common part after ":" in its id.
This solution is about resolving the page instead of having to maintain a static map, for the guy who will have to maintain this map it's very different :)
BTW I still don't get your proposal. How do you find the extension page from the extension id? Or is your suggestion to rename all extension page to be named .../Extension/${groupId}:${artifactId} ? (in which case it's a big change and I'm not sure I like it because the URLs won't be nice, and there will be differences in page names between extensions). What did I miss? Thanks -Vincent
No need to maintain a static Map for common documentations, better creating page on extensions.xwiki.org for them and redirect or put a link to the central right page. It's also possible to search for "xwiki-commons-component" when "xwiki-commons-component-api" can't be found, then try "xwiki-commons" etc. since this should work for most of them right now and for all of them when maven folder/id refactoring proposal from Sergiu will be implemented (because of the "s" we have sometimes in parent ids).
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information.
We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right?
Did not tried but I don't see why it would be the only place where maven variables don't work the same way.
Thanks -Vincent
Thanks -Vincent
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 Thu, Nov 17, 2011 at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 11:34 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Assuming the artifactid is always unique and no other contrib extensions has a common part after ":" in its id.
This solution is about resolving the page instead of having to maintain a static map, for the guy who will have to maintain this map it's very different :)
BTW I still don't get your proposal. How do you find the extension page from the extension id?
Or is your suggestion to rename all extension page to be named .../Extension/${groupId}:${artifactId} ? (in which case it's a big change and I'm not sure I like it because the URLs won't be nice, and there will be differences in page names between extensions).
What did I miss?
Extensions on extensions.xwiki.org are supposed to provide a there id (it's a field in the class) to be valid extensions from EM/XR POV.
Thanks -Vincent
No need to maintain a static Map for common documentations, better creating page on extensions.xwiki.org for them and redirect or put a link to the central right page. It's also possible to search for "xwiki-commons-component" when "xwiki-commons-component-api" can't be found, then try "xwiki-commons" etc. since this should work for most of them right now and for all of them when maven folder/id refactoring proposal from Sergiu will be implemented (because of the "s" we have sometimes in parent ids).
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information.
We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right?
Did not tried but I don't see why it would be the only place where maven variables don't work the same way.
Thanks -Vincent
Thanks -Vincent
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
On Nov 18, 2011, at 8:29 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 11:34 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Assuming the artifactid is always unique and no other contrib extensions has a common part after ":" in its id.
This solution is about resolving the page instead of having to maintain a static map, for the guy who will have to maintain this map it's very different :)
BTW I still don't get your proposal. How do you find the extension page from the extension id?
Or is your suggestion to rename all extension page to be named .../Extension/${groupId}:${artifactId} ? (in which case it's a big change and I'm not sure I like it because the URLs won't be nice, and there will be differences in page names between extensions).
What did I miss?
Extensions on extensions.xwiki.org are supposed to provide a there id (it's a field in the class) to be valid extensions from EM/XR POV.
ok I see. So we'll do a XWQL query on the extension id and then get the matching document and its URL. Cool. +1 for 3) too then. Now is http://xwiki.org/documentation a good prefix? Other ideas: - http://xwiki.org/doc - http://doc.xwiki.org - http://xwiki.org/module I don't have any strong opinion on this. IMO the redirect page should be a page on extensions:ExtensionCode.LocateExtension or extensions:ExtensionCode.ExtensionDocumentationRedirect I'll try to set this up. Thanks -Vincent
Thanks -Vincent
No need to maintain a static Map for common documentations, better creating page on extensions.xwiki.org for them and redirect or put a link to the central right page. It's also possible to search for "xwiki-commons-component" when "xwiki-commons-component-api" can't be found, then try "xwiki-commons" etc. since this should work for most of them right now and for all of them when maven folder/id refactoring proposal from Sergiu will be implemented (because of the "s" we have sometimes in parent ids).
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information.
We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right?
Did not tried but I don't see why it would be the only place where maven variables don't work the same way.
Thanks -Vincent
Thanks -Vincent
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 Nov 18, 2011, at 9:13 AM, Vincent Massol wrote:
On Nov 18, 2011, at 8:29 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 11:34 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol <[email protected]> wrote: > Hi devs, > > Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value. > > Sergiu pointed to me that currently our website <url> are wrong. > > This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids. > > For example for Commons Component API this gives us: > > <url>http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api</url> > > which is not pointing to anything valid. > > I see 2 ways of fixing this: > > Solution 1 > ======== > > Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>. > > Pros: > - Easy and we can point to wherever the documentation is located > > Cons: > - Tedious > - Fragile. If we rename a page on the wiki then the link is broken >
-0. Not a big fan of this solution., way too much work.
> Solution 2 > ======== > > Set the top level URL to something like: > > <url>http://xwiki.org/documentation?id=</url> > > For example for Commons Component API this will generate: > > <url>http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api</url> > > Then: > * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation > * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with. > > Pros: > - Simple, no need to modify all poms. We only need to change the top level pom <url> value > - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain. > > Cons: > - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available. > > So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe <url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
We can't disable auto-completion AFAIK - I've google it earlier today with no luck (if by that you mean the fact that maven suffixes the base url with the artifact ids).
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
It's mostly the same thing since we can extract the last segment in the path + we'll still need to maintain a map since we don't have web page for all submodules. For ex for the 3 modules in commons observation it's the same documentation URL.
Assuming the artifactid is always unique and no other contrib extensions has a common part after ":" in its id.
This solution is about resolving the page instead of having to maintain a static map, for the guy who will have to maintain this map it's very different :)
BTW I still don't get your proposal. How do you find the extension page from the extension id?
Or is your suggestion to rename all extension page to be named .../Extension/${groupId}:${artifactId} ? (in which case it's a big change and I'm not sure I like it because the URLs won't be nice, and there will be differences in page names between extensions).
What did I miss?
Extensions on extensions.xwiki.org are supposed to provide a there id (it's a field in the class) to be valid extensions from EM/XR POV.
ok I see. So we'll do a XWQL query on the extension id and then get the matching document and its URL. Cool.
+1 for 3) too then.
Now is http://xwiki.org/documentation a good prefix?
Other ideas: - http://xwiki.org/doc - http://doc.xwiki.org - http://xwiki.org/module
I don't have any strong opinion on this.
IMO the redirect page should be a page on extensions:ExtensionCode.LocateExtension or extensions:ExtensionCode.ExtensionDocumentationRedirect
I'll try to set this up.
Ok I've implemented it. Here's the URL that I've settled on: http://extensions.xwiki.org/?id=… For example: http://extensions.xwiki.org/?id=org.xwiki.rendering:xwiki-rendering-macro-co... Pros: * It's clear it's about extension documentation * It's short and stable (if we ever remove the extensions wiki we can add an Apache rewrite rule) * It was easy to implement since all we need to do is modify extensions:Main.WebHome * It's kind of logical since the extension wiki home page lists all extensions and if you pass an extension id it shows the doc for that extension I'm now going to update our Maven POMs. Thanks -Vincent
Thanks -Vincent
Thanks -Vincent
No need to maintain a static Map for common documentations, better creating page on extensions.xwiki.org for them and redirect or put a link to the central right page. It's also possible to search for "xwiki-commons-component" when "xwiki-commons-component-api" can't be found, then try "xwiki-commons" etc. since this should work for most of them right now and for all of them when maven folder/id refactoring proposal from Sergiu will be implemented (because of the "s" we have sometimes in parent ids).
Pros: - same as Solution 2 plus no need to maintain a map ;)
See above.
Cons: - the URL is not very nice
Indeed, there's duplicated information.
We could maybe add the groupId in the URL, **IF** variable expansion work in <url>. I guess you tried it before proposing it right?
Did not tried but I don't see why it would be the only place where maven variables don't work the same way.
Thanks -Vincent
> Thanks > -Vincent
On 11/17/2011 04:55 AM, Thomas Mortagne wrote:
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol<[email protected]> wrote:
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website<url> are wrong.
This is because the top level POM has<url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1 ========
Do as I started this morning, i.e. set the<url> explicitly. For example I've set PHP Macro module URL this morning to<url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to<url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros: - Easy and we can point to wherever the documentation is located
Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken
-0. Not a big fan of this solution., way too much work.
Solution 2 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros: - Simple, no need to modify all poms. We only need to change the top level pom<url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Solution 3 ========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}</url> (maybe<url>http://xwiki.org/documentation?id=${groupId}:${artifactId}&path=</url> if we can't disable auto-completion).
Tried it, works well with: http://xwiki.org/documentation?id=${groupId}:${artifactId}&path= +1 for 3, mixed with 1 (explicit URLs) occasionally.
And use the id to find the extensions page on extensions.xwiki.org instead of maintaining a map.
Pros: - same as Solution 2 plus no need to maintain a map ;)
Cons: - the URL is not very nice
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (4)
-
Denis Gervalle -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol