You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Rick <cr...@gmail.com> on 2007/01/29 15:14:24 UTC
Compiling from java root
Just want to make sure I understand the consequences of compiling from
the java root with -Pall. As I understand it this shouldn't be an issue
and all should compile and test. The only consequence now is that the
projects under sca/kernel will not be used by the other projects for the
build and mvn unit test.
If working on the kernel I need to really do nothing different for
eclipse, except that it probable makes sense to have a separate
workspace for the kernel if I'm also working on some of the other
Tuscany parts.
Working on components other than the kernel, I need to import into
Eclipse only those projects not under sca/kernel and to debug the
kernel code import the code under branches\pre-spec-changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by Jim Marino <jm...@myromatours.com>.
On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
> Jeremy,
> thanks for your reply. A key time when this has become an issue
> for me is
> when applying patches. My general process has been to ensure I have a
> complete clean svn extraction, build it to see if there are any
> current
> issues in the trunk, inspect and apply the patch and build it
> again. If
> there are deltas in the error sets (hopefully the initial build's
> error set
> was empty) then there's an issue with the patch.
Shouldn't this be done using unit and integration tests, and not
against the entire trunk? For example, particular extensions may
reference different versions of SDO. I would imagine we need to be
able to accommodate a patch introducing API changes for a later
version than one referenced by a particular extension.
> This has meant in the past
> often even small patches still take an hour or so to apply.
Isn't that a problem in itself?
> Now that the
> trunk has significantly less chance of being stable this has become
> unworkable.
>
It has been my experience that the previous build structure was
unworkable since it did not allow extensions to evolve independently.
Solving this issue by modularizing unfortunately means an upstream
module cannot make assumptions about downstream modules, for example,
that they reference HEAD or a particular version and will compile
against it. The best solutions I have seen in the past to this
problem is extensive unit and integration tests in the upstream
module. If these are done right, it should be trivial to apply small
patches since they can be verified by the current build run.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
> Jeremy,
> thanks for your reply. A key time when this has become an issue
> for me is
> when applying patches. My general process has been to ensure I have a
> complete clean svn extraction, build it to see if there are any
> current
> issues in the trunk, inspect and apply the patch and build it
> again. If
> there are deltas in the error sets (hopefully the initial build's
> error set
> was empty) then there's an issue with the patch. This has meant in
> the past
> often even small patches still take an hour or so to apply. Now
> that the
> trunk has significantly less chance of being stable this has become
> unworkable.
Agreed. Sounds like the issue here though is that there is
insufficient test coverage in SDO so check whether or not a patch was
good. If SDO operates on the principle that its build is good
(including running tests as part of that build), then you can take a
working copy, apply the patch, rebuild and have confidence that the
build will remain good. That's very workable.
If something downstream breaks unexpectedly then it indicates that
there is a hole in the test coverage i.e. that downstream code was
doing something not clearly defined in the API contract. This is a
great opportunity to improve the API coverage to clarify this
interaction and either document the behvaiour (meaning the downstream
code needs to use the API correctly) or fix the implementation bug it
exposed.
>
> BTW, I saw that you posted a new snapshot of SDO a couple of days
> ago. I
> wasn't sure how best to choose when to post a new snapshot or how to
> communicate an imminent update. Is there a best practice for
> choosing when
> and how to deploy new snapshots?
In general, anyone should be able to redeploy a SNAPSHOT at any time
- some communities even do it automatically, say nightly. They are,
by definition, unstable versions. IIRC I did it because something was
trying to use SDO and either couldn't find the right version or had
problems with the online version.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by kelvin goodson <ke...@gmail.com>.
Jeremy,
thanks for your reply. A key time when this has become an issue for me is
when applying patches. My general process has been to ensure I have a
complete clean svn extraction, build it to see if there are any current
issues in the trunk, inspect and apply the patch and build it again. If
there are deltas in the error sets (hopefully the initial build's error set
was empty) then there's an issue with the patch. This has meant in the past
often even small patches still take an hour or so to apply. Now that the
trunk has significantly less chance of being stable this has become
unworkable.
BTW, I saw that you posted a new snapshot of SDO a couple of days ago. I
wasn't sure how best to choose when to post a new snapshot or how to
communicate an imminent update. Is there a best practice for choosing when
and how to deploy new snapshots?
Best Regards, Kelvin.
On 30/01/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> Rick just about covers it.
>
> The key thing is that downstream dependencies should be depending on
> SDO's published APIs and to avoid disruption to users you really
> don't want to be making incompatible changes to those APIs. Ideally
> there would be tests that exercised those APIs and you could rely on
> those to catch changes that break things.
I don't think that my concern was with instability with the SDO API, but
rather the implementation. It was the execution of the dependent project's
test cases that were adding information. The 2.1 API has been in place for a
while and unchanging, but some of the features not implemented. We are
expanding the test set within the build, and of course the community test
suite is developing well, but neither are yet at a stage where they give me
full confidence changes to the implementation don't cause adverse effects.
Relying on other modules in Tuscany to do this is a bad idea as they
> are likely only to exercise part of the SDO APIs. Even if they do
> break and you fix them, what about other code outside Tuscany?
Indeed, that's why I said that running a full build gave me a "warm
feeling". Running the tests alone is clearly a prereq, but there was
additional benefit in running the full build. Agreed there's lots of code
running outside the Tuscany build, but its not low hanging fruit for
increasing my state of confidence that a change has not introduced a bug.
Regarding the tools, there was talk in the past about moving them to
> SDO as they actually don't have anything to do with SCA. Doing that
> would mean they could easily be tested in conjunction with any SDO
> changes and released with SDO. Should we go ahead and do that?
>
> --
> Jeremy
>
> On Jan 30, 2007, at 5:39 AM, Rick wrote:
>
> > Kevin,
> > Be forewarned, I'm slightly fuzzy about how some things have been
> > separated out in the SCA build, but I'll try to answer. First of -
> > Pall from java root seems to be bad way to go all around. The
> > split in between the core(kernel) SCA and other extensions and
> > samples. Nothing in the kernel I'm pretty sure has any SDO
> > dependencies so you really don't need to test against the very HEAD
> > of those parts. The core is in two directories under java/sca
> > runtime and kernel.
> > These are published and like I said you don't need to test SDO
> > against them.
> >
> > For non core parts the are what is left in java\sca extensions,
> > plugins, services, and test. The theory is they should be using
> > the published (stable) kernel. These do have some SDO
> > dependencies, like the SDO databinding, and the maven tools that
> > help generate SDOs for wsdl2java. There is also samples that is
> > still in sampleapps which have SDO dependencies. As of right now I
> > think you have to manually issue a mvn build for these in each of
> > their respective directories.
> >
> >
> > kelvin goodson wrote:
> >> I've probably missed something in the mailing list here. Since
> >> profiles
> >> appeared in the top level pom the way I have been ensuring a
> >> change in SDO
> >> doesn't break modules that have dependencies on SDO is to run a
> >> mvn -Pall.
> >> I've done a bit of mailing list searching to find posts related to
> >> how these
> >> dependencies now work, but I haven't found anything definitive. I
> >> know we
> >> now have deployed snapshot versions of SDO and other modules.
> >> Whilst the
> >> set of SDO tests is building up, I don't yet have confidence that
> >> they will
> >> catch potential build breaks, so a full build of the trunk gave
> >> me a warm
> >> feeling that I wasn't going to break anything, but clearly this
> >> doesn't
> >> work any more. If I only run the SDO build and rely on the fact that
> >> upstream modules are insulated by depending on the snapshot then
> >> I'm just
> >> storing up troubles for the next time we post an SDO snapshot.
> >> Can someone
> >> help me to understand how I can change my build process to retain
> >> this level
> >> of confidence please?
> >> Regards, Kelvin.
> >> On 29/01/07, Jeremy Boynes <jb...@apache.org> wrote:
> >>>
> >>> On Jan 29, 2007, at 6:14 AM, Rick wrote:
> >>>
> >>> > Just want to make sure I understand the consequences of compiling
> >>> > from the java root with -Pall.
> >>>
> >>> As I understand it, there is no guarantee that that will work. If
> >>> you
> >>> do that you are trying to build using current SVN head from
> >>> independent modules - not only within SCA but also SDO and DAS.
> >>>
> >>> > As I understand it this shouldn't be an issue and all should
> >>> > compile and test. The only consequence now is that the projects
> >>> > under sca/kernel will not be used by the other projects for the
> >>> > build and mvn unit test.
> >>>
> >>> This is true at a module level but in a reactor build if two
> >>> versions
> >>> of a module exist then mvn will resolve to the latest one. Because
> >>> you include everything with -Pall, everything will resolve to the
> >>> latest unstable trunk and downstream modules are likely to fail.
> >>>
> >>> >
> >>> > If working on the kernel I need to really do nothing different for
> >>> > eclipse, except that it probable makes sense to have a separate
> >>> > workspace for the kernel if I'm also working on some of the other
> >>> > Tuscany parts.
> >>> >
> >>> > Working on components other than the kernel, I need to import into
> >>> > Eclipse only those projects not under sca/kernel and to debug the
> >>> > kernel code import the code under branches\pre-spec-changes.
> >>>
> >>> I have no idea what you need to do in Eclipse, but in general you
> >>> should be referencing the snapshot binaries of SDO, DAS, SCA Kernel
> >>> and such as defined by the dependency version, associating the
> >>> appropriate source code with those binaries.
> >>>
> >>> --
> >>> Jeremy
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Compiling from java root
Posted by Jeremy Boynes <jb...@apache.org>.
Rick just about covers it.
The key thing is that downstream dependencies should be depending on
SDO's published APIs and to avoid disruption to users you really
don't want to be making incompatible changes to those APIs. Ideally
there would be tests that exercised those APIs and you could rely on
those to catch changes that break things.
Relying on other modules in Tuscany to do this is a bad idea as they
are likely only to exercise part of the SDO APIs. Even if they do
break and you fix them, what about other code outside Tuscany?
Regarding the tools, there was talk in the past about moving them to
SDO as they actually don't have anything to do with SCA. Doing that
would mean they could easily be tested in conjunction with any SDO
changes and released with SDO. Should we go ahead and do that?
--
Jeremy
On Jan 30, 2007, at 5:39 AM, Rick wrote:
> Kevin,
> Be forewarned, I'm slightly fuzzy about how some things have been
> separated out in the SCA build, but I'll try to answer. First of -
> Pall from java root seems to be bad way to go all around. The
> split in between the core(kernel) SCA and other extensions and
> samples. Nothing in the kernel I'm pretty sure has any SDO
> dependencies so you really don't need to test against the very HEAD
> of those parts. The core is in two directories under java/sca
> runtime and kernel.
> These are published and like I said you don't need to test SDO
> against them.
>
> For non core parts the are what is left in java\sca extensions,
> plugins, services, and test. The theory is they should be using
> the published (stable) kernel. These do have some SDO
> dependencies, like the SDO databinding, and the maven tools that
> help generate SDOs for wsdl2java. There is also samples that is
> still in sampleapps which have SDO dependencies. As of right now I
> think you have to manually issue a mvn build for these in each of
> their respective directories.
>
>
> kelvin goodson wrote:
>> I've probably missed something in the mailing list here. Since
>> profiles
>> appeared in the top level pom the way I have been ensuring a
>> change in SDO
>> doesn't break modules that have dependencies on SDO is to run a
>> mvn -Pall.
>> I've done a bit of mailing list searching to find posts related to
>> how these
>> dependencies now work, but I haven't found anything definitive. I
>> know we
>> now have deployed snapshot versions of SDO and other modules.
>> Whilst the
>> set of SDO tests is building up, I don't yet have confidence that
>> they will
>> catch potential build breaks, so a full build of the trunk gave
>> me a warm
>> feeling that I wasn't going to break anything, but clearly this
>> doesn't
>> work any more. If I only run the SDO build and rely on the fact that
>> upstream modules are insulated by depending on the snapshot then
>> I'm just
>> storing up troubles for the next time we post an SDO snapshot.
>> Can someone
>> help me to understand how I can change my build process to retain
>> this level
>> of confidence please?
>> Regards, Kelvin.
>> On 29/01/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>
>>> On Jan 29, 2007, at 6:14 AM, Rick wrote:
>>>
>>> > Just want to make sure I understand the consequences of compiling
>>> > from the java root with -Pall.
>>>
>>> As I understand it, there is no guarantee that that will work. If
>>> you
>>> do that you are trying to build using current SVN head from
>>> independent modules - not only within SCA but also SDO and DAS.
>>>
>>> > As I understand it this shouldn't be an issue and all should
>>> > compile and test. The only consequence now is that the projects
>>> > under sca/kernel will not be used by the other projects for the
>>> > build and mvn unit test.
>>>
>>> This is true at a module level but in a reactor build if two
>>> versions
>>> of a module exist then mvn will resolve to the latest one. Because
>>> you include everything with -Pall, everything will resolve to the
>>> latest unstable trunk and downstream modules are likely to fail.
>>>
>>> >
>>> > If working on the kernel I need to really do nothing different for
>>> > eclipse, except that it probable makes sense to have a separate
>>> > workspace for the kernel if I'm also working on some of the other
>>> > Tuscany parts.
>>> >
>>> > Working on components other than the kernel, I need to import into
>>> > Eclipse only those projects not under sca/kernel and to debug the
>>> > kernel code import the code under branches\pre-spec-changes.
>>>
>>> I have no idea what you need to do in Eclipse, but in general you
>>> should be referencing the snapshot binaries of SDO, DAS, SCA Kernel
>>> and such as defined by the dependency version, associating the
>>> appropriate source code with those binaries.
>>>
>>> --
>>> Jeremy
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by Rick <cr...@gmail.com>.
Kevin,
Be forewarned, I'm slightly fuzzy about how some things have been separated out
in the SCA build, but I'll try to answer. First of -Pall from java root seems
to be bad way to go all around. The split in between the core(kernel) SCA and
other extensions and samples. Nothing in the kernel I'm pretty sure has any SDO
dependencies so you really don't need to test against the very HEAD of those
parts. The core is in two directories under java/sca runtime and kernel.
These are published and like I said you don't need to test SDO against them.
For non core parts the are what is left in java\sca extensions, plugins,
services, and test. The theory is they should be using the published (stable)
kernel. These do have some SDO dependencies, like the SDO databinding, and the
maven tools that help generate SDOs for wsdl2java. There is also samples that
is still in sampleapps which have SDO dependencies. As of right now I think you
have to manually issue a mvn build for these in each of their respective
directories.
kelvin goodson wrote:
> I've probably missed something in the mailing list here. Since profiles
> appeared in the top level pom the way I have been ensuring a change in SDO
> doesn't break modules that have dependencies on SDO is to run a mvn -Pall.
> I've done a bit of mailing list searching to find posts related to how
> these
> dependencies now work, but I haven't found anything definitive. I know we
> now have deployed snapshot versions of SDO and other modules. Whilst the
> set of SDO tests is building up, I don't yet have confidence that they will
> catch potential build breaks, so a full build of the trunk gave me a warm
> feeling that I wasn't going to break anything, but clearly this doesn't
> work any more. If I only run the SDO build and rely on the fact that
> upstream modules are insulated by depending on the snapshot then I'm just
> storing up troubles for the next time we post an SDO snapshot. Can someone
> help me to understand how I can change my build process to retain this
> level
> of confidence please?
>
> Regards, Kelvin.
>
> On 29/01/07, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Jan 29, 2007, at 6:14 AM, Rick wrote:
>>
>> > Just want to make sure I understand the consequences of compiling
>> > from the java root with -Pall.
>>
>> As I understand it, there is no guarantee that that will work. If you
>> do that you are trying to build using current SVN head from
>> independent modules - not only within SCA but also SDO and DAS.
>>
>> > As I understand it this shouldn't be an issue and all should
>> > compile and test. The only consequence now is that the projects
>> > under sca/kernel will not be used by the other projects for the
>> > build and mvn unit test.
>>
>> This is true at a module level but in a reactor build if two versions
>> of a module exist then mvn will resolve to the latest one. Because
>> you include everything with -Pall, everything will resolve to the
>> latest unstable trunk and downstream modules are likely to fail.
>>
>> >
>> > If working on the kernel I need to really do nothing different for
>> > eclipse, except that it probable makes sense to have a separate
>> > workspace for the kernel if I'm also working on some of the other
>> > Tuscany parts.
>> >
>> > Working on components other than the kernel, I need to import into
>> > Eclipse only those projects not under sca/kernel and to debug the
>> > kernel code import the code under branches\pre-spec-changes.
>>
>> I have no idea what you need to do in Eclipse, but in general you
>> should be referencing the snapshot binaries of SDO, DAS, SCA Kernel
>> and such as defined by the dependency version, associating the
>> appropriate source code with those binaries.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by kelvin goodson <ke...@gmail.com>.
I've probably missed something in the mailing list here. Since profiles
appeared in the top level pom the way I have been ensuring a change in SDO
doesn't break modules that have dependencies on SDO is to run a mvn -Pall.
I've done a bit of mailing list searching to find posts related to how these
dependencies now work, but I haven't found anything definitive. I know we
now have deployed snapshot versions of SDO and other modules. Whilst the
set of SDO tests is building up, I don't yet have confidence that they will
catch potential build breaks, so a full build of the trunk gave me a warm
feeling that I wasn't going to break anything, but clearly this doesn't
work any more. If I only run the SDO build and rely on the fact that
upstream modules are insulated by depending on the snapshot then I'm just
storing up troubles for the next time we post an SDO snapshot. Can someone
help me to understand how I can change my build process to retain this level
of confidence please?
Regards, Kelvin.
On 29/01/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Jan 29, 2007, at 6:14 AM, Rick wrote:
>
> > Just want to make sure I understand the consequences of compiling
> > from the java root with -Pall.
>
> As I understand it, there is no guarantee that that will work. If you
> do that you are trying to build using current SVN head from
> independent modules - not only within SCA but also SDO and DAS.
>
> > As I understand it this shouldn't be an issue and all should
> > compile and test. The only consequence now is that the projects
> > under sca/kernel will not be used by the other projects for the
> > build and mvn unit test.
>
> This is true at a module level but in a reactor build if two versions
> of a module exist then mvn will resolve to the latest one. Because
> you include everything with -Pall, everything will resolve to the
> latest unstable trunk and downstream modules are likely to fail.
>
> >
> > If working on the kernel I need to really do nothing different for
> > eclipse, except that it probable makes sense to have a separate
> > workspace for the kernel if I'm also working on some of the other
> > Tuscany parts.
> >
> > Working on components other than the kernel, I need to import into
> > Eclipse only those projects not under sca/kernel and to debug the
> > kernel code import the code under branches\pre-spec-changes.
>
> I have no idea what you need to do in Eclipse, but in general you
> should be referencing the snapshot binaries of SDO, DAS, SCA Kernel
> and such as defined by the dependency version, associating the
> appropriate source code with those binaries.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Compiling from java root
Posted by haleh mahbod <hm...@gmail.com>.
I added this to FAQ (
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+-+FAQ)
Please update the link if additional info needs to be added.
On 1/29/07, Rick <cr...@gmail.com> wrote:
>
> Ok, I had a momentary mental block that 0.1-pre-spec-SNAPSHOT is a ...
> SNAPSHOT.
> So the difference in prefix of the versions "0.1-pre-spec-" and
> "1.0-incubator" will have no bearing when done from the top and I'll just
> get
> the latest of the trunk of all; which we know can be out of sync.
>
> Sorry before hand if I'm dwelling on the obvious, but I hope his may help
> others
> too:
>
> To compile and work on the latest kernel, I need to build these projects
> from
> the trunk: (they are part of pre-spec-changes)
> kernel
> runtime
> services
> test
>
> And for non-kernel
> extensions
> plugins
>
> Maybe we can have profiles for this like -Pall to make it easier ?
>
> To be safe if I'm working between these two, do I need to keep a separate
> repo?
> Or does the prefix difference help out there ?
>
> Thanks
>
> Jeremy Boynes wrote:
> > On Jan 29, 2007, at 6:14 AM, Rick wrote:
> >
> >> Just want to make sure I understand the consequences of compiling from
> >> the java root with -Pall.
> >
> > As I understand it, there is no guarantee that that will work. If you do
> > that you are trying to build using current SVN head from independent
> > modules - not only within SCA but also SDO and DAS.
> >
> >> As I understand it this shouldn't be an issue and all should compile
> >> and test. The only consequence now is that the projects under
> >> sca/kernel will not be used by the other projects for the build and
> >> mvn unit test.
> >
> > This is true at a module level but in a reactor build if two versions of
> > a module exist then mvn will resolve to the latest one. Because you
> > include everything with -Pall, everything will resolve to the latest
> > unstable trunk and downstream modules are likely to fail.
> >
> >>
> >> If working on the kernel I need to really do nothing different for
> >> eclipse, except that it probable makes sense to have a separate
> >> workspace for the kernel if I'm also working on some of the other
> >> Tuscany parts.
> >>
> >> Working on components other than the kernel, I need to import into
> >> Eclipse only those projects not under sca/kernel and to debug the
> >> kernel code import the code under branches\pre-spec-changes.
> >
> > I have no idea what you need to do in Eclipse, but in general you should
> > be referencing the snapshot binaries of SDO, DAS, SCA Kernel and such as
> > defined by the dependency version, associating the appropriate source
> > code with those binaries.
> >
> > --
> > Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Compiling from java root
Posted by Rick <cr...@gmail.com>.
Ok, I had a momentary mental block that 0.1-pre-spec-SNAPSHOT is a ... SNAPSHOT.
So the difference in prefix of the versions "0.1-pre-spec-" and
"1.0-incubator" will have no bearing when done from the top and I'll just get
the latest of the trunk of all; which we know can be out of sync.
Sorry before hand if I'm dwelling on the obvious, but I hope his may help others
too:
To compile and work on the latest kernel, I need to build these projects from
the trunk: (they are part of pre-spec-changes)
kernel
runtime
services
test
And for non-kernel
extensions
plugins
Maybe we can have profiles for this like -Pall to make it easier ?
To be safe if I'm working between these two, do I need to keep a separate repo?
Or does the prefix difference help out there ?
Thanks
Jeremy Boynes wrote:
> On Jan 29, 2007, at 6:14 AM, Rick wrote:
>
>> Just want to make sure I understand the consequences of compiling from
>> the java root with -Pall.
>
> As I understand it, there is no guarantee that that will work. If you do
> that you are trying to build using current SVN head from independent
> modules - not only within SCA but also SDO and DAS.
>
>> As I understand it this shouldn't be an issue and all should compile
>> and test. The only consequence now is that the projects under
>> sca/kernel will not be used by the other projects for the build and
>> mvn unit test.
>
> This is true at a module level but in a reactor build if two versions of
> a module exist then mvn will resolve to the latest one. Because you
> include everything with -Pall, everything will resolve to the latest
> unstable trunk and downstream modules are likely to fail.
>
>>
>> If working on the kernel I need to really do nothing different for
>> eclipse, except that it probable makes sense to have a separate
>> workspace for the kernel if I'm also working on some of the other
>> Tuscany parts.
>>
>> Working on components other than the kernel, I need to import into
>> Eclipse only those projects not under sca/kernel and to debug the
>> kernel code import the code under branches\pre-spec-changes.
>
> I have no idea what you need to do in Eclipse, but in general you should
> be referencing the snapshot binaries of SDO, DAS, SCA Kernel and such as
> defined by the dependency version, associating the appropriate source
> code with those binaries.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Compiling from java root
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 29, 2007, at 6:14 AM, Rick wrote:
> Just want to make sure I understand the consequences of compiling
> from the java root with -Pall.
As I understand it, there is no guarantee that that will work. If you
do that you are trying to build using current SVN head from
independent modules - not only within SCA but also SDO and DAS.
> As I understand it this shouldn't be an issue and all should
> compile and test. The only consequence now is that the projects
> under sca/kernel will not be used by the other projects for the
> build and mvn unit test.
This is true at a module level but in a reactor build if two versions
of a module exist then mvn will resolve to the latest one. Because
you include everything with -Pall, everything will resolve to the
latest unstable trunk and downstream modules are likely to fail.
>
> If working on the kernel I need to really do nothing different for
> eclipse, except that it probable makes sense to have a separate
> workspace for the kernel if I'm also working on some of the other
> Tuscany parts.
>
> Working on components other than the kernel, I need to import into
> Eclipse only those projects not under sca/kernel and to debug the
> kernel code import the code under branches\pre-spec-changes.
I have no idea what you need to do in Eclipse, but in general you
should be referencing the snapshot binaries of SDO, DAS, SCA Kernel
and such as defined by the dependency version, associating the
appropriate source code with those binaries.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org