30 Jan
2012
30 Jan
'12
8:24 a.m.
Hello fellow XWikiers,
I am regularly working with my favorite IDE, IntelliJ IDEA, and it is doing a very good
work for me to edit velocity and groovy. I am using this also for the source of wiki pages
which I upload using a tiny upload script (that posts like a form using curl and simple
preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Thus far I've been using wiki/src/main/pages/<spaceName>/<pageName>.vm (or
.grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
thanks in advance
Paul
[1] upload-to-wiki can be found in
https://github.com/xwiki-contrib/xwiki-clams-core/tree/master/tools/src/mai…
30 Jan
30 Jan
9:25 a.m.
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht wrote:
Hello fellow XWikiers,
I am regularly working with my favorite IDE, IntelliJ IDEA, and it is doing a very good
work for me to edit velocity and groovy. I am using this also for the source of wiki pages
which I upload using a tiny upload script (that posts like a form using curl and simple
preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Yep, we already save our XAR pages in our SCM in the xwiki project dev.
Thus far I've been using
wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
Personally I'd love to have an IDE plugin (for intellij IEA for example; )) that would
take a file in XWiki XML format and displays the content as editable text. When saved, it
would be saved in the XWiki XML format with proper XML-encoding.
An alternative which might be even better (since it would work with all IDEs and I think
this is what you're proposing) would be to do something like this:
* Store XAR pages into 2 files:
** one file for the content itself saved without XML-encoding, as plain text
** another file containing the metadata
* Modify our XAR plugin so that it combines the 2 files into one XML file in the XWiki XML
file format when it generates the XAR.
* Adding a Mojo so that the user can upload a given page into a running instance would be
the icing on the cake.
* We'll also need another mojo that takes an existing XAR and extracts it and split
pages into the 2 files mentioned above.
The issue you have with classpath resolution is probably not so hard to fix. I'll need
to try this out to try to find a solution.
Definitely +1 from me to explore such ideas. The best IMO Paul would be to continue the
work we started with the XAR plugin.
Thanks
-Vincent
thanks in advance
Paul
[1] upload-to-wiki can be found in
https://github.com/xwiki-contrib/xwiki-clams-core/tree/master/tools/src/mai…
9:33 a.m.
On Mon, Jan 30, 2012 at 9:25 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht wrote:
+1, I agree there is a lot of things we can improve and add in the XAR
plugin. Add support for an expanded page format should not be very
hard.
Hello fellow XWikiers,
I am regularly working with my favorite IDE, IntelliJ IDEA, and it is doing a very good
work for me to edit velocity and groovy. I am using this also for the source of wiki pages
which I upload using a tiny upload script (that posts like a form using curl and simple
preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Yep, we already save our XAR pages in our SCM in the xwiki project dev.
Thus far I've been using
wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
Personally I'd love to have an IDE plugin (for intellij IEA for example; )) that
would take a file in XWiki XML format and displays the content as editable text. When
saved, it would be saved in the XWiki XML format with proper XML-encoding.
An alternative which might be even better (since it would work with all IDEs and I think
this is what you're proposing) would be to do something like this:
* Store XAR pages into 2 files:
** one file for the content itself saved without XML-encoding, as plain text
** another file containing the metadata
* Modify our XAR plugin so that it combines the 2 files into one XML file in the XWiki
XML file format when it generates the XAR.
* Adding a Mojo so that the user can upload a given page into a running instance would be
the icing on the cake.
* We'll also need another mojo that takes an existing XAR and extracts it and split
pages into the 2 files mentioned above.
The issue you have with classpath resolution is probably not so hard to fix. I'll
need to try this out to try to find a solution.
Definitely +1 from me to explore such ideas. The best IMO Paul would be to continue the
work we started with the XAR plugin.
Thanks
-Vincent
--
Thomas Mortagne
thanks in advance
Paul
[1] upload-to-wiki can be found in
https://github.com/xwiki-contrib/xwiki-clams-core/tree/master/tools/src/mai…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
8:29 p.m.
Am 30.01.2012 09:33, schrieb Thomas Mortagne:
* Store XAR pages into 2 files:
> ** one file for the content itself saved without XML-encoding, as plain text
> ** another file containing the metadata
> * Modify our XAR plugin so that it combines the 2 files into one XML file in the
XWiki XML file format when it generates the XAR.
> * Adding a Mojo so that the user can upload a given page into a running instance
would be the icing on the cake.
> * We'll also need another mojo that takes an existing XAR and extracts it and
split pages into the 2 files mentioned above.
I have implemented a simliar approach in my private workspace. I have
* a mojo that parses wiki pages xml files for #include and #attach
directives (allows storing attachments in it's original form in SCM).
The result is written into target/resources.
* the normal xar packaging reads the xml files from target/resources,
creates the packaging.xml and creates the xar file.
* I have extended the rest interface by a xar import/export feature.
* I have an mojo that deploys the created xar via the rest interface.
It works quite well. I am working with eclipse. Via the external tool
configuration I can deploy the xar directly from the IDE.
If someone is interrested I can contribute the code.
For me an ideal solution would be an extended XAR file, that can contain
wiki pages (xml), java classes (with @Component annotations) and
frontend resources (javascript, GWT, ...). Such a XAR file should be
deployable via the rest interface. On the maven layer it should be an
normal jar packaging project with additional resources (wiki pages,
attachments).
Richard
10:41 p.m.
Richard,
you seem to have a lot.
I'm not sure #include is what one wants... but that can still be discussed.
Is that code on top of the xar plugin?
Can you share it?
paul
rh <rhierlmeier(a)googlemail.com> a écrit :
Am 30.01.2012 09:33, schrieb Thomas Mortagne:
* Store XAR pages into 2 files:
> ** one file for the content itself saved without XML-encoding, as plain text
> ** another file containing the metadata
> * Modify our XAR plugin so that it combines the 2 files into one XML file in the
XWiki XML file format when it generates the XAR.
> * Adding a Mojo so that the user can upload a given page into a running instance
would be the icing on the cake.
> * We'll also need another mojo that takes an existing XAR and extracts it and
split pages into the 2 files mentioned above.
I have implemented a simliar approach in my private workspace. I have
* a mojo that parses wiki pages xml files for #include and #attach
directives (allows storing attachments in it's original form in SCM).
The result is written into target/resources.
* the normal xar packaging reads the xml files from target/resources,
creates the packaging.xml and creates the xar file.
* I have extended the rest interface by a xar import/export feature.
* I have an mojo that deploys the created xar via the rest interface.
It works quite well. I am working with eclipse. Via the external tool
configuration I can deploy the xar directly from the IDE.
If someone is interrested I can contribute the code.
For me an ideal solution would be an extended XAR file, that can contain
wiki pages (xml), java classes (with @Component annotations) and
frontend resources (javascript, GWT, ...). Such a XAR file should be
deployable via the rest interface. On the maven layer it should be an
normal jar packaging project with additional resources (wiki pages,
attachments).
Richard
_____________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:24 p.m.
Le 30 janv. 2012 à 09:25, Vincent Massol a écrit :
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht wrote:
Tastes interesting but I think it might be easier to accomodate our tool to the widespread
practice.
I am regularly working with my favorite IDE,
IntelliJ IDEA, and it is doing a very good work for me to edit velocity and groovy. I am
using this also for the source of wiki pages which I upload using a tiny upload script
(that posts like a form using curl and simple preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Yep, we already save our XAR pages in our SCM in the xwiki project dev.
Thus far I've been using
wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
Personally I'd love to have an IDE plugin (for intellij IEA for example; )) that
would take a file in XWiki XML format and displays the content as editable text. When
saved, it would be saved in the XWiki XML format with proper XML-encoding. An alternative which might be even better (since it
would work with all IDEs and I think this is what you're proposing) would be to do
something like this:
* Store XAR pages into 2 files:
** one file for the content itself saved without XML-encoding, as plain text
** another file containing the metadata
Correct.
And XInclude has one form for such inclusion.
* Modify our XAR plugin so that it combines the 2
files into one XML file in the XWiki XML file format when it generates the XAR.
I would love that!
* Adding a Mojo so that the user can upload a given
page into a running instance would be the icing on the cake.
indeed. Or use some other simpler tool.
Here, the real power might be to do some version control to avoid conflict with a
previous... not sure it is desired or possible.
* We'll also need another mojo that takes an
existing XAR and extracts it and split pages into the 2 files mentioned above.
Very easy if XInclude is used.
(I tend to use jdom for this kind of things, dom4j works well also)
The issue you have with classpath resolution is
probably not so hard to fix.
I'll need to try this out to try to find a solution.
Gotcha, you remember me JetBrains Support helped me there... Just add "xar"
among the archive file types in the preferences!!
Definitely +1 from me to explore such ideas. The best
IMO Paul would be to continue the work we started with the XAR plugin.
Ok... where' the code?
Who are the guys on it?
I sure have the XML competency but less the maven competency (last i programmed for maven
when at jelly times).
paul
6:39 p.m.
On Jan 30, 2012, at 5:24 PM, Paul Libbrecht wrote:
Le 30 janv. 2012 à 09:25, Vincent Massol a écrit :
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwik…
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht
wrote:
Tastes interesting but I think it might be easier to accomodate our tool to the
widespread practice.
I am regularly working with my favorite IDE,
IntelliJ IDEA, and it is doing a very good work for me to edit velocity and groovy. I am
using this also for the source of wiki pages which I upload using a tiny upload script
(that posts like a form using curl and simple preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Yep, we already save our XAR pages in our SCM in the xwiki project dev.
Thus far I've been using
wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
Personally I'd love to have an IDE plugin (for intellij IEA for example; )) that
would take a file in XWiki XML format and displays the content as editable text. When
saved, it would be saved in the XWiki XML format with proper XML-encoding. An alternative which might be even better (since
it would work with all IDEs and I think this is what you're proposing) would be to do
something like this:
* Store XAR pages into 2 files:
** one file for the content itself saved without XML-encoding, as plain text
** another file containing the metadata
Correct.
And XInclude has one form for such inclusion.
* Modify our XAR plugin so that it combines the 2
files into one XML file in the XWiki XML file format when it generates the XAR.
I would love that!
* Adding a Mojo so that the user can upload a
given page into a running instance would be the icing on the cake.
indeed. Or use some other simpler tool.
Here, the real power might be to do some version control to avoid conflict with a
previous... not sure it is desired or possible.
* We'll also need another mojo that takes an
existing XAR and extracts it and split pages into the 2 files mentioned above.
Very easy if XInclude is used.
(I tend to use jdom for this kind of things, dom4j works well also)
The issue you have with classpath resolution is
probably not so hard to fix.
I'll need to try this out to try to find a solution.
Gotcha, you remember me JetBrains Support helped me there... Just add "xar"
among the archive file types in the preferences!!
Definitely +1 from me to explore such ideas. The
best IMO Paul would be to continue the work we started with the XAR plugin.
Ok... where' the code? Who are the guys on it?
Right now, nobody, it's all yours ;)
You can send pull requests and we'll apply.
I sure have the XML competency but less the maven
competency (last i programmed for maven when at jelly times).
oh good old jelly! I remember that times when James just created Jelly and we were having
fun with it. It didn't look at bad idea at the time ;)
Thanks
-Vincent
4613
days inactive
4613
days old
6 comments
4 participants
participants (4)
-
Paul Libbrecht -
rh -
Thomas Mortagne -
Vincent Massol