Seperating into archives...

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Hello all,

Happy new year, Sylvester, and all that!

I've been very quiet recently - taking a (well deserved) break after 
much activity last year.

Anyway - I just wanted to check with you people, who have more 
experience with this...

A few years ago I provided a few business solutions based on the 
Naked Objects Framework (java, at the time) to a few clients. The 
deliverables effectively consisted of 3 parts:
a) The client solution application (jars, images, etc),
b) the NOF framework,
c) other dependencies required by the NOF. 

For space reasons (I had and still have very limited bandwidth),
I wanted to separate these three (so I could independently update and 
replace 1 of the three "libraries").

Most of the day-to-day changes affected only the client application, 
which was also conveniently, the smallest.

Now, I return to my question: How difficult is it to create 3 (for 
example, jars), that neatly contain only 1 of the three deliverables, as 
mentioned above?

I can see that the application archives can be built extracted as part of 
the standard "mvn install". The same is also true of the individual 
components that make up the (Isis) framework - but it would be 
convenient to be able to aggregate the required framework archives 
into a single archive, and do the same again (i.e. a single archive) for 
the framework dependencies (e.g. all the other components managed 
by maven).

Comments?

Regards,
Kevin

Re: Seperating into archives...

[Mark Struberg <st...@yahoo.de>]

nowaday, most packages are available in the public good (means maven.central). So (under the condition that you cutomers do have a medium ok connection) you could also just provide them with a small maven pom which does package all the 3rd party jars on their side. 
But maybe it's easier then to just burn a CD and send it over to them. 

LieGrue,
strub

--- On Fri, 1/14/11, Kevin Meyer <ke...@kmz.co.za> wrote:

> From: Kevin Meyer <ke...@kmz.co.za>
> Subject: Re: Seperating into archives...
> To: isis-dev@incubator.apache.org
> Date: Friday, January 14, 2011, 6:58 AM
> Hi,
> 
> Repacking all the archives into 3 archives was my way of
> compromising
> between bandwidth use and upgrade convenience.
> 
> For total convenience, I would send the client a single
> archive with
> all dependencies - but this maximises the data footprint.
> 
> To minimize data footprint, I could just send the
> individual packages
> that have changed, but this has a high workflow overhead
> (on my side
> I have to identify what packages are to be added and
> removed, and this
> must be repeated on the client site).
> 
> An intermediate would be to "just" manage the 3 archive
> packages
> as listed. Then the client just needs to replace 1 (or 2 or
> 3) of the
> 3 packages.
> 
> -- Mark:
> Thanks for the advice.
> 
> I must admit, maven certainly goes a long way to helping in
> this
> process. At the time when I had this problem, I think the
> NOF was
> using ant, and I was using Eclipse to build distribtion
> packages.
> I don't remember the full details anymore.
> 
> Thanks,
> Kevin
> 
> 
> On Thu, January 13, 2011 13:57, Mohammad Nour El-Din
> wrote:
> > But if you have the problem with the bandwidth so why
> you wanna make
> > all in one archive ? IMHO I think you should make it
> in separate
> > archives and update only the archives you need to
> update.
> >
> 
> 
> 


      

Re: Seperating into archives...

[Kevin Meyer <ke...@kmz.co.za>]

Hi,

Repacking all the archives into 3 archives was my way of compromising
between bandwidth use and upgrade convenience.

For total convenience, I would send the client a single archive with
all dependencies - but this maximises the data footprint.

To minimize data footprint, I could just send the individual packages
that have changed, but this has a high workflow overhead (on my side
I have to identify what packages are to be added and removed, and this
must be repeated on the client site).

An intermediate would be to "just" manage the 3 archive packages
as listed. Then the client just needs to replace 1 (or 2 or 3) of the
3 packages.

-- Mark:
Thanks for the advice.

I must admit, maven certainly goes a long way to helping in this
process. At the time when I had this problem, I think the NOF was
using ant, and I was using Eclipse to build distribtion packages.
I don't remember the full details anymore.

Thanks,
Kevin


