How can I exclude individual resources

[barbs]

I have two Flare projects. I am importing 7 source files from ProjectA into ProjectB. I have enabled "Import resources" as these files contain about 10 or so snippets that about 10 images that must also be imported. I have also enabled "Auto re-import" as both of these are active projects, and I want to keep the files in ProjectB updated as their source files in ProjectA are updated.

The problem is that 2 of the imported images already exist in ProjectB. Each time I re-import, these images are imported with an incremental file name. For instance, information.png imports as information1.png. And the imported source file that references information.png automatically updates to link to information1.png. This wouldn't be a big problem if it ended right there. But if I turn around and import again, I get information2.png, and so on and so on.

I tried to update my import file. I opened it with the Internal Text Editor and added the image files to the ExcludedFiles tag. And removed the image files from the GeneratedFiles tag. And Yes, I double checked that the Source and AbsoluteSource referenced in the ExcludedFiles tags are for the source files that are being imported.

Code: Select all

  <ExcludedFiles>
    <Url
      Source="../../../IntegrationBuilder/Content/Resources/Images/Information.png"
      AbsoluteSource="file:///C:/Users/bstork/Perforce/BSPC/Help/BarTender/Main/IntegrationBuilder/Content/Resources/Images/Information.png" />
    <Url
      Source="../../../IntegrationBuilder/Content/Resources/Images/Warning.png"
      AbsoluteSource="file:///C:/Users/bstork/Perforce/BSPC/Help/BarTender/Main/IntegrationBuilder/Content/Resources/Images/Warning.png" />
  </ExcludedFiles>

This did not work. While my additions to the ExcludedFiles tag remain, they don't seem to have any effect. Once I re-import, the image files are added back into the GeneratedFiles tag, having simply updated the file for the most recent image import, for example information#.png.

If anyone can help me figure this out, I would be very thankful!
Barb

NOTE: We used Perforce for source control of our projects/files. Each time I build the project that is importing the files, I have to checkout all files relate to the import, as they must all be readable. That includes all source files, snippets, and images, as well as the import file, the import TOC, and the project file.

[sfng]

I'm amazed that there are no replies (and no other threads either!) about this.

I have this exact same problem. I need to reuse in my project (let's call it the target project) some files that exist already in another project (source project). These source topic files have images, some of which already exist in the target (for example the product logo) and one of the topics references a table stylesheet that also exists in the target project. In addition the source file contains snippets.

When I do the initial import any file that exists already in the target gets a duplicate with the number 1 added to the end, for example tablestyle.css exists already and the import adds tablestyle1.css to my tablestyle folder.

Any reimports bring in further duplicates, many more than the initial import because now all the resource files exist in the target, this includes the images and the snippets. So aswell as a snippet brought in by the import "importedsnippet.flsnp" now I have "importedsnippet1.flsnp" in the snippets folder, and then also I end up with tablestyle.css; tablestyle1.css; and tablestyle2.css!!


This is nothing to do with the timestamp. I tested this by manually copy pasting the source table style file over to replace my target table style file so that they were truly identical. The import process still makes a duplicate table style file. I thought that the timestamp might be an issue as all the files are version controlled (not in Flare but externally).

The imported topic files are rewritten in the import process to use the duplicate files, so that the table in the imported topic references image1.png instead of image.png and tablestyle1.css instead of just tablestyle.css so you can't just manually delete the duplicate files unless you go into the underlying code and correct the references also.

Flare obviously sees that these files exist already, or it would not make the duplicates, so why can't it ask if you want to replace the files you have already with the imported versions which have the same name?

This whole process strikes me as a bug, why would anyone want to create duplicates without being asked if you actually want them first?

[barbs]

Sorry, but I'm kind of glad I'm not the only person that has run into this problem. I'll try and explain what is working for us. I actually just wrote down this process so I can get it documented here at the office.

1. In Windows Explorer, navigate to your project folder
2. In the Content folder, create a subfolder called “Imported”. This will be at the same level as “Resources.”
3. Check out from your version control software the project file (*.flprj) for the project into which you want to import files.
4. Open the project in in Flare.
5. Select the Project tab in Flare.
6. Click Import and select HTML File Set.
7. In the Import HTML Files Wizard, on the Import HTML Files page, select Import into this project.
8. Click Next.
9. On the next page, click the “plus” icon and to open the Open File dialog, browse to the appropriate folder, and select the files you want to import.
10. Click Open to close the Open File dialog. The files you want to import should now appear in the Import HTML Files Wizard.
11. Enable (check) Link Generated Files to Source Files.
12. Click Next.
13. Click Import to folder, and browse to and select the “Imported” folder that you created in step 2.
14. Enable (check) Import resources.
15. Select Keep existing structure.
16. Enable (check) Auto-reimport before ‘Generate Output’.
17. Click Finish.
18. Ignore the errors about unable to find the styles. (It seems that Flare is smart enough to figure out to use the styles associated with the project into which the file are imported; ours are the same in both projects, so not an issue).
19. On the Accept Imported Documents dialog, click Accept.

This is what our folder structure looks like then in Flare's Content Explorer:

ContentFolder.jpg

The 7 "Deploy" files you see in the above screenshot are the imported files. The images and snippets that those files link to are in the Imported/Resources/Images folder and the Imported/Resources/Snippets folder. I do not end up with any repeated images in the "main" Resources/Images folder for the project.

I check out of our revision control software the TOC for the project and any topic files that need to link to those imported files and create my links to them in the "Imported' folder. And then I build my target(s).

This could still be a problem when you re-import. It might make duplicates again in the "Imported" folder. I am avoiding this by NOT checking into our revision control software any of the imported files and imported resource files. I only check in the Flare import file (*.flimphtml), and of course the master TOC and topic files that I updated to the correct links).

When I later need to rebuild my targets, I have found that I MUST checkout the Flare import file (*.flimphtml) so that its writable. Based on #16 in the above procedure the re-import happens automatically, and if any of those imported files have been updated, the updated versions are generated for the target. We do not check back in (submit) the Flare import file (*.flimphtml) into our revision control software! This update has gotten pretty long, so see my next comment on why we don't check it back in.

Not sure if this process will work for you. If not, I hope it at least gives you some more ideas to play around with.

[barbs]

Alright, continuation of our story for dealing with importing files....

As I noted, we do not check back in (submit) the Flare import file (*.flimphtml) into our revision control software after we have built our target(s). After the build is complete, we revert the file. We only check it in after the initial creation of the import file (and only after making some edits noted below). This is because of the way Flare re-writes the file each time you import, using the absolute path of the computer on which you are building the target. This is a nightmare if you have multiple authors that might be working in the project and building the target. If I created the import file and checked it in, and then my coworker checks it out and tries to build the target, the import will FAIL.

There are several discussions on this forum about this that discuss drive mapping to avoid this issue. See viewtopic.php?f=5&t=18405&p=96733&hilit=absolute#p96710. But I wasn't sure how to set this up with our revision control software. In discussing this with my manager, she suggested that we just hand-edit the Flare import file (*.flimphtml) in Notepad++ to update the absolute paths to relative paths.

Based on the file structure noted in the previous post, this screenshot shows the two places in the import file where we replaced the absolute path generated by Flare with a relative path that will work regardless of who, or on what computer, the target is built. The Import file must still be checked out to build the target, but again, we revert the file when done with the build.

ImportFile.jpg

[ChoccieMuffin]

