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