You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Chris Tucker <ch...@linspireinc.com> on 2005/11/15 00:47:59 UTC

Multi-module project with Eclipse

Hi,

The page http://maven.apache.org/guides/mini/guide-ide-eclipse.html 
explains how to use Eclipse with a multi-module Maven2 project. 
Specifically, it gives instructions to "handle maven multiple module 
projects with eclipse while keeping the recommended hierachical project 
layout.".  I'd be interested to hear why the hierarchical project layout 
is preferred.  So far, I can see the following pros and cons:

1) The hierarchical structure is more natural: it's not necessary for 
users to dig around in POMs to see what other POMs are likely to play a 
part in the build.
2) The hierarchy nicely deals with organizing a set of artifacts that 
combine to produce another (e.g. for organizing the war/jar/par/ejb3 
modules that make up an ear in a EE 5 app)
3) As a corollary to (2) you can create changesets against a tree 
spanning multiple projects in Eclipse where appropriate (as it can be 
in, for example, an EAR project).  With a flat structure, this is much 
more cumbersome.
4) The hierarchy does not map cleanly into Eclipse: if the hierarchy 
gets deep, you end up with lots of "dummy" directory projects that house 
other projects.  Eclipse isn't really aware of the relationship between 
the "dummy" projects and the "real" projects, increasing the chances of 
Eclipse getting confused.
5) It's a pain to set up a freshly checked out tree in the hierarchical 
model: mvn eclipse:eclipse won't generate .project files for 
<packaging>pom</packaging> type projects.

I'm sure there are other arguments for and against that I'm missing, but 
right now I'm finding it hard to determine one as being superior to the 
other: indeed, both seem to have significant downsides.  Ideally Eclipse 
would support a more structured project model, but it seems unlikely 
that's going to happen any time soon so I'd be interested to hear how 
others have solved this problem.

Cheers,
Chris

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

Re: Multi-module project with Eclipse

Posted by Chris Tucker <ch...@linspireinc.com>.
If it helps matters, here is what I'm currently considering as a 
compromise between the two approaches (flat vs. hierarchical).  This is 
for a source tree that will contain, as an example, all of the "web" 
related ears in the system; in a full use, we might expect to see an 
expansion of directories at the top level to cover other systems.

.
|-- global-build-config
|   `-- pom.xml
+-- web
|   |-- web-build-config
|   |   `-- pom.xml
|   +-- ac
|   |   |-- ac-build-config
|   |   |   `-- pom.xml
|   |   |-- ac-domain
|   |   |   |-- pom.xml
|   |   |   `-- src
|   |   |       |-- main
|   |   |       `-- test
|   |   |-- ac-ear
|   |   |   `-- pom.xml
|   |   |-- ac-par
|   |   |   `-- pom.xml
|   |   `-- ac-war
|   |       |-- pom.xml
|   |       `-- src
|   |           `-- main
|   |               |-- resources
|   |               `-- webapp
|   +-- ecomm
|   |   |-- ...
|   +-- mail
|       |-- ...
`-- ...

At each level I create a self-contained project that I can load into 
eclipse that contains only a POM; this is equivalent to putting the pom 
directly in the levels' directory, but allows me to manipulate it 
without having a tree of all children open in Eclipse (meaning I can 
work independently on any project at any level).  The only time this 
rule is breached is at the leaves, where mvn is much happier if the POM 
is colocated (I don't want to have to specify where the POM is every time).

Each directory under "web", except for the web-build-config directory, 
is an EAR project (though other project types would be quite acceptible 
too).  These then break down into a build-config for that project and 
the separate components that will be assembled into a final EAR.

Reasons I like this structure:
- almost as simple as a pure hierarchy for understanding where POMs will 
come into a build from
- organizes related artifacts together neatly
- doesn't require dummy projects: everything can be a true project in 
Eclipse
- expands cleanly to arbitrary depth

Reasons I don't like this structure:
- doesn't really solve the source management problem of potentially 
wanting to commit something atomically across project boundaries (though 
Eclipse seems to handle this better than I previously thought)
- still suffers the problem of not having automatic .project generation 
for pom-only artifacts (though this could readily be fixed with some 
tweaking of maven-eclipse-plugin).

Thoughts?

Cheers,
Chris


Srepfler Srgjan wrote:
> These are really good remarks and it reflects the show-stopper that we 
> received after we realized there is slim chance on sharing our ear 
> application modules between maven 2 and eclipse's WTP.
> I think more discussion on this subject could be useful and some help on 
> how to manage code base between the environments and hints on how do 
> maven/eclipse developers might evolve their environments would be useful.
> 
> Chris Tucker wrote:
> 
>> Hi,
>>
>> The page http://maven.apache.org/guides/mini/guide-ide-eclipse.html 
>> explains how to use Eclipse with a multi-module Maven2 project. 
>> Specifically, it gives instructions to "handle maven multiple module 
>> projects with eclipse while keeping the recommended hierachical 
>> project layout.".  I'd be interested to hear why the hierarchical 
>> project layout is preferred.  So far, I can see the following pros and 
>> cons:
>>
>> 1) The hierarchical structure is more natural: it's not necessary for 
>> users to dig around in POMs to see what other POMs are likely to play 
>> a part in the build.
>> 2) The hierarchy nicely deals with organizing a set of artifacts that 
>> combine to produce another (e.g. for organizing the war/jar/par/ejb3 
>> modules that make up an ear in a EE 5 app)
>> 3) As a corollary to (2) you can create changesets against a tree 
>> spanning multiple projects in Eclipse where appropriate (as it can be 
>> in, for example, an EAR project).  With a flat structure, this is much 
>> more cumbersome.
>> 4) The hierarchy does not map cleanly into Eclipse: if the hierarchy 
>> gets deep, you end up with lots of "dummy" directory projects that 
>> house other projects.  Eclipse isn't really aware of the relationship 
>> between the "dummy" projects and the "real" projects, increasing the 
>> chances of Eclipse getting confused.
>> 5) It's a pain to set up a freshly checked out tree in the 
>> hierarchical model: mvn eclipse:eclipse won't generate .project files 
>> for <packaging>pom</packaging> type projects.
>>
>> I'm sure there are other arguments for and against that I'm missing, 
>> but right now I'm finding it hard to determine one as being superior 
>> to the other: indeed, both seem to have significant downsides.  
>> Ideally Eclipse would support a more structured project model, but it 
>> seems unlikely that's going to happen any time soon so I'd be 
>> interested to hear how others have solved this problem.
>>
>> Cheers,
>> Chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

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

changelog-maven-plugin problem

Posted by Ashley Hurkoo <ah...@tenzeng.com>.
I am not sure where the error is coming from, it just says FATAL ERROR

Also is there a way to run just the changelog plugin instead of of doing mvn
site:site and wait forever?


      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>changelog-maven-plugin</artifactId>        
      </plugin>
    </plugins>

 

  <scm>
 
<connection>scm:cvs:pserver:ashley@10.4.0.243:/usr/local/cvsroot:LGEnterpris
e</connection>
 
<developerConnection>scm:cvs:pserver:ashley@10.4.0.243:/usr/local/cvsroot:LG
Enterprise</developerConnection>
    </scm>


[INFO] [site:site]
[WARNING] Error loading report org.apache.maven.changelog.ChangeLogReport -
AbstractMethodError: canGenerateReport()
[WARNING] Error loading report
org.apache.maven.changelog.DeveloperActivityReport - AbstractMethodError:
canGenerateReport()
[WARNING] Error loading report org.apache.maven.changelog.FileActivityReport
- AbstractMethodError: canGenerateReport()
[INFO] Generate "changelog" report.
[INFO] Generating changed sets xml to:
c:\Ashley\modules\MMS_IA\LGEnterprise\target\changelog.xml
[INFO] ChangeSet between 2005-10-16 and 2005-11-16: 0 entries
[INFO]
----------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
----------------------------------------------------------------------------
[INFO] null
[INFO]
----------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
        at java.util.Hashtable.put(Hashtable.java:398)
        at
org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530)
        at
org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:
541)
        at
org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370)
        at
org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java
:263)
        at
org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeL
ogReport.java:218)
        at
org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.ja
va:198)
        at
org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.jav
a:173)
        at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.
java:117)
        at
org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:80
2)
        at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManage
r.java:399)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLife
cycleExecutor.java:519)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(De
faultLifecycleExecutor.java:482)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifec
ycleExecutor.java:452)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail
ures(DefaultLifecycleExecutor.java:301)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Defa
ultLifecycleExecutor.java:268)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycle
Executor.java:137)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
----------------------------------------------------------------------------


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

Re: Javadoc within the maven generated site

Posted by Brett Porter <br...@gmail.com>.
We don't generally recommend building from SVN unless you intend to
patch the code, however for the record you do this:

svn co https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
and in the plugin of your choice, run:
mvn install

For now, you can do this to get the latest published build (which I've
just done):

<pluginRepositories>
  <pluginRepository>
    <id>snapshots</id>
    <url>http://snapshots.maven.codehaus.org/maven2</url>
  </pluginRepository>
</pluginRepositories>

Cheers,
Brett

