[orbit-dev] Fw: Remaining issues for Orbit Recipes Adoption

["David M Williams" <david_williams@xxxxxxxxxx>]

Trying once again to "get this message
through". 
(I opened bug 486216 on "mailing
list" problems ... if anyone else has sent one since January 7th,
you might need to resend? ) 

----- Forwarded by David
M Williams/Raleigh/IBM on 01/20/2016 08:13 PM -----

From:      
 David M Williams/Raleigh/IBM
To:      
 orbit-dev@xxxxxxxxxxx,
Cc:      
 Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx>, Roland Grunberg <rgrunber@xxxxxxxxxx>
Date:      
 01/20/2016 02:03 PM
Subject:    
   Re: Remaining
issues for Orbit Recipes Adoption

---

> and I was
wondering if lack of pack200 support would be a deal-breaker.

Yes. We definitely need pack200 versions of all jars
produced. 
In fact, we need any "new build" to produce
exactly what the "old build" does. 

Well, with a few exceptions. 
The exceptions I know about are some old "map
formats" that were published on download page, 
and have been deprecated for a long time: 

map
file in CVS, text format (Deprecated. The p2
format map file is recommended. See Orbit
Builds for Consumers)
map
file in GET, http format (Deprecated. The p2
format map file is recommended. See Orbit
Builds for Consumers) 

But otherwise, as far as I am concerned, everything
else needs to be there before we can say it is ready. 
Especially the same tests ran, etc. 

I am a little surprised that is not well understood,
especially about pack200. My apologies if I have not communicated that
well. 

We do not want to "move backwards" in anyway.

= = = = = = 

Also, why is this communication not happening on "orbit-dev"
list? Please use that list to state current status and plans and/or ask
questions. 

From my point of view, at one point we hoped that
the repo we produce for Mars.2 would be our last use of "the old build".
But that is no longer feasible. There are already
a few cases of "things for Neon" in the old build that would
not make sense to "through away". 
I still need to add a new version of ICU4J, and since
the new build is not ready yet for prime time, I think I will use the old
build for that. 

= = = = = = 

Glad to hear there is some progress being made, but
I still do not have a good sense of where things are, or who is doing what.

Thanks, 





From:      
 Roland Grunberg <rgrunber@xxxxxxxxxx>
To:      
 Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx>, 
Cc:      
 David M Williams/Raleigh/IBM@IBMUS
Date:      
 01/20/2016 01:09 PM
Subject:    
   Re: Remaining
issues for Orbit Recipes Adoption

---

> I've scheduled some time next week to work on
the open topics. My goal is to
> have signing in place end of next week.
> 
> No comparator is currently run. The repository is built all the time
from
> scratch. The comparator would happen afterwards. However, I'm working
on
> producing a delta repo only instead of the full repo on each build.
It's
> still difficult to produce a real delta, i.e. only recompile bundles
which
> changed. I have an idea for implementing this but it's more tricky
then I
> thought.

So we now have jar signing through eclipse-jarsigner-plugin, and I was
wondering if lack of pack200 support would be a deal-breaker.

I think the nicest way would be to integrate it with tycho's pack200 plugins,
but some changes will be required on them so they can support our bundle
recipes, or possibly all jars (much like the eclipse-jarsigner now does)

Cheers,
-- 
Roland Grunberg