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
Aperture-devel@lists.sourceforge.net
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
Aperture-devel@lists.sourceforge.net
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.sauermann@dfki.de

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
____________________________________________________