Hi Paul and Vincent I checkout out XEclipse and it is a nice tool but just not what I am looking for because I want to keep editing the code inside IntelliJ as a Groovy or Velocity script. Paul's idea is much closer to what I am looking for. Still I like XEclipse do view the content of a space in its raw format rather than through the XWiki view. At least this way I know what pages are out there in a space. That said last night I wrote a simple and stupid Maven 2 plugin that takes the plain code and inserts into the XML class using <![CDATA[ ... ]]> to protect the encoding and then build a XAR file from it using the XAR Maven 2 plugin. This is still cumbersome because I need to upload and import the XAR file which is too much of a hassle. Now I am thinking that maybe one could create a Maven 2 Plugin that uploads the Content of a page or an Object directly into the running XWiki instance as Paul's script or XEclipse does. This way I don't need a XAR file and I need one Maven command to upload all the changes in one step. Finally I ran into some shortcomings of the XAR plugin because the pages need to be placed into the "src/main/resources" directory. It might be better to make that configurable because my own Maven plugin needs to put the generated classes inside the "src/main/resources" directory but that is not a wise idea. If I find time I will make that configurable soon. Cheers - Andy On Dec 27, 2009, at 8:25 AM, Paul Libbrecht wrote:

We have been using a very simple post method that allows two things:

- keep the source code files as source, e.g. a velocity file is a .vm file - a command called uploadPages (made of mostly curl and a bit of groovy)

I use IntelliJ with a bit "well-informed-classes" to edit both groovy and velocity files and upload with uploadPages. See http://svn.activemath.org/intergeo/Platform/bin/ to get uploadPages and uploadPages.grv.

The big advantage of keeping the source files source is that they are svn-shared as is, so they merge well, and are edited with luxury (e.g. auto-complete on variable names, properties uniqueness check, evil velocity syntax catches, not yet wiki syntax protection indeed!).

I feel uploadPages should be turned into some simple ant tasks, I just didn't find the time to do it. I would also love that this would apply to any document-information, thus far it's just the page content in english.

Direct page preview of the page being edited, as XEclipse always does, is too minimalistic to my taste: I always test some derivative of the code I edit (e.g. I edit a groovy class and test a vm page that uses the groovy as tool, or I test things with parameters...).

paul

Le 27-déc.-09 à 10:16, Vincent Massol a écrit :

...

Hi Andreas,

On Dec 27, 2009, at 1:16 AM, Andreas Schaefer wrote:

...

Hi

For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes.

Because I don't use Eclipse I am not able to use the XEclipse tool

XEclipse is a standalone tool (it's a RCP application), you don't need Eclipse to use it... :)

...

but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file.

But then you need to load the XAR to test it. You need to automate that part too. What you need is the full round trip: - get a page content locally - make changes to it - save (which uploads it to the server) - test

This is what Eclipse does indeed. However XEclipse has some current limitations, one of which is that it doesn't work with XWiki Syntax 2.0 yet (there's some code for this in SVN I believe though). Unfortunately not many devs have been working on XEclipse which is a real pity since it has a huge potential.

Re encoding I'm not sure why you'd want to do that. You can just copy paste the content in pages directly without going through XAR + import.

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Paul I think the inclusion of external content is problematic because it must be maintained even through exports otherwise it helpfulness is limited. I went ahead and created a simple Maven plugin that published the content of Groovy or VM files into the appropriate document / object. The only thing it relies on is the pattern of the File name. It must look like this: <PageId>[.<class name>[.<object number>]].<extension> The plugin takes the URL to the server, user name and password and the Space the documents resides in. In addition it has a list of extension that will be removed from the file name before its pattern is parsed. This way I can support Groovy, Velocity, Java Script etc. For example the content of the Blog's AddCategory can be published in a file called: AddCategory.vm or the Archive Panel can be published with a file named: ArchivePanel.Panels.Category.groovy or ArchivePanel.Panels.Category.0.groovy This would be a simple configuration: <plugin> <groupId>org.xwiki.platform.tools</groupId> <artifactId>xwiki-content-publisher-plugin</artifactId> <version>1.5-SNAPSHOT</version> <executions> <execution> <phase>generate-sources</phase> <goals><goal>publish</goal></goals> <configuration> <sourceDirectory>src/main/content</sourceDirectory> <extensions>.groovy,.vm</extensions> <spaceName>GBlog</spaceName> <createElements>false</createElements> <serverURL>http://127.0.0.1:8080/xwiki/xmlrpc</serverURL> <userName>ABC</userName> <password>XXXX</password> </configuration> </execution> </executions> </plugin> This way I can develop the code outside and with a simple Maven plugin it can be pushed to the server much like your Groovy script but it works over a number of files or an entire project. Together with a merge tool (which could be incorporate into the XAR plugin or also could be place inside a separated plugin) this would make it easy to write application outside of XWiki using the tools like Eclipse or IntelliJ and still being able to easily post them to a XWiki or create a XAR file for publication. Cheers - Andy On Dec 28, 2009, at 2:04 PM, Paul Libbrecht wrote:

