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/03/22 18:10:35 UTC
Build structure - having cake and still eating
We know from M2 experience and the number of "profiles" in the
integration branch that a top-down, build-everything approach does
not work.
We also know from practical experience that people struggle building
modules.
I believe there is a middle ground that supports both approaches;
* have a flat module structure that allows any module to be built on
its own
using dependencies from the mvn repos
* have particular assemblies that pull modules together into whatever
bundles
people want. The assemblies can use released modules from mvn,
snapshot
modules from mvn, a copy of any revision of that module, or can track
trunk using svn externals
An example of this is the assembly I used for the tag for the TSSS
demo code which uses a combination of released artifacts and known
revisions.
This gives module developers their own space to work in, and allows
people consuming those modules to choose how stable the code they
want to use is (from released through to head).
Hopefully this will provide a middle ground we are all comfortable with.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Raymond Feng <en...@gmail.com>.
The svn:externals property seems to be very powerful since it can link to
different revisions for sources from different SVN locations. This way, we
can reference a particular revision in some cases.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, March 22, 2007 10:34 AM
Subject: Re: Build structure - having cake and still eating
> On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
>
>> +1.
>>
>> I think it's in line with the proposal in my response to Meeraj.
>>
>> One question: For a bundle to reference a module in the Tuscany source
>> tree, do we really have to copy (or use svn:externals property) if it
>> points to a location (under trunk, tags, or branches) in the Tuscany
>> tree? I think a relative path for the <module> will work.
>
> It will.
>
> The difference would be that with a ../.. type relative path someone
> can't just check out the assembly module, they need to check out the
> whole tree from some common root. With an external they could just check
> out the assembly module and the source for the dependency would be
> checked out as well. Of course, then they might have multiple copies of
> the dependency source to manage.
>
> Either works and it would up to the users of the assembly module to
> choose which style they prefer.
>
> --
> 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: Build structure - having cake and still eating
Posted by Simon Laws <si...@googlemail.com>.
On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> > Jeremy. This sounds like a simpler approach than what is there now.
> > I like
> > the idea but a question.
> >
> > 1) move everything that does not logical depend on
> > org.apache.tuscany:sca:1.0-incubating to contrib
> >
> > from your previous definition do you mean those things that are not
> > considered to be independent. Or do you mean things that could be
> > independent but just aren't packaged that way now. I assume that
> > you mean
> > the latter as your next point is to go ahead and make them
> > independent.
>
> Yes things aren't really independent due to the intermediate poms in
> the physical directory tree.
>
> >
> > Also is the global parent version 1.0-incubating or 1.0-incubating-
> > SNAPSHOT.
> > I note that now you have it without SNAPSHOT but its children with
> > SNAPSHOT.
> > Are you just saying that the global parent doesn't get packaged/
> > released
> > per-se SNAPSHOT or not.
>
> This is the pom defined in the tag here:
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
> sca/1.0-incubating
>
> which is a stable artifact - one we have voted to release but are
> waiting for the IPMC to approve. It will not move.
>
> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
> THREAD]]
> http://mail-archives.apache.org/mod_mbox/incubator-general/
> 200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
>
> The things in trunk are not stable and so have a SNAPSHOT version.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ok, I get it. Thanks Jemery.
S
Re: Build structure - having cake and still eating
Posted by ant elder <an...@gmail.com>.
On 3/24/07, ant elder <an...@gmail.com> wrote:
>
>
>
> On 3/24/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > OK, I give up on this, and I'll try not bring this subject up anymore
> > !!!
>
>
> Don't give up, its important to get to the build we think is the best for
> Tuscany.
>
> I think the crux of the problem was said in the previous email - we can't
> see how to make what we want work with independently versioned modules.
>
> So are "independently versioned modules" worth it?
>
> Given all the past threads debating this, all the confusion and trouble
> users and developers have been having, and the current state of the project
> and community, how about we put independently versioned modules as a TODO to
> look at in the future when things are more clear and stable, and for now go
> back to a single version and a project you can build from the top with mvn?
>
Discussion on this seems to have died down so I'm going to call a vote so we
have closure on this for the next release. I'll leave it a couple more days
to see if anything else comes up but given the whats been said i think the
vote will be along the lines of having a single version for everything in
java/sca and pom.xml that enables all that to be built from the top with
mvn.
...ant
Re: Build structure - having cake and still eating
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to move back to "single version and a project you can build from
the top with mvn"
On 3/23/07, ant elder <an...@gmail.com> wrote:
> On 3/24/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > OK, I give up on this, and I'll try not bring this subject up anymore !!!
>
>
> Don't give up, its important to get to the build we think is the best for
> Tuscany.
>
> I think the crux of the problem was said in the previous email - we can't
> see how to make what we want work with independently versioned modules.
>
> So are "independently versioned modules" worth it?
>
> Given all the past threads debating this, all the confusion and trouble
> users and developers have been having, and the current state of the project
> and community, how about we put independently versioned modules as a TODO to
> look at in the future when things are more clear and stable, and for now go
> back to a single version and a project you can build from the top with mvn?
>
> ...ant
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by ant elder <an...@gmail.com>.
On 3/24/07, Luciano Resende <lu...@gmail.com> wrote:
>
> OK, I give up on this, and I'll try not bring this subject up anymore !!!
Don't give up, its important to get to the build we think is the best for
Tuscany.
I think the crux of the problem was said in the previous email - we can't
see how to make what we want work with independently versioned modules.
So are "independently versioned modules" worth it?
Given all the past threads debating this, all the confusion and trouble
users and developers have been having, and the current state of the project
and community, how about we put independently versioned modules as a TODO to
look at in the future when things are more clear and stable, and for now go
back to a single version and a project you can build from the top with mvn?
...ant
Re: Build structure - having cake and still eating
Posted by Luciano Resende <lu...@gmail.com>.
OK, I give up on this, and I'll try not bring this subject up anymore !!!
I'll continue with my hijacked java/pom.xml and update it as needed, I just
feel sorry for the new people that will come to the Tuscany community and
will fill the same pain as Mario and others.
Just in case others might benefit from this, here are the profiles I have in
my hijacked java/pom.xml that is working at the moment and building sca or
sdo or das.
<profiles>
<!-- profile to build sdo -->
<profile>
<id>sdo</id>
<modules>
<module>sdo</module>
</modules>
</profile>
<!-- profile to build das -->
<profile>
<id>das</id>
<modules>
<module>das</module>
</modules>
</profile>
<!-- profile to build sca -->
<profile>
<id>sca</id>
<modules>
<!-- support modules -->
<module>pom/parent</module>
<module>pom/sca</module>
<module>buildtools</module>
<!-- spec -->
<module>spec/sca-api-r1.0</module>
<!-- sca modules -->
<module>sca/kernel</module>
<module>sca/runtime</module>
<module>sca/services</module>
<module>sca/console</module>
<module>sca/jms-discovery</module>
<module>sca/http.jetty</module>
<!-- samples -->
<module>sca/core-samples</module>
<module>sca/core-samples/standalone/calculator</module>
<module>sca/core-samples/standalone/loanapplication</module>
<!-- integration tests -->
<module>sca/integration-test</module>
<!-- unstbale modules that are left out of the build
<module>sca/core-samples/webapp/webcalc</module>
-->
</modules>
</profile>
</profiles>
--
Luciano Resende
http://people.apache.org/~lresende
On 3/23/07, Jeremy Boynes <jb...@apache.org> wrote:
>
>
> On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote:
>
> > Jeremy
> >
> > So, having these assemblies modules sounded interesting to me
> > until the
> > moment you said you want to base them on deployed artifacts... we
> > have never
> > had a habit of publishing SNAPSHOTS for all possible artifacts, and
> > even the
> > members of the community that are proposing this approach are
> > failing to
> > deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this.
>
> Ideally the deployed artifacts they would depend on would be stable
> released ones - this is directly inline with the stability goals
> expressed by the likes of Dave Booz. In general, aggregations should
> not depend on SNAPSHOTs or a head revision except where absolutely
> necessary.
>
> Mario's pain was caused because we had not put together an assembly
> of the modules needed for the demo. It was the wee hours of the
> morning, I hope you understand. Once the dust settled, the modular,
> independent nature of what we had allowed us to put together a very
> simple assembly for building exactly that (independent of any other
> activity in trunk). You can see this here:
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss-
> demo
>
> >
> > You also mentioned before that we have M2 experience of a top
> > down build
> > not working, I'm not sure about all the details that comes to your
> > mind when
> > you say that, but I remember some build brakes (and I think this is
> > acceptable in trunk, right ?)
>
> No, not really.
>
> > and we could set some conventions like,
> > modules that are "unstable at the moment" would be removed from the
> > maven
> > profile (and maybe a JIRA would be created)... later on, when the
> > module is
> > back to it's stability, whoever fixed the issue would close the
> > JIRA (if
> > any) and put the module back to the stable profile.
>
> The problem of this approach is that it couples everything together
> through the parent pom. Even if a separate parent is used, the
> reactor will attempt to use common dependency versions across the
> modules. This means that modules get coupled together based on the
> versions of their dependencies and so we lose the independence
> between them.
>
> Basically, unless they all use the same version then they won't all
> build.
>
> >
> > Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure
> > both can
> > co-exist together in perfect harmony, and it would definitely be a
> > good
> > solution for members of the community that are interested only in a
> > subset
> > of Tuscany (e.g some embedder that only requires the kernel, and a
> > Spring
> > extension for example), and these assembly modules could be created as
> > needed
> >
> > These profiles would probably make the user experience of someone
> > that
> > comes to evaluate Tuscany trunk much easier, as already mentioned
> > by Mario
> > [1], and help others to be more productive as already expressed on
> > various
> > other threads [2][3].
>
> This is where we disagree. Doing what you suggest couples all modules
> at a single monolithic version level. That may be desirable in a
> commercial product but is not a way to scale an open source community.
>
> One of the problems we have is that the documentation on the build
> and the pom structure is misleading and confusing users. I wanted to
> clean that up by removing bad poms such as java/pom.xml but was
> overruled.
>
> >
> > If I understand your concerns, having the convention of moving
> > unstable
> > modules out of the maven profile should help, but maybe you could
> > explain
> > what worries you, that you are fighting so hard not to allow people
> > to build
> > different modules with a simple mvn command. Nevertheless, it's good
> > practice to build before committ, right ?
>
> Please can we not make this personal - I am not fighting hard not to
> allow anything. I am trying to find a middle ground that allows
> people who need to build groups of modules to do so and at the same
> time preserve the independence between the modules.
>
> I do not know of a way to make what you want work with independently
> versioned modules. I have proposed something that people seemed to be
> able to live with and which I believe works. Let's hear technically
> viable alternatives.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote:
> Jeremy
>
> So, having these assemblies modules sounded interesting to me
> until the
> moment you said you want to base them on deployed artifacts... we
> have never
> had a habit of publishing SNAPSHOTS for all possible artifacts, and
> even the
> members of the community that are proposing this approach are
> failing to
> deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this.
Ideally the deployed artifacts they would depend on would be stable
released ones - this is directly inline with the stability goals
expressed by the likes of Dave Booz. In general, aggregations should
not depend on SNAPSHOTs or a head revision except where absolutely
necessary.
Mario's pain was caused because we had not put together an assembly
of the modules needed for the demo. It was the wee hours of the
morning, I hope you understand. Once the dust settled, the modular,
independent nature of what we had allowed us to put together a very
simple assembly for building exactly that (independent of any other
activity in trunk). You can see this here:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss-
demo
>
> You also mentioned before that we have M2 experience of a top
> down build
> not working, I'm not sure about all the details that comes to your
> mind when
> you say that, but I remember some build brakes (and I think this is
> acceptable in trunk, right ?)
No, not really.
> and we could set some conventions like,
> modules that are "unstable at the moment" would be removed from the
> maven
> profile (and maybe a JIRA would be created)... later on, when the
> module is
> back to it's stability, whoever fixed the issue would close the
> JIRA (if
> any) and put the module back to the stable profile.
The problem of this approach is that it couples everything together
through the parent pom. Even if a separate parent is used, the
reactor will attempt to use common dependency versions across the
modules. This means that modules get coupled together based on the
versions of their dependencies and so we lose the independence
between them.
Basically, unless they all use the same version then they won't all
build.
>
> Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure
> both can
> co-exist together in perfect harmony, and it would definitely be a
> good
> solution for members of the community that are interested only in a
> subset
> of Tuscany (e.g some embedder that only requires the kernel, and a
> Spring
> extension for example), and these assembly modules could be created as
> needed
>
> These profiles would probably make the user experience of someone
> that
> comes to evaluate Tuscany trunk much easier, as already mentioned
> by Mario
> [1], and help others to be more productive as already expressed on
> various
> other threads [2][3].
This is where we disagree. Doing what you suggest couples all modules
at a single monolithic version level. That may be desirable in a
commercial product but is not a way to scale an open source community.
One of the problems we have is that the documentation on the build
and the pom structure is misleading and confusing users. I wanted to
clean that up by removing bad poms such as java/pom.xml but was
overruled.
>
> If I understand your concerns, having the convention of moving
> unstable
> modules out of the maven profile should help, but maybe you could
> explain
> what worries you, that you are fighting so hard not to allow people
> to build
> different modules with a simple mvn command. Nevertheless, it's good
> practice to build before committ, right ?
Please can we not make this personal - I am not fighting hard not to
allow anything. I am trying to find a middle ground that allows
people who need to build groups of modules to do so and at the same
time preserve the independence between the modules.
I do not know of a way to make what you want work with independently
versioned modules. I have proposed something that people seemed to be
able to live with and which I believe works. Let's hear technically
viable alternatives.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Luciano Resende <lu...@gmail.com>.
Jeremy
So, having these assemblies modules sounded interesting to me until the
moment you said you want to base them on deployed artifacts... we have never
had a habit of publishing SNAPSHOTS for all possible artifacts, and even the
members of the community that are proposing this approach are failing to
deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this.
You also mentioned before that we have M2 experience of a top down build
not working, I'm not sure about all the details that comes to your mind when
you say that, but I remember some build brakes (and I think this is
acceptable in trunk, right ?) and we could set some conventions like,
modules that are "unstable at the moment" would be removed from the maven
profile (and maybe a JIRA would be created)... later on, when the module is
back to it's stability, whoever fixed the issue would close the JIRA (if
any) and put the module back to the stable profile.
Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure both can
co-exist together in perfect harmony, and it would definitely be a good
solution for members of the community that are interested only in a subset
of Tuscany (e.g some embedder that only requires the kernel, and a Spring
extension for example), and these assembly modules could be created as
needed
These profiles would probably make the user experience of someone that
comes to evaluate Tuscany trunk much easier, as already mentioned by Mario
[1], and help others to be more productive as already expressed on various
other threads [2][3].
If I understand your concerns, having the convention of moving unstable
modules out of the maven profile should help, but maybe you could explain
what worries you, that you are fighting so hard not to allow people to build
different modules with a simple mvn command. Nevertheless, it's good
practice to build before committ, right ?
[1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15894.html
[2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html
[3] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15303.html
On 3/23/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote:
>
> > Hi Jeremy
> >
> > For the assembly proposal, are you suggesting something like :
> >
> > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> > sca/distribution/tss-sample/
>
> Something like that, yeah.
>
> You want to rely on things that are as stable as possible, preferably
> things that have been released. I would not have included pom/parent
> and buildtools as those are available from the release repo.
> Generally you want to include as few unstable dependencies as possible.
>
> Also, I noticed you have a assembly descriptor in your project but
> you also include distribution/sca/demo.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote:
> Hi Jeremy
>
> For the assembly proposal, are you suggesting something like :
>
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> sca/distribution/tss-sample/
Something like that, yeah.
You want to rely on things that are as stable as possible, preferably
things that have been released. I would not have included pom/parent
and buildtools as those are available from the release repo.
Generally you want to include as few unstable dependencies as possible.
Also, I noticed you have a assembly descriptor in your project but
you also include distribution/sca/demo.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Luciano Resende <lu...@gmail.com>.
Hi Jeremy
For the assembly proposal, are you suggesting something like :
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/sca/distribution/tss-sample/
--
Luciano Resende
http://people.apache.org/~lresende
On 3/22/07, Davanum Srinivas <da...@gmail.com> wrote:
>
> Jeremy,
>
> Please take a look at axis2 poms and geronimo poms. you don't need to
> install the parent pom before building modules. you can specify
> relative path to the parent.
>
> -- dims
>
> On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
> > OK.
> >
> > If we're going to hold the vote, I'll pull the candidate artifacts.
> > We can republish them later.
> >
> > That does mean that everyone will need to install the sca parent pom
> > from the tag in SVN before any of the modules in trunk will build.
> >
> > --
> > Jeremy
> >
> > On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote:
> >
> > > Jeremy,
> > >
> > > I'd like to see some progress on the community front! Let's see this
> > > approach agreed upon and fleshed out a bit more.
> > >
> > > thanks,
> > > dims
> > >
> > > On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
> > >> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> > >> > Jeremy. This sounds like a simpler approach than what is there now.
> > >> > I like
> > >> > the idea but a question.
> > >> >
> > >> > 1) move everything that does not logical depend on
> > >> > org.apache.tuscany:sca:1.0-incubating to contrib
> > >> >
> > >> > from your previous definition do you mean those things that are not
> > >> > considered to be independent. Or do you mean things that could be
> > >> > independent but just aren't packaged that way now. I assume that
> > >> > you mean
> > >> > the latter as your next point is to go ahead and make them
> > >> > independent.
> > >>
> > >> Yes things aren't really independent due to the intermediate poms in
> > >> the physical directory tree.
> > >>
> > >> >
> > >> > Also is the global parent version 1.0-incubating or 1.0-incubating-
> > >> > SNAPSHOT.
> > >> > I note that now you have it without SNAPSHOT but its children with
> > >> > SNAPSHOT.
> > >> > Are you just saying that the global parent doesn't get packaged/
> > >> > released
> > >> > per-se SNAPSHOT or not.
> > >>
> > >> This is the pom defined in the tag here:
> > >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
> > >> sca/1.0-incubating
> > >>
> > >> which is a stable artifact - one we have voted to release but are
> > >> waiting for the IPMC to approve. It will not move.
> > >>
> > >> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
> > >> THREAD]]
> > >> http://mail-archives.apache.org/mod_mbox/incubator-general/
> > >> 200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
> > >>
> > >> The things in trunk are not stable and so have a SNAPSHOT version.
> > >> --
> > >> Jeremy
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> > > Developers
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Build structure - having cake and still eating
Posted by Davanum Srinivas <da...@gmail.com>.
Jeremy,
Please take a look at axis2 poms and geronimo poms. you don't need to
install the parent pom before building modules. you can specify
relative path to the parent.
-- dims
On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
> OK.
>
> If we're going to hold the vote, I'll pull the candidate artifacts.
> We can republish them later.
>
> That does mean that everyone will need to install the sca parent pom
> from the tag in SVN before any of the modules in trunk will build.
>
> --
> Jeremy
>
> On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote:
>
> > Jeremy,
> >
> > I'd like to see some progress on the community front! Let's see this
> > approach agreed upon and fleshed out a bit more.
> >
> > thanks,
> > dims
> >
> > On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
> >> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> >> > Jeremy. This sounds like a simpler approach than what is there now.
> >> > I like
> >> > the idea but a question.
> >> >
> >> > 1) move everything that does not logical depend on
> >> > org.apache.tuscany:sca:1.0-incubating to contrib
> >> >
> >> > from your previous definition do you mean those things that are not
> >> > considered to be independent. Or do you mean things that could be
> >> > independent but just aren't packaged that way now. I assume that
> >> > you mean
> >> > the latter as your next point is to go ahead and make them
> >> > independent.
> >>
> >> Yes things aren't really independent due to the intermediate poms in
> >> the physical directory tree.
> >>
> >> >
> >> > Also is the global parent version 1.0-incubating or 1.0-incubating-
> >> > SNAPSHOT.
> >> > I note that now you have it without SNAPSHOT but its children with
> >> > SNAPSHOT.
> >> > Are you just saying that the global parent doesn't get packaged/
> >> > released
> >> > per-se SNAPSHOT or not.
> >>
> >> This is the pom defined in the tag here:
> >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
> >> sca/1.0-incubating
> >>
> >> which is a stable artifact - one we have voted to release but are
> >> waiting for the IPMC to approve. It will not move.
> >>
> >> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
> >> THREAD]]
> >> http://mail-archives.apache.org/mod_mbox/incubator-general/
> >> 200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
> >>
> >> The things in trunk are not stable and so have a SNAPSHOT version.
> >> --
> >> Jeremy
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> > Developers
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
OK.
If we're going to hold the vote, I'll pull the candidate artifacts.
We can republish them later.
That does mean that everyone will need to install the sca parent pom
from the tag in SVN before any of the modules in trunk will build.
--
Jeremy
On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote:
> Jeremy,
>
> I'd like to see some progress on the community front! Let's see this
> approach agreed upon and fleshed out a bit more.
>
> thanks,
> dims
>
> On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
>> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
>> > Jeremy. This sounds like a simpler approach than what is there now.
>> > I like
>> > the idea but a question.
>> >
>> > 1) move everything that does not logical depend on
>> > org.apache.tuscany:sca:1.0-incubating to contrib
>> >
>> > from your previous definition do you mean those things that are not
>> > considered to be independent. Or do you mean things that could be
>> > independent but just aren't packaged that way now. I assume that
>> > you mean
>> > the latter as your next point is to go ahead and make them
>> > independent.
>>
>> Yes things aren't really independent due to the intermediate poms in
>> the physical directory tree.
>>
>> >
>> > Also is the global parent version 1.0-incubating or 1.0-incubating-
>> > SNAPSHOT.
>> > I note that now you have it without SNAPSHOT but its children with
>> > SNAPSHOT.
>> > Are you just saying that the global parent doesn't get packaged/
>> > released
>> > per-se SNAPSHOT or not.
>>
>> This is the pom defined in the tag here:
>> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
>> sca/1.0-incubating
>>
>> which is a stable artifact - one we have voted to release but are
>> waiting for the IPMC to approve. It will not move.
>>
>> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
>> THREAD]]
>> http://mail-archives.apache.org/mod_mbox/incubator-general/
>> 200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
>>
>> The things in trunk are not stable and so have a SNAPSHOT version.
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> Developers
>
> ---------------------------------------------------------------------
> 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: Build structure - having cake and still eating
Posted by Davanum Srinivas <da...@gmail.com>.
Jeremy,
I'd like to see some progress on the community front! Let's see this
approach agreed upon and fleshed out a bit more.
thanks,
dims
On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> > Jeremy. This sounds like a simpler approach than what is there now.
> > I like
> > the idea but a question.
> >
> > 1) move everything that does not logical depend on
> > org.apache.tuscany:sca:1.0-incubating to contrib
> >
> > from your previous definition do you mean those things that are not
> > considered to be independent. Or do you mean things that could be
> > independent but just aren't packaged that way now. I assume that
> > you mean
> > the latter as your next point is to go ahead and make them
> > independent.
>
> Yes things aren't really independent due to the intermediate poms in
> the physical directory tree.
>
> >
> > Also is the global parent version 1.0-incubating or 1.0-incubating-
> > SNAPSHOT.
> > I note that now you have it without SNAPSHOT but its children with
> > SNAPSHOT.
> > Are you just saying that the global parent doesn't get packaged/
> > released
> > per-se SNAPSHOT or not.
>
> This is the pom defined in the tag here:
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
> sca/1.0-incubating
>
> which is a stable artifact - one we have voted to release but are
> waiting for the IPMC to approve. It will not move.
>
> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
> THREAD]]
> http://mail-archives.apache.org/mod_mbox/incubator-general/
> 200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
>
> The things in trunk are not stable and so have a SNAPSHOT version.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> Jeremy. This sounds like a simpler approach than what is there now.
> I like
> the idea but a question.
>
> 1) move everything that does not logical depend on
> org.apache.tuscany:sca:1.0-incubating to contrib
>
> from your previous definition do you mean those things that are not
> considered to be independent. Or do you mean things that could be
> independent but just aren't packaged that way now. I assume that
> you mean
> the latter as your next point is to go ahead and make them
> independent.
Yes things aren't really independent due to the intermediate poms in
the physical directory tree.
>
> Also is the global parent version 1.0-incubating or 1.0-incubating-
> SNAPSHOT.
> I note that now you have it without SNAPSHOT but its children with
> SNAPSHOT.
> Are you just saying that the global parent doesn't get packaged/
> released
> per-se SNAPSHOT or not.
This is the pom defined in the tag here:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
sca/1.0-incubating
which is a stable artifact - one we have voted to release but are
waiting for the IPMC to approve. It will not move.
[[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
THREAD]]
http://mail-archives.apache.org/mod_mbox/incubator-general/
200703.mbox/%3c4279CE28-142B-4BEE-9688-F2057A9E4F07@apache.org%3e
The things in trunk are not stable and so have a SNAPSHOT version.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Simon Laws <si...@googlemail.com>.
On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 22, 2007, at 11:19 AM, Simon Laws wrote:
> > <stupidquestion>
> > When you talk about flattening the module hierarchy do you mean this
> > literally in svn (which I like the sound of as I can never find
> > anything in
> > all the nested dirs - my inexperience showing) or is this some virtual
> > flattening?
> > </stupidquestion>
>
> Not a <stupidquestion> at all. We can do either or both ...
> <mvnStuffAsBackgound>
> The logical/virtual tree here is the <parent> structure in the pom.
> Maven projects can inherit project definitions (stuff like
> dependencies, repo locations, plugins to use) from another project by
> specifying it in their <parent> element - this can be used to avoid
> repetition of stuff like dependency versions, plugin configurations
> and so on.
>
> This is actually independent of the physical directory structure,
> although often the pom in one directory is used as the parent for
> <modules> that it builds. This is actually conflating physical
> structure and logical structure together and although it seemed like
> a good idea at the time I don't think that it is working any more.
> </mvnStuffAsBackground>
>
> I think we should first flatten the logical hierarchy so that all
> independent module groups inherit from a global parent. This would be
> org.apache.tuscany:sca:1.0-incubating. By "independent" I mean
> things that could be released independently - these could be groups
> of tightly coupled modules (such the current "kernel" or "runtime")
> or individual modules such as "http.jetty"
>
> I started on this for the modules that were part of 2.0-alpha but
> have not done it yet for the modules in extensions or services that
> were not. I think we should do this now for the others - I'll make a
> start on the ones used in the demo.
>
> An orthogonal issue is how we lay out the physical directory tree. It
> is probably simpler to get rid of midlevel parents like "extensions"
> and "services" all together and just have a flat structure under
> "sca" - I think that would help make things easier to find.
>
> We started doing that with a gradual migration of stuff from
> "services" to "extensions" but I think doing this gradually has
> probably just added to the confusion. I'd suggest we give up on the
> gradual approach and move everything under "contrib" until we can fix
> the logical structure as above.
>
> To summarize:
> 1) move everything that does not logical depend on
> org.apache.tuscany:sca:1.0-incubating to contrib
> 2) update each module or group in contrib to be logically independent
> 3) once the module is independent move it to the flat structure under
> sca so it is easy to find
>
> I'm going to get started with the modules used in the demo.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Jeremy. This sounds like a simpler approach than what is there now. I like
the idea but a question.
1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib
from your previous definition do you mean those things that are not
considered to be independent. Or do you mean things that could be
independent but just aren't packaged that way now. I assume that you mean
the latter as your next point is to go ahead and make them independent.
Also is the global parent version 1.0-incubating or 1.0-incubating-SNAPSHOT.
I note that now you have it without SNAPSHOT but its children with SNAPSHOT.
Are you just saying that the global parent doesn't get packaged/released
per-se SNAPSHOT or not.
S
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 22, 2007, at 11:19 AM, Simon Laws wrote:
> <stupidquestion>
> When you talk about flattening the module hierarchy do you mean this
> literally in svn (which I like the sound of as I can never find
> anything in
> all the nested dirs - my inexperience showing) or is this some virtual
> flattening?
> </stupidquestion>
Not a <stupidquestion> at all. We can do either or both ...
<mvnStuffAsBackgound>
The logical/virtual tree here is the <parent> structure in the pom.
Maven projects can inherit project definitions (stuff like
dependencies, repo locations, plugins to use) from another project by
specifying it in their <parent> element - this can be used to avoid
repetition of stuff like dependency versions, plugin configurations
and so on.
This is actually independent of the physical directory structure,
although often the pom in one directory is used as the parent for
<modules> that it builds. This is actually conflating physical
structure and logical structure together and although it seemed like
a good idea at the time I don't think that it is working any more.
</mvnStuffAsBackground>
I think we should first flatten the logical hierarchy so that all
independent module groups inherit from a global parent. This would be
org.apache.tuscany:sca:1.0-incubating. By "independent" I mean
things that could be released independently - these could be groups
of tightly coupled modules (such the current "kernel" or "runtime")
or individual modules such as "http.jetty"
I started on this for the modules that were part of 2.0-alpha but
have not done it yet for the modules in extensions or services that
were not. I think we should do this now for the others - I'll make a
start on the ones used in the demo.
An orthogonal issue is how we lay out the physical directory tree. It
is probably simpler to get rid of midlevel parents like "extensions"
and "services" all together and just have a flat structure under
"sca" - I think that would help make things easier to find.
We started doing that with a gradual migration of stuff from
"services" to "extensions" but I think doing this gradually has
probably just added to the confusion. I'd suggest we give up on the
gradual approach and move everything under "contrib" until we can fix
the logical structure as above.
To summarize:
1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib
2) update each module or group in contrib to be logically independent
3) once the module is independent move it to the flat structure under
sca so it is easy to find
I'm going to get started with the modules used in the demo.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Simon Laws <si...@googlemail.com>.
On 3/22/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
>
> > +1.
> >
> > I think it's in line with the proposal in my response to Meeraj.
> >
> > One question: For a bundle to reference a module in the Tuscany
> > source tree, do we really have to copy (or use svn:externals
> > property) if it points to a location (under trunk, tags, or
> > branches) in the Tuscany tree? I think a relative path for the
> > <module> will work.
>
> It will.
>
> The difference would be that with a ../.. type relative path someone
> can't just check out the assembly module, they need to check out the
> whole tree from some common root. With an external they could just
> check out the assembly module and the source for the dependency would
> be checked out as well. Of course, then they might have multiple
> copies of the dependency source to manage.
>
> Either works and it would up to the users of the assembly module to
> choose which style they prefer.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Sounds like a good compromise to me
<stupidquestion>
When you talk about flattening the module hierarchy do you mean this
literally in svn (which I like the sound of as I can never find anything in
all the nested dirs - my inexperience showing) or is this some virtual
flattening?
</stupidquestion>
Simon
Re: Build structure - having cake and still eating
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
> +1.
>
> I think it's in line with the proposal in my response to Meeraj.
>
> One question: For a bundle to reference a module in the Tuscany
> source tree, do we really have to copy (or use svn:externals
> property) if it points to a location (under trunk, tags, or
> branches) in the Tuscany tree? I think a relative path for the
> <module> will work.
It will.
The difference would be that with a ../.. type relative path someone
can't just check out the assembly module, they need to check out the
whole tree from some common root. With an external they could just
check out the assembly module and the source for the dependency would
be checked out as well. Of course, then they might have multiple
copies of the dependency source to manage.
Either works and it would up to the users of the assembly module to
choose which style they prefer.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build structure - having cake and still eating
Posted by Jim Marino <jm...@myromatours.com>.
This seems good +1.
Jim
On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
> +1.
>
> I think it's in line with the proposal in my response to Meeraj.
>
> One question: For a bundle to reference a module in the Tuscany
> source tree, do we really have to copy (or use svn:externals
> property) if it points to a location (under trunk, tags, or
> branches) in the Tuscany tree? I think a relative path for the
> <module> will work.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jeremy Boynes"
> <jb...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Thursday, March 22, 2007 10:10 AM
> Subject: Build structure - having cake and still eating
>
>
>> We know from M2 experience and the number of "profiles" in the
>> integration branch that a top-down, build-everything approach
>> does not work.
>>
>> We also know from practical experience that people struggle
>> building modules.
>>
>> I believe there is a middle ground that supports both approaches;
>> * have a flat module structure that allows any module to be built
>> on its own
>> using dependencies from the mvn repos
>> * have particular assemblies that pull modules together into
>> whatever bundles
>> people want. The assemblies can use released modules from mvn,
>> snapshot
>> modules from mvn, a copy of any revision of that module, or can
>> track
>> trunk using svn externals
>>
>> An example of this is the assembly I used for the tag for the
>> TSSS demo code which uses a combination of released artifacts and
>> known revisions.
>>
>> This gives module developers their own space to work in, and
>> allows people consuming those modules to choose how stable the
>> code they want to use is (from released through to head).
>>
>> Hopefully this will provide a middle ground we are all comfortable
>> with.
>> --
>> 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: Build structure - having cake and still eating
Posted by Raymond Feng <en...@gmail.com>.
+1.
I think it's in line with the proposal in my response to Meeraj.
One question: For a bundle to reference a module in the Tuscany source tree,
do we really have to copy (or use svn:externals property) if it points to a
location (under trunk, tags, or branches) in the Tuscany tree? I think a
relative path for the <module> will work.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, March 22, 2007 10:10 AM
Subject: Build structure - having cake and still eating
> We know from M2 experience and the number of "profiles" in the
> integration branch that a top-down, build-everything approach does not
> work.
>
> We also know from practical experience that people struggle building
> modules.
>
> I believe there is a middle ground that supports both approaches;
> * have a flat module structure that allows any module to be built on its
> own
> using dependencies from the mvn repos
> * have particular assemblies that pull modules together into whatever
> bundles
> people want. The assemblies can use released modules from mvn, snapshot
> modules from mvn, a copy of any revision of that module, or can track
> trunk using svn externals
>
> An example of this is the assembly I used for the tag for the TSSS demo
> code which uses a combination of released artifacts and known revisions.
>
> This gives module developers their own space to work in, and allows
> people consuming those modules to choose how stable the code they want to
> use is (from released through to head).
>
> Hopefully this will provide a middle ground we are all comfortable with.
> --
> 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