You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off all, thanks for all the effort so far. I like to where this is going!
I would like a way to include / exclude specific files or folders from the src.
For example I have a folder sfjl and sfjl_examples, and I don't want the sfjl_examples folders included in the jar file.
Second, it would be nice to store export settings in settings.json.
For example, I would love something like this:
Have a setting to customize the export action looks good. One thing I'm thinking about is:
for the excludes and includes pattern, I think its better to put the final content there, which are the class files, not the source files. Does that make sense?
Sheng Chen (@jdneo) For me that is totally fine. And I prefer to accidentally release a jar that is missing a class file then releasing a jar that contains a file not meant to be released yet. If a project gets large it might be a hazzle to have to list all the class files. But I think people that have big project will relay on things like maven or graddle anyway. Also for any programmer with some basics skills it won't be hard to automate something to read a folder with the class files for example and print the strings that you can copy paste (most noob example I can think of). So yeah, keeping it simple is totally fine with me.
One important thing, you should not have to mention inner classes. Also it should also be possible to include other files like it already is now. This can be used to include some shader files for example that you can load using getClass().getResourceAsStream("/blur.glsl"); .
From a user experience perspective, I think when using this:
Then the next window should show the already created configs for jar exports, with at the bottom something like: "create new jar export config", which will take you threw the steps of naming the config and selecting the main class etc.
I think it's good to have advanced settings of exporting a jar, including some properties like includes, excludes and manifest. This would let users have chance to custom a pattern to exclude some folders and class files, or to include some resource files from other folder.
In your example, excluding some folder makes sense to me. But I'm a little puzzled by including a .java file. Do you want to add the corresponding .class file or just want to add it as a resource?
In your example, excluding some folder makes sense to me. But I'm a little puzzled by including a .java file. Do you want to add the corresponding .class file or just want to add it as a resource?
I added the .java by accident, I changed the OP. There should however be an option to include the source files so "Go to Defenition" works.
In your example, excluding some folder makes sense to me. But I'm a little puzzled by including a .java file. Do you want to add the corresponding .class file or just want to add it as a resource?
I added the .java by accident, I changed the OP. There should however be an option to include the source files so "Go to Defenition" works.
Hi Doeke Wartena (@clankill3r) ,
I'm going to use the custom task to support the predefined settings of export jar. I would like to know that if property mainMethod could meet your requirement of property manifest in your example? Thank you.
Doeke Wartena (@clankill3r) We want to know what kind of information you would like to specify in the customized manifest file. If we provide a field to let users specify the Main-Class, will it work in your case? Or there are other fields you would like to customize in the manifest file?
If we provide a field to let users specify the Main-Class, will it work in your case? Or there are other fields you would like to customize in the manifest file?
The things is, if you would support all those with special things in a json file then all you do is creating another chain that can potentially break. Also the amount of java programmers doing something with agent's for example is relative small.
Being able to set just the Main-Class will likely cover >95% of all cases. So my suggestion is to have two options where either one is used, one is specifying a Main-Class and two is a path to a manifest file. Having both options will allow 100% of the cases I assume.
Actually, now thinking about it, maybe it should always link to a manifest file, but that the first time it could ask for a Main-Class and creates a bare bones manifest file. That will be even more simple.
Activity
jdneo commentedon Aug 14, 2020
Doeke Wartena (@clankill3r)
Have a setting to customize the export action looks good. One thing I'm thinking about is:
for the excludes and includes pattern, I think its better to put the final content there, which are the class files, not the source files. Does that make sense?
clankill3r commentedon Aug 14, 2020
Sheng Chen (@jdneo) For me that is totally fine. And I prefer to accidentally release a jar that is missing a class file then releasing a jar that contains a file not meant to be released yet. If a project gets large it might be a hazzle to have to list all the class files. But I think people that have big project will relay on things like maven or graddle anyway. Also for any programmer with some basics skills it won't be hard to automate something to read a folder with the class files for example and print the strings that you can copy paste (most noob example I can think of). So yeah, keeping it simple is totally fine with me.
One important thing, you should not have to mention inner classes. Also it should also be possible to include other files like it already is now. This can be used to include some shader files for example that you can load using
getClass().getResourceAsStream("/blur.glsl");.clankill3r commentedon Aug 14, 2020
From a user experience perspective, I think when using this:
Then the next window should show the already created configs for jar exports, with at the bottom something like: "create new jar export config", which will take you threw the steps of naming the config and selecting the main class etc.
jdneo commentedon Aug 21, 2020
Shi Chen (@CsCherrYY) will recently look into this since he's the contributor of this feature.
CsCherrYY commentedon Aug 25, 2020
Doeke Wartena (@clankill3r)
Thanks for your follow and excellent idea of this feature!
I think it's good to have advanced settings of exporting a jar, including some properties like
includes,excludesandmanifest. This would let users have chance to custom a pattern to exclude some folders and class files, or to include some resource files from other folder.In your example, excluding some folder makes sense to me. But I'm a little puzzled by including a
.javafile. Do you want to add the corresponding.classfile or just want to add it as a resource?clankill3r commentedon Aug 25, 2020
I added the
.javaby accident, I changed the OP. There should however be an option to include the source files so "Go to Defenition" works.CsCherrYY commentedon Sep 24, 2020
Hi Doeke Wartena (@clankill3r) ,
I'm going to use the custom task to support the predefined settings of export jar. I would like to know that if property
mainMethodcould meet your requirement of propertymanifestin your example? Thank you.clankill3r commentedon Sep 25, 2020
Shi Chen (@CsCherrYY) Sorry, I don't understand the question.
jdneo commentedon Sep 25, 2020
Doeke Wartena (@clankill3r) We want to know what kind of information you would like to specify in the customized manifest file. If we provide a field to let users specify the
Main-Class, will it work in your case? Or there are other fields you would like to customize in the manifest file?clankill3r commentedon Sep 26, 2020
In certain cases I use things like this as well:
The things is, if you would support all those with special things in a json file then all you do is creating another chain that can potentially break. Also the amount of java programmers doing something with agent's for example is relative small.
Being able to set just the
Main-Classwill likely cover >95% of all cases. So my suggestion is to have two options where either one is used, one is specifying aMain-Classand two is a path to a manifest file. Having both options will allow 100% of the cases I assume.Actually, now thinking about it, maybe it should always link to a manifest file, but that the first time it could ask for a
Main-Classand creates a bare bones manifest file. That will be even more simple.jdneo commentedon Sep 27, 2020
Agree.
Thank you for the suggestion. We will consider about it.
jdneo commentedon Nov 16, 2020
Reopen this issue since #350 cannot unblock other customized usage.
jdneo commentedon Dec 1, 2021
Close this thread since the most part of the request should have been resolved.
There is one remaining: allow user to customized the manifest or allow user to select one, which will be tracked by #526.
Thanks.
JotaRata commentedon Nov 13, 2024
The suggested method of using
!{compileOutput}/packageNamedoes not work for me, I am using Maven for dependency management.How is that feature supposed to be used?