You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(56) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ben...@id...> - 2004-05-22 12:24:11
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: <mm...@gm...> - 2003-09-09 07:09:03
|
Hello Oliver, I am pretty busy right now as well. But the weather gets worse, and so I have a little bit more time for this projects :-) 1) In my opinion we have to split the whole stuff from ANT. This means, that we cannot use this kind of configuration. The configuration should be centralized in a way, that the user can decide how to use Greebo. So basically this means, that the configuration should be handled by greebo. This enables the user to use different "client"-systems. So, I agree with your suggestions. 2) I believe that we should use an own repository.xml file. This enables us to use several repository files (one global, one user specific and one project specific). 3) Think about JavaDoc, other Resources, Documentation, etc. 4) Exactly, this property file can then be extended by the user, if needed. We should provide a couple of standard adapter, but still there could be a need for extension. 8) Partly agreed. I believe that we should not use the <jar>-tag anymore, since an Artifact could be anything, not only a jar file. Greets Markus > > > > > Hi Markus > > Sorry for the delay but I have a lot of work to do... > > 1) What kind of configuration variables do you mean? Do you want to mov > e > the attributes from the greebo task to this file? > <greebo dir="${contrib.dir}" dependencyFile="${basedir}/dependency. > xml" > omitVersion="true" fileSetId="contrib.fs" > > I think we should still support these attributes in a ant task. The tas > k > implementation fills the properties in java.util.Properties and pass th > is > information to the Greebo Client. So, the whole implementation of Greeb > o is > independent from Ant. I guess there is also a plugin mechanism to integ > rate > greebo into Maven. > > > 2) You mean, you what to move the following properties to an ant > independent configuration file? > <repository url="file:///${deploy.dir.local}" type="maven" > synchronize="true"/> > <repository url="http://${deploy.host}/maven" type="maven" timeout= > "1000"/> > > 3) What could an artificate be else than a Jar? > > 4) You mean a properties file as part of the greebo jar? > > 7) As mentioned in 1) > > 8) As you know, I've added the attribute fileSetId to the greebo task w > hich > creates an ant fileset. I can then reference this fileset to build or r > un > my application. Sometimes, I only need some jars to build the applicati > on > but not for the runtime. I guess, you're addressing this issue? I don't > > understand what impact your attribute of the artifact should have? > > I want to have a more flexible dependency.xml. Instead of: > <dependency> > <id>ant</id> > <jar>ant-1.5.2.jar</jar> > </dependency> > <dependency> > <id>ant</id> > <jar>optional-1.5.2.jar</jar> > </dependency> > > something like: > <dependency> > <id>ant</id> > <version>1.5.2</version> > <jar>ant</jar> > <jar>optional</jar> > </dependency> > > That's much easier... > > Cheers > Oliver > > > > ****************************************************************** > Oliver Wulff > Zürich Versicherungs-Gesellschaft > IA4, CoC Middleware > Postfach, 8085 Zürich > Telefon: +41- 1 628 58 07 > Fax: +41 - 1 623 58 07 > E-Mail: mailto:oli...@zu... > > > > > > > "Markus M. May" > > > <mm...@gm...> An: gr > eeb...@li... > > Gesendet von: Kopie: > > > gre...@li...ur Thema: [G > reebo-devel] Reengineering > > ceforge.net > > > > > > > > > 19.08.2003 21:38 > > > Bitte antworten an > > > greebo-devel > > > > > > > > > > > > > Okay, > finally I checked the stuff from Oliver in. Currently I am working a bi > t > on the design of the project. Because we would like to make Greebo > ant-independent, there are some changes. > 1) I would like to make all of greebo configurable in one .properties o > r > .xml file. > 2) Another xml file will contain the repositories (or should the repos > also be defined in the configuration.xml?) - Also some of the jars are > dependend on a specific repository (a small local repo e.g.), so how to > > design this? > 3) I believe that we will need a couple of Factories. For the Repositor > y > as well as for the Artifacts??? > 4) make property file, which maps a repo type (e.g. MAVEN) to a specifi > c > class, this type can then be used in the repository.xml (attribute of > repository) > 5) make step 4) also for the artifacts > 6) Rename dependency to artifact > 7) make a base class (e.g. GreeboClient) which handles the configuratio > n > and probably also reads the repository.xml and the artifacts.xml > 8) the artifact should have an attribute for the loading time (runtime, > > build, ...) > > So, Ozben what do you think? Oliver? > > Greets, > > Markus > > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > _______________________________________________ > Greebo-devel mailing list > Gre...@li... > https://lists.sourceforge.net/lists/listinfo/greebo-devel > > > > > > > > > ******************* BITTE BEACHTEN ******************* > Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet > möglicherweise vertrauliche oder gesetzlich geschützte Daten oder > Informationen. Zum Empfang derselben ist (sind) ausschliesslich die > genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht > irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese un > ter > Ausschluss jeder Reproduktion zu zerstören und die absendende Person > > umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Greebo-devel mailing list > Gre...@li... > https://lists.sourceforge.net/lists/listinfo/greebo-devel > |
From: Oliver W. <oli...@zu...> - 2003-09-09 05:58:02
|
Hi Markus Sorry for the delay but I have a lot of work to do... 1) What kind of configuration variables do you mean? Do you want to mov= e the attributes from the greebo task to this file? <greebo dir=3D"${contrib.dir}" dependencyFile=3D"${basedir}/dependency.= xml" omitVersion=3D"true" fileSetId=3D"contrib.fs" > I think we should still support these attributes in a ant task. The tas= k implementation fills the properties in java.util.Properties and pass th= is information to the Greebo Client. So, the whole implementation of Greeb= o is independent from Ant. I guess there is also a plugin mechanism to integ= rate greebo into Maven. 2) You mean, you what to move the following properties to an ant independent configuration file? <repository url=3D"file:///${deploy.dir.local}" type=3D"maven" synchronize=3D"true"/> <repository url=3D"http://${deploy.host}/maven" type=3D"maven" timeout=3D= "1000"/> 3) What could an artificate be else than a Jar? 4) You mean a properties file as part of the greebo jar? 7) As mentioned in 1) 8) As you know, I've added the attribute fileSetId to the greebo task w= hich creates an ant fileset. I can then reference this fileset to build or r= un my application. Sometimes, I only need some jars to build the applicati= on but not for the runtime. I guess, you're addressing this issue? I don't= understand what impact your attribute of the artifact should have? I want to have a more flexible dependency.xml. Instead of: <dependency> <id>ant</id> <jar>ant-1.5.2.jar</jar> </dependency> <dependency> <id>ant</id> <jar>optional-1.5.2.jar</jar> </dependency> something like: <dependency> <id>ant</id> <version>1.5.2</version> <jar>ant</jar> <jar>optional</jar> </dependency> That's much easier... Cheers Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... = = "Markus M. May" = = <mm...@gm...> An: gr= eeb...@li... = Gesendet von: Kopie: = = gre...@li...ur Thema: [G= reebo-devel] Reengineering = ceforge.net = = = = = = 19.08.2003 21:38 = = Bitte antworten an = = greebo-devel = = = = = = Okay, finally I checked the stuff from Oliver in. Currently I am working a bi= t on the design of the project. Because we would like to make Greebo ant-independent, there are some changes. 1) I would like to make all of greebo configurable in one .properties o= r .xml file. 2) Another xml file will contain the repositories (or should the repos also be defined in the configuration.xml?) - Also some of the jars are dependend on a specific repository (a small local repo e.g.), so how to= design this? 3) I believe that we will need a couple of Factories. For the Repositor= y as well as for the Artifacts??? 4) make property file, which maps a repo type (e.g. MAVEN) to a specifi= c class, this type can then be used in the repository.xml (attribute of repository) 5) make step 4) also for the artifacts 6) Rename dependency to artifact 7) make a base class (e.g. GreeboClient) which handles the configuratio= n and probably also reads the repository.xml and the artifacts.xml 8) the artifact should have an attribute for the loading time (runtime,= build, ...) So, Ozben what do you think? Oliver? Greets, Markus ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the= best hiring companies. http://www.dice.com/index.epl?rel_code=3D104 _______________________________________________ Greebo-devel mailing list Gre...@li... https://lists.sourceforge.net/lists/listinfo/greebo-devel ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese un= ter Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person= umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe.= |
From: <mm...@gm...> - 2003-08-22 03:00:51
|
Hello, even though it seems, that I am pretty much alone on this one, here another mail concerning the reengineering of Greebo. Last night I took a look at several "ProtocolHandler" and I found a pretty good one at apache. Its name is VFS, and you can get a peek on this project at http://jakarta.apache.org/commons/sandbox/vfs/api.html . So I believe, that the usage of this API will save a lot of our time, and I would strongly suggest to use this one. Regards, Markus |
From: <mm...@gm...> - 2003-08-20 14:35:30
|
Hello, I just have had some time and did some design things on greebo. you can take a look at. Any comments are welcome. Greets Markus |
From: Markus M. M. <mm...@gm...> - 2003-08-20 00:18:55
|
Okay, finally I checked the stuff from Oliver in. Currently I am working a bit on the design of the project. Because we would like to make Greebo ant-independent, there are some changes. 1) I would like to make all of greebo configurable in one .properties or .xml file. 2) Another xml file will contain the repositories (or should the repos also be defined in the configuration.xml?) - Also some of the jars are dependend on a specific repository (a small local repo e.g.), so how to design this? 3) I believe that we will need a couple of Factories. For the Repository as well as for the Artifacts??? 4) make property file, which maps a repo type (e.g. MAVEN) to a specific class, this type can then be used in the repository.xml (attribute of repository) 5) make step 4) also for the artifacts 6) Rename dependency to artifact 7) make a base class (e.g. GreeboClient) which handles the configuration and probably also reads the repository.xml and the artifacts.xml 8) the artifact should have an attribute for the loading time (runtime, build, ...) So, Ozben what do you think? Oliver? Greets, Markus |
From: Oliver W. <oli...@zu...> - 2003-08-19 05:42:56
|
And here is the document: (See attached file: Greebo.doc) ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese unt= er Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe.= |
From: Oliver W. <oli...@zu...> - 2003-08-18 05:52:08
|
Hi Markus My changes: 1) Bugfix in synchronizeFile() long lastModified =3D newFile.lastModified(); destinationFile.setLastModified(lastModified); 2) timeout attribute added to ant task You remember that Java blocks when the TCP connection can't be establis= hed. So I added a static timeout of 500ms. Now, you can set this in the ant = task 3) omitVersion element moved from dependency.xml to ant task attribute This is a quite important feature, so we don't have to deal with versio= n number's in dependency.xml and in fileset definition. 4) ant task creates a fileset of all downloaded jars ant task attribute fileSetId defines the name Sample: <target name=3D"repository"> <mkdir dir=3D"${contrib.dir}"/> <mkdir dir=3D"${deploy.dir.local}"/> <greebo dir=3D"${contrib.dir}" dependencyFile=3D"${basedir}/dependency.xml" omitVersion=3D"true" fileSetId=3D"contrib.fs" > <repository url=3D"file:///${deploy.dir.local}" type=3D"mav= en" synchronize=3D"true"/> <repository url=3D"http://${deploy.host}/maven" type=3D"mav= en" timeout=3D"1000"/> </greebo> </target> <path id=3D"build.classpath"> <pathelement path=3D"${classes.dir}"/> <fileset refid=3D"contrib.fs"/> </path> Here the source: (See attached file: src.zip) I'll be in military the next days. Could you check it in? Cheers Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... = = "Markus M. May" = = <mm...@gm...> An: gr= eeb...@li... = Gesendet von: Kopie: = = gre...@li...ur Thema: Re= : [Greebo-devel] Let's reactivate greebo = ceforge.net = = = = = = 16.08.2003 16:55 = = Bitte antworten an = = greebo-devel = = = = = = Sorry for the late reply :-( Anyway, Oliver, I remember your Documentation, but unfortunately my Laptop got stolen, and so I cannot access this document anymore. Do you= mind to resend it to this list? What kind of updates you mean, when you say, that you are using an updated version in your company? Can you check this stuff in? Regards, Markus PS: I think we really have to push this now. PPS: Ozbene are you still there? mm...@gm... wrote: > I believe that a change in design is not the only thing which should = be > done. also the whole stuff should be a little more flexible and there= for we > should probably start once again with a refactoring. > > > >>I really like this project, so I'll do the design changes to support = both >>file and maven style repositories, and will submit patches in the nex= t few >>days. >> >>Mauro >> > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites includin= g > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_0= 1/01 > _______________________________________________ > Greebo-devel mailing list > Gre...@li... > https://lists.sourceforge.net/lists/listinfo/greebo-devel > > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_0= 1/01 _______________________________________________ Greebo-devel mailing list Gre...@li... https://lists.sourceforge.net/lists/listinfo/greebo-devel = |
From: Markus M. M. <mm...@gm...> - 2003-08-16 15:18:08
|
Sorry for the late reply :-( Anyway, Oliver, I remember your Documentation, but unfortunately my Laptop got stolen, and so I cannot access this document anymore. Do you mind to resend it to this list? What kind of updates you mean, when you say, that you are using an updated version in your company? Can you check this stuff in? Regards, Markus PS: I think we really have to push this now. PPS: Ozbene are you still there? mm...@gm... wrote: > I believe that a change in design is not the only thing which should be > done. also the whole stuff should be a little more flexible and therefor we > should probably start once again with a refactoring. > > > >>I really like this project, so I'll do the design changes to support both >>file and maven style repositories, and will submit patches in the next few >>days. >> >>Mauro >> > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Greebo-devel mailing list > Gre...@li... > https://lists.sourceforge.net/lists/listinfo/greebo-devel > > |
From: Oliver W. <oli...@zu...> - 2003-08-02 13:58:29
|
Hi all I will be present. We are using Greebo (updated version) in our whole build environment to= get the necessary jar files. We already discussed some refactoring issues. You remember my paper and= the suggestion from Ozben. How do we want proceed? Cheers Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... = = mm...@gm... = = Gesendet von: An: gr= eeb...@li... = gre...@li...ur Kopie: = = ceforge.net Thema: Re= : [Greebo-devel] Let's reactivate greebo = = = = = 02.08.2003 11:47 = = Bitte antworten an = = greebo-devel = = = = = = I believe that a change in design is not the only thing which should be= done. also the whole stuff should be a little more flexible and therefo= r we should probably start once again with a refactoring. > I really like this project, so I'll do the design changes to support = both > file and maven style repositories, and will submit patches in the nex= t few > days. > > Mauro > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_0= 1/01 _______________________________________________ Greebo-devel mailing list Gre...@li... https://lists.sourceforge.net/lists/listinfo/greebo-devel = |
From: <mm...@gm...> - 2003-08-02 11:24:35
|
Probably we should generate the main URL from the Repository and the rest from the Artifact. I believe that we should do it probably even more configurable. I will take a look into the maven code and let's see how they have resolved it. Greets > Looking at the code trying to figure out what I did wrong I noticed that > the artifact is being responsible for generating the URL based on checking > the type of repository it is being passed in. > > I think that a better design would be to let the repository define the > URL. This would make the system more flexible, now adding a new repository > would require somebody to change the Artifact classes. > > I understand that this could be due to the intention of grabbing things > other than Jar files, but in the case of, say Javadoc, we'd probably need > another repository type, since you'd need to download a whole web, and not > just 1 or 2 files. > > Mauro > |
From: <mm...@gm...> - 2003-08-02 09:48:16
|
I believe that a change in design is not the only thing which should be done. also the whole stuff should be a little more flexible and therefor we should probably start once again with a refactoring. > I really like this project, so I'll do the design changes to support both > file and maven style repositories, and will submit patches in the next few > days. > > Mauro > |
From: Botelho, M. <Mau...@tu...> - 2003-08-02 00:23:35
|
I really like this project, so I'll do the design changes to support both file and maven style repositories, and will submit patches in the next few days. Mauro |
From: <mm...@gm...> - 2003-08-01 20:11:56
|
Sorry Mauro, but to be honest, this project is not real active anymore. Probably we can try to reactivate it :-) Markus > Looking at the code trying to figure out what I did wrong I noticed that > the artifact is being responsible for generating the URL based on checking > the type of repository it is being passed in. > > I think that a better design would be to let the repository define the > URL. This would make the system more flexible, now adding a new repository > would require somebody to change the Artifact classes. > > I understand that this could be due to the intention of grabbing things > other than Jar files, but in the case of, say Javadoc, we'd probably need > another repository type, since you'd need to download a whole web, and not > just 1 or 2 files. > > Mauro > |
From: Botelho, M. <Mau...@tu...> - 2003-08-01 14:03:03
|
Looking at the code trying to figure out what I did wrong I noticed that the artifact is being responsible for generating the URL based on checking the type of repository it is being passed in. I think that a better design would be to let the repository define the URL. This would make the system more flexible, now adding a new repository would require somebody to change the Artifact classes. I understand that this could be due to the intention of grabbing things other than Jar files, but in the case of, say Javadoc, we'd probably need another repository type, since you'd need to download a whole web, and not just 1 or 2 files. Mauro |
From: Botelho, M. <Mau...@tu...> - 2003-08-01 13:37:14
|
When I try using this: <greebo dir="${buildDir}/lib"> <repository url="http://www.ibiblio.org/maven" type="maven"/> <jarDependency name="servletapi" version="2.3" /> </greebo> I get this output: grabDependencies: [null] Getting: http://www.ibiblio.org/maven/servletapi-2.3.jar [null] Error opening connection java.io.IOException [null] Error opening connection java.io.IOException [null] Error opening connection java.io.IOException [null] Can't get http://www.ibiblio.org/maven/servletapi-2.3.jar to C:\Proj ects\Utils\Utils\lib\servletapi.jar The right location of the file should be: http://www.ibiblio.org/maven/servletapi/servletapi-2.3.jar Am I doing something wrong? Mauro |
From: Oliver W. <oli...@zu...> - 2003-04-04 06:03:00
|
Hi Ozben Yes, I'm still around. The vacation was very nice. Unfortunately, I hav= e to go to the "green" vacation next week which means military and then I wi= ll have more time. Last week, I did some extensions to the greebo-0.1 release so we can us= e it in our company. I did the following changes: 1) omitVersion moved from JarVersion to Ant task attribute 2) fix in synchronizeFile: set file date of target file from source fil= e 3) new attribute "fileSetId" in Ant task which includes all jars listed= in dependency.xml 4) attribute "dir" of Ant task is optional now, if the fileSetId attrib= ute exist but the dir attribute does not, then the first repository has to = have an url like "file://" What I'm just thinking about is to implement something to support the following dependency: <dependency> <group>xerces</group> <version>1.2.6</version> <id>xercesImpl</id> <id>xmlParserAPIs</id> <id>xml-apis</id> </dependency> About repository, I think there are two points which are important here= . First, how is the repository structured and second, how you communicate= with this repository (file://, http://, ...). Ozben, your suggestion fo= r the dynamic structure fits perfectly for the first point. The second po= int should we handle by subclassing. Because there are some points which differs from transport to transport (example: isRepositoryAvailable). I= 'd like to get rid of the "if"'s... I'll try to take a look to your code this weekend before I leave for so= me days... :-( Here is the code of my changes: (See attached file: src.zip) Cheers Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese unt= er Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe. = |
From: Ozben E. <Oz...@di...> - 2003-04-03 17:44:27
|
=20 Guys? Are you there? How was the vacation? :) =20 |
From: Oliver W. <oli...@zu...> - 2003-03-22 11:13:08
|
>> 1) What if you already require a specific version of beanutils in your program? Suppose You require a functionality in beanutils that is prese= nt in versions 1.0 to 1.4 (hypothetical example) and struts 1.1 can use bean-utils with versions 1.3 to 1.6. So the obvious answer is to downlo= ad 1.3 or preferably 1.4. Calculating this in a dependency graph is not a trivial task. It is more like an AI search. 2) What about dependencies that have the same attributes but different types? Consider beanutils-1.1.jar, beanutils-javadoc-1.1.zip and beanutils-src-1.1.jar All have the same attributes (Vendor, group, name= , version) but have different types (javadoc,jar,src). Should they be par= t of the dependency tree? >> I thinkt we should keep it simple as possible. If a dependent jar like struts is necessary and this jar needs other dependent jars then the developer has to decide it at the top level which jars he needs. So, we= don't have to worry about a tree. Especially, if a dependent jar needs = an older version of another jar (log4j-1.1.x) and the developer is using log4j-1.2.x in his code, then he will have a problem anyway which he co= uld only solve with a classloader. In this case, the developer should downl= oad only version 1.2.x from the repository so his code can compile. He has = to find another solution for deployment. >> I am not against having a user to override our repository class, so we = can always have an IRepository interface or an AbstractRepository base clas= s. But, for our purposes, we should have only one Repository class that handles different repository structures depending on an xml file. Then,= if we require to connect to a standardized repository structure like Maven= , then we can let the program use the maven-structure.xml that we distrib= ute with our greebo.jar. >> That sounds good for me. I was just thinking about future requests whic= h shouldn't be handled all in one class as it is at the moment. For examp= le, another transport to get the jars. Currently, we support "file access" = or "http". Looking forward for your changes in the code. But, I'm on vacation too the next five days. I'll enjoy some wellness-d= ays in Austria. Greets Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oli...@zu... ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese unt= er Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe.= |
From: Ozben E. <Oz...@di...> - 2003-03-21 18:24:53
|
> 1) Every repository must contain an xml-file... > Do you mean in the root directory of the repository? So that=20 > greebo reads > this file and can grab the dependencies dependent on the repository > structure? Correct. Whenever greebo connects to the repository, it reads the file, = and figures out the repository structure. This sort of a "map" of the = repository, if you like. >=20 > 2) Every dependency ( or at least...) should have an xml... > What do you mean exactly? Should this file be stored also in=20 > the repository > structure so that greebo can read it? So, you just define the=20 > dependency > struts (1.1) in your local dependeny file and if struts needs the > bean-utils class, it would get this information from this xml file? >=20 This is one of the murky points, and I am still trying to come up with a = good idea. Yes, when you require struts, it will automatically download its dependency bean-utils. But there are = a couple of issues here: 1) What if you already require a specific version of beanutils in your = program? Suppose You require a functionality in beanutils that is = present in versions 1.0 to 1.4 (hypothetical example) and struts 1.1 can = use bean-utils with versions 1.3 to 1.6. So the obvious answer is to = download 1.3 or preferably 1.4. Calculating this in a dependency graph = is not a trivial task. It is more like an AI search.=20 2) What about dependencies that have the same attributes but different = types? Consider beanutils-1.1.jar, beanutils-javadoc-1.1.zip and = beanutils-src-1.1.jar All have the same attributes (Vendor, group, name, = version) but have different types (javadoc,jar,src). Should they be part = of the dependency tree? > 3) Probably we wouldn't need subclassing for repository, I don't know. > Probably, in the near future, we need a feature we can't=20 > handle with the > xml files. So, we have to implement this feature (implementation gets > complexer and complexer). If it's a need for a user of=20 > greebo, he could > implement its own repository class. I think it's not=20 > necessary to define > this xml file for a standardized repository structures like=20 > maven. This can > be programmed fixed in a subclass. So, we'd have an=20 > additional repository > subclass like DynamicRepository which implements this feature. >=20 I am not against having a user to override our repository class, so we = can always have an IRepository interface or an AbstractRepository base = class. But, for our purposes, we should have only one Repository class = that handles different repository structures depending on an xml file. = Then, if we require to connect to a standardized repository structure = like Maven, then we can let the program use the maven-structure.xml that = we distribute with our greebo.jar.=20 > 4) You wrote that the local repository is mostly flat. We are=20 > using the > maven type for the local repository because a lot of projects=20 > are using > this local repository and they are using different versions=20 > of the same > jar. The maven type is a little bit more structured. Well, I didn't mean to say that it should be flat. Rather, it should = basically be a "repository converter", which can grab multiple = dependencies and multiple files from different repositories, and make a = new repository(e.g. Maven like). This also allows us to write a "daemon" = Greebo, which will go out there and grab dependencies from various = sources, and make a local repository for the developers. Imagine, = putting a cron job that calls an ant script which connects to ibiblio, = and grabs the latest. Something like that..for the future... I already started writing some proof-of-concept code, but it is still in = a very early stage. It can only read repository and client configuration = files. I'll add some more to it today. |
From: Ozben E. <Oz...@di...> - 2003-03-21 18:21:28
|
> -----Original Message----- > From: Markus M. May [mailto:mm...@gm...] > Sent: Friday, March 21, 2003 7:41 AM > To: gre...@li... > Subject: Re: Antwort: RE: [Greebo-devel] Proceed... >=20 >=20 > Hello Guys, > some cents from myself. I think Ozben has some great ideas=20 > there. Also,=20 > I believe we should rename the structure to greebo.??? and not to=20 > org.greebo, because this is already taken anyway. > Whatsoever, I am going to vacation now, and I will not be available=20 > until next Thursday. >=20 I'm fine with greebo.*, but what do you mean org.greebo is already = taken? Have a nice vacation!.. :) |
From: Markus M. M. <mm...@gm...> - 2003-03-21 16:25:09
|
Hello Guys, some cents from myself. I think Ozben has some great ideas there. Also, I believe we should rename the structure to greebo.??? and not to org.greebo, because this is already taken anyway. Whatsoever, I am going to vacation now, and I will not be available until next Thursday. Greets Markus Oliver Wulff wrote: >Hi Ozben > >Good idea. >I've got some question to get a picture: > >1) Every repository must contain an xml-file... >Do you mean in the root directory of the repository? So that greebo reads >this file and can grab the dependencies dependent on the repository >structure? > >2) Every dependency ( or at least...) should have an xml... >What do you mean exactly? Should this file be stored also in the repository >structure so that greebo can read it? So, you just define the dependency >struts (1.1) in your local dependeny file and if struts needs the >bean-utils class, it would get this information from this xml file? > >3) Probably we wouldn't need subclassing for repository, I don't know. >Probably, in the near future, we need a feature we can't handle with the >xml files. So, we have to implement this feature (implementation gets >complexer and complexer). If it's a need for a user of greebo, he could >implement its own repository class. I think it's not necessary to define >this xml file for a standardized repository structures like maven. This can >be programmed fixed in a subclass. So, we'd have an additional repository >subclass like DynamicRepository which implements this feature. > >4) You wrote that the local repository is mostly flat. We are using the >maven type for the local repository because a lot of projects are using >this local repository and they are using different versions of the same >jar. The maven type is a little bit more structured. > >I can give you more feedback when I get the answers to question 1 and 2. > >Greets >Oliver > > > > > > >******************* BITTE BEACHTEN ******************* >Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet >möglicherweise vertrauliche oder gesetzlich geschützte Daten oder >Informationen. Zum Empfang derselben ist (sind) ausschliesslich die >genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht >irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter >Ausschluss jeder Reproduktion zu zerstören und die absendende Person >umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Greebo-devel mailing list >Gre...@li... >https://lists.sourceforge.net/lists/listinfo/greebo-devel > > > > |
From: Oliver W. <oli...@zu...> - 2003-03-21 14:37:12
|
Hi Ozben Good idea. I've got some question to get a picture: 1) Every repository must contain an xml-file... Do you mean in the root directory of the repository? So that greebo rea= ds this file and can grab the dependencies dependent on the repository structure? 2) Every dependency ( or at least...) should have an xml... What do you mean exactly? Should this file be stored also in the reposi= tory structure so that greebo can read it? So, you just define the dependenc= y struts (1.1) in your local dependeny file and if struts needs the bean-utils class, it would get this information from this xml file? 3) Probably we wouldn't need subclassing for repository, I don't know. Probably, in the near future, we need a feature we can't handle with th= e xml files. So, we have to implement this feature (implementation gets complexer and complexer). If it's a need for a user of greebo, he could= implement its own repository class. I think it's not necessary to defin= e this xml file for a standardized repository structures like maven. This= can be programmed fixed in a subclass. So, we'd have an additional reposito= ry subclass like DynamicRepository which implements this feature. 4) You wrote that the local repository is mostly flat. We are using the= maven type for the local repository because a lot of projects are using= this local repository and they are using different versions of the same= jar. The maven type is a little bit more structured. I can give you more feedback when I get the answers to question 1 and 2= . Greets Oliver ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese unt= er Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe. = |
From: Ozben E. <Oz...@di...> - 2003-03-20 20:16:30
|
> -----Original Message----- > From: Markus M. May [mailto:mm...@gm...] > Sent: Thursday, March 20, 2003 11:58 AM > To: gre...@li... > Subject: Re: [Greebo-devel] Proceed... >=20 >=20 > Hello, > right now, we should do 2 things. First of all get a clean=20 > release 0.2=20 > out. This release should use the current structure, probably even the=20 > original structure from Ozben. After this release 2 we should=20 > restructure the whole stuff and begin with a new release.=20 > Currently I=20 > am not sure, if the current structure is good enough for a release,=20 > because I believe, we already changed to much. Even the=20 > initial version=20 > is already touched by myself, and I believe is not really a stable=20 > build. Ozben, can we probably kill all the stuff in the cvs and start=20 > from scratch with your release 0.1 and implement then all the wanted=20 > changes we made? How should we do this? What do you think? >=20 +1 for a clean 0.2 But I think we can manage to go with the source base. = I haven't tested the HEAD of cvs myself, but I can do so by this = weekend, and if we aim for low compatibility, and with some JBoss = integration, it should be ok. Then we can start from scratch with a whole new naming convention, and = classes. I still insist on org.greebo.* :) |
From: Ozben E. <Oz...@di...> - 2003-03-20 20:08:21
|
Sorry, I was planning to comment on the design issues. I think, as a = general approach, we should come up with our own repository system, = regardless of what we can borrow from Maven. My thoughts are as follows: First the definition of an artifact: An artifact is a file or a = non-separable group of files. For example, Microsoft SQLServer JDBC = Driver are made of three jar files from Microsoft itself, and thus they = can not be used separately, so they are non-separable, or atomic if you = like. Every artifact(a file, or an atomic group of files) will have a set of = its own dependencies. For example struts-1.1b3 depends on = commons-beanutils-1.0 (Well it may not be so, but this is just an = example). So there should be a configuration associated with every = artifact. If we take this approach, then a project itself can be = considered as an artifact, and hence have a dependency file of itself.=20 If we add this all these artifacts together, then we have a dependency = tree. (Actually it is a graph, but for simplicity, and practical = purposes I think we can safely assume it is a tree for now.) Every artifact has attributes associated with it: - Vendor (Apache) - Group (Commons) - Subgroup (beanutil) - Version (1.0, 1.1b3, SNAPSHOT, HEAD whatever) - Type (Jar, javadoc zip, src zip, dll, exe, etc.) =09 Other than the versioning information, all of these attributes are = linear, and independent of other dependencies. What I mean by that is, = Any combination of attributes except version will give you a unique = artifact, and the version specifies the temporal state of the artifact. = (This might seem like far too much Star Trek for a healthy person, but I = don't know anyway else to specify this.)=20 This also allows a customizable repository structure. As long as = somebody follows the convention of having a = vendor/group/subgroup/type/version attributes (some may be missing) in = their repository structure, it can easily be defined in an XML file. For = example if you have the repository: Apache +--Jakarta +--Commons +--beanutil +--jars +--jakarta-commons-beanutils-1.0.jar Then a dependency to this artifact could be associated like: <dependency id=3D"beanutil" > <vendor id=3D"Apache"/> <group id=3D"Jakarta" /> <group id=3D"Commons" parent-id=3D"Jakarta" /> <group id=3D"beanutil" parent-id=3D"Commons" /> <artifact type=3D"jar" /> </dependency> To define a specific set of files for a dependency, we can use: <dependency> <vendor id=3D"Microsoft"/> <group id=3D"SQLServer JDBC Drivers" /> <artifact type=3D"jar" > <file name=3D"mmssqlserver.jar"/> <file name=3D"msutil.jar"/> <file name=3D"msbase.jar"/> <!-- or if you want to control the naming you can use something like: = --> <!-- <file name=3D"${vendor}-util.${artifact-extension} /> --> </artifact> </dependency> And there can be a configuration file at the top of the repository that = defines the structure. For example: <repository> <structure> <directory id=3D"vendor directory" type=3D"vendor"/> <directory id=3D"major group" type=3D"group[1]"/> <directory id=3D"minor group1" parent-id=3D"major group" = type=3D"group[2]"/> =09 <directory id=3D"minor group2" parent-id=3D"minor group1" = type=3D"group[3]"/>=09 <directory id=3D"jar files" parent-id=3D"minor group3" = type=3D"artifact" artifact-type=3D"jar" /> <artifact-naming type=3D"jar" = convention=3D"${group[1]}-${group[2]}-${group[3]}-${version}"/> =09 </structure> <type-map> <artifact-type id=3D"jar" dir=3D"jars" extension=3D"jar" /> </type-map> </repository> Which describes the repository structure above. This gives us a high = flexibility to play around, and adapt to different repository = structures. To specify a flat structure, then we can use: <repository> <structure> <artifact-naming type=3D"jar" = convention=3D"${group[1]}-${group[2]}-${group[3]}-${version}"/> </structure> </repository> Then, on the client side, we can have a much simpler configuration file, = since most of the stuff is already up on the repositories: <dependencies> <!-- for a short hand notation, if we already now the id of the = dependency up on the repository --> <dependency repository-id=3D"(id of the dependency up, on the = repository site)" > <version>1.0</version> =09 <!-- For deleting the version number while saving to local f.s. --> <attribute name=3D"omit-version" value=3D"true" /> </dependency> <!-- If we are not familiar with the repository, then we can specify = the whole information --> <dependency> <vendor id=3D"Apache"/> <group id=3D"Jakarta" /> <group id=3D"Commons" parent-id=3D"Jakarta" /> <group id=3D"beanutil" parent-id=3D"Commons" /> <artifact type=3D"jar" /> =09 <version>1.0</version> <!-- For downloading the artifact itself only, w/o artifacts = dependencies --> <attribute name=3D"omit-dependencies" value=3D"true" /> </dependency> </dependencies> To sum up: -Every repository must contain an xml-file that specifies its structure. -Every dependency, (or at least every vendor, or first group) should = have an xml-file identifying itself, and its own dependencies. -Client should need as little configuration as possible, and should only = contain a list of repositories to check in order, the list of = dependencies, and a local repository to place things in. (which will = most probably be flat) With this approach, rather than sub classing different classes for = different types of repositories, artifact types, configurations etc. We = can write a single class for each of them, and place those differences = as data into the configuration files. This will probably make learning = curve steeper for an administrator, but I think it will still be fairly = easy for a developer to use the system. This also makes our job much = more easier, because our code base will be smaller and cleaner.=20 Comments are welcome.... > -----Original Message----- > From: Oliver Wulff [mailto:oli...@zu...] > Sent: Thursday, March 20, 2003 8:41 AM > To: gre...@li... > Subject: [Greebo-devel] Proceed... >=20 >=20 > Hi >=20 > How do we wanna proceed now? > Should I check in the design document in the directory "doc"? >=20 > Oliver >=20 |