Re: [cbi-dev] More on ... Orbit, maven.eclipse.org, etc.

[Andrew Ross <andrew.ross@xxxxxxxxxxx>]

David,

Unless I'm mistaken, Nexus is open source and version 2.0 is licensed under the GPL. You're likely thinking of Nexus pro.

I noticed when perusing maven.eclipse.org that it was the earlier version of (the open source version of) nexus. This version was licensed under the GPL.

Andrew

On 18 February 2012 14:42, David M Williams <david_williams@xxxxxxxxxx> wrote:

> Nexus is maven.eclipse.org.

Andrew, I think, then, your chart at
http://wiki.eclipse.org/CBI/Distribution
should say "maven.eclipse.org" instead of "Nexus".

Nexus is a brand name, of one particular (proposed) way to implement
"maven.eclipse.org. Eclipse is proud of being vendor neutral, and while we
(Eclipse) might have some license to use some subset of the full Nexus
product on some part of our (Eclipse) infrastructure, to me it still comes
across as "free advertising" ... that I think Eclipse tries to avoid in
such situations.

CC'ing Wayne and Mike as they are the experts in this area and they can
correct me if I am wrong (which, would not be the first time :)

Thanks,






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




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

_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev