This means you can - *in theory* - build the parent pom (and target
platform) [3] or grab it from Nexus [4] (if we decide to keep deploying
stuff there?), check out a component's sources from github, and build
that component against upstream eclipse deps + upstream previously-built
JBT components.
where would the (aggregated?) upstream of jboss tools live ? (not together with the base
targetplatform I assume)
/max
In other words... I think moving to github, one component at a time, MAY
BE VIABLE, but there's still a lot of testing left to do to validate
this theory.
[1]
http://download.jboss.org/jbosstools/updates/indigo/
[2]
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
[3]
http://anonsvn.jboss.org/repos/jbosstools/branches/3.3.indigo/build/
[4]
http://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/
N
On 03/07/2011 10:39 AM, Max Rydahl Andersen wrote:
>
>> +1 for git.
>>
>> Work with svn is very slow and disk-consuming and I have still issues 'svn
>> up', it still needs cleanup, or refuses to update. I started to hate svn,
>> please unschackle me :-)
>
> Btw. Nick and I had a chat the other day about what actually prevent us from moving
and
> if it was just a question about git vs svn then we could easily move (assuming
windows users
> are fine with using bash/cygwin)
>
> The challenge is that hudson+git is not as flexible as it currently is with svn and
we don't yet
> have a good use of having our builds pick up latest/matching dependencies from a
repository -
> thus not trivial to move away from git fully :(
>
> Will require a lot of effort.
>
> /max
>
>
>>
>> Libor
>> On Mon, 28 Feb 2011 18:54:34 +0100, Max Rydahl Andersen
>> <max.andersen(a)redhat.com> wrote:
>>
>>> Hey,
>>>
>>> We got our svn mirror now but after working with it a bit its basically
>>> just as slow as normal svn (if you can get it to work).
>>>
>>> ...thus i'm wondering if anyone can come up with good reasons to *not*
>>> just move all new development over to git and simply kill off
>>> the SVN completely for our jbosstools trunk development ?
>>>
>>> 3.2.x would stay in SVN.
>>>
>>> Comments/Suggestions/Screams/Objections ?
>>>
>>> /max
>>>
http://about.me/maxandersen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> /max
>
http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Eclipse Modeling & Dash Athena
http://nick.divbyzero.com
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev