-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split projects, migrate to Kotlin DSL #33
Conversation
f0958f6
to
838c6c8
Compare
@weisJ , I don't have a Windows machine with C++ toolchain installed. Can you please check if In other words: |
Yes the module is build correctly. |
96e0dd5
to
1826855
Compare
I guess the PR is more or less ready. Release to Central should work. If you have Docker, you can test the release with https://github.com/vlsi/asflike-release-environment#switching-tlps The doc is here: https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin#making-a-release-candidate Basically:
|
You can add
However please use And prepareVote is the only step that needs signing keys (it signs artifacts and pushes them to the staging repository). The release task does not need signing.
Oh. It looks like it can't find a keyring file. I have the following in my
|
build.gradle.kts
Outdated
|
||
val buildVersion = "darklaf".v + releaseParams.snapshotSuffix | ||
println("Building Darklaf $buildVersion") | ||
println(" OS: " + System.getProperty("os.name")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to remove this as the user often knows which OS they are using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be removed, no problem :)
Ok great that worked. Thank you! Also a separate repository was created that is empty. Is this something that can be avoided? (If not it's not a big deal.) How exactly does the voting process work? I'm still pretty new to this kind of stuff. |
filteringCharset = "UTF-8" | ||
textFrom("licenses/NOTICE.txt") | ||
textFrom("licenses/PBJAR_LICENSE.txt") | ||
textFrom("licenses/INTELLIJ_LICENSE.txt") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
textFrom("licenses/DARCULA_LICENSE.txt")
is missing here.
This would mean the parent project just adds Edit: Forgot to mention that I do like the idea :) |
Well, that was not intended. I don't think it makes sense to release My intention was to package lib and dll (is just a dll enough?) into darlaf-windows.jar. However, in practice https://oss.sonatype.org/content/repositories/comgithubweisj-1035/com/github/weisj/darklaf-windows/1.3.3.4/darklaf-windows-1.3.3.4.jar includes windows-x86/darklaf-windows.lib twice. Note: I think it is worth shipping debug libraries for the following reasons:
However, I thought I disabled publications of the individual dlls.
It does not have to be a formal vote, however in Apache Software Foundation they have a requirement that each release have to pass a vote. That is release manager prepares the release artifacts, then other committers verify the artifacts and express their opinions. It is like you shared a staging repository above. Now we know that the build script publishes a little bit too many files, and the contents of |
The root project does not have to add
Ok, cool. I suggest splitting the core to its own subfolder after this PR is merged. |
The dll should be enough as that is the one that is being loaded.
So instead of the lib twice the dll should be included.
Ok thank you for the clarification.
After testing it, it seems as if darklaf-core is needed when building the fat jar. |
What do you intend to use a fat jar for? Fat jars do not play well with licensing: you have to obey the licenses for third parties you bundle. |
@weisJ , could you share |
|
You are probably right with this. In this case the shadow plugin isn't needed anymore. |
I think the problem is with: from(binary.linkFile) to from(binary.linkFile
.map { it.asFile }
.map { it.parentFile.toPath().resolve( "${it.nameWithoutExtension}.dll") })
}
from(path) copies the dll instead of the lib file. Edit: Yes this resolves it. https://oss.sonatype.org/content/repositories/comgithubweisj-1036/com/github/weisj/darklaf-windows/1.3.3.4/darklaf-windows-1.3.3.4.jar |
Can you please try
Can you please try |
@vlsi working |
Does this conclude the PR? |
Not yet. Does binary.runtimeFile return a name of |
Just in case: can you please perform yet another |
|
Ok, great. rc2 looks wonderful to me. |
One more thing: the missing bit is copying of the generated-pom.xml to their respective locations. |
The following changes happen here:
darklaf-windows
is extracted to its own project. That helps to confine Windows-specific codedarklaf-native-utils
is extracted to its own project as well sodarklaf-windows
andcore
can depend on itjava-library
cpp-library
does not work with java-library , socompileOnly
+runtimeOnly
is used instead ofapi/implementation
.Note: I think it makes sense to move core into its own subfolder (e.g.
core
), however, that change is not included here.It would co-locate folders like
core/src/
andcore/build
.