1: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."