Maven Reorg tips (WAS: Re: What is needed to release Tools 2.0?)

[Antonio Petrelli-3]

2009/10/15 Nathan Bubna <nbubna@...>:
> Separate from the example apps? Or just from the main artifact(s).

From the main artifact, because it involves a specific web application
to be deployed. It could be included into another example app without
problem.

> This is one of the "maven mysteries" to me: what would be the "Maven
> way" to organize our three overlapping jars and 3 example apps and
> conjoined documentation?

Sorry, overlapping jars? What are you referring to?
About the example apps, there are two ways to make it work:
1. separate them from the main distribution, under a pom-typed Maven
project with one module for each app.
2. create a pom project that contains the main distribution and the
apps (eventually under another pom project) as modules.

Tiles uses the second approach, though there is the "showcase" app
(not updated) separated from the rest.

And what do you mean with conjoined documentation?

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nathan Bubna]

On Fri, Oct 16, 2009 at 1:23 AM, Antonio Petrelli
<antonio.petrelli@...> wrote:

> 2009/10/15 Nathan Bubna <nbubna@...>:
>> Separate from the example apps? Or just from the main artifact(s).
>
> From the main artifact, because it involves a specific web application
> to be deployed. It could be included into another example app without
> problem.
>
>> This is one of the "maven mysteries" to me: what would be the "Maven
>> way" to organize our three overlapping jars and 3 example apps and
>> conjoined documentation?
>
> Sorry, overlapping jars? What are you referring to?

We distribute three jars: velocity-tools-generic,
velocity-tools-view, and velocity-tools.  the view jar contains the
generic classes and some additional ones, and the plain velocity-tools
jar includes the generic and view classes and some additional ones
(the struts integration).  Three jars whose contents "overlap".

> About the example apps, there are two ways to make it work:
> 1. separate them from the main distribution, under a pom-typed Maven
> project with one module for each app.
> 2. create a pom project that contains the main distribution and the
> apps (eventually under another pom project) as modules.
>
> Tiles uses the second approach, though there is the "showcase" app
> (not updated) separated from the rest.
>
> And what do you mean with conjoined documentation?

Merely that the documentation for the three different parts (generic,
view, struts) is all interlinked; the struts docs link to view &
generic docs and view docs link to generic docs.

> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli-3]

2009/10/17 Nathan Bubna <nbubna@...>:
> On Fri, Oct 16, 2009 at 1:23 AM, Antonio Petrelli
> <antonio.petrelli@...> wrote:
>> Sorry, overlapping jars? What are you referring to?
>
> We distribute three jars: velocity-tools-generic,
> velocity-tools-view, and velocity-tools.  the view jar contains the
> generic classes and some additional ones, and the plain velocity-tools
> jar includes the generic and view classes and some additional ones
> (the struts integration).  Three jars whose contents "overlap".

The the best choice is to modularize source code and then use the
Maven Shade Plugin to create a "uber jar".
However in this case I prefer the "modularize as much as possible"
approach, i.e. creating very specific JARs with correct dependencies.
In this case, the modules would be:
tools-generic (depending on velocity)
tools-view (depending on generic)
tools-struts (depending on view and generic)
Maven users will get the dependencies automatically resolved.
Is it really necessary to create those "uber jars" after all? Is it so
difficult to put three jars instead of one in the classpath? Note that
it is possible with the Shade plugin, but it seems so useless to me.

> Merely that the documentation for the three different parts (generic,
> view, struts) is all interlinked; the struts docs link to view &
> generic docs and view docs link to generic docs.

There are two ways:
* creating Javadocs for all the modules of a project (approach used by Tiles)
* using the "detectOfflineLinks" parameter, that detects links between
Javadocs sites:
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#detectOfflineLinks
Note that you can even configure external links (e.g. if you want to
link to Javadocs of Java itself, you can do it).

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nathan Bubna]

Ok, you've got me fairly convinced that everything can be done.
That's great.  The next challenge is, i suppose, figuring out how to
transition things over smoothly.  Ideally, that would be in relatively
small (1 hr or less) tasks.

On Sun, Oct 18, 2009 at 5:42 AM, Antonio Petrelli
<antonio.petrelli@...> wrote:

> 2009/10/17 Nathan Bubna <nbubna@...>:
>> On Fri, Oct 16, 2009 at 1:23 AM, Antonio Petrelli
>> <antonio.petrelli@...> wrote:
>>> Sorry, overlapping jars? What are you referring to?
>>
>> We distribute three jars: velocity-tools-generic,
>> velocity-tools-view, and velocity-tools.  the view jar contains the
>> generic classes and some additional ones, and the plain velocity-tools
>> jar includes the generic and view classes and some additional ones
>> (the struts integration).  Three jars whose contents "overlap".
>
> The the best choice is to modularize source code and then use the
> Maven Shade Plugin to create a "uber jar".
> However in this case I prefer the "modularize as much as possible"
> approach, i.e. creating very specific JARs with correct dependencies.
> In this case, the modules would be:
> tools-generic (depending on velocity)
> tools-view (depending on generic)
> tools-struts (depending on view and generic)
> Maven users will get the dependencies automatically resolved.
> Is it really necessary to create those "uber jars" after all? Is it so
> difficult to put three jars instead of one in the classpath? Note that
> it is possible with the Shade plugin, but it seems so useless to me.
>
>> Merely that the documentation for the three different parts (generic,
>> view, struts) is all interlinked; the struts docs link to view &
>> generic docs and view docs link to generic docs.
>
> There are two ways:
> * creating Javadocs for all the modules of a project (approach used by Tiles)
> * using the "detectOfflineLinks" parameter, that detects links between
> Javadocs sites:
> http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#detectOfflineLinks
> Note that you can even configure external links (e.g. if you want to
> link to Javadocs of Java itself, you can do it).
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli-3]

2009/10/19 Nathan Bubna <nbubna@...>:
> Ok, you've got me fairly convinced that everything can be done.
> That's great.  The next challenge is, i suppose, figuring out how to
> transition things over smoothly.  Ideally, that would be in relatively
> small (1 hr or less) tasks.

Hehehe nice joke :-D Seriously it takes a lot of time, but, if I could
access a sandbox, I can show you the final layout of the project.

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nathan Bubna]

On Mon, Oct 19, 2009 at 6:35 AM, Antonio Petrelli
<antonio.petrelli@...> wrote:
> 2009/10/19 Nathan Bubna <nbubna@...>:
>> Ok, you've got me fairly convinced that everything can be done.
>> That's great.  The next challenge is, i suppose, figuring out how to
>> transition things over smoothly.  Ideally, that would be in relatively
>> small (1 hr or less) tasks.
>
> Hehehe nice joke :-D Seriously it takes a lot of time, but, if I could
> access a sandbox, I can show you the final layout of the project.

Hey, can you blame me for a little wishful thinking?  :)  I'll look
into the sandbox stuff.

> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...