17 Nov
2011
17 Nov
'11
11:34 a.m.
On Thu, Nov 17, 2011 at 11:04 AM, Vincent Massol <vincent(a)massol.net> wrote:
Did not tried but I don't see why it would be the only place where
maven variables don't work the same way.
On Nov 17, 2011, at 10:55 AM, Thomas Mortagne wrote:
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).
On Thu, Nov 17, 2011 at 9:57 AM, Vincent Massol
<vincent(a)massol.net> wrote:
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).
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). 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
--
Thomas Mortagne
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs