You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/02/21 20:15:18 UTC
Remove pom in tuscany/java
This one:
https://svn.apache.org/repos/asf/incubator/tuscany/java/pom.xml
This is no longer used as the parent for any of the modules and the
profiles it contains are no longer valid so it does not really serve
any purpose. I'd propose we remove it ...
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 21, 2007, at 12:50 PM, Luciano Resende wrote:
> If we follow the pattern we have been using for SDO, DAS, once we
> build the
> project, the samples are built together to make sure changes on the
> core
> didn't break functionality used by the samples. In the case of
> SCA, don't
> we want to do the same, and when building sca, we would build the
> samples as
> well ? (e.g java/sca, java/samples/sca and java/distribution/
> sca)... While
> we still don't have the ideal unit/integration tests that would
> exercise all
> our scenarios, the sample applications have always a good source to
> help as
> improve quality in the project.
>
> Maybe one solution would be to have those items moved to inside the
> sca
> project.
We decided a while back to move samples and tests into their modules.
There are two modules under sca already for testing the baseline:
integration-test
core-samples
I think the issue stems from the idea of "building sca" - "sca" isn't
a module or a distribution; instead we have a whole collection of
modules under there (kernel, runtime, etc.) that can be built and
distributed independently.
Integration testing is about testing integration - not just between
modules in the build but also about integration with platforms. When
doing a release we would want to verify that *identical*
distributions work in different environments. That means integration
testing is not about what was built on your local machine but that a
candidate distribution someone else built works in the environments
you are testing. The monolithic profile builds don't support this.
The same with samples. It's not enough to know that a sample runs,
it's important to know that it runs if the user follows the
instructions. Users typically don't have the source code on their
machine, they typically use a downloaded binary distribution; they
typically don't have artifacts in their local repo so its important
to know that the artifacts they will be downloading are consistent.
Again, the monolithic builds don't support this either.
Having the profiles there encourages bad behaviour on our part in
that the longer we keep building as a monolith the further away we
remain from the user experience.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Luciano Resende <lu...@gmail.com>.
If we follow the pattern we have been using for SDO, DAS, once we build the
project, the samples are built together to make sure changes on the core
didn't break functionality used by the samples. In the case of SCA, don't
we want to do the same, and when building sca, we would build the samples as
well ? (e.g java/sca, java/samples/sca and java/distribution/sca)... While
we still don't have the ideal unit/integration tests that would exercise all
our scenarios, the sample applications have always a good source to help as
improve quality in the project.
Maybe one solution would be to have those items moved to inside the sca
project.
--
Luciano Resende
http://people.apache.org/~lresende
On 2/21/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Feb 21, 2007, at 11:31 AM, Luciano Resende wrote:
>
> > Hi Jeremy
> >
> > Wouldn't we still have scenarios where we would like to build
> > multiple
> > projects from the Tuscany project root ? (e.g sca and samples/sca or
> > sca/sca-api-r1.0 and kernel). If so, the profiles inside java/pom.xml
> > should be way to go, no ?
>
> I don't think so, no.
>
> If we're doing that all the time then it implies that the modules are
> coupled together and that's a problem that should be solved by
> explicitly bundling those modules together into one or by managing
> the relationship between the modules better (i.e. keeping the
> interfaces compatible).
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Remove pom in tuscany/java
Posted by Rick Rineholt <cr...@gmail.com>.
Maybe I missed it, but is this documented today how to do this? What
modules to build for the kernel? For extensions? I recall I started to
help on a wiki page but can't seem to locate it now. I think I stopped
since even I got a bit confused on it. Can I ask where this is? And
is it current? Thanks
Jean-Sebastien Delfino wrote:
> Jeremy Boynes wrote:
>> On Feb 21, 2007, at 1:25 PM, Raymond Feng wrote:
>>
>>> So are you going to publish SNAPSHOT versions of the different
>>> modules to maven repo all the time? I assume the published artifacts
>>> are the dependencies used by modules. Otherwise, those who want to
>>> play with the source code won't have a good clue to build modules by
>>> the right order.
>>
>> All the time no, but certainly frequently (i.e. whenever something
>> significant changes).
>>
>> The goal is to support people who want to "play with the source code"
>> without requiring them to build everything as we have seen that that
>> is fragile and does not work. Most such people will start with an
>> extension module (like a fractal container or a REST binding) and so
>> we need to ensure the dependencies they need (primarily the kernel)
>> are published and available.
>>
>> For example, once we review and release the spec jar, *it should
>> never change* until the next release of the spec. The same with the
>> kernel apis/spis - the things extensions should depend on - although
>> the implementation of them (tuscany-core) may rev faster.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> I share Raymond's concerns. I find top-down builds with profiles
> listing the modules that work together very useful. This allows people
> to simply do svn co sca, mvn, and get a good build with jars in sync
> with the source. One more command, mvn -Peclipse eclipse:eclipse to
> get the whole source loaded in an Eclipse workspace (or the Idea
> equivalent command), and you're ready to do some work.
>
> Having to go into each module directory to build them individually, in
> a specific order, or with dependencies on external JARs with no simple
> way to generate a consistent IDE workspace with the correct level of
> source attached to the JARs is very error prone and confusing. This
> approach just does not work for me.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> On Feb 21, 2007, at 1:25 PM, Raymond Feng wrote:
>
>> So are you going to publish SNAPSHOT versions of the different
>> modules to maven repo all the time? I assume the published artifacts
>> are the dependencies used by modules. Otherwise, those who want to
>> play with the source code won't have a good clue to build modules by
>> the right order.
>
> All the time no, but certainly frequently (i.e. whenever something
> significant changes).
>
> The goal is to support people who want to "play with the source code"
> without requiring them to build everything as we have seen that that
> is fragile and does not work. Most such people will start with an
> extension module (like a fractal container or a REST binding) and so
> we need to ensure the dependencies they need (primarily the kernel)
> are published and available.
>
> For example, once we review and release the spec jar, *it should never
> change* until the next release of the spec. The same with the kernel
> apis/spis - the things extensions should depend on - although the
> implementation of them (tuscany-core) may rev faster.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I share Raymond's concerns. I find top-down builds with profiles listing
the modules that work together very useful. This allows people to simply
do svn co sca, mvn, and get a good build with jars in sync with the
source. One more command, mvn -Peclipse eclipse:eclipse to get the whole
source loaded in an Eclipse workspace (or the Idea equivalent command),
and you're ready to do some work.
Having to go into each module directory to build them individually, in a
specific order, or with dependencies on external JARs with no simple way
to generate a consistent IDE workspace with the correct level of source
attached to the JARs is very error prone and confusing. This approach
just does not work for me.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 21, 2007, at 1:25 PM, Raymond Feng wrote:
> So are you going to publish SNAPSHOT versions of the different
> modules to maven repo all the time? I assume the published
> artifacts are the dependencies used by modules. Otherwise, those
> who want to play with the source code won't have a good clue to
> build modules by the right order.
All the time no, but certainly frequently (i.e. whenever something
significant changes).
The goal is to support people who want to "play with the source code"
without requiring them to build everything as we have seen that that
is fragile and does not work. Most such people will start with an
extension module (like a fractal container or a REST binding) and so
we need to ensure the dependencies they need (primarily the kernel)
are published and available.
For example, once we review and release the spec jar, *it should
never change* until the next release of the spec. The same with the
kernel apis/spis - the things extensions should depend on - although
the implementation of them (tuscany-core) may rev faster.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Raymond Feng <en...@gmail.com>.
So are you going to publish SNAPSHOT versions of the different modules to
maven repo all the time? I assume the published artifacts are the
dependencies used by modules. Otherwise, those who want to play with the
source code won't have a good clue to build modules by the right order.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, February 21, 2007 12:05 PM
Subject: Re: Remove pom in tuscany/java
> On Feb 21, 2007, at 11:31 AM, Luciano Resende wrote:
>
>> Hi Jeremy
>>
>> Wouldn't we still have scenarios where we would like to build multiple
>> projects from the Tuscany project root ? (e.g sca and samples/sca or
>> sca/sca-api-r1.0 and kernel). If so, the profiles inside java/pom.xml
>> should be way to go, no ?
>
> I don't think so, no.
>
> If we're doing that all the time then it implies that the modules are
> coupled together and that's a problem that should be solved by explicitly
> bundling those modules together into one or by managing the relationship
> between the modules better (i.e. keeping the interfaces compatible).
>
> --
> 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: Remove pom in tuscany/java
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 21, 2007, at 11:31 AM, Luciano Resende wrote:
> Hi Jeremy
>
> Wouldn't we still have scenarios where we would like to build
> multiple
> projects from the Tuscany project root ? (e.g sca and samples/sca or
> sca/sca-api-r1.0 and kernel). If so, the profiles inside java/pom.xml
> should be way to go, no ?
I don't think so, no.
If we're doing that all the time then it implies that the modules are
coupled together and that's a problem that should be solved by
explicitly bundling those modules together into one or by managing
the relationship between the modules better (i.e. keeping the
interfaces compatible).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remove pom in tuscany/java
Posted by Luciano Resende <lu...@gmail.com>.
Hi Jeremy
Wouldn't we still have scenarios where we would like to build multiple
projects from the Tuscany project root ? (e.g sca and samples/sca or
sca/sca-api-r1.0 and kernel). If so, the profiles inside java/pom.xml
should be way to go, no ?
--
Luciano Resende
http://people.apache.org/~lresende
On 2/21/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> This one:
> https://svn.apache.org/repos/asf/incubator/tuscany/java/pom.xml
>
> This is no longer used as the parent for any of the modules and the
> profiles it contains are no longer valid so it does not really serve
> any purpose. I'd propose we remove it ...
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>