Is it possible to have a conditional package.json dependency based on the platform being built for, or, some hook that excludes / includes a dependency based on platform, when building a Nativescript 5.1 project?
My original plan was to use a Yarn alias to load 2 separate versions of a given package, then use platform.isIOS or platform.isAndroid to include only the right JS. However, under the hood the C++ shared object that both dependencies contain obviously has the same name - which gets clobbered, and both versions of the plugin end up using the same SO (defeating the point of the alias, as the bug I'm trying to get round is in the SO, not the plugin).
Related
My project consists of numerous (~100) components, most of them use ~10 core components. When I update a version of a core component I would like to have up-to-date version of it in every component that is using it.
Trouble is that components depend on many other components - and I want only one of these dependencies updated at a time (the one that has just been updated).
I am using versions-maven-plugin and the "update-properties" mojo - trouble is that it requires executing maven for each and every component in order to check if it needs update and doing the actual property update. I'm using Jenkins as a CI solution, tried that writing a custom pipeline and it sure is doable but it's still iterating over a whole project...
I was wondering if there maybe is a more efficient way to do this?
Would creating/maintaining dependency map be feasible here - do you know of any software that could be integrated into the pipeline to do that? (a little clarification here: all of my components are under the same maven groupid and the same project in gitlab).
I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/
I'm trying to design a solution that allows a single Virgo application to provide backwards compatibility for integrating with multiple versions of an external service provider.
For example, the application, call it PortalApp, is a portal that currently integrates with version 2.3 of ThirdPartyApp. ThirdPartyApp v3.0 is coming out soon with new features, so the new version of PortalApp will have features that won't work with the older version of ThirdPartyApp.
I don't require being able to serve both versions dynamically at run time, just one or the other. I've already established that I can have two versions of a module in the Virgo usr repository, and load one or the other based on the .plan file used at server start.
For simplicity, we can assume project is currently set up like this:
PortalApp
- web-app
- ThirdPartyProvider
There are a number of other modules that depend on ThirdPartyProvider, so changing the ArtifactId would break those chains. What I'd like to do is build two different versions of the same module. Something like this:
PortalApp
- web-app
- - 1.0
- - 2.0
- ThirdPartyProvider
- - 1.0
- - 2.0
I tried creating a parent pom.xml in web-app (packaging: pom) that identified both 1.0 and 2.0 as modules, but only one of them builds.
Can a single build of the PortalApp project build both versions of a module?
No, it's not possible (actually it is, but you really wouldn't want to do that because it's a world of pain). The pom has a version tag and this is the version of the artifact that is built.
Rather than do that, you should create a multi-module project, with one module for each web-app, as you have in your second diagram, each depending on the relevant version of the ThirdPartyProvider. You would then factor out the common code from these web-apps - usually this produces two things, a common web-app which you depend on from web-app:1 and web-app:2 (this will create what's called an 'overlay' which pushes the contents of common into the other two apps, but which doesn't overwrite existing files), and a shared java library containing the common java classes (depending on how you use the third-party api you may need two of these too).
You then build both web-apps, producing two artifacts, web-app-1.war and web-app-2.war, each with a dependency on the relevant ThridPartyProvider and on the common classes lib.
In order to keep all artifacts in the same version you could use Versions Maven Plugin to set the version 2.0 or 3.0 and in your build you can use mvn package -DthirdParty.version=3.0
Make sure your pom.xml looks like this
<properties>
<thirdParty.version>2.0</thirdParty.version>
</properties>
So you can use Jenkins in order to automate buils and ensure that eveyrhing is ok in your Continuous Integration process.
I have created a eclipse plugin and converted it to maven,which needs the dependency of antlr but when the plugin execute it says it cant find the required package. Then i came to know anltr is not osgi bundle. any one please tell me how to convert the antlr jar file into an osgi bundle.? The antlr dependency must support my mvenized eclipse plugin
The main ANTLR 4 project doesn't support this (see issue #689). However, I've recently created an independent fork of the project which aims to target a number of issues related to the use of ANTLR 4 in large(r)-scale and/or performance-critical applications. One of the items I'd like to implement is using OSGi for improved runtime versioning instead of the manual mechanism currently in place. I recommend filing an issue with this fork of the project so I can include these changes as part of my initial release.
https://github.com/tunnelvisionlabs/antlr4/issues
We create releases and upgrade the versions of our multi module project with the maven release plugin, which is usually triggered with a Jenkins release build. The problem is that we have a couple of modules whose versions should be updated as well, but which should not be built on the server - only the version upgrade should be performed. (These are just testing stuff only used occasionally by developers.) Any good ideas how to do that?
I believe the accepted policy is that every module should be built that forms part of a project. That includes those modules intended to test others.
If internally you have a situation in which a module is intended to test another but should definitely not form part of the build you may wish to extract that module into another project and adjust the module to depend on the artefacts of the older project's module.
You may still find that your CI server (such as Jenkins) recognises this dependency and builds your test project because it detects a changed dependency. In that case disable the automatic building of this test project.
You may find it less "smelly" to correct the testing procedure to ensure your test modules are designed to be run upon each build. Having a set of tests that should not be automatically run seems contrary to modern software engineering approaches.