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

[Carl Anderson <ccc@xxxxxxxxxx>]

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:/cvsroot/tools,,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
Nick Boldt <nickboldt@xxxxxxxxx>

Nick Boldt <nickboldt@xxxxxxxxx>

08/05/2009 04:22 PM

To	Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
cc	Carl Anderson/Raleigh/IBM@IBMUS, Yingmin YANG <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 
(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), 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> 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
>> https://dev.eclipse.org/mailman/listinfo/ve-dev
>>
>>
> 
> 
> 

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