nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

area compare / filelist in OD 6

Johnny

I'm not too sure on this one, haven't been able to find anything myself...

In previous versions of OD 5.x, if we specified a filelist deployment with no file passed

EG filelist=""

it would default to an area comparison.

So far I've had no such luck with the newer config type.


     <source >
          <fileSystem >
              <filelist area="$area^" filePath="$content_filelist^" >
                  <pathSpecification >
                      <path name="." />
        <filters>
         <includePath subPath="documents" />
         <includePath subPath="fragments" />
        </filters>
                  </pathSpecification>
              </filelist>
          </fileSystem>
      </source>

running the command


iwodcmd start profile -k "content_filelist=" 
or
iwodcmd start profile -k content_filelist=""

gives me this error


CFG 05019: 2005-03-23 10:32:00 EST GMT-05:00 ***ERROR - "filePath" attribute is missing or empty.
CFG 05020: 2005-03-23 10:32:00 EST GMT-05:00 ***ERROR - No set information (Source iwstore cfg)

Was this ever supposed to work?.. perhaps I'm dreaming but I thought it worked in 5.x
(Looking at the DTD, I see no filelist options for the remoteDiff element)

John Cuiuli

Find more posts tagged with

Comments

Adam Stoller

I don't think that worked (or it shouldn't have) in 5.x
A filelist deployment requires a filelist
A comparison (remoteDiff) deployment does not

If you need both kinds of deployments - then either create two deployment config files, or one deployment config file with two definitions and a single execDeploymentTask that takes a command line parameter to determine which deployment it's running (though I think you'll get a warning somewhere if you run the remoteDiff definition and haven't supplied a value for the filelist parameter in the filelist definition - even though it isn't being used for that run)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Johnny

Thanks for the suggestion.

Though I'm definitely sure I used it on 5.6

It was based on looking at this post many moons ago linl
There probably were some related posts after that.. though I haven't found them.

I could have sworn it was available for use after a SP, patch or something.

John Cuiuli

Adam Stoller

That thread is inconclusive - I made suggestions on what *might* work - but it doesn't look like it was ever verified as to whether it *did* work.
Also - with that DTD the filelist attribute was optional, with the new DTD you are explicitly stating that you are doing a filelist deployment - so it doesn't make any sense to consider it optional.
Again - either create two configs, or two definitions within one config of which only one will be executed based on a command-line parameter.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Johnny

I know it was inconclusive, sorry what I meant was that I tried doing this a while back based on what I read in this thread - and it worked.

Now it appears that it doesn't... my memory is shot - but I doubt it.

John Cuiuli

Johnny

OK I found my own thread

Adam Stoller

The bugfix was for sourceFilesystem
- if you're using the old DTD (which is still supported in 6.x) you can probably still get it to work this way.
- If you're using the new DTD (which you appeared to be doing) then I don't believe it makes sense for the old behavior to occur. By making filelist deployments into a separate directive rather than an attribute of a generate directive it doesn't make sense for the filelist to be optional anymore.

I'm not sure I'd classify it as a bug as long as the 5.5.x DTD is still accepted.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Johnny

I think it's about context/perspective.

The implementation and the function it serves is different.

Yes there are workarounds including using the legacy syntax.

But my question is to specifically find out if this "function" is still supported.

The function being for OpenDeploy to determine to use filelist or area deployment itself.
This function meant that in some use cases the calling logic for this did not need to know what it was passing as OD handled the situation.

I'm sorry, but my question is still the same.

Using a legacy syntax means that it will eventually be unsupported (the syntax).
I haven't come any across anything stating whether A or B is the case, thus I'm looking for clarification.

John Cuiuli

Migrateduser

John,

I looked in the OD 5.6 Reference. The filelist attribute is described as follows:

"specifies the absolute path to the file being accessed in a file list deployment. The presence of this attribute and value indicate the deployment is a file list type. The absence of this attribute indicates the deployment is a directory comparison type."

So, based on that description, it would seem a filelist attribute without a value is inconclusive. Sounds like OD 5.6 was falling back to a directory comparison deployment, as you stated, rather than giving an error for a missing filelist.

That behavior was not carried forward to OD 6, given the changes made to the DTD. Hope that clarifies.

Todd

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Johnny

Thanks for the feedback Todd.

I did read that too, it was part of the reason for clarification.

Reading the bugfix for 5.6, specifically specifies enabling such a feature.

It's that point which made me wonder. It's a feature I relied on quite a bit.

John Cuiuli

Migrateduser

Hmmm, I see now. Seems this wasn't so much a conceived feature as much as an artifact of behavior that turned into a de facto feature.

Since the OD 6 DTD doesn't support this behavior directly, I could file a feature request for future consideration. But I'd like to better understand the use case(s) first. In other words, help me justify having this sort of implicit switch versus just specifying two definitions or deployments and invoking the appropriate one.

Thanks.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Johnny

Well it's good to confirm, thanks.

I have to file for a feature request, for a feature that disapeared? Smiley Happy

I'm not going to push it that far, I just needed to find out what the situation was.

It definitely was a documented "feature", so .. I dunno...

John Cuiuli