Andreas,

I think the best would be to: - allow XML documents of pages to include external content (that's been discussed many many times I think) as content - insert an upload or previewlifecycle phase (?) which would directly upload all changed files of the project into the xar maven plugin; is it possible with XML-encoded pages?

I agree with you that I'd rather have it all in src/main/pages or src/ main/wikipages (we use pages with our approach but it's not very systematic yet).

Best would be to have it all within the maven-xar plugin if you manage, I feel; but the opinions of its authors should rather be heard.

paul

Le 28-déc.-09 à 01:31, Andreas Schaefer a écrit :

...

Hi Paul and Vincent

I checkout out XEclipse and it is a nice tool but just not what I am looking for because I want to keep editing the code inside IntelliJ as a Groovy or Velocity script. Paul's idea is much closer to what I am looking for. Still I like XEclipse do view the content of a space in its raw format rather than through the XWiki view. At least this way I know what pages are out there in a space.

That said last night I wrote a simple and stupid Maven 2 plugin that takes the plain code and inserts into the XML class using <! [CDATA[ ... ]]> to protect the encoding and then build a XAR file from it using the XAR Maven 2 plugin. This is still cumbersome because I need to upload and import the XAR file which is too much of a hassle.

Now I am thinking that maybe one could create a Maven 2 Plugin that uploads the Content of a page or an Object directly into the running XWiki instance as Paul's script or XEclipse does. This way I don't need a XAR file and I need one Maven command to upload all the changes in one step.

Finally I ran into some shortcomings of the XAR plugin because the pages need to be placed into the "src/main/resources" directory. It might be better to make that configurable because my own Maven plugin needs to put the generated classes inside the "src/main/ resources" directory but that is not a wise idea. If I find time I will make that configurable soon.

Cheers - Andy

On Dec 27, 2009, at 8:25 AM, Paul Libbrecht wrote:

...

We have been using a very simple post method that allows two things:

- keep the source code files as source, e.g. a velocity file is a .vm file - a command called uploadPages (made of mostly curl and a bit of groovy)

I use IntelliJ with a bit "well-informed-classes" to edit both groovy and velocity files and upload with uploadPages. See http://svn.activemath.org/intergeo/Platform/bin/ to get uploadPages and uploadPages.grv.

The big advantage of keeping the source files source is that they are svn-shared as is, so they merge well, and are edited with luxury (e.g. auto-complete on variable names, properties uniqueness check, evil velocity syntax catches, not yet wiki syntax protection indeed!).

I feel uploadPages should be turned into some simple ant tasks, I just didn't find the time to do it. I would also love that this would apply to any document-information, thus far it's just the page content in english.

Direct page preview of the page being edited, as XEclipse always does, is too minimalistic to my taste: I always test some derivative of the code I edit (e.g. I edit a groovy class and test a vm page that uses the groovy as tool, or I test things with parameters...).

paul

Le 27-déc.-09 à 10:16, Vincent Massol a écrit :

...

Hi Andreas,

On Dec 27, 2009, at 1:16 AM, Andreas Schaefer wrote:

...

Hi

For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes.

Because I don't use Eclipse I am not able to use the XEclipse tool

XEclipse is a standalone tool (it's a RCP application), you don't need Eclipse to use it... :)

...

but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file.

But then you need to load the XAR to test it. You need to automate that part too. What you need is the full round trip: - get a page content locally - make changes to it - save (which uploads it to the server) - test

This is what Eclipse does indeed. However XEclipse has some current limitations, one of which is that it doesn't work with XWiki Syntax 2.0 yet (there's some code for this in SVN I believe though). Unfortunately not many devs have been working on XEclipse which is a real pity since it has a huge potential.

