[kepler-dev] Maven and Ptolemy
cxh at eecs.berkeley.edu
Sat Aug 16 10:41:46 PDT 2008
Ok, it looks like I can change pom.xml so that it follows the
Ptolemy "standard" :-).
I don't have a complete build working, but I think it can be done.
A long time ago, I used to talk about code-motels, which were
like roach motels, where code checked in but never checked out.
For those of you not familiar with the "Roach Motel" ads of yore,
A roach motel is a little box with glue on the bottom. Cockroaches
would go inside, get stuck and not be able to get out. The tag
line of the ad campaign was "Roaches check in, but not out".
A code motel is a tool that wants to run the development process,
once the code motel is used, it is like joining a cult, one
cannot easily change code outside of the tool. This is also known
as the "round-trip problem". Fortunately, most tools have solved
this problem. While Maven has code motel tendencies, the design
of Maven appears to allow for other code structures.
I do think that the tool should conform to a pre-existing structure.
Sure, there might be bugs, but these are bugs that should be resolved.
I'm willing to help resolve them. I agree that we gain something
by following standards. I could argue that Ptolemy is using a much
more standard structure of recursive makefiles, and Maven should
have followed that structure. (There is an article about "Recursive
make considered harmful" though). The advantage of recursive
make is that in effect, each directory has a manifest that lists
what it provides and what it needs. I don't see an easy way
to get away from this.
About componetization, I think having everything local is a complete
win. I've just not seen the downside. For the Ptolemy project,
the source code is considered to be a form of publication, and really
should be shipped with the runtime .class files. Having the .java
files local to the .class files helps in deployment and helps
users find good example code. In many ways, this is a FSF-view of
the world, where the source code is always available. There
are times when having the source available is not required, say
deployment to small devices, so we should support source-less
distributions. However, when people ask me what we do, I say
"Make Ph.D.s". Shipping the source code really helps with that goal.
I think the next question is how to deal with optional package
discovery. The standard configure way is one way. I think Maven
can also check for the existence of classes and react accordingly.
David Welker wrote:
> 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
> 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
>> 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.
Christopher Brooks (cxh at eecs berkeley edu) University of California
Chess Executive Director US Mail: 337 Cory Hall
Programmer/Analyst Chess/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 fax: 510.642.2718 (office: 400A Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480
More information about the Kepler-dev