"The best way is to sync your stuff to the Central Repository" -- true,
but again, there are cases where this is _not possible_. What then? I feel
we keep repeating this mantra, but leaving out some cornerstones...
On Tue, Oct 18, 2016 at 12:04 AM Manfred Moser
wrote:
> The best way is to sync
Hello,
For ensuring that artifacts not go away (like recently some older JBoss public
repos) for enforcing licensing and security restrictions, for caching the
internet, and of course for having a single aggregated repository view we run a
single company server (with a filtered central and othe
On Mon, Oct 17, 2016 at 08:03:03PM +, KARR, DAVID wrote:
> One thing I run into when jumping between different projects is different
> expectations for what maven repos I need to be using. In the past, I had to
> have multiple copies of "~/.m2/settings.xml" lying around, and I would hack
>
> I'm trying, without success, to imagine why you do not simply
> accumulate elements as required.
Wouldn't that cause Maven to ping every server sequentially for every
needed artifact?
Better to set up a Maven repository manager (Nexus, Artifactory, etc.) and
proxy all the needed sources, no? T
But in a large corporate environment, the centralized repository manager can
house hundreds/thousands of repositories so unless you want to virtualize the
entire set of repositories (which tends to make the repository manager slower),
you still need to specify the repositories to search, right?
Yes, some years ago we did exactly this; most academic open source projects
then didn't bother with Maven Central and we relied on 8 different open
repositories around the world, often with dubious hostnames like
rpc268.cs.example.edu:8080 -- this meant that although the build was
reproducible for
Sounds tricky, even if you get Maven and it's dependencies working with
James, presumably you would also need javac to compile?
Why do you want to compile Java code on the embedded platform?
It should be more doable to package your application for jamvm using Maven,
but doing that packaging on a
Is this similar to what I am experiencing? Perhaps not.
My build fails when I change to jdk1.8. Works perfectly in jdk1.7 ... With no
changes other than the change to the jdk ...
Build fails ... cannot resolve dependency ...
Any suggestions?
-Original Message-
From: Stian Soiland-Reyes
Hello,
You can have multiple groups (but I have never seen hundreds or thousands in
use). In our case we have virtual repos only based on the product status and a
separate virtual one for build time (plugin) dependencies.
Btw one more reason for using different settings if you work on projects
Hi:
I have cleaned out the repository, used the -U option and still it will not
build with jdk 1.8
I am getting confused by this situation. It builds successfully with jdk 1.7
with no pom changes.
Is the jdk 1.8 compiler not happy?
Gopal
--
View this message in context:
http://maven.40175.n5
Hi,
Your previous error was about the snapshot policy, which the -U flag has
definitely solved. If you still hit an issue, it has to be a different
error, can you show what it is?
Guillaume
Le 18/10/2016 à 16:19, Gopal a écrit :
Hi:
I have cleaned out the repository, used the -U option and
On 17 Okt 2016, Manfred Moser wrote:
> If you really feel you need to control the source of where you download
> components from within the source control system
> I would still NOT use the repositories definition in the POM since that is
> them transferred to the target repo on deployment (unl
12 matches
Mail list logo
