7:17 a.m.
Hi guys,
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
them? Specifically:
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?
Regards,
Richard.
3:23 p.m.
a follow up:
during cleaning up of my faces scaffold changes I also dared to change
the following:
- test-harness-web:
- upgrade to JBoss AS 7.1.1.Final, added dependencies to JUnit
and Shrinkwrap, which seemed to be missing when running the maven build
I checked the customers of WebTestImpl and only found tests in
scaffold-faces and scaffold-aerogear, both are verified still working
- dstribution pom:
added a profile to run Forge via maven to enable run/debug for
the poor/lucky guys hooked on NetBeans (which really instruments Maven :) :
mvn -P runForge exec:exec
mvn -X -P debugForge exec:exec -Ddebug.props="-Xdebug
-Xrunjdwp:transport=dt_socket,address=${jpda.port},server=y,suspend=n"
The changes may be seen at: https://shadogray@github.com/shadogray/core.git
Any objections against those changes are accepted.
Regards,
Thomas
1:23 a.m.
Hey Thomas,
Could you post the link to the GitHub diff of your changes (or submit a
pull request to show that?) Thanks!
~Lincoln
On Mon, Apr 30, 2012 at 6:23 AM, Thomas Frühbeck <fruehbeck(a)aon.at> wrote:
a follow up:
during cleaning up of my faces scaffold changes I also dared to change the
following:
- test-harness-web:
- upgrade to JBoss AS 7.1.1.Final, added dependencies to JUnit and
Shrinkwrap, which seemed to be missing when running the maven build
I checked the customers of WebTestImpl and only found tests in
scaffold-faces and scaffold-aerogear, both are verified still working
- dstribution pom:
added a profile to run Forge via maven to enable run/debug for the
poor/lucky guys hooked on NetBeans (which really instruments Maven :) :
mvn -P runForge exec:exec
mvn -X -P debugForge exec:exec -Ddebug.props="-Xdebug
-Xrunjdwp:transport=dt_socket,**address=${jpda.port},server=y,**suspend=n"
The changes may be seen at: https://shadogray@github.com/**
shadogray/core.git <https://shadogray@github.com/shadogray/core.git>
Any objections against those changes are accepted.
Regards,
Thomas
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
1:08 p.m.
Hi Lincoln,
sent the pull request, evidently it is still a bit messy regarding
indentation :-/
Its annoying, in the IDE the problems dont show - sorry about it.
Regarding PullRequests: is there some kind of "fixup" or "squash"
functionality in GitHub?
Thomas
Am 01.05.2012 01:23, schrieb Lincoln Baxter, III:
Hey Thomas,
Could you post the link to the GitHub diff of your changes (or submit
a pull request to show that?) Thanks!
~Lincoln
1:11 p.m.
Not in GitHub, but you should squash changesets with git before creating a pull request.
Paul
On May 1, 2012, at 13:08 , Thomas Frühbeck wrote:
Hi Lincoln,
sent the pull request, evidently it is still a bit messy regarding
indentation :-/
Its annoying, in the IDE the problems dont show - sorry about it.
Regarding PullRequests: is there some kind of "fixup" or "squash"
functionality in GitHub?
Thomas
Am 01.05.2012 01:23, schrieb Lincoln Baxter, III:
> Hey Thomas,
>
> Could you post the link to the GitHub diff of your changes (or submit
> a pull request to show that?) Thanks!
>
> ~Lincoln
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
10:12 p.m.
Hi Paul,
one more question regarding git(hub).
The situation is the following:
- I have clone forge core on github
- have cloned it locally
- changed some code, committed _and pushed_ into my repository on github
Is there now any possibility to "remove"/revert/delete/undo this
_commit_ - not the change itself, just to keep history cleaner when
sending pull request?
Help appreciated,
Thomas
Am 01.05.2012 13:11, schrieb Paul Bakker:
Not in GitHub, but you should squash changesets with git before
creating a pull request.
Paul
11:16 p.m.
First of all, always use a branch to create pull requests, this makes it a lot easier to
work on several things at a time without getting messy commits.
To fix your current changeset you could create a new branch from master (without your
changes) and re-apply your changes by either "cherry-picking" them or merging
your existing branch into your new branch.
Now squash commits by using interactive rebase
(http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html). You should
never do this after you pushed to a remote location, but because this is a new branch
it's perfectly fine.
When you're happy with the changeset, push the branch to your github repo, and create
a pull request from that branch. Just close the messy pull-request, it's probably
easier to start clean.
Hope that helps :-)
Paul
On May 1, 2012, at 22:12 , Thomas Frühbeck wrote:
Hi Paul,
one more question regarding git(hub).
The situation is the following:
- I have clone forge core on github
- have cloned it locally
- changed some code, committed _and pushed_ into my repository on github
Is there now any possibility to "remove"/revert/delete/undo this
_commit_ - not the change itself, just to keep history cleaner when
sending pull request?
Help appreciated,
Thomas
Am 01.05.2012 13:11, schrieb Paul Bakker:
> Not in GitHub, but you should squash changesets with git before creating a pull
request.
>
> Paul
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
1:48 a.m.
Thanks paul! I couldn't have said it better. You can also see this process
in detail in the forge contributor docs :)
http://forge.github.com/docs/get_involved/contribute.html
~Lincoln
On Tue, May 1, 2012 at 2:16 PM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
First of all, always use a branch to create pull requests, this makes
it a
lot easier to work on several things at a time without getting messy
commits.
To fix your current changeset you could create a new branch from master
(without your changes) and re-apply your changes by either "cherry-picking"
them or merging your existing branch into your new branch.
Now squash commits by using interactive rebase (
http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html).
You should never do this after you pushed to a remote location, but because
this is a new branch it's perfectly fine.
When you're happy with the changeset, push the branch to your github repo,
and create a pull request from that branch. Just close the messy
pull-request, it's probably easier to start clean.
Hope that helps :-)
Paul
On May 1, 2012, at 22:12 , Thomas Frühbeck wrote:
> Hi Paul,
>
> one more question regarding git(hub).
> The situation is the following:
> - I have clone forge core on github
> - have cloned it locally
> - changed some code, committed _and pushed_ into my repository on github
>
> Is there now any possibility to "remove"/revert/delete/undo this
> _commit_ - not the change itself, just to keep history cleaner when
> sending pull request?
>
> Help appreciated,
> Thomas
>
> Am 01.05.2012 13:11, schrieb Paul Bakker:
>> Not in GitHub, but you should squash changesets with git before
creating a pull request.
>>
>> Paul
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
4378
days inactive
4381
days old
8 comments
4 participants
participants (4)
-
Lincoln Baxter, III -
Paul Bakker -
Richard Kennard -
Thomas Frühbeck