New JBoss DNA forums
by Randall Hauch
Hot on the heals of an upgrade and overhaul of our project site, the JBoss.org site has completed a migration of its forums. Not only are the forums much better, but it boasts a ton of new features and capabilities, including integration with the wiki.
Check out the new forum for JBoss DNA, and don't forget to update your bookmarks. And thanks to the JBoss.org team for continually improving our infrastructure!
Best regards,
Randall
14 years, 5 months
Re: [dna-dev] dna-dev Digest, Vol 21, Issue 10
by Serge Emmanuel Pagop
Hello together,
may be a change to Git is a great idea, but we need to know how quickly a developer can work with Git and eclipse. Because I know that for SVN there are a lot SVN plugins, that can be use with eclipse.
Or may be we can wait for a stable great eclipse Git plugin.
Cheers,
Serge.
-------
|||| Serge Emmanuel Pagop
|||| IT Senior Consultant
||||
||||
|||| innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
||||
|||| Business mobile: +49 178 4049592,
|||| Business Fax: +49 2102 77160-1,
|||| Business E-Mail: serge.pagop(a)innoq.com,
|||| Private E-Mail: serge.pagop(a)googlemail.com
|||| Web: http://www.innoq.com,
|||| Weblog: http://www.innoq.com/blog/sp,
|||| JBUG Munich: http://www.jbug-munich.org
On Dec 9, 2009, at 6:00 PM, dna-dev-request(a)lists.jboss.org wrote:
> Send dna-dev mailing list submissions to
> dna-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/dna-dev
> or, via email, send a message with subject or body 'help' to
> dna-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> dna-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dna-dev digest..."
>
>
> Today's Topics:
>
> 1. DNA nightly integration on JDK1.5 - Build # 609 - Still
> Unstable! (jboss-qa-internal(a)redhat.com)
> 2. Re: Version control poll (Brian Carothers)
> 3. Re: Version control poll (Randall Hauch)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 9 Dec 2009 02:16:13 -0500 (EST)
> From: jboss-qa-internal(a)redhat.com
> Subject: [dna-dev] DNA nightly integration on JDK1.5 - Build # 609 -
> Still Unstable!
> To: dna-dev(a)lists.jboss.org, rhauch(a)gmail.com
> Message-ID:
> <693109249.4141260342973772.JavaMail.hudson(a)soa8.qa.atl2.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> DNA nightly integration on JDK1.5 - Build # 609 - Still Unstable:
>
> Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20nightly%20integration%20on%20... to view the results.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 9 Dec 2009 07:03:59 -0600
> From: Brian Carothers <brian.carothers(a)amentra.com>
> Subject: Re: [dna-dev] Version control poll
> To: JBoss DNA <dna-dev(a)lists.jboss.org>
> Message-ID:
> <3E8F2B0F635FDE4CBEC121E3F3A2373A010F0CD3DB(a)AUSP01VMBX09.collaborationhost.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Comments inline.
>
>> -----Original Message-----
>> From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
>> Sent: Tuesday, December 08, 2009 2:47 PM
>> To: JBoss DNA
>> Subject: [dna-dev] Version control poll
>>
>> Personally, I've been using Git locally for many months, and couldn't
>> imagine going back. I simply love the ability to have local branches
>> (that are almost always named for the JIRA issue) and to switch between
>> them very easily. And I'm not even benefiting from the ability to push
>> these branches out anywhere else. The Git Eclipse plugin works very well
>> for me, but I'm very used to the command-line and don't expect much from
>> my Eclipse Team UI functionality anymore. (I really just want Eclipse to
>> tell me which files are changed locally, which the plugin does very well -
>> everything else I use the command line for because its far easier IMO.)
>
> There were several times this year when I was working on multiple issues simultaneously (or had completed 1-2 issues pending review and had started on another). I ended up having to create patches and revert as I shifted between issues or only work on issues that affected completely different sets of files (e.g., one connector-layer issue and one JCR-layer issue) and remember which was which.
>
> I broke the build many times because I fouled up this process.
>
> In theory, Git would make this much easier, right?
>
>> However, I do have several concerns. One of them is whether this raises
>> or lowers the bar for people downloading the source, submitting patches,
>> or for becoming new committers.
>
> I think it will. Had this project been git-only a year ago, I probably never would have gotten involved. It's not that git is bad or that learning git is hard, it's just one more bit of inertia to overcome.
>
>> For people that only have SVN experience,
>> I think this will dramatically raise the bar because Git will be a big
>> unknown for them. On the other hand, Git is becoming extremely popular
>> and used on a lot of projects, so while this might be the norm now, I
>> don't expect it will be in a year.
>
> Then, IMHO, we should move to Git in a year and let other projects train people, develop best practices, and support tooling improvements. IMHO, I think we should be focused on advancing the state-of-the-art in federating data sources, not in build processes.
>
>> For people that do know Git, our using
>> Git would actually _lower_ the bar for their submitting patches, because
>> they can create a patch on their own Git repository (or if that's not
>> accessible then on a site like GitHub) and give us a URL, where we can
>> pull it in to review and possibly commit.
>
> I think that the set of people who know Git, know Java, and might submit a DNA patch is a very small one right now. I think the set of people who might build from trunk right now (a prereq for creating a patch) but wouldn't bother if it meant they had to install and learn Git is a larger set.
>
> But that's right now. I wouldn't be shocked if things were different by this time next year.
>
>> Another concern is what the Git experience is on Windows, which I can't
>> evaluate. The Git experience is pretty much the same on OS X, Unix, and
>> Linux mostly because command-line support is so similar. But while
>> Windows has very different command-line support, it does seem that msysgit
>> (http://code.google.com/p/msysgit/) gets around that issue pretty well.
>> I'd love to hear about your experience with Git on Windows, though.
>
> I'll try this out post-0.7 and let you know.
>
>> One concern I have had in the past was whether our Hudson continuous
>> integration system will support Git. I happy to say that a Git plugin for
>> Hudson has been available for some time, that our Hudson team have a test
>> environment where they've install it, and I will be creating some test
>> jobs for them. So while this still is an issue, it shouldn't be within a
>> few weeks of the New Year (or sooner if I can find the time).
>
> Why would we want to be the guinea pig for this? :-)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 9 Dec 2009 09:04:45 -0600
> From: Randall Hauch <rhauch(a)redhat.com>
> Subject: Re: [dna-dev] Version control poll
> To: Brian Carothers <brian.carothers(a)amentra.com>, JBoss DNA
> <dna-dev(a)lists.jboss.org>
> Message-ID: <95DDA177-1A76-4941-82B6-9D2BDE38B6F7(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Dec 9, 2009, at 7:03 AM, Brian Carothers wrote:
>
>> Comments inline.
>>
>>> -----Original Message-----
>>> From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
>>> bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
>>> Sent: Tuesday, December 08, 2009 2:47 PM
>>> To: JBoss DNA
>>> Subject: [dna-dev] Version control poll
>>>
>>> Personally, I've been using Git locally for many months, and couldn't
>>> imagine going back. I simply love the ability to have local branches
>>> (that are almost always named for the JIRA issue) and to switch between
>>> them very easily. And I'm not even benefiting from the ability to push
>>> these branches out anywhere else. The Git Eclipse plugin works very well
>>> for me, but I'm very used to the command-line and don't expect much from
>>> my Eclipse Team UI functionality anymore. (I really just want Eclipse to
>>> tell me which files are changed locally, which the plugin does very well -
>>> everything else I use the command line for because its far easier IMO.)
>>
>> There were several times this year when I was working on multiple issues simultaneously (or had completed 1-2 issues pending review and had started on another). I ended up having to create patches and revert as I shifted between issues or only work on issues that affected completely different sets of files (e.g., one connector-layer issue and one JCR-layer issue) and remember which was which.
>>
>> I broke the build many times because I fouled up this process.
>>
>> In theory, Git would make this much easier, right?
>
> Every day (literally!) I switch branches to work on something else, without ever creating a patch. (Git has the uber-handy 'stash', but that's only needed if you're not ready to commit your changes locally.) Sometimes I do this multiple times. Oh, and I get version control on all my branches, and Git does help merge changes between different branches. So for example, if you fix an error on one branch (that hasn't yet been pushed to trunk), you can pull that change (or all the changes on that branch) into your branch with a simple merge.
>
> Git-SVN provides this functionality locally. But that's a still nowhere near what using Git all 'round will give you. Right now, if I needed a fix that you have locally, I would need to get a patch (even if we were both using Git-SVN locally). If we were using Git all 'round, we'd still push commits on our branches to a shared Git (and merge them onto the 'trunk' branch (we'd probably use a branch name that corresponded to the release effort), but I could very easily pull in some or all of your changes in my branch. Easy-peasy.
>
>>
>>> However, I do have several concerns. One of them is whether this raises
>>> or lowers the bar for people downloading the source, submitting patches,
>>> or for becoming new committers.
>>
>> I think it will. Had this project been git-only a year ago, I probably never would have gotten involved. It's not that git is bad or that learning git is hard, it's just one more bit of inertia to overcome.
>
> I'd probably agree with you. A year ago, Git didn't have nearly the uptake that it does have now. Today, I think the "standard" for new projects is either Git or Mercurial.
>
>>
>>> For people that only have SVN experience,
>>> I think this will dramatically raise the bar because Git will be a big
>>> unknown for them. On the other hand, Git is becoming extremely popular
>>> and used on a lot of projects, so while this might be the norm now, I
>>> don't expect it will be in a year.
>>
>> Then, IMHO, we should move to Git in a year and let other projects train people, develop best practices, and support tooling improvements. IMHO, I think we should be focused on advancing the state-of-the-art in federating data sources, not in build processes.
>
> I don't want to switch to Git because it's cool or fun or state of the art. I want to switch because Git-SVN already makes my life an order of magnitude easier (lots of branch switching), and would be another order of magnitude if we went whole-hog Git. Yes, all the committer's processes would change, because we'd be moving to doing all work on branches, and the main release branch becomes nothing but a merge point.
>
> ...
>
>>> One concern I have had in the past was whether our Hudson continuous
>>> integration system will support Git. I happy to say that a Git plugin for
>>> Hudson has been available for some time, that our Hudson team have a test
>>> environment where they've install it, and I will be creating some test
>>> jobs for them. So while this still is an issue, it shouldn't be within a
>>> few weeks of the New Year (or sooner if I can find the time).
>>
>> Why would we want to be the guinea pig for this? :-)
>
> Because it's not much work (provide a Git repository, define a Hudson job that works like ours, and help them work out the kinks), and I'm oh-so-tired of SVN. :-)
>
>
> ------------------------------
>
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
>
>
> End of dna-dev Digest, Vol 21, Issue 10
> ***************************************
14 years, 5 months
Changes to a few of our Maven module (aka project) names
by Randall Hauch
I just committed a change (SVN r1418) that removes the 'dna-search' project and adds an 'extensions/dna-search-lucene' project. This change makes the search engine functionality more like other extensions. I also took the opportunity to refactor the search engine components so they reuse the RequestProcessor framework, which makes it better fit to be reused inside a connector implementation (to provide native search capabilities for a connector) as well as make it easier to update the indexed content based upon observed events (e.g., Changes).
Please be sure to update your development workspaces when you update SVN.
Best regards,
Randall
14 years, 5 months
