Re: [scxml-js] working toward a release

[Jacob Beard <jb...@cs.mcgill.ca>]

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.

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 <ra...@gmail.com> wrote:
> On Sun, Aug 29, 2010 at 3:55 PM, Jacob Beard <jb...@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<ph...@gmail.com>
>>>  wrote:
>>>> Rahul Akolkar wrote:
>>>>> On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard<jb...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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

Re: [scxml-js] working toward a release

[Phil Steitz <ph...@gmail.com>]

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<ra...@gmail.com>  wrote:
>> On Sun, Aug 29, 2010 at 3:55 PM, Jacob Beard<jb...@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<ph...@gmail.com>
>>>>   wrote:
>>>>> Rahul Akolkar wrote:
>>>>>> On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard<jb...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


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