Mill Build Tool, how to use `evicted` - scala

I want to run evicted in my Mill-project.
With SBT it can be done in the sbt-console, using:
sbt>evicted
This returns a list of version conflicts warnings:
[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn] * com.typesafe:ssl-config-core_2.13:0.3.8 is selected over 0.4.0
[warn] +- com.typesafe.play:play-ws-standalone_2.13:2.0.6 (depends on 0.3.8)
[warn] +- com.typesafe.play:play_2.13:2.7.3 () (depends on 0.3.8)
[warn] +- com.typesafe.akka:akka-stream_2.13:2.5.23 () (depends on 0.4.0)
....
How is this done with Mill?
I tried the mill-console, there is no command (mill resolve _) and also Google could not help.

I assume, you are looking for possible classpath issues/warnings, which are the result of different versions of the same dependencies pulled in by transitive dependencies.
In mill, you can use the ivyDepsTree target to display a tree with all transitive ivy dependencies. This tree also includes details about version adjustments. Those lines will be printed in different colors. By default, orange for micro/patch version changes, red for minor version changes.
Let's look at the following excerpt from a random Java project:
$ mill __.ivyDepsTree
...
[416/426] <redacted>.test.ivyDepsTree
├─ com.lihaoyi:mill-contrib-testng:0.5.1-14-ef3708
│ ├─ org.scala-sbt:test-interface:1.0
│ └─ org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)
│ ├─ com.beust:jcommander:1.72
│ └─ org.apache-extras.beanshell:bsh:2.0b6
├─ org.testng:testng:6.14.2
│ ├─ com.beust:jcommander:1.72
│ └─ org.apache-extras.beanshell:bsh:2.0b6
├─ de.tototec:de.tobiasroeser.lambdatest:0.7.0
├─ org.slf4j:slf4j-api:1.7.25
├─ ch.qos.logback:logback-classic:1.2.3
│ ├─ ch.qos.logback:logback-core:1.2.3
│ └─ org.slf4j:slf4j-api:1.7.25
├─ org.aspectj:aspectjrt:1.8.13
├─ org.fedorahosted.tennera:jgettext:0.15
│ ├─ antlr:antlr:2.7.7
│ └─ org.slf4j:slf4j-api:1.7.5 -> 1.7.25
├─ org.antlr:com.springsource.antlr:2.7.7
...
You can see some adaptions because of conflicting versions: org.slf4j:slf4j-api:1.7.5 -> 1.7.25 (micro version upgrade) and org.testng:testng:6.11 -> 6.14.2 (possible incompatibility) (minor version upgrade).
Further, you could pipe the output to grep to filter the output, e.g. mill __.ivyDepsTree | grep "incompatibility".
And this looks like a usable mill equivalent to sbt evicted.
$ mill __.ivyDepsTree | grep "incompatibility"
...
[416/426] <redacted>.test.ivyDepsTree
│ └─ org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)
│ ├─ org.hibernate:com.springsource.org.hibernate:3.2.6.ga -> 3.3.2.GA (possible incompatibility)
│ ├─ org.jboss.javassist:com.springsource.javassist:3.3.0.ga -> 3.9.0.GA (possible incompatibility)
│ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│ │ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│ │ │ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│ │ │ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│ │ └─ org.testng:testng:6.4 -> 6.14.2 (possible incompatibility)
│ └─ org.testng:testng:6.4 -> 6.14.2 (possible incompatibility)
│ │ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│ └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)

Related

flask application structure for multiple apps and database connections

Although a beginner in web development, I currently have been working on a larger Flask application.
At the moment I'm working with the structure shown below but I'm wondering what is the best way to structure such an application especially regarding different database connections (SQLAlchemy).
Unlike what is shown in the usual (and very helpful) Flask tutorials, I envision an architecture of multiple, partially independent (sub)apps, each also relying on its own database connection. Also, I don't necessarily want to load all databases immediately when accessing the main website but only the one of the subapp that is needed.
For communication between server and client I plan to use REST API and I already use Blueprints to separate the subapps.
The app has a unified frontend, where the subapps are simply mapped to different URL endpoints (e.g. website.net/app1 and website.net/app2).
Any guidance on structuring such an app is greatly appreciated, thanks!
Current app structure:
project/
├─ run.py
├─ webapp/
│ ├─ __init__.py
│ ├─ static/
│ ├─ templates/
│ ├─ app1/
│ │ ├─ data/
│ │ │ ├─ app1_database.py
│ │ │ ├─ app1_db_session.py
│ │ │ ├─ app1_modelbase.py
│ │ ├─ database/
│ │ ├─ services/
│ │ │ ├─ app1_services.py
│ │ ├─ templates/
│ │ │ ├─ app1/
│ │ │ │ ├─ app1.html
│ │ ├─ __init__.py
│ │ ├─ app1_forms.py
│ │ ├─ app1_views.py
│ ├─ app2/
│ │ ├─ data/
│ │ │ ├─ app2_database.py
│ │ │ ├─ app2_db_session.py
│ │ │ ├─ app2_modelbase.py
│ │ ├─ database/
│ │ ├─ services/
│ │ │ ├─ app2_services.py
│ │ ├─ templates/
│ │ │ ├─ app2/
│ │ │ │ ├─ app2.html
│ │ ├─ __init__.py
│ │ ├─ app2_forms.py
│ │ ├─ app2_views.py
As we are talking about modules and directories structure the main goal is to compose the app in a way that will be easy to you to maintain, debug and improve. I think if you have several apps in one project you better place each on a different server. We usually use blueprints when we want to separate logic within a single app and especially when we are planning to reuse this logic in a different app. So we can just copy-paste the single blueprint to another project. For example authentication blueprint. It can be the same in several apps.
You didn't show any business logic of the app. So it's hard to say. I usually slpit files into directories considering business logic.

Not able to right click on JMeter elements

