I'm not sure if this is the right forum to post this question. If not,
please advice me where to post this question.
I setup a Nexus group repository that references several proxy
repositories. This group repo only references the released
(non-SNAPSHOT) artifacts.
The group repo referenc
Yes i have get the problem solved.
I will advice you to please read out the Maven's Book from Pages 32 to 42
Moreover >> Whenever you go for Maven's first time compilation ; please make
sure that your machine must have internet with downloading access ; THE MOST
IMPORTANT it must be free from al
To make it work the Maven way, you should ideally separate the jar
from the war file as an independent module. Your war file will then
depend on the jar.
Not sure if your packaging is war, adding maven-jar-plugin creates a jar
file? If it does then you can use build-helper-maven-plugin to ins
..or my favorite:
Change to the Maven Way(tm)! What you're doing is not, IMHO, the correct
way. I guess you're not doing Maven deploys to a remote repo as you would
end up with different flavors of a project's artifact? Which can't happen as
releases mustn't change.
What you should do is to either
I have a scenario where in my pom generates a war file. Whereas I also need a
jar of the same to be referenced by other projects. So I added a
maven-jar-plug-in to generate a jar for the same. As the pom was installing
this generated jar as the war to the repository. I mentioned a classifier to
di
> and copy them in as part of the hudson build. I guess we could put the
> settings.xml file for the hudson user in to source control, but having all
> of that information from across all of our projects in one place is far from
Well, it seems like you have a few options...
1. One big settings.x
Sorry, I guess I didn't explain. The configuration settings need to
be version controlled and the hudson server runs the builds for the
whole company.
As it stands now, we pull the profiles.xml files from a different svn
repo and copy them in as part of the hudson build. I guess we could
> want this information added in to our pom directly. Modifying settings.xml
> in a hudson build seems like a bad idea, since then if multiple hudson
> builds are run at once, they would impact eachother.
I don't understand this comment. You should be able to copy all your
profiles into one setti
>> You need to download it directly from the JavaEE site and install it with
>> the instructions that you find in the build log. License issues, it can't
>> be distributed through the central repo.
You may also find what you need (spec-jar-wise) from the Geronimo project:
http://repo2.maven.org/m
Ah ... ok, thanks
On Thu, Nov 11, 2010 at 4:08 PM, Brian Topping wrote:
> On Nov 10, 2010, at 9:58 PM, Simon Lewis wrote:
>
> > What's up with http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/
>
> You need to download it directly from the JavaEE site and install it with
> the instructions that
On Nov 10, 2010, at 9:58 PM, Simon Lewis wrote:
> What's up with http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/
You need to download it directly from the JavaEE site and install it with the
instructions that you find in the build log. License issues, it can't be
distributed through the ce
Hi,
What's up with http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/
Shouldn't there be a jar in there ??
thanks
Simon
Hi,
I am trying to upgrade a maven 2.x build system to a maven 3.x build
system and have run in to a problem with the fact that profiles.xml is
no longer supported. Our current build iconfigures the built .ear
file based on build properties supplied in profiles.xml. These
properties are
+1, That's the spirit! It's like I said, many teams for a long time have
under-valued the build process and deem the whole activity to be not
worth their time. And yet, so few teams I meet can provided me with a
bill-of-materials or even a basic architectural drawing showing the
relationship of th
I'm not talking about libraries, I'm talking about an app that has been
built for years either with Ant or without a build script. So we get a
known good EAR and de-construct it often finding JARs that don't exist
in the wild or are unidentifiable. So re-creating that EAR Maven can
become a real ch
On 10/11/2010 4:37 PM, Brian Topping wrote:
On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:
It is mostly exclusions to stop old versions of libraries from being dragged in
by mistake.
It took a bit of doing to get these the first time but it is nice now that we
do not have a screen full of co
That would be because hudson turns off failing a build if tests fail.
In hudson, failing tests is a yellow ball.
Build broken is a red ball
Everything hunky-dory is a blue ball.
your issue comes from using the crappy maven 2 project type in hudson which
modifies your build behind your back.
Use
Is there a way to configure the javadoc plugin to generate two sets of
Javadoc output? We find it convenient to have both the default public
and private versions.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
Fo
On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:
> It is mostly exclusions to stop old versions of libraries from being dragged
> in by mistake.
> It took a bit of doing to get these the first time but it is nice now that we
> do not have a screen full of conflicting version notes.
So I guess y
On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote:
> I have used the technique described here but I have also had too to
> forensic type package level comparisons to try an find matches.
> Eventually slugging our way through namespace collisions and knocking
> down issues one Classpath Not Found a
On 10/11/2010 3:40 PM, marshall wrote:
Hi;
This is probably a beginner question, but I thought it was worth posing
because it is frequently very frustrating when working with Maven.
Is there a clear way to know which particular dependencies Maven requires,
when working with a set of jars/li
I would be curious if you could unpack you app and just replace the JARs
with ones from Maven repo's and have it still work.
I can't tell you how projects I've encountered where I cannot figure
what version a JAR is or where it came from. I am sure I have seen hand
modified JAR lumping packages to
I would agree with you on this one. I think one of the discussions that
is missing here is the idea of when or how we determine we have
*something of value*.
My assumptions is it goes something like this:
Build -> Inspect and Test -> Value? YES|NO
Right now the approach presented in this group w
+1
> -Original Message-
> From: Brian Topping [mailto:topp...@codehaus.org]
> Sent: Wednesday, November 10, 2010 3:49 PM
> To: Maven Users List
> Subject: Re: Figuring out the proper Maven dependency setting
>
>
> On Nov 10, 2010, at 3:40 PM, marshall wrote:
>
> > Hi;
> > This is pr
On Nov 10, 2010, at 3:40 PM, marshall wrote:
> Hi;
> This is probably a beginner question, but I thought it was worth posing
> because it is frequently very frustrating when working with Maven.
> Is there a clear way to know which particular dependencies Maven requires,
> when working with a
stephenconnolly wrote:
>
> so lets say for #1 we add a phase of "ship"... we'd have the standard
> lifecycle something like
>
> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
> verify -> install -> deploy -> ship
>
> that would allow us to bind our CD steps to the "ship"
Hi;
This is probably a beginner question, but I thought it was worth posing
because it is frequently very frustrating when working with Maven.
Is there a clear way to know which particular dependencies Maven requires,
when working with a set of jars/libraries?
For example, I have been trying t
Certainly and I would promote that the solution using this mechanism should
allow a rang eto be specified. In a true CD shop though I think it would be
important the you could leave the upper bound off. It seems both are
supported so it is all good.
--
View this message in context:
http://maven.
stephenconnolly wrote:
>
> Well I regard that the project being delivered can only have internal
> -SNAPSHOT dependencies, all external (to the reactor) dependencies
> should be release dependencies.
>
> One of the things I have wanted to do with v-m-p is to hack around
> version ranges... for
Followup: I can reproduce this error with a very minimal project by using the
maven-arcetype-plugin to create a simple project, and then adding the following
plugin declaration to the POM:
org.apache.maven.plugins
maven-assembly-plugin
2.2
Obviously there are times when that is the case but and others when the
boundary would be welcome.
-Original Message-
From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com]
Sent: Wednesday, November 10, 2010 2:54 PM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven
I do
The dep ranges make more sense to me because they can equate to
feature/functionality sets and still enable parallel development for all
those non-CD shops ;-) I'm sure there is no notion of parallel
development in CD since they eschew branches in favor of Bliki feature
toggles (which are pretty
I don't think you need to specify a top end. For example, you could use [1.0,).
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-version-ranges.html
> -Original Message-
> From: jmorrow [mailto:j...@morrowmail.com]
> Sent: Wednesday, November 10, 2010 2:51 PM
>
Thiessen, Todd (Todd) wrote:
>
> Is LATEST deprecate now?
>
> But if I recall correctly, I don't think it would be quite right either as
> LATEST implies the latest release or snapshot. So you'll want to be
> careful here.
>
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Mav
And you're right. You could probably use version ranges for this as Stephen was
saying. Then you wouldn't use snapshot deps at all. All projects would simply
use the mvn ship command instead of mvn deploy and never work with snapshots.
Make it so ;-). I'd love to see what you have 2 weeks ;-).
Is LATEST deprecate now?
But if I recall correctly, I don't think it would be quite right either as
LATEST implies the latest release or snapshot. So you'll want to be careful
here.
> -Original Message-
> From: jmorrow [mailto:j...@morrowmail.com]
> Sent: Wednesday, November 10, 2010 1:
I am not entirely sure what Jason means when he says "pluck the snapshot out
and promote it to a release repository". I think he still means rebuild it from
source but I agree that that statement is a bit unclear.
The release plugin, by default, builds twice. First it checks out the code as a
s
> full stack trace below. Does anyone know what might be wrong? Is there any
> other information I should include to help diagnose? Thanks.
It might be helpful to send your configuration as well...
Wayne
-
To unsubscribe, e-m
stephenconnolly wrote:
>
>
>
> foo
> bar
> [1.0,2.0)
>
>
>
This seems to me to a place where the Maven concept of
LATEST actually makes sense to use. If we add around this
your concept of writting the concreate version and checking-in, it ott work
nicely. With this approach you do no
OK, I've done some further investigation and discovered that this only
happens on our Hudson CI server. The cmdline maven build works as expected.
For reference, here is the JIRA for the Hudson project:
http://issues.hudson-ci.org/browse/HUDSON-8065
--
View this message in context:
http://maven
BTW - I also think Stephen's suggestion is a good one - it's more or less
what I suggest in the book.
On 10 November 2010 09:45, Jez Humble wrote:
> Hey Todd.
>
> My interpretation of what Jason is saying in his comment here -
> http://www.lucasward.net/2010/11/maven-and-continuous-delivery.htm
Hey Todd.
My interpretation of what Jason is saying in his comment here -
http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html - "you
should be able to tag the code, and pluck the snapshot out and promote it to
a release repository... Someone just needs to do the two weeks of work
I've tried hard coding the resource bundle path and I get the same result.
And it only happens about half the time, regardless.
Judging by the stack trace, the problem is somehow related to what happens
when Surefire forks so that the tests run in their own JVM process. When I
set "forkMode" to
On 11/09/2010 06:43 PM, Benjamin Bentmann wrote:
Not possible.
Thanks, at least I will not waste more time trying.
usually accomplished by an artifact
handler for the dependency type in question which sets
includesDependencies=true like for WAR artifacts.
Interesting, did not think to look
I ended up using Cargo for that. In my particular case, all I did was to
create a tomcat6 instance (via Ubuntu built-in package) and add the admin
webapp
IMMV however
--
-- Aldrin Leal, / http://www.leal.eng.br/mnemetica/
On Wed, Nov 10, 2010 at 10:33 AM, Bruno Borges wrote:
> Have anyone exp
The exec-maven-plugin turned out to be a good solution. Now the shell
script simply delegates to maven:
mvn -q exec:java -DscxmlInputArgs="$*"
And the .bat script is virtually the same thing. Very clean and simple,
I think.
Thanks for your help with this,
Jake
On 10-11-09 02:25 PM, Benjami
I am trying to use the pre-defined "bin" assembly descriptor (descriptorRef)
and I am getting an error stating that "A tar file cannot include itself."
I've included a full stack trace below. Does anyone know what might be wrong?
Is there any other information I should include to help diagnos
Have anyone experienced running a WAR project in production based on the
Maven Tomcat plugin?
We are considering to use it as we think it is simpler than installing a
whole Tomcat setup and deploying WAR files . Our usecase has only one
project and no more modules are planned. Each one on its own
Agreed Stephen. I think your proposal is the best so far. I just want to make
sure we don't go back into a discussion about promoting snapshots to releases,
as I believe that is where this discussion started. To do that I think would
require a significant re-architecture of maven which I don't
Here's the contents of settings.xml relevant to our repo manager:
our-repository
Maven Repository Manager running on
corp.com
http://repo.corp.com/artifactory/repo
*
On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Todd) wrote:
> +1 here. Jez was indicating that it was "Crucial" that a snapshot build not
> get "rebuilt" when creating the release and simply get promoted to a release.
> That is simply not that way maven currently works. I hope that is now clear.
>
How have you defined your corp maven repo in your settings.xml
I'm wondering if it's a bug in maven 2 pulling releases from the wrong repo
and therefore you don't notice that the repo is defined incorrectly in
settings.xml
On 10 Nov 2010 08:39, "mjsell" wrote:
Yeah, this is definitely not a po
2010/11/10 jeb001 :
> I've seen that I should use profiles et filters.. but I don't know exactly
> how, with my 4-part project?
>
> In which pom.xml have I to define thoses filters ? each one ?
> I'm not sure this is the best way to do it..
Yes, each one you have such configurable resources.
1. Ju
Imho taking a snapshot artefact and renaming as a release artefact and
pushing to the remote repo will never be supported by maven, but my
ship-maven-plugin (not ready for publishing yet) and some extra mojos added
to versions-maven-plugin should enable CD in a way that is in keeping with
the "mave
There are 2 issues here: the one that Dennis pointed out that the last
line of the table has to match the first; the other that you can't have
all cells in all rows empty. Just add at least one row with at least one
non-empty cell to make it work.
Since you say that this used to work, it wou
I don't think thats the same thing. The proposal is to take a snapshot artifact
which was built using mvn deploy and promote it to the release repo. I think
what you are referring to here Jason is how the release plugin first builds the
snapshot, tags it, and then rebuilds the tag.
> -Origi
OK I have worked out what was causing the repeat attachment and deployment of
the sources and javadoc jars
I was already specifying javadoc and source jar creation in my build profile
- I didn't release that release:perform also specified these artifacts -
hence the attempt to deploy the 'same'
2010/11/10 emerson :
> When I import the project using eclipse2m, the source folder entry for
> the src/test/scenarios have Included: (All) and Excluded: **
Yes, it is annoying. There's an old JIRA issue for it:
https://issues.sonatype.org/browse/MNGECLIPSE-784
Antonio
--
On Nov 10, 2010, at 12:46 AM, Christopher Hunt wrote:
> Thanks Oliver.
>
> I think that it'll be quite a while before people write MOJOs just for Maven
> 3. From my own perspective having just written two new MOJOs, I'd like to be
> able to write for the future but recognise the present. It'd
I tried the m2eclipse, but that also seems to import a wrong build path.
I have the following entry on my parent pom.xml
src/test/scenarios
org.apache.maven.plugins
maven-surefire-plugin
src/test/scenar
2010/11/10 jeb001 :
> Now, I'm looking for the best way to use maven profiles with my new project
> organisation..
> I just wanna create 2 profiles, developpement and production, for each
> project.
> The production profile will have to package using src/main/resources-prod
> directory, and thes
>
Ok, that works the way I want... with 4 eclipse projects and only 3 real
ones.
Now, I'm looking for the best way to use maven profiles with my new project
organisation..
I just wanna create 2 profiles, developpement and production, for each
project.
The production profile will have to package usi
You're right, those 2 set of resources only differ in the addresses they
point. (or something like that..)
I've seen that I should use profiles et filters.. but I don't know exactly
how, with my 4-part project?
In which pom.xml have I to define thoses filters ? each one ?
I'm not sure this is t
Hi ildella,
Did you find a solution for this issue in your post. I am facing the same
problem. Tried setting the failOnError flag to true, but it didn't work. Its
considering a compiler error as a warning and not a error and its not
failing. Let me know what solution you ended up with?
Thanks,
L
Stephen's solution makes sense to me. It doesn't try to conflate the meaning
of SNAPSHOTs and it retains the metadata in trunk that keeps everything in
the Maven build instead of relying on an outside tool.
Anyone see any issues with this approach? I think I like it from what I
understand so far.
Yeah, this is definitely not a pom that exists in the project tree, so the
parent-pom resolution changes mentioned in the compatibility notes do not
apply. In my case it is a corporate pom that is separately released, and
all of our project trees end up inheriting from a previously released
versi
We handle this very problem by having different aggregating projects for
different purposes: one is, as you say, a global project that contains
all the modules that make up our application, which we use for full
builds and other, smaller aggregator projects that only contain the
minimal set of
67 matches
Mail list logo
