Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available
[Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #23425] Thu, 16 February 2006 19:16 Go to next message
Vishy Ramaswamy is currently offline Vishy RamaswamyFriend
Messages: 30
Registered: July 2009
Member
This is a multipart message in MIME format.
--=_alternative 0069F95385257117_=
Content-Type: text/plain; charset="US-ASCII"

http://eclipse.org/emft/news/release-notes.php?version=1.0.0
http://download.eclipse.org/technology/emft/downloads/?proj= validation
--=_alternative 0069F95385257117_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt> http://eclipse.org/emft/news/release-notes.php?version=1.0.0<br>
http://download.eclipse.org/technology/emft/downloads/?proj= validation</tt></font>
--=_alternative 0069F95385257117_=--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #23510 is a reply to message #23425] Thu, 16 February 2006 22:58 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi,

It seems the validation build did not make it to the update site. Only last
week's is available, while all other EMFT builds are there.

Thanks,
Rich

> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
> http://download.eclipse.org/technology/emft/downloads/?proj= validation
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #23726 is a reply to message #23510] Fri, 17 February 2006 17:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

Richard Gronback wrote:
> Hi,
> It seems the validation build did not make it to the update site. Only
> last week's is available, while all other EMFT builds are there.
>
> Thanks,
> Rich
>
>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>> http://download.eclipse.org/technology/emft/downloads/?proj= validation
>>
>
>

That's weird. I'll look into it.
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24253 is a reply to message #23726] Wed, 22 February 2006 13:37 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Nick,

Any luck on this, or should we just wait for this week's I-builds?

Thanks,
Rich

> Richard Gronback wrote:
>
>> Hi,
>> It seems the validation build did not make it to the update site.
>> Only
>> last week's is available, while all other EMFT builds are there.
>> Thanks,
>> Rich
>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>> http://download.eclipse.org/technology/emft/downloads/?proj= validati
>>> on
>>>
> That's weird. I'll look into it.
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24336 is a reply to message #24253] Wed, 22 February 2006 13:42 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------000409040904020000020709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

Is this the right thing?

http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&s=1.0.0/I200602161109
< http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&s=1.0.0/I200602161109>


Richard Gronback wrote:

> Hi Nick,
>
> Any luck on this, or should we just wait for this week's I-builds?
>
> Thanks,
> Rich
>
>> Richard Gronback wrote:
>>
>>> Hi,
>>> It seems the validation build did not make it to the update site.
>>> Only
>>> last week's is available, while all other EMFT builds are there.
>>> Thanks,
>>> Rich
>>>
>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>> http://download.eclipse.org/technology/emft/downloads/?proj= validati
>>>> on
>>>>
>> That's weird. I'll look into it.
>>
>
>


--------------000409040904020000020709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
Is this the right thing?<br>
<blockquote><a
href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&amp;s=1.0.0/I200602161109"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&amp;s=1.0.0/I200602161109</a><br>
</blockquote>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299038c805d4a804cb10@news.eclipse.org"
type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj= validati"> http://download.eclipse.org/technology/emft/downloads/?proj= validati</a>
<br>
on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------000409040904020000020709--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24376 is a reply to message #24336] Wed, 22 February 2006 14:07 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Ed,

Yes, we switched to using the zip from the download site in our build, but
we prefer to pull from the update sites via the command line to install our
dependencies.

Odd as it seems, the mixture of this one zip with the other dependencies
installed via update manager seems to cause the org.eclipse.emf.validation.ocl
plug-in not to load, and results in the failure of one of our tests (but
not when invoked from our workspaces... that's the odd part). We will look
into this further, but were wondering in the meantime if we will be back
in business tomorrow with full update site availability of all EMFT dependencies
we use in GMF's build.

Another thing that seems odd about the contents of the download zips is that
its plug-ins have no qualifier tag in their naming, while those that are
provided via the update site do. (?)

Oh, one more question while we're on the subject... will EMFT be producing
a milestone build in the Callisto M5 timeframe, or sticking to weekly I-builds
for now?

Thanks!
- Rich

> Rich,
>
> Is this the right thing?
>
>
> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer
> .php?proj=validation&s=1.0.0/I200602161109
>
> < http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe
> r.php?proj=validation&s=1.0.0/I200602161109>
> Richard Gronback wrote:
>
>> Hi Nick,
>>
>> Any luck on this, or should we just wait for this week's I-builds?
>>
>> Thanks,
>> Rich
>>> Richard Gronback wrote:
>>>
>>>> Hi,
>>>> It seems the validation build did not make it to the update site.
>>>> Only
>>>> last week's is available, while all other EMFT builds are there.
>>>> Thanks,
>>>> Rich
>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= valida
>>>>> ti on
>>>>>
>>> That's weird. I'll look into it.
>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24417 is a reply to message #24376] Wed, 22 February 2006 14:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------000805090007070501060401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

I see, so it's the update site that's messed up. We'll need to be
especially careful about that this week to ensure that all these things
are complete, since we really would like this week's EMF and EMFT builds
to be the M5 milestones.

Looking at that zip file I see this:

eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar

Is the _1.0.0 the qualifier?

I was expecting we would produce M5 builds for EMFT, but I'd better
confirm that with Nick and company. ;-)


Richard Gronback wrote:

> Hi Ed,
>
> Yes, we switched to using the zip from the download site in our build,
> but we prefer to pull from the update sites via the command line to
> install our dependencies.
>
> Odd as it seems, the mixture of this one zip with the other
> dependencies installed via update manager seems to cause the
> org.eclipse.emf.validation.ocl plug-in not to load, and results in the
> failure of one of our tests (but not when invoked from our
> workspaces... that's the odd part). We will look into this further,
> but were wondering in the meantime if we will be back in business
> tomorrow with full update site availability of all EMFT dependencies
> we use in GMF's build.
> Another thing that seems odd about the contents of the download zips
> is that its plug-ins have no qualifier tag in their naming, while
> those that are provided via the update site do. (?)
>
> Oh, one more question while we're on the subject... will EMFT be
> producing a milestone build in the Callisto M5 timeframe, or sticking
> to weekly I-builds for now?
>
> Thanks!
> - Rich
>
>> Rich,
>>
>> Is this the right thing?
>>
>>
>> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer
>> .php?proj=validation&s=1.0.0/I200602161109
>>
>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe
>> r.php?proj=validation&s=1.0.0/I200602161109>
>> Richard Gronback wrote:
>>
>>> Hi Nick,
>>>
>>> Any luck on this, or should we just wait for this week's I-builds?
>>>
>>> Thanks,
>>> Rich
>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi,
>>>>> It seems the validation build did not make it to the update site.
>>>>> Only
>>>>> last week's is available, while all other EMFT builds are there.
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= valida
>>>>>> ti on
>>>>>>
>>>> That's weird. I'll look into it.
>>>>
>
>


--------------000805090007070501060401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
I see, so it's the update site that's messed up.&nbsp; We'll need to be
especially careful about that this week to ensure that all these things
are complete, since we really would like this week's EMF and EMFT
builds to be the M5 milestones.<br>
<br>
Looking at that zip file I see this:<br>
<blockquote>eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar <br>
</blockquote>
Is the _1.0.0 the qualifier?<br>
<br>
I was expecting we would produce M5 builds for EMFT, but I'd better
confirm that with Nick and company. ;-)<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299078c805d8c7c9bcf0@news.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Yes, we switched to using the zip from the download site in our build,
but we prefer to pull from the update sites via the command line to
install our dependencies.
<br>
<br>
Odd as it seems, the mixture of this one zip with the other
dependencies installed via update manager seems to cause the
org.eclipse.emf.validation.ocl plug-in not to load, and results in the
failure of one of our tests (but not when invoked from our
workspaces... that's the odd part).&nbsp; We will look into this further,
but were wondering in the meantime if we will be back in business
tomorrow with full update site availability of all EMFT dependencies we
use in GMF's build.&nbsp; <br>
Another thing that seems odd about the contents of the download zips is
that its plug-ins have no qualifier tag in their naming, while those
that are provided via the update site do. (?)
<br>
<br>
Oh, one more question while we're on the subject... will EMFT be
producing a milestone build in the Callisto M5 timeframe, or sticking
to weekly I-builds for now?
<br>
<br>
Thanks!
<br>
- Rich
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
Is this the right thing?
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer</a>
<br>
..php?proj=validation&amp;s=1.0.0/I200602161109
<br>
<br>
&lt;<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe</a>
<br>
r.php?proj=validation&amp;s=1.0.0/I200602161109&gt;
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj= valida"> http://download.eclipse.org/technology/emft/downloads/?proj= valida</a>
<br>
ti on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------000805090007070501060401--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24459 is a reply to message #24417] Wed, 22 February 2006 14:25 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Thanks Ed.

The update site jars are named like this: org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar
where the '.qualifier' suffix on the version number is (should be) substituted
by the PDE build automatically with the build ID (typically).

Best,
Rich


> Rich,
>
> I see, so it's the update site that's messed up. We'll need to be
> especially careful about that this week to ensure that all these
> things are complete, since we really would like this week's EMF and
> EMFT builds to be the M5 milestones.
>
> Looking at that zip file I see this:
>
> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>
> Is the _1.0.0 the qualifier?
>
> I was expecting we would produce M5 builds for EMFT, but I'd better
> confirm that with Nick and company. ;-)
>
> Richard Gronback wrote:
>
>> Hi Ed,
>>
>> Yes, we switched to using the zip from the download site in our
>> build, but we prefer to pull from the update sites via the command
>> line to install our dependencies.
>>
>> Odd as it seems, the mixture of this one zip with the other
>> dependencies installed via update manager seems to cause the
>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>> the failure of one of our tests (but not when invoked from our
>> workspaces... that's the odd part). We will look into this further,
>> but were wondering in the meantime if we will be back in business
>> tomorrow with full update site availability of all EMFT dependencies
>> we use in GMF's build. Another thing that seems odd about the
>> contents of the download zips is that its plug-ins have no qualifier
>> tag in their naming, while those that are provided via the update
>> site do. (?)
>>
>> Oh, one more question while we're on the subject... will EMFT be
>> producing a milestone build in the Callisto M5 timeframe, or sticking
>> to weekly I-builds for now?
>>
>> Thanks!
>> - Rich
>>> Rich,
>>>
>>> Is this the right thing?
>>>
>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
>>> er .php?proj=validation&s=1.0.0/I200602161109
>>>
>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
>>> we
>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>> Richard Gronback wrote:
>>>> Hi Nick,
>>>>
>>>> Any luck on this, or should we just wait for this week's I-builds?
>>>>
>>>> Thanks,
>>>> Rich
>>>>> Richard Gronback wrote:
>>>>>
>>>>>> Hi,
>>>>>> It seems the validation build did not make it to the update site.
>>>>>> Only
>>>>>> last week's is available, while all other EMFT builds are there.
>>>>>> Thanks,
>>>>>> Rich
>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
>>>>>>> da ti on
>>>>>>>
>>>>> That's weird. I'll look into it.
>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24581 is a reply to message #24459] Wed, 22 February 2006 20:41 Go to previous messageGo to next message
Vishy Ramaswamy is currently offline Vishy RamaswamyFriend
Messages: 30
Registered: July 2009
Member
Hi Rich and Ed,
The EMFT components (validation, transaction. ocl and query) will be
producing M5 milestone builds tomorrow (obviously after the EMF M5 build is
declared).
Cheers
Vishy

"Richard Gronback" <richard.gronback@borland.com> wrote in message
news:1e248342990e8c805db56d4d130@news.eclipse.org...
> Thanks Ed.
>
> The update site jars are named like this:
org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar
> where the '.qualifier' suffix on the version number is (should be)
substituted
> by the PDE build automatically with the build ID (typically).
>
> Best,
> Rich
>
>
> > Rich,
> >
> > I see, so it's the update site that's messed up. We'll need to be
> > especially careful about that this week to ensure that all these
> > things are complete, since we really would like this week's EMF and
> > EMFT builds to be the M5 milestones.
> >
> > Looking at that zip file I see this:
> >
> > eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
> >
> > Is the _1.0.0 the qualifier?
> >
> > I was expecting we would produce M5 builds for EMFT, but I'd better
> > confirm that with Nick and company. ;-)
> >
> > Richard Gronback wrote:
> >
> >> Hi Ed,
> >>
> >> Yes, we switched to using the zip from the download site in our
> >> build, but we prefer to pull from the update sites via the command
> >> line to install our dependencies.
> >>
> >> Odd as it seems, the mixture of this one zip with the other
> >> dependencies installed via update manager seems to cause the
> >> org.eclipse.emf.validation.ocl plug-in not to load, and results in
> >> the failure of one of our tests (but not when invoked from our
> >> workspaces... that's the odd part). We will look into this further,
> >> but were wondering in the meantime if we will be back in business
> >> tomorrow with full update site availability of all EMFT dependencies
> >> we use in GMF's build. Another thing that seems odd about the
> >> contents of the download zips is that its plug-ins have no qualifier
> >> tag in their naming, while those that are provided via the update
> >> site do. (?)
> >>
> >> Oh, one more question while we're on the subject... will EMFT be
> >> producing a milestone build in the Callisto M5 timeframe, or sticking
> >> to weekly I-builds for now?
> >>
> >> Thanks!
> >> - Rich
> >>> Rich,
> >>>
> >>> Is this the right thing?
> >>>
> >>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
> >>> er .php?proj=validation&s=1.0.0/I200602161109
> >>>
> >>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
> >>> we
> >>> r.php?proj=validation&s=1.0.0/I200602161109>
> >>> Richard Gronback wrote:
> >>>> Hi Nick,
> >>>>
> >>>> Any luck on this, or should we just wait for this week's I-builds?
> >>>>
> >>>> Thanks,
> >>>> Rich
> >>>>> Richard Gronback wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> It seems the validation build did not make it to the update site.
> >>>>>> Only
> >>>>>> last week's is available, while all other EMFT builds are there.
> >>>>>> Thanks,
> >>>>>> Rich
> >>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
> >>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
> >>>>>>> da ti on
> >>>>>>>
> >>>>> That's weird. I'll look into it.
> >>>>>
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24621 is a reply to message #24459] Wed, 22 February 2006 20:49 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

The difference between _1.0.0 and _1.0.0.I200601261257 has been there
since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
the qualifier, only the UM jars.

This is because if you're downloading the zip, you will replace the old
content w/ the new content (or copy on top) and thus Eclipse will be
fine finding and resolving plugins.

But with UM installs, each release must be numbered greater than the
last or UM won't consider the content newer than what's already
installed, and won't present you the choice in the UM Wizard. To UM,
1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
1.0.0.IyyyymmddHHMM so that they can be installed sequentially. However,
due to a "feature" of UM and the way we suffix these jars, an I build
will always be considered "older" than an S build even if the I build's
datestamp is newer, since alphabetically, I < S. The workaround here is
to uncheck the box for "only latest" so that you can see I builds that
are newer than the S builds.

At some point, we might reverse this scheme so that we place the build
type code at the end (eg., 200601261257I), if enough people would find
that valuable.

[This is your cue to open a bug and have others vote on it. ;)]

Anyhoo... that aside, I'm still no closer to understanding why 3/5
updates worked fine but EODM and Validation failed (using the same code
to do the update!). It looks like there's something wrong with either
the SCP process itself or the compare process I do to verify that the
upload succeeded. Anyway, I'm hoping it's transient and that it won't
happen again tomorrow. If it does, I'll be sure the jars get there
manually if necessary.

Cheers,

Nick

Richard Gronback wrote:
> Thanks Ed.
>
> The update site jars are named like this:
> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
> '.qualifier' suffix on the version number is (should be) substituted by
> the PDE build automatically with the build ID (typically).
>
> Best,
> Rich
>
>
>> Rich,
>>
>> I see, so it's the update site that's messed up. We'll need to be
>> especially careful about that this week to ensure that all these
>> things are complete, since we really would like this week's EMF and
>> EMFT builds to be the M5 milestones.
>>
>> Looking at that zip file I see this:
>>
>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>
>> Is the _1.0.0 the qualifier?
>>
>> I was expecting we would produce M5 builds for EMFT, but I'd better
>> confirm that with Nick and company. ;-)
>>
>> Richard Gronback wrote:
>>
>>> Hi Ed,
>>>
>>> Yes, we switched to using the zip from the download site in our
>>> build, but we prefer to pull from the update sites via the command
>>> line to install our dependencies.
>>>
>>> Odd as it seems, the mixture of this one zip with the other
>>> dependencies installed via update manager seems to cause the
>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>> the failure of one of our tests (but not when invoked from our
>>> workspaces... that's the odd part). We will look into this further,
>>> but were wondering in the meantime if we will be back in business
>>> tomorrow with full update site availability of all EMFT dependencies
>>> we use in GMF's build. Another thing that seems odd about the
>>> contents of the download zips is that its plug-ins have no qualifier
>>> tag in their naming, while those that are provided via the update
>>> site do. (?)
>>>
>>> Oh, one more question while we're on the subject... will EMFT be
>>> producing a milestone build in the Callisto M5 timeframe, or sticking
>>> to weekly I-builds for now?
>>>
>>> Thanks!
>>> - Rich
>>>> Rich,
>>>>
>>>> Is this the right thing?
>>>>
>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
>>>> er .php?proj=validation&s=1.0.0/I200602161109
>>>>
>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
>>>> we
>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>> Richard Gronback wrote:
>>>>> Hi Nick,
>>>>>
>>>>> Any luck on this, or should we just wait for this week's I-builds?
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>> Richard Gronback wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> It seems the validation build did not make it to the update site.
>>>>>>> Only
>>>>>>> last week's is available, while all other EMFT builds are there.
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
>>>>>>>> da ti on
>>>>>>>>
>>>>>> That's weird. I'll look into it.
>>>>>>
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24778 is a reply to message #24621] Thu, 23 February 2006 09:37 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Thanks, Nick.

I'm not so interested in the UI of update manager, as we utilize the command
line interface to directly request specified builds. It does seem odd that
EMF[T] has two different naming conventions depending upon whether UM or
zips are produced. The GMF build simply uses the PDE build to generate both,
while I understand you have your own (working!) scripts, so no big deal really.

Looking forward to today's M5 builds.

Thanks again,
Rich



> The difference between _1.0.0 and _1.0.0.I200601261257 has been there
> since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
> the qualifier, only the UM jars.
>
> This is because if you're downloading the zip, you will replace the
> old content w/ the new content (or copy on top) and thus Eclipse will
> be fine finding and resolving plugins.
>
> But with UM installs, each release must be numbered greater than the
> last or UM won't consider the content newer than what's already
> installed, and won't present you the choice in the UM Wizard. To UM,
> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
> However, due to a "feature" of UM and the way we suffix these jars, an
> I build will always be considered "older" than an S build even if the
> I build's datestamp is newer, since alphabetically, I < S. The
> workaround here is to uncheck the box for "only latest" so that you
> can see I builds that are newer than the S builds.
>
> At some point, we might reverse this scheme so that we place the build
> type code at the end (eg., 200601261257I), if enough people would find
> that valuable.
>
> [This is your cue to open a bug and have others vote on it. ;)]
>
> Anyhoo... that aside, I'm still no closer to understanding why 3/5
> updates worked fine but EODM and Validation failed (using the same
> code to do the update!). It looks like there's something wrong with
> either the SCP process itself or the compare process I do to verify
> that the upload succeeded. Anyway, I'm hoping it's transient and that
> it won't happen again tomorrow. If it does, I'll be sure the jars get
> there manually if necessary.
>
> Cheers,
>
> Nick
>
> Richard Gronback wrote:
>
>> Thanks Ed.
>>
>> The update site jars are named like this:
>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>> '.qualifier' suffix on the version number is (should be) substituted
>> by the PDE build automatically with the build ID (typically).
>>
>> Best,
>> Rich
>>> Rich,
>>>
>>> I see, so it's the update site that's messed up. We'll need to be
>>> especially careful about that this week to ensure that all these
>>> things are complete, since we really would like this week's EMF and
>>> EMFT builds to be the M5 milestones.
>>>
>>> Looking at that zip file I see this:
>>>
>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>
>>> Is the _1.0.0 the qualifier?
>>>
>>> I was expecting we would produce M5 builds for EMFT, but I'd better
>>> confirm that with Nick and company. ;-)
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Yes, we switched to using the zip from the download site in our
>>>> build, but we prefer to pull from the update sites via the command
>>>> line to install our dependencies.
>>>>
>>>> Odd as it seems, the mixture of this one zip with the other
>>>> dependencies installed via update manager seems to cause the
>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>>> the failure of one of our tests (but not when invoked from our
>>>> workspaces... that's the odd part). We will look into this
>>>> further, but were wondering in the meantime if we will be back in
>>>> business tomorrow with full update site availability of all EMFT
>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>> about the contents of the download zips is that its plug-ins have
>>>> no qualifier tag in their naming, while those that are provided via
>>>> the update site do. (?)
>>>>
>>>> Oh, one more question while we're on the subject... will EMFT be
>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>> sticking to weekly I-builds for now?
>>>>
>>>> Thanks!
>>>> - Rich
>>>>> Rich,
>>>>>
>>>>> Is this the right thing?
>>>>>
>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-vi
>>>>> ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>
>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-v
>>>>> ie
>>>>> we
>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>> Richard Gronback wrote:
>>>>>> Hi Nick,
>>>>>>
>>>>>> Any luck on this, or should we just wait for this week's
>>>>>> I-builds?
>>>>>>
>>>>>> Thanks,
>>>>>> Rich
>>>>>>> Richard Gronback wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>> site.
>>>>>>>> Only
>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>> there.
>>>>>>>> Thanks,
>>>>>>>> Rich
>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= va
>>>>>>>>> li da ti on
>>>>>>>>>
>>>>>>> That's weird. I'll look into it.
>>>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24814 is a reply to message #24778] Thu, 23 February 2006 11:06 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Rich,

Adding build versions to the jar names in the zip is a fairly recently
platform change. Perhaps we should do the same thing now too? We're
just using the PDE build as well, but with some added bonus features.
;-) The platform plugins seem to to be directly updating the
Bundle-Version in the MANIFEST.MF with each build and I think that name
is simply reflected into the jar name. So maybe we should start doing
this updating of the MANFEST.MF too and that will produce names like we
see for the platform?


Richard Gronback wrote:
> Thanks, Nick.
>
> I'm not so interested in the UI of update manager, as we utilize the
> command line interface to directly request specified builds. It does
> seem odd that EMF[T] has two different naming conventions depending
> upon whether UM or zips are produced. The GMF build simply uses the
> PDE build to generate both, while I understand you have your own
> (working!) scripts, so no big deal really.
>
> Looking forward to today's M5 builds.
>
> Thanks again,
> Rich
>
>
>
>> The difference between _1.0.0 and _1.0.0.I200601261257 has been there
>> since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
>> the qualifier, only the UM jars.
>>
>> This is because if you're downloading the zip, you will replace the
>> old content w/ the new content (or copy on top) and thus Eclipse will
>> be fine finding and resolving plugins.
>>
>> But with UM installs, each release must be numbered greater than the
>> last or UM won't consider the content newer than what's already
>> installed, and won't present you the choice in the UM Wizard. To UM,
>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>> However, due to a "feature" of UM and the way we suffix these jars, an
>> I build will always be considered "older" than an S build even if the
>> I build's datestamp is newer, since alphabetically, I < S. The
>> workaround here is to uncheck the box for "only latest" so that you
>> can see I builds that are newer than the S builds.
>>
>> At some point, we might reverse this scheme so that we place the build
>> type code at the end (eg., 200601261257I), if enough people would find
>> that valuable.
>>
>> [This is your cue to open a bug and have others vote on it. ;)]
>>
>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>> updates worked fine but EODM and Validation failed (using the same
>> code to do the update!). It looks like there's something wrong with
>> either the SCP process itself or the compare process I do to verify
>> that the upload succeeded. Anyway, I'm hoping it's transient and that
>> it won't happen again tomorrow. If it does, I'll be sure the jars get
>> there manually if necessary.
>>
>> Cheers,
>>
>> Nick
>>
>> Richard Gronback wrote:
>>
>>> Thanks Ed.
>>>
>>> The update site jars are named like this:
>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>> '.qualifier' suffix on the version number is (should be) substituted
>>> by the PDE build automatically with the build ID (typically).
>>>
>>> Best,
>>> Rich
>>>> Rich,
>>>>
>>>> I see, so it's the update site that's messed up. We'll need to be
>>>> especially careful about that this week to ensure that all these
>>>> things are complete, since we really would like this week's EMF and
>>>> EMFT builds to be the M5 milestones.
>>>>
>>>> Looking at that zip file I see this:
>>>>
>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>
>>>> Is the _1.0.0 the qualifier?
>>>>
>>>> I was expecting we would produce M5 builds for EMFT, but I'd better
>>>> confirm that with Nick and company. ;-)
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Yes, we switched to using the zip from the download site in our
>>>>> build, but we prefer to pull from the update sites via the command
>>>>> line to install our dependencies.
>>>>>
>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>> dependencies installed via update manager seems to cause the
>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>>>> the failure of one of our tests (but not when invoked from our
>>>>> workspaces... that's the odd part). We will look into this
>>>>> further, but were wondering in the meantime if we will be back in
>>>>> business tomorrow with full update site availability of all EMFT
>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>> about the contents of the download zips is that its plug-ins have
>>>>> no qualifier tag in their naming, while those that are provided via
>>>>> the update site do. (?)
>>>>>
>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>> sticking to weekly I-builds for now?
>>>>>
>>>>> Thanks!
>>>>> - Rich
>>>>>> Rich,
>>>>>>
>>>>>> Is this the right thing?
>>>>>>
>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-vi
>>>>>> ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>
>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-v
>>>>>> ie
>>>>>> we
>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>> Richard Gronback wrote:
>>>>>>> Hi Nick,
>>>>>>>
>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>> I-builds?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>> Richard Gronback wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>> site.
>>>>>>>>> Only
>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>> there.
>>>>>>>>> Thanks,
>>>>>>>>> Rich
>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= va
>>>>>>>>>> li da ti on
>>>>>>>>>>
>>>>>>>> That's weird. I'll look into it.
>>>>>>>>
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24849 is a reply to message #24814] Thu, 23 February 2006 11:18 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Ed,

Right, if you add '.qualifier' to all your Bundle-Version entries in the
manifests, PDE build will replace these and take care of naming your files
accordingly, etc. We've run into some complications due to all this (e.g.
test executions, as the paths can vary with each build), but in the end if
it means the update manager will work better (particularly for Callisto),
it's worth the switch, imo.

Best,
Rich

> Rich,
>
> Adding build versions to the jar names in the zip is a fairly recently
> platform change. Perhaps we should do the same thing now too? We're
> just using the PDE build as well, but with some added bonus features.
> ;-) The platform plugins seem to to be directly updating the
> Bundle-Version in the MANIFEST.MF with each build and I think that
> name is simply reflected into the jar name. So maybe we should start
> doing this updating of the MANFEST.MF too and that will produce names
> like we see for the platform?
>
> Richard Gronback wrote:
>
>> Thanks, Nick.
>>
>> I'm not so interested in the UI of update manager, as we utilize the
>> command line interface to directly request specified builds. It does
>> seem odd that EMF[T] has two different naming conventions depending
>> upon whether UM or zips are produced. The GMF build simply uses the
>> PDE build to generate both, while I understand you have your own
>> (working!) scripts, so no big deal really.
>>
>> Looking forward to today's M5 builds.
>>
>> Thanks again,
>> Rich
>>> The difference between _1.0.0 and _1.0.0.I200601261257 has been
>>> there since Day One for EMF, UML2, and EMFT. The zips do not get
>>> tagged with the qualifier, only the UM jars.
>>>
>>> This is because if you're downloading the zip, you will replace the
>>> old content w/ the new content (or copy on top) and thus Eclipse
>>> will be fine finding and resolving plugins.
>>>
>>> But with UM installs, each release must be numbered greater than the
>>> last or UM won't consider the content newer than what's already
>>> installed, and won't present you the choice in the UM Wizard. To UM,
>>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>>> However, due to a "feature" of UM and the way we suffix these jars,
>>> an I build will always be considered "older" than an S build even if
>>> the I build's datestamp is newer, since alphabetically, I < S. The
>>> workaround here is to uncheck the box for "only latest" so that you
>>> can see I builds that are newer than the S builds.
>>>
>>> At some point, we might reverse this scheme so that we place the
>>> build type code at the end (eg., 200601261257I), if enough people
>>> would find that valuable.
>>>
>>> [This is your cue to open a bug and have others vote on it. ;)]
>>>
>>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>>> updates worked fine but EODM and Validation failed (using the same
>>> code to do the update!). It looks like there's something wrong with
>>> either the SCP process itself or the compare process I do to verify
>>> that the upload succeeded. Anyway, I'm hoping it's transient and
>>> that it won't happen again tomorrow. If it does, I'll be sure the
>>> jars get there manually if necessary.
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Richard Gronback wrote:
>>>
>>>> Thanks Ed.
>>>>
>>>> The update site jars are named like this:
>>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>>> '.qualifier' suffix on the version number is (should be)
>>>> substituted by the PDE build automatically with the build ID
>>>> (typically).
>>>>
>>>> Best,
>>>> Rich
>>>>> Rich,
>>>>>
>>>>> I see, so it's the update site that's messed up. We'll need to be
>>>>> especially careful about that this week to ensure that all these
>>>>> things are complete, since we really would like this week's EMF
>>>>> and EMFT builds to be the M5 milestones.
>>>>>
>>>>> Looking at that zip file I see this:
>>>>>
>>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>>
>>>>> Is the _1.0.0 the qualifier?
>>>>>
>>>>> I was expecting we would produce M5 builds for EMFT, but I'd
>>>>> better confirm that with Nick and company. ;-)
>>>>>
>>>>> Richard Gronback wrote:
>>>>>
>>>>>> Hi Ed,
>>>>>>
>>>>>> Yes, we switched to using the zip from the download site in our
>>>>>> build, but we prefer to pull from the update sites via the
>>>>>> command line to install our dependencies.
>>>>>>
>>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>>> dependencies installed via update manager seems to cause the
>>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results
>>>>>> in the failure of one of our tests (but not when invoked from our
>>>>>> workspaces... that's the odd part). We will look into this
>>>>>> further, but were wondering in the meantime if we will be back in
>>>>>> business tomorrow with full update site availability of all EMFT
>>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>>> about the contents of the download zips is that its plug-ins have
>>>>>> no qualifier tag in their naming, while those that are provided
>>>>>> via the update site do. (?)
>>>>>>
>>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>>> sticking to weekly I-builds for now?
>>>>>>
>>>>>> Thanks!
>>>>>> - Rich
>>>>>>> Rich,
>>>>>>>
>>>>>>> Is this the right thing?
>>>>>>>
>>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-
>>>>>>> vi ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>>
>>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads
>>>>>>> -v
>>>>>>> ie
>>>>>>> we
>>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>>> Richard Gronback wrote:
>>>>>>>> Hi Nick,
>>>>>>>>
>>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>>> I-builds?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rich
>>>>>>>>> Richard Gronback wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>>> site.
>>>>>>>>>> Only
>>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>>> there.
>>>>>>>>>> Thanks,
>>>>>>>>>> Rich
>>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj=
>>>>>>>>>>> va li da ti on
>>>>>>>>>>>
>>>>>>>>> That's weird. I'll look into it.
>>>>>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #24881 is a reply to message #24849] Thu, 23 February 2006 11:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------090501080206020704060308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

I've sent a note to Nick and the rest of the group to solicit opinions,
but it does seem the right way to go. Maybe that would eliminate the
need for this bugzilla (or could be used to implement it).

https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127


Richard Gronback wrote:
> Hi Ed,
>
> Right, if you add '.qualifier' to all your Bundle-Version entries in
> the manifests, PDE build will replace these and take care of naming
> your files accordingly, etc. We've run into some complications due to
> all this (e.g. test executions, as the paths can vary with each
> build), but in the end if it means the update manager will work better
> (particularly for Callisto), it's worth the switch, imo.
>
> Best,
> Rich
>
>> Rich,
>>
>> Adding build versions to the jar names in the zip is a fairly recently
>> platform change. Perhaps we should do the same thing now too? We're
>> just using the PDE build as well, but with some added bonus features.
>> ;-) The platform plugins seem to to be directly updating the
>> Bundle-Version in the MANIFEST.MF with each build and I think that
>> name is simply reflected into the jar name. So maybe we should start
>> doing this updating of the MANFEST.MF too and that will produce names
>> like we see for the platform?
>>
>> Richard Gronback wrote:
>>
>>> Thanks, Nick.
>>>
>>> I'm not so interested in the UI of update manager, as we utilize the
>>> command line interface to directly request specified builds. It does
>>> seem odd that EMF[T] has two different naming conventions depending
>>> upon whether UM or zips are produced. The GMF build simply uses the
>>> PDE build to generate both, while I understand you have your own
>>> (working!) scripts, so no big deal really.
>>>
>>> Looking forward to today's M5 builds.
>>>
>>> Thanks again,
>>> Rich
>>>> The difference between _1.0.0 and _1.0.0.I200601261257 has been
>>>> there since Day One for EMF, UML2, and EMFT. The zips do not get
>>>> tagged with the qualifier, only the UM jars.
>>>>
>>>> This is because if you're downloading the zip, you will replace the
>>>> old content w/ the new content (or copy on top) and thus Eclipse
>>>> will be fine finding and resolving plugins.
>>>>
>>>> But with UM installs, each release must be numbered greater than the
>>>> last or UM won't consider the content newer than what's already
>>>> installed, and won't present you the choice in the UM Wizard. To UM,
>>>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>>>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>>>> However, due to a "feature" of UM and the way we suffix these jars,
>>>> an I build will always be considered "older" than an S build even if
>>>> the I build's datestamp is newer, since alphabetically, I < S. The
>>>> workaround here is to uncheck the box for "only latest" so that you
>>>> can see I builds that are newer than the S builds.
>>>>
>>>> At some point, we might reverse this scheme so that we place the
>>>> build type code at the end (eg., 200601261257I), if enough people
>>>> would find that valuable.
>>>>
>>>> [This is your cue to open a bug and have others vote on it. ;)]
>>>>
>>>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>>>> updates worked fine but EODM and Validation failed (using the same
>>>> code to do the update!). It looks like there's something wrong with
>>>> either the SCP process itself or the compare process I do to verify
>>>> that the upload succeeded. Anyway, I'm hoping it's transient and
>>>> that it won't happen again tomorrow. If it does, I'll be sure the
>>>> jars get there manually if necessary.
>>>>
>>>> Cheers,
>>>>
>>>> Nick
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Thanks Ed.
>>>>>
>>>>> The update site jars are named like this:
>>>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>>>> '.qualifier' suffix on the version number is (should be)
>>>>> substituted by the PDE build automatically with the build ID
>>>>> (typically).
>>>>>
>>>>> Best,
>>>>> Rich
>>>>>> Rich,
>>>>>>
>>>>>> I see, so it's the update site that's messed up. We'll need to be
>>>>>> especially careful about that this week to ensure that all these
>>>>>> things are complete, since we really would like this week's EMF
>>>>>> and EMFT builds to be the M5 milestones.
>>>>>>
>>>>>> Looking at that zip file I see this:
>>>>>>
>>>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>>>
>>>>>> Is the _1.0.0 the qualifier?
>>>>>>
>>>>>> I was expecting we would produce M5 builds for EMFT, but I'd
>>>>>> better confirm that with Nick and company. ;-)
>>>>>>
>>>>>> Richard Gronback wrote:
>>>>>>
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> Yes, we switched to using the zip from the download site in our
>>>>>>> build, but we prefer to pull from the update sites via the
>>>>>>> command line to install our dependencies.
>>>>>>>
>>>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>>>> dependencies installed via update manager seems to cause the
>>>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results
>>>>>>> in the failure of one of our tests (but not when invoked from our
>>>>>>> workspaces... that's the odd part). We will look into this
>>>>>>> further, but were wondering in the meantime if we will be back in
>>>>>>> business tomorrow with full update site availability of all EMFT
>>>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>>>> about the contents of the download zips is that its plug-ins have
>>>>>>> no qualifier tag in their naming, while those that are provided
>>>>>>> via the update site do. (?)
>>>>>>>
>>>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>>>> sticking to weekly I-builds for now?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> - Rich
>>>>>>>> Rich,
>>>>>>>>
>>>>>>>> Is this the right thing?
>>>>>>>>
>>>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-
>>>>>>>> vi ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>>>
>>>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads
>>>>>>>> -v
>>>>>>>> ie
>>>>>>>> we
>>>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>>>> Richard Gronback wrote:
>>>>>>>>> Hi Nick,
>>>>>>>>>
>>>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>>>> I-builds?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rich
>>>>>>>>>> Richard Gronback wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>>>> site.
>>>>>>>>>>> Only
>>>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>>>> there.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rich
>>>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj=
>>>>>>>>>>>> va li da ti on
>>>>>>>>>>>>
>>>>>>>>>> That's weird. I'll look into it.
>>>>>>>>>>
>
>


--------------090501080206020704060308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
I've sent a note to Nick and the rest of the group to solicit opinions,
but it does seem the right way to go.&nbsp;&nbsp; Maybe that would eliminate the
need for this bugzilla (or could be used to implement it).<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a><br>
</blockquote>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299ca8c8068a6d1aaee0@news.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in
the manifests, PDE build will replace these and take care of naming
your files accordingly, etc.&nbsp; We've run into some complications due to
all this (e.g. test executions, as the paths can vary with each build),
but in the end if it means the update manager will work better
(particularly for Callisto), it's worth the switch, imo.
<br>
<br>
Best,
<br>
Rich
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
Adding build versions to the jar names in the zip is a fairly recently
<br>
platform change.&nbsp; Perhaps we should do the same thing now too?&nbsp; We're
<br>
just using the PDE build as well, but with some added bonus features.
<br>
;-)&nbsp;&nbsp; The platform plugins seem to to be directly updating the
<br>
Bundle-Version in the MANIFEST.MF with each build and I think that
<br>
name is simply reflected into the jar name.&nbsp; So maybe we should start
<br>
doing this updating of the MANFEST.MF too and that will produce names
<br>
like we see for the platform?
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Thanks, Nick.
<br>
<br>
I'm not so interested in the UI of update manager, as we utilize the
<br>
command line interface to directly request specified builds.&nbsp; It does
<br>
seem odd that EMF[T] has two different naming conventions depending
<br>
upon whether UM or zips are produced.&nbsp; The GMF build simply uses the
<br>
PDE build to generate both, while I understand you have your own
<br>
(working!) scripts, so no big deal really.
<br>
<br>
Looking forward to today's M5 builds.
<br>
<br>
Thanks again,
<br>
Rich
<br>
<blockquote type="cite">The difference between _1.0.0 and
_1.0.0.I200601261257 has been
<br>
there since Day One for EMF, UML2, and EMFT. The zips do not get
<br>
tagged with the qualifier, only the UM jars.
<br>
<br>
This is because if you're downloading the zip, you will replace the
<br>
old content w/ the new content (or copy on top) and thus Eclipse
<br>
will be fine finding and resolving plugins.
<br>
<br>
But with UM installs, each release must be numbered greater than the
<br>
last or UM won't consider the content newer than what's already
<br>
installed, and won't present you the choice in the UM Wizard. To UM,
<br>
1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
<br>
1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
<br>
However, due to a "feature" of UM and the way we suffix these jars,
<br>
an I build will always be considered "older" than an S build even if
<br>
the I build's datestamp is newer,&nbsp; since alphabetically, I &lt; S. The
<br>
workaround here is to uncheck the box for "only latest" so that you
<br>
can see I builds that are newer than the S builds.
<br>
<br>
At some point, we might reverse this scheme so that we place the
<br>
build type code at the end (eg., 200601261257I), if enough people
<br>
would find that valuable.
<br>
<br>
[This is your cue to open a bug and have others vote on it. ;)]
<br>
<br>
Anyhoo... that aside, I'm still no closer to understanding why 3/5
<br>
updates worked fine but EODM and Validation failed (using the same
<br>
code to do the update!). It looks like there's something wrong with
<br>
either the SCP process itself or the compare process I do to verify
<br>
that the upload succeeded. Anyway, I'm hoping it's transient and
<br>
that it won't happen again tomorrow. If it does, I'll be sure the
<br>
jars get there manually if necessary.
<br>
<br>
Cheers,
<br>
<br>
Nick
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Thanks Ed.
<br>
<br>
The update site jars are named like this:
<br>
org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
<br>
'.qualifier' suffix on the version number is (should be)
<br>
substituted by the PDE build automatically with the build ID
<br>
(typically).
<br>
<br>
Best,
<br>
Rich
<br>
<blockquote type="cite">Rich,
<br>
<br>
I see, so it's the update site that's messed up.&nbsp; We'll need to be
<br>
especially careful about that this week to ensure that all these
<br>
things are complete, since we really would like this week's EMF
<br>
and EMFT builds to be the M5 milestones.
<br>
<br>
Looking at that zip file I see this:
<br>
<br>
eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
<br>
<br>
Is the _1.0.0 the qualifier?
<br>
<br>
I was expecting we would produce M5 builds for EMFT, but I'd
<br>
better confirm that with Nick and company. ;-)
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
Yes, we switched to using the zip from the download site in our
<br>
build, but we prefer to pull from the update sites via the
<br>
command line to install our dependencies.
<br>
<br>
Odd as it seems, the mixture of this one zip with the other
<br>
dependencies installed via update manager seems to cause the
<br>
org.eclipse.emf.validation.ocl plug-in not to load, and results
<br>
in the failure of one of our tests (but not when invoked from our
<br>
workspaces... that's the odd part).&nbsp; We will look into this
<br>
further, but were wondering in the meantime if we will be back in
<br>
business tomorrow with full update site availability of all EMFT
<br>
dependencies we use in GMF's build. Another thing that seems odd
<br>
about the contents of the download zips is that its plug-ins have
<br>
no qualifier tag in their naming, while those that are provided
<br>
via the update site do. (?)
<br>
<br>
Oh, one more question while we're on the subject... will EMFT be
<br>
producing a milestone build in the Callisto M5 timeframe, or
<br>
sticking to weekly I-builds for now?
<br>
<br>
Thanks!
<br>
- Rich
<br>
<blockquote type="cite">Rich,
<br>
<br>
Is this the right thing?
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads"> http://download.eclipse.org/technology/emft/downloads/downlo ads</a>-
<br>
vi ew er .php?proj=validation&amp;s=1.0.0/I200602161109
<br>
<br>
&lt;<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads"> http://download.eclipse.org/technology/emft/downloads/downlo ads</a>
<br>
-v
<br>
ie
<br>
we
<br>
r.php?proj=validation&amp;s=1.0.0/I200602161109&gt;
<br>
Richard Gronback wrote:
<br>
<blockquote type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's
<br>
I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update
<br>
site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are
<br>
there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj="> http://download.eclipse.org/technology/emft/downloads/?proj=</a>
<br>
va li da ti on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------090501080206020704060308--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25031 is a reply to message #24881] Thu, 23 February 2006 15:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

Rich:

How do you make PDE replace "1.0.0.qualifier" with, for example,
"1.0.0I200602161109" ? Or does PDE do it automagically?

If you can provide some insight into this (here, in the bug, or via
email directly to codeslave(at)ca.ibm.com), then I can start exploring
after M5.

Anyway, I'll add this to my pile of never-ending TODOs. ;-)

Cheers,

Nick

Ed Merks wrote:
> Rich,
>
> I've sent a note to Nick and the rest of the group to solicit opinions,
> but it does seem the right way to go. Maybe that would eliminate the
> need for this bugzilla (or could be used to implement it).
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>
>
> Richard Gronback wrote:
>> Hi Ed,
>>
>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>> the manifests, PDE build will replace these and take care of naming
>> your files accordingly, etc. We've run into some complications due to
>> all this (e.g. test executions, as the paths can vary with each
>> build), but in the end if it means the update manager will work better
>> (particularly for Callisto), it's worth the switch, imo.
>>
>> Best,
>> Rich
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25072 is a reply to message #25031] Thu, 23 February 2006 15:26 Go to previous messageGo to next message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Nick,

I learned about this "automagic" feature in this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393
which led me to this article http://www.eclipse.org/equinox/documents/plugin-versioning.h tml


Of course, no clear instructions were found, so I poked into the platform's
manifests and found a curious .qualifier suffix added to their version numbers.
So, I tacked it onto ours as well and have been dealing with the repercussions
since ;-)

Best,
Rich


> Rich:
>
> How do you make PDE replace "1.0.0.qualifier" with, for example,
> "1.0.0I200602161109" ? Or does PDE do it automagically?
>
> If you can provide some insight into this (here, in the bug, or via
> email directly to codeslave(at)ca.ibm.com), then I can start exploring
> after M5.
>
> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>
> Cheers,
>
> Nick
>
> Ed Merks wrote:
>
>> Rich,
>>
>> I've sent a note to Nick and the rest of the group to solicit
>> opinions, but it does seem the right way to go. Maybe that would
>> eliminate the need for this bugzilla (or could be used to implement
>> it).
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>
>> Richard Gronback wrote:
>>
>>> Hi Ed,
>>>
>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>> the manifests, PDE build will replace these and take care of naming
>>> your files accordingly, etc. We've run into some complications due
>>> to all this (e.g. test executions, as the paths can vary with each
>>> build), but in the end if it means the update manager will work
>>> better (particularly for Callisto), it's worth the switch, imo.
>>>
>>> Best,
>>> Rich
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25113 is a reply to message #25072] Thu, 23 February 2006 16:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Rich,

We're all agreed we should go with this new approach. We've talk to
Sonia to get more details so we know what needs to be done. We'll start
trying to do this after the M5 milestone, i.e., next week...


Richard Gronback wrote:
> Hi Nick,
>
> I learned about this "automagic" feature in this bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
> this article
> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>
> Of course, no clear instructions were found, so I poked into the
> platform's manifests and found a curious .qualifier suffix added to
> their version numbers. So, I tacked it onto ours as well and have been
> dealing with the repercussions since ;-)
>
> Best,
> Rich
>
>
>> Rich:
>>
>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>
>> If you can provide some insight into this (here, in the bug, or via
>> email directly to codeslave(at)ca.ibm.com), then I can start exploring
>> after M5.
>>
>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>
>> Cheers,
>>
>> Nick
>>
>> Ed Merks wrote:
>>
>>> Rich,
>>>
>>> I've sent a note to Nick and the rest of the group to solicit
>>> opinions, but it does seem the right way to go. Maybe that would
>>> eliminate the need for this bugzilla (or could be used to implement
>>> it).
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>>> the manifests, PDE build will replace these and take care of naming
>>>> your files accordingly, etc. We've run into some complications due
>>>> to all this (e.g. test executions, as the paths can vary with each
>>>> build), but in the end if it means the update manager will work
>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>
>>>> Best,
>>>> Rich
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25194 is a reply to message #25072] Thu, 23 February 2006 16:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------030609090504020604080802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

It was brought to my attention that doing this correctly is important to
Callisto so we are looking at doing this *immediately*. This will delay
the availability of M5 perhaps even until tomorrow. Sorry for the
inconvenience. :-(


Richard Gronback wrote:
> Hi Nick,
>
> I learned about this "automagic" feature in this bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
> this article
> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>
> Of course, no clear instructions were found, so I poked into the
> platform's manifests and found a curious .qualifier suffix added to
> their version numbers. So, I tacked it onto ours as well and have been
> dealing with the repercussions since ;-)
>
> Best,
> Rich
>
>
>> Rich:
>>
>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>
>> If you can provide some insight into this (here, in the bug, or via
>> email directly to codeslave(at)ca.ibm.com), then I can start exploring
>> after M5.
>>
>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>
>> Cheers,
>>
>> Nick
>>
>> Ed Merks wrote:
>>
>>> Rich,
>>>
>>> I've sent a note to Nick and the rest of the group to solicit
>>> opinions, but it does seem the right way to go. Maybe that would
>>> eliminate the need for this bugzilla (or could be used to implement
>>> it).
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>>> the manifests, PDE build will replace these and take care of naming
>>>> your files accordingly, etc. We've run into some complications due
>>>> to all this (e.g. test executions, as the paths can vary with each
>>>> build), but in the end if it means the update manager will work
>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>
>>>> Best,
>>>> Rich
>
>


--------------030609090504020604080802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
It was brought to my attention that doing this correctly is important
to Callisto so we are looking at doing this <b>immediately</b>.&nbsp; This
will delay the availability of M5 perhaps even until tomorrow.&nbsp; Sorry
for the inconvenience.&nbsp; :-(<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e2483429a0f8c806ad00793880@news.eclipse.org"
type="cite">Hi Nick,
<br>
<br>
I learned about this "automagic" feature in this bug
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393">https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393</a> which led me to
this article
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml"> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</a> <br>
<br>
Of course, no clear instructions were found, so I poked into the
platform's manifests and found a curious .qualifier suffix added to
their version numbers. So, I tacked it onto ours as well and have been
dealing with the repercussions since ;-)
<br>
<br>
Best,
<br>
Rich
<br>
<br>
<br>
<blockquote type="cite">Rich:
<br>
<br>
How do you make PDE replace "1.0.0.qualifier" with, for example,
<br>
"1.0.0I200602161109" ? Or does PDE do it automagically?
<br>
<br>
If you can provide some insight into this (here, in the bug, or via
<br>
email directly to codeslave(at)ca.ibm.com), then I can start exploring
<br>
after M5.
<br>
<br>
Anyway, I'll add this to my pile of never-ending TODOs. ;-)
<br>
<br>
Cheers,
<br>
<br>
Nick
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
I've sent a note to Nick and the rest of the group to solicit
<br>
opinions, but it does seem the right way to go.&nbsp;&nbsp; Maybe that would
<br>
eliminate the need for this bugzilla (or could be used to implement
<br>
it).
<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a>
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in
<br>
the manifests, PDE build will replace these and take care of naming
<br>
your files accordingly, etc.&nbsp; We've run into some complications due
<br>
to all this (e.g. test executions, as the paths can vary with each
<br>
build), but in the end if it means the update manager will work
<br>
better (particularly for Callisto), it's worth the switch, imo.
<br>
<br>
Best,
<br>
Rich
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------030609090504020604080802--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25235 is a reply to message #25194] Thu, 23 February 2006 17:32 Go to previous messageGo to next message
Vishy Ramaswamy is currently offline Vishy RamaswamyFriend
Messages: 30
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C63875.3331AB20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rich,
This will also delay the declaration of EMFT M5 bits since the build =
scripts for EMFT are using the same infra as EMF. Sorry for the =
inconvenience. :-(
Thanks
Vishy
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:dtko83$2ma$1@utils.eclipse.org...
Rich,

It was brought to my attention that doing this correctly is important =
to Callisto so we are looking at doing this immediately. This will =
delay the availability of M5 perhaps even until tomorrow. Sorry for the =
inconvenience. :-(


Richard Gronback wrote:=20
Hi Nick,=20

I learned about this "automagic" feature in this bug =
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D99393 which led me to =
this article =
http://www.eclipse.org/equinox/documents/plugin-versioning.h tml=20

Of course, no clear instructions were found, so I poked into the =
platform's manifests and found a curious .qualifier suffix added to =
their version numbers. So, I tacked it onto ours as well and have been =
dealing with the repercussions since ;-)=20

Best,=20
Rich=20



Rich:=20

How do you make PDE replace "1.0.0.qualifier" with, for example,=20
"1.0.0I200602161109" ? Or does PDE do it automagically?=20

If you can provide some insight into this (here, in the bug, or =
via=20
email directly to codeslave(at)ca.ibm.com), then I can start =
exploring=20
after M5.=20

Anyway, I'll add this to my pile of never-ending TODOs. ;-)=20

Cheers,=20

Nick=20

Ed Merks wrote:=20


Rich,=20

I've sent a note to Nick and the rest of the group to solicit=20
opinions, but it does seem the right way to go. Maybe that =
would=20
eliminate the need for this bugzilla (or could be used to =
implement=20
it).=20

https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D109127=20

Richard Gronback wrote:=20


Hi Ed,=20

Right, if you add '.qualifier' to all your Bundle-Version =
entries in=20
the manifests, PDE build will replace these and take care of =
naming=20
your files accordingly, etc. We've run into some =
complications due=20
to all this (e.g. test executions, as the paths can vary with =
each=20
build), but in the end if it means the update manager will =
work=20
better (particularly for Callisto), it's worth the switch, =
imo.=20

Best,=20
Rich=20






------=_NextPart_000_0020_01C63875.3331AB20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Rich,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This will also delay the declaration of =
EMFT M5=20
bits since the build scripts for EMFT are using the same infra as EMF. =
<FONT=20
face=3D"Times New Roman" size=3D3>Sorry for the inconvenience.&nbsp;=20
:-(</FONT><BR>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vishy</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=20
wrote in message <A=20
=
href=3D"news:dtko83$2ma$1@utils.eclipse.org">news:dtko83$2ma$1@utils.ecli=
pse.org</A>...</DIV>Rich,<BR><BR>It=20
was brought to my attention that doing this correctly is important to =
Callisto=20
so we are looking at doing this <B>immediately</B>.&nbsp; This will =
delay the=20
availability of M5 perhaps even until tomorrow.&nbsp; Sorry for the=20
inconvenience.&nbsp; :-(<BR><BR><BR>Richard Gronback wrote:=20
<BLOCKQUOTE cite=3Dmid1e2483429a0f8c806ad00793880@news.eclipse.org=20
type=3D"cite">Hi Nick, <BR><BR>I learned about this "automagic" =
feature in=20
this bug <A class=3Dmoz-txt-link-freetext=20
=
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D99393">https://bu=
gs.eclipse.org/bugs/show_bug.cgi?id=3D99393</A>=20
which led me to this article <A class=3Dmoz-txt-link-freetext=20
=
href=3D" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml">=
http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</A>=20
<BR><BR>Of course, no clear instructions were found, so I poked into =
the=20
platform's manifests and found a curious .qualifier suffix added to =
their=20
version numbers. So, I tacked it onto ours as well and have been =
dealing=20
with the repercussions since ;-) <BR><BR>Best, <BR>Rich <BR><BR><BR>
<BLOCKQUOTE type=3D"cite">Rich: <BR><BR>How do you make PDE replace=20
"1.0.0.qualifier" with, for example, <BR>"1.0.0I200602161109" ? Or =
does=20
PDE do it automagically? <BR><BR>If you can provide some insight =
into this=20
(here, in the bug, or via <BR>email directly to =
codeslave(at)ca.ibm.com),=20
then I can start exploring <BR>after M5. <BR><BR>Anyway, I'll add =
this to=20
my pile of never-ending TODOs. ;-) <BR><BR>Cheers, <BR><BR>Nick =
<BR><BR>Ed=20
Merks wrote: <BR><BR>
<BLOCKQUOTE type=3D"cite">Rich, <BR><BR>I've sent a note to Nick =
and the=20
rest of the group to solicit <BR>opinions, but it does seem the =
right=20
way to go.&nbsp;&nbsp; Maybe that would <BR>eliminate the need =
for this=20
bugzilla (or could be used to implement <BR>it). <BR><BR><A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D109127">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D109127</A>=20
<BR><BR>Richard Gronback wrote: <BR><BR>
<BLOCKQUOTE type=3D"cite">Hi Ed, <BR><BR>Right, if you add =
'.qualifier'=20
to all your Bundle-Version entries in <BR>the manifests, PDE =
build=20
will replace these and take care of naming <BR>your files =
accordingly,=20
etc.&nbsp; We've run into some complications due <BR>to all =
this (e.g.=20
test executions, as the paths can vary with each <BR>build), =
but in=20
the end if it means the update manager will work <BR>better=20
(particularly for Callisto), it's worth the switch, imo. =
<BR><BR>Best,=20
<BR>Rich=20
<BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><BR><BR></BLOCKQUOTE ><BR></BLO=
CKQUOTE></BODY></HTML>

------=_NextPart_000_0020_01C63875.3331AB20--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25317 is a reply to message #25235] Thu, 23 February 2006 17:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------060901000709090409000405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Guys,

Note that Eclipse is spinning an M5a

https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866>

so we will delay producing M5 for EMF and EMFT until then, which gives
us more time to get this qualifier issue right too.


Vishy Ramaswamy wrote:
> Hi Rich,
> This will also delay the declaration of EMFT M5 bits since the build
> scripts for EMFT are using the same infra as EMF. Sorry for the
> inconvenience. :-(
> Thanks
> Vishy
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:dtko83$2ma$1@utils.eclipse.org...
> Rich,
>
> It was brought to my attention that doing this correctly is
> important to Callisto so we are looking at doing this
> *immediately*. This will delay the availability of M5 perhaps
> even until tomorrow. Sorry for the inconvenience. :-(
>
>
> Richard Gronback wrote:
>> Hi Nick,
>>
>> I learned about this "automagic" feature in this bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me
>> to this article
>> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>>
>> Of course, no clear instructions were found, so I poked into the
>> platform's manifests and found a curious .qualifier suffix added
>> to their version numbers. So, I tacked it onto ours as well and
>> have been dealing with the repercussions since ;-)
>>
>> Best,
>> Rich
>>
>>
>>> Rich:
>>>
>>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>>
>>> If you can provide some insight into this (here, in the bug, or via
>>> email directly to codeslave(at)ca.ibm.com), then I can start
>>> exploring
>>> after M5.
>>>
>>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Ed Merks wrote:
>>>
>>>> Rich,
>>>>
>>>> I've sent a note to Nick and the rest of the group to solicit
>>>> opinions, but it does seem the right way to go. Maybe that would
>>>> eliminate the need for this bugzilla (or could be used to
>>>> implement
>>>> it).
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Right, if you add '.qualifier' to all your Bundle-Version
>>>>> entries in
>>>>> the manifests, PDE build will replace these and take care of
>>>>> naming
>>>>> your files accordingly, etc. We've run into some
>>>>> complications due
>>>>> to all this (e.g. test executions, as the paths can vary with
>>>>> each
>>>>> build), but in the end if it means the update manager will work
>>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>>
>>>>> Best,
>>>>> Rich
>>
>>
>


--------------060901000709090409000405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
Note that Eclipse is spinning an M5a<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866">https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866
</a><br>
</blockquote>
so we will delay producing M5 for EMF and EMFT until then, which gives
us more time to get this qualifier issue right too.<br>
<br>
<br>
Vishy Ramaswamy wrote:
<blockquote cite="middtkrj8$hae$1@utils.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2800.1528" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Rich,</font></div>
<div><font face="Arial" size="2">This will also delay the declaration
of EMFT M5 bits since the build scripts for EMFT are using the same
infra as EMF. <font face="Times New Roman" size="3">Sorry for the
inconvenience.&nbsp; :-(</font><br>
Thanks</font></div>
<div><font face="Arial" size="2">Vishy</font></div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" &lt;<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>&gt;
wrote in message <a href="news:dtko83$2ma$1@utils.eclipse.org">news:dtko83$2ma$1@utils.eclipse.org</a>...</div>
Rich,<br>
<br>
It was brought to my attention that doing this correctly is important
to Callisto so we are looking at doing this <b>immediately</b>.&nbsp; This
will delay the availability of M5 perhaps even until tomorrow.&nbsp; Sorry
for the inconvenience.&nbsp; :-(<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e2483429a0f8c806ad00793880@news.eclipse.org"
type="cite">Hi Nick, <br>
<br>
I learned about this "automagic" feature in this bug <a
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393">https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393</a>
which led me to this article <a class="moz-txt-link-freetext"
href=" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml"> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</a>
<br>
<br>
Of course, no clear instructions were found, so I poked into the
platform's manifests and found a curious .qualifier suffix added to
their version numbers. So, I tacked it onto ours as well and have been
dealing with the repercussions since ;-) <br>
<br>
Best, <br>
Rich <br>
<br>
<br>
<blockquote type="cite">Rich: <br>
<br>
How do you make PDE replace "1.0.0.qualifier" with, for example, <br>
"1.0.0I200602161109" ? Or does PDE do it automagically? <br>
<br>
If you can provide some insight into this (here, in the bug, or via <br>
email directly to codeslave(at)ca.ibm.com), then I can start exploring <br>
after M5. <br>
<br>
Anyway, I'll add this to my pile of never-ending TODOs. ;-) <br>
<br>
Cheers, <br>
<br>
Nick <br>
<br>
Ed Merks wrote: <br>
<br>
<blockquote type="cite">Rich, <br>
<br>
I've sent a note to Nick and the rest of the group to solicit <br>
opinions, but it does seem the right way to go.&nbsp;&nbsp; Maybe that would <br>
eliminate the need for this bugzilla (or could be used to implement <br>
it). <br>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a>
<br>
<br>
Richard Gronback wrote: <br>
<br>
<blockquote type="cite">Hi Ed, <br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in <br>
the manifests, PDE build will replace these and take care of naming <br>
your files accordingly, etc.&nbsp; We've run into some complications due <br>
to all this (e.g. test executions, as the paths can vary with each <br>
build), but in the end if it means the update manager will work <br>
better (particularly for Callisto), it's worth the switch, imo. <br>
<br>
Best, <br>
Rich <br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>

--------------060901000709090409000405--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #25358 is a reply to message #25194] Thu, 23 February 2006 19:14 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
OK, thanks for the update.

> Rich,
>
> It was brought to my attention that doing this correctly is important
> to Callisto so we are looking at doing this *immediately*. This will
> delay the availability of M5 perhaps even until tomorrow. Sorry for
> the inconvenience. :-(
>
> Richard Gronback wrote:
>
>> Hi Nick,
>>
>> I learned about this "automagic" feature in this bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
>> this article
>> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>>
>> Of course, no clear instructions were found, so I poked into the
>> platform's manifests and found a curious .qualifier suffix added to
>> their version numbers. So, I tacked it onto ours as well and have
>> been dealing with the repercussions since ;-)
>>
>> Best,
>> Rich
>>> Rich:
>>>
>>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>>
>>> If you can provide some insight into this (here, in the bug, or via
>>> email directly to codeslave(at)ca.ibm.com), then I can start
>>> exploring after M5.
>>>
>>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Ed Merks wrote:
>>>
>>>> Rich,
>>>>
>>>> I've sent a note to Nick and the rest of the group to solicit
>>>> opinions, but it does seem the right way to go. Maybe that would
>>>> eliminate the need for this bugzilla (or could be used to implement
>>>> it).
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Right, if you add '.qualifier' to all your Bundle-Version entries
>>>>> in the manifests, PDE build will replace these and take care of
>>>>> naming your files accordingly, etc. We've run into some
>>>>> complications due to all this (e.g. test executions, as the paths
>>>>> can vary with each build), but in the end if it means the update
>>>>> manager will work better (particularly for Callisto), it's worth
>>>>> the switch, imo.
>>>>>
>>>>> Best,
>>>>> Rich
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #567681 is a reply to message #23425] Thu, 16 February 2006 22:58 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi,

It seems the validation build did not make it to the update site. Only last
week's is available, while all other EMFT builds are there.

Thanks,
Rich

> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
> http://download.eclipse.org/technology/emft/downloads/?proj= validation
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #567863 is a reply to message #23510] Fri, 17 February 2006 17:20 Go to previous message
Nick Boldt is currently offline Nick BoldtFriend
Messages: 481
Registered: July 2009
Senior Member
Richard Gronback wrote:
> Hi,
> It seems the validation build did not make it to the update site. Only
> last week's is available, while all other EMFT builds are there.
>
> Thanks,
> Rich
>
>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>> http://download.eclipse.org/technology/emft/downloads/?proj= validation
>>
>
>

That's weird. I'll look into it.
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568378 is a reply to message #23726] Wed, 22 February 2006 13:37 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Nick,

Any luck on this, or should we just wait for this week's I-builds?

Thanks,
Rich

> Richard Gronback wrote:
>
>> Hi,
>> It seems the validation build did not make it to the update site.
>> Only
>> last week's is available, while all other EMFT builds are there.
>> Thanks,
>> Rich
>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>> http://download.eclipse.org/technology/emft/downloads/?proj= validati
>>> on
>>>
> That's weird. I'll look into it.
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568489 is a reply to message #24253] Wed, 22 February 2006 13:42 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000409040904020000020709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

Is this the right thing?

http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&s=1.0.0/I200602161109
< http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&s=1.0.0/I200602161109>


Richard Gronback wrote:

> Hi Nick,
>
> Any luck on this, or should we just wait for this week's I-builds?
>
> Thanks,
> Rich
>
>> Richard Gronback wrote:
>>
>>> Hi,
>>> It seems the validation build did not make it to the update site.
>>> Only
>>> last week's is available, while all other EMFT builds are there.
>>> Thanks,
>>> Rich
>>>
>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>> http://download.eclipse.org/technology/emft/downloads/?proj= validati
>>>> on
>>>>
>> That's weird. I'll look into it.
>>
>
>


--------------000409040904020000020709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
Is this the right thing?<br>
<blockquote><a
href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&amp;s=1.0.0/I200602161109"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer.php?proj=validation&amp;s=1.0.0/I200602161109</a><br>
</blockquote>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299038c805d4a804cb10@news.eclipse.org"
type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj= validati"> http://download.eclipse.org/technology/emft/downloads/?proj= validati</a>
<br>
on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------000409040904020000020709--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568527 is a reply to message #24336] Wed, 22 February 2006 14:07 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Ed,

Yes, we switched to using the zip from the download site in our build, but
we prefer to pull from the update sites via the command line to install our
dependencies.

Odd as it seems, the mixture of this one zip with the other dependencies
installed via update manager seems to cause the org.eclipse.emf.validation.ocl
plug-in not to load, and results in the failure of one of our tests (but
not when invoked from our workspaces... that's the odd part). We will look
into this further, but were wondering in the meantime if we will be back
in business tomorrow with full update site availability of all EMFT dependencies
we use in GMF's build.

Another thing that seems odd about the contents of the download zips is that
its plug-ins have no qualifier tag in their naming, while those that are
provided via the update site do. (?)

Oh, one more question while we're on the subject... will EMFT be producing
a milestone build in the Callisto M5 timeframe, or sticking to weekly I-builds
for now?

Thanks!
- Rich

> Rich,
>
> Is this the right thing?
>
>
> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer
> .php?proj=validation&s=1.0.0/I200602161109
>
> < http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe
> r.php?proj=validation&s=1.0.0/I200602161109>
> Richard Gronback wrote:
>
>> Hi Nick,
>>
>> Any luck on this, or should we just wait for this week's I-builds?
>>
>> Thanks,
>> Rich
>>> Richard Gronback wrote:
>>>
>>>> Hi,
>>>> It seems the validation build did not make it to the update site.
>>>> Only
>>>> last week's is available, while all other EMFT builds are there.
>>>> Thanks,
>>>> Rich
>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= valida
>>>>> ti on
>>>>>
>>> That's weird. I'll look into it.
>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568596 is a reply to message #24376] Wed, 22 February 2006 14:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000805090007070501060401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

I see, so it's the update site that's messed up. We'll need to be
especially careful about that this week to ensure that all these things
are complete, since we really would like this week's EMF and EMFT builds
to be the M5 milestones.

Looking at that zip file I see this:

eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar

Is the _1.0.0 the qualifier?

I was expecting we would produce M5 builds for EMFT, but I'd better
confirm that with Nick and company. ;-)


Richard Gronback wrote:

> Hi Ed,
>
> Yes, we switched to using the zip from the download site in our build,
> but we prefer to pull from the update sites via the command line to
> install our dependencies.
>
> Odd as it seems, the mixture of this one zip with the other
> dependencies installed via update manager seems to cause the
> org.eclipse.emf.validation.ocl plug-in not to load, and results in the
> failure of one of our tests (but not when invoked from our
> workspaces... that's the odd part). We will look into this further,
> but were wondering in the meantime if we will be back in business
> tomorrow with full update site availability of all EMFT dependencies
> we use in GMF's build.
> Another thing that seems odd about the contents of the download zips
> is that its plug-ins have no qualifier tag in their naming, while
> those that are provided via the update site do. (?)
>
> Oh, one more question while we're on the subject... will EMFT be
> producing a milestone build in the Callisto M5 timeframe, or sticking
> to weekly I-builds for now?
>
> Thanks!
> - Rich
>
>> Rich,
>>
>> Is this the right thing?
>>
>>
>> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer
>> .php?proj=validation&s=1.0.0/I200602161109
>>
>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe
>> r.php?proj=validation&s=1.0.0/I200602161109>
>> Richard Gronback wrote:
>>
>>> Hi Nick,
>>>
>>> Any luck on this, or should we just wait for this week's I-builds?
>>>
>>> Thanks,
>>> Rich
>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi,
>>>>> It seems the validation build did not make it to the update site.
>>>>> Only
>>>>> last week's is available, while all other EMFT builds are there.
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= valida
>>>>>> ti on
>>>>>>
>>>> That's weird. I'll look into it.
>>>>
>
>


--------------000805090007070501060401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
I see, so it's the update site that's messed up.&nbsp; We'll need to be
especially careful about that this week to ensure that all these things
are complete, since we really would like this week's EMF and EMFT
builds to be the M5 milestones.<br>
<br>
Looking at that zip file I see this:<br>
<blockquote>eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar <br>
</blockquote>
Is the _1.0.0 the qualifier?<br>
<br>
I was expecting we would produce M5 builds for EMFT, but I'd better
confirm that with Nick and company. ;-)<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299078c805d8c7c9bcf0@news.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Yes, we switched to using the zip from the download site in our build,
but we prefer to pull from the update sites via the command line to
install our dependencies.
<br>
<br>
Odd as it seems, the mixture of this one zip with the other
dependencies installed via update manager seems to cause the
org.eclipse.emf.validation.ocl plug-in not to load, and results in the
failure of one of our tests (but not when invoked from our
workspaces... that's the odd part).&nbsp; We will look into this further,
but were wondering in the meantime if we will be back in business
tomorrow with full update site availability of all EMFT dependencies we
use in GMF's build.&nbsp; <br>
Another thing that seems odd about the contents of the download zips is
that its plug-ins have no qualifier tag in their naming, while those
that are provided via the update site do. (?)
<br>
<br>
Oh, one more question while we're on the subject... will EMFT be
producing a milestone build in the Callisto M5 timeframe, or sticking
to weekly I-builds for now?
<br>
<br>
Thanks!
<br>
- Rich
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
Is this the right thing?
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewer</a>
<br>
..php?proj=validation&amp;s=1.0.0/I200602161109
<br>
<br>
&lt;<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe"> http://download.eclipse.org/technology/emft/downloads/downlo ads-viewe</a>
<br>
r.php?proj=validation&amp;s=1.0.0/I200602161109&gt;
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj= valida"> http://download.eclipse.org/technology/emft/downloads/?proj= valida</a>
<br>
ti on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------000805090007070501060401--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568643 is a reply to message #24417] Wed, 22 February 2006 14:25 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Thanks Ed.

The update site jars are named like this: org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar
where the '.qualifier' suffix on the version number is (should be) substituted
by the PDE build automatically with the build ID (typically).

Best,
Rich


> Rich,
>
> I see, so it's the update site that's messed up. We'll need to be
> especially careful about that this week to ensure that all these
> things are complete, since we really would like this week's EMF and
> EMFT builds to be the M5 milestones.
>
> Looking at that zip file I see this:
>
> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>
> Is the _1.0.0 the qualifier?
>
> I was expecting we would produce M5 builds for EMFT, but I'd better
> confirm that with Nick and company. ;-)
>
> Richard Gronback wrote:
>
>> Hi Ed,
>>
>> Yes, we switched to using the zip from the download site in our
>> build, but we prefer to pull from the update sites via the command
>> line to install our dependencies.
>>
>> Odd as it seems, the mixture of this one zip with the other
>> dependencies installed via update manager seems to cause the
>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>> the failure of one of our tests (but not when invoked from our
>> workspaces... that's the odd part). We will look into this further,
>> but were wondering in the meantime if we will be back in business
>> tomorrow with full update site availability of all EMFT dependencies
>> we use in GMF's build. Another thing that seems odd about the
>> contents of the download zips is that its plug-ins have no qualifier
>> tag in their naming, while those that are provided via the update
>> site do. (?)
>>
>> Oh, one more question while we're on the subject... will EMFT be
>> producing a milestone build in the Callisto M5 timeframe, or sticking
>> to weekly I-builds for now?
>>
>> Thanks!
>> - Rich
>>> Rich,
>>>
>>> Is this the right thing?
>>>
>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
>>> er .php?proj=validation&s=1.0.0/I200602161109
>>>
>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
>>> we
>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>> Richard Gronback wrote:
>>>> Hi Nick,
>>>>
>>>> Any luck on this, or should we just wait for this week's I-builds?
>>>>
>>>> Thanks,
>>>> Rich
>>>>> Richard Gronback wrote:
>>>>>
>>>>>> Hi,
>>>>>> It seems the validation build did not make it to the update site.
>>>>>> Only
>>>>>> last week's is available, while all other EMFT builds are there.
>>>>>> Thanks,
>>>>>> Rich
>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
>>>>>>> da ti on
>>>>>>>
>>>>> That's weird. I'll look into it.
>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568810 is a reply to message #24459] Wed, 22 February 2006 20:41 Go to previous message
Vishy Ramaswamy is currently offline Vishy RamaswamyFriend
Messages: 30
Registered: July 2009
Member
Hi Rich and Ed,
The EMFT components (validation, transaction. ocl and query) will be
producing M5 milestone builds tomorrow (obviously after the EMF M5 build is
declared).
Cheers
Vishy

"Richard Gronback" <richard.gronback@borland.com> wrote in message
news:1e248342990e8c805db56d4d130@news.eclipse.org...
> Thanks Ed.
>
> The update site jars are named like this:
org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar
> where the '.qualifier' suffix on the version number is (should be)
substituted
> by the PDE build automatically with the build ID (typically).
>
> Best,
> Rich
>
>
> > Rich,
> >
> > I see, so it's the update site that's messed up. We'll need to be
> > especially careful about that this week to ensure that all these
> > things are complete, since we really would like this week's EMF and
> > EMFT builds to be the M5 milestones.
> >
> > Looking at that zip file I see this:
> >
> > eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
> >
> > Is the _1.0.0 the qualifier?
> >
> > I was expecting we would produce M5 builds for EMFT, but I'd better
> > confirm that with Nick and company. ;-)
> >
> > Richard Gronback wrote:
> >
> >> Hi Ed,
> >>
> >> Yes, we switched to using the zip from the download site in our
> >> build, but we prefer to pull from the update sites via the command
> >> line to install our dependencies.
> >>
> >> Odd as it seems, the mixture of this one zip with the other
> >> dependencies installed via update manager seems to cause the
> >> org.eclipse.emf.validation.ocl plug-in not to load, and results in
> >> the failure of one of our tests (but not when invoked from our
> >> workspaces... that's the odd part). We will look into this further,
> >> but were wondering in the meantime if we will be back in business
> >> tomorrow with full update site availability of all EMFT dependencies
> >> we use in GMF's build. Another thing that seems odd about the
> >> contents of the download zips is that its plug-ins have no qualifier
> >> tag in their naming, while those that are provided via the update
> >> site do. (?)
> >>
> >> Oh, one more question while we're on the subject... will EMFT be
> >> producing a milestone build in the Callisto M5 timeframe, or sticking
> >> to weekly I-builds for now?
> >>
> >> Thanks!
> >> - Rich
> >>> Rich,
> >>>
> >>> Is this the right thing?
> >>>
> >>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
> >>> er .php?proj=validation&s=1.0.0/I200602161109
> >>>
> >>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
> >>> we
> >>> r.php?proj=validation&s=1.0.0/I200602161109>
> >>> Richard Gronback wrote:
> >>>> Hi Nick,
> >>>>
> >>>> Any luck on this, or should we just wait for this week's I-builds?
> >>>>
> >>>> Thanks,
> >>>> Rich
> >>>>> Richard Gronback wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> It seems the validation build did not make it to the update site.
> >>>>>> Only
> >>>>>> last week's is available, while all other EMFT builds are there.
> >>>>>> Thanks,
> >>>>>> Rich
> >>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
> >>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
> >>>>>>> da ti on
> >>>>>>>
> >>>>> That's weird. I'll look into it.
> >>>>>
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568841 is a reply to message #24459] Wed, 22 February 2006 20:49 Go to previous message
Nick Boldt is currently offline Nick BoldtFriend
Messages: 481
Registered: July 2009
Senior Member
The difference between _1.0.0 and _1.0.0.I200601261257 has been there
since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
the qualifier, only the UM jars.

This is because if you're downloading the zip, you will replace the old
content w/ the new content (or copy on top) and thus Eclipse will be
fine finding and resolving plugins.

But with UM installs, each release must be numbered greater than the
last or UM won't consider the content newer than what's already
installed, and won't present you the choice in the UM Wizard. To UM,
1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
1.0.0.IyyyymmddHHMM so that they can be installed sequentially. However,
due to a "feature" of UM and the way we suffix these jars, an I build
will always be considered "older" than an S build even if the I build's
datestamp is newer, since alphabetically, I < S. The workaround here is
to uncheck the box for "only latest" so that you can see I builds that
are newer than the S builds.

At some point, we might reverse this scheme so that we place the build
type code at the end (eg., 200601261257I), if enough people would find
that valuable.

[This is your cue to open a bug and have others vote on it. ;)]

Anyhoo... that aside, I'm still no closer to understanding why 3/5
updates worked fine but EODM and Validation failed (using the same code
to do the update!). It looks like there's something wrong with either
the SCP process itself or the compare process I do to verify that the
upload succeeded. Anyway, I'm hoping it's transient and that it won't
happen again tomorrow. If it does, I'll be sure the jars get there
manually if necessary.

Cheers,

Nick

Richard Gronback wrote:
> Thanks Ed.
>
> The update site jars are named like this:
> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
> '.qualifier' suffix on the version number is (should be) substituted by
> the PDE build automatically with the build ID (typically).
>
> Best,
> Rich
>
>
>> Rich,
>>
>> I see, so it's the update site that's messed up. We'll need to be
>> especially careful about that this week to ensure that all these
>> things are complete, since we really would like this week's EMF and
>> EMFT builds to be the M5 milestones.
>>
>> Looking at that zip file I see this:
>>
>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>
>> Is the _1.0.0 the qualifier?
>>
>> I was expecting we would produce M5 builds for EMFT, but I'd better
>> confirm that with Nick and company. ;-)
>>
>> Richard Gronback wrote:
>>
>>> Hi Ed,
>>>
>>> Yes, we switched to using the zip from the download site in our
>>> build, but we prefer to pull from the update sites via the command
>>> line to install our dependencies.
>>>
>>> Odd as it seems, the mixture of this one zip with the other
>>> dependencies installed via update manager seems to cause the
>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>> the failure of one of our tests (but not when invoked from our
>>> workspaces... that's the odd part). We will look into this further,
>>> but were wondering in the meantime if we will be back in business
>>> tomorrow with full update site availability of all EMFT dependencies
>>> we use in GMF's build. Another thing that seems odd about the
>>> contents of the download zips is that its plug-ins have no qualifier
>>> tag in their naming, while those that are provided via the update
>>> site do. (?)
>>>
>>> Oh, one more question while we're on the subject... will EMFT be
>>> producing a milestone build in the Callisto M5 timeframe, or sticking
>>> to weekly I-builds for now?
>>>
>>> Thanks!
>>> - Rich
>>>> Rich,
>>>>
>>>> Is this the right thing?
>>>>
>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-view
>>>> er .php?proj=validation&s=1.0.0/I200602161109
>>>>
>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-vie
>>>> we
>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>> Richard Gronback wrote:
>>>>> Hi Nick,
>>>>>
>>>>> Any luck on this, or should we just wait for this week's I-builds?
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>> Richard Gronback wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> It seems the validation build did not make it to the update site.
>>>>>>> Only
>>>>>>> last week's is available, while all other EMFT builds are there.
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= vali
>>>>>>>> da ti on
>>>>>>>>
>>>>>> That's weird. I'll look into it.
>>>>>>
>
>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #568980 is a reply to message #24621] Thu, 23 February 2006 09:37 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Thanks, Nick.

I'm not so interested in the UI of update manager, as we utilize the command
line interface to directly request specified builds. It does seem odd that
EMF[T] has two different naming conventions depending upon whether UM or
zips are produced. The GMF build simply uses the PDE build to generate both,
while I understand you have your own (working!) scripts, so no big deal really.

Looking forward to today's M5 builds.

Thanks again,
Rich



> The difference between _1.0.0 and _1.0.0.I200601261257 has been there
> since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
> the qualifier, only the UM jars.
>
> This is because if you're downloading the zip, you will replace the
> old content w/ the new content (or copy on top) and thus Eclipse will
> be fine finding and resolving plugins.
>
> But with UM installs, each release must be numbered greater than the
> last or UM won't consider the content newer than what's already
> installed, and won't present you the choice in the UM Wizard. To UM,
> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
> However, due to a "feature" of UM and the way we suffix these jars, an
> I build will always be considered "older" than an S build even if the
> I build's datestamp is newer, since alphabetically, I < S. The
> workaround here is to uncheck the box for "only latest" so that you
> can see I builds that are newer than the S builds.
>
> At some point, we might reverse this scheme so that we place the build
> type code at the end (eg., 200601261257I), if enough people would find
> that valuable.
>
> [This is your cue to open a bug and have others vote on it. ;)]
>
> Anyhoo... that aside, I'm still no closer to understanding why 3/5
> updates worked fine but EODM and Validation failed (using the same
> code to do the update!). It looks like there's something wrong with
> either the SCP process itself or the compare process I do to verify
> that the upload succeeded. Anyway, I'm hoping it's transient and that
> it won't happen again tomorrow. If it does, I'll be sure the jars get
> there manually if necessary.
>
> Cheers,
>
> Nick
>
> Richard Gronback wrote:
>
>> Thanks Ed.
>>
>> The update site jars are named like this:
>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>> '.qualifier' suffix on the version number is (should be) substituted
>> by the PDE build automatically with the build ID (typically).
>>
>> Best,
>> Rich
>>> Rich,
>>>
>>> I see, so it's the update site that's messed up. We'll need to be
>>> especially careful about that this week to ensure that all these
>>> things are complete, since we really would like this week's EMF and
>>> EMFT builds to be the M5 milestones.
>>>
>>> Looking at that zip file I see this:
>>>
>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>
>>> Is the _1.0.0 the qualifier?
>>>
>>> I was expecting we would produce M5 builds for EMFT, but I'd better
>>> confirm that with Nick and company. ;-)
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Yes, we switched to using the zip from the download site in our
>>>> build, but we prefer to pull from the update sites via the command
>>>> line to install our dependencies.
>>>>
>>>> Odd as it seems, the mixture of this one zip with the other
>>>> dependencies installed via update manager seems to cause the
>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>>> the failure of one of our tests (but not when invoked from our
>>>> workspaces... that's the odd part). We will look into this
>>>> further, but were wondering in the meantime if we will be back in
>>>> business tomorrow with full update site availability of all EMFT
>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>> about the contents of the download zips is that its plug-ins have
>>>> no qualifier tag in their naming, while those that are provided via
>>>> the update site do. (?)
>>>>
>>>> Oh, one more question while we're on the subject... will EMFT be
>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>> sticking to weekly I-builds for now?
>>>>
>>>> Thanks!
>>>> - Rich
>>>>> Rich,
>>>>>
>>>>> Is this the right thing?
>>>>>
>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-vi
>>>>> ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>
>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-v
>>>>> ie
>>>>> we
>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>> Richard Gronback wrote:
>>>>>> Hi Nick,
>>>>>>
>>>>>> Any luck on this, or should we just wait for this week's
>>>>>> I-builds?
>>>>>>
>>>>>> Thanks,
>>>>>> Rich
>>>>>>> Richard Gronback wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>> site.
>>>>>>>> Only
>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>> there.
>>>>>>>> Thanks,
>>>>>>>> Rich
>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= va
>>>>>>>>> li da ti on
>>>>>>>>>
>>>>>>> That's weird. I'll look into it.
>>>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569040 is a reply to message #24778] Thu, 23 February 2006 11:06 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rich,

Adding build versions to the jar names in the zip is a fairly recently
platform change. Perhaps we should do the same thing now too? We're
just using the PDE build as well, but with some added bonus features.
;-) The platform plugins seem to to be directly updating the
Bundle-Version in the MANIFEST.MF with each build and I think that name
is simply reflected into the jar name. So maybe we should start doing
this updating of the MANFEST.MF too and that will produce names like we
see for the platform?


Richard Gronback wrote:
> Thanks, Nick.
>
> I'm not so interested in the UI of update manager, as we utilize the
> command line interface to directly request specified builds. It does
> seem odd that EMF[T] has two different naming conventions depending
> upon whether UM or zips are produced. The GMF build simply uses the
> PDE build to generate both, while I understand you have your own
> (working!) scripts, so no big deal really.
>
> Looking forward to today's M5 builds.
>
> Thanks again,
> Rich
>
>
>
>> The difference between _1.0.0 and _1.0.0.I200601261257 has been there
>> since Day One for EMF, UML2, and EMFT. The zips do not get tagged with
>> the qualifier, only the UM jars.
>>
>> This is because if you're downloading the zip, you will replace the
>> old content w/ the new content (or copy on top) and thus Eclipse will
>> be fine finding and resolving plugins.
>>
>> But with UM installs, each release must be numbered greater than the
>> last or UM won't consider the content newer than what's already
>> installed, and won't present you the choice in the UM Wizard. To UM,
>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>> However, due to a "feature" of UM and the way we suffix these jars, an
>> I build will always be considered "older" than an S build even if the
>> I build's datestamp is newer, since alphabetically, I < S. The
>> workaround here is to uncheck the box for "only latest" so that you
>> can see I builds that are newer than the S builds.
>>
>> At some point, we might reverse this scheme so that we place the build
>> type code at the end (eg., 200601261257I), if enough people would find
>> that valuable.
>>
>> [This is your cue to open a bug and have others vote on it. ;)]
>>
>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>> updates worked fine but EODM and Validation failed (using the same
>> code to do the update!). It looks like there's something wrong with
>> either the SCP process itself or the compare process I do to verify
>> that the upload succeeded. Anyway, I'm hoping it's transient and that
>> it won't happen again tomorrow. If it does, I'll be sure the jars get
>> there manually if necessary.
>>
>> Cheers,
>>
>> Nick
>>
>> Richard Gronback wrote:
>>
>>> Thanks Ed.
>>>
>>> The update site jars are named like this:
>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>> '.qualifier' suffix on the version number is (should be) substituted
>>> by the PDE build automatically with the build ID (typically).
>>>
>>> Best,
>>> Rich
>>>> Rich,
>>>>
>>>> I see, so it's the update site that's messed up. We'll need to be
>>>> especially careful about that this week to ensure that all these
>>>> things are complete, since we really would like this week's EMF and
>>>> EMFT builds to be the M5 milestones.
>>>>
>>>> Looking at that zip file I see this:
>>>>
>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>
>>>> Is the _1.0.0 the qualifier?
>>>>
>>>> I was expecting we would produce M5 builds for EMFT, but I'd better
>>>> confirm that with Nick and company. ;-)
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Yes, we switched to using the zip from the download site in our
>>>>> build, but we prefer to pull from the update sites via the command
>>>>> line to install our dependencies.
>>>>>
>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>> dependencies installed via update manager seems to cause the
>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results in
>>>>> the failure of one of our tests (but not when invoked from our
>>>>> workspaces... that's the odd part). We will look into this
>>>>> further, but were wondering in the meantime if we will be back in
>>>>> business tomorrow with full update site availability of all EMFT
>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>> about the contents of the download zips is that its plug-ins have
>>>>> no qualifier tag in their naming, while those that are provided via
>>>>> the update site do. (?)
>>>>>
>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>> sticking to weekly I-builds for now?
>>>>>
>>>>> Thanks!
>>>>> - Rich
>>>>>> Rich,
>>>>>>
>>>>>> Is this the right thing?
>>>>>>
>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-vi
>>>>>> ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>
>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads-v
>>>>>> ie
>>>>>> we
>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>> Richard Gronback wrote:
>>>>>>> Hi Nick,
>>>>>>>
>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>> I-builds?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>> Richard Gronback wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>> site.
>>>>>>>>> Only
>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>> there.
>>>>>>>>> Thanks,
>>>>>>>>> Rich
>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj= va
>>>>>>>>>> li da ti on
>>>>>>>>>>
>>>>>>>> That's weird. I'll look into it.
>>>>>>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569073 is a reply to message #24814] Thu, 23 February 2006 11:18 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Ed,

Right, if you add '.qualifier' to all your Bundle-Version entries in the
manifests, PDE build will replace these and take care of naming your files
accordingly, etc. We've run into some complications due to all this (e.g.
test executions, as the paths can vary with each build), but in the end if
it means the update manager will work better (particularly for Callisto),
it's worth the switch, imo.

Best,
Rich

> Rich,
>
> Adding build versions to the jar names in the zip is a fairly recently
> platform change. Perhaps we should do the same thing now too? We're
> just using the PDE build as well, but with some added bonus features.
> ;-) The platform plugins seem to to be directly updating the
> Bundle-Version in the MANIFEST.MF with each build and I think that
> name is simply reflected into the jar name. So maybe we should start
> doing this updating of the MANFEST.MF too and that will produce names
> like we see for the platform?
>
> Richard Gronback wrote:
>
>> Thanks, Nick.
>>
>> I'm not so interested in the UI of update manager, as we utilize the
>> command line interface to directly request specified builds. It does
>> seem odd that EMF[T] has two different naming conventions depending
>> upon whether UM or zips are produced. The GMF build simply uses the
>> PDE build to generate both, while I understand you have your own
>> (working!) scripts, so no big deal really.
>>
>> Looking forward to today's M5 builds.
>>
>> Thanks again,
>> Rich
>>> The difference between _1.0.0 and _1.0.0.I200601261257 has been
>>> there since Day One for EMF, UML2, and EMFT. The zips do not get
>>> tagged with the qualifier, only the UM jars.
>>>
>>> This is because if you're downloading the zip, you will replace the
>>> old content w/ the new content (or copy on top) and thus Eclipse
>>> will be fine finding and resolving plugins.
>>>
>>> But with UM installs, each release must be numbered greater than the
>>> last or UM won't consider the content newer than what's already
>>> installed, and won't present you the choice in the UM Wizard. To UM,
>>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>>> However, due to a "feature" of UM and the way we suffix these jars,
>>> an I build will always be considered "older" than an S build even if
>>> the I build's datestamp is newer, since alphabetically, I < S. The
>>> workaround here is to uncheck the box for "only latest" so that you
>>> can see I builds that are newer than the S builds.
>>>
>>> At some point, we might reverse this scheme so that we place the
>>> build type code at the end (eg., 200601261257I), if enough people
>>> would find that valuable.
>>>
>>> [This is your cue to open a bug and have others vote on it. ;)]
>>>
>>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>>> updates worked fine but EODM and Validation failed (using the same
>>> code to do the update!). It looks like there's something wrong with
>>> either the SCP process itself or the compare process I do to verify
>>> that the upload succeeded. Anyway, I'm hoping it's transient and
>>> that it won't happen again tomorrow. If it does, I'll be sure the
>>> jars get there manually if necessary.
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Richard Gronback wrote:
>>>
>>>> Thanks Ed.
>>>>
>>>> The update site jars are named like this:
>>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>>> '.qualifier' suffix on the version number is (should be)
>>>> substituted by the PDE build automatically with the build ID
>>>> (typically).
>>>>
>>>> Best,
>>>> Rich
>>>>> Rich,
>>>>>
>>>>> I see, so it's the update site that's messed up. We'll need to be
>>>>> especially careful about that this week to ensure that all these
>>>>> things are complete, since we really would like this week's EMF
>>>>> and EMFT builds to be the M5 milestones.
>>>>>
>>>>> Looking at that zip file I see this:
>>>>>
>>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>>
>>>>> Is the _1.0.0 the qualifier?
>>>>>
>>>>> I was expecting we would produce M5 builds for EMFT, but I'd
>>>>> better confirm that with Nick and company. ;-)
>>>>>
>>>>> Richard Gronback wrote:
>>>>>
>>>>>> Hi Ed,
>>>>>>
>>>>>> Yes, we switched to using the zip from the download site in our
>>>>>> build, but we prefer to pull from the update sites via the
>>>>>> command line to install our dependencies.
>>>>>>
>>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>>> dependencies installed via update manager seems to cause the
>>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results
>>>>>> in the failure of one of our tests (but not when invoked from our
>>>>>> workspaces... that's the odd part). We will look into this
>>>>>> further, but were wondering in the meantime if we will be back in
>>>>>> business tomorrow with full update site availability of all EMFT
>>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>>> about the contents of the download zips is that its plug-ins have
>>>>>> no qualifier tag in their naming, while those that are provided
>>>>>> via the update site do. (?)
>>>>>>
>>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>>> sticking to weekly I-builds for now?
>>>>>>
>>>>>> Thanks!
>>>>>> - Rich
>>>>>>> Rich,
>>>>>>>
>>>>>>> Is this the right thing?
>>>>>>>
>>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-
>>>>>>> vi ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>>
>>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads
>>>>>>> -v
>>>>>>> ie
>>>>>>> we
>>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>>> Richard Gronback wrote:
>>>>>>>> Hi Nick,
>>>>>>>>
>>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>>> I-builds?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rich
>>>>>>>>> Richard Gronback wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>>> site.
>>>>>>>>>> Only
>>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>>> there.
>>>>>>>>>> Thanks,
>>>>>>>>>> Rich
>>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj=
>>>>>>>>>>> va li da ti on
>>>>>>>>>>>
>>>>>>>>> That's weird. I'll look into it.
>>>>>>>>>
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569106 is a reply to message #24849] Thu, 23 February 2006 11:55 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090501080206020704060308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

I've sent a note to Nick and the rest of the group to solicit opinions,
but it does seem the right way to go. Maybe that would eliminate the
need for this bugzilla (or could be used to implement it).

https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127


Richard Gronback wrote:
> Hi Ed,
>
> Right, if you add '.qualifier' to all your Bundle-Version entries in
> the manifests, PDE build will replace these and take care of naming
> your files accordingly, etc. We've run into some complications due to
> all this (e.g. test executions, as the paths can vary with each
> build), but in the end if it means the update manager will work better
> (particularly for Callisto), it's worth the switch, imo.
>
> Best,
> Rich
>
>> Rich,
>>
>> Adding build versions to the jar names in the zip is a fairly recently
>> platform change. Perhaps we should do the same thing now too? We're
>> just using the PDE build as well, but with some added bonus features.
>> ;-) The platform plugins seem to to be directly updating the
>> Bundle-Version in the MANIFEST.MF with each build and I think that
>> name is simply reflected into the jar name. So maybe we should start
>> doing this updating of the MANFEST.MF too and that will produce names
>> like we see for the platform?
>>
>> Richard Gronback wrote:
>>
>>> Thanks, Nick.
>>>
>>> I'm not so interested in the UI of update manager, as we utilize the
>>> command line interface to directly request specified builds. It does
>>> seem odd that EMF[T] has two different naming conventions depending
>>> upon whether UM or zips are produced. The GMF build simply uses the
>>> PDE build to generate both, while I understand you have your own
>>> (working!) scripts, so no big deal really.
>>>
>>> Looking forward to today's M5 builds.
>>>
>>> Thanks again,
>>> Rich
>>>> The difference between _1.0.0 and _1.0.0.I200601261257 has been
>>>> there since Day One for EMF, UML2, and EMFT. The zips do not get
>>>> tagged with the qualifier, only the UM jars.
>>>>
>>>> This is because if you're downloading the zip, you will replace the
>>>> old content w/ the new content (or copy on top) and thus Eclipse
>>>> will be fine finding and resolving plugins.
>>>>
>>>> But with UM installs, each release must be numbered greater than the
>>>> last or UM won't consider the content newer than what's already
>>>> installed, and won't present you the choice in the UM Wizard. To UM,
>>>> 1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
>>>> 1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
>>>> However, due to a "feature" of UM and the way we suffix these jars,
>>>> an I build will always be considered "older" than an S build even if
>>>> the I build's datestamp is newer, since alphabetically, I < S. The
>>>> workaround here is to uncheck the box for "only latest" so that you
>>>> can see I builds that are newer than the S builds.
>>>>
>>>> At some point, we might reverse this scheme so that we place the
>>>> build type code at the end (eg., 200601261257I), if enough people
>>>> would find that valuable.
>>>>
>>>> [This is your cue to open a bug and have others vote on it. ;)]
>>>>
>>>> Anyhoo... that aside, I'm still no closer to understanding why 3/5
>>>> updates worked fine but EODM and Validation failed (using the same
>>>> code to do the update!). It looks like there's something wrong with
>>>> either the SCP process itself or the compare process I do to verify
>>>> that the upload succeeded. Anyway, I'm hoping it's transient and
>>>> that it won't happen again tomorrow. If it does, I'll be sure the
>>>> jars get there manually if necessary.
>>>>
>>>> Cheers,
>>>>
>>>> Nick
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Thanks Ed.
>>>>>
>>>>> The update site jars are named like this:
>>>>> org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
>>>>> '.qualifier' suffix on the version number is (should be)
>>>>> substituted by the PDE build automatically with the build ID
>>>>> (typically).
>>>>>
>>>>> Best,
>>>>> Rich
>>>>>> Rich,
>>>>>>
>>>>>> I see, so it's the update site that's messed up. We'll need to be
>>>>>> especially careful about that this week to ensure that all these
>>>>>> things are complete, since we really would like this week's EMF
>>>>>> and EMFT builds to be the M5 milestones.
>>>>>>
>>>>>> Looking at that zip file I see this:
>>>>>>
>>>>>> eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
>>>>>>
>>>>>> Is the _1.0.0 the qualifier?
>>>>>>
>>>>>> I was expecting we would produce M5 builds for EMFT, but I'd
>>>>>> better confirm that with Nick and company. ;-)
>>>>>>
>>>>>> Richard Gronback wrote:
>>>>>>
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> Yes, we switched to using the zip from the download site in our
>>>>>>> build, but we prefer to pull from the update sites via the
>>>>>>> command line to install our dependencies.
>>>>>>>
>>>>>>> Odd as it seems, the mixture of this one zip with the other
>>>>>>> dependencies installed via update manager seems to cause the
>>>>>>> org.eclipse.emf.validation.ocl plug-in not to load, and results
>>>>>>> in the failure of one of our tests (but not when invoked from our
>>>>>>> workspaces... that's the odd part). We will look into this
>>>>>>> further, but were wondering in the meantime if we will be back in
>>>>>>> business tomorrow with full update site availability of all EMFT
>>>>>>> dependencies we use in GMF's build. Another thing that seems odd
>>>>>>> about the contents of the download zips is that its plug-ins have
>>>>>>> no qualifier tag in their naming, while those that are provided
>>>>>>> via the update site do. (?)
>>>>>>>
>>>>>>> Oh, one more question while we're on the subject... will EMFT be
>>>>>>> producing a milestone build in the Callisto M5 timeframe, or
>>>>>>> sticking to weekly I-builds for now?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> - Rich
>>>>>>>> Rich,
>>>>>>>>
>>>>>>>> Is this the right thing?
>>>>>>>>
>>>>>>>> http://download.eclipse.org/technology/emft/downloads/downlo ads-
>>>>>>>> vi ew er .php?proj=validation&s=1.0.0/I200602161109
>>>>>>>>
>>>>>>>> < http://download.eclipse.org/technology/emft/downloads/downlo ads
>>>>>>>> -v
>>>>>>>> ie
>>>>>>>> we
>>>>>>>> r.php?proj=validation&s=1.0.0/I200602161109>
>>>>>>>> Richard Gronback wrote:
>>>>>>>>> Hi Nick,
>>>>>>>>>
>>>>>>>>> Any luck on this, or should we just wait for this week's
>>>>>>>>> I-builds?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rich
>>>>>>>>>> Richard Gronback wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> It seems the validation build did not make it to the update
>>>>>>>>>>> site.
>>>>>>>>>>> Only
>>>>>>>>>>> last week's is available, while all other EMFT builds are
>>>>>>>>>>> there.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rich
>>>>>>>>>>>> http://eclipse.org/emft/news/release-notes.php?version=1.0.0
>>>>>>>>>>>> http://download.eclipse.org/technology/emft/downloads/?proj=
>>>>>>>>>>>> va li da ti on
>>>>>>>>>>>>
>>>>>>>>>> That's weird. I'll look into it.
>>>>>>>>>>
>
>


--------------090501080206020704060308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
I've sent a note to Nick and the rest of the group to solicit opinions,
but it does seem the right way to go.&nbsp;&nbsp; Maybe that would eliminate the
need for this bugzilla (or could be used to implement it).<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a><br>
</blockquote>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e24834299ca8c8068a6d1aaee0@news.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in
the manifests, PDE build will replace these and take care of naming
your files accordingly, etc.&nbsp; We've run into some complications due to
all this (e.g. test executions, as the paths can vary with each build),
but in the end if it means the update manager will work better
(particularly for Callisto), it's worth the switch, imo.
<br>
<br>
Best,
<br>
Rich
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
Adding build versions to the jar names in the zip is a fairly recently
<br>
platform change.&nbsp; Perhaps we should do the same thing now too?&nbsp; We're
<br>
just using the PDE build as well, but with some added bonus features.
<br>
;-)&nbsp;&nbsp; The platform plugins seem to to be directly updating the
<br>
Bundle-Version in the MANIFEST.MF with each build and I think that
<br>
name is simply reflected into the jar name.&nbsp; So maybe we should start
<br>
doing this updating of the MANFEST.MF too and that will produce names
<br>
like we see for the platform?
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Thanks, Nick.
<br>
<br>
I'm not so interested in the UI of update manager, as we utilize the
<br>
command line interface to directly request specified builds.&nbsp; It does
<br>
seem odd that EMF[T] has two different naming conventions depending
<br>
upon whether UM or zips are produced.&nbsp; The GMF build simply uses the
<br>
PDE build to generate both, while I understand you have your own
<br>
(working!) scripts, so no big deal really.
<br>
<br>
Looking forward to today's M5 builds.
<br>
<br>
Thanks again,
<br>
Rich
<br>
<blockquote type="cite">The difference between _1.0.0 and
_1.0.0.I200601261257 has been
<br>
there since Day One for EMF, UML2, and EMFT. The zips do not get
<br>
tagged with the qualifier, only the UM jars.
<br>
<br>
This is because if you're downloading the zip, you will replace the
<br>
old content w/ the new content (or copy on top) and thus Eclipse
<br>
will be fine finding and resolving plugins.
<br>
<br>
But with UM installs, each release must be numbered greater than the
<br>
last or UM won't consider the content newer than what's already
<br>
installed, and won't present you the choice in the UM Wizard. To UM,
<br>
1.0.0 = 1.0.0 even if one is a week newer. To avoid this, we use
<br>
1.0.0.IyyyymmddHHMM so that they can be installed sequentially.
<br>
However, due to a "feature" of UM and the way we suffix these jars,
<br>
an I build will always be considered "older" than an S build even if
<br>
the I build's datestamp is newer,&nbsp; since alphabetically, I &lt; S. The
<br>
workaround here is to uncheck the box for "only latest" so that you
<br>
can see I builds that are newer than the S builds.
<br>
<br>
At some point, we might reverse this scheme so that we place the
<br>
build type code at the end (eg., 200601261257I), if enough people
<br>
would find that valuable.
<br>
<br>
[This is your cue to open a bug and have others vote on it. ;)]
<br>
<br>
Anyhoo... that aside, I'm still no closer to understanding why 3/5
<br>
updates worked fine but EODM and Validation failed (using the same
<br>
code to do the update!). It looks like there's something wrong with
<br>
either the SCP process itself or the compare process I do to verify
<br>
that the upload succeeded. Anyway, I'm hoping it's transient and
<br>
that it won't happen again tomorrow. If it does, I'll be sure the
<br>
jars get there manually if necessary.
<br>
<br>
Cheers,
<br>
<br>
Nick
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Thanks Ed.
<br>
<br>
The update site jars are named like this:
<br>
org.eclipse.emf.validation.ocl_1.0.0.I200601261257.jar where the
<br>
'.qualifier' suffix on the version number is (should be)
<br>
substituted by the PDE build automatically with the build ID
<br>
(typically).
<br>
<br>
Best,
<br>
Rich
<br>
<blockquote type="cite">Rich,
<br>
<br>
I see, so it's the update site that's messed up.&nbsp; We'll need to be
<br>
especially careful about that this week to ensure that all these
<br>
things are complete, since we really would like this week's EMF
<br>
and EMFT builds to be the M5 milestones.
<br>
<br>
Looking at that zip file I see this:
<br>
<br>
eclipse/plugins/org.eclipse.emf.validation_1.0.0.jar
<br>
<br>
Is the _1.0.0 the qualifier?
<br>
<br>
I was expecting we would produce M5 builds for EMFT, but I'd
<br>
better confirm that with Nick and company. ;-)
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
Yes, we switched to using the zip from the download site in our
<br>
build, but we prefer to pull from the update sites via the
<br>
command line to install our dependencies.
<br>
<br>
Odd as it seems, the mixture of this one zip with the other
<br>
dependencies installed via update manager seems to cause the
<br>
org.eclipse.emf.validation.ocl plug-in not to load, and results
<br>
in the failure of one of our tests (but not when invoked from our
<br>
workspaces... that's the odd part).&nbsp; We will look into this
<br>
further, but were wondering in the meantime if we will be back in
<br>
business tomorrow with full update site availability of all EMFT
<br>
dependencies we use in GMF's build. Another thing that seems odd
<br>
about the contents of the download zips is that its plug-ins have
<br>
no qualifier tag in their naming, while those that are provided
<br>
via the update site do. (?)
<br>
<br>
Oh, one more question while we're on the subject... will EMFT be
<br>
producing a milestone build in the Callisto M5 timeframe, or
<br>
sticking to weekly I-builds for now?
<br>
<br>
Thanks!
<br>
- Rich
<br>
<blockquote type="cite">Rich,
<br>
<br>
Is this the right thing?
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads"> http://download.eclipse.org/technology/emft/downloads/downlo ads</a>-
<br>
vi ew er .php?proj=validation&amp;s=1.0.0/I200602161109
<br>
<br>
&lt;<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/downlo ads"> http://download.eclipse.org/technology/emft/downloads/downlo ads</a>
<br>
-v
<br>
ie
<br>
we
<br>
r.php?proj=validation&amp;s=1.0.0/I200602161109&gt;
<br>
Richard Gronback wrote:
<br>
<blockquote type="cite">Hi Nick,
<br>
<br>
Any luck on this, or should we just wait for this week's
<br>
I-builds?
<br>
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite">Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
It seems the validation build did not make it to the update
<br>
site.
<br>
Only
<br>
last week's is available, while all other EMFT builds are
<br>
there.
<br>
Thanks,
<br>
Rich
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href=" http://eclipse.org/emft/news/release-notes.php?version=1.0.0"> http://eclipse.org/emft/news/release-notes.php?version=1.0.0</a>
<br>
<a class="moz-txt-link-freetext" href=" http://download.eclipse.org/technology/emft/downloads/?proj="> http://download.eclipse.org/technology/emft/downloads/?proj=</a>
<br>
va li da ti on
<br>
<br>
</blockquote>
</blockquote>
That's weird. I'll look into it.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------090501080206020704060308--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569259 is a reply to message #24881] Thu, 23 February 2006 15:09 Go to previous message
Nick Boldt is currently offline Nick BoldtFriend
Messages: 481
Registered: July 2009
Senior Member
Rich:

How do you make PDE replace "1.0.0.qualifier" with, for example,
"1.0.0I200602161109" ? Or does PDE do it automagically?

If you can provide some insight into this (here, in the bug, or via
email directly to codeslave(at)ca.ibm.com), then I can start exploring
after M5.

Anyway, I'll add this to my pile of never-ending TODOs. ;-)

Cheers,

Nick

Ed Merks wrote:
> Rich,
>
> I've sent a note to Nick and the rest of the group to solicit opinions,
> but it does seem the right way to go. Maybe that would eliminate the
> need for this bugzilla (or could be used to implement it).
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>
>
> Richard Gronback wrote:
>> Hi Ed,
>>
>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>> the manifests, PDE build will replace these and take care of naming
>> your files accordingly, etc. We've run into some complications due to
>> all this (e.g. test executions, as the paths can vary with each
>> build), but in the end if it means the update manager will work better
>> (particularly for Callisto), it's worth the switch, imo.
>>
>> Best,
>> Rich
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569287 is a reply to message #25031] Thu, 23 February 2006 15:26 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
Hi Nick,

I learned about this "automagic" feature in this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393
which led me to this article http://www.eclipse.org/equinox/documents/plugin-versioning.h tml


Of course, no clear instructions were found, so I poked into the platform's
manifests and found a curious .qualifier suffix added to their version numbers.
So, I tacked it onto ours as well and have been dealing with the repercussions
since ;-)

Best,
Rich


> Rich:
>
> How do you make PDE replace "1.0.0.qualifier" with, for example,
> "1.0.0I200602161109" ? Or does PDE do it automagically?
>
> If you can provide some insight into this (here, in the bug, or via
> email directly to codeslave(at)ca.ibm.com), then I can start exploring
> after M5.
>
> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>
> Cheers,
>
> Nick
>
> Ed Merks wrote:
>
>> Rich,
>>
>> I've sent a note to Nick and the rest of the group to solicit
>> opinions, but it does seem the right way to go. Maybe that would
>> eliminate the need for this bugzilla (or could be used to implement
>> it).
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>
>> Richard Gronback wrote:
>>
>>> Hi Ed,
>>>
>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>> the manifests, PDE build will replace these and take care of naming
>>> your files accordingly, etc. We've run into some complications due
>>> to all this (e.g. test executions, as the paths can vary with each
>>> build), but in the end if it means the update manager will work
>>> better (particularly for Callisto), it's worth the switch, imo.
>>>
>>> Best,
>>> Rich
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569318 is a reply to message #25072] Thu, 23 February 2006 16:09 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rich,

We're all agreed we should go with this new approach. We've talk to
Sonia to get more details so we know what needs to be done. We'll start
trying to do this after the M5 milestone, i.e., next week...


Richard Gronback wrote:
> Hi Nick,
>
> I learned about this "automagic" feature in this bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
> this article
> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>
> Of course, no clear instructions were found, so I poked into the
> platform's manifests and found a curious .qualifier suffix added to
> their version numbers. So, I tacked it onto ours as well and have been
> dealing with the repercussions since ;-)
>
> Best,
> Rich
>
>
>> Rich:
>>
>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>
>> If you can provide some insight into this (here, in the bug, or via
>> email directly to codeslave(at)ca.ibm.com), then I can start exploring
>> after M5.
>>
>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>
>> Cheers,
>>
>> Nick
>>
>> Ed Merks wrote:
>>
>>> Rich,
>>>
>>> I've sent a note to Nick and the rest of the group to solicit
>>> opinions, but it does seem the right way to go. Maybe that would
>>> eliminate the need for this bugzilla (or could be used to implement
>>> it).
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>>> the manifests, PDE build will replace these and take care of naming
>>>> your files accordingly, etc. We've run into some complications due
>>>> to all this (e.g. test executions, as the paths can vary with each
>>>> build), but in the end if it means the update manager will work
>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>
>>>> Best,
>>>> Rich
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569425 is a reply to message #25072] Thu, 23 February 2006 16:35 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030609090504020604080802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rich,

It was brought to my attention that doing this correctly is important to
Callisto so we are looking at doing this *immediately*. This will delay
the availability of M5 perhaps even until tomorrow. Sorry for the
inconvenience. :-(


Richard Gronback wrote:
> Hi Nick,
>
> I learned about this "automagic" feature in this bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
> this article
> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>
> Of course, no clear instructions were found, so I poked into the
> platform's manifests and found a curious .qualifier suffix added to
> their version numbers. So, I tacked it onto ours as well and have been
> dealing with the repercussions since ;-)
>
> Best,
> Rich
>
>
>> Rich:
>>
>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>
>> If you can provide some insight into this (here, in the bug, or via
>> email directly to codeslave(at)ca.ibm.com), then I can start exploring
>> after M5.
>>
>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>
>> Cheers,
>>
>> Nick
>>
>> Ed Merks wrote:
>>
>>> Rich,
>>>
>>> I've sent a note to Nick and the rest of the group to solicit
>>> opinions, but it does seem the right way to go. Maybe that would
>>> eliminate the need for this bugzilla (or could be used to implement
>>> it).
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>
>>> Richard Gronback wrote:
>>>
>>>> Hi Ed,
>>>>
>>>> Right, if you add '.qualifier' to all your Bundle-Version entries in
>>>> the manifests, PDE build will replace these and take care of naming
>>>> your files accordingly, etc. We've run into some complications due
>>>> to all this (e.g. test executions, as the paths can vary with each
>>>> build), but in the end if it means the update manager will work
>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>
>>>> Best,
>>>> Rich
>
>


--------------030609090504020604080802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rich,<br>
<br>
It was brought to my attention that doing this correctly is important
to Callisto so we are looking at doing this <b>immediately</b>.&nbsp; This
will delay the availability of M5 perhaps even until tomorrow.&nbsp; Sorry
for the inconvenience.&nbsp; :-(<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e2483429a0f8c806ad00793880@news.eclipse.org"
type="cite">Hi Nick,
<br>
<br>
I learned about this "automagic" feature in this bug
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393">https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393</a> which led me to
this article
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml"> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</a> <br>
<br>
Of course, no clear instructions were found, so I poked into the
platform's manifests and found a curious .qualifier suffix added to
their version numbers. So, I tacked it onto ours as well and have been
dealing with the repercussions since ;-)
<br>
<br>
Best,
<br>
Rich
<br>
<br>
<br>
<blockquote type="cite">Rich:
<br>
<br>
How do you make PDE replace "1.0.0.qualifier" with, for example,
<br>
"1.0.0I200602161109" ? Or does PDE do it automagically?
<br>
<br>
If you can provide some insight into this (here, in the bug, or via
<br>
email directly to codeslave(at)ca.ibm.com), then I can start exploring
<br>
after M5.
<br>
<br>
Anyway, I'll add this to my pile of never-ending TODOs. ;-)
<br>
<br>
Cheers,
<br>
<br>
Nick
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Rich,
<br>
<br>
I've sent a note to Nick and the rest of the group to solicit
<br>
opinions, but it does seem the right way to go.&nbsp;&nbsp; Maybe that would
<br>
eliminate the need for this bugzilla (or could be used to implement
<br>
it).
<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a>
<br>
<br>
Richard Gronback wrote:
<br>
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in
<br>
the manifests, PDE build will replace these and take care of naming
<br>
your files accordingly, etc.&nbsp; We've run into some complications due
<br>
to all this (e.g. test executions, as the paths can vary with each
<br>
build), but in the end if it means the update manager will work
<br>
better (particularly for Callisto), it's worth the switch, imo.
<br>
<br>
Best,
<br>
Rich
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>

--------------030609090504020604080802--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569451 is a reply to message #25194] Thu, 23 February 2006 17:32 Go to previous message
Vishy Ramaswamy is currently offline Vishy RamaswamyFriend
Messages: 30
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C63875.3331AB20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rich,
This will also delay the declaration of EMFT M5 bits since the build =
scripts for EMFT are using the same infra as EMF. Sorry for the =
inconvenience. :-(
Thanks
Vishy
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:dtko83$2ma$1@utils.eclipse.org...
Rich,

It was brought to my attention that doing this correctly is important =
to Callisto so we are looking at doing this immediately. This will =
delay the availability of M5 perhaps even until tomorrow. Sorry for the =
inconvenience. :-(


Richard Gronback wrote:=20
Hi Nick,=20

I learned about this "automagic" feature in this bug =
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D99393 which led me to =
this article =
http://www.eclipse.org/equinox/documents/plugin-versioning.h tml=20

Of course, no clear instructions were found, so I poked into the =
platform's manifests and found a curious .qualifier suffix added to =
their version numbers. So, I tacked it onto ours as well and have been =
dealing with the repercussions since ;-)=20

Best,=20
Rich=20



Rich:=20

How do you make PDE replace "1.0.0.qualifier" with, for example,=20
"1.0.0I200602161109" ? Or does PDE do it automagically?=20

If you can provide some insight into this (here, in the bug, or =
via=20
email directly to codeslave(at)ca.ibm.com), then I can start =
exploring=20
after M5.=20

Anyway, I'll add this to my pile of never-ending TODOs. ;-)=20

Cheers,=20

Nick=20

Ed Merks wrote:=20


Rich,=20

I've sent a note to Nick and the rest of the group to solicit=20
opinions, but it does seem the right way to go. Maybe that =
would=20
eliminate the need for this bugzilla (or could be used to =
implement=20
it).=20

https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D109127=20

Richard Gronback wrote:=20


Hi Ed,=20

Right, if you add '.qualifier' to all your Bundle-Version =
entries in=20
the manifests, PDE build will replace these and take care of =
naming=20
your files accordingly, etc. We've run into some =
complications due=20
to all this (e.g. test executions, as the paths can vary with =
each=20
build), but in the end if it means the update manager will =
work=20
better (particularly for Callisto), it's worth the switch, =
imo.=20

Best,=20
Rich=20






------=_NextPart_000_0020_01C63875.3331AB20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Rich,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This will also delay the declaration of =
EMFT M5=20
bits since the build scripts for EMFT are using the same infra as EMF. =
<FONT=20
face=3D"Times New Roman" size=3D3>Sorry for the inconvenience.&nbsp;=20
:-(</FONT><BR>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vishy</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=20
wrote in message <A=20
=
href=3D"news:dtko83$2ma$1@utils.eclipse.org">news:dtko83$2ma$1@utils.ecli=
pse.org</A>...</DIV>Rich,<BR><BR>It=20
was brought to my attention that doing this correctly is important to =
Callisto=20
so we are looking at doing this <B>immediately</B>.&nbsp; This will =
delay the=20
availability of M5 perhaps even until tomorrow.&nbsp; Sorry for the=20
inconvenience.&nbsp; :-(<BR><BR><BR>Richard Gronback wrote:=20
<BLOCKQUOTE cite=3Dmid1e2483429a0f8c806ad00793880@news.eclipse.org=20
type=3D"cite">Hi Nick, <BR><BR>I learned about this "automagic" =
feature in=20
this bug <A class=3Dmoz-txt-link-freetext=20
=
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D99393">https://bu=
gs.eclipse.org/bugs/show_bug.cgi?id=3D99393</A>=20
which led me to this article <A class=3Dmoz-txt-link-freetext=20
=
href=3D" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml">=
http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</A>=20
<BR><BR>Of course, no clear instructions were found, so I poked into =
the=20
platform's manifests and found a curious .qualifier suffix added to =
their=20
version numbers. So, I tacked it onto ours as well and have been =
dealing=20
with the repercussions since ;-) <BR><BR>Best, <BR>Rich <BR><BR><BR>
<BLOCKQUOTE type=3D"cite">Rich: <BR><BR>How do you make PDE replace=20
"1.0.0.qualifier" with, for example, <BR>"1.0.0I200602161109" ? Or =
does=20
PDE do it automagically? <BR><BR>If you can provide some insight =
into this=20
(here, in the bug, or via <BR>email directly to =
codeslave(at)ca.ibm.com),=20
then I can start exploring <BR>after M5. <BR><BR>Anyway, I'll add =
this to=20
my pile of never-ending TODOs. ;-) <BR><BR>Cheers, <BR><BR>Nick =
<BR><BR>Ed=20
Merks wrote: <BR><BR>
<BLOCKQUOTE type=3D"cite">Rich, <BR><BR>I've sent a note to Nick =
and the=20
rest of the group to solicit <BR>opinions, but it does seem the =
right=20
way to go.&nbsp;&nbsp; Maybe that would <BR>eliminate the need =
for this=20
bugzilla (or could be used to implement <BR>it). <BR><BR><A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D109127">https://b=
ugs.eclipse.org/bugs/show_bug.cgi?id=3D109127</A>=20
<BR><BR>Richard Gronback wrote: <BR><BR>
<BLOCKQUOTE type=3D"cite">Hi Ed, <BR><BR>Right, if you add =
'.qualifier'=20
to all your Bundle-Version entries in <BR>the manifests, PDE =
build=20
will replace these and take care of naming <BR>your files =
accordingly,=20
etc.&nbsp; We've run into some complications due <BR>to all =
this (e.g.=20
test executions, as the paths can vary with each <BR>build), =
but in=20
the end if it means the update manager will work <BR>better=20
(particularly for Callisto), it's worth the switch, imo. =
<BR><BR>Best,=20
<BR>Rich=20
<BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><BR><BR></BLOCKQUOTE ><BR></BLO=
CKQUOTE></BODY></HTML>

------=_NextPart_000_0020_01C63875.3331AB20--
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569538 is a reply to message #25235] Thu, 23 February 2006 17:53 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060901000709090409000405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Guys,

Note that Eclipse is spinning an M5a

https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866>

so we will delay producing M5 for EMF and EMFT until then, which gives
us more time to get this qualifier issue right too.


Vishy Ramaswamy wrote:
> Hi Rich,
> This will also delay the declaration of EMFT M5 bits since the build
> scripts for EMFT are using the same infra as EMF. Sorry for the
> inconvenience. :-(
> Thanks
> Vishy
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:dtko83$2ma$1@utils.eclipse.org...
> Rich,
>
> It was brought to my attention that doing this correctly is
> important to Callisto so we are looking at doing this
> *immediately*. This will delay the availability of M5 perhaps
> even until tomorrow. Sorry for the inconvenience. :-(
>
>
> Richard Gronback wrote:
>> Hi Nick,
>>
>> I learned about this "automagic" feature in this bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me
>> to this article
>> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>>
>> Of course, no clear instructions were found, so I poked into the
>> platform's manifests and found a curious .qualifier suffix added
>> to their version numbers. So, I tacked it onto ours as well and
>> have been dealing with the repercussions since ;-)
>>
>> Best,
>> Rich
>>
>>
>>> Rich:
>>>
>>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>>
>>> If you can provide some insight into this (here, in the bug, or via
>>> email directly to codeslave(at)ca.ibm.com), then I can start
>>> exploring
>>> after M5.
>>>
>>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Ed Merks wrote:
>>>
>>>> Rich,
>>>>
>>>> I've sent a note to Nick and the rest of the group to solicit
>>>> opinions, but it does seem the right way to go. Maybe that would
>>>> eliminate the need for this bugzilla (or could be used to
>>>> implement
>>>> it).
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Right, if you add '.qualifier' to all your Bundle-Version
>>>>> entries in
>>>>> the manifests, PDE build will replace these and take care of
>>>>> naming
>>>>> your files accordingly, etc. We've run into some
>>>>> complications due
>>>>> to all this (e.g. test executions, as the paths can vary with
>>>>> each
>>>>> build), but in the end if it means the update manager will work
>>>>> better (particularly for Callisto), it's worth the switch, imo.
>>>>>
>>>>> Best,
>>>>> Rich
>>
>>
>


--------------060901000709090409000405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
Note that Eclipse is spinning an M5a<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866">https://bugs.eclipse.org/bugs/show_bug.cgi?id=128866
</a><br>
</blockquote>
so we will delay producing M5 for EMF and EMFT until then, which gives
us more time to get this qualifier issue right too.<br>
<br>
<br>
Vishy Ramaswamy wrote:
<blockquote cite="middtkrj8$hae$1@utils.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2800.1528" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Rich,</font></div>
<div><font face="Arial" size="2">This will also delay the declaration
of EMFT M5 bits since the build scripts for EMFT are using the same
infra as EMF. <font face="Times New Roman" size="3">Sorry for the
inconvenience.&nbsp; :-(</font><br>
Thanks</font></div>
<div><font face="Arial" size="2">Vishy</font></div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" &lt;<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>&gt;
wrote in message <a href="news:dtko83$2ma$1@utils.eclipse.org">news:dtko83$2ma$1@utils.eclipse.org</a>...</div>
Rich,<br>
<br>
It was brought to my attention that doing this correctly is important
to Callisto so we are looking at doing this <b>immediately</b>.&nbsp; This
will delay the availability of M5 perhaps even until tomorrow.&nbsp; Sorry
for the inconvenience.&nbsp; :-(<br>
<br>
<br>
Richard Gronback wrote:
<blockquote cite="mid1e2483429a0f8c806ad00793880@news.eclipse.org"
type="cite">Hi Nick, <br>
<br>
I learned about this "automagic" feature in this bug <a
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393">https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393</a>
which led me to this article <a class="moz-txt-link-freetext"
href=" http://www.eclipse.org/equinox/documents/plugin-versioning.h tml"> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml</a>
<br>
<br>
Of course, no clear instructions were found, so I poked into the
platform's manifests and found a curious .qualifier suffix added to
their version numbers. So, I tacked it onto ours as well and have been
dealing with the repercussions since ;-) <br>
<br>
Best, <br>
Rich <br>
<br>
<br>
<blockquote type="cite">Rich: <br>
<br>
How do you make PDE replace "1.0.0.qualifier" with, for example, <br>
"1.0.0I200602161109" ? Or does PDE do it automagically? <br>
<br>
If you can provide some insight into this (here, in the bug, or via <br>
email directly to codeslave(at)ca.ibm.com), then I can start exploring <br>
after M5. <br>
<br>
Anyway, I'll add this to my pile of never-ending TODOs. ;-) <br>
<br>
Cheers, <br>
<br>
Nick <br>
<br>
Ed Merks wrote: <br>
<br>
<blockquote type="cite">Rich, <br>
<br>
I've sent a note to Nick and the rest of the group to solicit <br>
opinions, but it does seem the right way to go.&nbsp;&nbsp; Maybe that would <br>
eliminate the need for this bugzilla (or could be used to implement <br>
it). <br>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127">https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127</a>
<br>
<br>
Richard Gronback wrote: <br>
<br>
<blockquote type="cite">Hi Ed, <br>
<br>
Right, if you add '.qualifier' to all your Bundle-Version entries in <br>
the manifests, PDE build will replace these and take care of naming <br>
your files accordingly, etc.&nbsp; We've run into some complications due <br>
to all this (e.g. test executions, as the paths can vary with each <br>
build), but in the end if it means the update manager will work <br>
better (particularly for Callisto), it's worth the switch, imo. <br>
<br>
Best, <br>
Rich <br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>

--------------060901000709090409000405--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Announce] EMFT VALIDATION 1.0.0 I200602161109 is available [message #569560 is a reply to message #25194] Thu, 23 February 2006 19:14 Go to previous message
Richard Gronback is currently offline Richard GronbackFriend
Messages: 605
Registered: July 2009
Senior Member
OK, thanks for the update.

> Rich,
>
> It was brought to my attention that doing this correctly is important
> to Callisto so we are looking at doing this *immediately*. This will
> delay the availability of M5 perhaps even until tomorrow. Sorry for
> the inconvenience. :-(
>
> Richard Gronback wrote:
>
>> Hi Nick,
>>
>> I learned about this "automagic" feature in this bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393 which led me to
>> this article
>> http://www.eclipse.org/equinox/documents/plugin-versioning.h tml
>>
>> Of course, no clear instructions were found, so I poked into the
>> platform's manifests and found a curious .qualifier suffix added to
>> their version numbers. So, I tacked it onto ours as well and have
>> been dealing with the repercussions since ;-)
>>
>> Best,
>> Rich
>>> Rich:
>>>
>>> How do you make PDE replace "1.0.0.qualifier" with, for example,
>>> "1.0.0I200602161109" ? Or does PDE do it automagically?
>>>
>>> If you can provide some insight into this (here, in the bug, or via
>>> email directly to codeslave(at)ca.ibm.com), then I can start
>>> exploring after M5.
>>>
>>> Anyway, I'll add this to my pile of never-ending TODOs. ;-)
>>>
>>> Cheers,
>>>
>>> Nick
>>>
>>> Ed Merks wrote:
>>>
>>>> Rich,
>>>>
>>>> I've sent a note to Nick and the rest of the group to solicit
>>>> opinions, but it does seem the right way to go. Maybe that would
>>>> eliminate the need for this bugzilla (or could be used to implement
>>>> it).
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109127
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Ed,
>>>>>
>>>>> Right, if you add '.qualifier' to all your Bundle-Version entries
>>>>> in the manifests, PDE build will replace these and take care of
>>>>> naming your files accordingly, etc. We've run into some
>>>>> complications due to all this (e.g. test executions, as the paths
>>>>> can vary with each build), but in the end if it means the update
>>>>> manager will work better (particularly for Callisto), it's worth
>>>>> the switch, imo.
>>>>>
>>>>> Best,
>>>>> Rich
Previous Topic:OCL and Query interdependency
Next Topic:Vote for the Eclipse Community Awards
Goto Forum:
  


Current Time: Thu Mar 28 13:57:23 GMT 2024

Powered by FUDForum. Page generated in 0.06947 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top