I ended up with a tradoff and now ship any custom libs as a dependency
of type 'system',e.g.
<dependency>
  <groupId>org.chiba</groupId>
  <artifactId>chiba</artifactId>
  <version>1.2.0</version>
  <scope>system</scope>
  <systemPath>${basedir}/lib/chiba-1.2.0.jar</systemPath>
</dependency>

Other well known public libs, such as the jakarta stuff, will be
downloaded the usual way through public repos. If any of those
downloads fail developers are supposed to manage to download and
install them manually.

On 2/8/06, John Casey <[EMAIL PROTECTED]> wrote:
> it's possible, if a little involved. ;)
>
> First, you need a local repository that contains only the plugin
> artifacts needed for your build plus your project's dependencies. This
> means setting up a settings.xml that points to this isolated local
> repository (probably the settings.xml *and* the local repository will
> live in your project directory, but I'd expect that the local repository
> would *not* be checked into SCM...ignored, I mean). Then, to use this
> settings.xml, you'd have to use:
>
> mvn --offline --settings /path/to/your/settings.xml <some-phase>
>
> to run the build (offline, so it won't muck around with trying to access
> a remote repository). To keep this consistent, you may want to create a
> shell script or batch file in your project directory that would wrap the
> 'mvn' command line invocation, and inject these two options. This would
> be the entry point for your users to build your project. Now, if you're
> looking to locate this project directory on a CD, you must make sure
> that you're able to park your compiled classes somewhere writable, maybe
> in /tmp or something. You'd need:
>
> <build>
> <outputDirectory>${java.io.tmpdir}/${artifactId}-${version}</outputDirectory>
> </build>
>
> in your pom.xml, to redirect from /target to this new working directory.
>
> I *think* that would do the trick for you, but you'd have to check me on
> that. Also note that it's possible that the outputDirectory redirection
> has some bugs in it, as it relies on each plugin correctly referencing
> ${project.build.outputDirectory} in its output path construction, rather
> than simply ${basedir}/target or somesuch.
>
> Good luck, and let me know how it goes! :-)
>
> -john
>
>
> Stefan Podkowinski wrote:
> > The plugin looks interesting but its not quite what I need. Although
> > the assemble plugin allows to create custom source distributions with
> > gathered libs I dont get why I should do this since my project *is*
> > actually the source ;)
> >
> > What I like to do is to ship my maven project as it is including a
> > repository with all dependencies (which includes non-public jars or
> > patched jars). So even when the sky is falling and the last public
> > repo is gone, I can be sure my project compiles fine and I'm further
> > able to distribute it to others. Is there any standard way how this
> > could be done with maven? I'm aware that this possibly goes against
> > the whole 'no binaries in cvs' idea but I really wonder why I have to
> > setup my own remote repo and - even worse - why everyone else who
> > likes to work on the sources will have as well, just to keep some
> > control over artifacts.
> >
> > On 2/7/06, John Casey <[EMAIL PROTECTED]> wrote:
> >> This is probably going to be *a lot* easier for you:
> >>
> >> http://maven.apache.org/guides/mini/guide-assemblies.html
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> Stefan Podkowinski wrote:
> >>> Hello
> >>>
> >>> Whats the best way to distribute your project if you need to provide
> >>> all artifacts incl. dependencies with your release? E.g. if you want
> >>> to ship everything on CD, or just have a lot of artifacts that are not
> >>> available on public repos.
> >>>
> >>> I wonder if it would be possible to create a project specific local
> >>> repo that is refered to from pom.xml? But as far as I could tell
> >>> theres only a config option for remote repos and I didnt have much
> >>> success with it.. Am I missing something or how would I do this?
> >>>
> >>> Regards,
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to