Re encoding I'm not sure why you'd want to do that. You can just copy paste the content in pages directly without going through XAR + import.

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Because I am really lazy and if I banged my head enough on a wall I start doing what I was suppose to do a long time ago. As already mentioned in a Tweet I finally managed to create an IntelliJ 9 Plugin that will deploy the content of an Document onto a configured life server. Before deploying the Plugin to the JetBrains plugin repository I would love to test that by someone else. Is anyone out there willing to test that XWiki Publisher Plugin for IntelliJ 9 (Community Edition should work) ? It is configurable (server url, user name / password, target space and optional extension list). With that plugin you can publish the content of a page or object with a simple keyboard shortcut. This can be text, groovy, velocity etc. The plugin relies on this naming convention: - file extension are remove first - everything before the 1st dot is the document name in the given space - if there is a number at the end of the file name this is the object number / index - everything else, if provided, is the object class name Examples: - AddCategory.groovy referes to the <Space>.AddCategory document - ManageCategories.XWiki.JavaScriptExtension.js referes to the <Space>ManageCategories XWiki.JavaScriptExtension object (first one) - ManageCategories.XWiki.JavaScriptExtension.1.js referes to the <Space>ManageCategories XWiki.JavaScriptExtension second object Cheers - Andy On Dec 28, 2009, at 5:49 PM, Andreas Schaefer wrote:

Hi Paul

I think the inclusion of external content is problematic because it must be maintained even through exports otherwise it helpfulness is limited.

I went ahead and created a simple Maven plugin that published the content of Groovy or VM files into the appropriate document / object. The only thing it relies on is the pattern of the File name. It must look like this:

<PageId>[.<class name>[.<object number>]].<extension>

The plugin takes the URL to the server, user name and password and the Space the documents resides in. In addition it has a list of extension that will be removed from the file name before its pattern is parsed. This way I can support Groovy, Velocity, Java Script etc. For example the content of the Blog's AddCategory can be published in a file called:

AddCategory.vm

or the Archive Panel can be published with a file named:

ArchivePanel.Panels.Category.groovy or ArchivePanel.Panels.Category.0.groovy

This would be a simple configuration:

<plugin> <groupId>org.xwiki.platform.tools</groupId> <artifactId>xwiki-content-publisher-plugin</artifactId> <version>1.5-SNAPSHOT</version> <executions> <execution> <phase>generate-sources</phase> <goals><goal>publish</goal></goals> <configuration> <sourceDirectory>src/main/content</sourceDirectory> <extensions>.groovy,.vm</extensions> <spaceName>GBlog</spaceName> <createElements>false</createElements> <serverURL>http://127.0.0.1:8080/xwiki/xmlrpc</serverURL> <userName>ABC</userName> <password>XXXX</password> </configuration> </execution> </executions> </plugin>

This way I can develop the code outside and with a simple Maven plugin it can be pushed to the server much like your Groovy script but it works over a number of files or an entire project. Together with a merge tool (which could be incorporate into the XAR plugin or also could be place inside a separated plugin) this would make it easy to write application outside of XWiki using the tools like Eclipse or IntelliJ and still being able to easily post them to a XWiki or create a XAR file for publication.

Cheers - Andy

On Dec 28, 2009, at 2:04 PM, Paul Libbrecht wrote:

...

Andreas,

I think the best would be to: - allow XML documents of pages to include external content (that's been discussed many many times I think) as content - insert an upload or previewlifecycle phase (?) which would directly upload all changed files of the project into the xar maven plugin; is it possible with XML-encoded pages?

I agree with you that I'd rather have it all in src/main/pages or src/ main/wikipages (we use pages with our approach but it's not very systematic yet).

Best would be to have it all within the maven-xar plugin if you manage, I feel; but the opinions of its authors should rather be heard.

paul

Le 28-déc.-09 à 01:31, Andreas Schaefer a écrit :

...

Hi Paul and Vincent

I checkout out XEclipse and it is a nice tool but just not what I am looking for because I want to keep editing the code inside IntelliJ as a Groovy or Velocity script. Paul's idea is much closer to what I am looking for. Still I like XEclipse do view the content of a space in its raw format rather than through the XWiki view. At least this way I know what pages are out there in a space.

That said last night I wrote a simple and stupid Maven 2 plugin that takes the plain code and inserts into the XML class using <! [CDATA[ ... ]]> to protect the encoding and then build a XAR file from it using the XAR Maven 2 plugin. This is still cumbersome because I need to upload and import the XAR file which is too much of a hassle.

