On 17.01.2013 15:46, Francesco Chicchiriccò wrote: > On 17/01/2013 15:37, Christian Schneider wrote: >> I added the code to copy them too. I just committed them as they were >> reported changed. Should I delete the files and tell svn to ignore them? > > Just updated svn:ignore + removed again all local archetype resources > from SVN. > I will open an issue to change the resource population for archetype > in order to be more robust to this kind of changes. > >> I found that the AbstractDAOTests can not simply create the Activiti >> properties as the table is not there when we omit the spring xml to >> initialize Activiti. So I wanted to make the ContentLoader more >> flexible. >> This way I was able to replace the xsl based removal of Activiti >> properties by a java based one. I think this is better than xsl as it is >> more obvious to see in the code. It took me a while to see that the xsl >> does this... > Did you take into any account the export procedure for subsequent > re-import when changing this logic? > Have you tried how this behaves in overlays generated from the archetype? > Now we don't have any more a single content.xml (as generated by > export generates) but two separate content.xml and activiticontent.xml > > I will open another issue to verify how export / import procedure will > work after these changes. > Hi Francesco,
I am not aware how it works in the archetype. Can you explain shortly how the export works? I thought that we simply use the content.xml as a kind of template in the archetype and people would later simply change it. If it is a bigger issue I can revert the changes. They are not necessary for the issue SYNCOPE-241. Btw. I found that the ImportExport class mixes two things that seem to be quite independent. What do you think about splitting ImportExport into an ImportContent class and an ExportContent class? As far as I understood these functionalities seem to share no code in the ImportExport class. Regards Christian
