Regarding instaling plugins from Maven - we'd definitely like to support
this. Perhaps we could take what you've done and standardize it as a
supported plugin installation mechanism?
Regarding testing the plugins in a forge release distribution. As of Forge
1.0.3.Final, you can invoke Forge from the command line using:
forge -e "command or script to run"
So hopefully that will be of use :) You can install plugins using this
feature as well, so with the combination of the two, we should have some
good testing options!
Lincoln Baxter, III
"Simpler is better."
I´ve implemented the plugin specified on
https://issues.jboss.org/browse/FORGE-550, however, there is a small
change on the actual scaffold providers:
You must add the @Help annotation on top of it so that it will be
displayed next to the alias when running this plugin.
I kindly ask you if you are working on a scaffold provider to add this
annotation so it should display properly when running
Pull request @ https://github.com/forge/core/pull/153
after having a look at receipt at
http://forge.github.com/docs/get_involved/contribute.html I would like
to clarify the use the repositories.
- I have cloned forge/core to a private github repository
- cloned my repository to my local system
- generated a branch, committed changes, pushed to my github repository
One thing is left: how will I get updates of the master forge/core into
my _remote_ repository, as there is no "pull" on github?
If I understood correctly, I can associate the remote master by "git
remote add upstream <git_master_repo>"
To get the changes of the "upstream" master I issued:
~> git pull upstream master
Now my local repository was up do date, but not my remote repository. So
~> git push
which seemed to update my private _remote_ repository with the changes
from the remote "upstream" master.
So for me this means, that from now on I "remote control" my private
_remote_ repository via my _local_ repo.
Could you kindly comment/confirm/explain in more detail.
I'm taking a break from the JSF UI scaffolding at the moment, but I notice some incorrect changes have been made. Could I please ask someone to revisit
1. ForgeInspector now holds a reference to ForgeInspectorConfig internally, and uses this to access certain settings. Because ForgeInspector is required to
be immutable, but ForgeInspectorConfig is not, this may break things. ForgeInspector should *defensively copy* any settings it needs at construction time.
2. ForgeInspectorConfig has a getProject method that doesn't appear to be used?
3. ForgeInspectionResultProcessor has a setProject method. Again, this breaks immutability. Also, it doesn't appear to be used?
Thanks for letting me know about your vacation. Have fun! I've copied the
dev list, because this should be discussed openly among all the community :)
Answers in line:
What methods should the GitFacet implement (or at least provide stubs for)
> for the FORGE-183 to get accepted?
I'll answer this with another question: "what is the minimal set of Git
operations that will make it useful?" We can always expand later. So I'd
suggest starting with the bare minimum.
Should GitUtils be a part of FORGE-183 as well?
Not sure what you mean? If you need to make changes to GitUtils to
implement FORGE-183, then sure, that's fine.
What methods should I add in there (everything from Git)?
Start with the basics. I recommend starting with what you think is
necessary to implement the UNDO features :)
> In the mailing list I identified 5 methods. Can I use GitUtils class which
> is already present in the project? (
Yes, that would be my suggestion.
If I add all the methods needed for the undo plugin (about 15),
> wouldn't it be a pretty big commit for a single JIRA issue?
Size of commit is not really important as long as the JIRA issue is clear.
If you think the Issue is too vague, then feel free to split it into
several issues. Do you have permissions to edit and create JIRA issues? If
not, let me know and I will grant it to you.
Thanks~! Good questions! Always ask :)