[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Jetty and commons logging
- From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
- Date: Sun, 6 Jan 2008 18:35:15 +0000
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O/w+gkRXtm+cwGZst8pTXOih7QleOV/i60FHNzFVwl2PJDXmAC/lEQlnfiasYlHJzHoOvW/coQsJUwv4CM2dzg2BqdCLg0VrahiDuxrTt+zQesZWqaPDH81fhMuLPq6LTNoAhOtHfAAxUzKIGCBI2r7RSqxTHcvtZyXxjDn+O8k=
On Jan 6, 2008 1:18 AM, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> I won't disagree and would certainly welcome anyone who wanted to
> create/maintain such a repo. It seems that someone has done this at
> maven.org. The Maven user community should encourage that person to
> continue doing the work. I don't really see eclipse.org or the projects
> hosting another copy of all their bundles laid out in the standard Maven dir
> structure. Our mirrors would be upset at the doubling in size and we have
> to maintain the update site structure for the Eclipse user community anyway.
> As I understand Maven, it is at least in theory possible to define different
> kinds of repos so, for example, Eclipse update sites could be directly
> accessed from Maven. No idea what is involved in that but it feels like the
> right kind of direction.
The problem with the Eclipse downloads is that there's actually no
real way of knowing where to look for something. Quite apart from the
arbitrary tools/platform/technology project splits, each directory is
versioned in an S-3.4M2-200709210919 directory whose name is computed
based on the time that something was run, rather than anything
detectable. In order to provide my 'direct download links' I had to
manually grep for the random-date-string in order to update my links
each time a new drop was released.
Not only that, but eclipse.org doesn't provide any really useful way
of finding out what plugins are hosted, or even where. It also ends up
wasting a *heap* of bandwith; the -win32-win32-, -win32-wpf-,
-linux-gtk-, -linux-motif-, combos are all pretty much 95%+ the same,
with only a few native bits different from each of them. There's no
'one' place to download the individual plugins.
Even the update sites aren't helpful. You can't browse to them, and
even when you do (e.g. via a mirror) it's not clear as to which plugin
is stored in which location.
Lastly, there's no metadata available. One of the things which will
have been observed from the P2 work is that it is necessary to have a
(small) downloadable metadata file that can be downloaded without
needing to download the bits that the metadata refers to. In Maven,
this is the POM, and without it, a maven repo is just an HTTP store.
Whether the P2 work can be leveraged to have a Maven->P2 link (or vice
versa) is something that could be investigated, but the problem is
that if you rely on e.g. additions to the maven repository then they
are either done sporadically or erroneously. In the case of Eclipse,
several (different) people have uploaded variants of some of the core
Eclipse plugins, but then never get updated as newer versions are
available. If this process were baked into the Eclipse release
process, more people might be tempted to build upon OSGi systems than
they are at the moment.
For those that are interested in building OGSi with Maven, then take a
look at Pax Construct:
There's also Pax Runner, which allows bundles to be launched inside
different OSGi engines, such as Equinox and Felix: