[ http://issues.apache.org/jira/browse/TUSCANY-733?page=all ]
Jeremy Boynes reassigned TUSCANY-733:
-
Assignee: Jeremy Boynes (was: Meeraj Kunnumpurath)
Version information should not be in war plugin source code
[
http://issues.apache.org/jira/browse/TUSCANY-733?page=comments#action_12443530
]
Jeremy Boynes commented on TUSCANY-733:
---
Patch applied to trunk - thanks JoJo
Version information should not be in war plugin source code
I applied a patch from Jojo that allows you to specify the version of
the bootlibs that the plugin will use, overriding the default.
This seems small and stable and I think we should apply to M2 as well.
--
Jeremy
On Oct 19, 2006, at 7:11 AM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date:
I thought these two were different: the original (now updated) one in
sampleapps, Ken's start of a new version in samples/bigbank. The
latter seems dormant so unless someone wants to pick it up perhaps we
should move it to the sandbox.
--
Jeremy
On Oct 19, 2006, at 11:00 AM, Luciano
There was some discussion about this on the Java spec call today and
I have agreed to write up a proposal for how this can work. I plan
to start this on our wiki - if anyone is interested please jump in.
http://wiki.apache.org/ws/Tuscany/SpecProposals/Resources
--
Jeremy
On Oct 9, 2006,
Passed with binding +1's from rdonkin, geirm, dims
and non-binding +1 from matezw
Thank you everyone.
--
Jeremy
On Oct 15, 2006, at 6:34 PM, Jeremy Boynes wrote:
The Tuscany PPMC has voted to release a parent pom and buildtools
jar that are dependencies for a forthcoming M2 release
On 10/3/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
This sounds like having cake, eating it, and also being
able to
give it to a friend :-) We provide the flexibility for users:
1) to access infrastructure services through properties
Yes
could
write up some quick instructions on how to get Continuum set up to run
Tuscany builds if that would be helpful.
The next step, I would imagine, would be to create a maven profile
that, when enabled, would run some integration tests as part of the
build.
-Bert
On 10/17/06, Jeremy Boynes
I think getting the two versions is a pom problem, possibly related
to the issue with the plugin.
For the plugin having a hard coded version, it isn't the best way to
do it and there's a JIRA open[1] to fix this. If you could help with
the JIRA that would be appreciated.
--
Jeremy
[1]
On Oct 18, 2006, at 4:25 AM, kelvin goodson wrote:
I had a combined samples and binary distro in RC2, but the
discussion of
that candidate (
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09004.html)
resulted in me creating a separate distribution.
As to you parent directory
I'm afraid the LICENSE.txt file in the sdo-impl distribution does not
contain the text of the EPL/CPL for EMF. It is referenced by link
from the NOTICE file but legal best-practice says that the text of
all licenses should be included in the distribution.
Sorry to do this but -1.
--
Jeremy
On Oct 18, 2006, at 9:20 AM, Bert Lamb wrote:
I did a quick write up on how I set my server up here:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/ContinuumForTuscany
Hope this helps!
Thanks - I'll take a look and see if I can get it running on my
server later today.
--
Jeremy
On Oct 18, 2006, at 8:53 AM, Raymond Feng wrote:
+1 from me.
I can help as well. I already have a simple mortage approval
application in my sandbox and I'll convert it to whatever
integration test environment we come out when it's ready.
What I'm messing with is a maven plugin that can
() in the test code is null.
Suggestions on how to push this over without massive use of
reflection would be welcome. All the latest code is in the sandbox.
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/testing
Cheers
--
Jeremy
On Oct 18, 2006, at 9:57 AM, Jeremy Boynes wrote
A bit of history here :-)
In M1 we required that an application create a TuscanyRuntime before
interacting with any SCA code. We had feedback that this was a
problem for application developers and that they should not need to
do that - they should automatically have an SCA context as if by
On Oct 17, 2006, at 8:01 AM, Peter Cousins wrote:
1) Do you think bindings need to advertise whether they use
non-WorkScheduler threading via the manifest or some other
mechanism to
accommodate deployment issues/constraints?
Perhaps.
In our model there is nothing special about bindings -
artifacts will be overwritten). But we need to make sure that
isolation is not compromised in this case.
2) For the application-by-application case, it works very simlar
as the WAR plugin does to create a self-contained image.
Thanks,
Raymond
- Original Message - From: Jeremy Boynes
we chatted on irc but ...
On Oct 17, 2006, at 6:26 AM, kelvin goodson wrote:
I'm currently trying to deploy and sign the sdo artifatcs to the
remote
maven repository.
I have 2 issues.
1) I have put a server stanza in my settings.xml for maven to
give my
username and password for the
In cutting M2 the lack of integration testing has been quite painful.
We need to start adding the post-build functional/integration testing
we've talked about before but which we've not actually implemented.
I'm going to start work on some projects in the sandbox to try and
automate
[
http://issues.apache.org/jira/browse/TUSCANY-867?page=comments#action_12443136
]
Jeremy Boynes commented on TUSCANY-867:
---
I applied this patch (sans bat script and still have SNAPSHOT references in
the project tree:
$ grep -ri
It was change in the 0.95 spec that private field and setters are not
supported (due to security issues bypassing the Java protection model).
--
Jeremy
On Oct 16, 2006, at 9:32 AM, Scott Kurz wrote:
I noticed you can't use the @Reference annotation on a private
field of a
Java component
see the changes in the 0.95 CI spec.
Sections 1.3.1.1. Using Reference Injection and 1.7.9 could use
updating. I'll send a feedback via the OSOA site unless you tell
me that's
not necessary.
On 10/16/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
It was change in the 0.95 spec that private field
Sorry for the confusion here.
The intention is to support running applications through the launcher
using
$ java -jar launcher.jar ${your-executable-jar}
The launcher is assuming that your-executable-jar is packaged as a
executable jar with Main-Class and Class-Path attributes in the
Passed with PPMC +1's from kelvingoodson, jboynes, bdaniel, jmarino,
rfeng, rineholt, kwilliams, svkrish, antelder
and +1's from Luciano Resende, Simon Nash
I'll will ask the IPMC to ratify this.
--
Jeremy
On Oct 12, 2006, at 7:55 AM, Jeremy Boynes wrote:
New version of the build artifacts
I copied r464380 to create branches/das-java-M2
HTH
--
Jeremy
On Oct 15, 2006, at 10:15 PM, Luciano Resende wrote:
The DAS project have already gone trough 3 release candidates and I
believe
it's ready to get branched as suggested in a previous e-mail thread
started
by Jeremy.
want
to be
sure)
Thanks
- Venkat
On 10/14/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Oct 13, 2006, at 11:34 PM, Venkata Krishnan wrote:
Hi Jeremy, I can help with this. Could you please help a
bit with
how this
is to be done.
Here is what I understand as of now
of those in the repo from a
build of the trunk.
--
Jeremy
On Oct 14, 2006, at 3:57 AM, ant elder wrote:
Is the branch supposed to be buildable yet? It fails for me with It
requires a project with an existing pom.xml, but the build is not
using
one.
...ant
On 10/14/06, Jeremy Boynes [EMAIL
On Oct 13, 2006, at 11:34 PM, Venkata Krishnan wrote:
Hi Jeremy, I can help with this. Could you please help a bit with
how this
is to be done.
Here is what I understand as of now...
- Look up all Loaders (extended from LoaderExtension) and make this
modification for the xml type used by
/sdo-java-M2/sdo-api/
* branches/sdo-java-M2/sdo
These all produce non-SNAPSHOT artifacts in your local repo.
--
Jeremy
On Oct 13, 2006, at 7:10 PM, Jeremy Boynes wrote:
There are still a couple of changes needed before we have a
complete branch for the release. So far I have copied in sca
Definite +1 for consistency.
I think we should remove the version from the name as it impacts the
URL the user gets when they deploy to Tomcat. I think that should be
as short and simple as possible.
--
Jeremy
On Oct 13, 2006, at 5:38 AM, cr22rc wrote:
I agree we should be consistent.
+1
On Oct 13, 2006, at 5:18 AM, ant elder wrote:
The less config the better in my opinion so using the defaults
seems best.
A question could be are those default locations ok, but WEB-INF/
default.scdl
and WEB-INF/tuscany/extensions seem fine to me.
...ant
On 10/13/06, Rick [EMAIL
Repeating the same search in the sca tree shows quite a few
exceptions - any volunteer to clear them up?
$ grep -rli --exclude=*.svn-base licensors sca
sca/kernel/core/src/main/java/org/apache/tuscany/core/databinding/
impl/DataBindingRegistryImpl.java
I've added the Maven-based dependency support to the standalone
runtime as Meeraj described and it seems to work well. Ant's tested
with the JavaScript sample and we are able to run that just by
copying the container extension to the the extensions directory.
One thing we've noticed is
We need to remove the SNAPSHOT designation from the XML schema
namespaces that we use in SCA. Does anyone have a chance to look at
this?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
I added this (using -Doffline for the launcher for now) but I have
not figured out how to make the embedded Maven instance use it yet.
--
Jeremy
On Oct 13, 2006, at 2:28 PM, Jeremy Boynes wrote:
I've added the Maven-based dependency support to the standalone
runtime as Meeraj described
I put the Maven support in the standalone runtime and we have been
able to test samples that in both standalone and webapp
configurations that are not using the dependency mechanism. Rick
reports that BigBank is still working (although it has not as yet
been converted to use the dependency
Branch taken - if you fix anything please remember to apply the patch
to both trunk and the branch :-)
--
Jeremy
On Oct 13, 2006, at 6:39 PM, Jeremy Boynes wrote:
I put the Maven support in the standalone runtime and we have been
able to test samples that in both standalone and webapp
There are still a couple of changes needed before we have a complete
branch for the release. So far I have copied in sca but I have not
* branched/tagged the sca spec api
* tagged the commonj twm api
* included the samples
I plan to handle the first two.
I'd like to suggest for the samples we
New version of the build artifacts that other Tuscany modules depend
on. For each there are links to the tag (as a separate source
distribution is not really applicable) and the artifact.
Please vote to approve the release of these so we can use them to
build the releases of the other
My +1
--
Jeremy
On Oct 12, 2006, at 7:55 AM, Jeremy Boynes wrote:
New version of the build artifacts that other Tuscany modules
depend on. For each there are links to the tag (as a separate
source distribution is not really applicable) and the artifact.
Please vote to approve the release
[
http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441857
]
Jeremy Boynes commented on TUSCANY-833:
---
Jim's proposal to the mailing list sounds like a better long-term solution but
I am concerned that doing
The NOTICE text refers to the EPL and CPL but I didn't think there
was any reference to anything under those licenses in that module (as
opposed to the implementation). If this is right we should remove
that as being confusing; if not, then we should also include the EPL
and CPL text in
Another thought, for SCA we are using a common NOTICE file across
most modules with variable substitution to insert the name of the
module etc. This is because of the number of modules we have :-) That
might be useful here as well.
--
Jeremy
On Oct 12, 2006, at 2:12 PM, Jeremy Boynes wrote
You normally don't need or want to do this - the information is
inherited from the parent (das) pom.xml's dependencyManagement
section which enables it to be specified in one place and shared
between all modules.
--
Jeremy
On Oct 12, 2006, at 2:32 PM, Luciano Resende (JIRA) wrote:
as part of the source
distribution, then default values will be available.
- Luciano
On 10/12/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
You normally don't need or want to do this - the information is
inherited from the parent (das) pom.xml's dependencyManagement
section which enables
I had a memory of seeing one of these recently so I grepped for
something indicative in SDO and DAS and came up with:
$ grep -rli --exclude=*.svn-base licensors sdo das
sdo/distribution/src/main/assembly/sdo.xml
sdo/impl/src/test/resources/anytype.xsd
sdo/impl/src/test/resources/api_test.xsd
Depends on the repo.
In the webapp we have a maven based repo implementation that supports
transitive deps based on maven metadata in the artifact or in an
accompanying pom (at least, I think this is what Meeraj's thing does).
In the standalone env we are currently using a simpler repo
:
tuscany:dependency
groupaxis2/group
artifactaxis2-core/artifact
versionSNAPSHOT/version
/tuscany:dependency
How does the standalone environment currently translate this group,
artifact and version information into the name and location of the
dependency artifact that it will load?
Simon
Jeremy Boynes wrote
We have had quite a few suggestions over the last couple of days for
new functionality for the trunk some of which would result in changes
to the APIs. We have also had the completion of one of the major
pieces of code (async over axis webservices) that was still
outstanding although there
On Oct 11, 2006, at 4:57 PM, Simon Nash wrote:
Thanks. Using the local maven repo is convenient for maven users,
and adding full maven support (transitive dependency resolution
and automatic downloading) to the standalone environment is a
significant improvement for these users.
However, I'm
, at 7:14 AM, ant elder wrote:
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED]
wrote:
I think organizing the samples like this is a
good idea.
I'd
suggest
going one step further and place each sample with
the
implementation
of the service
On Oct 9, 2006, at 7:28 AM, Andy Piper wrote:
At 15:21 09/10/2006, Jeremy Boynes wrote:
In many cases building the sample does not actually prove anything as
they are not executed. This applies, for example, to the webapp-based
samples we have. When they are executed, we still don't know
build and
run the samples is the right long term solution, but until we have
that framework, we should not remove building the samples from
the regular build.
Simon
Jeremy Boynes wrote:
I was pointing out the reasoning behind (which is what Rick
asked) which should be fairly well known given
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ]
Jeremy Boynes closed TUSCANY-797.
-
Assignee: (was: Jeremy Boynes)
Thanks Simon
standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
On Oct 9, 2006, at 12:52 PM, Rick wrote:
Not really part of this thread, but a question that came to mind
because of it; would an integration test deploy and use Tomcat like
we had before? If we ever got to using a continuum type build in
apache would that be an issue ? Opening and
On Oct 7, 2006, at 10:08 PM, Luciano Resende wrote:
We could start with your previous post, and maybe take a portion of
Monday's
IRC Chat to go over QA or clarifications ? Does that sound good ?
Happy to chat on Monday (but remember it's a holiday in some parts of
the world and people may
I was asked off-list why I would abandon the release vote when I had
the necessary +1's. The answer is tied to the decision making process
at the ASF.
One of the benefits the ASF provides to its projects is that it is a
corporation, an actual legal entity that can perform legally binding
On Oct 8, 2006, at 10:54 AM, Daniel Kulp wrote:
I've been playing around with the ARAT tool that a couple of the
incubator
folks are working on:
http://code.google.com/p/arat/
I'd swear I ran that on buildtools before the release.
It found a BUNCH of files that don't have the proper
Licensing issues around DTDs used by checkstyle
---
Key: TUSCANY-806
URL: http://issues.apache.org/jira/browse/TUSCANY-806
Project: Tuscany
Issue Type: Bug
Reporter: Jeremy Boynes
[ http://issues.apache.org/jira/browse/TUSCANY-806?page=all ]
Jeremy Boynes reassigned TUSCANY-806:
-
Assignee: Jim Marino
Assigning to jmarino as the original contributor to the project.
Licensing issues around DTDs used by checkstyle
Li, your email is being held in a moderation queue as you are not
subscribed to the mailing list. I've modded one copy through.
--
Jeremy
On Oct 8, 2006, at 6:54 PM, Li Shen wrote:
Hi,
I noticed that in the helloworldws sample, now only SDO gets used.
If I want
to use JAXB/XMLBeans
In general, binary or mechanically generated files are not an issue.
AIUI arat spots some but not all.
XML files like the ones you mention are somewhat in the middle - they
are editable, but no-one is likely to be editing them directly or
supplying a patch for them. If they are not part of
I had volunteered to do a lightning talk on Tuscany in the Incubator
session at ApacheCon. Unfortunately I won't be attending - would
someone be able to take over? The sign up sheet is here:
http://wiki.apache.org/incubator/ApacheConFastTrack
--
Jeremy
I'm seeing a build failure in the echo.databinding sample:
testTransform(echo.DataBindingIntegrationTestCase) Time elapsed:
1.403 sec ERROR!
org.apache.tuscany.spi.wire.InvocationRuntimeException:
java.lang.IllegalArgumentException: argument type mismatch
at
, quite the
reverse in
fact.
Regards, Kelvin.
On 06/10/06, Jim Marino [EMAIL PROTECTED] wrote:
On Oct 6, 2006, at 12:30 PM, Jeremy Boynes wrote:
This got PPMC +1's from jboynes, dkulp, jmarino, rineholt, rfeng,
bdaniel, kwilliams
and +1 from Luciano Resende
However, there are significant
On Oct 5, 2006, at 11:28 PM, Jim Marino wrote:
A more complex case is where a composite at some arbitrary depth
down the application tree wants to share a class with a system
component (such as an extension) that is at some other arbitrary
depth down the runtime tree. We have two solutions
It's not a feature of maven - we can call them what we like. It may
be a feature of the maven-idea-plugin. I ignore them and just have
modules for the leaf projects.
I'd like to keep the overall parent (~/pom/parent/pom.xml) that
contains the project-wide configuration but if you'd like to
On Oct 6, 2006, at 1:57 AM, ant elder wrote:
Ok I think we're getting some agreement but I'd like to be clear
everyone
agrees and is happy before I make any changes. Sounds like for
things like
the Groovy/JavaScript/etc helloworld and calculator type samples
they would
go with the
The release plan had osgi in the include if its ready category. IMO
I don't think it's ready yet so would put it in the contrib
category (in the source, not in the binary, YMMV).
The need for multi-parent is really driven by SDO and Spring
support. In the webapp environment the user is
as the things being released and
the votes
we're going to be asking for?
...ant
On 10/6/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Any other votes on this?
--
Jeremy
On Oct 2, 2006, at 8:28 AM, Jeremy Boynes wrote:
The parent pom and buildtools are pre-reqs for all other Java
projects
On Oct 6, 2006, at 7:00 AM, Ken Tam wrote:
Thoughts on the search order/priority for these classloader
hierarchies? Child-before-parent has some real advantages here -- it
lets extensions specify exactly what version of a dependency to use
and expose to its consumers, rather than have the
On Oct 6, 2006, at 7:47 AM, Ken Tam wrote:
I was blocked this morning by an autowiring error running the Spring
integration BootstrapTestCase -- it kept complaining that it couldn't
resolve an autowire to BuilderRegistry. After rolling back pretty
much all the local changes that I thought
On IRC Kelvin mentioned possibly re-jigging the SDO distribution
format to include the assembly phase in the parent pom. The idea was
that would make it easier to aggregate things like JavaDoc across the
modules.
I've taken a swag at this in my sandbox:
,
then that would be a great advance.
Best Regards, Kelvin.
On 06/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
On IRC Kelvin mentioned possibly re-jigging the SDO distribution
format to include the assembly phase in the parent pom. The idea was
that would make it easier to aggregate things like
think it would be unwise to proceed to
the IPMC and so am going to withdraw these artifacts. We need to come
up with an alternative plan for the release which everyone is clear on.
--
Jeremy
On Oct 2, 2006, at 8:28 AM, Jeremy Boynes wrote:
The parent pom and buildtools are pre-reqs for all
I think organizing the samples like this is a good idea. I'd suggest
going one step further and place each sample with the implementation
of the service that it is illustrating. That way it becomes much
easier to tag/release each module on its own.
Also, the samples that are in java and
As Rick said, the the war plugin has a extensions configuration
element do the packaging as Meeraj described here:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/%
[EMAIL PROTECTED]
In general, you would not want to list extensions as normal pom
dependencies as that
On Oct 5, 2006, at 7:10 AM, Ken Tam wrote:
Yeah, I haven't run into the ordering issue because I'm just dealing
with individual extensions, but that completely makes sense.
It feels like if we're going to stay on the track of this maven(-like)
depot system for managing extensions, I would
On Oct 5, 2006, at 7:14 AM, ant elder wrote:
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I think organizing the samples like this is a good idea. I'd suggest
going one step further and place each sample with the implementation
of the service that it is illustrating. That way it becomes
It's actually even more complex than the situation that you outline
as we need to deal with a hierarchy of classloaders on both the
application and runtime sides. In general, we also will not have the
ability to control what gets added to the host environment's
classloaders that are the
On Oct 5, 2006, at 8:19 AM, Ken Tam wrote:
Failure to communicate -- I was _agreeing_ with Rick, and saying that
if we _didn't_ solve 765 (in particular supporting the pre-scan idea),
it would result in an increasingly crappy user experience. I _like_
just being able to drop extensions into a
On Oct 5, 2006, at 1:10 PM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Thu Oct 5 13:10:50 2006
New Revision: 453347
URL: http://svn.apache.org/viewvc?view=revrev=453347
Log:
comment out sdo samples assembly as it breaks the das build
Kelvin
I had to comment out the assembly step as it
Any other votes on this?
--
Jeremy
On Oct 2, 2006, at 8:28 AM, Jeremy Boynes wrote:
The parent pom and buildtools are pre-reqs for all other Java
projects in the M2 release. These are distributed through the maven
repo rather than as a end-user distribution. Please vote to approve
You need to bootstrap the runtime. There are two ways of doing this:
1) run from the command line using the launcher:
java -jar launcher.jar ${your-executable-jar}
2) configure your IDE to run the launcher (with the appropriate
classpath and params)
--
Jeremy
On Oct 5, 2006, at 7:17 PM,
I added Geoff Winn and Simon Laws to tuscany-developers
On Oct 3, 2006, at 8:17 PM, Jean-Sebastien Delfino wrote:
I am not able to assign a JIRA issue to Geoff. Simon Laws does not
seem to be in the assign list either.
How can we add these users (who already created many of issues) to
Kelvin asked about why we should vote on the parent pom artifacts and
buildtools separately rather than have a single vote for all
artifacts. It is due to the modular nature of our build and the
dependencies between the different distributions that we were looking
to produce. It's kind of
I have the same content in both the .zip and .tar.gz (which is good)
but it does not have these files in the bin directory (which is bad).
They used to be there (as of a couple of days ago) so something has
changed in the dependency matrix to break this.
--
Jeremy
On Oct 4, 2006, at 7:31
I've had two people express concern about the quality level we
currently have: Jim with concern on the unit test coverage, Rick with
concern about quality in general.
I'd like to ask everyone's opinion about where we are now, in general
and specifically about the content that we have
Simon's post reminded me of a question from the IRC chat Monday -
what is the state of the spring container and should we include it in
the M2 binary distro or not (it would still be in the source)?
--
Jeremy
-
To
then perhaps you would be prepared to
contribute a section to the release guidelines.
Best Regards, Kelvin.
On 04/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Kelvin asked about why we should vote on the parent pom artifacts and
buildtools separately rather than have a single vote for all
artifacts
samples and distribution are now moved under das
I had to find a name for the binary distro so I called it binary -
the artifactId has not changed.
--
Jeremy
On Oct 4, 2006, at 2:46 PM, Luciano Resende wrote:
Hi Jeremy
Thanks for volunteering on our last Monday IRC chat to help moving
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ]
Jeremy Boynes resolved TUSCANY-797.
---
Fix Version/s: Java-M2
Resolution: Fixed
Assignee: Jeremy Boynes
I added a lib directory for jars that get pulled in on the manifest
There seem to be a few changes mixed in here.
The extension directory moves from /WEB-INF to /META-INF and that
seems like an odd place to me. Is this what the plugin is doing?
Registering the RuntimeInfo and WebappRuntimeInfo separately to work
around an autowire issue seems hacky - I
I see wires in the assembly as representing the interaction between
application components. Properties on the other hand represent a
contract between the application component and the container (by
which I mean the container is responsible for configuring an instance
of the application
On Oct 3, 2006, at 1:41 PM, Jim Marino wrote:
I like most types of cake too but I think we should really have one
way of doing this. I've vacillated in the past on whether things
such as DataSources, EntityManagers, etc. are modeled as services
in an *application* assembly or are contracts
On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
This sounds like having cake, eating it, and also being able to
give it to a friend :-) We provide the flexibility for users:
1) to access infrastructure services through properties
Yes for things like JPA, JDBC, etc.
2) to reference
On Oct 1, 2006, at 10:19 PM, Luciano Resende wrote:
I recall a discussion about this topic :
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg06338.html
Did we ever made a template configuration available somewhere (e.g
Wiki) ?
In preparation for the SDO release I am about to tag the parent pom
and buildtools modules. To avoid disruption to the trunk I will not
update the build to use them until they have been released and hit
the online maven repo.
--
Jeremy
On Oct 2, 2006, at 12:21 AM, [EMAIL PROTECTED] wrote:
Author: jmarino
Date: Mon Oct 2 00:21:17 2006
New Revision: 451902
URL: http://svn.apache.org/viewvc?view=revrev=451902
Log:
skeleton for OpenJPA support
How baked is this? Should I be considering this for inclusion in the
release (in
The parent pom and buildtools are pre-reqs for all other Java
projects in the M2 release. These are distributed through the maven
repo rather than as a end-user distribution. Please vote to approve
the release content:
parent-pom
[tag]
401 - 500 of 1236 matches
Mail list logo
