[kepler-dev] Maven and Ptolemy

[David Welker]

A few thoughts in response to Christopher's interesting email:
> Ok, I was able to build using Maven.  I started from Tristan's notes
> and created $PTII/doc/coding/maven.htm, which I've attached.
>
> There are a few issues to contend with:
>
> * Why does "make maven" copy the .java files?  This means
>   that we have yet another copy of the code and that changes to the
>   master .java files are not propagated?  This was a problem with ant
>   in Kepler, we should see about avoiding it.
>
>   The tool should fit our current directory structure, we should
>   not need to change our directory structure to fit the tool.
I sort of like the idea of this. Our tools should conform to us, we 
shouldn't have to conform to our tools, right? But I think it may be a 
bit too idealistic.  In fact, to some degree, Maven can be configured to 
use different directory structures. However, this is a non-trivial 
amount of work to make it do so. And furthermore, it is not only Maven 
proper that we have to worry about, it is a whole host of Maven plugins 
that are maintained by various third parties. Not all of these third 
parties will necessarily handle differences from the standard directory 
structure gracefully or correctly.

Overall, I would be inclined to just simply follow the Maven standard, 
unless there is a truly compelling reason not to do so. Build systems 
are challenging enough. Why create the added stress of a directory 
structure different from what is expected by the tool? And what about 
third-party tools that don't work well with non-Maven directory structures?

Finally, even to the extent that Maven and third-party Maven plugins 
support other directory structures, there are more likely to be bugs. 
For example, Maven supports the automatic generation of Intellij, 
Netbeans, and Eclipse project files. However, if you change your 
directory structure, there is a higher chance that one of these generate 
project files would have a bug.
>
> * Having resources separate from the sources makes no sense for a
>   componetized architecture.  Every time a package is moved, the
>   resources need to be moved.  The resources should be in the
>   jar that uses the resources.
>
>   I know that webstart has a hard time finding resources that are not
>   in the jar file that contains the .class file that references the
>   resource.
As long as there are standards concerning where the resources are 
stored, (i.e. in a directory structure parallel to the code, but not 
necessarily with the .java files themselves), it is perfectly easy to 
package the resources in the jar that uses those resources. I am going 
to play devil's advocate and say that for a componetized architecture, 
it makes most sense to separate the resources from the .java files. The 
resources themselves should be considered as a set of components, and if 
you want to substitute a resource component, having that resource 
component widely separated in many different locations and entangled 
with .java files is going to make your task quite a bit more complicated.

Finally, the most compelling reason to use the Maven standard may have 
nothing to do with Maven or Maven plugins. If Ptolemy and Kepler were to 
define a common directory structure for storing code and defining 
modules that could be mixed and matched, it seems that we would be able 
to integrate the functionality of the two projects in a much more smooth 
matter, and to a higher degree. (i.e. If someone from Ptolemy wrote a 
module that would be useful in Kepler projects, it could be more easily 
used than currently. And vice-versa.) That common directory structure 
and standard for laying out modules might as well be the Maven standard, 
a standard that is increasingly being adopted by various Apache projects 
and other open source projects.
>
>   Maven seems to want resources in a separate directory.  David and I
>   have exchanged some email on this, and I'm not yet convinced that
>   having resources away from the code makes any sense.
>   The Maven docs say
>   "Having a common directory layout would allow for users familiar with
>    one Maven project to immediately feel at home in another Maven
>    project. The advantages are analogous to adopting a site-wide
>    look-and-feel."
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>
>
>   So, it sounds like this is a Maven standard.  The great thing about
>   standards is that there are so many to choose from.  :-)
>
>
>
> * The $PTII/pom.xml file lists dev.archer.edu.au
>   as the repository, this should probably be changed to the Ptolemy
>   website.  Should this be a configuration time choice?
>
> * There is this entire issue of how to generate the pom.xml file, what
>   to do not all of the optional components are available.  Right now,
>   it is fairly easy to build a stripped down Ptolemy that does not
>   include packages like Java 3D.  Do we still need a configure step?
This brings up what I see as a disadvantage of Maven. If you want to do 
changes that are not currently supported, you have to learn all about 
the Maven lifecycle and write a custom plugin to achieve your goals. I 
am not familiar enough with Maven to know whether the configuration here 
would be supported (or would only be supported only if you used the 
Maven directory structure standard) or whether you would need to write a 
custom plugin to do configuration.

Thanks for sharing your thoughts on this, to me, very interesting topic.

-David