On 11/15/05, Ashley Hurkoo <ah...@tenzeng.com> wrote:
> Can you send me a link where it is documented how to  build this plugin from
> SVN for it to work for me?
>
>
>
> -----Original Message-----
> From: Brett Porter [mailto:brett.porter@gmail.com]
> Sent: Tuesday, November 15, 2005 11:59 AM
> To: Maven Users List
> Subject: Re: Javadoc within the maven generated site
>
> It's a known issue, fixed in SVN.
>
> On 11/15/05, Ashley Hurkoo <ah...@tenzeng.com> wrote:
> > Does anyone knows how to generate the javadoc in the maven site,
> >
> > I did this
> >
> > <reporting>
> >         <plugins>
> >       <plugin>
> >         <groupId>org.apache.maven.plugins</groupId>
> >         <artifactId>maven-javadoc-plugin</artifactId>
> >       </plugin>
> >     </plugins>
> > </reporting>
> >
> > It generates the javadoc, but when I click the link on the maven
> > generated site, it does not work.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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

RE: Javadoc within the maven generated site

Posted by Ashley Hurkoo <ah...@tenzeng.com>.
Can you send me a link where it is documented how to  build this plugin from
SVN for it to work for me?

 

-----Original Message-----
From: Brett Porter [mailto:brett.porter@gmail.com] 
Sent: Tuesday, November 15, 2005 11:59 AM
To: Maven Users List
Subject: Re: Javadoc within the maven generated site

It's a known issue, fixed in SVN.

On 11/15/05, Ashley Hurkoo <ah...@tenzeng.com> wrote:
> Does anyone knows how to generate the javadoc in the maven site,
>
> I did this
>
> <reporting>
>         <plugins>
>       <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-javadoc-plugin</artifactId>
>       </plugin>
>     </plugins>
> </reporting>
>
> It generates the javadoc, but when I click the link on the maven 
> generated site, it does not work.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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


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

Re: Javadoc within the maven generated site

Posted by Brett Porter <br...@gmail.com>.
It's a known issue, fixed in SVN.

On 11/15/05, Ashley Hurkoo <ah...@tenzeng.com> wrote:
> Does anyone knows how to generate the javadoc in the maven site,
>
> I did this
>
> <reporting>
>         <plugins>
>       <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-javadoc-plugin</artifactId>
>       </plugin>
>     </plugins>
> </reporting>
>
> It generates the javadoc, but when I click the link on the maven generated
> site, it does not work.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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

Javadoc within the maven generated site

Posted by Ashley Hurkoo <ah...@tenzeng.com>.
Does anyone knows how to generate the javadoc in the maven site,

I did this

<reporting>
	<plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
      </plugin>
    </plugins>
</reporting>

It generates the javadoc, but when I click the link on the maven generated
site, it does not work.



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

Re: Multi-module project with Eclipse

Posted by Srepfler Srgjan <sr...@lnksystem.com>.
These are really good remarks and it reflects the show-stopper that we 
received after we realized there is slim chance on sharing our ear 
application modules between maven 2 and eclipse's WTP.
I think more discussion on this subject could be useful and some help on 
how to manage code base between the environments and hints on how do 
maven/eclipse developers might evolve their environments would be useful.

Chris Tucker wrote:

> Hi,
>
> The page http://maven.apache.org/guides/mini/guide-ide-eclipse.html 
> explains how to use Eclipse with a multi-module Maven2 project. 
> Specifically, it gives instructions to "handle maven multiple module 
> projects with eclipse while keeping the recommended hierachical 
> project layout.".  I'd be interested to hear why the hierarchical 
> project layout is preferred.  So far, I can see the following pros and 
> cons:
>
> 1) The hierarchical structure is more natural: it's not necessary for 
> users to dig around in POMs to see what other POMs are likely to play 
> a part in the build.
> 2) The hierarchy nicely deals with organizing a set of artifacts that 
> combine to produce another (e.g. for organizing the war/jar/par/ejb3 
> modules that make up an ear in a EE 5 app)
> 3) As a corollary to (2) you can create changesets against a tree 
> spanning multiple projects in Eclipse where appropriate (as it can be 
> in, for example, an EAR project).  With a flat structure, this is much 
> more cumbersome.
> 4) The hierarchy does not map cleanly into Eclipse: if the hierarchy 
> gets deep, you end up with lots of "dummy" directory projects that 
> house other projects.  Eclipse isn't really aware of the relationship 
> between the "dummy" projects and the "real" projects, increasing the 
> chances of Eclipse getting confused.
> 5) It's a pain to set up a freshly checked out tree in the 
> hierarchical model: mvn eclipse:eclipse won't generate .project files 
> for <packaging>pom</packaging> type projects.
>
> I'm sure there are other arguments for and against that I'm missing, 
> but right now I'm finding it hard to determine one as being superior 
> to the other: indeed, both seem to have significant downsides.  
> Ideally Eclipse would support a more structured project model, but it 
> seems unlikely that's going to happen any time soon so I'd be 
> interested to hear how others have solved this problem.
>
> Cheers,
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


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