Wayne is absolutely right ( and one of the best resources in the forum).
Maven imposes a very rigid way of organizing software development.
If you fight it, you will lose.
You can prolong the date of final defeat but you will lose.
If you want to gain the productivity that Maven can give:
1) Le
> Yes, I understand I don't have to have to depend on C from product X, but do
> I need to include it as a module?
You are getting modules, dependencies and artifacts mixed up.
The module concept is simply a convenient way for building an
application which is composed of several parts.
Say top (p
On Thu, Jul 21, 2011 at 3:28 AM, kanesee wrote:
> Hi Wayne,
>
> Yes, I understand I don't have to have to depend on C from product X, but do
> I need to include it as a module?
Re-read my message, well actually I should have written this
Modules != Dependencies
All Modules really do is make ma
Hi Wayne,
Yes, I understand I don't have to have to depend on C from product X, but do
I need to include it as a module?
-Kane
--
View this message in context:
http://maven.40175.n5.nabble.com/Misunderstanding-modules-Two-or-more-projects-in-the-reactor-have-the-same-identifier-tp4614001p461673
> Using the same example where libraries A and B depend on C. If Product X
> needs these libraries, can it just include as modules A and B or does it
> need C as well? That is, can a parent project just include the top-level
> projects or does it need to specify every component in the dependency tr
Yes, this was definitely helpful.
We'll have to rethink the way we're doing things for sure.
Just to clear one more thing up.
Using the same example where libraries A and B depend on C. If Product X
needs these libraries, can it just include as modules A and B or does it
need C as well? That is, c
Thanks for detailed explanation.
In order to not having relative path problems at our build server each
modules has it is own script and common workplace.
I will keep in my mind your suggestions. I am strongly agree with your
opinion.
Is there any resource for Maven patterns/antipatterns?
Cem
Hi
Referencing a files in another module using relative paths is an
anti-pattern. One reason for this is that it will break your build if
you are using a build server, like Jenkins. The build server will check
out each module into a separate folder, which is not in the same folder
structure that y
@stephenconnolly
Sorry but I could not understand your point exactly. Could you explain a
little bid more? You mean because of being at another folder such as my
repository it will point somewhere else?
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/Relative-path-to-
what happens if you have not checked out the parent but only the child
module?
in that case the parent is resolved from the local repo.
You really are pursing an anti-pattern
On 20 July 2011 08:10, Cem Koc wrote:
> I was really expecting something very very simple. :) I think that we
> should
I was really expecting something very very simple. :) I think that we should
file an issue regarding that. What we are trying to do is really very simple
and essential. Maybe properties should has another attribute like "final"
which is forbidding to be overwritten by children modules? What are you
11 matches
Mail list logo