Recently I downloaded a plugin - https://jmeter-plugins.org/?search=jpgc-ggl and since then I am not able to right click on any of the elements in the Jmeter GUI (v 5.2.1).
I tried the suggestion as below given in the link here but it did not solve the issue.
Removed jmeter-plugins-cmn-jmeter-0.4.jar from lib folder
Removed jmeter-plugins-graphs-ggl-2.0.jar from ext folder
Removed jmeter-plugins-manager-0.20.jar from ext folder
Please can someone help?
P.S: Plugins Manager gives me proxy Error on clicking because I am using my corporate proxy network. I download the jars and manually place them in the ext folder to use a plugin.
I cannot reproduce your issue using JMeter 5.2.1 and Graphs Generator Listener 2.0, here is listing of my JMeter's "lib" folder:
C:\TEMP\APACHE-JMETER-5.2.1\LIB
│ accessors-smart-1.2.jar
│ apiguardian-api-1.1.0.jar
│ asm-7.1.jar
│ bsf-2.4.0.jar
│ bsh-2.0b6.jar
│ bshclient.jar
│ caffeine-2.8.0.jar
│ checker-qual-2.10.0.jar
│ commons-codec-1.13.jar
│ commons-collections-3.2.2.jar
│ commons-dbcp2-2.5.0.jar
│ commons-io-2.6.jar
│ commons-jexl-2.1.1.jar
│ commons-jexl3-3.1.jar
│ commons-lang3-3.9.jar
│ commons-logging-1.2.jar
│ commons-math3-3.6.1.jar
│ commons-net-3.6.jar
│ commons-pool2-2.7.0.jar
│ commons-text-1.8.jar
│ darcula-e208efb96f70e4be9dc362fbb46f6e181ef501dd.jar
│ dec-0.1.2.jar
│ dnsjava-2.1.9.jar
│ error_prone_annotations-2.3.3.jar
│ freemarker-2.3.29.jar
│ geronimo-jms_1.1_spec-1.1.1.jar
│ groovy-all-2.4.16.jar
│ hamcrest-2.1.jar
│ hamcrest-core-2.1.jar
│ hamcrest-date-2.0.4.jar
│ httpasyncclient-4.1.4.jar
│ httpclient-4.5.10.jar
│ httpcore-4.4.12.jar
│ httpcore-nio-4.4.12.jar
│ httpmime-4.5.10.jar
│ jackson-annotations-2.9.10.jar
│ jackson-core-2.9.10.jar
│ jackson-databind-2.9.10.jar
│ javax.activation-1.2.0.jar
│ jcharts-0.7.5.jar
│ jcl-over-slf4j-1.7.28.jar
│ jmespath-core-0.3.0.jar
│ jmespath-jackson-0.3.0.jar
│ jmeter-plugins-cmn-jmeter-0.4.jar
│ jodd-core-5.0.13.jar
│ jodd-lagarto-5.0.13.jar
│ jodd-log-5.0.13.jar
│ jodd-props-5.0.13.jar
│ jorphan.jar
│ json-path-2.4.0.jar
│ json-smart-2.3.jar
│ jsoup-1.12.1.jar
│ jtidy-r938.jar
│ junit-4.12.jar
│ log4j-1.2-api-2.12.1.jar
│ log4j-api-2.12.1.jar
│ log4j-core-2.12.1.jar
│ log4j-slf4j-impl-2.12.1.jar
│ mail-1.5.0-b01.jar
│ miglayout-core-5.2.jar
│ miglayout-swing-5.2.jar
│ mongo-java-driver-2.11.3.jar
│ neo4j-java-driver-1.7.5.jar
│ oro-2.0.8.jar
│ ph-commons-9.3.7.jar
│ ph-css-6.2.0.jar
│ rhino-1.7.11.jar
│ rsyntaxtextarea-3.0.4.jar
│ Saxon-HE-9.9.1-5.jar
│ serializer-2.7.2.jar
│ slf4j-api-1.7.28.jar
│ tika-core-1.22.jar
│ tika-parsers-1.22.jar
│ xalan-2.7.2.jar
│ xercesImpl-2.12.0.jar
│ xml-apis-1.4.01.jar
│ xmlgraphics-commons-2.3.jar
│ xmlpull-1.1.3.1.jar
│ xpp3_min-1.1.4c.jar
│ xstream-1.4.11.jar
│
├───ext
│ ApacheJMeter_bolt.jar
│ ApacheJMeter_components.jar
│ ApacheJMeter_core.jar
│ ApacheJMeter_ftp.jar
│ ApacheJMeter_functions.jar
│ ApacheJMeter_http.jar
│ ApacheJMeter_java.jar
│ ApacheJMeter_jdbc.jar
│ ApacheJMeter_jms.jar
│ ApacheJMeter_junit.jar
│ ApacheJMeter_ldap.jar
│ ApacheJMeter_mail.jar
│ ApacheJMeter_mongodb.jar
│ ApacheJMeter_native.jar
│ ApacheJMeter_tcp.jar
│ jmeter-plugins-graphs-ggl-2.0.jar
│ jmeter-plugins-manager-0.20.jar
│ readme.txt
│
└───junit
readme.txt
The listing was generated using tree /F apache-jmeter-5.2.1\lib command, inspect your own folder and make sure it's in sync with what's displayed above.
Normally the reason of any JMeter failure or at least a clue can be found in jmeter.log file so take a look there - most probably you will see what's causing the error.
With regards to the Plugins Manager - you should be able to use it behind the proxy, it respects JMeter Proxy configuration, check out Plugins Manager Network Configuration chapter for more troubleshooting steps

Maven : import modules dependencies in parent project buildpath