On Thu, January 13, 2011 13:57, Mohammad Nour El-Din wrote:
> But if you have the problem with the bandwidth so why you wanna make
> all in one archive ? IMHO I think you should make it in separate
> archives and update only the archives you need to update.
>

Re: Seperating into archives...

[Mohammad Nour El-Din <no...@gmail.com>]

But if you have the problem with the bandwidth so why you wanna make
all in one archive ? IMHO I think you should make it in separate
archives and update only the archives you need to update.

On Thu, Jan 13, 2011 at 8:25 AM, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> Hello all,
>
> Happy new year, Sylvester, and all that!
>
> I've been very quiet recently - taking a (well deserved) break after
> much activity last year.
>
> Anyway - I just wanted to check with you people, who have more
> experience with this...
>
> A few years ago I provided a few business solutions based on the
> Naked Objects Framework (java, at the time) to a few clients. The
> deliverables effectively consisted of 3 parts:
> a) The client solution application (jars, images, etc),
> b) the NOF framework,
> c) other dependencies required by the NOF.
>
> For space reasons (I had and still have very limited bandwidth),
> I wanted to separate these three (so I could independently update and
> replace 1 of the three "libraries").
>
> Most of the day-to-day changes affected only the client application,
> which was also conveniently, the smallest.
>
> Now, I return to my question: How difficult is it to create 3 (for
> example, jars), that neatly contain only 1 of the three deliverables, as
> mentioned above?
>
> I can see that the application archives can be built extracted as part of
> the standard "mvn install". The same is also true of the individual
> components that make up the (Isis) framework - but it would be
> convenient to be able to aggregate the required framework archives
> into a single archive, and do the same again (i.e. a single archive) for
> the framework dependencies (e.g. all the other components managed
> by maven).
>
> Comments?
>
> Regards,
> Kevin
>
>



-- 
Thanks
- Mohammad Nour
  Author of (WebSphere Application Server Community Edition 2.0 User Guide)
  http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

"Stay hungry, stay foolish."
- Steve Jobs

Re: Seperating into archives...

[Mark Struberg <st...@yahoo.de>]

Hi Kevin!

This is either achievable by using the maven-dependency-plugin unpack-dependencies + maven-assembly-plugin for re-packaging it again or by using the maven-shade-plugin.

The more 'modern' way is to use the maven-shade-plugin. This would also allow you to 'shade' artifacts to different packages (e.g. org.apache.commons.logging would become my.private.org.apache.commons.logging) so it helps you with preventing classloader problems.

LieGrue,
strub

--- On Thu, 1/13/11, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

> From: Kevin Meyer - KMZ <ke...@kmz.co.za>
> Subject: Seperating into archives...
> To: Isis-dev@incubator.apache.org
> Date: Thursday, January 13, 2011, 8:25 AM
> Hello all,
> 
> Happy new year, Sylvester, and all that!
> 
> I've been very quiet recently - taking a (well deserved)
> break after 
> much activity last year.
> 
> Anyway - I just wanted to check with you people, who have
> more 
> experience with this...
> 
> A few years ago I provided a few business solutions based
> on the 
> Naked Objects Framework (java, at the time) to a few
> clients. The 
> deliverables effectively consisted of 3 parts:
> a) The client solution application (jars, images, etc),
> b) the NOF framework,
> c) other dependencies required by the NOF. 
> 
> For space reasons (I had and still have very limited
> bandwidth),
> I wanted to separate these three (so I could independently
> update and 
> replace 1 of the three "libraries").
> 
> Most of the day-to-day changes affected only the client
> application, 
> which was also conveniently, the smallest.
> 
> Now, I return to my question: How difficult is it to create
> 3 (for 
> example, jars), that neatly contain only 1 of the three
> deliverables, as 
> mentioned above?
> 
> I can see that the application archives can be built
> extracted as part of 
> the standard "mvn install". The same is also true of the
> individual 
> components that make up the (Isis) framework - but it would
> be 
> convenient to be able to aggregate the required framework
> archives 
> into a single archive, and do the same again (i.e. a single
> archive) for 
> the framework dependencies (e.g. all the other components
> managed 
> by maven).
> 
> Comments?
> 
> Regards,
> Kevin
> 
>