I have configured Multiple project in my eclipse workspace and each project
has its own POM.XML . I have worked with the dependencies with single
eclipse project with multiple modules in that single project and it works
fine when build with Maven but when working with Different projects is there
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz albert.kur...@gmail.comwrote:
Non-buildable source is fine as a gesture of goodwill, but I think if the
public source isn't buildable, we're gonna end up with egg on our faces.
Quote from:
I have a parent pom that has two modules, A B.
B depends on A.
A depends on P which is a 3rd party jar with provided scope. The task of
module A is to combine the contents of A P, this sum is the output of A.
Now when we build this (clean install) at the parent pom on two systems we
get two
Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
I think we all need some clarification, since we all talk about quality
(we all agreed upon the basic things unanimously).
What is the quality of a maven repository (in general)? Can we measure
it? Can we define it?
A wiki page with
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached
Hi Jeff,
Thank you for your answer. The problem is that I can't change parent poms
because it's enterprise poms. My poms inherit from them to respect
enterprise archictecture choices.
Emmanuel.
Jeff MAURY wrote:
From my experience with Maven, I discourage using properties for
defining
In that case, I don't understand where the versions of your projects are
defined because if the parents are enterprise pom, you are not allowed to
modify them !!!
Jeff
On Sat, Sep 26, 2009 at 4:06 PM, Emmanuel24 eserv...@xebia.fr wrote:
Hi Jeff,
Thank you for your answer. The problem is
From my experience with Maven, I discourage using properties for
defining pom version, Maven does handle it correctly on some cases,
even if the properties are defined on the parent pom
I recommand using version herited from the parent and updating the
parent version with the version plugin
Jeff
As I said, I define the version in ProjectParent and in this project, I
defined my modules as the figure shows it.
But my modules don't inherit from this project. That is the problem.
Emmanuel.
jeffma...@jeffmaury.com wrote:
In that case, I don't understand where the versions of your
In that case, you're stuck and the release plugin will do the job but don't
use properties to define versions.
I think a certain version of Maven allows to import a pom into another.
Regards
Jeff
On Sat, Sep 26, 2009 at 7:09 PM, Emmanuel24 eserv...@xebia.fr wrote:
As I said, I define the
I think we all need some clarification, since we all talk about quality
(we all agreed upon the basic things unanimously).
What is the quality of a maven repository (in general)? Can we measure it?
Can we define it?
A wiki page with piled up (even personal) opinions would be good -- whatever
they
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If Sonatype's goal is to sell these tools only for paying
IMHO, being buildable by maven is a nice to have, but to be honest, if
somebody wants to build their project with a DOS batch file and a
piece of string I don't mind as long as they publish the artifact with
a valid pom
anything else is setting the repository up for failure
Sent from my
You got the point. But that quality information (whatever it's form would
be), could do things like:
- describe the overall quality of repo (let's name it the MRQ score)
- the list (or only the count) of rules/tests ran (so, a repo of MRQ
score 5 with 5 tests would be less good than a repo with
if you start measuring artifact quality, it makes sense to break down
the stats by groupId
at least that way if I see that java.net has 100% quality for
com.stvconsultants.easygloss I can configure my repository manager to
allow that group I'd through, but leave org.glassfish out as its
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz albert.kur...@gmail.com wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to
central it just too useful... it has gathered critical mass whereby it is
nearly a right of passage for new java projects to get hosted on central...
hosting on central becomes one of those things projects are asked to do...
if we move the goalposts too far or too fast we will kill the
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
which selects which of the 3 maintained repo will be
On Sat, Sep 26, 2009 at 12:11 PM, Albert Kurucz albert.kur...@gmail.com wrote:
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified
On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If
On 2009-09-26, at 12:11 PM, Albert Kurucz wrote:
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
I find myself replicating the same log4j configuration in my Maven projects.
It's a typical setup I want my projects to always use. Is there any good way
to specify one in a parent POM for all child projects? Would the
maven-remote-resources-plugin be useful for this?
Paul
Something like this approach should work:
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/
On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict pbened...@apache.org wrote:
I find myself replicating the same log4j configuration in my Maven projects.
It's a
24 matches
Mail list logo