I'm trying to convert an old Ant project to Maven. The project has a massive code base which is packed in different wars using Ant targets. It has multiple source folders, and each war is generated using different classes of these source folder. The code base should be separated in different sub-project but at the moment this is not an option so the goal is to have multiple wars for one project.
I've tried to use maven modules, creating a parent pom and a subfolder maven-modules in which I have one pom for each war that I need to generate, here's an example:
OldMassiveProject
│ ├── src
│ │ └── bunch.of.packages
│ ├── other_src
│ │ └── bunch.of.packages
│ ├── various_resources_folder
...
│ ├── maven_modules
│ │ ├── module_1
│ │ │ └── pom.xml
│ │ ├── module_2
│ │ │ └── pom.xml
...
│ │ ├── module_n
│ │ │ └── pom.xml
│ ├── deploy_configuration
│ │ ├── module_1
│ │ │ ├── spring_files
│ │ │ └── web.xml
│ │ ├── module_2
│ │ │ ├── spring_files
│ │ │ └── web.xml
...
│ │ ├── module_n
│ │ │ ├── spring_files
│ │ │ └── web.xml
│ └── pom.xml (parent pom)
I've managed to create the wars but my IDE (Eclipse) cannot resolve imports of the dependencies used in the modules'pom. That's because the parent pom doesn't specify those dependencies so they are not added to the project's classpath. My question is: Is there a way to import modules' pom dependencies in the projectclass path?

SBT: which files to put under version control?

I created a Scala project with SBT, referencing ScalaTest. Now it has this tree:
├───lib
├───lib_managed
│ └───scala_2.9.0
│ └───compile
├───project
│ ├───boot
│ │ ├───other
│ │ │ └───net.java.dev.jna
│ │ │ └───jna
│ │ │ └───3.2.3
│ │ ├───scala-2.7.7
│ │ │ ├───lib
│ │ │ └───org.scala-tools.sbt
│ │ │ └───sbt
│ │ │ └───0.7.7
│ │ │ ├───compiler-interface-bin_2.7.7.final
│ │ │ ├───compiler-interface-bin_2.8.0.final
│ │ │ ├───compiler-interface-bin_2.8.1.final
│ │ │ ├───compiler-interface-bin_2.9.0.final
│ │ │ ├───compiler-interface-src
│ │ │ └───xsbti
│ │ └───scala-2.9.0
│ │ └───lib
│ └───build
│ └───target
│ └───scala_2.7.7
│ ├───analysis
│ └───classes
├───src
│ ├───main
│ │ ├───resources
│ │ └───scala
│ └───test
│ ├───resources
│ └───scala
└───target
In addition to src tree, which files/directories should I put under version control (now using SVN)?
For sbt 0.7, ignore the following:
lib_managed
target
project/boot
project/build/target
project/plugins/lib_managed
project/plugins/src_managed
project/plugins/target
project/plugins/project/build.properties
There's sbt 0.10.x now btw.
For xsbt 0.10+, here is my .gitignore, in my xsbt template project:
target/
project/boot/
*.jar
It is similar to the official .gitignore in the xsbt project, but Eugene's might be more complete.

Difference between build and deploy?

