Can generation not delete output directory contents?

[Colum]

I'm a new Flare user and was wondering if there is a way to stop Flare from deleting the contents of the output folder each time we generate the output? It appears not, and I know other tools operate the same way, but just need confirmation. Usinf Flare 2019 generating Clean HTML if that makes a difference, which I doubt. Many thanks.

[Nita Beck]

No, there is no such option to have Flare not clear the output folder for a given target when you rebuild that target. Doesn’t matter what the target type is, so Clean XHTML has nothing to do with it.

Why do you want not to have builds overwritten? If we understood your reasoning, we might have an alternative to suggest.

Meantime, would using Flare’s Publish functionality serve your purpose?

[Colum]

That's what I figured. Thank you Nita. My use case is as follows...

I have 1100 topics so want to split up these into separate Flare projects. We're publishing to Salesforce, but want a way to see (and test inter project links) before publishing. I had hoped that by setting each project to publish to the same directory would get around this issue. The only way I can see of achieving this is building each project to its own directory, and then copying / pasting all the files into a separate directory manually. Can you think of a better way - hopefully an automatic one?

[NorthEast]

Any reason why you're splitting it into 3 projects?
You could use a single project, and still produce 3 separate outputs, in addition to an output that contains everything.
You'd just use conditions to mark the topics, and then choose in the targets which conditions to exclude/include.

[Colum]

Hi Dave. We're a multi-author team and need to work on separate elements of the deliverable at the same time. By separating out into multiple projects we can do this.

[NorthEast]

Then I'd suggest using source control, so the team can work on a single project.

If you split it into separate projects, then you'd be introducing some quite severe limitations - e.g. you can't have any cross-references between topics in each project.

[Nita Beck]

I wholeheartedly endorse Dave's recommendation to use source control for team authoring. Even for those projects for which I'm the sole author, I still wouldn't think of operating without source control.

[Colum]

Thanks for all the responses so far and yes we will be using source control going forward, but we're not quite there yet. However another reason why I think we'll need multiple projects is the way each destination requires a Salesforce data category. See the "forum.png" attachment. We've one deliverable that includes the documentation for multiple products. The category specified in the destination controls the metadata in Salesforce that is used to filter the results displayed. Whilst you can have multiple categories in Flare, we don't want that. What this all means is having a Flare project for each product, each with one category. If we only had one project and specify multiple categories, the Salesforce metadata would be messed up.

[Nita Beck]

Have you looked at whether using publish destinations will achieve what you're after?

[NorthEast]

Thanks for all the responses so far and yes we will be using source control going forward, but we're not quite there yet. However another reason why I think we'll need multiple projects is the way each destination requires a Salesforce data category. See the "forum.png" attachment. We've one deliverable that includes the documentation for multiple products. The category specified in the destination controls the metadata in Salesforce that is used to filter the results displayed. Whilst you can have multiple categories in Flare, we don't want that. What this all means is having a Flare project for each product, each with one category. If we only had one project and specify multiple categories, the Salesforce metadata would be messed up.

You don't need 3 separate projects to do that though, you just need 3 separate targets in your project.
Each target can have its own destination, and can therefore have different destination properties.

Then for testing purposes, you could have another target that contains all the content from the 3 sections. Use that for whatever local testing you need, without actually publishing that target to Salesforce.