You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Jeffrey Liu <je...@ca.ibm.com> on 2005/05/03 22:12:49 UTC
Proposal for a centralized Eclipse update manager site for Apache projects/software
Hi,
This message was originally posted to the general@incubator.apache.org
mailing list. Someone pointed out that such discussion should be carried
out here instead. So I'm re-posting the original message here. Here it
goes:
I want to propose a centralized Eclipse update manager site for Apache
projects/software. Reason I propose an Eclipse update manager site for
Apache projects/software is because Eclipse projects such as the Web Tools
Platform (WTP) project often reuses software that are provided by Apache,
for example, Axis, Tomcat, Derby, etc... Often times, these Apache
software are not redistributed by the Eclipse projects, but instead, they
are listed as prerequisites. This means, end users must first download the
Eclipse project and all the Apache software prereq by the project, and
configure these software in the Eclipse project before they can get
started. This is error prone and hampers the out-of-the-box experience.
Imagine the following scenario:
A user downloads WTP. Unzip it and starts it up. S/he wants to create an
Axis Web service. S/he launches the wizard that creates a Web service, but
finds out s/he needs Tomcat and Axis. So s/he opens up her Web browser,
goes to the Apache Web site and looks for the download page for Tomcat and
Axis. S/he downloads and unzips Tomcat and Axis to the file system. Goes
back to WTP and manually configures Tomcat and Axis into her workspace.
S/he launches the wizard again and move on.
This is not easy. If there's an Eclipse update manager site for Apache
software, then when the user finds out s/he needs Tomcat and Axis, all
s/he needs to do now is launch the Eclipse update manager (URL to the
Apache update site will be preloaded), select Tomcat and Axis and click
Finish. The Eclipse update manager will download, install and configure
Tomcat and Axis automatically. This is much better than asking the user to
download and configure things manually. Also, this Eclipse update manager
site is useful when new versions of a Apache software is available. For
example:
Say Eclipse WTP 1.0 ships with Axis 1.2 support. If later on, Axis
releases a critical fix for Axis 1.2, then without an update site, we'll
need to do one of the following...
1. Rebuild WTP 1.0 with the Axis fix
2. Ask users to manually update WTP
3. Wait for the next version of WTP.
None of the above sound attractive. If there's an Eclipse update manager
site setup for Apache, then end users can search and install new updates
automatically by making just a few clicks. I believe this can advance the
integration between open source software that are provided in different
domains (Apache, Eclipse, etc). I think this will benefit the open source
community and can grow the open source ecosystem.
Suggestions/comments are welcomed.
Thanks,
Jeffrey Liu
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 3 May 2005, Jeffrey Liu wrote:
> I want to propose a centralized Eclipse update manager site for Apache
> projects/software. Reason I propose an Eclipse update manager site for
Would be excelent if it can be tied up with the existing dist/mirrored
infrastructure for anything 'bulk' downloads. So I guess this boils
down to
-> Lets make absolutely shure that the actual jar/tar/zip's are
fetched from the mirred repo's.
-> what extra metadata should be added to the repository
or somewhere else.
And who maintains this.
-> which crowd writes and maintains the clever code which takes this
data and populates the Eclipse update site.
In the ideal case it would extract the extra metadata from the jar/tar so
it can also be used by other similar update managers (or external things
like maven).
Dw
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Mark Diggory <md...@gmail.com>.
Brett Porter wrote:
>I echo David's sentiments on this. I'd be interested to know what is
>in the eclipse metadata you want to attach to the various artifacts in
>the repository, and whether any of it coincides with existing metadata
>formats in use here, such as the following for parts of jakarta
>commons:
>
>http://www.apache.org/dist/java-repository/commons-logging/poms/commons-logging-1.0.4.pom
>http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml
>
>
>
Its going to be similar, but specific to Eclipse and wrapped up in a Jar
file. More specifically, Eclipse plugins are now based in OSGI standards:
http://www.osgi.org/
To get even more specific plugins require a Manifest file and either of
the following (plugin.xml, fragment.xml, or feature.xml). When Eclipse
becomes fully OSGI standard, all plugins will be distributed as actual
jars whose contents will be accessed using standard java resources,
until then these are not real "jars" and get expanded into eclipses
plugins directory, thus they contain a heterogeneous mix of static
resources, classes and jar archives. The closest thing that I can
compare the entire thing to is a Webapplications WAR file.
>I don't think this is a question of a new repository, but rather what
>we can do to the existing one to better support what you are trying to
>achieve.
>
>
>
Exactly, we'd probably place "WAR"s into our repository, why not OSGI
standard plugins. Someday, in a perfect world, you might actually be
talking about the same exact thing when you refer to a a Jar on the
classpath and a plugin in Maven, Ant, Eclipse, NetBeans ...) then this
becomes ultimately powerful.
-Mark Diggory
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Brett Porter wrote:
>I echo David's sentiments on this. I'd be interested to know what is
>in the eclipse metadata you want to attach to the various artifacts in
>the repository, and whether any of it coincides with existing metadata
>formats in use here, such as the following for parts of jakarta
>commons:
>
>http://www.apache.org/dist/java-repository/commons-logging/poms/commons-logging-1.0.4.pom
>http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml
>
>
>
Its going to be similar, but specific to Eclipse and wrapped up in a Jar
file. More specifically, Eclipse plugins are now based in OSGI standards:
http://www.osgi.org/
To get even more specific plugins require a Manifest file and either of
the following (plugin.xml, fragment.xml, or feature.xml). When Eclipse
becomes fully OSGI standard, all plugins will be distributed as actual
jars whose contents will be accessed using standard java resources,
until then these are not real "jars" and get expanded into eclipses
plugins directory, thus they contain a heterogeneous mix of static
resources, classes and jar archives. The closest thing that I can
compare the entire thing to is a Webapplications WAR file.
>I don't think this is a question of a new repository, but rather what
>we can do to the existing one to better support what you are trying to
>achieve.
>
>
>
Exactly, we'd probably place "WAR"s into our repository, why not OSGI
standard plugins. Someday, in a perfect world, you might actually be
talking about the same exact thing when you refer to a a Jar on the
classpath and a plugin in Maven, Ant, Eclipse, NetBeans ...) then this
becomes ultimately powerful.
-Mark Diggory
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Brett Porter <br...@gmail.com>.
I echo David's sentiments on this. I'd be interested to know what is
in the eclipse metadata you want to attach to the various artifacts in
the repository, and whether any of it coincides with existing metadata
formats in use here, such as the following for parts of jakarta
commons:
http://www.apache.org/dist/java-repository/commons-logging/poms/commons-logging-1.0.4.pom
http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml
I don't think this is a question of a new repository, but rather what
we can do to the existing one to better support what you are trying to
achieve.
On a side note, there is another Maven repository outside of Apache
that automatically collects all of the ASF data as well as some other
open source projects and manually requested inclusions at
http://repo1.maven.org/maven/
Cheers,
Brett
On 5/4/05, David Jencks <dj...@apache.org> wrote:
> After reading some of the discussion I'm still left with the impression
> that what you are proposing is very similar to maven's dependency
> management with the addition of some client side gui fluff. I repeat
> my request that you explain how it differs and why it should be
> supported on apache space. There may be very good reasons, but so far
> I can't tell what they are from your description.
>
> As someone else pointed out, the repository can be used to distribute
> just about any kind of artifact. Exactly what do you want different
> from what the repository already offers? So far from your description
> I would guess, knowing nothing about eclipse, that what you are asking
> for is that all apache projects provide an eclipse plugin distribution
> version that is stored in the repository. Aside from the eclipse
> client side fluff, what do you want?
>
> I also suggest that changing the versions of dependencies declared by a
> project without rebuilding it may not be something that it is advisable
> to support too heavily.
>
> thanks
> david jencks
>
> On May 3, 2005, at 2:48 PM, Jeffrey Liu wrote:
>
> >
> > Hi Jaaron,
> >
> > Thanks for your inputs. The short answer to your question is, I'm not
> > looking for full-fledged plugins that support the toolings around ASF
> > projects. Developing a Tomcat plugin (like the one used in the Eclipse
> > help's system) would be out of the scope of what I'm proposing here.
> > You are right, what I'm proposing is simply a new mechanism (an update
> > site) to distribute outputs (jars, etc...) from ASF projects. I do
> > want to point out that such distribution mechanism is not limited to
> > projects that fills Eclipse dependencies, it can also be applied to
> > full-fledged plugins. For example, if one day, the Tomcat project
> > decides to roll its own version of the Eclipse plugins. These plugins
> > can be made available on the same update site. It's just that the
> > development of this plugin will remind in the Tomcat project. This new
> > update site that I'm proposing is an alternative, hopefully better (in
> > the eyes of Apache/Eclipse users), way of distributing ASF projects.
> >
> > I believe this new distribution mechanism will help both Eclipse
> > plugin developers and end users. For example, in WTP, there's a Web
> > app called the Web Services Explorer which allows you to query
> > business/services/etc from an UDDI registery. This Web app uses Apache
> > Axis as the underlying SOAP engine. As a developer, I would like the
> > ability to update the underlying Axis engine without having to rebuild
> > WTP. Reason is simple, if Axis releases a fix, without the support of
> > an update manager site, there's no easy way to get this fix into the
> > current version of WTP. I (and end users) will have to wait for the
> > next release of WTP in order to pick up this fix. Since Axis and WTP
> > run on different schedules, it would be a nightmare to manage what fix
> > gets into what release..... For end users, this update site can
> > improve usability as well. I'll reuse the example from the original
> > post. Picture that a end user is trying to generate a Web service
> > using WTP. The user finds out that s/he does not have Axis and Tomcat
> > downloaded. So the user download them manually and configure them into
> > the Eclipse workspace. Configure in this case requires the user to
> > launch the preference page and point WTP to the location of Axis and
> > Tomcat. New users will not know where to configure Axis and Tomcat
> > unless s/he reads some documentation. Wouldn't it be nice if the WTP
> > wizards detect that the user does not have Axis and Tomcat install, so
> > it pops up a dialog telling the user what's going on, shows the
> > license agreements to the user and install the Axis and Tomcat plugins
> > automatically? Btw, another reason why WTP is not redistributing any
> > ASF projects directly is because there are too many of them. Imagine
> > WTP ships with Tomcat 3.2, 4.1, 5.0, 5.5... the download size would be
> > huge and users do not want that. It's better to install things on the
> > fly when it's needed. That's why I think end users will benefit from
> > this update site as well.
> >
> > Thanks,
> >
> > Jeffrey Liu
> > IBM Rational Software - Performance Analyst
> > IBM Toronto Lab.
> > 8200 Warden Ave. Markham, Ontario, L6G 1C7
> > Internal mail: D3/R8V/8200/MKM (D3-268)
> > T/L: 969 3531
> > Tel: (905) 413 3531
> > Fax: (905) 413 4920
> > jeffliu@ca.ibm.com
> >
> >
> >
> >
> >
> > J Aaron Farr <ja...@gmail.com>
> >
> > 05/03/2005 04:34 PM
> >
> > Please respond to
> > repository
> >
> >
> >
> > To
> > repository@apache.org
> >
> > cc
> >
> > Subject
> > Re: Proposal for a centralized Eclipse update manager site for Apache
> > projects/software
> >
> >
> >
> >
> >
> >
> >
> > Hello all.
> >
> > I'm also copying over this reply I made from general@incubator.
> >
> > On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
> > >
> > > Hi,
> > >
> > > This message was originally posted to the
> > general@incubator.apache.org
> > > mailing list. Someone pointed out that such discussion should be
> > carried out
> > > here instead. So I'm re-posting the original message here. Here it
> > goes:
> > >
> > > I want to propose a centralized Eclipse update manager site for
> > Apache
> > > projects/software.
> >
> > Jeffrey,
> >
> > In thinking about your proposal more I've got a few questions:
> >
> > Are you looking for plugins that simply fulfill Eclipse project
> > dependencies or full-fledged plugins that would, for example, allow
> > you to launch Axis or Tomcat from within Eclipse? If it's resolving
> > dependencies, then I don't see how a plugin wrapper around the jars
> > would do this without some Eclipse code to integrate into the
> > development environment (WTP,PDE,JDT). AFAIK providing just a plugin
> > wrapper would only be useful for other plugin developers, not for a
> > 'end-user' developer who would happen to be using the WTP.
> >
> > Plugins which extend the IDE to use ASF projects such as a Struts or
> > Tomcat plugin are already available via various third parties. Are
> > you suggesting the ASF should provide its own Eclipse plugins with
> > similar functionality?
> >
> > The Eclipse project itself provides some ASF related plugins, most
> > notably the Tomcat plugin used for Eclipse's help system. Is this the
> > sort of plugin you are looking for? Likewise, Eclipse has started the
> > new Lepido project for a Cocoon development environment. Seeing that
> > Eclipse already hosts ASF related plugins, is there any reason for the
> > ASF to host a similar update site?
> >
> > I can see some advantage to providing ASF releases in plugin form but
> > only
> > for plugin developers, not for most Eclipse end users.
> >
> > jaaron
> >
>
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by David Jencks <dj...@apache.org>.
After reading some of the discussion I'm still left with the impression
that what you are proposing is very similar to maven's dependency
management with the addition of some client side gui fluff. I repeat
my request that you explain how it differs and why it should be
supported on apache space. There may be very good reasons, but so far
I can't tell what they are from your description.
As someone else pointed out, the repository can be used to distribute
just about any kind of artifact. Exactly what do you want different
from what the repository already offers? So far from your description
I would guess, knowing nothing about eclipse, that what you are asking
for is that all apache projects provide an eclipse plugin distribution
version that is stored in the repository. Aside from the eclipse
client side fluff, what do you want?
I also suggest that changing the versions of dependencies declared by a
project without rebuilding it may not be something that it is advisable
to support too heavily.
thanks
david jencks
On May 3, 2005, at 2:48 PM, Jeffrey Liu wrote:
>
> Hi Jaaron,
>
> Thanks for your inputs. The short answer to your question is, I'm not
> looking for full-fledged plugins that support the toolings around ASF
> projects. Developing a Tomcat plugin (like the one used in the Eclipse
> help's system) would be out of the scope of what I'm proposing here.
> You are right, what I'm proposing is simply a new mechanism (an update
> site) to distribute outputs (jars, etc...) from ASF projects. I do
> want to point out that such distribution mechanism is not limited to
> projects that fills Eclipse dependencies, it can also be applied to
> full-fledged plugins. For example, if one day, the Tomcat project
> decides to roll its own version of the Eclipse plugins. These plugins
> can be made available on the same update site. It's just that the
> development of this plugin will remind in the Tomcat project. This new
> update site that I'm proposing is an alternative, hopefully better (in
> the eyes of Apache/Eclipse users), way of distributing ASF projects.
>
> I believe this new distribution mechanism will help both Eclipse
> plugin developers and end users. For example, in WTP, there's a Web
> app called the Web Services Explorer which allows you to query
> business/services/etc from an UDDI registery. This Web app uses Apache
> Axis as the underlying SOAP engine. As a developer, I would like the
> ability to update the underlying Axis engine without having to rebuild
> WTP. Reason is simple, if Axis releases a fix, without the support of
> an update manager site, there's no easy way to get this fix into the
> current version of WTP. I (and end users) will have to wait for the
> next release of WTP in order to pick up this fix. Since Axis and WTP
> run on different schedules, it would be a nightmare to manage what fix
> gets into what release..... For end users, this update site can
> improve usability as well. I'll reuse the example from the original
> post. Picture that a end user is trying to generate a Web service
> using WTP. The user finds out that s/he does not have Axis and Tomcat
> downloaded. So the user download them manually and configure them into
> the Eclipse workspace. Configure in this case requires the user to
> launch the preference page and point WTP to the location of Axis and
> Tomcat. New users will not know where to configure Axis and Tomcat
> unless s/he reads some documentation. Wouldn't it be nice if the WTP
> wizards detect that the user does not have Axis and Tomcat install, so
> it pops up a dialog telling the user what's going on, shows the
> license agreements to the user and install the Axis and Tomcat plugins
> automatically? Btw, another reason why WTP is not redistributing any
> ASF projects directly is because there are too many of them. Imagine
> WTP ships with Tomcat 3.2, 4.1, 5.0, 5.5... the download size would be
> huge and users do not want that. It's better to install things on the
> fly when it's needed. That's why I think end users will benefit from
> this update site as well.
>
> Thanks,
>
> Jeffrey Liu
> IBM Rational Software - Performance Analyst
> IBM Toronto Lab.
> 8200 Warden Ave. Markham, Ontario, L6G 1C7
> Internal mail: D3/R8V/8200/MKM (D3-268)
> T/L: 969 3531
> Tel: (905) 413 3531
> Fax: (905) 413 4920
> jeffliu@ca.ibm.com
>
>
>
>
>
> J Aaron Farr <ja...@gmail.com>
>
> 05/03/2005 04:34 PM
>
> Please respond to
> repository
>
>
>
> To
> repository@apache.org
>
> cc
>
> Subject
> Re: Proposal for a centralized Eclipse update manager site for Apache
> projects/software
>
>
>
>
>
>
>
> Hello all.
>
> I'm also copying over this reply I made from general@incubator.
>
> On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
> >
> > Hi,
> >
> > This message was originally posted to the
> general@incubator.apache.org
> > mailing list. Someone pointed out that such discussion should be
> carried out
> > here instead. So I'm re-posting the original message here. Here it
> goes:
> >
> > I want to propose a centralized Eclipse update manager site for
> Apache
> > projects/software.
>
> Jeffrey,
>
> In thinking about your proposal more I've got a few questions:
>
> Are you looking for plugins that simply fulfill Eclipse project
> dependencies or full-fledged plugins that would, for example, allow
> you to launch Axis or Tomcat from within Eclipse? If it's resolving
> dependencies, then I don't see how a plugin wrapper around the jars
> would do this without some Eclipse code to integrate into the
> development environment (WTP,PDE,JDT). AFAIK providing just a plugin
> wrapper would only be useful for other plugin developers, not for a
> 'end-user' developer who would happen to be using the WTP.
>
> Plugins which extend the IDE to use ASF projects such as a Struts or
> Tomcat plugin are already available via various third parties. Are
> you suggesting the ASF should provide its own Eclipse plugins with
> similar functionality?
>
> The Eclipse project itself provides some ASF related plugins, most
> notably the Tomcat plugin used for Eclipse's help system. Is this the
> sort of plugin you are looking for? Likewise, Eclipse has started the
> new Lepido project for a Cocoon development environment. Seeing that
> Eclipse already hosts ASF related plugins, is there any reason for the
> ASF to host a similar update site?
>
> I can see some advantage to providing ASF releases in plugin form but
> only
> for plugin developers, not for most Eclipse end users.
>
> jaaron
>
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Jeffrey Liu <je...@ca.ibm.com>.
Hi Jaaron,
Thanks for your inputs. The short answer to your question is, I'm not
looking for full-fledged plugins that support the toolings around ASF
projects. Developing a Tomcat plugin (like the one used in the Eclipse
help's system) would be out of the scope of what I'm proposing here. You
are right, what I'm proposing is simply a new mechanism (an update site)
to distribute outputs (jars, etc...) from ASF projects. I do want to point
out that such distribution mechanism is not limited to projects that fills
Eclipse dependencies, it can also be applied to full-fledged plugins. For
example, if one day, the Tomcat project decides to roll its own version of
the Eclipse plugins. These plugins can be made available on the same
update site. It's just that the development of this plugin will remind in
the Tomcat project. This new update site that I'm proposing is an
alternative, hopefully better (in the eyes of Apache/Eclipse users), way
of distributing ASF projects.
I believe this new distribution mechanism will help both Eclipse plugin
developers and end users. For example, in WTP, there's a Web app called
the Web Services Explorer which allows you to query business/services/etc
from an UDDI registery. This Web app uses Apache Axis as the underlying
SOAP engine. As a developer, I would like the ability to update the
underlying Axis engine without having to rebuild WTP. Reason is simple, if
Axis releases a fix, without the support of an update manager site,
there's no easy way to get this fix into the current version of WTP. I
(and end users) will have to wait for the next release of WTP in order to
pick up this fix. Since Axis and WTP run on different schedules, it would
be a nightmare to manage what fix gets into what release..... For end
users, this update site can improve usability as well. I'll reuse the
example from the original post. Picture that a end user is trying to
generate a Web service using WTP. The user finds out that s/he does not
have Axis and Tomcat downloaded. So the user download them manually and
configure them into the Eclipse workspace. Configure in this case requires
the user to launch the preference page and point WTP to the location of
Axis and Tomcat. New users will not know where to configure Axis and
Tomcat unless s/he reads some documentation. Wouldn't it be nice if the
WTP wizards detect that the user does not have Axis and Tomcat install, so
it pops up a dialog telling the user what's going on, shows the license
agreements to the user and install the Axis and Tomcat plugins
automatically? Btw, another reason why WTP is not redistributing any ASF
projects directly is because there are too many of them. Imagine WTP ships
with Tomcat 3.2, 4.1, 5.0, 5.5... the download size would be huge and
users do not want that. It's better to install things on the fly when it's
needed. That's why I think end users will benefit from this update site as
well.
Thanks,
Jeffrey Liu
IBM Rational Software - Performance Analyst
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/R8V/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920
jeffliu@ca.ibm.com
J Aaron Farr <ja...@gmail.com>
05/03/2005 04:34 PM
Please respond to
repository
To
repository@apache.org
cc
Subject
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Hello all.
I'm also copying over this reply I made from general@incubator.
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
>
> Hi,
>
> This message was originally posted to the general@incubator.apache.org
> mailing list. Someone pointed out that such discussion should be carried
out
> here instead. So I'm re-posting the original message here. Here it goes:
>
> I want to propose a centralized Eclipse update manager site for Apache
> projects/software.
Jeffrey,
In thinking about your proposal more I've got a few questions:
Are you looking for plugins that simply fulfill Eclipse project
dependencies or full-fledged plugins that would, for example, allow
you to launch Axis or Tomcat from within Eclipse? If it's resolving
dependencies, then I don't see how a plugin wrapper around the jars
would do this without some Eclipse code to integrate into the
development environment (WTP,PDE,JDT). AFAIK providing just a plugin
wrapper would only be useful for other plugin developers, not for a
'end-user' developer who would happen to be using the WTP.
Plugins which extend the IDE to use ASF projects such as a Struts or
Tomcat plugin are already available via various third parties. Are
you suggesting the ASF should provide its own Eclipse plugins with
similar functionality?
The Eclipse project itself provides some ASF related plugins, most
notably the Tomcat plugin used for Eclipse's help system. Is this the
sort of plugin you are looking for? Likewise, Eclipse has started the
new Lepido project for a Cocoon development environment. Seeing that
Eclipse already hosts ASF related plugins, is there any reason for the
ASF to host a similar update site?
I can see some advantage to providing ASF releases in plugin form but only
for plugin developers, not for most Eclipse end users.
jaaron
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by J Aaron Farr <ja...@gmail.com>.
Hello all.
I'm also copying over this reply I made from general@incubator.
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
>
> Hi,
>
> This message was originally posted to the general@incubator.apache.org
> mailing list. Someone pointed out that such discussion should be carried out
> here instead. So I'm re-posting the original message here. Here it goes:
>
> I want to propose a centralized Eclipse update manager site for Apache
> projects/software.
Jeffrey,
In thinking about your proposal more I've got a few questions:
Are you looking for plugins that simply fulfill Eclipse project
dependencies or full-fledged plugins that would, for example, allow
you to launch Axis or Tomcat from within Eclipse? If it's resolving
dependencies, then I don't see how a plugin wrapper around the jars
would do this without some Eclipse code to integrate into the
development environment (WTP,PDE,JDT). AFAIK providing just a plugin
wrapper would only be useful for other plugin developers, not for a
'end-user' developer who would happen to be using the WTP.
Plugins which extend the IDE to use ASF projects such as a Struts or
Tomcat plugin are already available via various third parties. Are
you suggesting the ASF should provide its own Eclipse plugins with
similar functionality?
The Eclipse project itself provides some ASF related plugins, most
notably the Tomcat plugin used for Eclipse's help system. Is this the
sort of plugin you are looking for? Likewise, Eclipse has started the
new Lepido project for a Cocoon development environment. Seeing that
Eclipse already hosts ASF related plugins, is there any reason for the
ASF to host a similar update site?
I can see some advantage to providing ASF releases in plugin form but only
for plugin developers, not for most Eclipse end users.
jaaron
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Milos Kleint <mk...@gmail.com>.
there is already a maven plugin that's able to generate eclipse
plugins at http://mevenide.codehaus.org/maven-eclipse-plugin-plugin/index.html
AFAIK Gilles Dodinet is now working on a rewrite that will work both
with m1 and m2.
Regards
Milos Kleint
On 5/12/05, Dion Gillard <di...@gmail.com> wrote:
> Seems like a nice addition to the maven eclipse plugin or as an ant task.
>
> On 5/12/05, J Aaron Farr <ja...@gmail.com> wrote:
> > Found this article which explains how to wrap a jar into a plugin:
> >
> > http://owl-eclipse.projects.semwebcentral.org/CreateLibraryPlugin.html
> >
> > The example assumes you are using Eclipse to do this.
> >
> > --
> > jaaron
> >
>
> --
> http://www.multitask.com.au/people/dion/
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Dion Gillard <di...@gmail.com>.
Seems like a nice addition to the maven eclipse plugin or as an ant task.
On 5/12/05, J Aaron Farr <ja...@gmail.com> wrote:
> Found this article which explains how to wrap a jar into a plugin:
>
> http://owl-eclipse.projects.semwebcentral.org/CreateLibraryPlugin.html
>
> The example assumes you are using Eclipse to do this.
>
> --
> jaaron
>
--
http://www.multitask.com.au/people/dion/
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by J Aaron Farr <ja...@gmail.com>.
Found this article which explains how to wrap a jar into a plugin:
http://owl-eclipse.projects.semwebcentral.org/CreateLibraryPlugin.html
The example assumes you are using Eclipse to do this.
--
jaaron
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Thu, 5 May 2005, Mark R. Diggory wrote:
> >I think I belong to a group who is not totally Eclipse savvy/friendly, and
> >somewhat negative to an explicit support of Eclipse and not for other IDEs.
> I think that as long as we maintain that an Eclipse plugin is just a
> distributable artifact, then we do not provide any more support for
> Eclipse than we would for other IDE's.
If a certain group of people has an Eclipse itch - and really wants to
scratch it - then just let them go for it. It is only when their effords
actively hamper others - or when the people with the itch insists on
others bending over backwards - that the community has a whole need to
think twice.
But from what I see this is clearly an isolated itch - so I'd suggst to
let those who have that itsch scratch it to whatever effect they
accomplish.
Dw.
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 04 May 2005 21:26, Mark R. Diggory wrote:
>
>
>>Sorry if my response sounded abrasive, I'm not trying to be.
>>
>>
>
>No problem. And ditto sorry.
>
>I think I belong to a group who is not totally Eclipse savvy/friendly, and
>somewhat negative to an explicit support of Eclipse and not for other IDEs.
>
>
>Niclas
>
>
>
I think that as long as we maintain that an Eclipse plugin is just a
distributable artifact, then we do not provide any more support for
Eclipse than we would for other IDE's.
cheers,
Mark
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 04 May 2005 21:26, Mark R. Diggory wrote:
> Sorry if my response sounded abrasive, I'm not trying to be.
No problem. And ditto sorry.
I think I belong to a group who is not totally Eclipse savvy/friendly, and
somewhat negative to an explicit support of Eclipse and not for other IDEs.
Niclas
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Brett Porter wrote:
>On 5/5/05, Dion Gillard <di...@gmail.com> wrote:
>
>
>>Where do you see the Eclipse version number (not the artifact version)
>>fitting in?
>>
>>
>
>I was under the impression this would be captured within the archive itself.
>
>But should it need to be part of the path, it is probably sensible to
>make it part of the artifactId/versioning of the file:
>
>mylib-1.0-eclipse.jar
>mylib-1.0-eclipse2.jar
>
>Very rough, obviously. I wasn't really thinking of the specifics at
>this point, however I think it is reasonable to assume that we can or
>should map it to the repository in some way to leverage that. If it
>needs to be able to do more, then we can look at that too.
>
>
>
I believe this naming scheme is critical for Eclipse, so attempting to
redefine like you have above it is a problem. We might even find that
the "plugins" directory is unchangeable. So, I'm suggesting that to
publish a site in the repository, its going to have to look like this:
When Eclipse packages the archive, its not the "Eclipse" version thats
Identified, but the plugin version. so for instance, an Eclipse update
site for Axis would contain the following:
.../plugins/org.apache.axis_1.0.0.jar
.../plugins/org.apache.axis_2.0.0.jar
.../site.xml
The site.xml contains references to the above files. When the jar is
installed using the updater it gets expanded under the path in Eclipse:
eclipse/plugins/org.apache.axis_2.0.0/...
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.0.jar
/java-repository/axis/eclipse-distributions/plugins/site.xml
I'm going to also suggest that The updater will be responsible for
determining dependencies, this means that the closest packaging gets to
a dependency on a specif c "release" of Eclipse is really about the
plugin having different dependencies on the core eclipse runtime. This
means that say we had several versions of axis out where the differences
the dependencies are on a specific runtime plugin.
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.0.jar
>= org.eclipse.runtime_2.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.1.jar
>= org.eclipse.runtime_2.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.2.jar
>= org.eclipse.runtime_2.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.0.jar
>= org.eclipse.runtime_3.0
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.1.jar
>= org.eclipse.runtime_3.0
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.2.jar
>= org.eclipse.runtime_3.0
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.0.jar
>= org.eclipse.runtime_3.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.1.jar
>= org.eclipse.runtime_3.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.2.jar
>= org.eclipse.runtime_3.1
The dependencies would be determined by the Eclipse update manager via
the site.xml, not by the structure of the repository. By reading the
plugins dependencies, Eclipse determines which is the best fit for the
install.
-Mark
>>And what of eclipse features which are a bundling of related plugins
>>and resources?
>>
>>
>
>Again, I thought they were all described in the same way and its
>internal structure decided that.
>
>Cheers,
>Brett
>
>
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Brett Porter <br...@gmail.com>.
On 5/5/05, Dion Gillard <di...@gmail.com> wrote:
> Where do you see the Eclipse version number (not the artifact version)
> fitting in?
I was under the impression this would be captured within the archive itself.
But should it need to be part of the path, it is probably sensible to
make it part of the artifactId/versioning of the file:
mylib-1.0-eclipse.jar
mylib-1.0-eclipse2.jar
Very rough, obviously. I wasn't really thinking of the specifics at
this point, however I think it is reasonable to assume that we can or
should map it to the repository in some way to leverage that. If it
needs to be able to do more, then we can look at that too.
> And what of eclipse features which are a bundling of related plugins
> and resources?
Again, I thought they were all described in the same way and its
internal structure decided that.
Cheers,
Brett
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Dion Gillard <di...@gmail.com>.
Where do you see the Eclipse version number (not the artifact version)
fitting in?
e.g.
/eclipse2-plugins/
/eclipse3-plugins/
/eclipse-plugins/
And what of eclipse features which are a bundling of related plugins
and resources?
On 5/5/05, Brett Porter <br...@gmail.com> wrote:
> > Btw, is there any rules that govern what a project
> > can drop or not drop into the respository?
>
> Anything otherwise distributable should be fine.
>
> As far as I'm concerned, the repository is still the right place for
> these - perhaps under /eclipse-plugins/ (or some more suitable name)
> instead of /jars/.
>
> As I mentioned, this would apply for non-ASF projects using the other
> Maven repositories as well if Eclipse was able to use this repository
> layout to retrieve them.
>
> It should also be possible for projects using Maven to publish their
> Eclipse plugins along with their main distributions at release time,
> if Maven develops a way to construct them and store the necessary
> information in the proejct's one source code repository. I imagine
> this is a pretty simple task, but it's something to think about when
> projects start to take this up.
>
> Cheers,
> Brett
>
--
http://www.multitask.com.au/people/dion/
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Brett Porter <br...@gmail.com>.
> Btw, is there any rules that govern what a project
> can drop or not drop into the respository?
Anything otherwise distributable should be fine.
As far as I'm concerned, the repository is still the right place for
these - perhaps under /eclipse-plugins/ (or some more suitable name)
instead of /jars/.
As I mentioned, this would apply for non-ASF projects using the other
Maven repositories as well if Eclipse was able to use this repository
layout to retrieve them.
It should also be possible for projects using Maven to publish their
Eclipse plugins along with their main distributions at release time,
if Maven develops a way to construct them and store the necessary
information in the proejct's one source code repository. I imagine
this is a pretty simple task, but it's something to think about when
projects start to take this up.
Cheers,
Brett
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Jeffrey Liu <je...@ca.ibm.com>.
Thanks for everyone's input on this. To clarify, it is the second set of
dependencies that I am interested in. After reading up on many of the
advises posted here, I agree that there's no need for another repository.
The question now becomes whether ASF should host these plugin
distributions, and if so, what the structure would be. Jaaron, may I ask
what are your concerns with ASF hosting these plugin distributions? As
suggested by Mark earlier, the goal here is not to require all projects to
provide such plugin distribution. It remains a project decision to provide
this or not. But it would be nice to see the projects that are already
being used in Eclipse to take the lead on this. Btw, is there any rules
that govern what a project can drop or not drop into the respository?
Thanks,
Jeffrey Liu
J Aaron Farr <ja...@gmail.com>
05/04/2005 10:16 AM
Please respond to
repository
To
repository@apache.org
cc
Subject
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Before the conversation continues on a little, I think we need to
clarify how things work in Eclipse.
First off, there are two types of dependencies in Eclipse. One is the
traditional IDE project dependency. For example, let's say I'm
developing a Struts application. I'll need the Struts jars and a
couple Jakarta Commons jars and whatnot in my classpath. From what I
understand of Jeffrey's proposal, it isn't going to handle these sort
of dependencies at all. Instead, if you wanted to use the ASF's
java-repository, you would end up using Maven and either run "maven
eclipse" to configure the dependencies or use one of the couple
Eclipse plugins for Maven such as Mevenide to do essentially the same
thing. Point is, these are not the dependencies you are looking for.
Move along... :-)
The second type of dependency is internal to Eclipse. They are
inter-plugin dependencies. For example, suppose I have an Eclipse
plugin that uses Derby as an embedded database. I can either include
the derby jars in my own plugin, or I can wrap the Derby jars into a
second plugin and then make my plugin dependent on the Derby plugin.
If I choose this split route, then if there is some bug fix update to
Derby then the users of my plugin don't have to wait to get the bug
fix until I release an update to my plugin. Instead, they can
directly (even automatically) update their Derby plugin independently.
As David pointed out much earlier in this thread, there is a bit of a
risk when users start updating these dependencies on their own, but
Eclipse provides a versioning mechanism for plugin which can mitigate
this concern.
As a plugin developer, if I know these ASF Eclipse plugin wrapped
releases exist, then I can use them instead of directly including them
in my own plugin. To truly take advantage of them, I might have to
include some code in my plugin, but no special Eclipse code would be
required in the ASF plugin.
If I'm reading Jeffrey's proposal correctly, it's this second set of
dependencies he is interested in. Accomplishing this would still
require some work by a release manager to properly wrap up the jars
along with the Eclipse plugin metadata. However, most of the work
would be done my other plugin developers who were interested in taking
advantage of these ASF plugins.
I'm not certain that having the ASF host these plugins is really the
right approach, but at least we should be clear that the proposal is
not about IDE project dependencies.
--
jaaron
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by J Aaron Farr <ja...@gmail.com>.
Before the conversation continues on a little, I think we need to
clarify how things work in Eclipse.
First off, there are two types of dependencies in Eclipse. One is the
traditional IDE project dependency. For example, let's say I'm
developing a Struts application. I'll need the Struts jars and a
couple Jakarta Commons jars and whatnot in my classpath. From what I
understand of Jeffrey's proposal, it isn't going to handle these sort
of dependencies at all. Instead, if you wanted to use the ASF's
java-repository, you would end up using Maven and either run "maven
eclipse" to configure the dependencies or use one of the couple
Eclipse plugins for Maven such as Mevenide to do essentially the same
thing. Point is, these are not the dependencies you are looking for.
Move along... :-)
The second type of dependency is internal to Eclipse. They are
inter-plugin dependencies. For example, suppose I have an Eclipse
plugin that uses Derby as an embedded database. I can either include
the derby jars in my own plugin, or I can wrap the Derby jars into a
second plugin and then make my plugin dependent on the Derby plugin.
If I choose this split route, then if there is some bug fix update to
Derby then the users of my plugin don't have to wait to get the bug
fix until I release an update to my plugin. Instead, they can
directly (even automatically) update their Derby plugin independently.
As David pointed out much earlier in this thread, there is a bit of a
risk when users start updating these dependencies on their own, but
Eclipse provides a versioning mechanism for plugin which can mitigate
this concern.
As a plugin developer, if I know these ASF Eclipse plugin wrapped
releases exist, then I can use them instead of directly including them
in my own plugin. To truly take advantage of them, I might have to
include some code in my plugin, but no special Eclipse code would be
required in the ASF plugin.
If I'm reading Jeffrey's proposal correctly, it's this second set of
dependencies he is interested in. Accomplishing this would still
require some work by a release manager to properly wrap up the jars
along with the Eclipse plugin metadata. However, most of the work
would be done my other plugin developers who were interested in taking
advantage of these ASF plugins.
I'm not certain that having the ASF host these plugins is really the
right approach, but at least we should be clear that the proposal is
not about IDE project dependencies.
--
jaaron
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 04 May 2005 20:06, Mark Diggory wrote:
>
>
>>Thats a little pretentious, so Eclipse should support Maven, but not the
>>other way around? This is not about "every" Apache project having to
>>release Eclipse plugin format, just those that want to. Its trivial for
>>a project to organize an artifact directory for Eclipse
>>plugins/features. And doing so promotes more interoperability between
>>the two.
>>
>>
>
>My assertion is mostly based on the fact that almost 600 top level group names
>exist on http://www.ibiblio.org/maven, and go around asking the same question
>to a larger group of those seems to me to be very ineffective, especially
>since the benefit isn't obvious to those who have to do the work.
>
>
>
Sorry if my response sounded abrasive, I'm not trying to be. He was
simply asking advice on who to consult on publishing Eclipse artifacts.
The ASF Repository list is about discussing this kind of subject.
The benefit is in a greater, more useful "ASF Repository". Initially,
they thought they would need a separate "repository" to maintain these
distributables. They brought the subject up on the Incubator list
because of this, the moderator suggested it was a topic for the
repository list (which it is).
The question has now turned into how to physically structure a eclipse
plugin/feature distribution in the ASF repository so that it can be
accessed using the Eclipse update mechanism. I don't think the goal was
to require all TLP's to begin packaging everything to work in the
Eclipse updater. Nor, that they have a responsibility to do so, only
that if they wish to do so, that they may.
If it ultimately is determined that ASF repository isn't the place for
this (which would be sad indeed), then I'd recommend that the plugins
just be distributed out of the projects
"/www/www.apache.org/dist/<project>" directory at Apache (which
ultimately defeats our efforts to have a generic repository architecture).
>If Maven can generate it without any additional effort, then you have solved
>it for a chunk of those projects, that's great. I still maintain as a general
>rule that those who benefit, should also carry the majority of the burden, in
>this case Eclipse users/developers.
>
>
>Cheers
>Niclas
>
>
I think many of us wear multiple hats, working on many different OS
projects. The burden become less about "who is responsible" and more
about "wheres the best place to maintain code/releases".
-Mark
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 04 May 2005 20:06, Mark Diggory wrote:
> Thats a little pretentious, so Eclipse should support Maven, but not the
> other way around? This is not about "every" Apache project having to
> release Eclipse plugin format, just those that want to. Its trivial for
> a project to organize an artifact directory for Eclipse
> plugins/features. And doing so promotes more interoperability between
> the two.
My assertion is mostly based on the fact that almost 600 top level group names
exist on http://www.ibiblio.org/maven, and go around asking the same question
to a larger group of those seems to me to be very ineffective, especially
since the benefit isn't obvious to those who have to do the work.
If Maven can generate it without any additional effort, then you have solved
it for a chunk of those projects, that's great. I still maintain as a general
rule that those who benefit, should also carry the majority of the burden, in
this case Eclipse users/developers.
Cheers
Niclas
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Mark Diggory <md...@gmail.com>.
Niclas Hedhman wrote:
>On Wednesday 04 May 2005 04:12, Jeffrey Liu wrote:
>
>
>>I want to propose a centralized Eclipse update manager site for Apache
>>projects/software. Reason I propose an Eclipse update manager site for
>>Apache projects/software
>>
>>
>
>IIUYC, and perhaps others have not expressed this distinctly enough;
>
>It should be a lot less effort to ask Eclipse to support Maven styled
>repositories as well as its own system. By doing so, you get what I think you
>are fishing for, without the need for every Apache and SF.net project to
>publish their respective artifacts in Eclipse specific format.
>
>
Thats a little pretentious, so Eclipse should support Maven, but not the
other way around? This is not about "every" Apache project having to
release Eclipse plugin format, just those that want to. Its trivial for
a project to organize an artifact directory for Eclipse
plugins/features. And doing so promotes more interoperability between
the two.
A simple directory structure for eclipse artifacts:
/maven/axis/site.xml
/maven/axis/plugins/<plugin>.jar
/maven/axis/features/<feature>.jar
or
/maven/axis/eclipse/site.xml
/maven/axis/eclipse/plugins/<plugin>.jar
/maven/axis/eclipse/features/<feature>.jar
>On top of that, people over at the DPML (www.dpml.net) are working on
>providing Maven repository support for Eclipse, by leveraging the Transit
>sub-project which is capable of referencing artifacts (i.e. content) on
>Maven-styled organized (and others) repositories.
>Example;
>
> URL url = new URL( "artifact:jar:tomcat/catalina#5.5.9" );
> InputStream in = url.openStream();
>
>and the catalina-5.5.9.jar will be searched on the configured repositories.
>The Eclipse support effort is basically a matter of registration of the
>artifact: protocol to the OSGi network subsystem, and overcoming Eclipse's
>inability to use URLs instead of almost always requiring files :o( , so it
>will take quite a long time before those guys reach all the way we want.
>In any event, when the external Jar reference is created, the artifact: URI
>could be used, and with proper support in Eclipse, I think this is a
>non-issue for ASF projects.
>
>Cheers
>Niclas
>
>
Yes, thats very elegant, I hope that they are talking with Eclipse folks
and OSGi folk, or at least reviewing the specification to establish if
common strategies already exist there. But, thats a long way down the
road to interoperability. What's hoped for here is a place to store
plugin and feature artifacts for an apache project "now". It is not
think it much to ask...This IS what Maven was designed to be capable of
doing. If one wants to publish their own custom distributable, they can
configure Maven to do so.
-Mark
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 04 May 2005 04:12, Jeffrey Liu wrote:
>
>
>>I want to propose a centralized Eclipse update manager site for Apache
>>projects/software. Reason I propose an Eclipse update manager site for
>>Apache projects/software
>>
>>
>
>IIUYC, and perhaps others have not expressed this distinctly enough;
>
>It should be a lot less effort to ask Eclipse to support Maven styled
>repositories as well as its own system. By doing so, you get what I think you
>are fishing for, without the need for every Apache and SF.net project to
>publish their respective artifacts in Eclipse specific format.
>
>
Thats a little pretentious, so Eclipse should support Maven, but not the
other way around? This is not about "every" Apache project having to
release Eclipse plugin format, just those that want to. Its trivial for
a project to organize an artifact directory for Eclipse
plugins/features. And doing so promotes more interoperability between
the two.
A simple directory structure for eclipse artifacts:
/maven/axis/site.xml
/maven/axis/plugins/<plugin>.jar
/maven/axis/features/<feature>.jar
or
/maven/axis/eclipse/site.xml
/maven/axis/eclipse/plugins/<plugin>.jar
/maven/axis/eclipse/features/<feature>.jar
>On top of that, people over at the DPML (www.dpml.net) are working on
>providing Maven repository support for Eclipse, by leveraging the Transit
>sub-project which is capable of referencing artifacts (i.e. content) on
>Maven-styled organized (and others) repositories.
>Example;
>
> URL url = new URL( "artifact:jar:tomcat/catalina#5.5.9" );
> InputStream in = url.openStream();
>
>and the catalina-5.5.9.jar will be searched on the configured repositories.
>The Eclipse support effort is basically a matter of registration of the
>artifact: protocol to the OSGi network subsystem, and overcoming Eclipse's
>inability to use URLs instead of almost always requiring files :o( , so it
>will take quite a long time before those guys reach all the way we want.
>In any event, when the external Jar reference is created, the artifact: URI
>could be used, and with proper support in Eclipse, I think this is a
>non-issue for ASF projects.
>
>Cheers
>Niclas
>
>
Yes, thats very elegant, I hope that they are talking with Eclipse folks
and OSGi folk, or at least reviewing the specification to establish if
common strategies already exist there. But, thats a long way down the
road to interoperability. What's hoped for here is a place to store
plugin and feature artifacts for an apache project "now". It is not
think it much to ask...This IS what Maven was designed to be capable of
doing. If one wants to publish their own custom distributable, they can
configure Maven to do so.
-Mark
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 04 May 2005 04:12, Jeffrey Liu wrote:
> I want to propose a centralized Eclipse update manager site for Apache
> projects/software. Reason I propose an Eclipse update manager site for
> Apache projects/software
IIUYC, and perhaps others have not expressed this distinctly enough;
It should be a lot less effort to ask Eclipse to support Maven styled
repositories as well as its own system. By doing so, you get what I think you
are fishing for, without the need for every Apache and SF.net project to
publish their respective artifacts in Eclipse specific format.
On top of that, people over at the DPML (www.dpml.net) are working on
providing Maven repository support for Eclipse, by leveraging the Transit
sub-project which is capable of referencing artifacts (i.e. content) on
Maven-styled organized (and others) repositories.
Example;
URL url = new URL( "artifact:jar:tomcat/catalina#5.5.9" );
InputStream in = url.openStream();
and the catalina-5.5.9.jar will be searched on the configured repositories.
The Eclipse support effort is basically a matter of registration of the
artifact: protocol to the OSGi network subsystem, and overcoming Eclipse's
inability to use URLs instead of almost always requiring files :o( , so it
will take quite a long time before those guys reach all the way we want.
In any event, when the external Jar reference is created, the artifact: URI
could be used, and with proper support in Eclipse, I think this is a
non-issue for ASF projects.
Cheers
Niclas
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Steve Loughran <st...@gmail.com>.
On 5/4/05, Niclas Hedhman <ni...@apache.org> wrote:
> On Wednesday 04 May 2005 19:54, Milos Kleint wrote:
> > > Milos, didn't Netbeans itself devise some funky system for the
> > > non-distributables and click-thru license approvals??
> >
> > AFAIK such dependencies are scrambled and during the build process a
> > special ant task shows a dialog with license and unscrables them. Not
> > sure it's something like that could be generalized.
>
> But why is it legally possible for Netbeans (not accounting for Sun being Sun)
> to do such manouver ?
>
Presumably the files in question are hosted on Sun sites, so there is
no redistribution until the actual download in the ant task. That is
not a facility we have.
NB, one defect in the netbeans process is that it requests permissions
again even on a point update of an existing binary. Really it should
only ask if the license has changed.
-steve
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Milos Kleint <mk...@gmail.com>.
On 5/4/05, Niclas Hedhman <ni...@apache.org> wrote:
> On Wednesday 04 May 2005 19:54, Milos Kleint wrote:
> > > Milos, didn't Netbeans itself devise some funky system for the
> > > non-distributables and click-thru license approvals??
> >
> > AFAIK such dependencies are scrambled and during the build process a
> > special ant task shows a dialog with license and unscrables them. Not
> > sure it's something like that could be generalized.
>
> But why is it legally possible for Netbeans (not accounting for Sun being Sun)
> to do such manouver ?
>
no idea.
Milos Kleint
> Cheers
> Niclas
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Niclas Hedhman <ni...@apache.org>.
On Wednesday 04 May 2005 19:54, Milos Kleint wrote:
> > Milos, didn't Netbeans itself devise some funky system for the
> > non-distributables and click-thru license approvals??
>
> AFAIK such dependencies are scrambled and during the build process a
> special ant task shows a dialog with license and unscrables them. Not
> sure it's something like that could be generalized.
But why is it legally possible for Netbeans (not accounting for Sun being Sun)
to do such manouver ?
Cheers
Niclas
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Good stuff, maybe it'd be good to start a separate thread from the
Eclipse plugin artifact topic. -Mark
Steve Loughran wrote:
>On 5/4/05, Niclas Hedhman <ni...@apache.org> wrote:
>
>
>>On Wednesday 04 May 2005 19:34, Steve Loughran wrote:
>>
>>
>>
>>>maven repositories are fun because every JAR is on a URL; you can pass
>>>them to a URL classloader as is if you want. The .pom also declares
>>>dependencies for transitive work; a bit like debian apt-get.
>>>
>>>
>>I have missed this progress. Can you point me to the implementation of this?
>>
>>
>
>nothing in ant yet; maybe maven2. But the idea of a java version of
>apt-get with less 'one version per system' is a vision that should
>drive us all.
>
>
>
>
>
>
>>>-a gui client that could work with the existing Apache repositories
>>>-a client build on AWT for broadest cross platform execution.
>>>-some way of pushing out packages to multiple systems in a cluster
>>>-support per/user, per-system packages
>>>-good auditing to determine package set (with JMX integration)
>>>
>>>That is, a Java successor to all the rpm management tools.
>>>
>>>
>>Do you have any pointer to more elaborate ideas in this area??
>>
>>
>
>not yet. Like I said, I was at a configuration workshop last week. It
>was mostly about XML representations of configuration/state, but we
>drifted into the Open Source area a few times
>
>-Carwen covered JPackage and Config4Gnu
> jpackage is interesting, even though I'm personally unhappy with it.
>Its strength is it tries to integrate java package redist with the
>rpm framework. Its weaknesses are
>
>1. the core project teams dont think about it, need to be coerced into
>patching scripts and other things to work with jpackage
>
>2. RPM is very superuser-centric. I shouldnt have to be su to install
>stuff on my account.
>
>3. RPM is only good on redhat/suse/mandrake, and is somewhat brittle
>there. Partly that's to do with binaries, but also to do with
>locations of things.
>
>For the curious, I was talking about Smartfrog, and demoed a live
>download and run of Axis tcpmon from the m2 repository. The biggest
>issue i have there is signatures; we cant sign the JARs without side
>effects; I can put the SHA1 or MD5 checksums in the deployment
>descriptor, but that makes it too brittle to change.
>
>
>
>>>Incidentally, one pressing problem with the maven repositories is
>>>there is no easy way to fetch Sun stuff. That is, if I want to use
>>>Axis with mail.jar and activation,jar, you cant get those from the
>>>Apache site for legal reasons. Do you propose any solution to the
>>>clickthrough licensing problem?
>>>
>>>
>>Milos, didn't Netbeans itself devise some funky system for the
>>non-distributables and click-thru license approvals??
>>
>>
>>
>
>It publishes stuff encrypted; you need to click through or have a
>secret decryption key for automated builds. I am getting very close to
>mounting a maven2 repository of sun stuff at work, just to avoid their
>clickthrough junk.
>
>
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Steve Loughran <st...@gmail.com>.
On 5/4/05, Niclas Hedhman <ni...@apache.org> wrote:
> On Wednesday 04 May 2005 19:34, Steve Loughran wrote:
>
> > maven repositories are fun because every JAR is on a URL; you can pass
> > them to a URL classloader as is if you want. The .pom also declares
> > dependencies for transitive work; a bit like debian apt-get.
>
> I have missed this progress. Can you point me to the implementation of this?
nothing in ant yet; maybe maven2. But the idea of a java version of
apt-get with less 'one version per system' is a vision that should
drive us all.
>
> > -a gui client that could work with the existing Apache repositories
> > -a client build on AWT for broadest cross platform execution.
> > -some way of pushing out packages to multiple systems in a cluster
> > -support per/user, per-system packages
> > -good auditing to determine package set (with JMX integration)
> >
> > That is, a Java successor to all the rpm management tools.
>
> Do you have any pointer to more elaborate ideas in this area??
not yet. Like I said, I was at a configuration workshop last week. It
was mostly about XML representations of configuration/state, but we
drifted into the Open Source area a few times
-Carwen covered JPackage and Config4Gnu
jpackage is interesting, even though I'm personally unhappy with it.
Its strength is it tries to integrate java package redist with the
rpm framework. Its weaknesses are
1. the core project teams dont think about it, need to be coerced into
patching scripts and other things to work with jpackage
2. RPM is very superuser-centric. I shouldnt have to be su to install
stuff on my account.
3. RPM is only good on redhat/suse/mandrake, and is somewhat brittle
there. Partly that's to do with binaries, but also to do with
locations of things.
For the curious, I was talking about Smartfrog, and demoed a live
download and run of Axis tcpmon from the m2 repository. The biggest
issue i have there is signatures; we cant sign the JARs without side
effects; I can put the SHA1 or MD5 checksums in the deployment
descriptor, but that makes it too brittle to change.
>
> > Incidentally, one pressing problem with the maven repositories is
> > there is no easy way to fetch Sun stuff. That is, if I want to use
> > Axis with mail.jar and activation,jar, you cant get those from the
> > Apache site for legal reasons. Do you propose any solution to the
> > clickthrough licensing problem?
>
> Milos, didn't Netbeans itself devise some funky system for the
> non-distributables and click-thru license approvals??
>
It publishes stuff encrypted; you need to click through or have a
secret decryption key for automated builds. I am getting very close to
mounting a maven2 repository of sun stuff at work, just to avoid their
clickthrough junk.
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Milos Kleint <mk...@gmail.com>.
On 5/4/05, Niclas Hedhman <ni...@apache.org> wrote:
> On Wednesday 04 May 2005 19:34, Steve Loughran wrote:
<snip>
>
> > Incidentally, one pressing problem with the maven repositories is
> > there is no easy way to fetch Sun stuff. That is, if I want to use
> > Axis with mail.jar and activation,jar, you cant get those from the
> > Apache site for legal reasons. Do you propose any solution to the
> > clickthrough licensing problem?
>
> Milos, didn't Netbeans itself devise some funky system for the
> non-distributables and click-thru license approvals??
>
AFAIK such dependencies are scrambled and during the build process a
special ant task shows a dialog with license and unscrables them. Not
sure it's something like that could be generalized.
Milos Kleint
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Niclas Hedhman <ni...@apache.org>.
On Wednesday 04 May 2005 19:34, Steve Loughran wrote:
> maven repositories are fun because every JAR is on a URL; you can pass
> them to a URL classloader as is if you want. The .pom also declares
> dependencies for transitive work; a bit like debian apt-get.
I have missed this progress. Can you point me to the implementation of this?
> -a gui client that could work with the existing Apache repositories
> -a client build on AWT for broadest cross platform execution.
> -some way of pushing out packages to multiple systems in a cluster
> -support per/user, per-system packages
> -good auditing to determine package set (with JMX integration)
>
> That is, a Java successor to all the rpm management tools.
Do you have any pointer to more elaborate ideas in this area??
> Incidentally, one pressing problem with the maven repositories is
> there is no easy way to fetch Sun stuff. That is, if I want to use
> Axis with mail.jar and activation,jar, you cant get those from the
> Apache site for legal reasons. Do you propose any solution to the
> clickthrough licensing problem?
Milos, didn't Netbeans itself devise some funky system for the
non-distributables and click-thru license approvals??
Cheers
Niclas
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Steve Loughran <st...@gmail.com>.
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
>
> Hi Steve,
>
> Configure in this case means the user goes to the Eclipse perference page,
> choose the version of Tomcat that was downloaded, and point Eclipse to the
> location where it was unzipped. Nothing major, but not obvious to novice
> users. Although I'm not similar with what autonomic-system-management is, I
> don't think this is anything near that.
Well, that's all right then. I was worried you were thinking of
configuring tomcat to find a spare port, open a hole in the firewall,
etc etc.
But if you arent doing that, then this proposal is purely for the
Eclipse IDE itself?
That's a bit, well, limited.
We currently have three ways of distributing stuff
-on the web, for download
-as rpms, including jpackage rpms of java stuff
-as maven/maven2 downloads
RPMs are interesting because although linux-centric (and redhat
centric, to be precise), there are a lot of tools out there than can
pump them out to systems in a cluster; you get good management.
maven repositories are fun because every JAR is on a URL; you can pass
them to a URL classloader as is if you want. The .pom also declares
dependencies for transitive work; a bit like debian apt-get.
We are just starting to roll out Maven2 support, both in Apache and
outside it. I am not (yet) convinced we need
yet-another-archive-format with another set of distributables, and if
it only benefited one IDE, I dont think it is justifiable. It would
surely be better if we had
-a gui client that could work with the existing Apache repositories
-a client build on AWT for broadest cross platform execution.
-some way of pushing out packages to multiple systems in a cluster
-support per/user, per-system packages
-good auditing to determine package set (with JMX integration)
That is, a Java successor to all the rpm management tools.
Incidentally, one pressing problem with the maven repositories is
there is no easy way to fetch Sun stuff. That is, if I want to use
Axis with mail.jar and activation,jar, you cant get those from the
Apache site for legal reasons. Do you propose any solution to the
clickthrough licensing problem?
-steve
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Jeffrey Liu <je...@ca.ibm.com>.
Hi Steve,
Configure in this case means the user goes to the Eclipse perference page,
choose the version of Tomcat that was downloaded, and point Eclipse to the
location where it was unzipped. Nothing major, but not obvious to novice
users. Although I'm not similar with what autonomic-system-management is,
I don't think this is anything near that.
Thanks,
Jeffrey Liu
IBM Rational Software - Performance Analyst
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/R8V/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920
jeffliu@ca.ibm.com
Steve Loughran <st...@gmail.com>
05/03/2005 04:54 PM
Please respond to
repository
To
repository@apache.org
cc
Subject
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
> This is not easy. If there's an Eclipse update manager site for Apache
> software, then when the user finds out s/he needs Tomcat and Axis, all
s/he
> needs to do now is launch the Eclipse update manager (URL to the Apache
> update site will be preloaded), select Tomcat and Axis and click Finish.
The
> Eclipse update manager will download, install and configure Tomcat and
Axis
> automatically. This is much better than asking the user to download and
> configure things manually. Also, this Eclipse update manager site is
useful
> when new versions of a Apache software is available. For example:
What do you mean by "configure"
I ask as I am just back from a workshop on Configuration Management
tools at Edinburgh University, and want to see how far on the path
towards autonomic-system-management you are aiming.
Downloading stuff is easy. Getting it to work is a different problem.
-steve
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Steve Loughran <st...@gmail.com>.
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> wrote:
> This is not easy. If there's an Eclipse update manager site for Apache
> software, then when the user finds out s/he needs Tomcat and Axis, all s/he
> needs to do now is launch the Eclipse update manager (URL to the Apache
> update site will be preloaded), select Tomcat and Axis and click Finish. The
> Eclipse update manager will download, install and configure Tomcat and Axis
> automatically. This is much better than asking the user to download and
> configure things manually. Also, this Eclipse update manager site is useful
> when new versions of a Apache software is available. For example:
What do you mean by "configure"
I ask as I am just back from a workshop on Configuration Management
tools at Edinburgh University, and want to see how far on the path
towards autonomic-system-management you are aiming.
Downloading stuff is easy. Getting it to work is a different problem.
-steve