I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems.
I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a "library" distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash <[EMAIL PROTECTED]> wrote:
I was not suggesting a "kitchen sink" approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: > > On Nov 7, 2006, at 6:13 AM, ant elder wrote: > >> On 11/7/06, Simon Nash <[EMAIL PROTECTED]> wrote: >> >> webapp-1.0-incubator-M2-SNAPSHOT.jar >> >>> webapp-host-1.0-incubator-M2-SNAPSHOT.jar >>> are not present in the standalone launcher (the rest are). In order >>> to avoid the need for ant users to download these jars from a maven >>> repo, I'd like to propose adding them to the binary distro. For >>> example, they could go in a new webapp directory. They are not large >>> and they would not impact use of the binary distro as a standalone >>> Tuscany launcher. >> >> >> >> I think the issue here is what is our binary distro in M2, is it just >> the >> standalone distro or something more? Some previous discussion have been >> sounding like the binary distro is just the standalone distro, i'm not >> convinced thats true or a good idea. The current name is ...-bin not >> ...-standalone and it already includes the servlet jar and things >> like SDO. >> > They contain SDO because of a hack and should not, specifically the > jars need to be crammed on the system classpath because we have not yet > implemented multi-parent classloading. Once this is in place, they can > be removed. > > As for servlet jar, that is required by the Kernel for ServletHost. We > could factor that out as well moving forward. > >> If we don't include the two tuscany webapp jars in the bin distro we >> release >> then how do we get them released officially with an ipmc vote? >> >> Being pragmatic the easiest way to fix this particular problem >> probably is >> to just also include the two tuscany webapp jars as well. And if >> we're going >> down that route why not also add the javadoc and prebuilt samples as >> well so >> we have a really easy to use binary M2 release :) >> > And then the problem we have is we wind up with the monolith we tried > to avoid based on all of the modularity discussions. As you mentioned > below, when we include BigBank, we drag in DAS. In the future, when we > have additional samples such as a BigBank that uses JPA, we will need > to included those as well. Multiply that with JAXB, other web services > stacks, JMS, etc. The "kitchen sink" approach ultimately is not going > to work with the type of extensible runtime that we have. Instead of > creating a monolith, this can be solved (better IMO) by having the > runtime dynamically provision extensions based on the Maven Artifact > repository service that Meeraj and Jeremy worked on. > > Jeremy had very strong opinions on how this should be done; as our > release manager for M2, before making any significant changes to the > branch we should clear it with him. He mentioned he will be back online > Thursday. > > Jim > >> ...ant >> >> PS. Whats going to happen when trying to build bigbank with ant and >> the DAS >> jars are required? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
