12:05 p.m.
Hi guys,
This is for everyone who has a local clone of the
http://github.com/forge/jbosstools-forge. Because of a simultaneous change done by Nick
Boldt in the jbosstools repo (http://github.com/jbosstools/jbosstools-forge) I needed to
perform a forced push. You will have to do a 'git fetch --all' and then a 'git
reset --hard remote_name/master' to be synchronized again.
Sorry for the inconvenience.
Cheers,
Koen
2:55 p.m.
On Tue, Apr 09, 2013 at 12:05:47PM +0200, Koen Aers wrote:
Hi guys,
This is for everyone who has a local clone of the
http://github.com/forge/jbosstools-forge. Because of a simultaneous change done by Nick
Boldt in the jbosstools repo (http://github.com/jbosstools/jbosstools-forge) I needed to
perform a forced push. You will have to do a 'git fetch --all' and then a 'git
reset --hard remote_name/master' to be synchronized again.
What kind of change caused that ? I only see the commit I pushed based on Denis Golovin
patch on jbosstools-forge:
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
Could I have done something differently and we could have avoided that merge ? (I needed
the fix in since otherwise jbosstools-forge was not building)
/max
Sorry for the inconvenience.
Cheers,
Koen
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4:15 p.m.
What kind of change caused that ? I only see the commit I pushed based on Denis Golovin
patch on jbosstools-forge:
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
Could I have done something differently and we could have avoided that merge ? (I needed
the fix in since otherwise jbosstools-forge was not building)
It is indeed because of Denis Golovin's patch and not Nick Boldt. Lincoln had removed
all the .classpath and .project files in one of the commits on the master branch in the
fork that is in the forge organization and those two changes were in conflict.
And no, I don't think you could have done anything else. Usually I merge the changes
in the forge fork immediately in the jbosstools organization but this time there was a
rather big change implying an upload of a lot of jar files in the repo which I was
uncomfortable with. George fixed this by creating a Maven plugin that is able to pull in
the jars at build time instead.
Cheers,
Koen
2:26 p.m.
On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>
> What kind of change caused that ? I only see the commit I pushed based on Denis
Golovin patch on jbosstools-forge:
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>
> Could I have done something differently and we could have avoided that merge ? (I
needed the fix in since otherwise jbosstools-forge was not building)
It is indeed because of Denis Golovin's patch and not Nick Boldt. Lincoln had removed
all the .classpath and .project files in one of the commits on the master branch in the
fork that is in the forge organization and those two changes were in conflict.
Okey - yes, I know we can use maven to import but its much faster if .project/.classpath
files are present.
And no, I don't think you could have done anything else. Usually I
merge the changes in the forge fork immediately in the jbosstools organization but this
time there was a rather big change implying an upload of a lot of jar files in the repo
which I was uncomfortable with. George fixed this by creating a Maven plugin that is able
to pull in the jars at build time instead.
oh yes - jars available from maven repo should be done like you already do with forge 1
runtime.
What jars is this btw ? I thought we got Forge 2 runtime setup properly during Miami ?
/max
Cheers,
Koen
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4:20 p.m.
Why would removing .project and .classpath be an issue? These files cause
problems and inconsistencies when importing into different environments, or
even when simply updating maven dependencies of a bundle.
On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen <manderse(a)redhat.com>wrote:
On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>
>>
>> What kind of change caused that ? I only see the commit I pushed based
on Denis Golovin patch on jbosstools-forge:
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>>
>> Could I have done something differently and we could have avoided that
merge ? (I needed the fix in since otherwise jbosstools-forge was not
building)
>
>It is indeed because of Denis Golovin's patch and not Nick Boldt. Lincoln
had removed all the .classpath and .project files in one of the commits on
the master branch in the fork that is in the forge organization and those
two changes were in conflict.
Okey - yes, I know we can use maven to import but its much faster if
.project/.classpath files are present.
>And no, I don't think you could have done anything else. Usually I merge
the changes in the forge fork immediately in the jbosstools organization
but this time there was a rather big change implying an upload of a lot of
jar files in the repo which I was uncomfortable with. George fixed this by
creating a Maven plugin that is able to pull in the jars at build time
instead.
oh yes - jars available from maven repo should be done like you already do
with forge 1 runtime.
What jars is this btw ? I thought we got Forge 2 runtime setup properly
during Miami ?
/max
>Cheers,
>Koen
>
>
>
>
>_______________________________________________
>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."
4:39 p.m.
Max, faster in what sense ? Project import ? If so I think that's
irrelevant due to the benefits Lincoln described before.
On 04/10/2013 11:20 AM, Lincoln Baxter, III wrote:
Why would removing .project and .classpath be an issue? These files
cause problems and inconsistencies when importing into different
environments, or even when simply updating maven dependencies of a bundle.
On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen
<manderse(a)redhat.com <mailto:manderse@redhat.com>> wrote:
On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>
>>
>> What kind of change caused that ? I only see the commit I
pushed based on Denis Golovin patch on jbosstools-forge:
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>>
>> Could I have done something differently and we could have
avoided that merge ? (I needed the fix in since otherwise
jbosstools-forge was not building)
>
>It is indeed because of Denis Golovin's patch and not Nick Boldt.
Lincoln had removed all the .classpath and .project files in one
of the commits on the master branch in the fork that is in the
forge organization and those two changes were in conflict.
Okey - yes, I know we can use maven to import but its much faster
if .project/.classpath files are present.
>And no, I don't think you could have done anything else. Usually
I merge the changes in the forge fork immediately in the
jbosstools organization but this time there was a rather big
change implying an upload of a lot of jar files in the repo which
I was uncomfortable with. George fixed this by creating a Maven
plugin that is able to pull in the jars at build time instead.
oh yes - jars available from maven repo should be done like you
already do with forge 1 runtime.
What jars is this btw ? I thought we got Forge 2 runtime setup
properly during Miami ?
/max
>Cheers,
>Koen
>
>
>
>
>_______________________________________________
>forge-dev mailing list
>forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
>https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
*George Gastaldi* | /Senior Software Engineer/
JBoss Forge Team
Red Hat
4:46 p.m.
As a member of the peanut gallery, I would add my vote to the mix that, in
general, it's very nice to have your IDE config and your external build
process described by the same metadata (namely, pom.xml).
Matt
On Wed, Apr 10, 2013 at 9:39 AM, <ggastald(a)redhat.com> wrote:
Max, faster in what sense ? Project import ? If so I think
that's
irrelevant due to the benefits Lincoln described before.
On 04/10/2013 11:20 AM, Lincoln Baxter, III wrote:
Why would removing .project and .classpath be an issue? These files cause
problems and inconsistencies when importing into different environments, or
even when simply updating maven dependencies of a bundle.
On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen <manderse(a)redhat.com>wrote:
> On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
> >
> >>
> >> What kind of change caused that ? I only see the commit I pushed based
> on Denis Golovin patch on jbosstools-forge:
>
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
> >>
> >> Could I have done something differently and we could have avoided that
> merge ? (I needed the fix in since otherwise jbosstools-forge was not
> building)
> >
> >It is indeed because of Denis Golovin's patch and not Nick Boldt.
> Lincoln had removed all the .classpath and .project files in one of the
> commits on the master branch in the fork that is in the forge organization
> and those two changes were in conflict.
>
> Okey - yes, I know we can use maven to import but its much faster if
> .project/.classpath files are present.
>
> >And no, I don't think you could have done anything else. Usually I merge
> the changes in the forge fork immediately in the jbosstools organization
> but this time there was a rather big change implying an upload of a lot of
> jar files in the repo which I was uncomfortable with. George fixed this by
> creating a Maven plugin that is able to pull in the jars at build time
> instead.
>
> oh yes - jars available from maven repo should be done like you already
> do with forge 1 runtime.
>
> What jars is this btw ? I thought we got Forge 2 runtime setup properly
> during Miami ?
>
> /max
>
> >Cheers,
> >Koen
> >
> >
> >
> >
> >_______________________________________________
> >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."
_______________________________________________
forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
--
*George Gastaldi* | *Senior Software Engineer*
JBoss Forge Team
Red Hat
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
11:14 p.m.
Thanks for the nuts! :D
On Wed, Apr 10, 2013 at 10:46 AM, Matt Benson <gudnabrsam(a)gmail.com> wrote:
As a member of the peanut gallery, I would add my vote to the mix
that, in
general, it's very nice to have your IDE config and your external build
process described by the same metadata (namely, pom.xml).
Matt
On Wed, Apr 10, 2013 at 9:39 AM, <ggastald(a)redhat.com> wrote:
> Max, faster in what sense ? Project import ? If so I think that's
> irrelevant due to the benefits Lincoln described before.
>
>
> On 04/10/2013 11:20 AM, Lincoln Baxter, III wrote:
>
> Why would removing .project and .classpath be an issue? These files cause
> problems and inconsistencies when importing into different environments, or
> even when simply updating maven dependencies of a bundle.
>
>
> On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen <manderse(a)redhat.com
> > wrote:
>
>> On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>> >
>> >>
>> >> What kind of change caused that ? I only see the commit I pushed
>> based on Denis Golovin patch on jbosstools-forge:
>>
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>> >>
>> >> Could I have done something differently and we could have avoided
>> that merge ? (I needed the fix in since otherwise jbosstools-forge was not
>> building)
>> >
>> >It is indeed because of Denis Golovin's patch and not Nick Boldt.
>> Lincoln had removed all the .classpath and .project files in one of the
>> commits on the master branch in the fork that is in the forge organization
>> and those two changes were in conflict.
>>
>> Okey - yes, I know we can use maven to import but its much faster if
>> .project/.classpath files are present.
>>
>> >And no, I don't think you could have done anything else. Usually I
>> merge the changes in the forge fork immediately in the jbosstools
>> organization but this time there was a rather big change implying an upload
>> of a lot of jar files in the repo which I was uncomfortable with. George
>> fixed this by creating a Maven plugin that is able to pull in the jars at
>> build time instead.
>>
>> oh yes - jars available from maven repo should be done like you already
>> do with forge 1 runtime.
>>
>> What jars is this btw ? I thought we got Forge 2 runtime setup properly
>> during Miami ?
>>
>> /max
>>
>> >Cheers,
>> >Koen
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >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."
>
>
> _______________________________________________
> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> --
> *George Gastaldi* | *Senior Software Engineer*
> JBoss Forge Team
> Red Hat
>
> _______________________________________________
> 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."
6:33 p.m.
On Wed, Apr 10, 2013 at 10:20:16AM -0400, Lincoln Baxter, III wrote:
Why would removing .project and .classpath be an issue? These files
cause
problems and inconsistencies when importing into different environments, or
even when simply updating maven dependencies of a bundle.
it means you can no longer just do File > Import existing projects
Which is much faster.
Of course if your plugins now are 100% coupled to m2e that is a burden.
But generally we keep those files uptodate so you are not forced to use m2e in eclipse
(since for 99% of our plugins no maven is needed besides when running from cmd line)
/max
On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen <manderse(a)redhat.com>wrote:
> On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
> >
> >>
> >> What kind of change caused that ? I only see the commit I pushed based
> on Denis Golovin patch on jbosstools-forge:
>
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
> >>
> >> Could I have done something differently and we could have avoided that
> merge ? (I needed the fix in since otherwise jbosstools-forge was not
> building)
> >
> >It is indeed because of Denis Golovin's patch and not Nick Boldt. Lincoln
> had removed all the .classpath and .project files in one of the commits on
> the master branch in the fork that is in the forge organization and those
> two changes were in conflict.
>
> Okey - yes, I know we can use maven to import but its much faster if
> .project/.classpath files are present.
>
> >And no, I don't think you could have done anything else. Usually I merge
> the changes in the forge fork immediately in the jbosstools organization
> but this time there was a rather big change implying an upload of a lot of
> jar files in the repo which I was uncomfortable with. George fixed this by
> creating a Maven plugin that is able to pull in the jars at build time
> instead.
>
> oh yes - jars available from maven repo should be done like you already do
> with forge 1 runtime.
>
> What jars is this btw ? I thought we got Forge 2 runtime setup properly
> during Miami ?
>
> /max
>
> >Cheers,
> >Koen
> >
> >
> >
> >
> >_______________________________________________
> >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."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
6:34 p.m.
On Wed, Apr 10, 2013 at 09:46:05AM -0500, Matt Benson wrote:
As a member of the peanut gallery, I would add my vote to the mix
that, in
general, it's very nice to have your IDE config and your external build
process described by the same metadata (namely, pom.xml).
it is - these files are updated when you import with maven and you then refresh them.
And yes, I generally do not recommend committing these files to your projects
but in case of eclipse plugins in large projects file import existing is much faster
than letting m2e import it.
/max
Matt
On Wed, Apr 10, 2013 at 9:39 AM, <ggastald(a)redhat.com> wrote:
> Max, faster in what sense ? Project import ? If so I think that's
> irrelevant due to the benefits Lincoln described before.
>
>
> On 04/10/2013 11:20 AM, Lincoln Baxter, III wrote:
>
> Why would removing .project and .classpath be an issue? These files cause
> problems and inconsistencies when importing into different environments, or
> even when simply updating maven dependencies of a bundle.
>
>
> On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen
<manderse(a)redhat.com>wrote:
>
>> On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>> >
>> >>
>> >> What kind of change caused that ? I only see the commit I pushed based
>> on Denis Golovin patch on jbosstools-forge:
>>
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>> >>
>> >> Could I have done something differently and we could have avoided that
>> merge ? (I needed the fix in since otherwise jbosstools-forge was not
>> building)
>> >
>> >It is indeed because of Denis Golovin's patch and not Nick Boldt.
>> Lincoln had removed all the .classpath and .project files in one of the
>> commits on the master branch in the fork that is in the forge organization
>> and those two changes were in conflict.
>>
>> Okey - yes, I know we can use maven to import but its much faster if
>> .project/.classpath files are present.
>>
>> >And no, I don't think you could have done anything else. Usually I merge
>> the changes in the forge fork immediately in the jbosstools organization
>> but this time there was a rather big change implying an upload of a lot of
>> jar files in the repo which I was uncomfortable with. George fixed this by
>> creating a Maven plugin that is able to pull in the jars at build time
>> instead.
>>
>> oh yes - jars available from maven repo should be done like you already
>> do with forge 1 runtime.
>>
>> What jars is this btw ? I thought we got Forge 2 runtime setup properly
>> during Miami ?
>>
>> /max
>>
>> >Cheers,
>> >Koen
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >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."
>
>
> _______________________________________________
> forge-dev mailing
listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> --
> *George Gastaldi* | *Senior Software Engineer*
> JBoss Forge Team
> Red Hat
>
> _______________________________________________
> 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
8:21 p.m.
Sure, but since they are built with Maven I think is safe to let it do its
job :) I'll even go so far as to say that it is preferred, since you will
much more quickly find errors and inconsistencies that might otherwise have
eluded you, particularly if developing something that has frequent
dependency changes (like a prototype Forge 2 :)
Anyway, no point to debate this. Just a matter of preference it sounds like.
On Thu, Apr 11, 2013 at 12:33 PM, Max Rydahl Andersen
<manderse(a)redhat.com>wrote:
On Wed, Apr 10, 2013 at 10:20:16AM -0400, Lincoln Baxter, III wrote:
>Why would removing .project and .classpath be an issue? These files cause
>problems and inconsistencies when importing into different environments,
or
>even when simply updating maven dependencies of a bundle.
it means you can no longer just do File > Import existing projects
Which is much faster.
Of course if your plugins now are 100% coupled to m2e that is a burden.
But generally we keep those files uptodate so you are not forced to use
m2e in eclipse
(since for 99% of our plugins no maven is needed besides when running from
cmd line)
/max
>
>On Wed, Apr 10, 2013 at 8:26 AM, Max Rydahl Andersen <manderse(a)redhat.com
>wrote:
>
>> On Tue, Apr 09, 2013 at 04:15:27PM +0200, Koen Aers wrote:
>> >
>> >>
>> >> What kind of change caused that ? I only see the commit I pushed
based
>> on Denis Golovin patch on jbosstools-forge:
>>
https://github.com/jbosstools/jbosstools-forge/commit/a47e8b7fb2c2739c66f...
>> >>
>> >> Could I have done something differently and we could have avoided
that
>> merge ? (I needed the fix in since otherwise jbosstools-forge was not
>> building)
>> >
>> >It is indeed because of Denis Golovin's patch and not Nick Boldt.
Lincoln
>> had removed all the .classpath and .project files in one of the commits
on
>> the master branch in the fork that is in the forge organization and
those
>> two changes were in conflict.
>>
>> Okey - yes, I know we can use maven to import but its much faster if
>> .project/.classpath files are present.
>>
>> >And no, I don't think you could have done anything else. Usually I
merge
>> the changes in the forge fork immediately in the jbosstools organization
>> but this time there was a rather big change implying an upload of a lot
of
>> jar files in the repo which I was uncomfortable with. George fixed this
by
>> creating a Maven plugin that is able to pull in the jars at build time
>> instead.
>>
>> oh yes - jars available from maven repo should be done like you already
do
>> with forge 1 runtime.
>>
>> What jars is this btw ? I thought we got Forge 2 runtime setup properly
>> during Miami ?
>>
>> /max
>>
>> >Cheers,
>> >Koen
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >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."
>_______________________________________________
>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."
4028
days inactive
4035
days old
10 comments
5 participants
participants (5)
-
ggastald＠redhat.com -
Koen Aers -
Lincoln Baxter, III -
Matt Benson -
Max Rydahl Andersen