Is there a way to define dependency in Package.swift that would point at a certain branch latest commit, or even to just a specific commit ID (just like it is possible with Carthage)?
Use case would be, let's say I have a library repo where I would like to branch out and make some changes, and then be able to test them out in a dependent project.
As of Swift 4 you can use .branch() and .revision() as described in PackageDescription.md.
It is possible.
Go to project
Click on "Package Dependencies" Tab
Double click on the package you want to change the branch of
Specify the branch/commit.
Not yet, but swiftpm team is working on. Now you must specify a package version when declaring a dependency.
import PackageDescription
let package = Package(
name: "Example",
dependencies: [
.Package(url: "https://github.com/somePackage", "1.0.0")
]
)
In the future it will be possible, there was a discussion to add Version Locking but its not accepted and implemented yet.
For your use case you can fork the repo, do the changes, test them and then add a version tag to your fork. Now it's much more easier to do changes with Editable Packages functionality.
Related
I have an Alfresco module that I would like to have do some cleanup when a new version of it is installed.
In the current situation, an older version of the module created a folder node with custom properties at the root of the repository. We've since decided to have multiple such nodes, and none of them at that location. I'd like to put into the next version of the module code that would run at Alfresco startup, check for the existence of the old node, copy its properties into the appropriate new nodes, and delete the old node.
Is such a thing possible? I've looked at the Bootstrap configuration file, but that appears to only allow one to add things to the repository, not modify or delete them.
My suggestion is that you write a patch. That is a class that implements
org.alfresco.repo.admin.patch.AbstractPatch
Then you can do pretty much anything you want on bootstrap (except executing searches against solr since it wont be available).
Add some spring configuration, take a look at the file patch-services-context.xml for inspiration.
Yes you can do that, probably you missed the correct place in the documentation about that:
If you open Import Strategy you'll find a section Per BootstrapView, you should be using something like REPLACE_EXISTING or UPDATE_EXISTING for your ACP packaged content (if you're using ACPs as your bootstrap importing strategy).
Here is a more detailed description of the UUID Bindings values.
Hope that helps.
You can use patches.
When alfresco server starts it applies patches and executes database updates etc.
Definition :
A patch is a piece of Java code that executes once when Alfresco
Content Services starts. Custom patches can be implemented.
Documentation Link
I would like to get a better idea of conflicting dependencies between artifacts in my organization. For this, I have created a meta-project that includes all the other top-level projects. To identify conflicts of various transitive dependencies, my idea was to use a conflict manager.
I know I can set a conflict manager like this
conflictManager := ConflictManager.strict
How would I set the strict manager only for com.example packages, and possibly compose it with other more specific managers?
Is it possible to create completely custom dependency managers, which would only warn about conflicts?
I am also thankful for other ideas on solving this problem.
You can do it with
conflictManager := ConflictManager.strict.copy(organization = "com.example.*")
You can vary (Ivy) type of conflict manager, organization and module filters. See this sbt source with it's definition. Also see Ivy docs on types of conflict managers
It seems that you can define a custom Ivy conflict manager setting it's name with ConflictManager("...") (see the Ivy docs on what you can to write there). Although I don't see any way to combine several conflict managers: sbt provides only one setting key conflictManager and sets the ivy manager directly from it.
I use an ivysettings.xml file to configure the repositories to use for sbt, which uses Ivy.
However, it's not able to download a particular snapshot which uses unique naming (i.e. date-based naming). It only tries the patterns listed explicitly in my ivysettings.xml file (which makes sense), so it can't see the details in maven-metadata.xml which tell it the filename of the snapshot jar to download.
I tried specifying the version explicitly instead of as a snapshot in Build.scala:
"com.jolbox" % "bonecp" % "0.8.1-20131105.191813-1"
(which would be my ideal solution, because then it would be cached in our maven repository and I'd be guaranteed to always use the same snapshot), but this generated the wrong URL (there should be an 0.8.1-SNAPSHOT in there, but of course there isn't):
http://maven/nexus/content/groups/softwaretools-snapshot-group/com/jolbox/bonecp/0.8.1-20131105.191813-1/bonecp-0.8.1-20131105.191813-1.pom
I then tried specifying the URL explicitly using from, but this didn't work.
I then tried using latest.integration as the version, but that didn't correctly identify the latest version - it thought it was 0.8.0-rc1, which is clearly wrong.
Download the dependency manually and add it to the lib directory of the project (create it if necessary); remove it from the Build.scala file.
I'm using a pretty recent version of SBT (seems to be hard to figure out what the version is). I want to pass system properties to my application with sbt run as follows:
sbt -Dmyprop=x run
How could I do that?
SBT's runner doesn't normally create new processes, so you also have to tell it to do this if you want to set the arguments that are passed. You can add something like this to your build settings:
fork := true
javaOptions := Seq("-Dmx=1024M")
There's more detail on forking processes in the SBT documentation.
I found the best way to be adding this to build.sbt:
// important to use ~= so that any other initializations aren't dropped
// the _ discards the meaningless () value previously assigned to 'initialize'
initialize ~= { _ =>
System.setProperty( "config.file", "debug.conf" )
}
Related: When doing this to change the Typesafe Configuration that gets loaded (my use case), one needs to also manually include the default config. For this, the Typesafe Configuration's suggested include "application" wasn't enough but include classpath("application.conf") worked. Thought to mention since some others may well be wanting to override system properties for precisely the same reason.
Source: discussion on the sbt mailing list
Thanks for the pointer, this actually helped me solve a somewhat related problem with Scala Tests.
It turned out that sbt does fork the tests when there are sub-projects (see my code) and some of the tests fail to pick up the system property.
So in sbt -Dsomething="some value" test, some of the tests would fail when failing to find something in the system properties (that happened to be my DB URI, so it kinda mattered!)
This was driving me nuts, so I thought I'd post it here for future reference for others (as #akauppi correctly noted, chances are high that "others" may well be me in a few weeks!).
The fix was to add the following to build.st:
fork in Test := false
I think the best is to use the JAVA_OPTS environment variable:
#update the java options (maybe to keep previous options)
export JAVA_OPTS="${JAVA_OPTS} -Dmyprop=x"
#now run without any extra option
sbt run
You can pass system properties at the end of the sbt command:
sbt run -Dmyprop=x
If you have to pass program parameters into a stage, just pass system properties after the quotes again:
sbt "runMain com.example.MyClass -p param-value" -Dmyprop=x
I'm developing a product for Plone, say foo.core. Besides that core product, there are also several related products. like foo.optional. These releated products may be available in the instance and if they are available they may be installed (in other words: I cannot assume the code is available or, if it is, should be used).
These related products may override settings made by foo.core (e.g. in a Property Sheet). This works fine, but if I reinstall foo.core, the default settings are back. What I'd want is to somehow automatically reinstall foo.optional when foo.core is reinstalled in the QuickInstaller.
The solutions I could come up with are:
When foo.optional is installed, it
registers itself with foo.core. The
latter, foo.core, will handle the
reinstallation of all registered
products when the core package is
reinstalled.
The foo.core package
triggers an event which other
packages, like foo.optional, can
listen for. An event handler will
then trigger the reinstall of
foo.optional.
Make sure that foo.core
doesn't overwrite any settings that
may have been customized later by
other products.
Perhaps there are more alternatives? What would be the 'Plonish' approach?
Edit: I know that using upgrade steps might be better than reinstalling the product. However IMHO the problem remains the same: the Generic Setup profile used for the upgrade step might have a setting that is modified in the Generic Setup profile for the foo.optional package.
So using upgrade steps makes my problem even harder: how should I determine whether the upgrade step of foo.core means foo.optional should be reinstalled/upgraded? (The assumption is still that foo.core in principle does not know about foo.optional.)
The solution to your problem is much easier than what you propose:
We do NOT reinstall products like we did in the past when the product is updated. Reinstalling a product will cause your generic setup profile to be reapplied which is why you get your settings overwritten.
Instead you now provide upgrade steps. For instance if you change your profile version from 2 to 3 then you would have:
<genericsetup:upgradeStep
title="Upgrade foo.core from revision 2 to 3"
description="Adds stuff"
source="2"
destination="3"
handler="foo.core.upgrades.two_to_three.addStuff"
sortkey="1"
profile="foo.core:default"
/>
Inside the upgrade step you can do what you like, even re-run individual import steps.
If your product upgrade does not involve changing the GS profile, do not increment the version in metadata.xml. In that case you obviously don't need an upgrade step either.
I suspect you are making things much harder on yourself by involving Plone's add-on installation story (which is complicated by "old" and "new" technologies living side by side). I would take a step back and think more about the plugin system you are trying to design/implement, and avoid including Plone until you absolutely have to [1].
You also might consider using entry points to implement at least a portion of the plugin system:
http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins
[1] Assuming Plone is a strict requirement and that you are building a content-management-driven application, else you should probably be using Django or Pyramid
Install/reinstall doesn't make sens in the context of an add-on. The vocabulary has been change to activate/unactivate but it is not again enough to understand the situation.
You have a 'setup' where you apply a configuration profile. Apply again and again a configuration profile doesn't make anything except broke existing configurations.
This is why every body will reply to this question by use upgrade step. We don't trigger profile on reinstall, we upgrade add-ons when the setup profile has some changes.
So if you are in a case where settings added by foo.core are changed by foo.optional you can do the following.
With the new plone.registry you can add a handler to the IRecord related events:
add
edit
remove
Consider the documentation:
http://pypi.python.org/pypi/plone.registry
I have done some code related to this where I want to rebuild css registry when some settings has been changed:
https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py