2024:Project Migration Plan - Revision history

Dgreenwood at 17:29, 3 March 2025

2025-03-03T17:29:18Z

← Older revision		Revision as of 12:29, 3 March 2025
Line 1:		Line 1:
	'''''WHO IS THIS ARTICLE FOR?'''''		{{AutoVersion}}

			'''''WHO IS THIS ARTICLE FOR?'''''

	This article is intended for users who are:		This article is intended for users who are:

Dgreenwood: Dgreenwood moved page Project Migration Plan to 2024:Project Migration Plan

2025-03-03T17:28:43Z

Dgreenwood moved page Project Migration Plan to 2024:Project Migration Plan

← Older revision	Revision as of 12:28, 3 March 2025
(No difference)

Dgreenwood at 14:34, 26 February 2025

2025-02-26T14:34:23Z

← Older revision		Revision as of 09:34, 26 February 2025
Line 2:		Line 2:

	This article is intended for users who are:		This article is intended for users who are:
	# Upgrading to version ~~2024~~		# Upgrading to version 2023 or newer
	# Coming from version 2021 or ''older''		# Coming from version 2021 or ''older''
	# And, unfamiliar with '''Projects'''		# And, unfamiliar with '''Projects'''

Dgreenwood: Dgreenwood moved page beta:Project Migration Plan to Project Migration Plan without leaving a redirect

2025-02-25T18:00:24Z

Dgreenwood moved page beta:Project Migration Plan to Project Migration Plan without leaving a redirect

← Older revision	Revision as of 13:00, 25 February 2025
(No difference)

Dgreenwood at 15:35, 25 February 2025

2025-02-25T15:35:54Z

← Older revision		Revision as of 10:35, 25 February 2025
Line 21:		Line 21:
	'''FYI'''		'''FYI'''
	\|		\|
	If you have certain Grooper resources that can be used by multiple ~~'''~~Projects~~'''~~ (such as extractors, profile objects, or '''CMIS Connections'''), you can grant multiple ~~'''~~Projects~~'''~~ access to them through ~~'''~~Project~~'''~~ references.		If you have certain Grooper resources that can be used by multiple Projects (such as extractors, profile objects, or '''CMIS Connections'''), you can grant multiple Projects access to them through Project references.

	For more information, visit the [[Project]] article.		For more information, visit the [[Project]] article.

Dgreenwood at 15:35, 25 February 2025

2025-02-25T15:35:26Z

Dgreenwood: /* Project Migration Plan */

2025-02-25T15:27:45Z

Project Migration Plan

← Older revision		Revision as of 10:27, 25 February 2025
Line 99:		Line 99:
	[[File:Asset 22@4x.png]]		[[File:Asset 22@4x.png]]
	\|		\|
	You may download and import the files below into your own Grooper environment (version ~~2023~~).		You may download and import the files below into your own Grooper environment (version 2024).

	* [[File:2024 Wiki Project-Upgrading-to-2024-BEFORE Project.zip]]		* [[File:2024 Wiki Project-Upgrading-to-2024-BEFORE Project.zip]]

Dgreenwood: /* 7. Rename Project 1 */

2025-02-25T15:27:28Z

7. Rename Project 1

← Older revision		Revision as of 10:27, 25 February 2025
Line 479:		Line 479:
	\|}		\|}

	==== 7. Rename Project 1 ====		=== 7. Rename Project 1 ===

	{\|class="how-to-table"		{\|class="how-to-table"

Dgreenwood: /* Project Migration Plan */

2025-02-25T15:27:11Z

Project Migration Plan

← Older revision		Revision as of 10:27, 25 February 2025
Line 101:		Line 101:
	You may download and import the files below into your own Grooper environment (version 2023).		You may download and import the files below into your own Grooper environment (version 2023).

	* [[File:~~2023~~ Wiki Project-Upgrading-to-~~2023~~-BEFORE Project.zip]]		* [[File:2024 Wiki Project-Upgrading-to-2024-BEFORE Project.zip]]
	** Import this ZIP for an example of what "Project 1" looks like in a newly upgraded Grooper Repository.		** Import this ZIP for an example of what "Project 1" looks like in a newly upgraded Grooper Repository.

	* [[File:~~2023~~ Wiki Project-Upgrading-to-~~2023~~-AFTER Projects.zip]]		* [[File:2024 Wiki Project-Upgrading-to-2024-AFTER Projects.zip]]
	** Import this ZIP for an example of what these resources look like ''after'' we organize resources into '''Projects'''.		** Import this ZIP for an example of what these resources look like ''after'' we organize resources into '''Projects'''.
	\|}		\|}

	~~<tabs style="margin:20px">~~
	~~<tab name="1. Clean House" style="margin:20px">~~
	=== 1. Clean House ===		=== 1. Clean House ===

