Here is my layout:
base CC vob name: vobs/sbftest
UCM vob name: vobs/P_sbftest
Vobadmin created a default "Source" component for my UCM vob that looks like this:
vobs/P_sbftest/Source
Vobadmin also created a project for my UCM vob:
so my project explorer looks like this:
I added files to "Source" component through a remote client window.
Up to here all works find.
However, some of my team members will prefer to work under base CC, so according to this:
What are all the steps to migrate from Base clearcase to UCM?
Base CC views should be able to see my Source component, and the files that it contains, but this is not the case in my situation.
I created a base CC view and it shows other folders created directly in the base CC view, but the view does not see the "Source" component folder created by the UCM view.
Am I missing something?
Shouldn't the base CC view be able to see the "Source" components?
Here are the specs of the base CC view:
element * CHECKEDOUT
element * /main/LATEST
load \sbftest
Any help will be much appreciated.
When you are using UCM, ClearCase will create branches named after your Stream name.
So, you need to add a selection rule which will select the versions added to your Stream:
element * CHECKEDOUT
element * .../sbfuser_testir_proj_dev_strm/LATEST
element * .../am_testir_proj_dev_strm/LASTEST
element * .../testir_proj_int_strm/LASTEST
element * /main/LATEST
load \sbftest
Note the '.../branchname/LATEST' syntax which means: select the LATEST versions of the branch 'branchname', whatever the parent branch is.
I am not sure under which Stream you added your files, so the above config spec will select first the versions of branch 'sbfuser_testir_proj_dev_strm'.
If there is no version in that branch, it will default to the LATEST versions in branch 'am_testir_proj_dev_strm'.
If there is no version in that dev branch, it will default to the LATEST of the integration branch.
The OP falconk comments:
I asked around here and it looks like the UCM component was not created with the right options
That would explain the issue, since the only option when creating a component (see cleartool mkcomp) is the -root one: a component is either a "root-based" or "rootless".
If that component has no root, it is a "meta-component" made to aggregate other components.
And no amount of config spec selection rules will allow for "Source" to be seen.
Related
By default, the ASP.NET Core SPA project templates have a section in their .csproj files like so:
<!-- Include the newly-built files in the publish output -->
<ItemGroup>
<DistFiles Include="$(SpaRoot)dist\**; $(SpaRoot)dist-server\**" />
<DistFiles Include="$(SpaRoot)node_modules\**" Condition="'$(BuildServerSideRenderer)' == 'true'" />
<ResolvedFileToPublish Include="#(DistFiles->'%(FullPath)')" Exclude="#(ResolvedFileToPublish)">
<RelativePath>%(DistFiles.Identity)</RelativePath>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</ResolvedFileToPublish>
</ItemGroup>
I'm not finding any good documentation for this on Google, but I think this section might help me with what I want to do. I want to modify it for my own purposes but first I need to fully understand it, so could someone explain to me the following:
Where does SpaRoot get set?
What exactly does ResolvedFileToPublish do?
Where does DistFiles get set?
Where does FullPath get set?
What does the #(DistFiles->'%(FullPath)' "arrow notation" mean?
What does Exclude="#(ResolvedFileToPublish)" do?
What does DistFiles.Identity refer to and where does it get set?
UPDATE: This page gives some documentation on this item but not much:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-2.2#selective-file-inclusion
Where does SpaRoot get set?
SpaRoot is set as a property in the project by the template.
Projects contain a "static" portion; that is root-level PropertyGroup and ItemGroup elements.
Note that properties are like a global key-value dictionary (and whenever an XML node in a PropertyGroup defines a property, it overwrites existing ones with the same name).
Items however are like lists; you can add (<MyItem Include="..."/>), remove (... Remove="...") and even update items (... Update="..." in static portions only, no include/remove inside targets means "update all" which you can only filter with a Condition attribute). Items are like objects, they have an "ID" which is called "Identity" and can have other properties, which are called "metadata". The "Identity" is the part that is specified in Include, which may or may not be a file name. If a file is referenced, some well-known metadata is added automatically (such as file modification dates and FullPath). Metadata can also be defined on item XML elements as either attributes (e.g. as seen in Version="1.2.3" on PackageReference items) or as child elements of the item element (e.g. RelativePath as seen above).
What exactly does ResolvedFileToPublish do?
The build is executed in the build engine by running targets that contain logic. All of the build logic that .NET projects run are controlled from MSBuild code that uses the same syntax as the project file. So by using imports or SDKs, the .csproj file itself is a build definition rather than a configuration file. Using mechanisms like BeforeTargets/AfterTargets, one can hook into the build process at specific points to execute code; in this case, the template contains a target that hooks into the publish logic.
ResolvedFileToPublish itself doesn't do anything special. The XML elements tell msbuild to add items to the ResolvedFileToPublish list based on file specifications, one of them only if the project is configured with server-side rendering (which is a property that AFAIK is also present in the static portion of the project in the template).
At a later stage during the build, targets coming from the .NET SDK use these items to compute files to copy during publish operations, tool packaging, and/or single-file publishing (3.0 feature), see Microsoft.NET.Publish.targets for the code that uses #(Microsoft.NET.Publish.targets) to access the list of items.
It is a convention that whenever properties or items are used by Microsoft-/3rd-party build logic that do not start with underscores (_), those are allowed/expected to be configured via build customizations, such as provided in the SPA templates. So we are meant to add ResolvedFileToPublish items which are considered "public API", but not _ResolvedFileToPublishAlways. By adding the built SPA files as items, we can tell the publish logic to include them during publish.
Where does DistFiles get set?
DistFiles is created by this template / logic itself. There is next to no restriction on which item or property names can be used. This could also have been named SpaDistFiles or similar. The template creates some intermediate items it can later use to create ResolvedFileToPublish items and hopes that the name doesn't conflict with any other name used in build logic.
Where does FullPath get set?
Full path is an automatic well-known property that msbuild adds to items that reference files on disk.
While an item's identity could be ClientApp\dist\myapp\index.html (or relative paths containing ..\), its FullPath metadata will be C:\path\to\proj\ClientApp\.....
What does the #(DistFiles->'%(FullPath)' "arrow notation" mean?
While properties can be accessed using the $() syntax, items are referenced using #().
When you have item MyItem with identities A and B, #(MyItem) (when evaluated to text) would be A;B. This could again be interpreted as an item specification, so passed to <OtherItem Include="#(MyItem)" />.
But the #() syntax also allows for item transformations or calling item functions (#(MyItem->Count())). Transformation is a projection of each item to another item, so in this example, #(MyItem->'X') would result in X;X since both items are transformed to the same value. To include parts of the original item, metadata values can be accessed via %(). So #(MyItem->'Hello %(Identity)') would result in Hello A;Hello B, since Identity is default metadata.
In this case, the DistFiles items which contain the path relative to the project file are transformed to reference the full path. While this is not well documented, this is needed since publishing logic expects ResolvedFileToPublish items to contain an absolute/full path since it can also be flown across project references - e.g. a library could contain publish-only assets and the consuming project needs to copy them during publish so it needs to pass the full path and not the relative path, which would not be found in the consuming project.
What does Exclude="#(ResolvedFileToPublish)" do?
An item Include="..." can be filtered to not add items that are part of the Exclude definition.
In this case, the action translates to "Add the full path of DistFiles items as ResolvedFileToPublish items unless there is already an ResolvedFileToPublish item with the same identity (i.e. referring to the same file on disk)".
This is useful so as to not confuse the publish logic with duplicate items. Not sure at the moment if this would actually cause problems, but in order to be a good citizen, it is better not to cause additional file copies / file uploads (web deploy) etc.
The reason the files could already be in there is that they may have already been included by one of the default item specifications defined in the Web SDK that includes e.g. files in wwwroot or similar for publishing, depending on how your project is set up. The template just doesn't want to cause conflicts.
What does DistFiles.Identity refer to and where does it get set?
As mentioned above, items have some default metadata and Identity is one of them. In this case, the DistFiles items are created from file specifications relative to the project, so the item's identities are the project-relative paths (ClientApp\dist\...).
Since ResolvedFileToPublish items contain absolute paths, the RelativePath metadata tells the publish logic where to place the file during publish. You could also use this to rename the files or place them in subfolders.
In a verbose log / structured log, you should see that the items being added are C:\path\to\proj\ClientApp\dist\index.html with RelativePath=ClientApp\dist\index.html and CopyToPublishDirectory=PreserveNewest metadata.
Item batching
In the above code, there is a reference to metadata from within an attribute:
<RelativePath>%(DistFiles.Identity)</RelativePath>
While this tells MSBuild to set the RelativePath metadata to the source DistFiles item's Identity, this also triggers a feature called batching.
For every loose %(Item.Metadata) specification MSBuild sees (note that this only works inside targets) MSBuild groups the referenced item(s) into "batches" having the same property. It then runs the task that this is used in (in our case an intrinsic item add task) once for each batch, in which the #() notation will only yield the items from that particular batch.
When only batching on %(XYZ.Identity), this doesn't really matter and can be seen as a simple "for all".
So to be exact, the <ResolvedFileToPublish Include=... part would translate to: "For each set of DistFiles with the same Identity metadata, transform these items to their full path and, unless a ResolvedFileToPublish with this file name already exists, create a ResolvedFileToPublish item for them with the metadata RelativePath set to the DistFile item's Identity value, and the CopyToPublishDirectory metadata set to PreserveNewest."
When i want to create the onGet event code for a calculated attribute the proposed destination folder is "methods" where it should be "model" as described in the on-line documentation;
Strange enough, both files "<..>.events.js" and "<..>.methods.js" already exist under the model/<..> folders (where <..> stands for each datastore class in my model) but seem to be ignored by Wakanda Studio.
I did not find where i could change that destination.
Is it possible and where?
<..>-events.js and <..>-methods.js are recognized by model only when they are included in model.js, which can be found next to model.
Do you see code like this in model.js?
include("./methods/<..>/<..>-events.js");
include("./methods/<..>/<..>-methods.js");
In my current extension template i need to include template from another extension.
If i write
{include uri="design:article/full.tpl"}
it will search in my current extension. How can i direct it to other extension? According to doc there is a name parameter. What should be value of name?
https://doc.ez.no/eZ-Publish/Technical-manual/3.8/Reference/Template-functions/Miscellaneous/include
The design part of the design:article/full.tpl is already supposed to do what you want. It will search a article/full.tpl template, starting from a templates folder within your design folder extension/myextension/design.
eZ Publish will use the following rules to find the good template :
First : determinate which designs are used for the siteaccess. See the [DesignSettings] block in your site.ini files
[DesignSettings]
SiteDesign=a_design_specific_or_not_to_your_siteaccess
AdditionalSiteDesignList[]=another_generic_design
AdditionalSiteDesignList[]=standard
AdditionalSiteDesignList[]=base
Then : determinate which extensions are offering a design. See the [ExtensionSettings] block in each extension's design.ini file (exemple of the extension/ezflow/settings/design.ini.append.php) :
[ExtensionSettings]
DesignExtensions[]=ezflow
Finally, eZ Publish looks for the template. The SiteDesign design will be tried first, and then all the AdditionalSiteDesignList designs from top to bottom. Once the template is found, the lookup stops, and this information is cached (even if your TemplaceCache / TemplateCompile / ... is disabled). Remember the cache part, every time you add a new template, meant to be overriding another one, you need to clear the cache.
So if we have only 2 extensions offering a design, say ezflow and mysite, eZ Publish will try the following paths :
extension/mysite/design/a_design_specific_or_not_to_your_siteaccess/templates/full/article.tpl
extension/mysite/design/another_generic_design/templates/full/article.tpl
extension/mysite/design/standard/templates/full/article.tpl
extension/mysite/design/base/templates/full/article.tpl
extension/ezflow/design/a_design_specific_or_not_to_your_siteaccess/templates/full/article.tpl
extension/ezflow/design/another_generic_design/templates/full/article.tpl
extension/ezflow/design/standard/templates/full/article.tpl
extension/ezflow/design/base/templates/full/article.tpl
design/a_design_specific_or_not_to_your_siteaccess/templates/full/article.tpl
design/another_generic_design/templates/full/article.tpl
design/standard/templates/full/article.tpl
design/base/templates/full/article.tpl
Note that I made the hypothesis that the mysite extension has a higher priority than ezflow. See in settings/override/site.ini.append.php :
[ExtensionSettings]
ActiveExtensions[]
ActiveExtensions[]=mysite
....
ActiveExtensions[]=ezflow
....
This is for the system templates. The process is a little different when it comes to content templates (the ones which are used by attribute_view_gui and node_view_gui functions), see https://doc.ez.no/eZ-Publish/Technical-manual/4.x/Templates/The-template-override-system
fellows!
I have a problem with report generation from my model using a Master Document defining a complex documentation. I believe some of you can help me solve the problem.
Facts:
I have a complex project consisting of several views and packages, inluding domain model, use case model, business process model, etc.
The model is stored in shared (database) repository along with other projects.
I have created custom templates, TOC, cover page and stylesheets for the documentation.
I have created a Master Document package with the main template assigned defining the main document I want to have generated.
I have created several Model Document elements in that package to define individual chapters of the document, assigning adequate templates and model packages to each of them.
I have successfully generated the desired documentation.
I am using Enterprise Architect version 11.0.1107
Problem 1:
I would like to have generated several variants of the same documentation. Thus, I need to change the settings of the generation process like the options, exclude filters and element filters.
However, the settings is not remembered after the generation and I have to set all the settings again when generating documentation on the Master Document package.
Is there a way to save the settings for the Master Document? I have found the Report Specification element, but it does not work as expected (see Problem 2).
Problem 2:
I have tried to use Report Specification element to save the settings for the report generation. I have created that element in the same package as the Master Document is located, and also inside of that Master Document package.
In both cases, when generating the documentation for the first time, EA asked me to select the package. I selected the Master Document package and confirmed the generation. However, the generated document is empty as it clearly does not take the Model Document elements in the selected package into account.
Did I use the Report Specification incorectly? Should I use another package for the Report Specification element? Should I select another package when using the Report Specification for report generation?
Problem 3:
I tried to apply element filters and some other options to include only some of the elements in the report. Let's say I want only element with the version 1.1. So I set the filters to "version = 1.1" when generating the report from the Master Document package.
However, the report contained all elements, regardless their version. The same happened when I tried to exclude anonymous elements. Furthermore, for the next try the filter settings was lost again and I had to set it again before next generation (see Problem 1).
Where should I configure the filters? Should it be set when generating using the Master Document package? Should it be set somewhere for the Model Document elements? Should it be set in the templates (thus making them very specific rather than general)? In such case, should it be set for the model template or for the individual fragments?
Summary:
If you have any tips for combination of Master Document and Report Specification, as well as using the element filters when generating from the Master Document, I would be very grateful.
We do'nt use Report Specification element, but we store specific options into Resource Document. Use [Resource Document] button on Generate Documentation dialog. This specification is stored between Resources (see Resources Window) under Document Generation -> Defined Documents.I hope this solves problem 1 and 2
Problem 3 - EA has more ways, how select elements for generation, unfortunatelly you can't combine them (as far as I know). I would try to define custom find filter and use it.
Currently I am facing the following problem:
A website, which I have to make for a company, has different locations. But the content of a few pages is for all locations the same. Now I have created a global folder with the items for all the locations. But now I am facing the following problem: when accessing the global items from the website of a specific location I get the global url. But what I want is that the specific location url remains the same structure, for example:
Now it is www.url.com/global/subfolder/itemname
And what I want is www.url.com/location1/subfolder/itemname
Does anybody have any solution(s)/suggestion(s) for this problem?
Does anybody also have a solution for creating a menu to insert these global items but also to insert the location specific items?
Some more information about my Sitecore content structure
Global: contains the global items for alle locations
Corporate: the corporate website of the company
Location1: the website of location1
Location2: the website of location2
Adam Weber was right, cloning is your best solution:
Create your Global section, with all the child items you need
For each of your local sections, clone the global section and place it where you'd like it to appear within your local menu
If I understand you correctly, this is what I'd do. It might not be the prettiest solution. But it'll work.
You have your "data" items in /global/subfolder/itemname
then just create some templates, which are "dummy" pages, that only contain a link to the global item (and perhaps the few fields that could differ (perhaps contact email for the specifik location).
Then you make a sublayout that bascially jsut gets the referenced item and uses that instead of Sitecore.Context.Item.
Then create an instance of the "dummy" template in /location1/subfolder/itemname and reference it to /global/subfolder/itemname
That way you URLs will be correct and the data will be the same.
Another and probably smarter solution (if you have enabled proxies) is to create a proxy that takes
/global/subfolder/itemname as source and points to /location1/subfolder/ as target (or you could take /global/subfolder and check "include children".
Here is a Guide on how to use proxies in 5.3:
http://sdn.sitecore.net/Articles/Administration/Using%20Proxy%20Items%20in%205,-d-,3.aspx