Now I am thinking that maybe one could create a Maven 2 Plugin that uploads the Content of a page or an Object directly into the running XWiki instance as Paul's script or XEclipse does. This way I don't need a XAR file and I need one Maven command to upload all the changes in one step.

Finally I ran into some shortcomings of the XAR plugin because the pages need to be placed into the "src/main/resources" directory. It might be better to make that configurable because my own Maven plugin needs to put the generated classes inside the "src/main/ resources" directory but that is not a wise idea. If I find time I will make that configurable soon.

Cheers - Andy

On Dec 27, 2009, at 8:25 AM, Paul Libbrecht wrote:

...

We have been using a very simple post method that allows two things:

- keep the source code files as source, e.g. a velocity file is a .vm file - a command called uploadPages (made of mostly curl and a bit of groovy)

I use IntelliJ with a bit "well-informed-classes" to edit both groovy and velocity files and upload with uploadPages. See http://svn.activemath.org/intergeo/Platform/bin/ to get uploadPages and uploadPages.grv.

The big advantage of keeping the source files source is that they are svn-shared as is, so they merge well, and are edited with luxury (e.g. auto-complete on variable names, properties uniqueness check, evil velocity syntax catches, not yet wiki syntax protection indeed!).

I feel uploadPages should be turned into some simple ant tasks, I just didn't find the time to do it. I would also love that this would apply to any document-information, thus far it's just the page content in english.

Direct page preview of the page being edited, as XEclipse always does, is too minimalistic to my taste: I always test some derivative of the code I edit (e.g. I edit a groovy class and test a vm page that uses the groovy as tool, or I test things with parameters...).

paul

Le 27-déc.-09 à 10:16, Vincent Massol a écrit :

...

Hi Andreas,

On Dec 27, 2009, at 1:16 AM, Andreas Schaefer wrote:

...

Hi

For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes.

Because I don't use Eclipse I am not able to use the XEclipse tool

XEclipse is a standalone tool (it's a RCP application), you don't need Eclipse to use it... :)

...

but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file.

But then you need to load the XAR to test it. You need to automate that part too. What you need is the full round trip: - get a page content locally - make changes to it - save (which uploads it to the server) - test

This is what Eclipse does indeed. However XEclipse has some current limitations, one of which is that it doesn't work with XWiki Syntax 2.0 yet (there's some code for this in SVN I believe though). Unfortunately not many devs have been working on XEclipse which is a real pity since it has a huge potential.

Re encoding I'm not sure why you'd want to do that. You can just copy paste the content in pages directly without going through XAR + import.

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Paul Thanks for the hint with the directory. I will go ahead and implement it and send it to you afterwards. For now this is only a publishing plugin meaning it only puts code onto the server and not the other way around. IntelliJ has a way to compare and merge files but I am not quite sure if I have the time to do that. But maybe in the future if enough people are using it. For right now IntelliJ has the content meaning as a Velocity, Groovy or Text file and so IntelliJ does the syntax highlighting. I did not add any such thing for the XWiki syntax. For now the goal of the plugin is to enable Velocity or Groovy developers to use the power of the IDE and push it to the server quickly. I did assume that this is done against a local server and when the application is finished and ready to be deployed that a XAR file is created for this. Later multi user development could be added. Gimme a few days and I will sent it your way. Thanks - Andy On Jan 3, 2010, at 11:37 AM, Paul Libbrecht wrote:

I would love to test this!

