Support `mill init` from an existing Maven project (1500USD Bounty)
From the maintainer Li Haoyi: I'm putting a 1500USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
We should be able to run ./mill init to do a best effort conversion of an existing Maven project to Mill:
- Code-generate a
build.millcontaining aMavenModulefor the rootpom.xml, thepackage.millfor any subfolderpom.xmls - Convert the main and test dependencies on third-party libraries to
ivyDeps - Convert inter-subproject dependencies to
moduleDeps - Set any necessary
javacOptions - Implement
PublishModulewith relevant metadata - Support POM inheritance, dependency management, etc.
Such a conversion will never be 100%, but if we can automate 80% of the conversion that will already be a huge help for people migrating to Mill or even just trying it out
Some prior art that can be used as reference:
- Gradle's Maven Importer https://docs.gradle.org/current/userguide/build_init_plugin.html#sec:pom_maven_conversion
- SBT's POM Reader Plugin https://github.com/sbt/sbt-pom-reader
Is there any infrastructure for this already? For example, does mill init entry point exists?
@arturaz mill init already exists, and uses giter8 to initialize a repo based on some github URL:
https://github.com/com-lihaoyi/mill/blob/7732b0fa1588d7e6b4dd70a5016458ac193fa222/main/src/mill/main/MainModule.scala#L403
It should be pretty easy to add logic to check if there's an existing pom.xml in the project root and initialize based on that instead
I'll try to implement this :)
@arturaz go for it!
@arturaz Is this completed? If not do you mind if I give this a try 24 hours from now?
I am working on it right now (fell ill with COVID after starting it). Could you give me a couple of days to finish it? 🙂
---- On Mon, 23 Sep 2024 03:29:37 +0300 @.*** wrote ----
@arturaz Is this completed? If not do you mind if I give this a try 24 hours from now?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
@arturaz Would you like some help with completing it?
@arturaz Would you like some help with completing it?
I'm not sure how that'd work, at least right now, but I will keep that in mind!
@arturaz Bounty percentages seem like a reasonable option if you're interested in receiving help & sharing some bounty percentage.
Hey @llvee.
I think you should take over this. I've pushed what I've done to https://github.com/arturaz/mill/commit/3bcf83464353e57f3251df13c8fa94f10e92974d , feel free to use any or none of it.
I've hit a bump while implementing BOM file support and thinking on how to translate that to mill when Maven allows property references to be used in any part of the artifact.
And then life hit me and now it seems I won't have time for at least 3 weeks.
I've used these repos as the target for conversion:
- https://github.com/redis/lettuce
- https://github.com/redisson/redisson
Cheers!
Yes depending on Scalalib is fine. We can reorganize the module dependencies inside Mill as necessary.
But we should not need fancy build DSLs. We just need to generated source code as strings. Helper methods are fine, but Scala already does a decent job at mangling strings. I don't want this to be overengineered
On Sat, 12 Oct 2024 at 3:26 PM, Ajay Chandran @.***> wrote:
@lihaoyi https://github.com/lihaoyi Would it be okay if mill.init package depended on mill.scalalib?
This allows for patterns like
// Build DSL
// usage: extends[mill.Module] def
extends[T](implicit T: ClassTag[T]): Build =extends(T.runtimeClass.getCanonicalName)// usage: extends("mill.Module") def
extends(supertype: String): Build = ???— Reply to this email directly, view it on GitHub https://github.com/com-lihaoyi/mill/issues/3449#issuecomment-2408565346, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5HBDBSTOLUQZCF5DPHC3LZ3EPQ7AVCNFSM6AAAAABNRLVUQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGU3DKMZUGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>