I noticed that whenever my Release/Snapshot Maven repository in nexus is updated i.e a build package is added, the group maven repository updates too. Is this a default behavior? Can this be changed?
Group repositories are really just pointers to include all the member components. They do not contain any components of their own. Their real value is 1) to setup one place to pull from rather than multiple and 2) to set an ordering in event of conflict (if you try and pull foo.jar and 2 repositories contain it, it'll take from the first group member containing it).
What you've described is default behavior and cannot be changed except to remove a the repository from the group which would defeat the above stated purposes.
I am not sure which repository version you are on but you can read more about groups here. The behavior/concept has not changed fundamentally since NXRM2.
Related
In .net core microservices, another team works on open source modules, and I extend their modules in my project. I already added one column in a Entity and then same column is added by open source team. Now duplicate column error is showing.
I can not alter open source migration files and my column is already in production.
How to resolve this issue please suggest.
i think we are dealing with multiple smells here.
each microservice should have its own Datarealm
by the sound of it you extended a Table of an object which was generated by the opensource service
But this does not help you, the question is can you merge the Data which is in this column.
If so you might get away with a simple copy/update.
What you need todo is:
Create a new Column With a different Name
Copy your existing Data into the new column
Drop your column
Execute your Migration
Copy your Data back into the column
Test your application very carefully, if the logic which you have implemented for the from you generated Data works as intended
Drop your backup column
Depending on the amount of Data this will lead to a downtime, so plan ahead and have a rollback strategy ready if something goes wrong.
Personal Opinion to Prevent those Smells
Every time i needed an opensource project in my projects in the past i wrote a wrapper around it, this has multiple benefits.
For one if the api of the project changes you only have to update it in exactly one place, which improves the maintainability.
Because it has a wrapper it automatically gets a own Database and if i need to extend an entity which i get from one of those opensource projects, i usually do it via Foreign Keys with a different Table. Which then gets linked via a view.
Yes this costs some performance, but in the end it was worth it every time.
I'm trying to obtain a dependency graph (either as an image or in text-form) from a bazel cquery. According to the documentation, the option --output=graph is currently only supported by bazel query, but not by cquery. Unfortunately, in our project it's not possible to use query since it fetches some external dependencies with restricted access. Only using a config (with cquery) prevents fetching these restricted dependencies.
Is there a work-around to somehow get a graph-like structure from cquery? The default output is just a flattened list which seems to contain no information on the inter-dependencies between the targets.
If the inter-dependencies can somehow be printed, I guess it would be quite easy to reconstruct an image from it.
The following works: Using query instead of cquery and appending the flag --keep_going to ignore errors caused by external dependencies that cannot be fetched by everybody. Then --output=graph can be used.
Note: The result might be different from a configured cquery, but for our purposes, it doesn't matter much.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
Relatively simple question:
If I have already created items to an existing schema and that changes for an upgrade how do I automate data migration?
That is, if my content model changes between revision 1.10 of my product and 1.11, how do I migrate the data while avoiding the "model is not compatiable" type of errors? For the purposes of this question, the alfresco version can be assumed to not have changed. However, resetting the Solr index and needing to re-index can be assumed to be needed!
thanks#
Make sure to execute the steps in the proper order. It is your responsibility and Alfresco does not offer much support here. For the sake of an example, let's assume you are removing a mandatory property. I would do something like this:
Upgrade the model and make the property optional
Remove the value from all content instances
Upgrade the model with the property removed
This example should work without an index rebuild. Other changes, such as when you change how a property is indexed require an index update. If in doubt, rebuild the index.
We have a CRM 2011 managed solution that includes some changes to a standard entity (account) - i.e. new form and some extra fields. In most cases, we can install without a problem as the changes are merged. However we have encountered some instances where a client has renamed the Account entity to something else (Company) as an unmanaged chage (including view names) and our solution changes the entity name and view changes back to 'Account' when installed, based on the 'last one wins' rule.
My question is, is it possible to protect un-managed changes, so that we do not overwrite un-merged changes? i.e. similar to Managed Properties?
Any suggestions would be most appreciated.
Unfortunately, I don't think this is possible although maybe I don't fully understand what you are aiming to do. When you export a solution it will save a snapshot of all the included components. When you reimport, it should set all of the included components as they were when you exported them. If you exported the account entity with a customized name, what sort of logic would you want in place to disallow that change to be imported?
If anyone else has a solution to this, I'd be glad to see it but I haven't come across one yet.