-
Notifications
You must be signed in to change notification settings - Fork 43
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
Reduce assumptions about project structure #48
Comments
Should the config within the moduleA go into the classpath or is that a typo? |
That is correct. |
Could you please create a test repo with the subprojects/modules and some of these libraries? That would really help here. |
I've created a simple project a https://github.com/alexanderfloh/launch4j-issue48 to show the basic structure. However, I ran into the problem that the files specified in Also, as mentioned above there is no way of retaining the folder structure.
|
As per #49 I would like a way of specifying no classpath, so just the JAR file specified in the
But when I do this, I still have all the dependent JARs for the current project added to the classpath (from
I took a look at
I guess this is why A-ha - another workaround. I realised my project uses the application plugin, which makes it a Java project, thus the compile dependencies are included on the classpath. I didn't need that, changed to distribution plugin only, and this appears to work - the entire classpath is not copied in. Apologies for the rambling, I hope this helps someone else. |
This commit allows to change the resulting library folder structure by setting the `copyConfigurable` with either a FileCollection or a CopySpec. The latter will result in an incomplete UP-To-DATE check on the second run after a change and so should only be used as last resort.
This commit allows to change the resulting library folder structure by setting the `copyConfigurable` with either a FileCollection or a CopySpec. The latter will result in an incomplete UP-To-DATE check on the second run after a change and so should only be used as last resort.
@gravelld @alexanderfloh the commit def mySpec = copySpec {
from(project(':module-A').jar.outputs.files) {
into('module-a')
}
from(project(':module-A').sourceSets.config.resources) {
into('module-a')
}
from(project(':module-B').jar.outputs.files) {
into('module-b')
}
}
launch4j {
mainClassName = 'A'
dontWrapJar = true
headerType = 'console' // just for testing the printlns of your test project
jar = "module-a.jar"
copyConfigurable = mySpec
} The resulting classpath section in the launch4j xml looks like: <classPath>
<mainClass>A</mainClass>
<cp>lib\module-a\module-A.jar</cp>
<cp>lib\module-a\someConfigFile.xml</cp>
<cp>lib\module-b\module-B.jar</cp>
</classPath> |
@TheBoegl works fine for the demo project, I'll also try if for my real app. Can you please clarify what you meant by
Again, thanks for all the work you're putting into this! |
You're welcome! In the current implementation I've seen no other way how to configure the task inputs if a CopySpec is passed into the If that is OK for you, please close this issue, otherwise feel free to help to improve this implementation. |
Thanks for your work @TheBoegl |
@TheBoegl I discovered another problem when trying it with my real world app: I didn't realize that it makes a difference when adding directories to the classpath vs. adding files to the classpath. I'm guessing that this resolving of the actual files rather than just using the directory is a side effect of using the CopySpec, and my guess it is required for the up-to-date checks, but I'm hoping you may have another idea how to solve this. In the Gradle Eclipse plugin I've noticed they give you various levels of fallbacks to modifiy the generated Eclipse project's classpath do you think something like this might make sense here as well? |
IMHO I don't think that a CopySpec with a set Would it be OK for you to configure the classpath on your own and provide the CopySpec? This way the convention over configuration approach would work for a typical use case and a special one, like yours, would be configurable after all. |
This commit adds the option to override the classpath which usually is created by the runtime configuration or the `copyConfigurable`. This should only be used as last resort fall back option because no further internal configuration is used or the input validated.
@alexanderfloh I've pushed the changes to OJO as version 2.4.0-SNAPSHOT. You can test this snapshot and give feedback afterwards. |
Hi, I've already added this as comment to #37 but I think it may have been lost.
Unfortunately I'm still unable to build my application, so I'll try to give more context.
As mentioned before, the application consists of multiple modules, and the distribution should look like this (items marked with a
*
should go in the classpath):Ideally, I'd like to be able to convince the launch4j plugin to not make any assumptions about my directory structure. Just point it at a directory, specify what should be included in the classpath and have it generate an .exe-file.
Alternatively, being able to provide a
CopySpec
for copyConfigurable might work as well for me, but I'm a bit worried about that resulting in an unnecessary amount of copies of the output files.Thanks for investing your time in this, I appreciate it.
The text was updated successfully, but these errors were encountered: