On Nov 7, 2006, at 10:43 AM, Simon Nash wrote:
It seems that if you go down this route you will wind up re-inventing Maven. Maven seems simple enough to me.Jeremy, Thanks for the quick response. I am trying to be pragmatic here and deal with simple use cases. I haven't yet worked out the best way to deal with external or transitive dependencies from an ant build environment (though I do have some thoughts), but having a complete story for this is not needed to build a simple webapp.
Both Jeremy and Raymond pointed out the issue about working from a standalone distribution. There is a further issue that statically cramming things into the distribution is not going to solve. Namely, moving forward, these jars are not going to be the only things required to run in a web app in many of the common usage scenarios. For example, there will also be pure-Tuscany things like a JNDI-based implementation of ResourceHost to support the @Resource tag and service discovery. In addition, people may want to use other optional extensions such as Celtix instead of Axis or JAXB instead of SDO. The best way to solve this other than using Maven (and potentially embedding it as part of the distribution) is to use the artifact repository at runtime or, as you mentioned, a custom Ant task that replicated its functionality at deployment time (it could even embed Maven :-) ). The Ant task would download the jars and place them in the Ant project folder as determined by the user.Adding these 2 jars would be a simple change that would make the "first use" encounter with Tuscany quite a bit easier for ant users.
What would be a less than ideal solution is to adopt the "kitchen sink" approach. Even if today it is two jars, this will quickly break down as the complexity of the runtime configuration increases. Putting this in as a temporary stopgap also does not seem like a good move given the issues it presents moving forward and the fact that we would have to remove it in the next release.
Perhaps a custom Ant task which replicates the functionality in Maven is something you could look into? If you embedded Maven, I don't think it would be that much work.
Jim
I am not proposing a library with extension dependencies like the ones you mentioned (either direct or transitive). I think there are a lot of issues with this, mainly because these dependencies are not part of Tuscany but are part of other projects. The 2 webapp jars are part of Tuscany and would be included in the Tuscany binary distro as a convenience to Tuscany users. IDE-specific packages are something we might get to in the future. I am not trying to be anything like that ambitious at the moment. Yes, we could insist that all Tuscany application developers build with maven. I don't think that would be a wise approach if we want to build a broad-based community. At least there should be some level of support for other build environments, or enough indication of what is going on under the maven covers that people can create other build setups themselves if they want to. Simple ant scripts can serve as this kind of documentation. You're right that a war doesn't need the standalone distribution to be present in order to run. Having a way to use our binary distribution in "library" mode, at least for the Tuscany artifacts that it contains, seems attractive to me if the cost is only adding 2 small jars. I'm quite a newbie with ant so I don't think my war building script in its current form provides the slickest possible approach. I'd be happy to make it available so that people can look at it and perhaps suggest improvements. It currently takes quite a literal approach to recreating the exact same directory and file structure as the maven build produces. I'll create a JIRA and attach the 2 scripts I have created so far (standalone and war). Simon Jeremy Boynes wrote: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) locatedin the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currentlydisconnected state) if you could describe how your environment handlesthese. 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 standaloneruntime distribution as the basis of a build environment is the way tobe 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 standalonedistro 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 buildthese webapps from the binary distro and a simple ant script using onlybuilt-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 thebinary 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 simpleTuscany 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 theseusing ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possibleoptions, which will necessarily be more complex than the simple casewhere there are no dependencies. I'd like to give our users a simpleexperience 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] > > >--------------------------------------------------------------------- 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]
