On 9/12/10 10:03 PM, Jacob Beard wrote:
Hi,
I'm continuing to make progress on the build system, and there's
currently one issue upon which I could use some guidance.
First, here's an update on the current status of the [scxml-js] build
system. The build architecture is currently structured like this:
http://stuff.echo-flow.com/build-architecture.dot.pdf
Basically, there are two entry points into the build: an Ant script
(build.xml), and a Maven script (pom.xml). They both provide build
services like compilation and testing, but aren't completely
equivalent. In particular, the Ant build provides more fine-grained
control over testing, allowing three main testing targets to be
executed (run-unit-tests-with-selenium,
run-in-browser-unit-tests-with-selenium, and
run-unit-tests-with-rhino), whereas the Maven build right now
currently only delegates to the run-unit-tests-with-rhino Ant target.
I wasn't able to find a way to Maven to delegate to individual Ant
testing targets without making a mess of the Ant part of the build
system, and so I chose to restrict the tests that Maven was able to
perform. I therefore think that it's importAnt to maintain both Ant
and Maven as front-ends to the build.
The decision I'm now facing has to do with the Ant front-end. It
currently uses Maven Ant Tools to read the dependencies from the
pom.xml, and then download dependencies and set up the classpath.
Maven Ant Tools is therefore necessary to bootstrap the Ant front-end.
The issue is that Maven Ant Tools can itself be seen as a dependency
which can be downloaded with Maven; however, this cannot be done from
Ant, because the Maven Ant Tools library itself is required to do so.
I think there are several possibilities to resolve this, including
creating a target to download the Maven Ant Tools jar from the Maven
repositories manually, as is currently done with several JavaScript
libraries.
Another possibility might be to allow the user to pass in
the location of Maven Ant Tools as a command-line argument to the Ant
front-end.
Or define it as a property and have it default in
build.properties.sample to ${user.home}/.m2/repository/path-to-tools
That way running the maven build will download the tools once and
the Ant build will subsequently find them. People just running Ant
will have to configure the property or pass it in on the command line.
You can also have the Ant build check if the file exists in the
local maven repo and conditionally execute a get to download it if
it is not there. Again, this requires that there *be* a local maven
repo to house the jar or that the build create and maintain a lib
directory for dependencies.
Phil
If you have any ideas about this, I'd greatly appreciate it if you
could let me know. Thanks,
Jake
On Mon, Aug 30, 2010 at 9:18 AM, Rahul Akolkar<rahul.akol...@gmail.com> wrote:
On Sun, Aug 29, 2010 at 3:55 PM, Jacob Beard<jbea...@cs.mcgill.ca> wrote:
On 10-08-29 07:51 PM, Rahul Akolkar wrote:
On Sun, Aug 29, 2010 at 12:02 PM, Phil Steitz<phil.ste...@gmail.com>
wrote:
Rahul Akolkar wrote:
On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard<jbea...@cs.mcgill.ca>
wrote:
Hi,
I have a Maven question which seems appropriate for this list.
I'm having some trouble understanding how precisely Maven is used in
the
release process. I think CreatingReleases doesn't really describe it,
except
in the bottom section "Procedure for creating a release using M2
(outdated
by above)". The article it links to, Releasing A Maven Project
<http://maven.apache.org/developers/release/releasing.html>, seems to
talk
about releases components /for/ Maven, as opposed to those that simply
use
Maven as the build system.
<snip/>
Releasing at Commons is geared towards achieving two aspects:
(a) adding the necessary jar(s) to the maven central repository
(b) adding the source and binary distros to all the Apache mirrors
Sorry to come into this late; but it is important to note that (b)
*is* the release. We do (a) as a convenience for users and it is
not IMO a *required* release step;
<snip/>
Indeed, I mention things along those lines below, good to clarify upfront.
nor is it strictly required that
Commons components use Maven as their build tool.
<snap/>
Sure, but the chances of me fully supporting (i.e. +1'ing) a sandbox
promotion increase when "mvn install" (with a profile or two thrown
in) produces the distros and any Maven repo artifacts without much
other work. Similarly, any component-specific build or release process
reduces those chances.
Well, at the moment it is possible to build the release JAR with Maven and
AntRun.
I was most recently investigating how to use Ant to download dependencies
that do not have a Maven repo, as is the case for several of the JavaScript
libraries I'm using; and how to integrate the unit testing targets that
currently exist in the [scxml-js] Ant build into the Maven build. This last
task was where I really felt I was seeing the limits of the possible
integration between Maven and Ant, and unfortunately, I didn't feel I could
ask about it on the Maven list. But if running all unit tests using Maven is
not a strict requirement (they would still be runnable by directly calling
Ant), then it sounds like the best approach would be to continue using Maven
and AntRun. This means that Maven will be used for some things, and Ant for
other things, but Maven would still be used for (a) and (b), which seems to
be the most critical.
I'll put aside my investigations into integrating the unit tests, and
instead focus on getting the Maven assembly phase to work, as it sounds like
this is more important.
<snip/>
Sounds reasonable to me. Things other than (a) and (b) can continue to
be documented here [1] (while those two follow the Commons m2 recipe).
-Rahul
[1] http://commons.apache.org/sandbox/gsoc/2010/scxml-js/guide.html
Let me know how this sounds. Thanks,
Jake
-Rahul
The only thing
that is really required is a maven-generated site.
Phil
Maven helps in generating the above artifacts while taking care of
most details needed to make the artifacts release-worthy.
Part of the Maven setup at Commons (the bits captured in the parent
pom) is towards making (a) a lot easier (it does things like building
additional source and javadoc jars, adding good jar manifests etc.) --
this will help with building the [scxml-js] jar. So of the two
[scxml-js] release artifacts, the jar can be mostly covered by Maven
setup in place for other components.
For alpha/beta releases, sometimes (a) may be skipped. We may want to
do this (skip) for the first [scxml-js] release (if and when it is
promoted out of sandbox).
We achieve (b) using Maven assemblies [1]. Maven will help with
creating checksums and signatures that are needed for the distros (and
would otherwise have to be done by hand). (b) is never optional.
Basically, I think the first subtask involved in setting up a a Maven
build
for my project is to determine what are the precise tasks and goals
that are
called in the Maven build in the release lifecycle (I'm attempting to
use
Maven terminology here; if I'm getting this wrong, please correct me).
<snip/>
If the standard directory layout is used for any Java code and jar
resources, generating the jar release artifact won't need any more
prodding (as indicated above, the commons-parent pom will do most of
the work).
The next subtask would then be to delegate these Maven goals, where
needed,
to the ant build script. This may involve overriding Maven's default
behaviour.
<snap/>
The minimized JavaScript artifact will likely need ant scripting to
produce. Look at the maven antrun plugin [1] for details on this
(potentially tied to the package phase).
If you haven't tried this yet, to see what Maven does in terms of
producing artifacts for potential release, run something like 'mvn
-Prc install' in Commons SCXML trunk as an example of what artifacts
gets generated (they will be added to the local ~/.m2 repo).
-Rahul
[1] http://maven.apache.org/plugins/maven-assembly-plugin/
[2] http://maven.apache.org/plugins/maven-antrun-plugin/
The second subtask is one that I will ask about on the Maven mailing
list,
but the first subtask (what tasks and goals are called in a Commons
release
lifecycle) is better for this list.
Let me know what you think about this. Thanks,
Jake
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
