You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Andrew Jaquith <an...@me.com> on 2008/11/10 05:18:50 UTC
Protocol for patching?
Forgive me for asking a question that has probably been asked (or
answered) before, but what is the protocol for patching issues common
to the trunk and 2.8 branches?
Should it be (1) patch trunk, and then merge to 2.8, or (2) patch 2.8
and then merge with trunk?
I have in my own work on the Stripes branch, typically been merging
from trunk to Stripes branch
Also when I merge, I add the following commit comment to the Stripes
commit:
"Merged STRIPES_BRANCH with trunk revision 703235."
...which makes it crystal clear that it's from trunk, and up to a
specific revision number.
Regardless of which direction takes precedence (trunk-->2.8 or 2.8--
>trunk), it's probably a good idea to put in merge comments that
include revision numbers.
A.
Re: Minor baseUrl comment.
Posted by Andrew Jaquith <an...@me.com>.
Yeah, I've noticed this too. Could you file a JIRA? This should be in
2.8.1.
On Nov 10, 2008, at 11:29, "Volkar, John M." <JV...@medrad.com> wrote:
> Just installed 2.8 for a test spin, one minor observation:
>
> If baseUrl does not end with a trailing slash CSS is not found causing
> the page to be rendered badly.
>
> FYI: The installer does not enforce a trailing slash.
>
> I don't know if this is worthy of a jira issue, but fixing this
> would be
> newbie friendly.
>
> Regards,
> John Volkar
Re: WikiPlugins and 3.0, was -> RE: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>
> I don't have any problem with the parameter handling myself. Most of
> my issues have to do with plugin paths and deployment. There needs to
> be some way of specifying compatibility and dependency, and to do so
> within the code of the plugin rather than some external file. I'm keen
> to hear more of what John has to say in this regard, and I haven't had
> a chance to look at the new API you've done (indeed, I didn't
> notice it
> in the code as I've been deploying a few wikis which has kept me
> busy).
I highly recommend subscribing to the jspwiki-commits (which you
should be on anyway, since you're a committer) mailing list.
It's a good idea to propose something NOW, as opposed to after 3.0 is
released. ;-)
>> I've got three or four templates *I* think look more attractive
>> than the
> default, though they were designed for specific branding and would
> require
> some reworking. I'd be willing to submit one of them if Dirk or
> someone
> wanted to fix up the JavaScript issues that might arise. I do have a
> graphic design background (though I'm loath to admit it at times). I
> could post some screenshots if you were interested.
Absolutely.
> naked eye, so it's a bit of a shame. We look clean but naked. [In some
> circles that's a Good Thing.]
Well, if we were dirty and naked I think that would get us some free
publicity. And probably a short jail sentence.
Which, in some circles, is also a good thing.
/Janne
Re: WikiPlugins and 3.0, was -> RE: Idea? Auto-update (Ecplise-like)
mechanism for JSPWiki plugins.
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>
> Yes, plugins can be changed (everything is broken anyway) but nobody has
> been interested in providing any comments or design so far. If you want
> to lead the discussion, go ahead!
Janne,
It's not necessarily from a lack of interest, it's that this is as you
know a volunteer team, and those of us whose participation is based on
time available and external schedules don't necessarily have a schedule
that syncs up with the development cycle of JSPWiki. I for example have
been largely unavailable for the past few months, and am just now
going into another period where most of my time will be devoted to
a few other things, some related to JSPWiki (e.g., two papers due
prior to Christmas and three new projects coming into the new year). I
would prefer to have more control over my time allocation but I do have
to eat.
> (My hope is though that we can survive with rather a minimal set of
> changes as to encourage people to port their plugins to 3.0. Our plugin
> system is fairly stable and easy to understand - if there was anything I
> would change it would be that I would change the way parameters are
> transmitted. A Map prevents for example multiple parameters of the same
> name, which is a bit painful. But you guys do plugins more, so please
> start the discussion!)
I don't have any problem with the parameter handling myself. Most of
my issues have to do with plugin paths and deployment. There needs to
be some way of specifying compatibility and dependency, and to do so
within the code of the plugin rather than some external file. I'm keen
to hear more of what John has to say in this regard, and I haven't had
a chance to look at the new API you've done (indeed, I didn't notice it
in the code as I've been deploying a few wikis which has kept me busy).
> Mediawiki (which is about 90% of the world's wiki installations) does
> not give a list of backlinks when clicking on the title. Neither does
> TWiki, which probably accounts for a majority of the rest. Therefore
> the assertion about every other wiki engine is flat out wrong, and just
> shows that there is a bias towards a particular selection from the
> beginning. (In fact, I think it is a clunky idea at best. Our
> ReferringPagesPlugin is superior, since it can be embedded in the
> LeftMenu.)
I largely agree with this. MediaWiki has the benefit of massive popularity
based on exposure due to Wikipedia and a popular development platform, not
to say that JSPs are unpopular but they're appealing to a different coding
personality.
> Our default template could look better, I agree (and I am not too hot on
> the other skins on it either). Unfortunately, we don't have any graphic
> designers in the team... If a company out there would like to help
> JSPWiki, getting someone with a very good eye for loan for a while might
> be very nice... ;-)
I've got three or four templates *I* think look more attractive than the
default, though they were designed for specific branding and would require
some reworking. I'd be willing to submit one of them if Dirk or someone
wanted to fix up the JavaScript issues that might arise. I do have a
graphic design background (though I'm loath to admit it at times). I
could post some screenshots if you were interested.
A more graphically appealing design would lend a lot more interest to the
project. Sadly, people tend to judge things on appearance rather than
functionality and the jspwiki.org site is on the barren side. We have
some nice new JavaScript functionality which is mostly invisible to the
naked eye, so it's a bit of a shame. We look clean but naked. [In some
circles that's a Good Thing.]
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: WikiPlugins and 3.0, was -> RE: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yes, plugins can be changed (everything is broken anyway) but nobody
has been interested in providing any comments or design so far. If
you want to lead the discussion, go ahead!
(My hope is though that we can survive with rather a minimal set of
changes as to encourage people to port their plugins to 3.0. Our
plugin system is fairly stable and easy to understand - if there was
anything I would change it would be that I would change the way
parameters are transmitted. A Map prevents for example multiple
parameters of the same name, which is a bit painful. But you guys do
plugins more, so please start the discussion!)
Mediawiki (which is about 90% of the world's wiki installations) does
not give a list of backlinks when clicking on the title. Neither
does TWiki, which probably accounts for a majority of the rest.
Therefore the assertion about every other wiki engine is flat out
wrong, and just shows that there is a bias towards a particular
selection from the beginning. (In fact, I think it is a clunky idea
at best. Our ReferringPagesPlugin is superior, since it can be
embedded in the LeftMenu.)
Our default template could look better, I agree (and I am not too hot
on the other skins on it either). Unfortunately, we don't have any
graphic designers in the team... If a company out there would like
to help JSPWiki, getting someone with a very good eye for loan for a
while might be very nice... ;-)
/Janne
On 11 Nov 2008, at 03:22, Volkar, John M. wrote:
> Agreed Murray.
>
> I've not been following closely but it appears with 3.0 just around
> the
> corner compatibility breaking changes are now possible. For instance,
> plugins in general can be broken and changed. For example, WikiPlugin
> could spout new *required* methods and have signature changes.
>
> Things like generics and annotations are now possible in 3.0 so
> perhaps
> the time is ripe for significant change.
>
> Of course wholesale change just for change sake isn't a good idea, but
> really an opportunity for change like this doesn't happen very
> often in
> a project's lifecycle (after all, I haven't heard anyone say anything
> about 4.0 ... yet <grin/>).
>
> Let me think on this some more and pull the code from svn (and get
> back
> up to speed with svn, eclipse, etc... It's been too long.). I'll
> browse
> around and see about writing out some sort of proposal regarding
> plugins
> and 3.0. This should be given some thought by plugin developers and a
> wish list should be discussed.
>
> ----
> Unless of course current committer thinking is that this is an area
> where change isn't desired in 3.0?
>
> I see lots of talk about storage backends, UI front ends and other
> plumbing, but nothing systematic regarding plugins. Is this viewed
> as a
> fully satisfied niche of JSPWiki? This seems ashamed because plugins
> represent a fairly simple way of bolting new functionality into
> JSPWiki
> as a platform and the existing framework could be strengthened to make
> plugin development easier and more regular. But then again, if it
> ain't
> broke don't fix it is a good rule-of-thumb too.
>
> ----
> <aside>
> I'm ashamed to admit it, but I've had a recent experience where a
> group
> of wiki users choose UseMod over JSPWiki because the JSPWiki UI was
> too-cluttered and complicated (quote: "and *why* doesn't the page
> title
> give a list of backlinks like every other wiki in existence?").
> <head-shaking/> Just shows that not everyone can be happy; they
> detested
> the default template, tried installing other templates and threw up
> their hands in disgust. Anyway it just goes to show that there are
> different folks in the world.
> </aside>
>
>
>
> Regards,
> John Volkar
>
>
>
>
> -----Original Message-----
> From: Murray Altheim [mailto:murray07@altheim.com]
> Sent: Monday, November 10, 2008 4:58 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki
> plugins.
>
> Volkar, John M. wrote:
>> Anyone give any thought to how sanctioned plugins could be hosted and
>> have a means for live running sites to auto-download and install
>> updates to them?
>>
>> If there were someway to do this, the annotations which are being
>> discussed could be used to query a plugin about its needs,
>> dependencies, etc. This would have to be seriously thought thru, but
>> could be quite cool.
>
> Hi John,
>
> From someone with a *lot* of plugins to deal with, the current system
> using jspwiki_module.xml is rather broken. It's too complicated,
> and if
> one misses a file, or misses a plugin alias (i.e., a class used to
> shorten a name or move a plugin into a parent package), or includes in
> the XML configuration a plugin that isn't actually available, the
> whole
> shebang comes apart. I've ended up removing all the XML files from my
> jar files since I couldn't get everything to reliably work.
>
> My feeling is that annotations might work fine if they permit each
> plugin and any of its aliases to function independently and not be
> bound
> to packaging restraints; this is not to speak of actual code
> dependencies. I am wary of further complications though. If, for
> example, someone has available to them dozens of plugins, and has
> several sites using different combinations of plugins, whatever
> approach
> is taken would hopefully be pretty seamless and not require
> complicated
> combinations of configuration files or machinations in ant build
> scripts
> as I've had to try, such as copying from a pool of jspwiki_module.xml
> files depending on configuration. A mess.
>
> I'm currently dealing with installs that include three or four jar
> files, sometimes with code dependencies across jars, and as I've
> mentioned before it's unclear about the order and priority of
> processing
> when there are multiple XML configuration files.
>
> Murray
>
> ......................................................................
> ..
> ...
> Murray Altheim <murray07 at altheim.com> ===
> = =
> http://www.altheim.com/murray/ = =
> ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = =
> = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
WikiPlugins and 3.0, was -> RE: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by "Volkar, John M." <JV...@medrad.com>.
Agreed Murray.
I've not been following closely but it appears with 3.0 just around the
corner compatibility breaking changes are now possible. For instance,
plugins in general can be broken and changed. For example, WikiPlugin
could spout new *required* methods and have signature changes.
Things like generics and annotations are now possible in 3.0 so perhaps
the time is ripe for significant change.
Of course wholesale change just for change sake isn't a good idea, but
really an opportunity for change like this doesn't happen very often in
a project's lifecycle (after all, I haven't heard anyone say anything
about 4.0 ... yet <grin/>).
Let me think on this some more and pull the code from svn (and get back
up to speed with svn, eclipse, etc... It's been too long.). I'll browse
around and see about writing out some sort of proposal regarding plugins
and 3.0. This should be given some thought by plugin developers and a
wish list should be discussed.
----
Unless of course current committer thinking is that this is an area
where change isn't desired in 3.0?
I see lots of talk about storage backends, UI front ends and other
plumbing, but nothing systematic regarding plugins. Is this viewed as a
fully satisfied niche of JSPWiki? This seems ashamed because plugins
represent a fairly simple way of bolting new functionality into JSPWiki
as a platform and the existing framework could be strengthened to make
plugin development easier and more regular. But then again, if it ain't
broke don't fix it is a good rule-of-thumb too.
----
<aside>
I'm ashamed to admit it, but I've had a recent experience where a group
of wiki users choose UseMod over JSPWiki because the JSPWiki UI was
too-cluttered and complicated (quote: "and *why* doesn't the page title
give a list of backlinks like every other wiki in existence?").
<head-shaking/> Just shows that not everyone can be happy; they detested
the default template, tried installing other templates and threw up
their hands in disgust. Anyway it just goes to show that there are
different folks in the world.
</aside>
Regards,
John Volkar
-----Original Message-----
From: Murray Altheim [mailto:murray07@altheim.com]
Sent: Monday, November 10, 2008 4:58 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki
plugins.
Volkar, John M. wrote:
> Anyone give any thought to how sanctioned plugins could be hosted and
> have a means for live running sites to auto-download and install
> updates to them?
>
> If there were someway to do this, the annotations which are being
> discussed could be used to query a plugin about its needs,
> dependencies, etc. This would have to be seriously thought thru, but
> could be quite cool.
Hi John,
From someone with a *lot* of plugins to deal with, the current system
using jspwiki_module.xml is rather broken. It's too complicated, and if
one misses a file, or misses a plugin alias (i.e., a class used to
shorten a name or move a plugin into a parent package), or includes in
the XML configuration a plugin that isn't actually available, the whole
shebang comes apart. I've ended up removing all the XML files from my
jar files since I couldn't get everything to reliably work.
My feeling is that annotations might work fine if they permit each
plugin and any of its aliases to function independently and not be bound
to packaging restraints; this is not to speak of actual code
dependencies. I am wary of further complications though. If, for
example, someone has available to them dozens of plugins, and has
several sites using different combinations of plugins, whatever approach
is taken would hopefully be pretty seamless and not require complicated
combinations of configuration files or machinations in ant build scripts
as I've had to try, such as copying from a pool of jspwiki_module.xml
files depending on configuration. A mess.
I'm currently dealing with installs that include three or four jar
files, sometimes with code dependencies across jars, and as I've
mentioned before it's unclear about the order and priority of processing
when there are multiple XML configuration files.
Murray
........................................................................
...
Murray Altheim <murray07 at altheim.com> ===
= =
http://www.altheim.com/murray/ = =
===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = =
= =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> My feeling is that annotations might work fine if they permit each
> plugin and any of its aliases to function independently and not be
> bound to packaging restraints; this is not to speak of actual code
> dependencies. I am wary of further complications though. If, for
> example, someone has available to them dozens of plugins, and has
> several sites using different combinations of plugins, whatever
> approach
> is taken would hopefully be pretty seamless and not require
> complicated
> combinations of configuration files or machinations in ant build
> scripts
> as I've had to try, such as copying from a pool of jspwiki_module.xml
> files depending on configuration. A mess.
Any comments on the new annotation system, which I checked into the
trunk yesterday? The API has been in there for months now, but I
didn't see any comments on it so I went ahead and implemented it.
/Janne
Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by Murray Altheim <mu...@altheim.com>.
Volkar, John M. wrote:
> Anyone give any thought to how sanctioned plugins could be hosted and
> have a means for live running sites to auto-download and install updates
> to them?
>
> If there were someway to do this, the annotations which are being
> discussed could be used to query a plugin about its needs, dependencies,
> etc. This would have to be seriously thought thru, but could be quite
> cool.
Hi John,
From someone with a *lot* of plugins to deal with, the current system
using jspwiki_module.xml is rather broken. It's too complicated, and
if one misses a file, or misses a plugin alias (i.e., a class used to
shorten a name or move a plugin into a parent package), or includes in
the XML configuration a plugin that isn't actually available, the whole
shebang comes apart. I've ended up removing all the XML files from my
jar files since I couldn't get everything to reliably work.
My feeling is that annotations might work fine if they permit each
plugin and any of its aliases to function independently and not be
bound to packaging restraints; this is not to speak of actual code
dependencies. I am wary of further complications though. If, for
example, someone has available to them dozens of plugins, and has
several sites using different combinations of plugins, whatever approach
is taken would hopefully be pretty seamless and not require complicated
combinations of configuration files or machinations in ant build scripts
as I've had to try, such as copying from a pool of jspwiki_module.xml
files depending on configuration. A mess.
I'm currently dealing with installs that include three or four jar
files, sometimes with code dependencies across jars, and as I've
mentioned before it's unclear about the order and priority of
processing when there are multiple XML configuration files.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
No, I have to admit that I haven't. But I think this is a really
great idea, though it does sound like a lot of coding.
You could open up a JIRA ticket for this idea; someone could pick it
up perhaps?
One could perhaps start with some simple Ant scripts; something like
"ant update" might work well.
/Janne
On 10 Nov 2008, at 23:45, Volkar, John M. wrote:
> Anyone give any thought to how sanctioned plugins could be hosted and
> have a means for live running sites to auto-download and install
> updates
> to them?
>
> If there were someway to do this, the annotations which are being
> discussed could be used to query a plugin about its needs,
> dependencies,
> etc. This would have to be seriously thought thru, but could be quite
> cool.
>
> With the advent of apache SVN hosting, and being under the apache
> umbrella, this might be viable now. Dunno.
>
> Another thought (I've lamented my outdated jspwiki installs a few
> time);
> it would be especially cool if jspwiki could update itself say
> (2.8.0 to
> 2.8.x) bug fixes. But this is probably a container management
> nightmare.
>
> Regards (and where *is* that rock?),
> John Volkar
>
>
Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Posted by "Volkar, John M." <JV...@medrad.com>.
Anyone give any thought to how sanctioned plugins could be hosted and
have a means for live running sites to auto-download and install updates
to them?
If there were someway to do this, the annotations which are being
discussed could be used to query a plugin about its needs, dependencies,
etc. This would have to be seriously thought thru, but could be quite
cool.
With the advent of apache SVN hosting, and being under the apache
umbrella, this might be viable now. Dunno.
Another thought (I've lamented my outdated jspwiki installs a few time);
it would be especially cool if jspwiki could update itself say (2.8.0 to
2.8.x) bug fixes. But this is probably a container management
nightmare.
Regards (and where *is* that rock?),
John Volkar
Re: Minor? ShortViewURLConstructor doesn't (fully) work
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Ah, but [Edit:xxx] is a recommended shortcut for PageAliases and other
> things, its littered across several pieces of documentation. But
> whatever. No JIRA for this then. Good'nuff.
Which just shows how badly outdated our documentation is... ;-)
> PS: But this was a *useful* shortcut; if this is a "won't fix" then
> there should be a sanctioned replacement for it. (Perhaps a [{Edit
> PageName}] plugin?)
That might make a lot more sense. InterWiki plugins are not very
good for internal references, since they are static but our URIs are
not :-/
/Janne
RE: Minor? ShortViewURLConstructor doesn't (fully) work
Posted by "Volkar, John M." <JV...@medrad.com>.
Ah, but [Edit:xxx] is a recommended shortcut for PageAliases and other
things, its littered across several pieces of documentation. But
whatever. No JIRA for this then. Good'nuff.
Regards (and crawling back under my rock),
John Volkar
PS: But this was a *useful* shortcut; if this is a "won't fix" then
there should be a sanctioned replacement for it. (Perhaps a [{Edit
PageName}] plugin?)
-----Original Message-----
From: Janne Jalkanen [mailto:Janne.Jalkanen@ecyrd.com]
Sent: Monday, November 10, 2008 2:06 PM
To: jspwiki-dev@incubator.apache.org
Subject: Re: Minor? ShortViewURLConstructor doesn't (fully) work
> Test spinning 2.8 some more... Perhaps this is JIRA worthy?
I think only in the sense that we should point out that the Edit:
interwiki link only works with the DefaultURLConstructor, and probably
should be removed anyway.
After all, "Edit" is not an *interwiki* link, just a brainfart of a
shortcut that has been in there for ages, and the only reason why it is
there is that I haven't remembered to remove it for the past three years
or so ;-)
/Janne
>
> Vanilla 2.8 install...
>
> Changing:
> jspwiki.urlConstructor = ShortViewURLConstructor
> jspwiki.shortURLConstructor.prefix = wiki/
>
> Then a link like [Edit:LeftMenu] does not work. "No such page
> 'Edit.jsp' would you like to create it."
>
> ----
> Trying:
> jspwiki.shortURLConstructor.prefix = /wiki
>
> Causes http://mr-npd/advdev//wikiMain, since baseUrl has an ending
> slash (and we need that), but [Edit:LeftMenu] works.
>
> ----
> Trying:
> jspwiki.shortURLConstructor.prefix = wiki
>
> Causes http://mr-npd/advdev/wikiMain which obviously won't work, but
> [Edit:LeftMenu] works.
>
> ----
> Trying (out of desparation):
> jspwiki.shortURLConstructor.prefix = /wiki/
>
> Causes http://mr-npd/advdev//wiki/Main which works as a link (but
> really
> now!) and http://mr-npd/advdev//wiki/Edit.jsp?page=LeftMenu which
> obviously doesn't work.
>
> ----
>
> So it appears that there is some tangle between url constructors and
> baseUrl and Interwiki links that should be ironed out?
>
> I'm forced to conclude that ShortViewURLConstructor is broken enough
> to make it unusable. Or am I missing something completely obvious?
>
> This can be seen on http://www.jspwiki.org/wiki/TestPage?version=48 if
> you like.
>
> Regards,
> John Volkar
>
>
>
>
> -----Original Message-----
> From: Volkar, John M. [mailto:JVolkar@medrad.com]
> Sent: Monday, November 10, 2008 11:30 AM
> To: jspwiki-dev@incubator.apache.org
> Subject: Minor baseUrl comment.
>
> Just installed 2.8 for a test spin, one minor observation:
>
> If baseUrl does not end with a trailing slash CSS is not found causing
> the page to be rendered badly.
>
> FYI: The installer does not enforce a trailing slash.
>
> I don't know if this is worthy of a jira issue, but fixing this would
> be newbie friendly.
>
> Regards,
> John Volkar
Re: Minor? ShortViewURLConstructor doesn't (fully) work
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Test spinning 2.8 some more... Perhaps this is JIRA worthy?
I think only in the sense that we should point out that the Edit:
interwiki link only works with the DefaultURLConstructor, and
probably should be removed anyway.
After all, "Edit" is not an *interwiki* link, just a brainfart of a
shortcut that has been in there for ages, and the only reason why it
is there is that I haven't remembered to remove it for the past three
years or so ;-)
/Janne
>
> Vanilla 2.8 install...
>
> Changing:
> jspwiki.urlConstructor = ShortViewURLConstructor
> jspwiki.shortURLConstructor.prefix = wiki/
>
> Then a link like [Edit:LeftMenu] does not work. "No such page
> 'Edit.jsp' would you like to create it."
>
> ----
> Trying:
> jspwiki.shortURLConstructor.prefix = /wiki
>
> Causes http://mr-npd/advdev//wikiMain, since baseUrl has an ending
> slash
> (and we need that), but [Edit:LeftMenu] works.
>
> ----
> Trying:
> jspwiki.shortURLConstructor.prefix = wiki
>
> Causes http://mr-npd/advdev/wikiMain which obviously won't work, but
> [Edit:LeftMenu] works.
>
> ----
> Trying (out of desparation):
> jspwiki.shortURLConstructor.prefix = /wiki/
>
> Causes http://mr-npd/advdev//wiki/Main which works as a link (but
> really
> now!) and http://mr-npd/advdev//wiki/Edit.jsp?page=LeftMenu which
> obviously doesn't work.
>
> ----
>
> So it appears that there is some tangle between url constructors and
> baseUrl and Interwiki links that should be ironed out?
>
> I'm forced to conclude that ShortViewURLConstructor is broken
> enough to
> make it unusable. Or am I missing something completely obvious?
>
> This can be seen on http://www.jspwiki.org/wiki/TestPage?version=48 if
> you like.
>
> Regards,
> John Volkar
>
>
>
>
> -----Original Message-----
> From: Volkar, John M. [mailto:JVolkar@medrad.com]
> Sent: Monday, November 10, 2008 11:30 AM
> To: jspwiki-dev@incubator.apache.org
> Subject: Minor baseUrl comment.
>
> Just installed 2.8 for a test spin, one minor observation:
>
> If baseUrl does not end with a trailing slash CSS is not found causing
> the page to be rendered badly.
>
> FYI: The installer does not enforce a trailing slash.
>
> I don't know if this is worthy of a jira issue, but fixing this
> would be
> newbie friendly.
>
> Regards,
> John Volkar
Minor? ShortViewURLConstructor doesn't (fully) work
Posted by "Volkar, John M." <JV...@medrad.com>.
Test spinning 2.8 some more... Perhaps this is JIRA worthy?
Vanilla 2.8 install...
Changing:
jspwiki.urlConstructor = ShortViewURLConstructor
jspwiki.shortURLConstructor.prefix = wiki/
Then a link like [Edit:LeftMenu] does not work. "No such page
'Edit.jsp' would you like to create it."
----
Trying:
jspwiki.shortURLConstructor.prefix = /wiki
Causes http://mr-npd/advdev//wikiMain, since baseUrl has an ending slash
(and we need that), but [Edit:LeftMenu] works.
----
Trying:
jspwiki.shortURLConstructor.prefix = wiki
Causes http://mr-npd/advdev/wikiMain which obviously won't work, but
[Edit:LeftMenu] works.
----
Trying (out of desparation):
jspwiki.shortURLConstructor.prefix = /wiki/
Causes http://mr-npd/advdev//wiki/Main which works as a link (but really
now!) and http://mr-npd/advdev//wiki/Edit.jsp?page=LeftMenu which
obviously doesn't work.
----
So it appears that there is some tangle between url constructors and
baseUrl and Interwiki links that should be ironed out?
I'm forced to conclude that ShortViewURLConstructor is broken enough to
make it unusable. Or am I missing something completely obvious?
This can be seen on http://www.jspwiki.org/wiki/TestPage?version=48 if
you like.
Regards,
John Volkar
-----Original Message-----
From: Volkar, John M. [mailto:JVolkar@medrad.com]
Sent: Monday, November 10, 2008 11:30 AM
To: jspwiki-dev@incubator.apache.org
Subject: Minor baseUrl comment.
Just installed 2.8 for a test spin, one minor observation:
If baseUrl does not end with a trailing slash CSS is not found causing
the page to be rendered badly.
FYI: The installer does not enforce a trailing slash.
I don't know if this is worthy of a jira issue, but fixing this would be
newbie friendly.
Regards,
John Volkar
Minor baseUrl comment.
Posted by "Volkar, John M." <JV...@medrad.com>.
Just installed 2.8 for a test spin, one minor observation:
If baseUrl does not end with a trailing slash CSS is not found causing
the page to be rendered badly.
FYI: The installer does not enforce a trailing slash.
I don't know if this is worthy of a jira issue, but fixing this would be
newbie friendly.
Regards,
John Volkar
Re: Protocol for patching?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
I usually patch 2.8 branch, then merge it into the trunk, since most
patches are against the 2.8 branch at the moment.
I include a comment, but that does not quote revision number, just
the fact that it was merged with 2.8 branch. I look up the revision
number from the history. :-)
(No objection to start adding to the revision number, but my English
fails at your sentence: Does it mean that STRIPES_BRANCH was merged
into trunk; or trunk was merged into STRIPES_BRANCH?)
/Janne
On Nov 10, 2008, at 06:18 , Andrew Jaquith wrote:
> Forgive me for asking a question that has probably been asked (or
> answered) before, but what is the protocol for patching issues
> common to the trunk and 2.8 branches?
>
> Should it be (1) patch trunk, and then merge to 2.8, or (2) patch
> 2.8 and then merge with trunk?
>
> I have in my own work on the Stripes branch, typically been merging
> from trunk to Stripes branch
>
> Also when I merge, I add the following commit comment to the
> Stripes commit:
>
> "Merged STRIPES_BRANCH with trunk revision 703235."
>
> ...which makes it crystal clear that it's from trunk, and up to a
> specific revision number.
>
> Regardless of which direction takes precedence (trunk-->2.8 or 2.8--
> >trunk), it's probably a good idea to put in merge comments that
> include revision numbers.
>
> A.