Good practice for derived version of Sweet Home 3D

[enkonyito]

To individually modify the ceiling lights of the rooms, a derived version of Sweet Home 3D must be created, the main constraint of which is to update each new version of the program.

For a good follow-up of these derived versions, is it better to create a new Sweet Home 3D project or a new Plug-in ticket in the official Sweet Home 3D project?

The GNU General Public License requires the publication of the source code for the modified program.

Apart from the executable jar version essential for a plug-in, distributing only a portable version for major updates (X.Y) of Sweet Home 3D is it enough?

[enkonyito]

The build of [font=courier new]jarExecutable[/font] and [font=courier new]sourceArchive[/font] is successful but not for [font=courier new]portableArchive[/font] because I get this message.

Code: Select all

Warning: Could not find file C:\Library\Java\JavaVirtualMachines\zulu-15.0.2-macosx_aarch64.jdk\Contents\MacOS\libjli.dylib to copy.

Is it because in the build.xml file it is mentioned that ?

Code: Select all

Builds install/portable/SweetHome3D-version-portable files required for SweetHome3D portable version 
CAUTION : May be run only under Mac OS X and requires 
		OpenJDK 15.0.2 for x86_64 installed in /Library/Java/JavaVirtualMachines/zulu-15.0.2-macosx_x86_64.jdk, 
                OpenJDK 15.0.2 for arm64  installed in /Library/Java/JavaVirtualMachines/zulu-15.0.2-macosx_aarch64.jdk, 
                lipo, codesign and a certificate imported in Keychain Access

[Puybaret]

If the purpose of this derived version is only to handle individual light on ceilings as explained here, I think you could manage this feature with a plug-in that would modify the property of your choice on room instances. Properties are saved in SH3D files and you may even listen to their change from version 6.4.
A plug-in would also prevent from generating updates for each new version of Sweet Home3D.

If you want to build a portable version, you'll need a macOS computer for some parts as you correctly read (I gave some explanations about building the portable version in a comment of this blog article), but you could avoid it by reusing the existing portable version since you probably just want to change only SweetHome3D.jar file.

Finally, about where to host derived versions, it's up to you to decide. Just keep in mind that "Sweet Home 3D" is a registered trademark owned by eTeks, and it can't be reused anyhow.

[enkonyito]

If the purpose of this derived version is only to handle individual light on ceilings as explained here, I think you could manage this feature with a plug-in that would modify the property of your choice on room instances. Properties are saved in SH3D files and you may even listen to their change from version 6.4.
A plug-in would also prevent from generating updates for each new version of Sweet Home3D.

This derived version also offers the grouping of actions of the same plug-in in a menu.
This time around I added a new [font=courier new]CEILING_LIGHT_POWER[/font] property and a [font=courier new]ceilingLightPower[/font] spinner in the edit room panel. Is it also possible to manage them from a plug-in as you suggested?

If you want to build a portable version, you'll need a macOS computer for some parts as you correctly read (I gave some explanations about building the portable version in a comment of this blog article), but you could avoid it by reusing the existing portable version since you probably just want to change only SweetHome3D.jar file.

As I have been using the portable version for 1 year mainly with a configuration file, I had not noticed this old article.
Not having macOS, how to reuse portable version 6.5 with the derived jar file?

Finally, about where to host derived versions, it's up to you to decide. Just keep in mind that "Sweet Home 3D" is a registered trademark owned by eTeks, and it can't be reused anyhow.

If that were to be done, I thought to change the name by putting a reference to "Sweet Home 3D".

[enkonyito]

Not having macOS, how to reuse portable version 6.5 with the derived jar file?

By replacing the SweetHome3D.jar file with my derived version, I can reuse the downloaded portable version.
SH3D-6.5-portable_derived.jpg

[enkonyito]

With the build.xml of SweetHome3D-7.3, it is possible to do without a macOs computer to create a portable version.
I don't know if this is normal but in the [font=courier new]data[/font] folder, the [font=courier new]furniture[/font], [font=courier new]languages[/font] and [font=courier new]textures[/font] folders are empty.

The other solution, replacing the SweetHome3D.jar file of the existing portable version, still works.
Tip: This also works for the existing installer version.

[Puybaret]

Yes, it's possible to build the portable version 7.3 under any system because macOS support was removed from portable version for security reasons.
Note that if you want to generate the Windows executable files and don't have a signature, you should run windowsSignedPortableLaunchers target after removing the lines 1547 to 1563 in build.xml.
Then, you have to fill the [font=courier new]runtime[/font] folder with JREs (you can copy them from exisitng portable version), and fill the subdolders of [font=courier new]data[/font] with the libraries of your choice. These folders are empty when you run the current portableArchive target.