[
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
|
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
