Dependencies not available in the future

[David Ojeda <do...@integra.la>]

Hello all...

Every day I am one step closer to decide to migrate to maven2, however I have 
a new question.
Suppose that I have a project X that depends on Y and Z. When I finish this 
project it is common to give the source code to the client. Usually, I deliver 
the source code, ant scripts and the necessary jars in order to build the 
application. If I switch to maven, I would probably deliver just the source 
code in the proper directory structure and pom. In this case what worries me 
is that in the future, dependency Y or Z could be unavailable for various 
reasons: repository is no longer available, a specific version of dependencies 
are difficult to obtain, etc.

So my question is: what can I do if I want to deliver give the source code and 
the dependencies jars?

Here are some of my ideas:
- Maintain a private repository with dependencies and use the deploy:deploy-
file goal to add dependencies to it.
Problem: in the love/hate relationship of client/developer companies, I think 
that the clients might argue that they do not want to depend on the developer 
company repository. Could be a repository in the client company.
- Deliver all jars and scripts to install them in the local repository. Seems 
very 'hackish' and not so 'mavenish'.

What is your experience with this situation?
Thanks for your attention

-- 
David Ojeda


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependencies not available in the future

[David Ojeda <do...@integra.la>]

Hello Simone and Graham,

Both options satisfy my needs. I prefer to deliver a ~/.m2/repository but I 
think it will depend on the client...

Thank you

On Monday 03 November 2008 12:33:28 Simone Gianni wrote:
> Hi David,
> nobody said that a repository has to be remote, you can create a local
> file repository, and install there (copying it from the main repo, or
> using mvn deploy) all the dependencies you want, then configure this
> repository in your pom, and ship it together with you project.
>
> For example, you could organize the release as :
> myproject
> ... pom.xml
> ... submodule
> ....... pom.xml
> ....... src/main etc..
> ... othermodule
> ....... etc etc
> dependencies
> ... org
> ...... apache
> .......... same as if it was a repository, folders, containing jars and
> so on
>
> then, if I receive this package and want to build it, a simple mvn
> install (or mvn whatever you say) in the myproject directory will
> suffice, cause there will be a (rather ugly) repository entry pointing
> to ../dependencies, otherwise I could edit the main pom.xml and write a
> complete path there, or you could use a variable (but have never tried
> this), or place the repository as a sub-folder of myproject itself.
>
> Hope this helps,
> Simone
>
> David Ojeda wrote:
> > Hello all...
> >
> > Every day I am one step closer to decide to migrate to maven2, however I
> > have a new question.
> > Suppose that I have a project X that depends on Y and Z. When I finish
> > this project it is common to give the source code to the client. Usually,
> > I deliver the source code, ant scripts and the necessary jars in order to
> > build the application. If I switch to maven, I would probably deliver
> > just the source code in the proper directory structure and pom. In this
> > case what worries me is that in the future, dependency Y or Z could be
> > unavailable for various reasons: repository is no longer available, a
> > specific version of dependencies are difficult to obtain, etc.
> >
> > So my question is: what can I do if I want to deliver give the source
> > code and the dependencies jars?
> >
> > Here are some of my ideas:
> > - Maintain a private repository with dependencies and use the
> > deploy:deploy- file goal to add dependencies to it.
> > Problem: in the love/hate relationship of client/developer companies, I
> > think that the clients might argue that they do not want to depend on the
> > developer company repository. Could be a repository in the client
> > company. - Deliver all jars and scripts to install them in the local
> > repository. Seems very 'hackish' and not so 'mavenish'.
> >
> > What is your experience with this situation?
> > Thanks for your attention

-- 
Ing. David Ojeda
Integra Consultores
Caracas, Venezuela

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependencies not available in the future

[Simone Gianni <si...@apache.org>]

Hi David,
nobody said that a repository has to be remote, you can create a local
file repository, and install there (copying it from the main repo, or
using mvn deploy) all the dependencies you want, then configure this
repository in your pom, and ship it together with you project.

For example, you could organize the release as :
myproject
... pom.xml
... submodule
....... pom.xml
....... src/main etc..
... othermodule
....... etc etc
dependencies
... org
...... apache
.......... same as if it was a repository, folders, containing jars and
so on

then, if I receive this package and want to build it, a simple mvn
install (or mvn whatever you say) in the myproject directory will
suffice, cause there will be a (rather ugly) repository entry pointing
to ../dependencies, otherwise I could edit the main pom.xml and write a
complete path there, or you could use a variable (but have never tried
this), or place the repository as a sub-folder of myproject itself.

Hope this helps,
Simone

David Ojeda wrote:
> Hello all...
>
> Every day I am one step closer to decide to migrate to maven2, however I have 
> a new question.
> Suppose that I have a project X that depends on Y and Z. When I finish this 
> project it is common to give the source code to the client. Usually, I deliver 
> the source code, ant scripts and the necessary jars in order to build the 
> application. If I switch to maven, I would probably deliver just the source 
> code in the proper directory structure and pom. In this case what worries me 
> is that in the future, dependency Y or Z could be unavailable for various 
> reasons: repository is no longer available, a specific version of dependencies 
> are difficult to obtain, etc.
>
> So my question is: what can I do if I want to deliver give the source code and 
> the dependencies jars?
>
> Here are some of my ideas:
> - Maintain a private repository with dependencies and use the deploy:deploy-
> file goal to add dependencies to it.
> Problem: in the love/hate relationship of client/developer companies, I think 
> that the clients might argue that they do not want to depend on the developer 
> company repository. Could be a repository in the client company.
> - Deliver all jars and scripts to install them in the local repository. Seems 
> very 'hackish' and not so 'mavenish'.
>
> What is your experience with this situation?
> Thanks for your attention
>
>   


-- 
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependencies not available in the future

[Graham Leggett <mi...@sharp.fm>]

David Ojeda wrote:

> So my question is: what can I do if I want to deliver give the source code and 
> the dependencies jars?
> 
> Here are some of my ideas:
> - Maintain a private repository with dependencies and use the deploy:deploy-
> file goal to add dependencies to it.
> Problem: in the love/hate relationship of client/developer companies, I think 
> that the clients might argue that they do not want to depend on the developer 
> company repository. Could be a repository in the client company.
> - Deliver all jars and scripts to install them in the local repository. Seems 
> very 'hackish' and not so 'mavenish'.
> 
> What is your experience with this situation?

Keep it simple: Deliver a copy of the local repository (stored in 
~/.m2/repository) along with the source code. Job done.

In the worst case scenario where dependencies are missing, you just drop 
the saved repository into ~/.m2/repository, and build.

Regards,
Graham
--