oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: Roadmap
Date Tue, 15 Jun 2010 16:22:17 GMT
2010/6/15 Pid <pidster@apache.org>

> We will need to publish an "all-in-one", or at least an API + impl pair.
>

We WILL ship an all-in-one jar, but still we can keep source codes separate
for different places.


>
>
> > So, from an "Amber user" point of view, visibility on how modules are
> > organized is quite opaque, as long as you don't need to depend only on
> > one specific module, like for example only on the API interfaces, or
> > only the key crypt part cause, in which case it is a problem to extract
> > out only the part you need. That's why I love projects with small modules
> :)
>
> This sounds OK in principal, but would it mean also publishing a lot of
> small jars?
>

I think "a lot" will resolve to something like 3/4 core modules, not one
hundred :) If then we plan to have tools, those will probably be separate.
Anyway only on the maven repository, for maven consumption, not for the
final non-maven user.

A user using maven will point to "amber-consumer" or whatever, and will have
maven resolve the jars required, and notice nothing.

The user not using maven will download and use the all-in-one bundle, that
maven can build automatically, and live with it.

As long as he does not want to use in its project only, for example, the
signatures part, in which case he can still dig in the maven repo.


>
> Is it really a big gain to separate Client/Server functions?  The client
> part isn't so complicated and will involve minimal additional classes
> I'd have thought.
>



> Do you have thoughts on how we'd define an API that would support being
> separated for Server & Client usages?
>

You are right, we can discover that there is no use case that involves using
X without Y, or that X+Y is small enough to be a single code base no matter
what the use case.

I'd just like to avoid the monolithic approach, permiting "partial usage"
from other projects without having them to import a single gigantic full
featured jar file. A lot of people is scared of adding an "x megs"
dependency, even if, when they just load two classes, it does not matter how
big the jar actually is, but still they seem to care a lot.


Simone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message