Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Summary: How to setup an (existing) TYPO3 Composer project for developing custom TYPO3 extensions (that are used in that project)? How to handle extensions not specific to the individual project, which may be in several projects.
I have a Composer TYPO3 project for our site. Relevant files (such as composer.json, composer.lock, LocalConfiguration.php are included in the Git repo)
The question is how to develop own custom (currently non-public) extensions and setup the development instance.
It seems, the solution of choice for the extensions specific to the project is to include them in the project repo, e.g. in a folder /extensions and adding them using repository type=path like this:
composer.json:
"repositories": [
{
"type": "path",
"url": "extensions/*"
},
...
"require": {
"myvendor/myextension": "#dev",
...
}
For extensions used only in this project this makes sense to me.
What do I do with extensions that are not specific to this project? They are used in other projects as well. For example, there might be a bug which is reproducible in my project - so I would like to debug and develop on the extension in this project. Same goes for creating PR for public extensions of other authors.
What I currently have for the custom extensions: They have their separate git repositories (private Gitlab), are tagged for releases and required with version tags.
composer.json (incomplete)
{
"repositories": [
{
"type": "gitlab",
"url": "git#gitlab.mysite.org:typo3-extensions/my_extension.git"
}
],
"require": {
"myvendor/my-extension": "^1.3.1"
}
}
This setup is not suitable for using the same git repository to setup the development site and develop extensions on this (as the custom extension are fetched from Gitlab by Composer without the .git files).
To me, the most straightforward solution seems to be to create a new branch in the extensions' repository starting at the commit/tag/version that is currently used in the specific problem.
Set the required version in the project to the new branch and start hacking away at the problem till you find a solution.
Then you can consider merging the changes back into master or keep a separate branch for this project which receives updates from master.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have never used the gradle wrapper, but IntelliJ Documentation recommends it. Are there any drawbacks to using it?
In particular, if I use 'too new' a version, will I have any trouble porting to older OSs?
The wrapper makes your projects more self contained and build-predictable. You can set the version to whatever you want, so 'too new' a version is not an issue. The wrapper is also cross platform.
The main upside is that you can set the version in your build file, and anyone pulling down the code will build off of your specified Gradle version, regardless of what they have installed on their machine, or even not installed at all.
The downsides are:
Uses more drive space.
Harder to change the Gradle version on multiple projects at once, unless you have a common defined version somewhere, and that creates a dependency between projects. If you have many projects and upgrade gradle version to the latest and greatest, each will have to download it. Then again, the Gradle files to install will be cached locally, so that will speed things up.
Now for the opinion part...
I find that unless I need to lock a project to a specific Gradle version for compatibility, or have many others building a project that may be using different Gradle versions, I am happy linking to a local version from the IJ project, and not using the wrapper. That way I can change the version for all my project’s modules in one place.
I have a Laravel 5.3 project which I am upgrading to Laravel 5.4 and due to some changes in Laravel there are some dependencies that need updating. Every dependency except one had an updated I could safely switch to.
Checking github I found others with the same issue and an easy solution on how to fix the problem. However, due to unknown reasons the developer of the dependency has stated that they will no longer support it and would consider it deprecated. There are pull requests to fix the issue but no one can accept these requests.
What I can do is navigate to my vendor folder and make the changes myself but I know this isn't the right way to do things as the changes will get overwritten eventually and we are back to square one.
How do I deal with the problem of outdated/unmaintained dependencies with problems I could fix on my own or solve with the help of others who share their solutions?
1) I could copy the files from vendor and try to just integrate the third party files into my project.
2) I could fork the repository and make the required changes and either add my forked version to packagist (doesn't feel right) or add my forked git as a repository in the composer.json file.
I am open to other ideas, thanks!
I will add the way I have solved it for now. If someone has a better answer I would gladly accept it.
In my case the repository in question is a Github repository which I could fork. I can then clone the repository and make any needed changes. Let's say that the following is what I have in my composer.json file.
"require": {
"someoneelse/project": "^1.0"
}
Inside my composer.json file I found the "someoneelse/project" for the dependency and changed the current version requirement "^1.0" to "dev-master". This will pull the latest commit from the master branch and put minimum-stability as dev.
I then added my repository to composer.json. You can do this like so
"repositories": [
{
"type": "git",
"url": "https://github.com/markustenghamn/project.git"
}
],
"require": {
"someoneelse/project": "dev-master"
}
Running composer update will now fetch the latest version from my forked repository. If someone decides to start working on this project again I can always change it back. The dependency may require other dependencies in forked projects composer.json file, remember to update these if needed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
This post was edited and submitted for review 1 year ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I have an Xcode 7.3 workspace with three projects, App, FrameworkA, and FrameworkB. Each project has a single target. This is iOS, so the framework targets are Cocoa Touch Frameworks, which means frameworks containing dynamically linked shared libraries.
App depends on Framework A which depends on Framework B. These dependencies are working, insofar as A properly links to the build product of B, and the App properly links to and embeds both frameworks A and B (because you cannot have one framework embedding another, it seems an application bundle needs to link and embed both direct and transitive dependencies.)
But here is my problem. Frameworks A and B have the usual build configurations, Debug and Release. App has an additional build configuration, LocalRelease, which is triggered by the Run build action, and used for building an optimized build (like Release) but code signed with a developer identity (like Debug).
When I try to build App with this LocalRelease build configuration, this breaks the build since it breaks the dependencies on frameworks A and B. I believe that is because these frameworks do not have LocalRelease build configurations, so Xcode never puts their build products into a LocalRelease-iphoneos folder, as it does with App.
So my narrow question is, how do I configure build settings so that a project with a nonstandard build configuration name (like LocalRelease) can depend on other projects that use only the standard build configuration names? I'm hoping there's a simple way to do this that does not require adding scripts or xcconfig files, but if those are necessary I'd love to understand why.
And my broader question is, is it in general a bad idea to introduce additional build configurations because they do not allow smooth interaction of dependencies between projects in a shared workspace? I was led to defining this third configuration because I wanted an optimized local build, I did not want to define a new scheme, and I wanted the choice of build type to be expressed by the various build actions (run, profile, release) of a single scheme.
But maybe this was the wrong way to do it. As long as it is the case that build configuration names drive build product directory paths, and dependent projects need to find each other's build products in a shared directory, it seems like introducing a non-standard build configuration name to a project will break interoperation with depended-upon other projects.
I raised a Developer Technical Support ticket with Apple about this, and spoke to the Xcode engineers at WWDC.
Answers to my own questions
how do I configure build settings so that a project with a nonstandard build configuration name (like LocalRelease) can depend on other projects that use only the standard build configuration names?
Answer: cannot be done.
is it in general a bad idea to introduce additional build configurations because they do not allow smooth interaction of dependencies between projects in a shared workspace?
Answer: yes, this is a bad idea.
So creating a new named build configuration is not the smart way to do what I was trying to do. Unfortunately, seems like the "simplest" solution is to embrace xcconfig files and change config files manually for this sort of thing.
In Xcode 11, it appears that if no corresponding configuration is found in the project dependency, the build system falls back to the setting Use {configuration here} for command-line builds under project configurations.
Xcode settings UI
Cleaning, building, and then inspecting my built products directory shows that the dependency is only built for the selected configuration.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently our main product solution is stored in a single TFS project, and all 3rd-party libraries that are referenced by our projects are pulled in from nuget, so the binary files are not stored in TFS. Now we are having to create a customized fork of one of the libraries (class library) that our product will reference. The library we are going to "fork" lives on codeplex as a TFS/SVN style project that we don't control, so we only have read access to it via the SVN interface, meaning there's no way to do a proper fork like you might be able to do with a git project. As such, our fork has to live elsewhere, disconnected from the codeplex project going forward. Since we use TFS for our main product, we'd like to store the fork and develop it in our TFS environment.
What is the best practice for storing this library in TFS so that our main project can reference it? Should it be in its own TFS Project? How should another project in TFS reference the library?
The team Project is a choice that you will have to make as to which best suits you, either a new stand alone isolated project or whether it just sits with in your current one project, it really depends on how much development work you are going to do with it and whether you want to be able to manage that through the same sprints etc.
To consume it i would just build it and create a NuGet Package and consume it in the same way as you do with all the rest of your referenced projects, obviously you may need to have this in your own NuGet feed.
If this is the only project that requires this customized library, put it in a folder inside of your current project that is parallel to your Sources (now cloaking is not required). Create a manual triggered build definition that builds the library and creats a NuGet package. Use a post-build script (or modify nuget.target) to push that NuGet library to your NuGet repository. Then reference this in your daily build.
You can overlay new releases from codeplex in your folder structure, if needed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I work on a project far too big to reside in a single Visual Studio / Eclipse / NetBeans project and we have a "common software" team responsible for developing and maintaining software libraries used by other teams.
I'm struggling with how to manage the development of and changes to the common software. When method signatures and classes change, do I keep the old versions and mark them deprecated? The current plan is to distribute a new build of common libraries every two weeks.
Definitely set up a repository. If you are a Maven-hater check out Gradle, it uses Ivy. Maven has a reputation for being complex but it does have better tool support. IDEs support Maven either out-of-the-box or with plugins, they give you graphs showing what the jars in your project depend on, so you can see conflicts easily.
Either Ivy or Maven will sort out your dependencies so your projects are using the right versions. Each of your projects should list (in the pom.xml for Maven) what version of which of your common libraries that it uses.
A common feature of most version control systems is the use of external branches. Common software is fetched from a shared repository and integrated in each project on update.
A key difficulty lies in documentation changes to the public API of common software and I see two solutions : good communication of deprecated signatures adn continuous integration where finding out deprecated methods can prove painfull.
There are a few options you can have.
Option A: use a repository
For Java based systems I would recommend that you use Ant+Ivy or Maven and create an internal repository with the code in those common projects.
Option B: Classpath Project
If setting up a repository is too much, what you can do is a create an eclipse project called classpath with the following three directories in it
classpath\
docs\
sources\
jars\
The team working on the common project can have a build script which complier the common code and places it into the classpath project, all that the rest of the dev team need to do is checkout the classpath project and reference the files in it during development.
Personally I am a fan of option B unless there is a full time person dedicated to doing builds in which case I go for option A.
The way to manage changes in method signatures is to follow a common version convention so when you do a major version number increase you can say dependent code will have to be changed, and if it is a minor version number increase then dependent code does not need to change. marking code as deprecated is a very practical option because IDE and build systems should issue warnings and allow the coders to switch to newer versions. If the same team is changing the common code and the main project then you will need to have the actual eclipse projects all checked out in the same workspace so that re factoring tools can do their job.
Unless the code in common will be used across across many projects I would keep it in all in one project, you can use multiple source folders to make navigating to various parts of the code easy. If you are having trouble with developers checking in stuff that is breaking things, then I would recommend you have more frequent checkins or have developers work on branches where they merge from the trunk to their work branch frequently to eliminate sync problems, when done they can merge from the branch back to the trunk, the latest version of subversion have decent support for this, and DVCS source control systems like mercurial, and git hub are excellent at this.