directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [jira] Created: (DIRSERVER-900) Reduce the number of jars
Date Sun, 15 Apr 2007 15:37:14 GMT
What if we define various usage scenarios and then
figure out the best way to please customers (Users, developers)?

Here's a few.
ApacheDS Development:

Put all the jars in a maven repository
and provide clean documentation indicating
what developers need to use when accessing
ApacheDS APIs.

ApacheDS Install:

The RPM Installer will have 1 installer rpm,
that pulls all other RPM dependencies, that
have a 1:1 correspondence with the maven jars.

I think the other *NIXs will have a similar approach
with an FHS file layout.

Need to figure out windows still.

I would think that it would be possible to just provide
a small RPM like installer, and then have the OSGi container
pull and install the other jars that it the Eclipse
Update service does.

Are there any other scenarios we need to consider?

- Ole

Alex Karasulu wrote:
> Yeah I agree that we have two apposing things to engineer around.  OSGi 
> pushes to more jars and most users will want one for the whole project.  
> I think we can achieve both goals with a little maven magic.
> We just need this before we start moving in the path of breaking up jars 
> into more jars.  It will be nice to just have a single assembly for 
> ApacheDS distributed with maven.  I think the server-main was supposed 
> to do this but we're not uploading the assembly to the m2 repo but the 
> compiled empty artifact.  We definitely need to fix this project so 
> users can just us it with one jar.  Perhaps we might change it's name to 
> best indicate this fact?
> WDYT about calling it something like apacheds-all or apacheds-complete?
> Alex
> On 4/13/07, *Emmanuel Lecharny* < 
> <>> wrote:
>     Alex Karasulu a écrit :
>      > We're actually going to be going in the opposite direction with OSGi
>      > when we
>      > break things down into fine grained services.  We may reach 100 jars
>      > if we
>      > do it right.
>     I don't think that this direction is incompatible with another target,
>     which is a packaged version (and this is the target I was talking about
>     in this JIRA)
>      >
>      > We can use an assembly to create one jar if that makes people
>     happy.  But
>      > this JIRA is a waste considering our direction.
>     Make people happy seems important to me :)
>     Just consider that micro-decision (like create an hundred of jars for
>     internal reasons) should not be opposed to macro-decision (packaging the
>     server in a couple of jars for people hapiness), but it's obviously
>     another task for us (vreating the pckages, managing them, ect...).
>     I personnaly think that delivering a server composed of an hundred of
>     jars for technical reasons like OSGI, and to impose this choice to user
>     to be just a wrong move. Not that OSGI is the bad direction, but users
>     should not be aware of that if they don't want to be.
>     Of course, I just express my very own opinion here, not the project
>     opinion. We will have to discuss this point, for sure !
>     Emmanuel

View raw message