I haven't used Intellij IDEA in so long I actually don't even remember how to install it, or whether it is compatible with VS Code or VS Studio or both. Or even other editors for that matter.
In any case, sight unseen, if you followed the Ace3 docs, there is something that still works yet is years out of date in terms of "accepted practice", and that is ye olde embeds.xml.
That is a legacy convention from when Ace was new, Ace2 was newer still, and it had its own addon installer/updater, long before Curse or Twitch amalgamated both Curseforge and Wowace into one cohesive installer that propogated to Curse.
The point being that embeds.xml works, but should be replaced by directly referencing SomeLib.xml or SomeLib.lua in MyAddOn.toc.
Like I said, using embeds.xml still works, but if you are writing a plugin that creates a stub for a new addon, then please remove that functionality and update with the current accepted practice.
Oh, and don't think I am down or negative about your project. That is far from the case. I am 100% all for these kinds of useful tools and wish there were a lot more of them, so I hope you have phenomenal success, even possibly extending your project to IntelliSense the WoW API and major libraries. That would be amazing!
Hey, I thought of something else that you could do that is something a lot more basic than IntelliSense or supporting a few library APIs, and that is building into your stub default repository keyword substitution.
For example, in your MyAddOn.toc stub, you could have the stub say ## Version: @project-version@ instead of ## Version: 1.0 (or whatever you have) and you could also wrap the Libs folder with no-lib-strip codes. That sort of thing would be really, really handy for a stub.
I didn't really pay attention to new ways of doing things AddOn-wise, so don't worry, I'm ready to hear pretty much any suggestion :p I'm an advanced object oriented designer and dev, not an AddOn dev, and the reason why I'm developing this plugin is simply that I didn't want to re-do those steps every time :p (Plus, some friends and I felt there was something missing in the Wow AddOn dev chain: good tools)
I'll modify the TocFile to point to individual files instead of the enbeds.xml. To be frank, I'd rather never use xml, but I thought this was the accepted way of referencing libs x)
About IntelliSense, the Lua plugin by sylvanaar should provide basic Lua support (I use it for add-ons) and I bundled the wow-api wrapper from the same guy. On a new project, I have all the Lua stdlib and the wow-api that autocompletes, but not Ace3, due to how their Lua "Objects" are created: the Lua plugin doesn't parse it very well.
Impelmenting my own Lua parser is on my roadmap for the plugin though, it is a good way to train with Kotlin :p
About your second post, I am considering using IntelliJ File Templates to generate the default files, but it was too much of a hassle without clear docs, and I first wanted something working :) For now, all the strings written in the default files are ust compile time constants. Every part of the plugin is abstracted though, so adding new functionalities is just a matter of actually implementing them.
My job consists of allowing code to be re-used and understandable, so please, feel free to help on the project if you'd like (anyone, not just Myrroddin :p)
Oh, and repository keyword substitution only works with SourceForge right ? Not that it really matters, but I'd rather abstract the concept, add some deploy configuration, and implement SourceForge way of doing it x) That way, people pushing on different hosts can still chose not to implement it Sourceforge's way
I don't know about SourceForge; the link I provided was directly for the Curseforge/Wowace repo packager. There are repo keywords that definitely would work for GitHub, SourceForge and all the external sites, but I wasn't referring to those.
Those repository keywords you mean are supported by your repo client (TortoiseSVN and the like) which are similar in function but not the ones I meant.
God, I must be tired; I'm saying the same thing twice in one post!
And please don't look to me for coding help. I stuggle enough with Lua, know nothing about xml, and have a passing knowledge of Java and C#. All I can do is provide feedback :P
Repository keyword substitution is implemented with git hooks (for git, at least) which cam mean several things:
* Either the packaging tool bundles those hooks (often stored on the git server that receives your code)
* Or you implemented it on your side
I was just saying that I am going to abstract those concepts to allow ANY service to be implemented later on, and also expose a Cursewow/Wowace implementation as the default one, all integrated in IntelliJ's interface :)
I wasn't particularly asking you to help on the code, but was just insisting on the fact that the project is open sourced, so people can just fork it and modify it to their convenience. Your feedback is appreciated though :) That's a good way to contribute without the need to actually dev :p
PS: Do you know why the embeds.xml isn't used anymore ? If I had to design a way to reference a bunch of libs in a config file, I would use something similar, like almost EVERY other 'package/dependency manager-like' tool. Not XML of course, but YAML or JSON, instead of having a list of entries in my main config file.
I gave you a brief history of things via PM, but for the rest of folks, embeds.xml was required with the old pre-Curse WowaceUpdater; it was the only way the app could find library files on wowace.com to bundle them into a project. Since Curse Updater 2.0 through today's Twitch App, which replaced WowaceUpdater, they can pull from any repository.
Also, it makes loading an addon into WoW a slight bit faster, as WoW doesn't have to load a file (embeds.xml) that in turn loads other files (libraries). Install enough addons on a slower, older computer, and it will be noticeable.
Addon authors haven't had to hard-embed libraries (except for LibDataBroker-1.1, which has no .toc file) in years if they use the repository system, which is yet another reason for embeds.xml to go the way of the dodo.
Even authors who don't use the repository system and manually zip addons for upload don't need embeds.xml anymore. Users don't need to know where a library is hosted. Everybody wins!
I know of the cost of the xml file indirection (after 10 years of C++, I'd hope :p), and it's not that problematic, considering wow probably caches it somewhere independently of the method used, but I was talking about a design pov: having a list of files referenced in a toc file doesn't seem very practical, that's basically why we invented markup languages. The fact that the repo handles it better is a good reason though.
I still use embeds.xml simply because I don't feel like going into the ToC and scrolling to the spot where file loading is declared, then find the spot where libs are included versus AddOn files. In fact, for some of my larger projects I actually have a manifest.xml in each subdirectory that loads the relevant Lua files.
Simply because the practice is no longer necessary as it was in the old WowAce days doesn't mean it absolutely has no place ever.
I didn't really pay attention to new ways of doing things AddOn-wise, so don't worry, I'm ready to hear pretty much any suggestion :p I'm an advanced object oriented designer and dev, not an AddOn dev, and the reason why I'm developing this plugin is simply that I didn't want to re-do those steps every time :p (Plus, some friends and I felt there was something missing in the Wow AddOn dev chain: good tools)
I'll modify the TocFile to point to individual files instead of the enbeds.xml. To be frank, I'd rather never use xml, but I thought this was the accepted way of referencing libs x)
About IntelliSense, the Lua plugin by sylvanaar should provide basic Lua support (I use it for add-ons) and I bundled the wow-api wrapper from the same guy. On a new project, I have all the Lua stdlib and the wow-api that autocompletes, but not Ace3, due to how their Lua "Objects" are created: the Lua plugin doesn't parse it very well.
Impelmenting my own Lua parser is on my roadmap for the plugin though, it is a good way to train with Kotlin :p
About your second post, I am considering using IntelliJ File Templates to generate the default files, but it was too much of a hassle without clear docs, and I first wanted something working :) For now, all the strings written in the default files are ust compile time constants. Every part of the plugin is abstracted though, so adding new functionalities is just a matter of actually implementing them.
My job consists of allowing code to be re-used and understandable, so please, feel free to help on the project if you'd like (anyone, not just Myrroddin :p)
include some convey arrangement, and execute SourceForge method for doing it x) That way, individuals pushing on various hosts can in any case decided not to actualize it Sourceforge's way
Hiho!
I just finished the first version of a plugin for IntelliJ IDEA:
https://plugins.jetbrains.com/plugin/10042-world-of-warcraft-addon-support
The plugin generates:
It is under MIT License, so feel free to fork it :)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI haven't used Intellij IDEA in so long I actually don't even remember how to install it, or whether it is compatible with VS Code or VS Studio or both. Or even other editors for that matter.
In any case, sight unseen, if you followed the Ace3 docs, there is something that still works yet is years out of date in terms of "accepted practice", and that is ye olde embeds.xml.
That is a legacy convention from when Ace was new, Ace2 was newer still, and it had its own addon installer/updater, long before Curse or Twitch amalgamated both Curseforge and Wowace into one cohesive installer that propogated to Curse.
The point being that embeds.xml works, but should be replaced by directly referencing SomeLib.xml or SomeLib.lua in MyAddOn.toc.
Like I said, using embeds.xml still works, but if you are writing a plugin that creates a stub for a new addon, then please remove that functionality and update with the current accepted practice.
Oh, and don't think I am down or negative about your project. That is far from the case. I am 100% all for these kinds of useful tools and wish there were a lot more of them, so I hope you have phenomenal success, even possibly extending your project to IntelliSense the WoW API and major libraries. That would be amazing!
Good luck! :D
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorHey, I thought of something else that you could do that is something a lot more basic than IntelliSense or supporting a few library APIs, and that is building into your stub default repository keyword substitution.
For example, in your MyAddOn.toc stub, you could have the stub say ## Version: @project-version@ instead of ## Version: 1.0 (or whatever you have) and you could also wrap the Libs folder with no-lib-strip codes. That sort of thing would be really, really handy for a stub.
Hey!
Thanks for the feedback, it's much appreciated :)
I didn't really pay attention to new ways of doing things AddOn-wise, so don't worry, I'm ready to hear pretty much any suggestion :p I'm an advanced object oriented designer and dev, not an AddOn dev, and the reason why I'm developing this plugin is simply that I didn't want to re-do those steps every time :p (Plus, some friends and I felt there was something missing in the Wow AddOn dev chain: good tools)
I'll modify the TocFile to point to individual files instead of the enbeds.xml. To be frank, I'd rather never use xml, but I thought this was the accepted way of referencing libs x)
About IntelliSense, the Lua plugin by sylvanaar should provide basic Lua support (I use it for add-ons) and I bundled the wow-api wrapper from the same guy. On a new project, I have all the Lua stdlib and the wow-api that autocompletes, but not Ace3, due to how their Lua "Objects" are created: the Lua plugin doesn't parse it very well.
Impelmenting my own Lua parser is on my roadmap for the plugin though, it is a good way to train with Kotlin :p
About your second post, I am considering using IntelliJ File Templates to generate the default files, but it was too much of a hassle without clear docs, and I first wanted something working :) For now, all the strings written in the default files are ust compile time constants. Every part of the plugin is abstracted though, so adding new functionalities is just a matter of actually implementing them.
My job consists of allowing code to be re-used and understandable, so please, feel free to help on the project if you'd like (anyone, not just Myrroddin :p)
Oh, and repository keyword substitution only works with SourceForge right ? Not that it really matters, but I'd rather abstract the concept, add some deploy configuration, and implement SourceForge way of doing it x) That way, people pushing on different hosts can still chose not to implement it Sourceforge's way
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI don't know about SourceForge; the link I provided was directly for the Curseforge/Wowace repo packager. There are repo keywords that definitely would work for GitHub, SourceForge and all the external sites, but I wasn't referring to those.
Those repository keywords you mean are supported by your repo client (TortoiseSVN and the like) which are similar in function but not the ones I meant.
God, I must be tired; I'm saying the same thing twice in one post!
And please don't look to me for coding help. I stuggle enough with Lua, know nothing about xml, and have a passing knowledge of Java and C#. All I can do is provide feedback :P
Repository keyword substitution is implemented with git hooks (for git, at least) which cam mean several things:
* Either the packaging tool bundles those hooks (often stored on the git server that receives your code)
* Or you implemented it on your side
I was just saying that I am going to abstract those concepts to allow ANY service to be implemented later on, and also expose a Cursewow/Wowace implementation as the default one, all integrated in IntelliJ's interface :)
I wasn't particularly asking you to help on the code, but was just insisting on the fact that the project is open sourced, so people can just fork it and modify it to their convenience. Your feedback is appreciated though :) That's a good way to contribute without the need to actually dev :p
PS: Do you know why the embeds.xml isn't used anymore ? If I had to design a way to reference a bunch of libs in a config file, I would use something similar, like almost EVERY other 'package/dependency manager-like' tool. Not XML of course, but YAML or JSON, instead of having a list of entries in my main config file.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI gave you a brief history of things via PM, but for the rest of folks, embeds.xml was required with the old pre-Curse WowaceUpdater; it was the only way the app could find library files on wowace.com to bundle them into a project. Since Curse Updater 2.0 through today's Twitch App, which replaced WowaceUpdater, they can pull from any repository.
Also, it makes loading an addon into WoW a slight bit faster, as WoW doesn't have to load a file (embeds.xml) that in turn loads other files (libraries). Install enough addons on a slower, older computer, and it will be noticeable.
Addon authors haven't had to hard-embed libraries (except for LibDataBroker-1.1, which has no .toc file) in years if they use the repository system, which is yet another reason for embeds.xml to go the way of the dodo.
Even authors who don't use the repository system and manually zip addons for upload don't need embeds.xml anymore. Users don't need to know where a library is hosted. Everybody wins!
I know of the cost of the xml file indirection (after 10 years of C++, I'd hope :p), and it's not that problematic, considering wow probably caches it somewhere independently of the method used, but I was talking about a design pov: having a list of files referenced in a toc file doesn't seem very practical, that's basically why we invented markup languages. The fact that the repo handles it better is a good reason though.
-
View User Profile
-
View Posts
-
Send Message
AdminI still use embeds.xml simply because I don't feel like going into the ToC and scrolling to the spot where file loading is declared, then find the spot where libs are included versus AddOn files. In fact, for some of my larger projects I actually have a manifest.xml in each subdirectory that loads the relevant Lua files.
Simply because the practice is no longer necessary as it was in the old WowAce days doesn't mean it absolutely has no place ever.