Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
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
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
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
On 5/4/05, Niclas Hedhman <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
On 5/4/05, Niclas Hedhman <[EMAIL PROTECTED]> 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
Brett Porter wrote: On 5/5/05, Dion Gillard <[EMAIL PROTECTED]> 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
On 5/5/05, Dion Gillard <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
> 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
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 <[EMAIL PROTECTED]> 05/04/2005 10:16 AM Please respond to repository To [EMAIL PROTECTED] 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
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
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/" 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
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
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/.jar /maven/axis/features/.jar or /maven/axis/eclipse/site.xml /maven/axis/eclipse/plugins/.jar /maven/axis/eclipse/features/.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
On 5/4/05, Niclas Hedhman <[EMAIL PROTECTED]> 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
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/.jar /maven/axis/features/.jar or /maven/axis/eclipse/site.xml /maven/axis/eclipse/plugins/.jar /maven/axis/eclipse/features/.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
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
On 5/4/05, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Wednesday 04 May 2005 19:34, Steve Loughran wrote: > > > 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
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
On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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
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
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
Jeffrey, Yes as they pointed out I'm moving our responses to the thread to the repository group. Each project is responsible for their repository contents. So, from this standpoint, if you took Axis for example, the Axis group would be responsible for managing the release of any Axis Eclipse plugin artifacts into the repository. Now, the benefit (or burden) of this is that Axis gets canonical control of managing the distribution of such a plugin and can maintain authority of its release cycle. So ultimately, you should hop onto the Axis list and start a discussion there concerning if they are interested in maintaining the plugin. Some important facts about the repository. 1.) The repository under www.apache.org/dist/java-repository is only for full releases of apache projects (not nightly/integration builds). 2.) Its is not advised that you point users directly at the above url, but go through any of the many Apache mirrors. 3.) All released artifacts should be signed by author using both PGP and MD5 signatures. In regards to (2), I'd be interested in seeing how the new mirrors feature of the Eclipse update manager can handle this gracefully. Jeffrey Liu wrote: Hi Mark, Thanks for the clarification. If I understand it correctly, this means potentially I can put plugin distributions into this repository, host a site.xml file somewhere and point to these plugin distributions? Also, this is probably a dumb question, but I'll ask anyways. Who is responsible for putting these release distributions into this repository? Individual projects? Is this done automatically (each build/release)? 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 [EMAIL PROTECTED] Mark Diggory <[EMAIL PROTECTED]> 05/03/2005 03:58 PM Please respond to general To general@incubator.apache.org cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software Slow down, to clarify, the repository is not just for "Jar's", it is for any release distributions. An Eclipse plugin for, lets say, Ant, would be a distributable, just like any other binary or src distribution in the repository. In Eclipse, a plugin archive is "poorly" prefixed with the extension "jar", it is really a zip archive containing everything for that plugin (from what I understand, this will change in the future and it will truly be a jar, but that is an aside). The repository can hold these files and referencing them using a site.xml could happen from just about anywhere else (such as the project website). -Mark Diggory Jeffrey Liu wrote: Hi Dion, Thanks for your response. The existing repository won't work. Unlike a Java application, putting JARs on the classpath is not sufficient to make Eclipse aware of these libraries. Eclipse needs to work with something known as an Eclipse plug-in, which is really the JARs themselves plus a couple XML configuration files. So, in order to make use of the Eclipse update manager, we need to bundle the JARs, the XML configuration files and other files such as license/readme/etc together in the form of an Eclipse plug-in. 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 [EMAIL PROTECTED] Dion Gillard <[EMAIL PROTECTED]> 05/03/2005 10:33 AM Please respond to general To general@incubator.apache.org cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software Is there a reason we can't reuse the existing repository at http://www.apache.org/dist/java-repository/ ? In your example, Eclipse could be configured to check http://www.apache.org/dist/java-repository/axis/jars/ for an update? On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> wrote: Hi, I want to propose a centralized Eclipse update manager site for Apache projects/software. This may not be the correct place to ask this, but I can find a better place to do it, so I decided to start here. If this is not the right place, can somebody point me to the correct location? Thanks! 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 s
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
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
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
Jeffrey, Yes as they pointed out I'm moving our responses to the thread to the repository group. Each project is responsible for their repository contents. So, from this standpoint, if you took Axis for example, the Axis group would be responsible for managing the release of any Axis Eclipse plugin artifacts into the repository. Now, the benefit (or burden) of this is that Axis gets canonical control of managing the distribution of such a plugin and can maintain authority of its release cycle. So ultimately, you should hop onto the Axis list and start a discussion there concerning if they are interested in maintaining the plugin. Some important facts about the repository. 1.) The repository under www.apache.org/dist/java-repository is only for full releases of apache projects (not nightly/integration builds). 2.) Its is not advised that you point users directly at the above url, but go through any of the many Apache mirrors. 3.) All released artifacts should be signed by author using both PGP and MD5 signatures. In regards to (2), I'd be interested in seeing how the new mirrors feature of the Eclipse update manager can handle this gracefully. Jeffrey Liu wrote: Hi Mark, Thanks for the clarification. If I understand it correctly, this means potentially I can put plugin distributions into this repository, host a site.xml file somewhere and point to these plugin distributions? Also, this is probably a dumb question, but I'll ask anyways. Who is responsible for putting these release distributions into this repository? Individual projects? Is this done automatically (each build/release)? 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 [EMAIL PROTECTED] Mark Diggory <[EMAIL PROTECTED]> 05/03/2005 03:58 PM Please respond to general To general@incubator.apache.org cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software Slow down, to clarify, the repository is not just for "Jar's", it is for any release distributions. An Eclipse plugin for, lets say, Ant, would be a distributable, just like any other binary or src distribution in the repository. In Eclipse, a plugin archive is "poorly" prefixed with the extension "jar", it is really a zip archive containing everything for that plugin (from what I understand, this will change in the future and it will truly be a jar, but that is an aside). The repository can hold these files and referencing them using a site.xml could happen from just about anywhere else (such as the project website). -Mark Diggory Jeffrey Liu wrote: Hi Dion, Thanks for your response. The existing repository won't work. Unlike a Java application, putting JARs on the classpath is not sufficient to make Eclipse aware of these libraries. Eclipse needs to work with something known as an Eclipse plug-in, which is really the JARs themselves plus a couple XML configuration files. So, in order to make use of the Eclipse update manager, we need to bundle the JARs, the XML configuration files and other files such as license/readme/etc together in the form of an Eclipse plug-in. 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 [EMAIL PROTECTED] Dion Gillard <[EMAIL PROTECTED]> 05/03/2005 10:33 AM Please respond to general To general@incubator.apache.org cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software Is there a reason we can't reuse the existing repository at http://www.apache.org/dist/java-repository/ ? In your example, Eclipse could be configured to check http://www.apache.org/dist/java-repository/axis/jars/ for an update? On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> wrote: Hi, I want to propose a centralized Eclipse update manager site for Apache projects/software. This may not be the correct place to ask this, but I can find a better place to do it, so I decided to start here. If this is not the right place, can somebody point me to the correct location? Thanks! 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 b
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
t; 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 > > [EMAIL PROTECTED] > > > > > > > > > > > > J Aaron Farr <[EMAIL PROTECTED]> > > > > 05/03/2005 04:34 PM > > > > Please respond to > > repository > > > > > > > > To > > [EMAIL PROTECTED] > > > > 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 [EMAIL PROTECTED] > > > > On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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
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 [EMAIL PROTECTED] Steve Loughran <[EMAIL PROTECTED]> 05/03/2005 04:54 PM Please respond to repository To [EMAIL PROTECTED] cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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
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 [EMAIL PROTECTED] J Aaron Farr <[EMAIL PROTECTED]> 05/03/2005 04:34 PM Please respond to repository To [EMAIL PROTECTED] 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 [EMAIL PROTECTED] On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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 mess
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
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 [EMAIL PROTECTED] J Aaron Farr <[EMAIL PROTECTED]> 05/03/2005 04:34 PM Please respond to repository To [EMAIL PROTECTED] 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 [EMAIL PROTECTED] On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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 plugi
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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
Hello all. I'm also copying over this reply I made from [EMAIL PROTECTED] On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> 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
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