Very quick reply (I'm skiving and having a five-minute break in the forums).

Do you import your master project into EVERYTHING? (I ask, because this is what I do, so I only have one stylesheet to manage, and I import my Globals project into everything else).

If yes, then the solution is pretty straightforward - delete all the files that exist in your Globals project from your target projects. That way, you ONLY get the versions that are imported from the Globals project.

If, on the other hand, you WANT to have different versions of a file in different projects and the file exists in the Globals project, an alternative approach is to apply a condition in the Globals project to all the topics that you definitely DO want to import to all your target projects, and then in the target projects adjust the import file so that in the Import Conditions box you include the condition applied in Globals, and select the Auto-Exclude Non-Tagged Files check box.

Finally, before checking in your import files, edit them in a text editor to remove any stuff that Flare has added (Generated Files, Excluded files, date of last import - that kind of thing) and check the "clean" file in.


Don't know if that's of any use - haven't been able to read and digest the whole thread in detail. But it might stop the problems you're experiencing.

Happy weekend, everyone!

[barbs]

I'm not usually that fast! I'm just hitting the forums pretty hard as I try and figure out some more issues this week and noticed that one of my questions I'd pretty much given up on had been commented on.

No, we don't currently have a "Master" project for styles, conditional tag sets, variables, etc. That's another thing I'm looking into, because we have too many projects and keeping them all in sync is getting hard.

We have one big project that covers our "main" product. And then we have 9 or 10 sub-projects that are merged into that one (not imported). They are companion applications to our main product. So, like this:

• Main Product (companion products merge into this one)
  • Companion Product #1
    Companion Product #2
    Companion Product #3
    Companion Product #4 (imports 7 topics from Companion Product #5)
    Companion Product #5
    Companion Product #6
    etc.

Currently each project has all its own Stylesheets, Conditional Tag Sets, Variable sets, targets, etc. They are (should be) identical, but right now keeping them so is manual, so there's a lot of room for error. Hopefully this month I'll be tackling creating a "Master" project for all of those things and updating all of the projects to import from it. I have to admit, I'm feeling a little intimidated by the task.

[ChoccieMuffin]

Currently each project has all its own Stylesheets, Conditional Tag Sets, Variable sets, targets, etc. They are (should be) identical, but right now keeping them so is manual, so there's a lot of room for error. Hopefully this month I'll be tackling creating a "Master" project for all of those things and updating all of the projects to import from it. I have to admit, I'm feeling a little intimidated by the task.

You will be SO glad when you do it, it saves hours of pulling your hair out!

I suggest that when you have created a Globals project to contain common stuff, you remove those items from each of the target projects, so the ONLY copy of, say, your stylesheet is in version control in the Globals project. Same for other common content. That does mean that when you check out a target project you HAVE to run the globals import file so you can carry on working, but that just gets to be automatic once you've done it.

To create a Globals project you could either start with a clean, blank Flare project and add the things you want, or start with your massive project, rename it and delete stuff that you don't want. Before you do the next bit, make a backup of your massive project in case you get in a tizz. Then in your massive project create a Flare import file .flimpfl for the Globals project and remove everything that is now in your Globals project from version control. Run the import and check that you now have what you were expecting.

For your other target projects, make a backup and delete the stuff that's in the Globals project, create a Globals.flimpfl and do the same.

Fingers crossed!

[MattyQ]

6. Click Import and select HTML File Set.
7. In the Import HTML Files Wizard, on the Import HTML Files page, select Import into this project.

Hi, barbs,

I'm currently following your steps to reproduce, and I'll follow up again once I've finished, but I had a quick question (I don't think you've answered it in the above posts): Is there a reason you folks are using the HTML File Set import to pull files from another Flare project, rather than using the Flare Project import (which is, I think, a more traditional way to import files from one project to another)?

[MattyQ]

The problem is that 2 of the imported images already exist in ProjectB. Each time I re-import, these images are imported with an incremental file name. For instance, information.png imports as information1.png. And the imported source file that references information.png automatically updates to link to information1.png. This wouldn't be a big problem if it ended right there. But if I turn around and import again, I get information2.png, and so on and so on.

Okay, so, after going through the steps exactly as you describe, I believe a couple of things are at play here:

I tested the "reimport" in two ways -- by building the project (at which point, the files are automatically reimported). I also reimported manually, which is to say, in Flare I navigated to the Project Organizer pane, expanded the Imports folder, double-clicked on my import file to open it up, and, in the upper-left corner, clicked Reimport.... At neither point were files duplicated, just replaced as I would expect.

Out of curiosity, when you say "re-import," have you been repeating the procedure you outlined each time?

The only time I was able to get duplicate files, which I expected, was when I repeatedly created a new HTML import (that is to say, repeated the procedure you gave to "re-import" the files). If that's the case, that's why you're seeing duplicates appear -- Flare is duplicating the image files that are controlled by an existing import file (however many number of times you've attempted to reimport in that method).

Let us know if you reimport in a different manner -- it would be interesting to retest, as I was unable to replicate the problem using the standard Flare methods of reimporting.

If you haven't tried it, also, a Flare Project import might make your lives easier, though I can appreciate sticking with the HTML import if only so you can control what folder the imported files are sent to. The condition-based import that Choccie mentions is only available via the Flare Project import.

[barbs]

Fingers crossed!

Thanks!
Barb

[barbs]

6. Click Import and select HTML File Set.
7. In the Import HTML Files Wizard, on the Import HTML Files page, select Import into this project.

Hi, barbs,

I'm currently following your steps to reproduce, and I'll follow up again once I've finished, but I had a quick question (I don't think you've answered it in the above posts): Is there a reason you folks are using the HTML File Set import to pull files from another Flare project, rather than using the Flare Project import (which is, I think, a more traditional way to import files from one project to another)?

Hi Matty,

The reason I went this route (HTML File Set import) was because it gave me the option of putting all of my import files into a separate folder. I didn't see this option using the Flare Project Importer. Having all of the "import" topics and resources in a separate folder completely resolved the issue of extra files being created. For example, when I was importing into the standard "Content" and "Images" folders, if plus.gif already existed AND it was being imported because it was a linked resource file to one of the imported topics, it would import as plus1.gif, and all of the links to that image in the imported topic would update to reference the new image file plus1.gif.

Honestly we could have probably gotten away with this if I'd thought out the whole idea of adding the imported topics and resource files into our revision software. This created a problem because then I had plus.gif and plus1.gif, and if I built our project again, I would then have plus2.gif. In my re-do of our import process, I no longer check any of those imported files into our revision software...there's no reason to. They are saved to the revision software in their "base" project. Within the project they are imported into, they only need to update on the fly when we build, and then they are in the output.

I've got to say, though, I really like having all of the imported topics/resources in their own folder. It makes it really easy to see what is imported.

Also, in my original message, when I say "re-import", I mean when that automatically happens when I build my project.

Hope that helps you understand where I was coming from. Definitely keep the suggestions coming if you see anything that you think would improve the process. Seems like I learn something new every time I look at it again!

Thanks for joining my little ray of import fun!
Barb

[MattyQ]

Hi, Barb,

Thanks for answering my questions and addressing my assumptions!

It is fascinating behavior -- I've been using various imports for a couple years now and only encountered that issue when there were multiple import files in play. This will be a good one to try to replicate to make sure we don't end up in the same place ourselves in the future! Thanks for the detailed explanation of all the moving parts.

[BobMerrill]

So I've been looking at this because one of my clients is in the process of standardizing the documentation appearance of many products after a number o acquisitions.
As a result, we have a template that is being developed in a project that contains style sheets, page layouts, variable sets, and other resources we need to make everyone look like they are part of the same company. We are trying to find the best way to maintain a set of global files that everyone can use, but be able to apply project-unique content within those global files.

I've looked at doing this in two ways:
- Using an external resource and mapping the files in that resource to the project.
- Using the import feature
What I discovered is this:
- If you use an external resource and map, you can use source and destination paths to whole folders and take anything in the folder. It doesn't appear you can exclude files. The place this information is stored is in the project file itself (.flprj).
- If you use the import feature, you can import whatever you want, and have it re-import before it builds. You can also exclude files. This info is in a .flimpfl file in the Imports folder and looks like this:

Code: Select all

    <Synchronize>
        <Mapping ProjectPath="Project/Skins/" ExternalPath="file:///[absolutepath]Project/Skins/" />
        <Mapping ProjectPath="Project/ConditionTagSets/" ExternalPath="file:///[absolutepath]/Project/ConditionTagSets/" />
        <Mapping ProjectPath="Project/VariableSets/" ExternalPath="file:///[absolutepath]/Project/VariableSets/" />
        <etc... />
    </Synchronize>

I personally prefer the mechanism presented by the external resource mapping. It is cleaner in that it doesn't import absolute files, it grabs everything in a folder. If there were a way to exclude files automatically using this method, I would do it.
The other method (import project) does allow exclusion of files. I did a test where I defined one, and found that the excluded file definitions are in an attribute of the CatapultProject element named ExcludePattern like so:

Code: Select all

  ExcludePattern="LocalVariables.flvar"

This seems different from the other techniques described. I guess we'll end up using the Import method, unless MadCap somehow comes up with a way to exclude files using the External Resource Mapping method. And by then it will probably be too late - this is a pretty big infrastructure change, and once we implement it in one method I doubt we're going to change it.

[NorthEast]

We have a 'global project' with material we use in all projects - stylesheets, master pages, page layouts, images, etc.

In the global project, any files that will be re-used in our projects are marked with a condition.

In our projects, we set up a project import, and set it up to import all files from the global project that include that condition.

The global project is in source control and is mapped to a folder on the network. This means that the path in each project import file is always to the same fixed location.
If you wanted to have the global project on a local drive, I'd suggest that you set up a drive mapping to a folder with your Flare projects, and set up the import path from the mapped drive. This means everyone can have the same drive/folder structure; e.g. instead of c:\users\bob\Flare projects\ you can import from P:\Flare projects\ , where Bob maps his P: drive to c:\users\bob\.