Hi,
Please see more comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, March 22, 2007 9:13 AM
Subject: RE: Compilation status
Raymond,
I think in this specific scenario, we were trying to build an assembly
from different components. This included the kernel, standalone server,
a discovery implementation, amanagement implementation, one of the
sample applications etc. I don't think having a single maven POM that
included all the modules for all the artifacts being assembled would
have been practically feasible. In such scenarios, IMO, an assembly is
exactly what we need. It is assembling a distribution from a set of
components that have already been built. We can't expect the assembly to
build all the components it assembles. Howabout, the transitive
dependencies for those components? Would we get the assembly build to
build them as well?
<rfeng>
Distribution seems to be the place to assemble components to form a
meaningful bundle. But the problem is that the current assembly only create
binaries which are not ideal for fast-moving code.
Why don't we create a pom.xml per assembly to include the source modules
from Tuscany for that bundle? The source modules can be at different levels,
for example, we can point to tagged source for the sca-api-r1.0 and point to
trunk for other unreleased modules. This way, we can build Tuscany modules
per assembly without breaking the modularity story.
For transitive dependencies, I assume you were talking about external
artifacts used by Tuscany modules. But remember, usually they are released
(even for SNAPSHOTs which we should avoid, they are published). I don't see
a need to build them by Tuscany.
</rfeng>
From, my experience in the last two months, I haven't found the lack of
a pom that included all the modules to be built, an inhibiting factor.
Rather, I had a clear picture of what artifacts I wanted for the task I
was doing and built them individually or depended on published
snapshots. As the system grows in complexity it is difficult to have
everything built in one go. That would be introducing unnecessary
coupling. My personal view would be to build related components
together, like the kernel pom including SPI, core, host-api etc and
runtime building standalone, runtime services etc.
<rfeng>
It's good to hear that you all like to build related components together.
What's related has different meanings for different perspetives. If I only
work on the kernel, then the kernel top-down build would be sufficient. If I
want to use the demo bundle, I would say all the modules in that bundle are
related.
I'm really concerned by the user experiences (incuding even some
developers). If you feel the current situation not inhibiting, why did it
take poor guys like Mario to spend two days to just get everything he wants
to try compiled? Not many folks will continue if it happens to them, so I
have to praise Mario for his devotion.
</rfeng>
Thanks
Meeraj
-----Original Message-----
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 3:50 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Compilation status
Hi,
I hate to bring up this issue again, but I really share the pain that
Mario just went through. Don't we think we have room for improvements to
build the stuff in a much simpler fashion? To me, to have a build for a
bundle which consists of a set of the modules working together at the
same level would be really helpful for the poor guys. It's very
difficult to manually coordinate the build across modules even with
published SNAPSHOTs (which I don't see it happens frequently and it's
also very hard because a collection of SNAPSHOTs don't really establish
a baseline for those who want to try the latest code).
I (assume that I) understand all the rationales and pricinples for
modulization. But I'm really scared by the user experiences. Where is
the reasonable middle ground?
Thanks,
Raymond
----- Original Message -----
From: "Antollini, Mario" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, March 22, 2007 6:57 AM
Subject: RE: Compilation status
Meeraj,
Finally, I was able to generate the server.star.jar file.
This is compilation order that worked for me:
java/spec/commonj/
java/spec/sca-api-r1.0/
java/sca/kernel/
java/sca/runtime/
java/sca/services/
java/sca/contrib/discovery/
java/sca/contrib/discovery/jms
java/sca/console/
java/sca/core-samples/
java/distribution/sca/demo.app
java/distribution/sca/demo/
Disclaimer: I have been struggling with the compilation for two days, I
cannot fully assure that the order of the above list is the actual
order. If anyone is able to compile this exact way, please let us know.
BTW, java/sca/extensions/ cannot be compiled for now.
Besides the good news, I was not able to start the servers (take a look
at the attachment to see the errors)
Do you have any idea what could be happening?
Thanks and regards,
Mario
-----Original Message-----
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 10:13 AM
To: tuscany-dev@ws.apache.org
Subject: RE: Compilation status
Mario,
AFAIK extensions in trunk is still in a bit of a flux. If you want to
run the demo, you don't need to run the extensions (the demo uses Java
container with local bindings), I will try to post a dfeinitive list of
tasks to build and run the demo later in the day, which will be useful
to Simon as well.
Ta
Meeraj
-----Original Message-----
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 12:29 PM
To: tuscany-dev@ws.apache.org
Subject: Compilation status
Meeraj,
I just wanted you to know that I am still not able to compile the code I
checked out from SVN. The main problem is located in the *extensions*
project. I have been modifying the pom files within this project but I
did not manage to get it compiled yet.
Basically, the main problems are related to inconsistencies between
parent references (e.g.; axis2's root project is using groupId
*org.apache.tuscany.sca.axis2* while the plugin subproject states that
its parent is *org.apache.tuscany.sca.extensions.axis2*).
Any tips about this?
Thanks,
Mario
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom
VAT No. 226 6112 87
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
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]
This message has been checked for all email viruses by MessageLabs.
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
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]