Dims,
I am more than happy to find a middle ground where everyone can work
together. I was just pointing out the technical issues with a top down
pom. Worst case as a compromise, I may even agree to a top-down pom,
even though I don't agree with it from a technical perspective, so that
we can work together.
On a side note what I suggested on the thread "Objective of the
following sandbox", is that there had been lot of discussion and work in
the last two months on stuff around the kernel. As I said, I am happy to
discuss Sebastien's proposal. However, that should not be done in
isolation. We should also take into consideration, the work we have done
so far and why we want to start from scratch rather than improve the
kernel incrementally.
I am all for modularizing the kernel, this is something we all agree on.
However, that doesn't mean we start from scratch. Some of the issues
Sebastien has raised were discussed on the list more than ten moths ago,
and we as a community took a decision to take the direction we now have
in kernel. In my opinion that is water under bridge.
However, if we need to go back and discuss those things again, I am
happy to do it. But as I said, these discussions shouldn't be done in
isolation, there should also be a strong rationale on what is so wrong
with the current kernel, that it needs to be changed so drastically.
Thanks
Meeraj
>> -----Original Message-----
>> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
>> Sent: 24 March 2007 13:31
>> To: [email protected]
>> Subject: Re: Build structure - having cake and still eating
>>
>> Meeraj,
>>
>> Using assemblies is ok. It does not have to be published.
>> Once everyone is in the same bandwagon, then it's ok to
>> publish. Till then, please find a way to work with
>> assemblies w/o having to rely on published artifacts. If
>> this is a maven problem, then find another way to solve the
>> problem or ask at least raise an issue with maven folks.
>> As for myself, am putting my foot down on publishing till
>> everyone shares. This is getting more and more like 3-4 year
>> olds in the sandbox not sharing their toys and saying hey
>> you did not talk to me when i talked to you. So shut up now.
>> Everyone has a life, everyone has priorities. When folks
>> come to the table, the conversation should begin again.
>> Again, Please figure out a way everyone can work.
>>
>> thanks,
>> dims
>>
>> On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>> > Luciano,
>> >
>> > Your hijacked version of pom portrays all the issues
>> associated with a
>> > top down pom with a single version in a complex project. You have
>> > included the modules you want to build. It may not be of
>> any use to
>> > me, if I want to build a separate set of modules. So what
>> is the point
>> > in committing your pom to the source tree, if it is of use to only
>> > yourself?
>> >
>> > Then the solution would be to build the whole thing. That
>> would never
>> > scale for complexity. Why would I want to build the whole kitchen
>> > sink, if I am interested in building only a subset that is
>> pertinent
>> > to the task I am working on? A single version and top down
>> build that
>> > builds everything, IMHO, would create unnecessary coupling
>> in complex projects.
>> >
>> >
>> > If we rely on a top down build that builds everything,
>> regardless of
>> > area of the project we are working on, I would say we lack
>> clarity in
>> > terms of how the project is architecturally modularized.
>> >
>> > And for new comers to build samples, I agree with Jeremy
>> that the best
>> > thing to do is use mvn assemblies based on published artifacts.
>> >
>> > On a side note, I think you should never give up :) IMHO we should
>> > have these constructive discussions, as long as they are
>> in the best
>> > interest of the community and the project.
>> >
>> > ta
>> > Meeraj
>> >
>> > >> -----Original Message-----
>> > >> From: Luciano Resende [mailto:[EMAIL PROTECTED]
>> > >> Sent: 24 March 2007 00:05
>> > >> To: [email protected]
>> > >> Subject: Re: Build structure - having cake and still eating
>> > >>
>> > >> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> > >> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >> This message has been checked for all email viruses by
>> MessageLabs
>> >
>> > *****************************************************
>> >
>> > You can find us at www.voca.com
>> >
>> > *****************************************************
>> > This communication is confidential and intended for the
>> exclusive use
>> > of the addressee only. You should not disclose its contents to any
>> > other person.
>> > If you are not the intended recipient please notify the
>> sender named
>> > above immediately.
>> >
>> > Registered in England, No 1023742,
>> > Registered Office: Voca Limited
>> > Drake House, Three Rivers Court,
>> > Homestead Road, Rickmansworth,
>> > Hertfordshire, WD3 1FX. United Kingdom
>> >
>> > VAT No. 226 6112 87
>> >
>> >
>> > This message has been checked for all email viruses by MessageLabs.
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>> --
>> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web
>> Services Developers
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> This message has been checked for all email viruses by MessageLabs.
>>
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
