29 Dec
2009
29 Dec
'09
11:09 p.m.
Le 29-déc.-09 à 02:49, Andreas Schaefer a écrit :
I think the inclusion of external content is
problematic because it
must be maintained even through exports otherwise it helpfulness is
limited.
But you were doing inclusion, so why is it problematic?
The thing is... you need property inclusion if you want the xar to
contain all the things (e.g. the rights attached to a document, the
object properties). The "plain text files" would only be needed for
those bits that you really care to manually encode, e.g. the source
content, the panel text property, ...
It is zero problem for a developer to maintain the consistency of
files I think.
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
Is this the object property value ? It looks like it.
The below code seems to indicate a spaceName, why this not the
directory name?
it sounds quite attractive though, I would love to have this.
why not bind this to an "extra" lifecycle phase? I think generate-
sources is always run when you build such lifecycle phase as install
(which is the default suggestion) whereas the normal build system of a
deployed application should probably not include it.
Btw, as far as I could tell, the "official" extension for groovy files
is not .groovy but .grv.
paul
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 :
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs