Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Orbit, maven.eclipse.org, etc.
David, I was hoping to trigger a discussion and thinking about how we distribute software to our many builds and feed external builds as well. This is happening, and your comments contribute to the discussion so I am grateful for your time and the input. Hopefully this'll help clear things up a bit more. 

On 02/17/2012 12:42 PM, David M Williams wrote:

I still don't understand.

First, in attached reply-note you say

"Thinking
about this made it clear the issue is larger than simply putting Orbit
content into maven, which was the point of this page."

What's the point of the page? Putting Orbit content into maven?
I am working towards articulating/putting forth a position there is considerable value in developing/implementing a unifying & stackable set of repositories for distributing software to builds. This would involve all 3 types of software. Primarily, I am thinking of builds in Eclipse community forge, the LTS forge, and Polarsys forge, however the same solution would provide value to those building based on Eclipse technology, wherever they may be. 


Second, on the wiki, you still "summarize" with

Summary
    1.	Orbit's distribution model doesn't scale as much as we need nor offer
       enough flexibility
    2.	Orbit only covers a small portion of software consumption - third
       party. Thus even with Orbit, another mechanism is always needed
    3.	A subset of projects in the Eclipse ecosystem use Orbit
    4.	Project, 3rd party (modified&  unmodified) software needs to be in
       bundle format in any case to satisfy runtime demand.

I think the first three points should be removed or changed ... they don't
seem specific to Orbit.
That's part of my point. Replicating stuff from Orbit into Nexus gives us at least two systems to manage.I believe we could manage the same thing with a single system. This helps tremendously as that system is proxied/cached/replicated many times to LTS, Polarsys, and other places the software is consumed.
Also, from the point of view of project A consuming project B, project B might be (should be?) considered third party even if it comes from Eclipse. If we treated all software the same, we'd have a unifying point between builds/projects/consumers of the technology. 


For the fourth point, I'd ask, "so"?
Whatever the technology that shares software, it seems clear it must be able to handle bundles as input and output. 


> From my point of view, the Orbit Project produces just another p2 repo,
produced by a PDE build, just like many other Eclipse Projects, so no need
to call it out separately from other p2 repositories in your diagram.

One guess as to what you might be trying to say, is that each Eclipse
Project produces its own p2 repository and its hard for consumers to build
against lots of separate p2 repositories.  Maybe you could represent that
by removing Orbit repo, and adding multiple p2 repositories in your
diagram .... you know, one of those "stacked" repository symbols. (But,
again, depends on what you are trying to say and represent, which isn't
clear to me).
I was thinking it makes sense to show we have some 3rd party stuff that comes in via. the CQ process and other content is built. I'll think a bit if the diagram can represent this clearly. I have a few ideas. 


Next, what's Nexus? Who uses that? How does that play in current system?

Nexus is maven.eclipse.org.


Are you saying there are CQ'd third party bundles that go directly into
Nexus, but not in Orbit? Which is what your picture implies.
At the moment it's the opposite. Software in Orbit is not in Nexus. As you note, people want both at the least. I'm suggesting/ checking if we could have 1 system. That would make it less work to proxy/cache/replicate into LTS/Polarsys and make it easier for people consuming Eclipse technology. 



Next, not sure what value "Hudson" has in the picture. Sure it "runs
jobs" ... but, there are (currently) other ways to run jobs and while
Hudson is a common choice, I'm not sure of its relevance to this picture.
You're right. In an earlier version I didn't have it for that reason. It doesn't add a ton of value in this context, but it does in a broader look at the systems involved in build @ Eclipse. I'll leave it for now if you don't mind as I don't think it hurts clarity. 



Please take these comments and questions not as "criticism", but just an
indication of the current state of (my) confusion ... which I assume is
what you are trying to clear up, so I thought I would just openly express
my ignorance so you'd know how much work you have to do to achieve that. :)
Thank you again. I'm very grateful you took the time to read the page and provide input and ask questions. Your input is appreciated. 


From:	Andrew Ross<andrew.ross@xxxxxxxxxxx>
To:	cbi-dev@xxxxxxxxxxx,
Date:	02/17/2012 11:42 AM
Subject:	Re: [cbi-dev] Orbit, maven.eclipse.org, etc.
Sent by:	cbi-dev-bounces@xxxxxxxxxxx




Hi David,

Thanks for that. I think that's good now.

To answer your question, the fact orbit content isn't available in
maven.eclipse.org certainly was noteworthy. It was something important
to look at in any case in the context of LTS, Polarsys, etc. Thinking
about this made it clear the issue is larger than simply putting Orbit
content into maven, which was the point of this page.

Andrew

On 02/17/2012 11:06 AM, David M Williams wrote:

I agree, you seem to not understand Orbit, I tried to edit, but got
"conflict" with your edits, but still see your "list of concerns" about
Orbit in the summary, which I don't understand. Here is what I was going

to

say about Orbit:

Orbit provides a centralized clearing house for IP policy approved 3rd
party dependencies. [dw edits, 02/17/2012]<del>Orbit provides this
software as a zip file containing bundles for all software. This would be
better if it were componentized so that just what is needed can be
consumed.</del>   Orbit provides this software as a p2 repository, so only
those bundles required by a build need to be fetched from that

repository.

The standard PDE build does this transparently. [not sure about others
build systems.] A large archive file of the while p2 repository is
provided, for those that prefer to have their own copy on, say, on some
"off site" server so they can do builds disconnected from the internet.

I think you might be trying to "talk around" the main Orbit complaint

which

is "there is no mavenized version of Orbit bundles"? No?






From:		 Andrew Ross<andrew.ross@xxxxxxxxxxx>
To:		 Common-build Developers discussion<cbi-dev@xxxxxxxxxxx>,
Date:		 02/17/2012 10:59 AM
Subject:		 Re: [cbi-dev] Orbit, maven.eclipse.org, etc.
Sent by:		 cbi-dev-bounces@xxxxxxxxxxx



Thanks for the quick feedback and correction Kim. I removed that concern.

I

saw the zip, but wasn't sure if people were pulling it or accessing the
bundles inside directly off a URL.

On 02/17/2012 10:53 AM, Kim Moir wrote:
        Andrew,

        I'm confused by your statement "Orbit provides this software as a

zip

        file containing bundles for all software. This would be better if

it

        were componentized so that just what is needed can be consumed. "

        Orbit provides p2 repos full of nice bundle components :-)



http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/orbitBundles-R20120119162704.p2.map



        We don't download the zip, we just consume the bundles we need and
        have been approved to consume from the Orbit repos.

        Kim




        From:        Andrew Ross<andrew.ross@xxxxxxxxxxx>
        To:        Common-build Developers discussion<cbi-dev@xxxxxxxxxxx>
        Date:        02/17/2012 09:40 AM
        Subject:        [cbi-dev] Orbit, maven.eclipse.org, etc.
        Sent by:        cbi-dev-bounces@xxxxxxxxxxx



        Hi Everyone,

        I wanted to share some thoughts around Orbit, maven.eclipse.org,

etc.

        as
        I feel it is very important, a deceptively big problem at the

moment,

        and I don't think I articulated my thoughts well up to this point.
        This
        wiki page attempts to do so:
        http://wiki.eclipse.org/CBI/Distribution

        I'd like to discuss this as part of the agenda at next week's CBI
        meeting. I'm sure the information on the wiki could use more

details

        for
        completeness/correctness, so please help make it so in what ever

way

        is
        most convenient for you such as editing the wiki, replying to this
        list,
        calling me, etc.

        Thanks very much,

        Andrew

Back to the top