What is the difference between a build and deploy and re-deploy?
What should be done when you just have some HTML changes and no Java code changes?
Should I do a build and deploy or just a re-deploy?
Disclaimer: Defining what build and deploy means is very subjective.
I will start with deploy. Deploy should mean take all of my artifacts and either copy them to a server, or execute them on a server. It should truly be a simple process.
Build means, process all of my code/artifacts and prepare them for deployment. Meaning compile, generate code, package, etc.
That helped? Some people do consider deploy as part of the "build process" which I don't really argue with because generally in order to test or run you have to deploy it somewhere.
The rule is generally if it is dynamic code, then you need to do a build/redeploy.
If you are just editing static html, css, images etc. then you can simply just patch (and preferably a server restart).
As always when "patching" there is added risk that you could not be deploying the entire code base, or someone could do it wrong.
Personally I like doing full build/redeploys because you always know you are in-sync with your source control. However there is always risk that deployments go bad, either the build part or the install part. If your builds take a long time, or you are unnecessarily having to deploy a lot of moving parts, then consider either breaking them down into smaller deployable components or create a more complete deployment plan.
As usual there is no silver bullet here.
Build means to Compile the project.
Deploy means to Compile the project & Publish the output
For web applications no need to deploy or nothing need to do at client side except simple browser with url.
all web applications are deployed at Server Machine(IIS) only, that application can be accessed by all client machines (any browser is enough).
For Desktop applications Wherever you want to use the application, need to deployed/installed in that system.
Watch this deploying process:
------ Build started: Project: AdventureWorks, Configuration: Release ------
Skipping 'belyaev_db.rds'. Item is up to date.
Skipping 'Sales Rep.rdl'. Item is up to date.
Skipping 'Top_10.rsd'. Item is up to date.
Build complete -- 0 errors, 0 warnings
------ Deploy started: Project: AdventureWorks, Configuration: Release ------
Deploying to http://...
Deploying data source '/Data Sources/belyaev_db'.
Warning : ...
Deploying data set '/Datasets/Top_10'.
Warning : ...
Error ...
Deploy complete -- 1 errors, 2 warnings
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
In this case I have some issues but as you can see - first step is in building - verification data sources and reports and only after that - deploying.
Build and Deployment are Back To Back Processes!
Build can be taken Only if there is any JAVA Code Change.
For only HTML or CSS file updates, no need of New Build.
The Property files change needs the Server Restart.
No need of Deploying Unchanged Build ear/tar file.
For updated ear Build, Deployment on Server process should be initiated.
The gist:
SOURCE DEPLOYMENT MODEL
┌──────────────────────────────────────────────────────────────────────┐
│ │
│ BINARY DEPLOYMENT MODEL │
│ ┌─────────────────────────────────────────────┐ │
│ │ │ │
│ │ │ │
│ ┌────────┐ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ source │ BUILD │ │ application │ DELIVER │ installed │ │ │
│ │ code ├─────────┼─►│ binary ├──────────►│ application │ │ │
│ └────────┘ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ │ │
│ └─────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────┘
To put it in context:
BINARY DEPLOYMENT MODEL
┌──────────────────────────────────────────────────────────────────────────────┐
│ │
│ BUILD MACHINE │
│ ( OR FARM ) TARGET MACHINE │
│ ______________________________________ _____________________ │
│ / /│ / /│ │
│ ┌─────────────────────────────────────┐ │ ┌────────────────────┐ │ │
│ │ │ │ │ │ │ │
│ │ ┌────────┐ ┌─────────────┐ │ │ │ ┌─────────────┐ │ │ │
│ │ │ source │ BUILD │ application │ │ │ DELIVER │ │ installed │ │ │ │
│ │ │ code ├─────────►│ binary ├─┼─┼─────────┼──►│ application │ │ │ │
│ │ └────────┘ └─────────────┘ │ │ │ └─────────────┘ │ │ │
│ │ │/ │ │/ │
│ └─────────────────────────────────────┘ └────────────────────┘ │
│ │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
SOURCE DEPLOYMENT MODEL
┌───────────────────────────────────────────────────────────────────────────────┐
│ │
│ BUILD MACHINE │
│ ( OR FARM ) TARGET MACHINE │
│ _______________ _____________________________________________ │
│ / /│ / /│ │
│ ┌──────────────┐ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ │ │ │ │ │
│ │ ┌────────┐ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │
│ │ │ source │ │ │ DELIVER │ │ application │ BUILD │ installed │ │ │ │
│ │ │ code ├──┼─┼───────────┼──►│ binary ├────────►│ application │ │ │ │
│ │ └────────┘ │ │ │ └─────────────┘ └─────────────┘ │ │ │
│ │ │/ │ │/ │
│ └──────────────┘ └────────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────────────────────────────┘