[forge-dev] jbosstools-forge

[Lincoln Baxter, III]

Thanks for the nuts! :D


On Wed, Apr 10, 2013 at 10:46 AM, Matt Benson <gudnabrsam at 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 at 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 at 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/a47e8b7fb2c2739c66f917eb8f3fa1f0ae939e70
>>> >>
>>> >> 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 at lists.jboss.org
>>> >https://lists.jboss.org/mailman/listinfo/forge-dev
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130410/dc213e3c/attachment.html