I'm wondering what the scope of the id's are in the various elements where you
can reference a repository. To be specific, if I have definitions of my repos
in , , are the id's
supposed to be unique?
What happens if they aren't? In some cases, it seems that they are the same
repos. For ins
> > Concerning the empty "relativePath" element, this will typically be
> > empty when you can't guarantee that the parent is in the parent
> > directory. it's a common practice to separate the responsibilities of
> > the aggregator pom from the parent pom. When that is the case, if you
> > don'
> > 1) set up local nexus to have a proxy repo that proxies the release
> > nexus's "public" group, if this even works technically
> >
>
> I've been told on this list this is a no-no, because you have to pick an
> artifact
> type when you proxy (release or snapshot; what if the proxied grou
> > Do I need to restructure the way I do my whole build, externalizing
> > the config to another artifact?
>
> This is one (good) way to do it.
>
What then are the options for handling this externalized configuration at build
time? At first glance, I'm thinking it requires a whole extra buil
I'm using Cargo to deploy my WAR to a testing server. The idea is that the CI
build will push the app over to a testing server. When deployed to this
testing environment, my Spring configuration wires mock business objects into
the app. The spring config resides inside my WAR. It's unclear t
>
> In your repo, can you not upload the jars as maven-like artifacts?
>
I can, or at least I can have someone, who is authorized, do that for me. I
was hoping to automate the process of converting the distribution zip into
useable maven pieces . . . perhaps that's just not very normal thi
We have a 3rd party dependency whose distribution consists of a zip file with a
set of jars and native libraries. Our repository person has deployed this zip
for us. We are trying to process the zip into more consumable pieces. We'd
like to create another zip, containing only the native libra
> If you want to basically override the deployed x.y-SNAPSHOT version with the
> last deployed one, then you might want to have a look at buildnumber-
> maven-plugin. This is going to create a variable (say
> buildnumber) in your context. Then you can use that variable in a generated
> manifest.
I frequently deploy artifacts that I build locally to some of my dev
environment servers. Later I have trouble figuring out which one of my local
dev builds I'm looking at in a given dev environment; this is because they are
all named "blahblah-SNAPSHOT.run"
So, I'd like to add a timestamp t
