Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ve-dev] cbi-ve-1.4-nightly-Ganymede build breakage
Turns out the correct map entry was R3_1_maintenance, not R3_0_maintenance. Build is happy again. 

https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-ve-1.4-nightly-Ganymede/
Note that we're using org.eclipse.jem.ui from R3_0_4 since it doesn't appear to exist in R3_1 or HEAD.
If the VE devs want to refactor to remove that dependency, great... but until then we will depend on this mix of sources from WTP 3.0 and 3.1. 

N

Nick Boldt wrote:
Are those plugins available on an update site or via a small runtime/sdk zip? If so I'll happily switch to depending on your binaries instead of rebuilding from source.
Thanks for the catch -- blindly changing everything to maintenance branch was clearly unwise. :) 

N
On Thu, Aug 6, 2009 at 12:15 AM, Carl Anderson <ccc@xxxxxxxxxx <mailto:ccc@xxxxxxxxxx>> wrote: 

    Nick,

    OK, so from the latest build file, the problem I see is that you
    switched the org.eclipse.jem.sdk feature and the org.eclipse.jem
    feature over to use the R3_0_maintenance tag. If you look in your
    map file, you will see that those two features are kept in the VE
    CVS repository: :pserver:*anonymous@xxxxxxxxxxxxxxx*
    <mailto:anonymous@xxxxxxxxxxxxxxx>:/cvsroot/tools,,org.eclipse.ve/features/org.eclipse.jem.sdk-feature
    <http://org.eclipse.ve/features/org.eclipse.jem.sdk-feature> . Now,
    since those are not in the webtools CVS repository, they are not
    branched to R3_0_maintenance. If you wish to continue building those
    features, you will need to restore the tag for those to HEAD.
    But, once again, I will push for the fact that rebuilding our
    plugins is not a good idea. It would be much better (and far safer)
    if VE instead pulled and compiled against the JEM plugins found in
    our R3_0_5 release.


    FWIW,

    - Carl Anderson
    WTP programmer
    Inactive hide details for Nick Boldt <nickboldt@xxxxxxxxx>Nick Boldt
    <nickboldt@xxxxxxxxx <mailto:nickboldt@xxxxxxxxx>>


                            *Nick Boldt <nickboldt@xxxxxxxxx
                            <mailto:nickboldt@xxxxxxxxx>>*

                            08/05/2009 04:22 PM

    	

    To
    	
    Discussions people developing code for the Visual Editor project
    <ve-dev@xxxxxxxxxxx <mailto:ve-dev@xxxxxxxxxxx>>

    cc
    	
    Carl Anderson/Raleigh/IBM@IBMUS, Yingmin YANG <yves.yang@xxxxxxxxxxx
    <mailto:yves.yang@xxxxxxxxxxx>>

    Subject
    	
    Re: [ve-dev] cbi-ve-1.4-nightly-Ganymede build breakage

    	


    I've switched the ve.map [1] to use R3_0_maintenance instead of HEAD
    [2]
    to test if that simple fix works, but the build's still failing [3].

    [1]http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ve/org.eclipse.ve.releng/maps/jem.map?root=Tools_Project&view=log
    <http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ve/org.eclipse.ve.releng/maps/jem.map?root=Tools_Project&view=log>

    (not yet updated in viewcvs)
    [2]https://build.eclipse.org/hudson/job/cbi-ve-1.4-nightly-Ganymede/ws/build/org.eclipse.ve.releng/maps/jem.map
    [3]https://build.eclipse.org/hudson/job/cbi-ve-1.4-nightly-Ganymede/28/console

    Can someone attach here, email me directly (nickboldt@xxxxxxxxx
    <mailto:nickboldt@xxxxxxxxx>), or
    point me at where in CVS I can find the 1.45.2.17 version of the
    jst-jem.map, so I can use those entries instead?

    Nick Boldt wrote:
     > Backstory: When I started doing the VE build a few months back, I
     > wanted to get VE building w/ whatever it took, which at the time
     > involved pulling JEM from HEAD. It was easier IMHO to rebuild JEM
     > along with VE and ship it along with VE (as it was two years ago when
     > VE 1.2 was released) than to depend on JEM binaries.
     >
     > That's where we came from. Where we go now is up to the VE
    project leadership.
     >
     > OPTION 1a:
     >
     > If we can build based on JEM binaries instead of sources, we can
     > redistribute the identical WTP-built bits on the VE site to make
     > installation a tad easier - esp. if these binaries are not part of
     > Ganymede or Galileo.
     >
     > OPTION 1b:
     >
     > Of course there's no need to redistribute JEM if we're building
     > against their binaries rather than sources, so we could opt to NOT
     > include JEM in the VE offerings.
     >
     > OPTION 2:
     >
     > Or, we can just update the map file used to specify the JEM
    sources to
     > the correct versions, and build against the source (and continue to
     > ship JEM with VE).
     >
     > How would the dev team like to proceed?
     >
     > N
     >
     > On Mon, Aug 3, 2009 at 6:03 PM, Carl Anderson<ccc@xxxxxxxxxx
    <mailto:ccc@xxxxxxxxxx>> wrote:
     >> Folks,
     >>
     >> So I broke the VE Ganymede build with the post-Ganymede
    refactoring that we
     >> (WTP) are doing for
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=269281 .
     >> This leads to a simple question- if this is a Ganymede-level VE
    build, why
     >> is HEAD being pulled into the build, instead of the Ganymede
    level of JEM
     >> that was shipped? (That would be the R3_0_maintenance branch,
    but the exact
     >> contents are also listed out in the 1.45.2.17 version of the
    jst-jem.map
     >> file. I can give the exact versions of the plugins, if that is
     >> desired/required.)
     >> I am also curious as to why you are rebuilding JEM- I assume
    that there are
     >> reasons, but having different "official builds" of plugins that
    could get
     >> pulled into the same Eclipse workspace worries me. Perhaps it is
    something
     >> as simple as how WTP does not package something easily for your
    consumption?
     >> Also, as I announced in wtp-dev, we are going to bump the minor
    version of
     >> the org.eclipse.jem.util plugin version id up to 2.1.0 to
    reflect the work
     >> that is going on therein. (However, that would not effect the VE
    Ganymende
     >> build if it pulls the WTP Ganymede version of JEM.)
     >> Lastly, if there truly is a need for VE to continue to build
    with the HEAD
     >> version of JEM, I would be willing to work with your team to
    create a
     >> minimally consumable set of plugins that can be pulled from WTP
    into the VE
     >> offering... however, this would be something moreso
    Helios-based, and not
     >> compatible with Ganymede (although possibly compatible with
    Galileo).
     >>
     >> FWIW,
     >>
     >> - Carl Anderson
     >> WTP programmer
     >>
     >> _______________________________________________
     >> ve-dev mailing list
     >> ve-dev@xxxxxxxxxxx <mailto:ve-dev@xxxxxxxxxxx>
     >> https://dev.eclipse.org/mailman/listinfo/ve-dev
     >>
     >>
     >
     >
     >
-- Nick Boldt :: http://nick.divbyzero.com 
    Release Engineer :: Eclipse Modeling & Dash Athena


    _______________________________________________
    ve-dev mailing list
    ve-dev@xxxxxxxxxxx <mailto:ve-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/ve-dev




--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Dash Athena
http://nick.divbyzero.com


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena

Back to the top