As a small feature request I would suggest to make the space name be, by default, the directory name. I would also add yet another oil to the naming: the language in such as WebHome.fr.vm (so that's the french version of the WebHome document).

I'm interested to see how you pull things up and down and prevent desychnronization. I'm also interested to see the syntax highlighting you reach! (differently said: is there a way to make the wiki syntax *also* in there!)

thanks much

paul

Le 03-janv.-10 à 06:15, Andreas Schaefer a écrit :

...

Because I am really lazy and if I banged my head enough on a wall I start doing what I was suppose to do a long time ago.

As already mentioned in a Tweet I finally managed to create an IntelliJ 9 Plugin that will deploy the content of an Document onto a configured life server. Before deploying the Plugin to the JetBrains plugin repository I would love to test that by someone else.

Is anyone out there willing to test that XWiki Publisher Plugin for IntelliJ 9 (Community Edition should work) ? It is configurable (server url, user name / password, target space and optional extension list). With that plugin you can publish the content of a page or object with a simple keyboard shortcut. This can be text, groovy, velocity etc. The plugin relies on this naming convention:

- file extension are remove first - everything before the 1st dot is the document name in the given space - if there is a number at the end of the file name this is the object number / index - everything else, if provided, is the object class name

Examples:

- AddCategory.groovy referes to the <Space>.AddCategory document - ManageCategories.XWiki.JavaScriptExtension.js referes to the <Space>ManageCategories XWiki.JavaScriptExtension object (first one) - ManageCategories.XWiki.JavaScriptExtension.1.js referes to the <Space>ManageCategories XWiki.JavaScriptExtension second object

Cheers - Andy

On Dec 28, 2009, at 5:49 PM, Andreas Schaefer wrote:

...

Hi Paul

I think the inclusion of external content is problematic because it must be maintained even through exports otherwise it helpfulness is limited.

I went ahead and created a simple Maven plugin that published the content of Groovy or VM files into the appropriate document / object. The only thing it relies on is the pattern of the File name. It must look like this:

<PageId>[.<class name>[.<object number>]].<extension>

The plugin takes the URL to the server, user name and password and the Space the documents resides in. In addition it has a list of extension that will be removed from the file name before its pattern is parsed. This way I can support Groovy, Velocity, Java Script etc. For example the content of the Blog's AddCategory can be published in a file called:

AddCategory.vm

or the Archive Panel can be published with a file named:

ArchivePanel.Panels.Category.groovy or ArchivePanel.Panels.Category.0.groovy

This would be a simple configuration:

<plugin> <groupId>org.xwiki.platform.tools</groupId> <artifactId>xwiki-content-publisher-plugin</artifactId> <version>1.5-SNAPSHOT</version> <executions> <execution> <phase>generate-sources</phase> <goals><goal>publish</goal></goals> <configuration> <sourceDirectory>src/main/content</sourceDirectory> <extensions>.groovy,.vm</extensions> <spaceName>GBlog</spaceName> <createElements>false</createElements> <serverURL>http://127.0.0.1:8080/xwiki/xmlrpc</serverURL> <userName>ABC</userName> <password>XXXX</password> </configuration> </execution> </executions> </plugin>

This way I can develop the code outside and with a simple Maven plugin it can be pushed to the server much like your Groovy script but it works over a number of files or an entire project. Together with a merge tool (which could be incorporate into the XAR plugin or also could be place inside a separated plugin) this would make it easy to write application outside of XWiki using the tools like Eclipse or IntelliJ and still being able to easily post them to a XWiki or create a XAR file for publication.

Cheers - Andy

On Dec 28, 2009, at 2:04 PM, Paul Libbrecht wrote:

...

Andreas,

I think the best would be to: - allow XML documents of pages to include external content (that's been discussed many many times I think) as content - insert an upload or previewlifecycle phase (?) which would directly upload all changed files of the project into the xar maven plugin; is it possible with XML-encoded pages?

I agree with you that I'd rather have it all in src/main/pages or src/ main/wikipages (we use pages with our approach but it's not very systematic yet).

Best would be to have it all within the maven-xar plugin if you manage, I feel; but the opinions of its authors should rather be heard.

paul

Le 28-déc.-09 à 01:31, Andreas Schaefer a écrit :

...

Hi Paul and Vincent

I checkout out XEclipse and it is a nice tool but just not what I am looking for because I want to keep editing the code inside IntelliJ as a Groovy or Velocity script. Paul's idea is much closer to what I am looking for. Still I like XEclipse do view the content of a space in its raw format rather than through the XWiki view. At least this way I know what pages are out there in a space.

That said last night I wrote a simple and stupid Maven 2 plugin that takes the plain code and inserts into the XML class using <! [CDATA[ ... ]]> to protect the encoding and then build a XAR file from it using the XAR Maven 2 plugin. This is still cumbersome because I need to upload and import the XAR file which is too much of a hassle.

Now I am thinking that maybe one could create a Maven 2 Plugin that uploads the Content of a page or an Object directly into the running XWiki instance as Paul's script or XEclipse does. This way I don't need a XAR file and I need one Maven command to upload all the changes in one step.

Finally I ran into some shortcomings of the XAR plugin because the pages need to be placed into the "src/main/resources" directory. It might be better to make that configurable because my own Maven plugin needs to put the generated classes inside the "src/main/ resources" directory but that is not a wise idea. If I find time I will make that configurable soon.

Cheers - Andy

On Dec 27, 2009, at 8:25 AM, Paul Libbrecht wrote:

...

We have been using a very simple post method that allows two things:

- keep the source code files as source, e.g. a velocity file is a .vm file - a command called uploadPages (made of mostly curl and a bit of groovy)

I use IntelliJ with a bit "well-informed-classes" to edit both groovy and velocity files and upload with uploadPages. See http://svn.activemath.org/intergeo/Platform/bin/ to get uploadPages and uploadPages.grv.

The big advantage of keeping the source files source is that they are svn-shared as is, so they merge well, and are edited with luxury (e.g. auto-complete on variable names, properties uniqueness check, evil velocity syntax catches, not yet wiki syntax protection indeed!).

I feel uploadPages should be turned into some simple ant tasks, I just didn't find the time to do it. I would also love that this would apply to any document-information, thus far it's just the page content in english.

Direct page preview of the page being edited, as XEclipse always does, is too minimalistic to my taste: I always test some derivative of the code I edit (e.g. I edit a groovy class and test a vm page that uses the groovy as tool, or I test things with parameters...).

paul

Le 27-déc.-09 à 10:16, Vincent Massol a écrit :

> Hi Andreas, > > On Dec 27, 2009, at 1:16 AM, Andreas Schaefer wrote: > >> Hi >> >> For the development of the Groovy based Blog I just developed the >> code in IntelliJ, copied inside a browser and eventually exported >> the content into a XAR file. Slowly but surely this is getting way >> to much work especially when doing sweeping changes. >> >> Because I don't use Eclipse I am not able to use the XEclipse tool > > XEclipse is a standalone tool (it's a RCP application), you don't > need > Eclipse to use it... :) > >> but I was wondering if anybody knows a way to XML encode text >> (within Maven2) so that it later could use Ant's copy and filter >> tool to incorporate the developed code / content inside the XML >> file >> that will build up the XAR file. > > But then you need to load the XAR to test it. You need to automate > that part too. What you need is the full round trip: > - get a page content locally > - make changes to it > - save (which uploads it to the server) > - test > > This is what Eclipse does indeed. However XEclipse has some current > limitations, one of which is that it doesn't work with XWiki Syntax > 2.0 yet (there's some code for this in SVN I believe though). > Unfortunately not many devs have been working on XEclipse which is a > real pity since it has a huge potential. > > Re encoding I'm not sure why you'd want to do that. You can just > copy > paste the content in pages directly without going through XAR + > import. > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

that certainly tastes something that could be wishable but I wonder if there's not something hidden here. I haven't heard of many "virtual subversion servers", have you? The worst hidden bit is, in my current practice, that all our sources are, of course, in our subversion repository anyways so one would need to start the multiple-subversion-business (svk maybe?) which is considerably less robust than svn as far as I know. paul Le 29-déc.-09 à 01:24, Niels Mayer a écrit :

What about having a "virtual" subversion checkin URL associated with any Xwiki site. There's be a restricted set of files that could be checked in, where most Xwiki documents are ".vm" files -- velocity macro.

The subversion protocol, which is just HTTP, would actually be implemented in Xwiki, such that subversion checkins would checkin a new version (doing all the xml-encoding and name-fixing needed for storage in xwiki's db). A subversion checkout would de-encode the XML and reverse-name-fix for 1-1 correspondence with the checked-in file. Fancier subversion protocol functionalit like diffs and retrieving revs, etc could all be "not implemented" but the basics of checkin/checkout to the "head" would still work. Most of subversion's "RCS" facilities are already implemented in Xwiki's document store, so this proposed feature would represent a bridge between subversion and the document store. The user would end up using whatever preferred GUI frontend (or commandline) svn tools available....

There'd be numerous limitations on this virtual subversion store that would just cause it to "error out" if inappropriate filenames or directories are attempted checkin (e.g. "." in the name). Errors would also occur w/ invalid xwiki db read/write perms for the checkin user. Further, the special subversion repo would also only implement one level of "directory" (representing xwiki spaces) and would require that any non-vm files (aka attachments) have a valid path representing the document name (minus vm exptension). e.g. /<space>/<document>/<attachment>.<ext> for all /<space>/<document>.vm

Niels http://nielsmayer.com

On Sat, Dec 26, 2009 at 4:16 PM, Andreas Schaefer <[email protected]> wrote:

...

Hi

For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes.

Because I don't use Eclipse I am not able to use the XEclipse tool but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file.

Thanks - Andy _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs