2.1.x Branch created
by Max Rydahl Andersen
Hi,
In case you missed it in the svn commit logs a branch where created for 2.1.x and CR1 was tagged.
That means if something needs to go into the final 2.1 you need to commit it in the branch too.
Please make sure when you resolve in jira you set the right fix versions! (tip: you can select multiple with Ctrl key ;)
/max
15 years, 11 months
Fix to the build problem
by Rob Stryker
Max:
The fix was simply that we required both patches in order to make it work.
Marshall is on it. I'm going to comment on the eclipse bug.
- Rob
15 years, 12 months
Export/Import Runtime/Servers?
by Galder Zamarreno
Hi,
Given a JBDS workspace, can Runtime/Servers be imported/exported in case
you need to rebuild your workspace?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years
Re: State of SVN and build
by Max Rydahl Andersen
cc'ed on to jbosstools-dev where this belongs ;)
> Since this release is moving forward, I figured while we all wait for
> builds and prepare our next set of goals, we should take a quick look at
> the state of our svn and how it relates to our builds.
>
> I'm going to suggest something, and fully expect to get shot down, which
> is fine ;) But since I'm just sitting here waiting for the ganymede
> branch to check out, I think it's a fine use of my time.
>
> It seems we have several types of branches, in a general sense. Some of
> them are temporary branches where someone is working on something at
> their leisure. An example of this branch would be before_xulrunner, or
> ganymede, which then had to be merged back in eventually (or not, up to
> the brancher obviously). The second type is actual release branches...
> such as jbosstools-2.1.x. These are for release and *must* be kept around.
>
> The third, arguably, which may not exist yet, would be individual
> component branches for releases / maintenance. Let's not forget one of
> the promises of the productization of the product was to allow
> individual components to move forward as they want. I'll tackle this
> type later. For now, let's just accept that this type could (possibly)
> exist.
>
> The first thing I notice is that the "branches" section of our svn has
> no sub-directories for type of branch. Now perhaps this is by design,
> and standard, but I think it would be prudent to have three primary
> subdirectories to "branches", specifically:
> - temporary / working / toBeMerged / some other name
> - releases
> - components
>
> All of the individual branches could then be shoved into one of these
> three folders. In this way, our branch section would be much cleaner. We
> would easily be able to get rid of branches that are outdated or clearly
> temporary. Rather than just having one big "branches" folder with all
> sorts of garbage thrown in, it would bring a sense of order to the madness.
>
> ** Obviously any change in this structure would require a similar change
> of the appropriate properties in the build.
>
> The next question I have, though, relates to how build and svn interact.
> As of now, it would be impossible for me to make my HEAD / TRUNK for
> ASTools use ganymede without breaking the build (assuming every other
> plugin stays behind using the older plugins). I would argue that this
> is a bad situation. I would argue that I should be able to make my
> bleeding-edge code use something brand new while my component's
> contribution to JBoss Tools (and nightly builds) is still the old branch
> / tag.
>
> For example, I've known for over a month now that there were severe
> changes to the Server Tools actions in ganymede, but I was unable to do
> anything to fix it because I wasn't able to focus my main development
> forward on that stream. My nightly build contributions would be sucked
> into the JBDS and JBossTools tags, and then the fact that JBDS was using
> wtp 2.x and I was using 3.x would cause errors.
>
> If this is by design, and we want it this way to keep us all on track
> and on the same page, I can completely understand. However it was my
> understanding that JBoss Tools would allow for individual releases of
> the components and individual components to move forward bleeding edge
> if they wanted.
>
> Any input here is welcome. Below is a list of branches and how I think I
> would organize them if SVN were to be re-worked a bit.
>
> - Rob Stryker
> --------
>
> branches
> |- temporary
> |- before_xulrunner
> |- jbosstools_xulrunner
> |- before-eclipse-3.3
> |- ganymede
> |- jboss
> |- JBW_BERLIN_2006_BRANCH
> |- REWRITE_2007_16_4
> |- release
> |- jbosstools-2.0.x
> |- jbosstools-2.1.x
> |- TOOLS_3_1_0_BETA4_branch
> |- TOOLS_3_1_0_BETA5a_branch
> |- components
> |- IDE_AOP_DEVELOPER_1_1_2_branch
> |- IDE_CORE_1_6_0_branch
> |- IDE_EJB3_TOOLS_1_0_2_branch
> |- IDE_RELENG_ECLIPSE31
> |- IDE_TESTS_ECLIPSE31
>
>
16 years
Re: State of SVN and build
by Max Rydahl Andersen
forgot to cc jbosstools-dev
>>> Please don't.
>>>
>>> Wether you do your new development in a new branch or in head makes
>>> zero extra work for you - but if trunk becomes inconsistent it gives
>>> alot of extra work to everyone working across the projects (which
>>> most of us do)
>>>
>>
>> But it could cause problems *not* to. What if I want to make an
>> out-of-sync release of just my tools for some higher build drivers? If I
>> were to make a release, wouldn't it be reasonable for the user to expect
>> that *that* work is in trunk and not in a branch?
>
> eeh no...why ? That component would be "out-of-the-ordinary" as it is now.
>
> How many of the components in JBT do you see doing more releases than we do
> now with JBT (on different drivers ?)
>
>> Not that I genuinely see myself as that ambitious, but, one of the
>> promises was that we'd be able to make out of sync releases, those that
>> don't time up with the product. If I were to push forward on ganymede
>> and make a release tomorrow (obviously hypoethetical) and people
>> downloaded it and wanted to view the code, it's reasonable for them to
>> expect the newest release on the newest drivers is being done in the
>> main trunk.
>>
>> Or is this a wrong assumption?
>
> It is the common assumption, but the same could be said about JBossTools.
>
> And my point is that we can have easy checkouts for both scenarios with
> equal amount of work if we keep jbt in trunk and spinoffs in branches -
> if we keep trunk in "sync"
>
> Note: we could also go the other way and create a jbt-trunk which everyone
> would work from except you (or other components that want to do spinoff releases)
> ...but I don't really see the advantage of this added complexity.
>
> Note: If we were only doing releaes every year or had alot more people working in N different directions, then sure - we would have to do this.
> But that is not what we are doing is it ?
>
> /max
>
>
>
>
>
16 years
Re: 2.1.x Branch created
by Marshall Culpepper
We use a tag from branch. If you have fixes to make, you'll need to make
them on the 2.1.x branch, and then notify me so we can re-tag if necessary
Snjezana Peco wrote:
> Max,
>
> Do JBDS builds use the branch or head?
> I am planing to add a simple temporary test to check errors in the
> hibernate tests, but I am not sure where to commit it.
>
> Snjeza
>
> Max Rydahl Andersen wrote:
>> Hi,
>>
>> In case you missed it in the svn commit logs a branch where created
>> for 2.1.x and CR1 was tagged.
>>
>> That means if something needs to go into the final 2.1 you need to
>> commit it in the branch too.
>>
>> Please make sure when you resolve in jira you set the right fix
>> versions! (tip: you can select multiple with Ctrl key ;)
>>
>> /max
>>
>>
>
16 years
QA Daily report 28 April 2008
by Aliaksey Nis
Hello Denis,
This is Daily QA report for 28 April 2008.
Tasks performed:
1. Free testing of JBDS 2.1.0-beta1 build.
2. VPE testing.
3. Issues verification.
4. Testcases updating.
--
Best regards,
Aliaksey mailto:anis@exadel.com
16 years
