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/main...
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/main...
On Mon, Jan 30, 2012 at 9:25 AM, Vincent Massol <[email protected]> wrote:
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.
+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.
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/main...
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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
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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Le 30 janv. 2012 à 09:25, Vincent Massol a écrit :
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht wrote:
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.
Tastes interesting but I think it might be easier to accomodate our tool to the widespread practice.
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
On Jan 30, 2012, at 5:24 PM, Paul Libbrecht wrote:
Le 30 janv. 2012 à 09:25, Vincent Massol a écrit :
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht wrote:
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.
Tastes interesting but I think it might be easier to accomodate our tool to the widespread practice.
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?
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwiki...
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
participants (4)
-
Paul Libbrecht -
rh -
Thomas Mortagne -
Vincent Massol