From: Antoni M. <ant...@gm...> - 2009-02-09 23:34:16
|
I've taken a look at the maven-enabled folders Herko has been preparing in the last weeks. All in all it's great. I'm really excited 1. I would suggest to add .settings, .project, .classpath and target to svn:ignore in ALL folders. - this way we loose the Aperture formatter, and the license templates, but they can be exported and imported at the workspace, level, no need to put them in the project settings 2. I assume we're going for maximal division e.g. data sources, accessors and crawlers - all in separate bundles, even if the FilesystemDataSource, FileAccessor and FilesystemCrawler are all 'somehow' similar and it might be worth a thought to bundle them together. 3. DefaultRegistries should be removed from the 'core' bundles, as they will not work, the default registries need to be included in some kind of coarsegrained "impl" bundle. 4. Why is rdf-util split from util? I can work on extractors tomorrow. Herko? -- Antoni Myłka ant...@gm... |
From: Leo S. <leo...@df...> - 2009-02-10 08:40:05
|
It was Antoni Mylka who said at the right time 10.02.2009 00:34 the following words: > I've taken a look at the maven-enabled folders Herko has been > preparing in the last weeks. > > All in all it's great. I'm really excited > > 1. I would suggest to add .settings, .project, .classpath and target > to svn:ignore in ALL folders. > - this way we loose the Aperture formatter, and the license > templates, but they can be exported and imported at the workspace, > level, no need to put them in the project settings > maybe there is an option in maven to let it put them into the metadata on eclipse:eclipse? any workspace setting failed us when used in nepomuk: formatting, license boiler, mikhail kotelnikovs template features, nobody used them. depending on the discipline of us is a natural source of fail. > 2. I assume we're going for maximal division e.g. data sources, > accessors and crawlers - all in separate bundles, even if the > FilesystemDataSource, FileAccessor and FilesystemCrawler are all > 'somehow' similar and it might be worth a thought to bundle them > together. > the outlook crawler is all tightly knit together, has to be one package. I would bundle in larger chunks, we must split when there are dependencies (thats where maven helps us) but sesame2's "let 1000 projects grow" approach was a bit complex. > 3. DefaultRegistries should be removed from the 'core' bundles, as > they will not work, the default registries need to be included in some > kind of coarsegrained "impl" bundle. > ok > 4. Why is rdf-util split from util? > good question. why is util split from core anyway? best Leo > I can work on extractors tomorrow. > > Herko? > > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-10 09:31:53
|
>> 1. I would suggest to add .settings, .project, .classpath and target >> to svn:ignore in ALL folders. >> - this way we loose the Aperture formatter, and the license >> templates, but they can be exported and imported at the workspace, >> level, no need to put them in the project settings >> > maybe there is an option in maven to let it put them into the metadata > on eclipse:eclipse? > > any workspace setting failed us when used in nepomuk: formatting, > license boiler, mikhail kotelnikovs template features, nobody used them. > depending on the discipline of us is a natural source of fail. Ok, in that case I'll remove the settings. I think having some kind of coding standard helps new developers get into the code as well as make the code more readable in general, but if no one is going to stick to it let's just forget it. >> 2. I assume we're going for maximal division e.g. data sources, >> accessors and crawlers - all in separate bundles, even if the >> FilesystemDataSource, FileAccessor and FilesystemCrawler are all >> 'somehow' similar and it might be worth a thought to bundle them >> together. >> > the outlook crawler is all tightly knit together, has to be one package. Yes, the Outlook crawler is going to be one bundle. > I would bundle in larger chunks, we must split when there are > dependencies (thats where maven helps us) but sesame2's "let 1000 > projects grow" approach was a bit complex. Where possible, I want to use separate bundles. Both to enable the full use of OSGi features and to enforce a clean separation of concerns for components. There will be aggregated bundles for those who aren't interested in that. >> 3. DefaultRegistries should be removed from the 'core' bundles, as >> they will not work, the default registries need to be included in some >> kind of coarsegrained "impl" bundle. >> > ok Yes, obviously this is the case. I'm not finished yet :) I just copied the existing packages. The Default* stuff is going in a separate tree next to core. >> 4. Why is rdf-util split from util? >> > good question. why is util split from core anyway? I'm looking at the old Mavenization branch and I think I decided to split because of dependencies: the classes in RDF util caused a dependency on the entire Sesame one-jar and its dependencies. In the new Mavenization effort, we can have dependencies only on the Aduna commons modules that are actually used, so it makes less sense now. I'll integrate the two modules. Antoni, it would be great if you could help me with the extractors. Because of dependencies, I think it makes sense to group them according to implementation. I'd suggest the following in .../extractor /core = core API and registry impl /corel /office = all Corel Office formats (wordperfect, presentations) /util = shared utilities /ms-ole = parent package for all impls that use POI /office = all MS Office formats (office, word, excel, powerpoint) /publisher = MS Publisher /quattro = MS Quattro /works = MS Works /visio = MS Visio /util = shared utilities/POI /opendocument = OpenDocument/Open Office documents /openxml = OpenXML/Office 2007 documents / < etc > = other packages as single modules /util = utilities shared by multiple modules Cheers, Herko |
From: Antoni M. <ant...@gm...> - 2009-02-10 22:59:56
|
2009/2/10 Herko ter Horst <her...@ad...>: > >>> 4. Why is rdf-util split from util? >>> >> >> good question. why is util split from core anyway? > > I'm looking at the old Mavenization branch and I think I decided to split > because of dependencies: the classes in RDF util caused a dependency on the > entire Sesame one-jar and its dependencies. In the new Mavenization effort, > we can have dependencies only on the Aduna commons modules that are actually > used, so it makes less sense now. I'll integrate the two modules. You've put those four util classes in an rdf.util package. This is a backwards-incompatible change. I actually meant moving those four classes back to the aperture.util package. They don't add any additional dependencies. IMHO this is very important. If we move classes, then we will need to release Aperture 2.0. In this particular case I see no benefit, InferenceUtil, ModelUtil, OntologyUtil and XmlSafetyUtils could just as well stay in the aperture.util package (or aperture.util.ontology - in case of OntologyUtil). I'm not saying that moving classes has absolutely no benefits though. For instance, accessor.MessageDataObject and accessor.base.MessageDataObjectBase shouldn't belong in the aperture-accessor-core module because they introduce a dependency on javamail. I'll go on with the extractor mavenization leaving it as Herko did it, but I guess this matter deserves some discussion. And shouldn't concrete datasource implementations go into a separate 'impl' module tree? I see that it's more of a aestetic distinction than a technical one, just wanted to clarify our intentions. -- Antoni Myłka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-02-11 00:20:38
|
And one more thing. I noticed that two methods have been removed from the UriUtil class in the util package. It may have been done to remove any dependencies from the util package. It's an aperture-util package. Almost every Aperture class depends on rdf2go in some way. Do you see the need to have an rdf2go-free util module? Is there any use for it outside Aperture? If you think there is, then maybe your original idea with a separate rdf-util module wasn't too bad, but then the package name should stay the same, and the UriUtil class should go into rdf-util. For the time being, I reintroduced those two methods to UriUtil and added a dependency on rdf2go to the aperture-util module. Please comment. 2009/2/10 Antoni Mylka <ant...@gm...>: > 2009/2/10 Herko ter Horst <her...@ad...>: >> >>>> 4. Why is rdf-util split from util? >>>> >>> >>> good question. why is util split from core anyway? >> >> I'm looking at the old Mavenization branch and I think I decided to split >> because of dependencies: the classes in RDF util caused a dependency on the >> entire Sesame one-jar and its dependencies. In the new Mavenization effort, >> we can have dependencies only on the Aduna commons modules that are actually >> used, so it makes less sense now. I'll integrate the two modules. > > You've put those four util classes in an rdf.util package. This is a > backwards-incompatible change. I actually meant moving those four > classes back to the aperture.util package. They don't add any > additional dependencies. > > IMHO this is very important. If we move classes, then we will need to > release Aperture 2.0. > > In this particular case I see no benefit, InferenceUtil, ModelUtil, > OntologyUtil and XmlSafetyUtils could just as well stay in the > aperture.util package (or aperture.util.ontology - in case of > OntologyUtil). > > I'm not saying that moving classes has absolutely no benefits though. > For instance, accessor.MessageDataObject and > accessor.base.MessageDataObjectBase shouldn't belong in the > aperture-accessor-core module because they introduce a dependency on > javamail. > > I'll go on with the extractor mavenization leaving it as Herko did it, > but I guess this matter deserves some discussion. > > And shouldn't concrete datasource implementations go into a separate > 'impl' module tree? I see that it's more of a aestetic distinction > than a technical one, just wanted to clarify our intentions. -- Antoni Myłka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-02-11 00:47:48
|
A third and final post, time to go to bed. I wanted to mavenize extractors, but thought that it makes little sense to do so without ApertureTestBase class. The problem with ApertureTestBase was that it required the MagicMimeTypeIdentifier and some other core modules - accessors, and crawlers. I did accessors and crawlers, and removed the MagicMimeTypeIdentifer. CrawlerHandlerBase.processBinary method also refers the MagicMimeTypeIdentifier. Either we remove processBinary, or move the CrawlerHandlerBase to some other module. (I removed it for the time being). I removed the TestIncrementalCrawlerHandler from the testbase module, for the same reason - it requires the MagicMimeTypeIdentifier. I guess it might be possible to make the mime type identification modules independent of anything else, which will place them at the top of the build order. Then we can make everything depend on it (via <scope>test</scope>), this will solve the problems in the testbase module, but the CrawlerHandlerBase will still need to go somewhere else. 2009/2/11 Antoni Mylka <ant...@gm...>: > And one more thing. I noticed that two methods have been removed from > the UriUtil class in the util package. It may have been done to remove > any dependencies from the util package. It's an aperture-util package. > Almost every Aperture class depends on rdf2go in some way. > > Do you see the need to have an rdf2go-free util module? Is there any > use for it outside Aperture? If you think there is, then maybe your > original idea with a separate rdf-util module wasn't too bad, but then > the package name should stay the same, and the UriUtil class should go > into rdf-util. > > For the time being, I reintroduced those two methods to UriUtil and > added a dependency on rdf2go to the aperture-util module. > > Please comment. > > 2009/2/10 Antoni Mylka <ant...@gm...>: >> 2009/2/10 Herko ter Horst <her...@ad...>: >>> >>>>> 4. Why is rdf-util split from util? >>>>> >>>> >>>> good question. why is util split from core anyway? >>> >>> I'm looking at the old Mavenization branch and I think I decided to split >>> because of dependencies: the classes in RDF util caused a dependency on the >>> entire Sesame one-jar and its dependencies. In the new Mavenization effort, >>> we can have dependencies only on the Aduna commons modules that are actually >>> used, so it makes less sense now. I'll integrate the two modules. >> >> You've put those four util classes in an rdf.util package. This is a >> backwards-incompatible change. I actually meant moving those four >> classes back to the aperture.util package. They don't add any >> additional dependencies. >> >> IMHO this is very important. If we move classes, then we will need to >> release Aperture 2.0. >> >> In this particular case I see no benefit, InferenceUtil, ModelUtil, >> OntologyUtil and XmlSafetyUtils could just as well stay in the >> aperture.util package (or aperture.util.ontology - in case of >> OntologyUtil). >> >> I'm not saying that moving classes has absolutely no benefits though. >> For instance, accessor.MessageDataObject and >> accessor.base.MessageDataObjectBase shouldn't belong in the >> aperture-accessor-core module because they introduce a dependency on >> javamail. >> >> I'll go on with the extractor mavenization leaving it as Herko did it, >> but I guess this matter deserves some discussion. >> >> And shouldn't concrete datasource implementations go into a separate >> 'impl' module tree? I see that it's more of a aestetic distinction >> than a technical one, just wanted to clarify our intentions. > > > -- > Antoni Myłka > ant...@gm... > -- Antoni Myłka ant...@gm... |
From: Herko t. H. <her...@ad...> - 2009-02-17 09:14:17
|
Antoni Mylka wrote: > And one more thing. I noticed that two methods have been removed from > the UriUtil class in the util package. It may have been done to remove > any dependencies from the util package. It's an aperture-util package. > Almost every Aperture class depends on rdf2go in some way. > > Do you see the need to have an rdf2go-free util module? Is there any > use for it outside Aperture? If you think there is, then maybe your > original idea with a separate rdf-util module wasn't too bad, but then > the package name should stay the same, and the UriUtil class should go > into rdf-util. > > For the time being, I reintroduced those two methods to UriUtil and > added a dependency on rdf2go to the aperture-util module. > > Please comment. I've indeed removed (actually moved: the methods are in ModelUtil now) those methods to get a dependency-free util package (for reasons outlined in my earlier mail). Most of UriUtil deals with generic URI issues. The methods that have been moved dealt with URIs in the context of an RDF2Go model, hence the move to ModelUtil. Herko |
From: Leo S. <leo...@df...> - 2009-02-17 09:26:18
|
well, the problem is that we are currently mixing two issues, which is dangerous: * mavenization * releasing aperture 2.0 Bear in mind that all we do currently should also help the SMILA people to include aperture, especially help them in their IP due diligence. If we are now beginning talking about aperture 2.0, it will take many months and it will break compability with NEPOMUK and other products that depend on aperture (dynaq, ...). One thing after another! fix mavenization, but do not put architecture changes in. separate concerns. for this reason I am strongly against moving classes around. Especially if the reason is a possible future replacement for a utility class with apache utility classes (or aduna utility classes). we are talking about ~1000 LOC, the effort to replace them with apache is clearly not worth it. utility classes are just that: making life easier. no need to optimize here. best Leo It was Herko ter Horst who said at the right time 17.02.2009 10:14 the following words: > Antoni Mylka wrote: > >> And one more thing. I noticed that two methods have been removed from >> the UriUtil class in the util package. It may have been done to remove >> any dependencies from the util package. It's an aperture-util package. >> Almost every Aperture class depends on rdf2go in some way. >> >> Do you see the need to have an rdf2go-free util module? Is there any >> use for it outside Aperture? If you think there is, then maybe your >> original idea with a separate rdf-util module wasn't too bad, but then >> the package name should stay the same, and the UriUtil class should go >> into rdf-util. >> >> For the time being, I reintroduced those two methods to UriUtil and >> added a dependency on rdf2go to the aperture-util module. >> >> Please comment. >> > > I've indeed removed (actually moved: the methods are in ModelUtil now) > those methods to get a dependency-free util package (for reasons > outlined in my earlier mail). > > Most of UriUtil deals with generic URI issues. The methods that have > been moved dealt with URIs in the context of an RDF2Go model, hence the > move to ModelUtil. > > Herko > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-17 11:24:05
|
Leo, > whats the problem if we move all the util into the "core" project? I'm not sure what you mean by "core" project. We are talking about modules in the "core" project. There is a util module and there is an rdf module that also contains RDF-specific utilities, a couple of which were moved from the util module for reasons I outlined in my earlier mail. > afaik we had to do the same with rdf2go I don't know what you mean by this. Cheers, Herko >>> well, the problem is that we are currently mixing two issues, which >>> is dangerous: >>> * mavenization >>> * releasing aperture 2.0 >>> >> >> No, we're not (at least I'm not). We're discussing if any changes we >> need to make to Mavenize Aperture warrant a different version number. >> I'm not saying this should be Aperture 2.0. I'm currently calling it >> 1.3.0. It could be 1.2.1, 1.5, 2.0, I don't know. >> >> I'm definitely NOT proposing that we change the architecture of >> Aperture at this time. I'm just moving a couple minor (IMO) things >> around to avoid unnecessary dependencies between modules. However, we >> are significantly changing the way Aperture is organized and built. >> This alone *could* be a change big enough to warrant the 2.0 label, >> even if we don't change anything else. >> >> >>> Bear in mind that all we do currently should also help >>> the SMILA people to include aperture, especially help them >>> in their IP due diligence. >>> >>> If we are now beginning talking about aperture 2.0, it will take >>> many months and it will break compability with NEPOMUK and other >>> products >>> that depend on aperture (dynaq, ...). >>> >> >> I think a couple of minor incompatibilities with the existing API are >> no big deal if we document them properly. >> >> >>> One thing after another! >>> fix mavenization, but do not put architecture changes in. >>> separate concerns. >>> >> >> Moving a method or a class is not an architectural change. >> Mavenization requires that we think about dependencies between >> modules. If breaking a dependency between two modules can be done by >> moving one or two methods to a different class, or moving one or two >> classes to a different module, that's just part of the process, in my >> opinion. >> >> >>> for this reason I am strongly against moving classes around. >>> >> >> I don't see the harm in moving a few things. It's not like I'm >> completely changing the way Aperture works. >> >> >>> Especially if the reason is a possible future replacement for a >>> utility class with apache utility >>> classes (or aduna utility classes). >>> we are talking about ~1000 LOC, the effort to replace them with apache >>> is clearly not worth it. >>> utility classes are just that: making life easier. >>> no need to optimize here. >>> >> >> That's not the reason. The reason is to keep a clean dependency tree >> and avoid dependency cycles. aperture-util contains utilities for "us" >> as Aperture programmers (the utilities everyone already has in some >> form or shape, like StringUtil, IOUtil, etc.). aperture-rdf-util >> contains utilities for Aperture itself AND for Aperture *users* that >> need to deal with the RDF2Go models in Aperture. >> >> aperture-util and aperture-rdf-util are part of this discussion just >> because I Mavenized them first. I'm not trying to optimize anything >> specifically (although if I could replace 1000 LOC with a >> well-established existing library, I'd say it's worth it, but never >> mind that, that's not the goal of this discussion). As Antoni has >> already seen, there are dependencies/difficulties like this all over >> the code. We just need to fix those in the best possible way. >> >> Herko >> >> ------------------------------------------------------------------------------ >> >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Aperture-devel mailing list >> Ape...@li... >> https://lists.sourceforge.net/lists/listinfo/aperture-devel >> > > |
From: Leo S. <leo...@df...> - 2009-02-17 15:57:57
|
ok, I thought we had one module for the core APIs, but you separated them all into multiple modules already best Leo It was Herko ter Horst who said at the right time 17.02.2009 12:24 the following words: > Leo, > > >> whats the problem if we move all the util into the "core" project? >> > > I'm not sure what you mean by "core" project. We are talking about > modules in the "core" project. There is a util module and there is an > rdf module that also contains RDF-specific utilities, a couple of which > were moved from the util module for reasons I outlined in my earlier mail. > > >> afaik we had to do the same with rdf2go >> > > I don't know what you mean by this. > > Cheers, > > Herko > > >>>> well, the problem is that we are currently mixing two issues, which >>>> is dangerous: >>>> * mavenization >>>> * releasing aperture 2.0 >>>> >>>> >>> No, we're not (at least I'm not). We're discussing if any changes we >>> need to make to Mavenize Aperture warrant a different version number. >>> I'm not saying this should be Aperture 2.0. I'm currently calling it >>> 1.3.0. It could be 1.2.1, 1.5, 2.0, I don't know. >>> >>> I'm definitely NOT proposing that we change the architecture of >>> Aperture at this time. I'm just moving a couple minor (IMO) things >>> around to avoid unnecessary dependencies between modules. However, we >>> are significantly changing the way Aperture is organized and built. >>> This alone *could* be a change big enough to warrant the 2.0 label, >>> even if we don't change anything else. >>> >>> >>> >>>> Bear in mind that all we do currently should also help >>>> the SMILA people to include aperture, especially help them >>>> in their IP due diligence. >>>> >>>> If we are now beginning talking about aperture 2.0, it will take >>>> many months and it will break compability with NEPOMUK and other >>>> products >>>> that depend on aperture (dynaq, ...). >>>> >>>> >>> I think a couple of minor incompatibilities with the existing API are >>> no big deal if we document them properly. >>> >>> >>> >>>> One thing after another! >>>> fix mavenization, but do not put architecture changes in. >>>> separate concerns. >>>> >>>> >>> Moving a method or a class is not an architectural change. >>> Mavenization requires that we think about dependencies between >>> modules. If breaking a dependency between two modules can be done by >>> moving one or two methods to a different class, or moving one or two >>> classes to a different module, that's just part of the process, in my >>> opinion. >>> >>> >>> >>>> for this reason I am strongly against moving classes around. >>>> >>>> >>> I don't see the harm in moving a few things. It's not like I'm >>> completely changing the way Aperture works. >>> >>> >>> >>>> Especially if the reason is a possible future replacement for a >>>> utility class with apache utility >>>> classes (or aduna utility classes). >>>> we are talking about ~1000 LOC, the effort to replace them with apache >>>> is clearly not worth it. >>>> utility classes are just that: making life easier. >>>> no need to optimize here. >>>> >>>> >>> That's not the reason. The reason is to keep a clean dependency tree >>> and avoid dependency cycles. aperture-util contains utilities for "us" >>> as Aperture programmers (the utilities everyone already has in some >>> form or shape, like StringUtil, IOUtil, etc.). aperture-rdf-util >>> contains utilities for Aperture itself AND for Aperture *users* that >>> need to deal with the RDF2Go models in Aperture. >>> >>> aperture-util and aperture-rdf-util are part of this discussion just >>> because I Mavenized them first. I'm not trying to optimize anything >>> specifically (although if I could replace 1000 LOC with a >>> well-established existing library, I'd say it's worth it, but never >>> mind that, that's not the goal of this discussion). As Antoni has >>> already seen, there are dependencies/difficulties like this all over >>> the code. We just need to fix those in the best possible way. >>> >>> Herko >>> >>> ------------------------------------------------------------------------------ >>> >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>> Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source >>> code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Aperture-devel mailing list >>> Ape...@li... >>> https://lists.sourceforge.net/lists/listinfo/aperture-devel >>> >>> >> > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-17 10:10:18
|
Hi Leo, > well, the problem is that we are currently mixing two issues, which is > dangerous: > * mavenization > * releasing aperture 2.0 No, we're not (at least I'm not). We're discussing if any changes we need to make to Mavenize Aperture warrant a different version number. I'm not saying this should be Aperture 2.0. I'm currently calling it 1.3.0. It could be 1.2.1, 1.5, 2.0, I don't know. I'm definitely NOT proposing that we change the architecture of Aperture at this time. I'm just moving a couple minor (IMO) things around to avoid unnecessary dependencies between modules. However, we are significantly changing the way Aperture is organized and built. This alone *could* be a change big enough to warrant the 2.0 label, even if we don't change anything else. > Bear in mind that all we do currently should also help > the SMILA people to include aperture, especially help them > in their IP due diligence. > > If we are now beginning talking about aperture 2.0, it will take > many months and it will break compability with NEPOMUK and other products > that depend on aperture (dynaq, ...). I think a couple of minor incompatibilities with the existing API are no big deal if we document them properly. > One thing after another! > fix mavenization, but do not put architecture changes in. > separate concerns. Moving a method or a class is not an architectural change. Mavenization requires that we think about dependencies between modules. If breaking a dependency between two modules can be done by moving one or two methods to a different class, or moving one or two classes to a different module, that's just part of the process, in my opinion. > for this reason I am strongly against moving classes around. I don't see the harm in moving a few things. It's not like I'm completely changing the way Aperture works. > Especially if the reason is a possible future replacement for a utility > class with apache utility > classes (or aduna utility classes). > we are talking about ~1000 LOC, the effort to replace them with apache > is clearly not worth it. > utility classes are just that: making life easier. > no need to optimize here. That's not the reason. The reason is to keep a clean dependency tree and avoid dependency cycles. aperture-util contains utilities for "us" as Aperture programmers (the utilities everyone already has in some form or shape, like StringUtil, IOUtil, etc.). aperture-rdf-util contains utilities for Aperture itself AND for Aperture *users* that need to deal with the RDF2Go models in Aperture. aperture-util and aperture-rdf-util are part of this discussion just because I Mavenized them first. I'm not trying to optimize anything specifically (although if I could replace 1000 LOC with a well-established existing library, I'd say it's worth it, but never mind that, that's not the goal of this discussion). As Antoni has already seen, there are dependencies/difficulties like this all over the code. We just need to fix those in the best possible way. Herko |
From: Leo S. <leo...@df...> - 2009-02-17 11:17:55
|
whats the problem if we move all the util into the "core" project? afaik we had to do the same with rdf2go best Leo It was Herko ter Horst who said at the right time 17.02.2009 11:10 the following words: > Hi Leo, > > >> well, the problem is that we are currently mixing two issues, which is >> dangerous: >> * mavenization >> * releasing aperture 2.0 >> > > No, we're not (at least I'm not). We're discussing if any changes we > need to make to Mavenize Aperture warrant a different version number. > I'm not saying this should be Aperture 2.0. I'm currently calling it > 1.3.0. It could be 1.2.1, 1.5, 2.0, I don't know. > > I'm definitely NOT proposing that we change the architecture of Aperture > at this time. I'm just moving a couple minor (IMO) things around to > avoid unnecessary dependencies between modules. However, we are > significantly changing the way Aperture is organized and built. This > alone *could* be a change big enough to warrant the 2.0 label, even if > we don't change anything else. > > >> Bear in mind that all we do currently should also help >> the SMILA people to include aperture, especially help them >> in their IP due diligence. >> >> If we are now beginning talking about aperture 2.0, it will take >> many months and it will break compability with NEPOMUK and other products >> that depend on aperture (dynaq, ...). >> > > I think a couple of minor incompatibilities with the existing API are no > big deal if we document them properly. > > >> One thing after another! >> fix mavenization, but do not put architecture changes in. >> separate concerns. >> > > Moving a method or a class is not an architectural change. Mavenization > requires that we think about dependencies between modules. If breaking a > dependency between two modules can be done by moving one or two methods > to a different class, or moving one or two classes to a different > module, that's just part of the process, in my opinion. > > >> for this reason I am strongly against moving classes around. >> > > I don't see the harm in moving a few things. It's not like I'm > completely changing the way Aperture works. > > >> Especially if the reason is a possible future replacement for a utility >> class with apache utility >> classes (or aduna utility classes). >> we are talking about ~1000 LOC, the effort to replace them with apache >> is clearly not worth it. >> utility classes are just that: making life easier. >> no need to optimize here. >> > > That's not the reason. The reason is to keep a clean dependency tree and > avoid dependency cycles. aperture-util contains utilities for "us" as > Aperture programmers (the utilities everyone already has in some form or > shape, like StringUtil, IOUtil, etc.). aperture-rdf-util contains > utilities for Aperture itself AND for Aperture *users* that need to deal > with the RDF2Go models in Aperture. > > aperture-util and aperture-rdf-util are part of this discussion just > because I Mavenized them first. I'm not trying to optimize anything > specifically (although if I could replace 1000 LOC with a > well-established existing library, I'd say it's worth it, but never mind > that, that's not the goal of this discussion). As Antoni has already > seen, there are dependencies/difficulties like this all over the code. > We just need to fix those in the best possible way. > > Herko > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-17 09:10:59
|
Hi all, Sorry I didn't respond sooner, I've been down with the flu most of last week... >>>> 4. Why is rdf-util split from util? >>>> >>> good question. why is util split from core anyway? >> I'm looking at the old Mavenization branch and I think I decided to split >> because of dependencies: the classes in RDF util caused a dependency on the >> entire Sesame one-jar and its dependencies. In the new Mavenization effort, >> we can have dependencies only on the Aduna commons modules that are actually >> used, so it makes less sense now. I'll integrate the two modules. > > You've put those four util classes in an rdf.util package. This is a > backwards-incompatible change. I actually meant moving those four > classes back to the aperture.util package. They don't add any > additional dependencies. They do, they add RDF2Go, Aduna XML, SLF4j. But more importantly, aperture-util contains generic utilities that could eventually be replaced by similar utilities from other sources (Apache and Aduna commons packages could probably replace 80% of those utils). aperture-rdf-util contains specific utilities for dealing with RDF2Go models, and Aperture-specific ontologies. They are much more important and unique to Aperture. > IMHO this is very important. If we move classes, then we will need to > release Aperture 2.0. I wouldn't say it's "very" important. I'm not opposed to bumping the version number a bit more than just the next dot-release, the changes are significant enough to warrant it. I went with 1.3.0 for now, but I could see this go to 1.5 or indeed 2.0. > In this particular case I see no benefit, InferenceUtil, ModelUtil, > OntologyUtil and XmlSafetyUtils could just as well stay in the > aperture.util package (or aperture.util.ontology - in case of > OntologyUtil). > > I'm not saying that moving classes has absolutely no benefits though. > For instance, accessor.MessageDataObject and > accessor.base.MessageDataObjectBase shouldn't belong in the > aperture-accessor-core module because they introduce a dependency on > javamail. > > I'll go on with the extractor mavenization leaving it as Herko did it, > but I guess this matter deserves some discussion. > > And shouldn't concrete datasource implementations go into a separate > 'impl' module tree? I see that it's more of a aestetic distinction > than a technical one, just wanted to clarify our intentions. I thought about this. Before the license change, this would have been quite important, as it would allow us to make a clear distinction between the AFL and OSL licensed parts of the code. As everything is under BSD now, it doesn't matter that much anymore. So it seemed better to me to have as few separate source trees as possible. Cheers, Herko |