I find the arguments given convincing. So, all new extensions will
continue to get their own directory in the normal MediaWiki extensions
directory. The only exceptions are, for now, result printers and
datatypes, based on Markus' arguments -- they are too small really.
Thanks for the comments!
d
On Montag, 18. August 2008, Denny Vrandečić wrote:
> Oh, sorry, I was unclear: yes, you are fully right, every extension
> should have its own folder. The question is just, should they be
>
> 1) Grouped in one SemanticMediaWikiExt directory
I think this is only good if all the extensions are best
It would probably be easier to develop something similar to the
Extension distributor and install it on semantic-mediawiki.org.
Basically you would give it a list of extension folders, and when
someone requests it would build a tarball of all those folders, making
sure to svn up first. You coul
It's an extension that lets users get "tarballs" on-the-fly from SVN for a
specific extension. You can see it in action here:
http://www.mediawiki.org/wiki/Special:ExtensionDistributor
-Yaron
2008/8/18 Nathan Yergler <[EMAIL PROTECTED]>
> Do you have a link for Extension Distributor? I'm not
Do you have a link for Extension Distributor? I'm not familiar with that.
On Mon, Aug 18, 2008 at 11:34 AM, Daniel Friesen <[EMAIL PROTECTED]> wrote:
> Ugh, you do realize that once you use any of those options other than
> the current (which is a mediawiki svn standard) it instantly becomes
> im
To tell you the truth, I don't see any benefit of having extensions to be
inside SMWExt folder - it's not a huge trouble to increase number of folders
in mediawiki/trunk/extensions/ and considering generic tools for
distribution (and hopefully installation in the future) I'd vote for keeping
them a
Well, could the Extension Distributor be modified to allow for extensions
located somewhere other than the top-level directory? If not, that's one of
those technical obstacles that has to be considered.
I don't see people getting code they don't want as a big problem - I guess I
take Rolf's positi
Ugh, you do realize that once you use any of those options other than
the current (which is a mediawiki svn standard) it instantly becomes
impossible to let users use the Extension Distributor to get a copy of
that individual extension?
And if you put it inside of a SemanticMediaWiki/extensions/
Yaron Koren skrev:
> The idea of an SMW "extensions" directory sounds very interesting, and
> maybe presents itself as a long-term solution to the problem of
> getting all the SMW extensions into one package - the vaunted
> "Semantic Bundle". Yes, I'm doing what I can to try to get people to
>
The idea of an SMW "extensions" directory sounds very interesting, and maybe
presents itself as a long-term solution to the problem of getting all the
SMW extensions into one package - the vaunted "Semantic Bundle". Yes, I'm
doing what I can to try to get people to know about all the extensions, bu
Can I just chime in as a below-technical par user of these things.
Whatever you do, can you think about the consequences for maintenance
by end users (I mean MW administrators of course) with SVN. Right now
in Mediawiki proper (unless I've been totally dumb and there is a
better way I haven't figu
Oh, sorry, I was unclear: yes, you are fully right, every extension
should have its own folder. The question is just, should they be
1) Grouped in one SemanticMediaWikiExt directory
2) Be first level on the MediaWiki/extensions directory
3) Be grouped in a SemanticMediaWiki/extensions/ directory
4
On Mon, Aug 18, 2008 at 8:04 AM, Denny Vrandečić
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I am just wondering: I have two small extensions ready to release, and
> several others are brewing. As was discussed on this list, it was
> preferred not to have such extensions part of the core code, in orde
Hi all,
I am just wondering: I have two small extensions ready to release, and
several others are brewing. As was discussed on this list, it was
preferred not to have such extensions part of the core code, in order to
not increase code bloat, feature creep, and to increase maintainability
of the c
14 matches
Mail list logo