You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Saleem Shafi <sa...@gmail.com> on 2005/09/29 19:47:36 UTC

multi-project structure issues in M2

hello,

i'm doing some research for a new build system that we want to roll
out at the end of the year and i've got Maven2 on the top of my list,
so i'm trying to work out all of the scenarios that we envision and
making sure that Maven2 can handle them in a reasonable manner.. 
please bear with me as i'm probably going to be sending out a lot of
questions/suggestions in the next week or so..  if it's any incentive,
if i can get this puppy working, i'd be happy to document the use
cases and how i got 'em going..

ok, first one:  project structure and module dependencies

one of the main reasons i'm coming to Maven2 is the enhanced support
for multi-project builds, and i don't even mind the fact that we've
gotta change the structure of our projects since they're in a bit of a
mess at the moment anyway..  here's the situation:  we've got one real
application, with a few different clients, the main one being a
webapp.  Although it's one product, different parts of it get
developed and released at different speeds so, we'd like to break 'em
out into separate projects or modules.  That would get me here:

app
  module1
  module2
  webapp
  wsclient

but, i'd like to make a physical separation between the server-side
app and the different clients, which each have nothing to do with each
other, so i want to be able to do this:

app
  server
    module1
    module2
  client
    webapp
    wsclient


i got the impression that i could reference the pom.xml in app from
the webapp/pom.xml using the <relativePath/> element, but i'm having
trouble getting the app/pom.xml to recognize webapp as a module since
it's embedded in client.  i could setup webapp as a completely
separate project and just create a dependency to server as i would
with wsclient, but the way our team is organized, the people working
on a particular module are generally the same people that work on the
webapp that references that module, so it works better as a project
reference in Eclipse, rather than a library reference.  Is there any
way to get this setup to work without having to specify the entire
client area as a module?  as i said, the different clients themselves
aren't related to each other, so it seems strange for them to have to
all be built together, and only webapp needs to build the server stuff
at the same time, the other clients will treat server as an artifact
dependency.  If this can't be done, is it like this by design, or
should i submit a JIRA request (i'd like to be able to just specify
"client/webapp" as the module)?  if it's designed like this, what's
the purpose of the <relativePath/> element on the lookup of the parent
if the lookup of the module can't be just as flexible?


on a related note, just questioning the purpose of the whole parent
project notion, i understood from Maven1 and the reactor that the
purpose of a parent project was mainly to allow closely-related
projects to build together rather than having to rely on installed
artifacts..  there is the added benefit of being able to define
default configuration values, etc., but i've always understood the
building issue to be the main driving force..  My question is, if
that's the case, why not just introduce a new revision type to the
existing dependency concept that allows you to specify that you want
the latest code for a particular project built fresh?  that way, you
could specify a dependency to any old project and as long as there was
a pom defined for it in your repository, you could find the code and
build it and use the target as part of the classpath for the
subsequent build.  it may require a little extra info in the pom, e.g.
in the dependent project's pom you could have an optional path to a
local copy of the project pom, and in the pom of the project you
depend upon, maybe the SCM location of the latest source, just in case
it's not already available locally.  if all that fails, the revision
value could just be interpreted as snapshot and all is well.  does any
of that make sense?  i'm not sure if i'm missing something about what
the parent project is for or if there's something that would make what
i'm suggesting horribly difficult, but if it doesn't seem too crazy
i'll submit a JIRA request for it.  i think that'll help with a few of
the project structure flexibility issues people like to complain
about.


Saleem.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: multi-project structure issues in M2

Posted by Brett Porter <br...@gmail.com>.
On 9/30/05, Saleem Shafi <sa...@gmail.com> wrote:
> i got the impression that i could reference the pom.xml in app from
> the webapp/pom.xml using the <relativePath/> element, but i'm having
> trouble getting the app/pom.xml to recognize webapp as a module since
> it's embedded in client.

In this structure you have two choices:
- inherit from app, use relativePath so it can be found (but still
must give g/a/v)
- have a client pom that inherits from app, and have each client
module inherit from client.

Am I understanding correctly here?

> on a related note, just questioning the purpose of the whole parent
> project notion, i understood from Maven1 and the reactor that the
> purpose of a parent project was mainly to allow closely-related
> projects to build together rather than having to rely on installed
> artifacts..

well, that didn't work in m1, but it does in m2 :)

The parent notion is solely for inheritence - ie sharing of metadata
among projects. This is different to dependencies (more like
composition in OO terms, you don't actually take on their properties
but you can use them).

<modules> ios the reactor and determines what gets built. Usually,
this is symmetrical to <parent/>, but not necessarily.

> My question is, if
> that's the case, why not just introduce a new revision type to the
> existing dependency concept that allows you to specify that you want
> the latest code for a particular project built fresh?

That's been thought of. I don't think it is in JIRA yet, but you are
welcome to file it. It's certainly a mode we'd like to support.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org