Line 123:		Line 121:
	[[File:2023-Project-Clean-House-01.png]]		[[File:2023-Project-Clean-House-01.png]]
	\|}		\|}
	~~</tab>~~
	~~<tab name="2. Create Project" style="margin:20px">~~
	=== 2. Create Project ===		=== 2. Create Project ===

Line 192:		Line 189:
	\|}		\|}

	~~</tab>~~
	~~<tab name="3. Rename Resources">~~
	=== 3. Rename Resources ===		=== 3. Rename Resources ===

Line 207:		Line 202:
	[[File:2023-Project-Project-Migration-Plan-Rename-Resources-01.png]]		[[File:2023-Project-Project-Migration-Plan-Rename-Resources-01.png]]
	\|}		\|}
	~~</tab>~~
	~~<tab name="4. Analyze References">~~
	=== 4. Analyze References ===		=== 4. Analyze References ===

Line 271:		Line 265:
	Your choice will largely depend on how big your environment is, how many times the resources in "Project 1" are referenced by different potential '''Projects''', and if you prefer to have local copies of these resources that can be edited independently or if you want these resources to be truly shared across different '''Projects''' (meaning changing one single object will impact how multiple '''Projects''' implement it).		Your choice will largely depend on how big your environment is, how many times the resources in "Project 1" are referenced by different potential '''Projects''', and if you prefer to have local copies of these resources that can be edited independently or if you want these resources to be truly shared across different '''Projects''' (meaning changing one single object will impact how multiple '''Projects''' implement it).

	=== Option 1: Copy the Resources ===		==== Option 1: Copy the Resources ====

	The process will be most time consuming if you want to copy these objects over to the '''Project'''. However, doing so does have benefits. Once you copy these shared resources from "Project 1", you will no longer need the reference to "Project 1". At that point the '''Project''' is independent and self contained. If you need to share this '''Project''' with another Grooper environment (say promoting it from a "test" repository to a "development" repository) it will have no dependencies to another '''Project''' that need to be shared along side it.		The process will be most time consuming if you want to copy these objects over to the '''Project'''. However, doing so does have benefits. Once you copy these shared resources from "Project 1", you will no longer need the reference to "Project 1". At that point the '''Project''' is independent and self contained. If you need to share this '''Project''' with another Grooper environment (say promoting it from a "test" repository to a "development" repository) it will have no dependencies to another '''Project''' that need to be shared along side it.
Line 318:		Line 312:
	\|}		\|}

	=== Option 2: Keep Project 1 Shared ===		==== Option 2: Keep Project 1 Shared ====

	{\|class="how-to-table"		{\|class="how-to-table"
Line 334:		Line 328:
	\|}		\|}

	=== Option 3: Option 1 + Option 2 ===		==== Option 3: Option 1 + Option 2 ====

	There's also no reason why you can't copy some items over to your new '''Project''' and keep others referenced through '''Project''' references.		There's also no reason why you can't copy some items over to your new '''Project''' and keep others referenced through '''Project''' references.

	For example, in our first example, we could have copied over the two '''IP Profiles''' but kept the '''CMIS Connection''' as a shared resource. In fact, that would have made more sense. If we have to make changes to a '''CMIS Connection''' (like entering new access permissions), we would only want to do that once by manipulating one single object, rather than reproducing our efforts by editing multiple copies of the same object in multiple '''Projects'''.		For example, in our first example, we could have copied over the two '''IP Profiles''' but kept the '''CMIS Connection''' as a shared resource. In fact, that would have made more sense. If we have to make changes to a '''CMIS Connection''' (like entering new access permissions), we would only want to do that once by manipulating one single object, rather than reproducing our efforts by editing multiple copies of the same object in multiple '''Projects'''.
	~~</tab>~~
	~~<tab name="5. Remove Project References">~~
	=== 5. Remove Project References ===		=== 5. Remove Project References ===

Line 383:		Line 376:
	[[File:2023-Project-Project-Migration-Plan-Remove-Project-References-02.png]]		[[File:2023-Project-Project-Migration-Plan-Remove-Project-References-02.png]]
	\|}		\|}
	~~</tab>~~
	~~<tab name="6. Reorganize Shared Resources">~~
	=== 6. Reorganize Shared Resources ===		=== 6. Reorganize Shared Resources ===

Line 394:		Line 386:
	# Organizing any remaining shared resources into folders and deleting empty folders, as you see fit.		# Organizing any remaining shared resources into folders and deleting empty folders, as you see fit.

	=== Manually Creating Projects ===		==== Manually Creating Projects ====

	There are some situations where you may need to manually create a '''Project''' for certain assets remaining in "Project 1". Most commonly, this can happen if you have resources you've created for testing purposes that are not tied to a '''Batch Process''' and you want to keep them around.		There are some situations where you may need to manually create a '''Project''' for certain assets remaining in "Project 1". Most commonly, this can happen if you have resources you've created for testing purposes that are not tied to a '''Batch Process''' and you want to keep them around.
Line 465:		Line 457:
	\|}		\|}

	=== Clean Up Remaining Folders ===		==== Clean Up Remaining Folders ====

	After you've moved everything out of "Project 1" into a new '''Project''' (whether manually or through the "Create Project" feature), the only resources left should be shared resources, objects intended to be used by any current or future '''Project'''.		After you've moved everything out of "Project 1" into a new '''Project''' (whether manually or through the "Create Project" feature), the only resources left should be shared resources, objects intended to be used by any current or future '''Project'''.
Line 487:		Line 479:
	\|}		\|}

	~~</tab>~~		==== 7. Rename Project 1 ====
	~~<tab name~~=~~"7. Rename Project 1">~~
	=== 7. Rename Project 1 ===

	{\|class="how-to-table"		{\|class="how-to-table"
Line 501:		Line 491:
	[[File:2023-Project-Project-Migration-Plan-Rename-Project-1-01.png]]		[[File:2023-Project-Project-Migration-Plan-Rename-Project-1-01.png]]
	\|}		\|}
	~~</tab>~~
	~~:[[#Using Resources in Other Projects\|Click here to return to the top of the tab]]~~
	~~</tabs>~~

Dgreenwood at 21:33, 17 July 2024

2024-07-17T21:33:29Z

← Older revision		Revision as of 16:33, 17 July 2024
Line 5:		Line 5:
	# Coming from version 2021 or ''older''		# Coming from version 2021 or ''older''
	# And, unfamiliar with "'''Projects'''"		# And, unfamiliar with "'''Projects'''"

	~~{\|class="download-box"~~
	\|
	~~[[File:Asset 22@4x.png]]~~
	\|
	~~You may download and import the files below into your own Grooper environment (version 2023).~~

	* [[File:2023 Wiki Project-Upgrading-to-2023-BEFORE Project.zip]]
	** Import this ZIP for a look into a newly upgraded Grooper Repository ''before'' we organize resources into '''Projects'''.

	* [[File:2023 Wiki Project-Upgrading-to-2023-AFTER Projects.zip]]
	** Import this ZIP for a look into the Grooper Repository ''after'' we organize resources into '''Projects'''.
	\|}


	{{#lst:Glossary\|Project}}		{{#lst:Glossary\|Project}}


	[[File:2023-Project-Projects-and-Upgrading-to-2023-01.png\|right\|600px]]		[[File:2023-Project-Projects-and-Upgrading-to-2023-01.png\|right\|600px]]
Line 41:		Line 26:
	\|}		\|}

	=== What happens when you upgrade? ===		== What happens when you upgrade? ==

	Upon upgrading to a version with '''Projects''', the organization of your Grooper Repository's node tree will change.		Upon upgrading to a version with '''Projects''', the organization of your Grooper Repository's node tree will change.
Line 68:		Line 53:
	* Anything in the "Global Resources" folder will be placed throughout "Project 1".		* Anything in the "Global Resources" folder will be placed throughout "Project 1".

	=== Deciding What to Do Next ===		== Deciding What to Do Next ==

	It's important to point out your Grooper environment will work just fine with everything organized into the single "Project 1" '''Project'''. You can leave everything as is in "Project 1" upon upgrading to version '''2023''' and continue processing '''Batches''' of documents as if nothing happened.		It's important to point out your Grooper environment will work just fine with everything organized into the single "Project 1" '''Project'''. You can leave everything as is in "Project 1" upon upgrading to version '''2023''' and continue processing '''Batches''' of documents as if nothing happened.
Line 96:		Line 81:
	#* If so, '''Projects''' are ''really'' for you. Aside from object organization, the other big reason for creating the '''Project''' architecture was to maintain object reference integrity. '''Projects''' will greatly assist you in preventing reference corruption in your Grooper environments.		#* If so, '''Projects''' are ''really'' for you. Aside from object organization, the other big reason for creating the '''Project''' architecture was to maintain object reference integrity. '''Projects''' will greatly assist you in preventing reference corruption in your Grooper environments.

	=== Project Migration Plan ===		== Project Migration Plan ==

	Ok, you've decided '''Projects''' are for you, and you want to move resources out of "Project 1" to best take advantage of them. What are the next steps forward?		Ok, you've decided '''Projects''' are for you, and you want to move resources out of "Project 1" to best take advantage of them. What are the next steps forward?
Line 109:		Line 94:
	# Reorganize any shared resource objects that remain in "Project 1"		# Reorganize any shared resource objects that remain in "Project 1"
	# Rename "Project 1" to something like "Global Resources" or "Shared Resources"		# Rename "Project 1" to something like "Global Resources" or "Shared Resources"

			{\|class="download-box"
			\|
			[[File:Asset 22@4x.png]]
			\|
			You may download and import the files below into your own Grooper environment (version 2023).

			* [[File:2023 Wiki Project-Upgrading-to-2023-BEFORE Project.zip]]
			** Import this ZIP for an example of what "Project 1" looks like in a newly upgraded Grooper Repository.

			* [[File:2023 Wiki Project-Upgrading-to-2023-AFTER Projects.zip]]
			** Import this ZIP for an example of what these resources look like ''after'' we organize resources into '''Projects'''.
			\|}

	<tabs style="margin:20px">		<tabs style="margin:20px">

← Older revision		Revision as of 10:35, 25 February 2025
Line 4:		Line 4:
	# Upgrading to version 2024		# Upgrading to version 2024
	# Coming from version 2021 or ''older''		# Coming from version 2021 or ''older''
	# And, unfamiliar with "'''Projects'''"		# And, unfamiliar with '''Projects'''

	{{#lst:Glossary\|Project}}		{{#lst:Glossary\|Project}}

	[[File:2023-Project-Projects-and-Upgrading-to-2023-01.png\|right\|600px]]		[[File:2023-Project-Projects-and-Upgrading-to-2023-01.png\|right\|600px]]
	'''Projects''' are a new way of organizing Grooper resources in version ~~'''2023'''~~. Before ~~the introduction of '''~~Projects~~'''~~, ~~these~~ objects were ~~interspersed~~ throughout various locations in the node tree.		'''Projects''' are a new way of organizing Grooper resources first implemented in Grooper version 2022. Before Projects were introduced, node objects were spread throughout various folder locations in the node tree.

	~~'''~~Projects~~'''~~ allow users to organize resources used for a similar purpose (or "project") in a single container.		Projects allow users to organize resources used for a similar purpose (or "project") in a single container.

	The screenshot to the right shows the difference.		The screenshot to the right shows the difference.
	* Before ~~'''~~Projects~~'''~~, similar resources were scattered throughout the node tree.		* Before Projects, similar resources were scattered throughout the node tree.
	* With ~~'''~~Projects~~'''~~, similar resources can be grouped together under a single node.		* With Projects, similar resources can be grouped together under a single node.

	{\|class="fyi-box"		{\|class="fyi-box"
Line 48:		Line 48:
	Find them in the "Projects" node.		Find them in the "Projects" node.

	Most Grooper objects in your repository will be placed into a new ~~'''~~Project~~'''~~ named "Project 1".		Most Grooper objects in your repository will be placed into a new Project named "Project 1".
	* All ~~'''~~Content Models~~'''~~ will be organized into a folder named "Content Models".		* All Content Models will be organized into a folder named "Content Models".
	* All ''working~~'' '~~''Batch Processes~~'''~~ will be placed in a folder named "Processes".		* All ''working'' Batch Processes will be placed in a folder named "Processes".
	* Anything in the "Global Resources" folder will be placed throughout "Project 1".		* Anything in the "Global Resources" folder will be placed throughout "Project 1".

	== Deciding What to Do Next ==		== Deciding What to Do Next ==

	It's important to point out your Grooper environment will work just fine with everything organized into the single "Project 1" ~~'''~~Project~~'''~~. You can leave everything as is in "Project 1" upon upgrading to version ~~'''~~2023~~'''~~ and continue processing ~~'''~~Batches~~'''~~ of documents as if nothing happened.		It's important to point out your Grooper environment will work just fine with everything organized into the single "Project 1" Project. You can leave everything as is in "Project 1" upon upgrading to version 2023 and continue processing Batches of documents as if nothing happened.

	Going forward you have two options:		Going forward you have two options:

	# Do nothing. Leave all Grooper resources organized into "Project 1"		# Do nothing. Leave all Grooper resources organized into "Project 1"
	# Migrate resources into their own ~~'''~~Projects~~'''~~.		# Migrate resources into their own Projects.

	You should consider this an "all or nothing" choice. There are some significant benefits to organizing resources into their own ~~'''~~Projects~~'''~~, but it should not be done haphazardly. You will not see the true benefits of this new architecture if you take a "half in/half out" approach. That said, migrating resources to new ~~'''~~Projects~~'''~~ will take time. There are some utilities that will aid you in this task, but there will necessarily be some manual moving of objects from one node location to another.		You should consider this an "all or nothing" choice. There are some significant benefits to organizing resources into their own Projects, but it should not be done haphazardly. You will not see the true benefits of this new architecture if you take a "half in/half out" approach. That said, migrating resources to new Projects will take time. There are some utilities that will aid you in this task, but there will necessarily be some manual moving of objects from one node location to another.

	So, should you migrate away from "Project 1" at all? Here are some things to keep in mind, when making this decision.		So, should you migrate away from "Project 1" at all? Here are some things to keep in mind, when making this decision.

	# '''It's all or nothing.'''		# '''It's all or nothing.'''
	#* Again, we stress the importance of committing to the move. You should commit to migrating everything to new ~~'''~~Projects~~'''~~ (with the exception of a handful of shared resources), rather than just a few. The benefits of the ~~'''~~Project~~'''~~ architecture will not be realized until you've completed the entire process. Not following this advice increases the likelihood of a time-sensitive call to the help-desk in the future. This call will likely be time-consuming as we attempt to track down the issue through a partially architected system.		#* Again, we stress the importance of committing to the move. You should commit to migrating everything to new Projects (with the exception of a handful of shared resources), rather than just a few. The benefits of the Project architecture will not be realized until you've completed the entire process. Not following this advice increases the likelihood of a time-sensitive call to the help-desk in the future. This call will likely be time-consuming as we attempt to track down the issue through a partially architected system.
	# '''You don't have to move things from "Project 1" at all."		# '''You don't have to move things from "Project 1" at all."'''
	#* If you do not have the time or resources to migrate out of "Project 1", it's best to leave everything in "Project 1". Everything will continue to work as it did previously.		#* If you do not have the time or resources to migrate out of "Project 1", it's best to leave everything in "Project 1". Everything will continue to work as it did previously.
	# '''Do you have time to do it?'''		# '''Do you have time to do it?'''
	#* This is probably the biggest question you need to ask yourself. The migration will take time. The larger the repository is, with many ~~'''~~Content Models~~'''~~, ~~'''~~Batch Processes~~'''~~, profiles and other objects, the longer it's going to take.		#* This is probably the biggest question you need to ask yourself. The migration will take time. The larger the repository is, with many Content Models, Batch Processes, profiles and other objects, the longer it's going to take.
	# '''Do you have a lot of "shared resources"?'''		# '''Do you have a lot of "shared resources"?'''
	#* If you frequently have individual ~~'''~~Data Types~~'''~~, ~~'''~~Lexicons~~'''~~, profiles, ~~'''~~CMIS Connections~~'''~~ or other objects used across many different ~~'''~~Content Models~~'''~~ and ~~'''~~Batch Processes~~'''~~, this will take the highest amount of time and effort to migrate. Ensuring these shared resources are accessible to each ~~'''~~Project~~'''~~ created is the most time consuming part of any migration out of "Project 1".		#* If you frequently have individual Data Types, Lexicons, profiles (ex: OCR Profiles), CMIS Connections or other objects used across many different Content Models and Batch Processes, this will take the highest amount of time and effort to migrate. Ensuring these shared resources are accessible to each Project created is the most time consuming part of any migration out of "Project 1".
	# '''Do you frequently promote objects from a "test" or "dev" Grooper Repository to a "production" Grooper Repository?'''		# '''Do you frequently promote objects from a "test" or "dev" Grooper Repository to a "production" Grooper Repository?'''
	#* If so, ~~'''~~Projects~~'''~~ are for you. The new architecture provides multiple advantages to this kind of workflow. You should seriously consider devoting the time to migrate resources into their own ~~'''~~Projects~~'''~~, if you maintain multiple environments to publish Grooper objects from development to production repositories.		#* If so, Projects are for you. The new architecture provides multiple advantages to this kind of workflow. You should seriously consider devoting the time to migrate resources into their own Projects, if you maintain multiple environments to publish Grooper objects from development to production repositories.
	# '''Do you use third-party data entry companies to review work in Grooper?'''		# '''Do you use third-party data entry companies to review work in Grooper?'''
	#* If so, ~~'''~~Projects~~'''~~ are for you. You'll benefit from being able to push complete and tidy project packages to an environment dedicated to that company.		#* If so, Projects are for you. You'll benefit from being able to push complete and tidy project packages to an environment dedicated to that company.
	# '''Do you have multiple Grooper engineers working in the same Grooper Repository(ies)?'''		# '''Do you have multiple Grooper engineers working in the same Grooper Repository(ies)?'''
	#* If so, ~~'''~~Projects~~'''~~ are ''really'' for you. Aside from object organization, the other big reason for creating the ~~'''~~Project~~'''~~ architecture was to maintain object reference integrity. ~~'''~~Projects~~'''~~ will greatly assist you in preventing reference corruption in your Grooper environments.		#* If so, Projects are ''really'' for you. Aside from object organization, the other big reason for creating the Project architecture was to maintain object reference integrity. Projects will greatly assist you in preventing reference corruption in your Grooper environments.

	== Project Migration Plan ==		== Project Migration Plan ==

	Ok, you've decided ~~'''~~Projects~~'''~~ are for you, and you want to move resources out of "Project 1" to best take advantage of them. What are the next steps forward?		Ok, you've decided Projects are for you, and you want to move resources out of "Project 1" to best take advantage of them. What are the next steps forward?

	We've narrowed the process down to seven general steps:		We've narrowed the process down to seven general steps:

	# Clean up your repository. Delete items that are no longer in use and will not be used in the future.		# Clean up your repository. Delete items that are no longer in use and will not be used in the future.
	# Use the "Create Project" ~~feature~~ for each '''Batch Process'''.		# Use the "Create Project" command for each '''Batch Process'''.
	# As each ~~'''~~Project~~'''~~ is created, rename any objects as needed if your prior naming conventions no longer make sense.		# As each Project is created, rename any objects as needed if your prior naming conventions no longer make sense.
	# For each ~~'''~~Project~~'''~~, use the "Usage" tab to decide what to do about "shared resources" used by multiple ~~'''~~Projects~~'''~~.		# For each Project, use the "Usage" tab to decide what to do about "shared resources" used by multiple Projects.
	# Remove ~~'''~~Project~~'''~~ references if the "Outbound References" list is empty.		# Remove Project references if the "Outbound References" list is empty.
	# Reorganize any shared resource objects that remain in "Project 1"		# Reorganize any shared resource objects that remain in "Project 1"
	# Rename "Project 1" to something like "Global Resources" or "Shared Resources"		# Rename "Project 1" to something like "Global Resources" or "Shared Resources"
Line 105:		Line 105:

	* [[File:2024 Wiki Project-Upgrading-to-2024-AFTER Projects.zip]]		* [[File:2024 Wiki Project-Upgrading-to-2024-AFTER Projects.zip]]
	** Import this ZIP for an example of what these resources look like ''after'' we organize resources into ~~'''~~Projects~~'''~~.		** Import this ZIP for an example of what these resources look like ''after'' we organize resources into Projects.
	\|}		\|}