You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Frank Budinsky <fr...@ca.ibm.com> on 2007/01/05 04:08:06 UTC
Maven dependencies question
I think I need some help form somebody with a better understanding (than
me) of how maven dependencies work.
Because the Java sdo/impl project includes an optional stax
loader/serializer it includes this in its pom.xml file:
<!-- dependencies for optional StAX functions -->
<dependency>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
<version>1.0.1</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
One of the new implementation classes in the the sdo/impl project also
uses the StAX function itself, internally in its implementation.
Now, in the sdo/tools project, we have a test program that calls the
implementation class that uses the StAX stuff (indirectly though an SDO
helper interface). Note that the test program in the sdo/tools project has
no import or direct use of any StAX interfaces.
However, when we now run mvn in the sdo/tools project, the test program,
mentioned above, fails with the following error:
java.lang.NoClassDefFoundError:
javax/xml/stream/XMLStreamException
I was able to fix the problem by copying the stax dependency from the
sdo/impl pom.xml file and adding it to the pom.xml in the sdo/tools
project, but this seems a bit ridiculous, since as I mentioned above, the
use of stax is really only in the sdo/impl project.
Can anybody see what the problem might be, or suggest how to fix this?
Thanks in advance,
Frank.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Toni Menzel <to...@gmx.de>.
Hi,
building the spec libs myself is the winning tip! Now the build goes fine.
Just didn't realised that the sources of the spec lib where in the
tuscany svn..
thank you all for the quick and helpful answers!
regards,
Toni
Raymond Feng schrieb:
> Hi,
>
> You need to build the specs first before the sca modules.
>
>> cd spec
>> mvn clean install
>
> Or you build all things in one:
>
>> cd <tuscany>/java
>> mvn -Pall clean install
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Toni Menzel" <to...@gmx.de>
> To: <tu...@ws.apache.org>
> Sent: Friday, January 05, 2007 3:51 PM
> Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims
> missing jar dependency)
>
>
>> I did this:
>> svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
>> cd sdo;mvn clean install
>> cd ../sca;mvn clean install
>>
>> the second mvn call breaks with missing dependency.
>>
>> @Slava, can you rebuild your question, don't know what you are
>> talking about exactly..?
>>
>> Toni
>>
>>
>>
>> Slava Imeshev schrieb:
>>> Guys,
>>>
>>> If you tell me how to build tuscany from a command line at one shot.
>>> I can make sure that such
>>> errors are caught immeditely.
>>>
>>> Slava
>>>
>>>
>>> --- Toni Menzel <to...@gmx.de> wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> I just tried to build tuscany from source for the first time.
>>>> Building sdo works out-of-the-box but the sca breaks with the
>>>> following message:
>>>> Downloading:
>>>> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
>>>>
>>>> [WARNING] Unable to get resource from repository
>>>> apache.ws.m1.snapshots (http://ws.zones.apache.org/repository)
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [INFO] Failed to resolve artifact.
>>>>
>>>> Missing:
>>>> ----------
>>>> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
>>>>
>>>> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
>>>> .m2/settings.xml, but this doesn't work either..
>>>>
>>>> is there any known issue with this revision or am i missing something?
>>>>
>>>> thanks in advance,
>>>> Toni
>>>>
>>>>
>>>> PS: I tried using a fresh local mvn repository, too :-(
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> --
>> Toni Menzel
>> http://www.tonit.com
>> mailto:tonimenzel@gmx.de
>>
>>
>> ---------------------------------------------------------------------
>> 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
--
Toni Menzel
http://www.tonit.com
mailto:tonimenzel@gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
You need to build the specs first before the sca modules.
> cd spec
> mvn clean install
Or you build all things in one:
> cd <tuscany>/java
> mvn -Pall clean install
Thanks,
Raymond
----- Original Message -----
From: "Toni Menzel" <to...@gmx.de>
To: <tu...@ws.apache.org>
Sent: Friday, January 05, 2007 3:51 PM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
>I did this:
> svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
> cd sdo;mvn clean install
> cd ../sca;mvn clean install
>
> the second mvn call breaks with missing dependency.
>
> @Slava, can you rebuild your question, don't know what you are talking
> about exactly..?
>
> Toni
>
>
>
> Slava Imeshev schrieb:
>> Guys,
>>
>> If you tell me how to build tuscany from a command line at one shot. I
>> can make sure that such
>> errors are caught immeditely.
>>
>> Slava
>>
>>
>> --- Toni Menzel <to...@gmx.de> wrote:
>>
>>
>>> Hi!
>>>
>>> I just tried to build tuscany from source for the first time.
>>> Building sdo works out-of-the-box but the sca breaks with the following
>>> message:
>>> Downloading:
>>> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
>>> [WARNING] Unable to get resource from repository apache.ws.m1.snapshots
>>> (http://ws.zones.apache.org/repository)
>>> [INFO] ------------------------------------------------------------------------
>>> [ERROR] BUILD ERROR
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Failed to resolve artifact.
>>>
>>> Missing:
>>> ----------
>>> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
>>>
>>> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
>>> .m2/settings.xml, but this doesn't work either..
>>>
>>> is there any known issue with this revision or am i missing something?
>>>
>>> thanks in advance,
>>> Toni
>>>
>>>
>>> PS: I tried using a fresh local mvn repository, too :-(
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> --
> Toni Menzel
> http://www.tonit.com
> mailto:tonimenzel@gmx.de
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 8, 2007, at 9:15 AM, Simon Nash wrote:
> Thanks for the pointer. I have downloaded the book and I have read
> the sections describing SNAPSHOTs. I look forward to reading the
> remainder.
>
> My reference to a "user" was intended to mean anyone needing to put
> together a working combination of already built SNAPSHOT modules for
> the selection of sca infrastructure components that they need.
Someone looking to use Tuscany - what I would call a "user" - would
not be doing this - they should be using released versions that
provide some level of stability. With smaller modules we can release
more often to provide these baselines.
> Project developers would certainly fall into this category. If they
> are developing code inside one module, they can assemble a test
> environment for that code from other pre-built modules that are in
> a known working state. This should be the main benefit of having
> a modular build.
If you're developing an extension you don't want to be tracking head
all the time - ideally you would be developing against a released
version of the kernel and other extensions. If you're not doing that
then you need to be tracking the current trunk and reacting to
changes in it - SNAPSHOTs are ideal for that.
>
> My main point was that using SNAPSHOT dependencies between all the
> separately built sca modules (kernel and extensions) leads to tight
> coupling when new SNAPSHOTs of upstream modules are published,
> because it is necessary to simultaneously publish matching SNAPSHOTs
> of downstream modules to keep them in sync. For example, publication
> of a new kernel SNAPSHOT with an SPI change would require
> republication
> of SNAPSHOTs for all extensions that depend on the changed SPI. If
> these dependent extensions are not republished as SNAPSHOTs, the
> set of latest SNAPSHOTs will no longer be self-consistent. Having the
> downstream components depend on a known upstream level (however
> this is done) avoids this problem.
>
> Does anyone else think this is a problem that should concern us?
No. Release early, release often and use those releases as much as
you can. That's how this model works.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy Boynes wrote:
> On Jan 8, 2007, at 9:51 AM, Jean-Sebastien Delfino wrote:
>
>> Simon,
>>
>> I think that what you're describing is a problem only if the jar is
>> published as xyz-SNAPSHOT.jar without identifying the specific level
>> of code in the jar. If it is published as xyz-r493223- SNAPSHOT.jar
>> for example (or another form of identification of a specific level)
>> then a new revision of the SPI will be published in a different jar
>> (xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223
>> will continue to reference xyz-r493223- SNAPSHOT.jar, components that
>> want to move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
>>
>> So if I understand correctly, this scheme allows the core components
>> to move on with changes without breaking the others that depend on
>> the core. These components become responsible for catching up with
>> core changes when they wish or can do it (and they better do it
>> frequently to avoid surprises when they move up levels). Whoever
>> wants to build a working distribution or run an end to end scenario
>> becomes responsible for putting the pieces together, and coordinating
>> and working with the various component providers to make sure that
>> they all work on compatible levels of the core jars.
>>
>> Does that make sense?
>
It makes good sense to me. This is the approach that I was suggesting
in my original post on this topic.
> When coupled with releases rather than SNAPSHOT timestamps, yes. You
> might want to use an old snapshot temporarily but in general it's not a
> good idea.
>
This works if releases happen frequently enough. The process would be
to develop downstream components based on stable upstream dependencies
where possible. When an incompatible change is made to the upstream
component (making it unstable), the downstream component developer can
either a) move up to the unstable dependency, or b) stay with the
stable dependency. In case a), the SNAPSHOT downstream and SNAPSHOT
upstream components become tightly coupled until they are both released
again. In case b), the SNAPSHOT downstream and SNAPSHOT upstream
components become incompatible until the upstream component is released
again, at which time the downstream component must react to the
incompatible change and produce a new release. This works as long as
everyone understands exactly which components are tightly coupled and
what combinations are incompatible, except in cases such as:
both B and C depend on A
latest A and B are coupled, and latest A and C are imcompatible
someone needs to use latest B and latest C together
>>
>> I think it would help a lot if somebody who understands this new
>> scheme better than me could educate us on the steps that the various
>> people on the project will have to go through when a change occurs in
>> one of the core Jars.
>
>
> Generally nothing assuming the changes are generally compatible (80-20
> rule). When they aren't, then they need to update their code to react
> to the change which is work that would need to be done anyway.
>
Presumably these issues would show up as a result of running integration
tests after an incompatible change is made to an upstream module. All
the downstream folks would then need to scramble to fix their code to
react to the change. While they are doing this, there would be no easy way
to assemble a working set of compatible components that are more recent
than the last released versions.
Simon
> --
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 8, 2007, at 9:51 AM, Jean-Sebastien Delfino wrote:
> Simon,
>
> I think that what you're describing is a problem only if the jar is
> published as xyz-SNAPSHOT.jar without identifying the specific
> level of code in the jar. If it is published as xyz-r493223-
> SNAPSHOT.jar for example (or another form of identification of a
> specific level) then a new revision of the SPI will be published in
> a different jar (xyz-r493224-SNAPSHOT.jar). Components that want to
> stay on r493223 will continue to reference xyz-r493223-
> SNAPSHOT.jar, components that want to move on to r493224 will
> reference xyz-r493224-SNAPSHOT.jar.
>
> So if I understand correctly, this scheme allows the core
> components to move on with changes without breaking the others that
> depend on the core. These components become responsible for
> catching up with core changes when they wish or can do it (and they
> better do it frequently to avoid surprises when they move up
> levels). Whoever wants to build a working distribution or run an
> end to end scenario becomes responsible for putting the pieces
> together, and coordinating and working with the various component
> providers to make sure that they all work on compatible levels of
> the core jars.
>
> Does that make sense?
When coupled with releases rather than SNAPSHOT timestamps, yes. You
might want to use an old snapshot temporarily but in general it's not
a good idea.
>
> I think it would help a lot if somebody who understands this new
> scheme better than me could educate us on the steps that the
> various people on the project will have to go through when a change
> occurs in one of the core Jars.
Generally nothing assuming the changes are generally compatible
(80-20 rule). When they aren't, then they need to update their code
to react to the change which is work that would need to be done anyway.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 10, 2007, at 7:25 AM, ant elder wrote:
> On 1/10/07, Jeremy Boynes <jb...@apache.org> wrote:
> <snip>
>
>> For example, Spring does have independently
>> > released subprojects, but the main Spring release is a lot more
>> > than just
>> > the their IOC container, it comes with a whole bunch of related
>> > components -
>> > spring-aop, spring-jms, spring-jpa, etc - that they deem make the
>> > release
>> > useful and interesting, and that they have tested are all at
>> > compatible
>> > levels. Also, all those components are generally only released
>> > together
>> > rather than having lots of separate independent releases. This
>> seems
>> > generally the case looking across most other projects vaguely
>> > similar to us.
>>
>> This is a different kind of beast - it's an aggregation of released
>> components put together for users. Pulling this kind of thing
>> together takes a lot of time an resource
>
>
> Maybe we've not been talking about the same thing. Do you think we
> need a
> beast like this? I guess I was thinking we did as it seems a bit
> unfriendly
> to just put a whole lot of independently released artifacts up on our
> website and leave it to users to work out which work together.
"Need" such a thing - hopefully our dynamic configuration support
will be good enough that we don't "need" to do this. If we do "need"
to do this then, based on what we've been through so far, I don't
think the project will be able to grow.
Having said that, we should still make it possible for those who want
such a thing to be able to build one easily. There's an essential
difference between the production of components and the production of
distributions. More like Linux than Windows.
We might /choose/ to do such a thing, but that's a different question.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by ant elder <an...@gmail.com>.
On 1/10/07, Jeremy Boynes <jb...@apache.org> wrote:
<snip>
> For example, Spring does have independently
> > released subprojects, but the main Spring release is a lot more
> > than just
> > the their IOC container, it comes with a whole bunch of related
> > components -
> > spring-aop, spring-jms, spring-jpa, etc - that they deem make the
> > release
> > useful and interesting, and that they have tested are all at
> > compatible
> > levels. Also, all those components are generally only released
> > together
> > rather than having lots of separate independent releases. This seems
> > generally the case looking across most other projects vaguely
> > similar to us.
>
> This is a different kind of beast - it's an aggregation of released
> components put together for users. Pulling this kind of thing
> together takes a lot of time an resource
Maybe we've not been talking about the same thing. Do you think we need a
beast like this? I guess I was thinking we did as it seems a bit unfriendly
to just put a whole lot of independently released artifacts up on our
website and leave it to users to work out which work together.
...ant
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 10, 2007, at 5:17 AM, ant elder wrote:
> On 1/10/07, Jim Marino <jm...@myromatours.com> wrote:
>
> <snip>
>
>> Have we looked on how other Apache Projects are handling this ?
>> >
>> I believe Jeremy has with Geronimo. Other projects outside Apache
>> such as JBoss, Hibernate, and Spring release subprojects
>> independently as well.
>
>
> True, but what is a 'subproject' is not precisely defined and
> they are
> usually fairly coarsely grained.
I would say that usually they are not: HTTPD with modules, Maven with
plugins, Jakarta/Tomcat with Commons... There are also projects that
don't have such a modular structure and face the same issues we are
running into: Axis with all the WS sub-projects is an example.
> For example, Spring does have independently
> released subprojects, but the main Spring release is a lot more
> than just
> the their IOC container, it comes with a whole bunch of related
> components -
> spring-aop, spring-jms, spring-jpa, etc - that they deem make the
> release
> useful and interesting, and that they have tested are all at
> compatible
> levels. Also, all those components are generally only released
> together
> rather than having lots of separate independent releases. This seems
> generally the case looking across most other projects vaguely
> similar to us.
This is a different kind of beast - it's an aggregation of released
components put together for users. Pulling this kind of thing
together takes a lot of time an resource - we see that in Geronimo
where they need to pull together a certified implementation of JEE
which is a major effort for the project; we saw it here pulling
together the M1 and M2 releases. What we found is that kills momentum
on the project.
Moving to stable, released components that such a beast can use has
benefits all around - component developers can proceed at their own
pace with a stable set of contracts between them, the project can
scale because we don't force everyone to maintain everything, it's
easier to create an aggregation as there is a set of stable
components to pick from.
Of course, this assumes there is a set of released components to
select from ...
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jim Marino <jm...@myromatours.com>.
On Jan 10, 2007, at 5:17 AM, ant elder wrote:
> On 1/10/07, Jim Marino <jm...@myromatours.com> wrote:
>
> <snip>
>
>> Have we looked on how other Apache Projects are handling this ?
>> >
>> I believe Jeremy has with Geronimo. Other projects outside Apache
>> such as JBoss, Hibernate, and Spring release subprojects
>> independently as well.
>
>
> True, but what is a 'subproject' is not precisely defined and
> they are
> usually fairly coarsely grained. For example, Spring does have
> independently
> released subprojects, but the main Spring release is a lot more
> than just
> the their IOC container, it comes with a whole bunch of related
> components -
> spring-aop, spring-jms, spring-jpa, etc - that they deem make the
> release
> useful and interesting, and that they have tested are all at
> compatible
> levels.
Subprojects in Spring such as Pitchfork, WebFlow and Spring Security
are released independtly. Spring AOP and their IOC container would be
equivalent to our kernel projects. It's also interesting to note that
for the other pieces you mentioned they are modularizing further.
> Also, all those components are generally only released together
> rather than having lots of separate independent releases. This seems
> generally the case looking across most other projects vaguely
> similar to us.
>
That's not been my experience. The Spring modules I mentioned, as
well as Eclipse, Hibernate, Jetty and JBoss are a some that come to
mind.
Jim
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by ant elder <an...@gmail.com>.
On 1/10/07, Jim Marino <jm...@myromatours.com> wrote:
<snip>
> Have we looked on how other Apache Projects are handling this ?
> >
> I believe Jeremy has with Geronimo. Other projects outside Apache
> such as JBoss, Hibernate, and Spring release subprojects
> independently as well.
True, but what is a 'subproject' is not precisely defined and they are
usually fairly coarsely grained. For example, Spring does have independently
released subprojects, but the main Spring release is a lot more than just
the their IOC container, it comes with a whole bunch of related components -
spring-aop, spring-jms, spring-jpa, etc - that they deem make the release
useful and interesting, and that they have tested are all at compatible
levels. Also, all those components are generally only released together
rather than having lots of separate independent releases. This seems
generally the case looking across most other projects vaguely similar to us.
...ant
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jim Marino <jm...@myromatours.com>.
Hi Luciano,
Comments inline.
Jim
On Jan 9, 2007, at 2:12 PM, Luciano Resende wrote:
> I'm trying to better understand and reflect about the day to day
> changes
> that might come from this discussion, and here are some questions :
>
> I think this scenario is really good between projects (e.g SCA and
> Axis,
> and/or SCA and DAS), but does it really make sense to have DAS
> Container
> from trunk not working with SCA from trunk ? I think this will be a
> side
> effect of having a DAS container based on a old SCA or Kernel or
> any other
> SNAPSHOT module.
Yes I think it makes sense. In order to have proper modularity, a
particular extension needs to treat the SCA kernel as third-party
software such as a JDBC driver. For example, extensions may only be
available for a particular version of the kernel. Of course, an
extension is free to reference SNAPSHOT, but it does so with the
recognition that this will likely introduce instability. I would
caution extensions from referencing SNAPSHOTs except in special
circumstances. Again, the same "third-party" rule-of-thumb applies:
extensions rarely reference SNAPSHOTs of technologies from other
projects.
>
> Also, on the scenario where I'm working on the DAS container and
> need to
> change/add functionality to DAS, how do I grab the source of the
> SNAPSHOT of
> that DAS,make necessary updates, and start using that, instead of the
> published SNAPSHOT ? Or I'll have to add the functionality to DAS,
> publish a
> new SNAPSHOT (that might bring other instabilities) and then I can
> use it. ?
> This would be a problem for interactive parallel development, no ?
This would follow the same process as requiring a feature in third-
party software. For example, the DAS container should treat DAS the
same way the JPA integration treats JPA implementations (e.g.
OpenJPA). If a new feature is required, either a new SNAPSHOT is
published or a new release is cut. Publishing SNAPSHOTs always brings
the possibility of introducing side-effects or instabilities and any
downstream software referencing them needs to be aware of that. What
we can't have is the DAS container referencing DAS directly as that
will result in tight coupling where people need to build both the DAS
and SCA trees.
I also don't see this as a problem for parallel development as the
model is release early, release often. We need to maintain a loose
coupling between these technologies otherwise we will wind up with
the problems we had in M1. IMO, having to directly reference a third-
party technology is a risky work-around for not having the proper
development cycle in place.
>
> Also, are we going to flood IPMC with release votes (I'm only
> counting the
> final release votes), as we need to vote for DAS and SDO, Kernel,
> etc, once
> that is released then we need to vote for all containers, etc no ?
>
There will certainly be more votes. However, I don't see the release
process as happening all at once since that is what we are trying to
get away from. DAS, SDO, and SCA don't need to be released at the
same time as they are completely independent technologies. Similarly,
extensions would be released individually or in sets but we would not
be releasing extensions all at once. The kernel will be released
often and before extensions. There will likely be no relation to when
DAS and SDO are released as the kernel does not require those
technologies.
> Have we looked on how other Apache Projects are handling this ?
>
I believe Jeremy has with Geronimo. Other projects outside Apache
such as JBoss, Hibernate, and Spring release subprojects
independently as well.
Jim
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
>
> On 1/9/07, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> To better evaulate if the code base is ready to be a release,
>> there are
>> two
>> useful techiques discribed in the "Better Builds with Maven" book
>> (http://www.mergere.com/m2book_download.jsp):
>>
>> 6.9. Monitoring and Improving the Health of Your Dependencies
>>
>> Run "mvn site" to create dependency and dependency convergence
>> reports.
>>
>> The report shows all of the dependencies included in all of the
>> modules
>> within the project. It also includes some statistics and reports
>> on two
>> important factors:
>>
>> * Whether the versions of dependencies used for each module is in
>> alignment. This helps ensure your build is consistent and reduces the
>> probability of introducing an accidental incompatibility.
>>
>> * Whether there are outstanding SNAPSHOT dependencies in the
>> build,
>> which indicates dependencies that are in development, and must be
>> updated
>> before the project can be released.
>>
>> 6.10. Monitoring and Improving the Health of Your Releases
>>
>> An important tool in determining whether a project is ready to be
>> released is Clirr (http://clirr.sf.net/). Clirr detects whether the
>> current
>> version of a library has introduced any binary incompatibilities
>> with the
>> previous release.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Jim Marino" <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Tuesday, January 09, 2007 1:27 AM
>> Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims
>> missing
>> jar dependency)
>>
>>
>> >I know very little about Maven except to follow how it expects
>> projects
>> to
>> >be structured and behave or it will inflict untold amounts of pain
>> (which
>> >is probably fair given its goal of trying to standardize project
>> build
>> >structures) :-) Here is how I picture things will work:
>> >
>> > 1. We decided that modules are either independent or grouped
>> by function.
>> > For example, the Axis2 binding extension and the WSDL to Java
>> tool if
>> it
>> > is specific to Axis. Modules are grouped independently from their
>> > dependencies. For example, the JPA extension is independent
>> from the
>> > Geronimo transaction manager since the two are not inherently tied
>> > together (the former only requires a JTA implementation).
>> >
>> > 2. We also decided that modules will be organized in the source
>> tree by
>> > how they are released. For example, the Axis2 binding extension
>> will be
>> > grouped with the WSDL to Java tool. This will have the side
>> effect of
>> > solving the problem of specifying versions of common dependencies.
>> >
>> > 3. The above assumes modules will be developed independently or
>> by how
>> > they are grouped. Consequently, most of the time, they will never
>> > reference a SNAPSHOT version of a dependency. Instead, modules will
>> > reference a released version. This hold whether the dependency
>> is on
>> > another Tuscany Java SCA module or third-party software. For
>> example, the
>> > kernel, SDO, Spring, or ActiveMQ. Another way of viewing this
>> is that
>> > dependencies on other Tuscany modules are treated as if they were
>> > third-party software. Sometimes a module may choose to work off a
>> > SNAPSHOT version. If that is the case, the developers of the
>> module are
>> > responsible for keeping up with changes as the SNAPSHOT version is
>> > updated. Consequently, relying on a SNAPSHOT version may result in
>> > instability. It will more often be the case that modules will
>> upgrade to
>> > a new released version of a dependency. From a process
>> standpoint, there
>> > should be no difference between upgrading Axis2 and Tuscany kernel
>> > versions.
>> >
>> > 4. Samples will be grouped with their respective modules. For
>> example,
>> > the JavaScript samples would be grouped with the JavaScript
>> extension
>> > module. Samples which span multiple technologies will be grouped
>> > separately and will behave the same as modules, i.e. they will
>> most
>> often
>> > reference released versions of dependencies. Grouping samples with
>> their
>> > extensions will allow them to be released without having to
>> release all
>> > of the other (unrelated) samples. It will also provide a more
>> modular
>> > distribution as end-users will receive only the samples they are
>> > interested in.
>> >
>> > 5. Modules will be released either independently or by grouping.
>> They
>> > will not be released with their dependencies. For example, the
>> Axis2
>> > extension and the WSDL to Java tool will be released
>> independently from
>> > kernel. This is the same process we have been following on a
>> more macro
>> > level between the SCA, SDO and DAS subprojects. This is more of a
>> > release "caravan" as opposed to "train". Modules can choose to
>> provide
>> > follow on releases after a new dependency version is published
>> (e.g.
>> > kernel, SDO, etc.) or they may choose to wait depending on the
>> module
>> > lifecycle.
>> >
>> > 6. Samples may be released with their extensions or independently;
>> it is
>> > up to the module.
>> >
>> > In practice, I would expect upstream modules such as kernel to
>> release
>> > early and often. When a downstream module is ready, it will
>> cutover to
>> > using the new released version of the upstream modules. If
>> downstream
>> > modules all rely on SNAPSHOT versions, we will wind up with the
>> same
>> > monolithic and unstable build we currently have since SNAPSHOTs
>> represent
>> > the state of HEAD. Sometimes a module will require a new
>> feature in a
>> > dependency. In this case, Tuscany dependencies will work the
>> same as
>> > third-party ones: either a new release is cut or SNAPSHOT is used.
>> >
>> > What happens when B and C reference incompatible versions of A and
>> > someone wants to use them together? For end-users, in the
>> runtime, we
>> > will load different versions of A using SCA deployment
>> mechanisms and
>> > classloader isolation. Similarly, in development, their
>> dependencies need
>> > to be isolated by referencing different versions of A and
>> making sure
>> the
>> > proper classloader isolation is in effect, otherwise they
>> cannot use
>> them
>> > together.
>> >
>> > Given this, specific comments inline...
>> >
>> > Jim
>> >
>> >
>> >> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
>> >> understand what you're saying and how this modular build scheme
>> is going
>> >> to work, and I'm still looking for answers to some of my
>> questions :)
>> >>
>> >> - Are we going to update snapshot Jars over time? or use a
>> >> <uniqueVersion>true</uniqueVersion> repository config to
>> publish unique
>> >> timestamped versions (which, if I understand correctly will
>> not update
>> >> over time)? or do we only want to use releases of pieces of
>> Tuscany to
>> >> build working assemblies?
>> >>
>> > By their nature SNAPSHOTS evolve over time. However,
>> "working" assemblies
>> > should generally never reference SNAPSHOT versions as they change
>> causing
>> > instability. Rather, working assemblies should reference released
>> > versions of dependencies.
>> >
>> >> - If we're going to use timestamped snapshots, does anybody
>> know how
>> to
>> >> reference a specific timestamp (I couldn't figure this out
>> from the
>> >> Maven docs).
>> >>
>> > I don't think we need to reference specific timestamps. Either
>> a module
>> > references a released version or SNAPSHOT. If it references the
>> latter,
>> > it is responsible for tracking changes. If the module developers
>> require
>> > ongoing stability, they should not reference SNAPSHOT.
>> >
>> >> - How do people in the group want to associate a specific SVN
>> revision
>> >> with a published snapshot? Jeremy, do you know the recommended
>> Maven
>> way
>> >> to do that?
>> >>
>> > We should never need to do this.
>> >
>> >> Thanks,
>> >>
>> >> --
>> >> Jean-Sebastien
>> >>
>> >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Luciano Resende <lu...@gmail.com>.
I'm trying to better understand and reflect about the day to day changes
that might come from this discussion, and here are some questions :
I think this scenario is really good between projects (e.g SCA and Axis,
and/or SCA and DAS), but does it really make sense to have DAS Container
from trunk not working with SCA from trunk ? I think this will be a side
effect of having a DAS container based on a old SCA or Kernel or any other
SNAPSHOT module.
Also, on the scenario where I'm working on the DAS container and need to
change/add functionality to DAS, how do I grab the source of the SNAPSHOT of
that DAS,make necessary updates, and start using that, instead of the
published SNAPSHOT ? Or I'll have to add the functionality to DAS, publish a
new SNAPSHOT (that might bring other instabilities) and then I can use it. ?
This would be a problem for interactive parallel development, no ?
Also, are we going to flood IPMC with release votes (I'm only counting the
final release votes), as we need to vote for DAS and SDO, Kernel, etc, once
that is released then we need to vote for all containers, etc no ?
Have we looked on how other Apache Projects are handling this ?
--
Luciano Resende
http://people.apache.org/~lresende
On 1/9/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> To better evaulate if the code base is ready to be a release, there are
> two
> useful techiques discribed in the "Better Builds with Maven" book
> (http://www.mergere.com/m2book_download.jsp):
>
> 6.9. Monitoring and Improving the Health of Your Dependencies
>
> Run "mvn site" to create dependency and dependency convergence
> reports.
>
> The report shows all of the dependencies included in all of the
> modules
> within the project. It also includes some statistics and reports on two
> important factors:
>
> * Whether the versions of dependencies used for each module is in
> alignment. This helps ensure your build is consistent and reduces the
> probability of introducing an accidental incompatibility.
>
> * Whether there are outstanding SNAPSHOT dependencies in the build,
> which indicates dependencies that are in development, and must be updated
> before the project can be released.
>
> 6.10. Monitoring and Improving the Health of Your Releases
>
> An important tool in determining whether a project is ready to be
> released is Clirr (http://clirr.sf.net/). Clirr detects whether the
> current
> version of a library has introduced any binary incompatibilities with the
> previous release.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jim Marino" <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, January 09, 2007 1:27 AM
> Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims
> missing
> jar dependency)
>
>
> >I know very little about Maven except to follow how it expects projects
> to
> >be structured and behave or it will inflict untold amounts of pain
> (which
> >is probably fair given its goal of trying to standardize project build
> >structures) :-) Here is how I picture things will work:
> >
> > 1. We decided that modules are either independent or grouped
> by function.
> > For example, the Axis2 binding extension and the WSDL to Java tool if
> it
> > is specific to Axis. Modules are grouped independently from their
> > dependencies. For example, the JPA extension is independent from the
> > Geronimo transaction manager since the two are not inherently tied
> > together (the former only requires a JTA implementation).
> >
> > 2. We also decided that modules will be organized in the source tree by
> > how they are released. For example, the Axis2 binding extension will be
> > grouped with the WSDL to Java tool. This will have the side effect of
> > solving the problem of specifying versions of common dependencies.
> >
> > 3. The above assumes modules will be developed independently or by how
> > they are grouped. Consequently, most of the time, they will never
> > reference a SNAPSHOT version of a dependency. Instead, modules will
> > reference a released version. This hold whether the dependency is on
> > another Tuscany Java SCA module or third-party software. For
> example, the
> > kernel, SDO, Spring, or ActiveMQ. Another way of viewing this is that
> > dependencies on other Tuscany modules are treated as if they were
> > third-party software. Sometimes a module may choose to work off a
> > SNAPSHOT version. If that is the case, the developers of the module are
> > responsible for keeping up with changes as the SNAPSHOT version is
> > updated. Consequently, relying on a SNAPSHOT version may result in
> > instability. It will more often be the case that modules will
> upgrade to
> > a new released version of a dependency. From a process
> standpoint, there
> > should be no difference between upgrading Axis2 and Tuscany kernel
> > versions.
> >
> > 4. Samples will be grouped with their respective modules. For example,
> > the JavaScript samples would be grouped with the JavaScript extension
> > module. Samples which span multiple technologies will be grouped
> > separately and will behave the same as modules, i.e. they will most
> often
> > reference released versions of dependencies. Grouping samples with
> their
> > extensions will allow them to be released without having to release all
> > of the other (unrelated) samples. It will also provide a more modular
> > distribution as end-users will receive only the samples they are
> > interested in.
> >
> > 5. Modules will be released either independently or by grouping. They
> > will not be released with their dependencies. For example, the Axis2
> > extension and the WSDL to Java tool will be released independently from
> > kernel. This is the same process we have been following on a more macro
> > level between the SCA, SDO and DAS subprojects. This is more of a
> > release "caravan" as opposed to "train". Modules can choose to provide
> > follow on releases after a new dependency version is published (e.g.
> > kernel, SDO, etc.) or they may choose to wait depending on the module
> > lifecycle.
> >
> > 6. Samples may be released with their extensions or independently;
> it is
> > up to the module.
> >
> > In practice, I would expect upstream modules such as kernel to release
> > early and often. When a downstream module is ready, it will cutover to
> > using the new released version of the upstream modules. If downstream
> > modules all rely on SNAPSHOT versions, we will wind up with the same
> > monolithic and unstable build we currently have since SNAPSHOTs
> represent
> > the state of HEAD. Sometimes a module will require a new feature in a
> > dependency. In this case, Tuscany dependencies will work the same as
> > third-party ones: either a new release is cut or SNAPSHOT is used.
> >
> > What happens when B and C reference incompatible versions of A and
> > someone wants to use them together? For end-users, in the runtime, we
> > will load different versions of A using SCA deployment mechanisms and
> > classloader isolation. Similarly, in development, their
> dependencies need
> > to be isolated by referencing different versions of A and making sure
> the
> > proper classloader isolation is in effect, otherwise they cannot use
> them
> > together.
> >
> > Given this, specific comments inline...
> >
> > Jim
> >
> >
> >> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
> >> understand what you're saying and how this modular build scheme
> is going
> >> to work, and I'm still looking for answers to some of my questions :)
> >>
> >> - Are we going to update snapshot Jars over time? or use a
> >> <uniqueVersion>true</uniqueVersion> repository config to
> publish unique
> >> timestamped versions (which, if I understand correctly will not update
> >> over time)? or do we only want to use releases of pieces of Tuscany to
> >> build working assemblies?
> >>
> > By their nature SNAPSHOTS evolve over time. However,
> "working" assemblies
> > should generally never reference SNAPSHOT versions as they change
> causing
> > instability. Rather, working assemblies should reference released
> > versions of dependencies.
> >
> >> - If we're going to use timestamped snapshots, does anybody know how
> to
> >> reference a specific timestamp (I couldn't figure this out from the
> >> Maven docs).
> >>
> > I don't think we need to reference specific timestamps. Either a module
> > references a released version or SNAPSHOT. If it references the latter,
> > it is responsible for tracking changes. If the module developers
> require
> > ongoing stability, they should not reference SNAPSHOT.
> >
> >> - How do people in the group want to associate a specific SVN revision
> >> with a published snapshot? Jeremy, do you know the recommended Maven
> way
> >> to do that?
> >>
> > We should never need to do this.
> >
> >> Thanks,
> >>
> >> --
> >> Jean-Sebastien
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
You probably have two ways to reference a particular version of a SNAPSHOT
if you need to do so.
1) The "Better Builds with Maven" book
(http://www.mergere.com/m2book_download.jsp), section: 7.6. Team Dependency
Management Using Snapshots"
Reference a specific version such as "xyz-1.0-20060211.131114-1" over
"xyz-1.0-SNAPSHOT"
2) http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins,
section: Deploying the plugin to an internal repository for use within your
company
Use the INTERNAL-r123456 versioning scheme.
I think Option 1 is less disruptive.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, January 08, 2007 9:46 PM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
> Jeremy Boynes wrote:
>> On Jan 8, 2007, at 5:42 PM, Jean-Sebastien Delfino wrote:
>>
>>> Jeremy Boynes wrote:
>>>> -1 - this is not the way Maven SNAPSHOTs work.
>>>> -- Jeremy
>>>>
>>>>>
>>>>> I'm not a maven expert but I think that we need:
>>>>> - an identification of a particular SNAPSHOT level, xyz-SNAPSHOT
>>>>> won't work, we need xyz-<level>-SNAPSHOT.
>>>>> - a way to associate a level with a particular SVN revision,
>>>>> xyz-r493223-SNAPSHOT is the most obvious to me.
>>>>> - a way to move levels without scrambling artifact ids, I imagine that
>>>>> the maven version attribute can be used for that.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --Jean-Sebastien
>>>
>>> What part of what I said are you disagreeing with? the requirements I
>>> was trying to spell out? or the use of revision names in the JAR names?
>>>
>>> Raymond was asking to use artifact ids and you didn't -1 that, is this
>>> what you think should be done?
>>>
>>> Earlier in this thread (which you just cut out), you said "published
>>> snapshots have a timestamp in the version so it is possible to refer to
>>> an older one if something in the latest causes problems". This will work
>>> as well for me, if there is a good way to associate a timestamped
>>> snapshot with a specific SVN revision (to know what exact level code
>>> we're running with).
>>>
>>> Can one of our maven experts help us understand how to get this
>>> timestamp in? is this done with <uniqueVersion>true</uniqueVersion> in
>>> your repository definition?
>>>
>>> How do we reference a specific timestamped version?
>>>
>>> --Jean-Sebastien
>>
>> Chill out man - you asked for thoughts and you got mine. Including a SVN
>> revision number in a SNAPSHOT reference just isn't how Maven works. The
>> very point of SNAPSHOTs is that they update over time so that people get
>> the latest version of a project under development. That by definition
>> makes them unstable and unsuitable for trying to assemble something known
>> to be working - if you want that, use a release.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
> understand what you're saying and how this modular build scheme is going
> to work, and I'm still looking for answers to some of my questions :)
>
> - Are we going to update snapshot Jars over time? or use a
> <uniqueVersion>true</uniqueVersion> repository config to publish unique
> timestamped versions (which, if I understand correctly will not update
> over time)? or do we only want to use releases of pieces of Tuscany to
> build working assemblies?
>
> - If we're going to use timestamped snapshots, does anybody know how to
> reference a specific timestamp (I couldn't figure this out from the Maven
> docs).
>
> - How do people in the group want to associate a specific SVN revision
> with a published snapshot? Jeremy, do you know the recommended Maven way
> to do that?
>
> Thanks,
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Nash wrote:
> Jeremy Boynes wrote:
>
>> On Jan 10, 2007, at 4:45 AM, Simon Nash wrote:
>>
>>> Jeremy Boynes wrote:
>>>
>>>> On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
>>>>
>>>>> I know very little about Maven except to follow how it expects
>>>>> projects to be structured and behave or it will inflict untold
>>>>> amounts of pain (which is probably fair given its goal of trying
>>>>> to standardize project build structures) :-) Here is how I
>>>>> picture things will work:
>>>>>
>>>> +1 on the general description (snipped for brevity).
>>>
>>>
>>> +1 on Jim's general description as well. I see the key points as:
>>> 1) Downstream modules (including the current HEAD versions) will
>>> normally depend on released versions of upstream modules, not
>>> on SNAPSHOTs.
>>> 2) Upstream modules will release often, so that downstream modules
>>> don't normally need to create a SNAPSHOT dependency to get
>>> important
>>> new function.
>>> 3) Where a downstream module does introduce a SNAPSHOT dependency,
>>> it becomes responsible for tracking that dependency and adjusting
>>> as necessary to keep up with updated SNAPSHOT versions of the
>>> upstream module.
>>> 4) We will use classloader isolation and multiple version support
>>> to manage the issue of incompatible dependencies, where possible.
>>> This won't deal with all cases, such as kernel SPI changes,
>>> where only one copy (I presume) can be loaded.
>>
>>
>>
>> I'd add an addition point:
>> 5) Upstream modules should avoid incompatible changes between SPI
>> versions. When they are needed, some heads-up should be provided so
>> that downstream users are not unduly impacted. This really applies to
>> inter-SNAPSHOT changes - we'd want to avoid such changes between
>> releases as much as possible but within a release cycle you may want
>> to refactor things a couple times.
>>
> +1
>
Sorry, I pressed Send a bit hastily.
A refinement of this principle is that when making "incompatible"
changes, it is sometimes possible to make them in a way that provides
some level of backwards compatibility. For example, if renaming a
method or adding a new parameter, the old method name or signature
can be kept around for a while rather than deleting it immediately.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy Boynes wrote:
> On Jan 10, 2007, at 4:45 AM, Simon Nash wrote:
>
>> Jeremy Boynes wrote:
>>
>>> On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
>>>
>>>> I know very little about Maven except to follow how it expects
>>>> projects to be structured and behave or it will inflict untold
>>>> amounts of pain (which is probably fair given its goal of trying
>>>> to standardize project build structures) :-) Here is how I
>>>> picture things will work:
>>>>
>>> +1 on the general description (snipped for brevity).
>>
>> +1 on Jim's general description as well. I see the key points as:
>> 1) Downstream modules (including the current HEAD versions) will
>> normally depend on released versions of upstream modules, not
>> on SNAPSHOTs.
>> 2) Upstream modules will release often, so that downstream modules
>> don't normally need to create a SNAPSHOT dependency to get important
>> new function.
>> 3) Where a downstream module does introduce a SNAPSHOT dependency,
>> it becomes responsible for tracking that dependency and adjusting
>> as necessary to keep up with updated SNAPSHOT versions of the
>> upstream module.
>> 4) We will use classloader isolation and multiple version support
>> to manage the issue of incompatible dependencies, where possible.
>> This won't deal with all cases, such as kernel SPI changes,
>> where only one copy (I presume) can be loaded.
>
>
> I'd add an addition point:
> 5) Upstream modules should avoid incompatible changes between SPI
> versions. When they are needed, some heads-up should be provided so
> that downstream users are not unduly impacted. This really applies to
> inter-SNAPSHOT changes - we'd want to avoid such changes between
> releases as much as possible but within a release cycle you may want to
> refactor things a couple times.
>
+1
Simon
> --
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 10, 2007, at 4:45 AM, Simon Nash wrote:
> Jeremy Boynes wrote:
>
>> On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
>>> I know very little about Maven except to follow how it expects
>>> projects to be structured and behave or it will inflict untold
>>> amounts of pain (which is probably fair given its goal of trying
>>> to standardize project build structures) :-) Here is how I
>>> picture things will work:
>>>
>> +1 on the general description (snipped for brevity).
> +1 on Jim's general description as well. I see the key points as:
> 1) Downstream modules (including the current HEAD versions) will
> normally depend on released versions of upstream modules, not
> on SNAPSHOTs.
> 2) Upstream modules will release often, so that downstream modules
> don't normally need to create a SNAPSHOT dependency to get
> important
> new function.
> 3) Where a downstream module does introduce a SNAPSHOT dependency,
> it becomes responsible for tracking that dependency and adjusting
> as necessary to keep up with updated SNAPSHOT versions of the
> upstream module.
> 4) We will use classloader isolation and multiple version support
> to manage the issue of incompatible dependencies, where possible.
> This won't deal with all cases, such as kernel SPI changes,
> where only one copy (I presume) can be loaded.
I'd add an addition point:
5) Upstream modules should avoid incompatible changes between SPI
versions. When they are needed, some heads-up should be provided so
that downstream users are not unduly impacted. This really applies to
inter-SNAPSHOT changes - we'd want to avoid such changes between
releases as much as possible but within a release cycle you may want
to refactor things a couple times.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy Boynes wrote:
>
> On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
>
>> I know very little about Maven except to follow how it expects
>> projects to be structured and behave or it will inflict untold
>> amounts of pain (which is probably fair given its goal of trying to
>> standardize project build structures) :-) Here is how I picture
>> things will work:
>>
>
> +1 on the general description (snipped for brevity).
>
+1 on Jim's general description as well. I see the key points as:
1) Downstream modules (including the current HEAD versions) will
normally depend on released versions of upstream modules, not
on SNAPSHOTs.
2) Upstream modules will release often, so that downstream modules
don't normally need to create a SNAPSHOT dependency to get important
new function.
3) Where a downstream module does introduce a SNAPSHOT dependency,
it becomes responsible for tracking that dependency and adjusting
as necessary to keep up with updated SNAPSHOT versions of the
upstream module.
4) We will use classloader isolation and multiple version support
to manage the issue of incompatible dependencies, where possible.
This won't deal with all cases, such as kernel SPI changes,
where only one copy (I presume) can be loaded.
>>
>>
>>> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
>>> understand what you're saying and how this modular build scheme is
>>> going to work, and I'm still looking for answers to some of my
>>> questions :)
>>>
>>> - Are we going to update snapshot Jars over time? or use a
>>> <uniqueVersion>true</uniqueVersion> repository config to publish
>>> unique timestamped versions (which, if I understand correctly will
>>> not update over time)? or do we only want to use releases of pieces
>>> of Tuscany to build working assemblies?
>>>
>> By their nature SNAPSHOTS evolve over time. However, "working"
>> assemblies should generally never reference SNAPSHOT versions as they
>> change causing instability. Rather, working assemblies should
>> reference released versions of dependencies.
>
>
> I would put less emphasis on "working" than on "released." We only use
> released pieces to build released assemblies, following the normal
> convention of not using SNAPSHOTs in any release.
>
I think "working" is the right goal to have. See points 1 and 3 in my
comments above. It's a significant overhead for a downstream module to
have a SNAPSHOT dependency on an upstream module, because of the need
to track and adjust to updated SNAPSHOTs. I would not expect developers
of downstream modules to want to have this burden unless it is necessary,
and if they do take it on then I would expect the upstream module to
create a new release soon to get back into stable dependency mode.
Simon
>>
>>> - If we're going to use timestamped snapshots, does anybody know how
>>> to reference a specific timestamp (I couldn't figure this out from
>>> the Maven docs).
>>>
>> I don't think we need to reference specific timestamps. Either a
>> module references a released version or SNAPSHOT. If it references
>> the latter, it is responsible for tracking changes. If the module
>> developers require ongoing stability, they should not reference
>> SNAPSHOT.
>>
>
> I don't think you can from the build. You can install that version in
> your repo as your SNAPSHOT and reference that - see the
> install:install-file goal.
>
>>> - How do people in the group want to associate a specific SVN
>>> revision with a published snapshot? Jeremy, do you know the
>>> recommended Maven way to do that?
>>>
>> We should never need to do this.
>
>
> I don't want to. I don't know a way in Maven to do that. It is not
> common practice.
> --
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
> I know very little about Maven except to follow how it expects
> projects to be structured and behave or it will inflict untold
> amounts of pain (which is probably fair given its goal of trying to
> standardize project build structures) :-) Here is how I picture
> things will work:
>
+1 on the general description (snipped for brevity).
>
>
>> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
>> understand what you're saying and how this modular build scheme is
>> going to work, and I'm still looking for answers to some of my
>> questions :)
>>
>> - Are we going to update snapshot Jars over time? or use a
>> <uniqueVersion>true</uniqueVersion> repository config to publish
>> unique timestamped versions (which, if I understand correctly will
>> not update over time)? or do we only want to use releases of
>> pieces of Tuscany to build working assemblies?
>>
> By their nature SNAPSHOTS evolve over time. However, "working"
> assemblies should generally never reference SNAPSHOT versions as
> they change causing instability. Rather, working assemblies should
> reference released versions of dependencies.
I would put less emphasis on "working" than on "released." We only
use released pieces to build released assemblies, following the
normal convention of not using SNAPSHOTs in any release.
>
>> - If we're going to use timestamped snapshots, does anybody know
>> how to reference a specific timestamp (I couldn't figure this out
>> from the Maven docs).
>>
> I don't think we need to reference specific timestamps. Either a
> module references a released version or SNAPSHOT. If it references
> the latter, it is responsible for tracking changes. If the module
> developers require ongoing stability, they should not reference
> SNAPSHOT.
>
I don't think you can from the build. You can install that version in
your repo as your SNAPSHOT and reference that - see the
install:install-file goal.
>> - How do people in the group want to associate a specific SVN
>> revision with a published snapshot? Jeremy, do you know the
>> recommended Maven way to do that?
>>
> We should never need to do this.
I don't want to. I don't know a way in Maven to do that. It is not
common practice.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
To better evaulate if the code base is ready to be a release, there are two
useful techiques discribed in the "Better Builds with Maven" book
(http://www.mergere.com/m2book_download.jsp):
6.9. Monitoring and Improving the Health of Your Dependencies
Run "mvn site" to create dependency and dependency convergence reports.
The report shows all of the dependencies included in all of the modules
within the project. It also includes some statistics and reports on two
important factors:
* Whether the versions of dependencies used for each module is in
alignment. This helps ensure your build is consistent and reduces the
probability of introducing an accidental incompatibility.
* Whether there are outstanding SNAPSHOT dependencies in the build,
which indicates dependencies that are in development, and must be updated
before the project can be released.
6.10. Monitoring and Improving the Health of Your Releases
An important tool in determining whether a project is ready to be
released is Clirr (http://clirr.sf.net/). Clirr detects whether the current
version of a library has introduced any binary incompatibilities with the
previous release.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, January 09, 2007 1:27 AM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
>I know very little about Maven except to follow how it expects projects to
>be structured and behave or it will inflict untold amounts of pain (which
>is probably fair given its goal of trying to standardize project build
>structures) :-) Here is how I picture things will work:
>
> 1. We decided that modules are either independent or grouped by function.
> For example, the Axis2 binding extension and the WSDL to Java tool if it
> is specific to Axis. Modules are grouped independently from their
> dependencies. For example, the JPA extension is independent from the
> Geronimo transaction manager since the two are not inherently tied
> together (the former only requires a JTA implementation).
>
> 2. We also decided that modules will be organized in the source tree by
> how they are released. For example, the Axis2 binding extension will be
> grouped with the WSDL to Java tool. This will have the side effect of
> solving the problem of specifying versions of common dependencies.
>
> 3. The above assumes modules will be developed independently or by how
> they are grouped. Consequently, most of the time, they will never
> reference a SNAPSHOT version of a dependency. Instead, modules will
> reference a released version. This hold whether the dependency is on
> another Tuscany Java SCA module or third-party software. For example, the
> kernel, SDO, Spring, or ActiveMQ. Another way of viewing this is that
> dependencies on other Tuscany modules are treated as if they were
> third-party software. Sometimes a module may choose to work off a
> SNAPSHOT version. If that is the case, the developers of the module are
> responsible for keeping up with changes as the SNAPSHOT version is
> updated. Consequently, relying on a SNAPSHOT version may result in
> instability. It will more often be the case that modules will upgrade to
> a new released version of a dependency. From a process standpoint, there
> should be no difference between upgrading Axis2 and Tuscany kernel
> versions.
>
> 4. Samples will be grouped with their respective modules. For example,
> the JavaScript samples would be grouped with the JavaScript extension
> module. Samples which span multiple technologies will be grouped
> separately and will behave the same as modules, i.e. they will most often
> reference released versions of dependencies. Grouping samples with their
> extensions will allow them to be released without having to release all
> of the other (unrelated) samples. It will also provide a more modular
> distribution as end-users will receive only the samples they are
> interested in.
>
> 5. Modules will be released either independently or by grouping. They
> will not be released with their dependencies. For example, the Axis2
> extension and the WSDL to Java tool will be released independently from
> kernel. This is the same process we have been following on a more macro
> level between the SCA, SDO and DAS subprojects. This is more of a
> release "caravan" as opposed to "train". Modules can choose to provide
> follow on releases after a new dependency version is published (e.g.
> kernel, SDO, etc.) or they may choose to wait depending on the module
> lifecycle.
>
> 6. Samples may be released with their extensions or independently; it is
> up to the module.
>
> In practice, I would expect upstream modules such as kernel to release
> early and often. When a downstream module is ready, it will cutover to
> using the new released version of the upstream modules. If downstream
> modules all rely on SNAPSHOT versions, we will wind up with the same
> monolithic and unstable build we currently have since SNAPSHOTs represent
> the state of HEAD. Sometimes a module will require a new feature in a
> dependency. In this case, Tuscany dependencies will work the same as
> third-party ones: either a new release is cut or SNAPSHOT is used.
>
> What happens when B and C reference incompatible versions of A and
> someone wants to use them together? For end-users, in the runtime, we
> will load different versions of A using SCA deployment mechanisms and
> classloader isolation. Similarly, in development, their dependencies need
> to be isolated by referencing different versions of A and making sure the
> proper classloader isolation is in effect, otherwise they cannot use them
> together.
>
> Given this, specific comments inline...
>
> Jim
>
>
>> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
>> understand what you're saying and how this modular build scheme is going
>> to work, and I'm still looking for answers to some of my questions :)
>>
>> - Are we going to update snapshot Jars over time? or use a
>> <uniqueVersion>true</uniqueVersion> repository config to publish unique
>> timestamped versions (which, if I understand correctly will not update
>> over time)? or do we only want to use releases of pieces of Tuscany to
>> build working assemblies?
>>
> By their nature SNAPSHOTS evolve over time. However, "working" assemblies
> should generally never reference SNAPSHOT versions as they change causing
> instability. Rather, working assemblies should reference released
> versions of dependencies.
>
>> - If we're going to use timestamped snapshots, does anybody know how to
>> reference a specific timestamp (I couldn't figure this out from the
>> Maven docs).
>>
> I don't think we need to reference specific timestamps. Either a module
> references a released version or SNAPSHOT. If it references the latter,
> it is responsible for tracking changes. If the module developers require
> ongoing stability, they should not reference SNAPSHOT.
>
>> - How do people in the group want to associate a specific SVN revision
>> with a published snapshot? Jeremy, do you know the recommended Maven way
>> to do that?
>>
> We should never need to do this.
>
>> Thanks,
>>
>> --
>> Jean-Sebastien
>>
>
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jim Marino <jm...@myromatours.com>.
I know very little about Maven except to follow how it expects
projects to be structured and behave or it will inflict untold
amounts of pain (which is probably fair given its goal of trying to
standardize project build structures) :-) Here is how I picture
things will work:
1. We decided that modules are either independent or grouped by
function. For example, the Axis2 binding extension and the WSDL to
Java tool if it is specific to Axis. Modules are grouped
independently from their dependencies. For example, the JPA extension
is independent from the Geronimo transaction manager since the two
are not inherently tied together (the former only requires a JTA
implementation).
2. We also decided that modules will be organized in the source tree
by how they are released. For example, the Axis2 binding extension
will be grouped with the WSDL to Java tool. This will have the side
effect of solving the problem of specifying versions of common
dependencies.
3. The above assumes modules will be developed independently or by
how they are grouped. Consequently, most of the time, they will never
reference a SNAPSHOT version of a dependency. Instead, modules will
reference a released version. This hold whether the dependency is on
another Tuscany Java SCA module or third-party software. For example,
the kernel, SDO, Spring, or ActiveMQ. Another way of viewing this is
that dependencies on other Tuscany modules are treated as if they
were third-party software. Sometimes a module may choose to work off
a SNAPSHOT version. If that is the case, the developers of the module
are responsible for keeping up with changes as the SNAPSHOT version
is updated. Consequently, relying on a SNAPSHOT version may result in
instability. It will more often be the case that modules will upgrade
to a new released version of a dependency. From a process standpoint,
there should be no difference between upgrading Axis2 and Tuscany
kernel versions.
4. Samples will be grouped with their respective modules. For
example, the JavaScript samples would be grouped with the JavaScript
extension module. Samples which span multiple technologies will be
grouped separately and will behave the same as modules, i.e. they
will most often reference released versions of dependencies. Grouping
samples with their extensions will allow them to be released without
having to release all of the other (unrelated) samples. It will also
provide a more modular distribution as end-users will receive only
the samples they are interested in.
5. Modules will be released either independently or by grouping. They
will not be released with their dependencies. For example, the Axis2
extension and the WSDL to Java tool will be released independently
from kernel. This is the same process we have been following on a
more macro level between the SCA, SDO and DAS subprojects. This is
more of a release "caravan" as opposed to "train". Modules can choose
to provide follow on releases after a new dependency version is
published (e.g. kernel, SDO, etc.) or they may choose to wait
depending on the module lifecycle.
6. Samples may be released with their extensions or independently; it
is up to the module.
In practice, I would expect upstream modules such as kernel to
release early and often. When a downstream module is ready, it will
cutover to using the new released version of the upstream modules. If
downstream modules all rely on SNAPSHOT versions, we will wind up
with the same monolithic and unstable build we currently have since
SNAPSHOTs represent the state of HEAD. Sometimes a module will
require a new feature in a dependency. In this case, Tuscany
dependencies will work the same as third-party ones: either a new
release is cut or SNAPSHOT is used.
What happens when B and C reference incompatible versions of A and
someone wants to use them together? For end-users, in the runtime, we
will load different versions of A using SCA deployment mechanisms and
classloader isolation. Similarly, in development, their dependencies
need to be isolated by referencing different versions of A and making
sure the proper classloader isolation is in effect, otherwise they
cannot use them together.
Given this, specific comments inline...
Jim
> I'm perfectly cool. Thanks for your thoughts, I'm just trying to
> understand what you're saying and how this modular build scheme is
> going to work, and I'm still looking for answers to some of my
> questions :)
>
> - Are we going to update snapshot Jars over time? or use a
> <uniqueVersion>true</uniqueVersion> repository config to publish
> unique timestamped versions (which, if I understand correctly will
> not update over time)? or do we only want to use releases of pieces
> of Tuscany to build working assemblies?
>
By their nature SNAPSHOTS evolve over time. However, "working"
assemblies should generally never reference SNAPSHOT versions as they
change causing instability. Rather, working assemblies should
reference released versions of dependencies.
> - If we're going to use timestamped snapshots, does anybody know
> how to reference a specific timestamp (I couldn't figure this out
> from the Maven docs).
>
I don't think we need to reference specific timestamps. Either a
module references a released version or SNAPSHOT. If it references
the latter, it is responsible for tracking changes. If the module
developers require ongoing stability, they should not reference
SNAPSHOT.
> - How do people in the group want to associate a specific SVN
> revision with a published snapshot? Jeremy, do you know the
> recommended Maven way to do that?
>
We should never need to do this.
> Thanks,
>
> --
> Jean-Sebastien
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> On Jan 8, 2007, at 5:42 PM, Jean-Sebastien Delfino wrote:
>
>> Jeremy Boynes wrote:
>>> -1 - this is not the way Maven SNAPSHOTs work.
>>> -- Jeremy
>>>
>>>>
>>>> I'm not a maven expert but I think that we need:
>>>> - an identification of a particular SNAPSHOT level, xyz-SNAPSHOT
>>>> won't work, we need xyz-<level>-SNAPSHOT.
>>>> - a way to associate a level with a particular SVN revision,
>>>> xyz-r493223-SNAPSHOT is the most obvious to me.
>>>> - a way to move levels without scrambling artifact ids, I imagine
>>>> that the maven version attribute can be used for that.
>>>>
>>>> Thoughts?
>>>>
>>>> --Jean-Sebastien
>>
>> What part of what I said are you disagreeing with? the requirements I
>> was trying to spell out? or the use of revision names in the JAR names?
>>
>> Raymond was asking to use artifact ids and you didn't -1 that, is
>> this what you think should be done?
>>
>> Earlier in this thread (which you just cut out), you said "published
>> snapshots have a timestamp in the version so it is possible to refer
>> to an older one if something in the latest causes problems". This
>> will work as well for me, if there is a good way to associate a
>> timestamped snapshot with a specific SVN revision (to know what exact
>> level code we're running with).
>>
>> Can one of our maven experts help us understand how to get this
>> timestamp in? is this done with <uniqueVersion>true</uniqueVersion>
>> in your repository definition?
>>
>> How do we reference a specific timestamped version?
>>
>> --Jean-Sebastien
>
> Chill out man - you asked for thoughts and you got mine. Including a
> SVN revision number in a SNAPSHOT reference just isn't how Maven
> works. The very point of SNAPSHOTs is that they update over time so
> that people get the latest version of a project under development.
> That by definition makes them unstable and unsuitable for trying to
> assemble something known to be working - if you want that, use a release.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I'm perfectly cool. Thanks for your thoughts, I'm just trying to
understand what you're saying and how this modular build scheme is going
to work, and I'm still looking for answers to some of my questions :)
- Are we going to update snapshot Jars over time? or use a
<uniqueVersion>true</uniqueVersion> repository config to publish unique
timestamped versions (which, if I understand correctly will not update
over time)? or do we only want to use releases of pieces of Tuscany to
build working assemblies?
- If we're going to use timestamped snapshots, does anybody know how to
reference a specific timestamp (I couldn't figure this out from the
Maven docs).
- How do people in the group want to associate a specific SVN revision
with a published snapshot? Jeremy, do you know the recommended Maven way
to do that?
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 8, 2007, at 5:42 PM, Jean-Sebastien Delfino wrote:
> Jeremy Boynes wrote:
>> -1 - this is not the way Maven SNAPSHOTs work.
>> --
>> Jeremy
>>
>>>
>>> I'm not a maven expert but I think that we need:
>>> - an identification of a particular SNAPSHOT level, xyz-SNAPSHOT
>>> won't work, we need xyz-<level>-SNAPSHOT.
>>> - a way to associate a level with a particular SVN revision, xyz-
>>> r493223-SNAPSHOT is the most obvious to me.
>>> - a way to move levels without scrambling artifact ids, I imagine
>>> that the maven version attribute can be used for that.
>>>
>>> Thoughts?
>>>
>>> --Jean-Sebastien
>
> What part of what I said are you disagreeing with? the requirements
> I was trying to spell out? or the use of revision names in the JAR
> names?
>
> Raymond was asking to use artifact ids and you didn't -1 that, is
> this what you think should be done?
>
> Earlier in this thread (which you just cut out), you said
> "published snapshots have a timestamp in the version so it is
> possible to refer to an older one if something in the latest causes
> problems". This will work as well for me, if there is a good way to
> associate a timestamped snapshot with a specific SVN revision (to
> know what exact level code we're running with).
>
> Can one of our maven experts help us understand how to get this
> timestamp in? is this done with <uniqueVersion>true</
> uniqueVersion> in your repository definition?
>
> How do we reference a specific timestamped version?
>
> --
> Jean-Sebastien
Chill out man - you asked for thoughts and you got mine. Including a
SVN revision number in a SNAPSHOT reference just isn't how Maven
works. The very point of SNAPSHOTs is that they update over time so
that people get the latest version of a project under development.
That by definition makes them unstable and unsuitable for trying to
assemble something known to be working - if you want that, use a
release.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> -1 - this is not the way Maven SNAPSHOTs work.
> --
> Jeremy
>
>>
>> I'm not a maven expert but I think that we need:
>> - an identification of a particular SNAPSHOT level, xyz-SNAPSHOT
>> won't work, we need xyz-<level>-SNAPSHOT.
>> - a way to associate a level with a particular SVN revision,
>> xyz-r493223-SNAPSHOT is the most obvious to me.
>> - a way to move levels without scrambling artifact ids, I imagine
>> that the maven version attribute can be used for that.
>>
>> Thoughts?
>>
>> --Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
What part of what I said are you disagreeing with? the requirements I
was trying to spell out? or the use of revision names in the JAR names?
Raymond was asking to use artifact ids and you didn't -1 that, is this
what you think should be done?
Earlier in this thread (which you just cut out), you said "published
snapshots have a timestamp in the version so it is possible to refer to
an older one if something in the latest causes problems". This will work
as well for me, if there is a good way to associate a timestamped
snapshot with a specific SVN revision (to know what exact level code
we're running with).
Can one of our maven experts help us understand how to get this
timestamp in? is this done with <uniqueVersion>true</uniqueVersion> in
your repository definition?
How do we reference a specific timestamped version?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
-1 - this is not the way Maven SNAPSHOTs work.
--
Jeremy
>
> I'm not a maven expert but I think that we need:
> - an identification of a particular SNAPSHOT level, xyz-SNAPSHOT
> won't work, we need xyz-<level>-SNAPSHOT.
> - a way to associate a level with a particular SVN revision, xyz-
> r493223-SNAPSHOT is the most obvious to me.
> - a way to move levels without scrambling artifact ids, I imagine
> that the maven version attribute can be used for that.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Is it possible to publish SNAPSHOT jars in format of
> "xyz-r123456-SNAPSHOT.jar" instead of "xyz-SNAPSHOT.jar"? Or are you
> proposing to use artifact id as "xyz-r123456" instead of "xyz"?
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, January 08, 2007 9:51 AM
> Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims
> missing jar dependency)
>
>
>> Simon Nash wrote:
>>> Thanks for the pointer. I have downloaded the book and I have read
>>> the sections describing SNAPSHOTs. I look forward to reading the
>>> remainder.
>>>
>>> My reference to a "user" was intended to mean anyone needing to put
>>> together a working combination of already built SNAPSHOT modules for
>>> the selection of sca infrastructure components that they need.
>>> Project developers would certainly fall into this category. If they
>>> are developing code inside one module, they can assemble a test
>>> environment for that code from other pre-built modules that are in
>>> a known working state. This should be the main benefit of having
>>> a modular build.
>>>
>>> My main point was that using SNAPSHOT dependencies between all the
>>> separately built sca modules (kernel and extensions) leads to tight
>>> coupling when new SNAPSHOTs of upstream modules are published,
>>> because it is necessary to simultaneously publish matching SNAPSHOTs
>>> of downstream modules to keep them in sync. For example, publication
>>> of a new kernel SNAPSHOT with an SPI change would require republication
>>> of SNAPSHOTs for all extensions that depend on the changed SPI. If
>>> these dependent extensions are not republished as SNAPSHOTs, the
>>> set of latest SNAPSHOTs will no longer be self-consistent. Having the
>>> downstream components depend on a known upstream level (however
>>> this is done) avoids this problem.
>>>
>>> Does anyone else think this is a problem that should concern us?
>>>
>>> Simon
>>>
>>> Jeremy Boynes wrote:
>>>
>>>> You misunderstand the purpose of SNAPSHOTs. They do not affect
>>>> users as released code does not reference them. They provide a way
>>>> for project developers to cooperate during a release development
>>>> cycle without requiring everyone to build everything all the time
>>>> (which as we have seen does not scale). They also provide a
>>>> mechanism that does not require downstream developers to update
>>>> references to every build number/timestamp every time a new
>>>> unstable build is published (which does not scale either but for
>>>> different reasons).
>>>>
>>>> There's a good reference on how Maven works here: http://
>>>> www.mergere.com/m2book_download.jsp
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>> On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
>>>>
>>>>> I'm a bit concerned about moving to a highly modularized build where
>>>>> all the dependencies between the modules are defined as latest
>>>>> SNAPSHOT dependencies.
>>>>>
>>>>> By doing this we would solve the problem of the fragile monolothic
>>>>> build, but we would create a different kind of fragility where
>>>>> republication of a SNAPSHOT for one module can break the currently
>>>>> published SNAPSHOTs of other modules that have dependencies on it.
>>>>>
>>>>> This kind of fragility would show up at runtime when a combination
>>>>> of incompatible latest published SNAPSHOTs is brought together in
>>>>> a user's environment. The only way to prevent this from happening
>>>>> is to rebuild and republish all downstream dependent SNAPSHOTs
>>>>> whenever an upstream SNAPSHOT is changed and republished, which
>>>>> would effectively be re-introducing tight coupling by the back door.
>>>>>
>>>>> If the published downstream modules depend on upstream releases,
>>>>> then this problem does not occur. It would still not be possible
>>>>> for a user to combine all latest SNAPSHOTs and have the combination
>>>>> work, but it would be possible to deduce from the dependency chain
>>>>> which downstream modules were built and tested with a given release
>>>>> of an upstream module, and reliably produce a working combination.
>>>>>
>>>>> A slight modification of this scheme would be to make downstream
>>>>> modules explicitly dependent on timestamped versions of upstream
>>>>> SNAPSHOTs, instead of being dependent on the latest published
>>>>> SNAPSHOT. Moving to a different version of an upstream dependency
>>>>> would require explicit action from a downstream dependency by
>>>>> modifying its pom.xml file. This requires greater version dependency
>>>>> awareness on the part of Tuscany developers, with the benefit that
>>>>> by making version dependencies explicit rather than implicit, it
>>>>> would be possible to create a tool that allows a user to bring
>>>>> together a compatible set of timestamped SNAPSHOTs. This approach
>>>>> solves the problem of "latest SNAPSHOT hell" without the overhead
>>>>> of creating a lot of releases for relatively minor changes.
>>>>>
>>>>> Simon
>>>>>
>>>>> Jeremy Boynes wrote:
>>>>>
>>>>>> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>>>>>>
>>>>>>> I'm trying to understand the new modularized build scheme, and
>>>>>>> have a few questions:
>>>>>>>
>>>>>>> I'm not quite sure what you mean by published dependencies?
>>>>>>> releases? snapshots?
>>>>>>>
>>>>>> Anything that a module depends on that is not built by the
>>>>>> current build run. It could be from Tuscany, it could be from
>>>>>> another project; it could be released (preferable) or it could
>>>>>> be a snapshot.
>>>>>> Basically, if it's not built by the current run then it needs to
>>>>>> have been published somewhere for the build to work.
>>>>>>
>>>>>>> What are the criteria for deciding to re-publish a Tuscany jar?
>>>>>>
>>>>>> For a release, we need to release it :-)
>>>>>> For a snapshot, any committer can publish one at any time and
>>>>>> should if there is function in there that other modules depend
>>>>>> on. For example, adding a new annotation to spec would be a good
>>>>>> reason to republish the spec snapshot.
>>>>>>
>>>>>>>
>>>>>>> Is the online repository going to keep multiple levels of
>>>>>>> published dependencies?
>>>>>>
>>>>>> It does. Releases generally live forever, snapshots get removed
>>>>>> periodically when they are deemed obsolete. Published snapshots
>>>>>> have a timestamp in the version so it is possible to refer to an
>>>>>> older one if something in the latest causes problems; referring
>>>>>> to an obsolete snapshot is generally problematic as at some
>>>>>> point it will go away.
>>>>>> HTH
>>>>>> --
>>>>>> 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
>>>
>>>
>>
>> Simon,
>>
>> I think that what you're describing is a problem only if the jar is
>> published as xyz-SNAPSHOT.jar without identifying the specific level
>> of code in the jar. If it is published as xyz-r493223-SNAPSHOT.jar
>> for example (or another form of identification of a specific level)
>> then a new revision of the SPI will be published in a different jar
>> (xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223
>> will continue to reference xyz-r493223-SNAPSHOT.jar, components that
>> want to move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
>>
>> So if I understand correctly, this scheme allows the core components
>> to move on with changes without breaking the others that depend on
>> the core. These components become responsible for catching up with
>> core changes when they wish or can do it (and they better do it
>> frequently to avoid surprises when they move up levels). Whoever
>> wants to build a working distribution or run an end to end scenario
>> becomes responsible for putting the pieces together, and coordinating
>> and working with the various component providers to make sure that
>> they all work on compatible levels of the core jars.
>>
>> Does that make sense?
>>
>> I think it would help a lot if somebody who understands this new
>> scheme better than me could educate us on the steps that the various
>> people on the project will have to go through when a change occurs in
>> one of the core Jars.
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
I'm not a maven expert but I think that we need:
- an identification of a particular SNAPSHOT level, xyz-SNAPSHOT won't
work, we need xyz-<level>-SNAPSHOT.
- a way to associate a level with a particular SVN revision,
xyz-r493223-SNAPSHOT is the most obvious to me.
- a way to move levels without scrambling artifact ids, I imagine that
the maven version attribute can be used for that.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Is it possible to publish SNAPSHOT jars in format of
"xyz-r123456-SNAPSHOT.jar" instead of "xyz-SNAPSHOT.jar"? Or are you
proposing to use artifact id as "xyz-r123456" instead of "xyz"?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, January 08, 2007 9:51 AM
Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
> Simon Nash wrote:
>> Thanks for the pointer. I have downloaded the book and I have read
>> the sections describing SNAPSHOTs. I look forward to reading the
>> remainder.
>>
>> My reference to a "user" was intended to mean anyone needing to put
>> together a working combination of already built SNAPSHOT modules for
>> the selection of sca infrastructure components that they need.
>> Project developers would certainly fall into this category. If they
>> are developing code inside one module, they can assemble a test
>> environment for that code from other pre-built modules that are in
>> a known working state. This should be the main benefit of having
>> a modular build.
>>
>> My main point was that using SNAPSHOT dependencies between all the
>> separately built sca modules (kernel and extensions) leads to tight
>> coupling when new SNAPSHOTs of upstream modules are published,
>> because it is necessary to simultaneously publish matching SNAPSHOTs
>> of downstream modules to keep them in sync. For example, publication
>> of a new kernel SNAPSHOT with an SPI change would require republication
>> of SNAPSHOTs for all extensions that depend on the changed SPI. If
>> these dependent extensions are not republished as SNAPSHOTs, the
>> set of latest SNAPSHOTs will no longer be self-consistent. Having the
>> downstream components depend on a known upstream level (however
>> this is done) avoids this problem.
>>
>> Does anyone else think this is a problem that should concern us?
>>
>> Simon
>>
>> Jeremy Boynes wrote:
>>
>>> You misunderstand the purpose of SNAPSHOTs. They do not affect users as
>>> released code does not reference them. They provide a way for project
>>> developers to cooperate during a release development cycle without
>>> requiring everyone to build everything all the time (which as we have
>>> seen does not scale). They also provide a mechanism that does not
>>> require downstream developers to update references to every build
>>> number/timestamp every time a new unstable build is published (which
>>> does not scale either but for different reasons).
>>>
>>> There's a good reference on how Maven works here: http://
>>> www.mergere.com/m2book_download.jsp
>>>
>>> --
>>> Jeremy
>>>
>>> On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
>>>
>>>> I'm a bit concerned about moving to a highly modularized build where
>>>> all the dependencies between the modules are defined as latest
>>>> SNAPSHOT dependencies.
>>>>
>>>> By doing this we would solve the problem of the fragile monolothic
>>>> build, but we would create a different kind of fragility where
>>>> republication of a SNAPSHOT for one module can break the currently
>>>> published SNAPSHOTs of other modules that have dependencies on it.
>>>>
>>>> This kind of fragility would show up at runtime when a combination
>>>> of incompatible latest published SNAPSHOTs is brought together in
>>>> a user's environment. The only way to prevent this from happening
>>>> is to rebuild and republish all downstream dependent SNAPSHOTs
>>>> whenever an upstream SNAPSHOT is changed and republished, which
>>>> would effectively be re-introducing tight coupling by the back door.
>>>>
>>>> If the published downstream modules depend on upstream releases,
>>>> then this problem does not occur. It would still not be possible
>>>> for a user to combine all latest SNAPSHOTs and have the combination
>>>> work, but it would be possible to deduce from the dependency chain
>>>> which downstream modules were built and tested with a given release
>>>> of an upstream module, and reliably produce a working combination.
>>>>
>>>> A slight modification of this scheme would be to make downstream
>>>> modules explicitly dependent on timestamped versions of upstream
>>>> SNAPSHOTs, instead of being dependent on the latest published
>>>> SNAPSHOT. Moving to a different version of an upstream dependency
>>>> would require explicit action from a downstream dependency by
>>>> modifying its pom.xml file. This requires greater version dependency
>>>> awareness on the part of Tuscany developers, with the benefit that
>>>> by making version dependencies explicit rather than implicit, it
>>>> would be possible to create a tool that allows a user to bring
>>>> together a compatible set of timestamped SNAPSHOTs. This approach
>>>> solves the problem of "latest SNAPSHOT hell" without the overhead
>>>> of creating a lot of releases for relatively minor changes.
>>>>
>>>> Simon
>>>>
>>>> Jeremy Boynes wrote:
>>>>
>>>>> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>>>>>
>>>>>> I'm trying to understand the new modularized build scheme, and have
>>>>>> a few questions:
>>>>>>
>>>>>> I'm not quite sure what you mean by published dependencies?
>>>>>> releases? snapshots?
>>>>>>
>>>>> Anything that a module depends on that is not built by the current
>>>>> build run. It could be from Tuscany, it could be from another
>>>>> project; it could be released (preferable) or it could be a snapshot.
>>>>> Basically, if it's not built by the current run then it needs to have
>>>>> been published somewhere for the build to work.
>>>>>
>>>>>> What are the criteria for deciding to re-publish a Tuscany jar?
>>>>>
>>>>> For a release, we need to release it :-)
>>>>> For a snapshot, any committer can publish one at any time and should
>>>>> if there is function in there that other modules depend on. For
>>>>> example, adding a new annotation to spec would be a good reason to
>>>>> republish the spec snapshot.
>>>>>
>>>>>>
>>>>>> Is the online repository going to keep multiple levels of published
>>>>>> dependencies?
>>>>>
>>>>> It does. Releases generally live forever, snapshots get removed
>>>>> periodically when they are deemed obsolete. Published snapshots have
>>>>> a timestamp in the version so it is possible to refer to an older one
>>>>> if something in the latest causes problems; referring to an obsolete
>>>>> snapshot is generally problematic as at some point it will go away.
>>>>> HTH
>>>>> --
>>>>> 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
>>
>>
>
> Simon,
>
> I think that what you're describing is a problem only if the jar is
> published as xyz-SNAPSHOT.jar without identifying the specific level of
> code in the jar. If it is published as xyz-r493223-SNAPSHOT.jar for
> example (or another form of identification of a specific level) then a new
> revision of the SPI will be published in a different jar
> (xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223 will
> continue to reference xyz-r493223-SNAPSHOT.jar, components that want to
> move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
>
> So if I understand correctly, this scheme allows the core components to
> move on with changes without breaking the others that depend on the core.
> These components become responsible for catching up with core changes when
> they wish or can do it (and they better do it frequently to avoid
> surprises when they move up levels). Whoever wants to build a working
> distribution or run an end to end scenario becomes responsible for putting
> the pieces together, and coordinating and working with the various
> component providers to make sure that they all work on compatible levels
> of the core jars.
>
> Does that make sense?
>
> I think it would help a lot if somebody who understands this new scheme
> better than me could educate us on the steps that the various people on
> the project will have to go through when a change occurs in one of the
> core Jars.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Thanks for the pointer. I have downloaded the book and I have read
> the sections describing SNAPSHOTs. I look forward to reading the
> remainder.
>
> My reference to a "user" was intended to mean anyone needing to put
> together a working combination of already built SNAPSHOT modules for
> the selection of sca infrastructure components that they need.
> Project developers would certainly fall into this category. If they
> are developing code inside one module, they can assemble a test
> environment for that code from other pre-built modules that are in
> a known working state. This should be the main benefit of having
> a modular build.
>
> My main point was that using SNAPSHOT dependencies between all the
> separately built sca modules (kernel and extensions) leads to tight
> coupling when new SNAPSHOTs of upstream modules are published,
> because it is necessary to simultaneously publish matching SNAPSHOTs
> of downstream modules to keep them in sync. For example, publication
> of a new kernel SNAPSHOT with an SPI change would require republication
> of SNAPSHOTs for all extensions that depend on the changed SPI. If
> these dependent extensions are not republished as SNAPSHOTs, the
> set of latest SNAPSHOTs will no longer be self-consistent. Having the
> downstream components depend on a known upstream level (however
> this is done) avoids this problem.
>
> Does anyone else think this is a problem that should concern us?
>
> Simon
>
> Jeremy Boynes wrote:
>
>> You misunderstand the purpose of SNAPSHOTs. They do not affect users
>> as released code does not reference them. They provide a way for
>> project developers to cooperate during a release development cycle
>> without requiring everyone to build everything all the time (which
>> as we have seen does not scale). They also provide a mechanism that
>> does not require downstream developers to update references to every
>> build number/timestamp every time a new unstable build is published
>> (which does not scale either but for different reasons).
>>
>> There's a good reference on how Maven works here: http://
>> www.mergere.com/m2book_download.jsp
>>
>> --
>> Jeremy
>>
>> On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
>>
>>> I'm a bit concerned about moving to a highly modularized build where
>>> all the dependencies between the modules are defined as latest
>>> SNAPSHOT dependencies.
>>>
>>> By doing this we would solve the problem of the fragile monolothic
>>> build, but we would create a different kind of fragility where
>>> republication of a SNAPSHOT for one module can break the currently
>>> published SNAPSHOTs of other modules that have dependencies on it.
>>>
>>> This kind of fragility would show up at runtime when a combination
>>> of incompatible latest published SNAPSHOTs is brought together in
>>> a user's environment. The only way to prevent this from happening
>>> is to rebuild and republish all downstream dependent SNAPSHOTs
>>> whenever an upstream SNAPSHOT is changed and republished, which
>>> would effectively be re-introducing tight coupling by the back door.
>>>
>>> If the published downstream modules depend on upstream releases,
>>> then this problem does not occur. It would still not be possible
>>> for a user to combine all latest SNAPSHOTs and have the combination
>>> work, but it would be possible to deduce from the dependency chain
>>> which downstream modules were built and tested with a given release
>>> of an upstream module, and reliably produce a working combination.
>>>
>>> A slight modification of this scheme would be to make downstream
>>> modules explicitly dependent on timestamped versions of upstream
>>> SNAPSHOTs, instead of being dependent on the latest published
>>> SNAPSHOT. Moving to a different version of an upstream dependency
>>> would require explicit action from a downstream dependency by
>>> modifying its pom.xml file. This requires greater version dependency
>>> awareness on the part of Tuscany developers, with the benefit that
>>> by making version dependencies explicit rather than implicit, it
>>> would be possible to create a tool that allows a user to bring
>>> together a compatible set of timestamped SNAPSHOTs. This approach
>>> solves the problem of "latest SNAPSHOT hell" without the overhead
>>> of creating a lot of releases for relatively minor changes.
>>>
>>> Simon
>>>
>>> Jeremy Boynes wrote:
>>>
>>>> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>>>>
>>>>> I'm trying to understand the new modularized build scheme, and
>>>>> have a few questions:
>>>>>
>>>>> I'm not quite sure what you mean by published dependencies?
>>>>> releases? snapshots?
>>>>>
>>>> Anything that a module depends on that is not built by the
>>>> current build run. It could be from Tuscany, it could be from
>>>> another project; it could be released (preferable) or it could be
>>>> a snapshot.
>>>> Basically, if it's not built by the current run then it needs to
>>>> have been published somewhere for the build to work.
>>>>
>>>>> What are the criteria for deciding to re-publish a Tuscany jar?
>>>>
>>>> For a release, we need to release it :-)
>>>> For a snapshot, any committer can publish one at any time and
>>>> should if there is function in there that other modules depend
>>>> on. For example, adding a new annotation to spec would be a good
>>>> reason to republish the spec snapshot.
>>>>
>>>>>
>>>>> Is the online repository going to keep multiple levels of
>>>>> published dependencies?
>>>>
>>>> It does. Releases generally live forever, snapshots get removed
>>>> periodically when they are deemed obsolete. Published snapshots
>>>> have a timestamp in the version so it is possible to refer to an
>>>> older one if something in the latest causes problems; referring
>>>> to an obsolete snapshot is generally problematic as at some point
>>>> it will go away.
>>>> HTH
>>>> --
>>>> 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
>
>
Simon,
I think that what you're describing is a problem only if the jar is
published as xyz-SNAPSHOT.jar without identifying the specific level of
code in the jar. If it is published as xyz-r493223-SNAPSHOT.jar for
example (or another form of identification of a specific level) then a
new revision of the SPI will be published in a different jar
(xyz-r493224-SNAPSHOT.jar). Components that want to stay on r493223
will continue to reference xyz-r493223-SNAPSHOT.jar, components that
want to move on to r493224 will reference xyz-r493224-SNAPSHOT.jar.
So if I understand correctly, this scheme allows the core components to
move on with changes without breaking the others that depend on the
core. These components become responsible for catching up with core
changes when they wish or can do it (and they better do it frequently to
avoid surprises when they move up levels). Whoever wants to build a
working distribution or run an end to end scenario becomes responsible
for putting the pieces together, and coordinating and working with the
various component providers to make sure that they all work on
compatible levels of the core jars.
Does that make sense?
I think it would help a lot if somebody who understands this new scheme
better than me could educate us on the steps that the various people on
the project will have to go through when a change occurs in one of the
core Jars.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks for the pointer. I have downloaded the book and I have read
the sections describing SNAPSHOTs. I look forward to reading the
remainder.
My reference to a "user" was intended to mean anyone needing to put
together a working combination of already built SNAPSHOT modules for
the selection of sca infrastructure components that they need.
Project developers would certainly fall into this category. If they
are developing code inside one module, they can assemble a test
environment for that code from other pre-built modules that are in
a known working state. This should be the main benefit of having
a modular build.
My main point was that using SNAPSHOT dependencies between all the
separately built sca modules (kernel and extensions) leads to tight
coupling when new SNAPSHOTs of upstream modules are published,
because it is necessary to simultaneously publish matching SNAPSHOTs
of downstream modules to keep them in sync. For example, publication
of a new kernel SNAPSHOT with an SPI change would require republication
of SNAPSHOTs for all extensions that depend on the changed SPI. If
these dependent extensions are not republished as SNAPSHOTs, the
set of latest SNAPSHOTs will no longer be self-consistent. Having the
downstream components depend on a known upstream level (however
this is done) avoids this problem.
Does anyone else think this is a problem that should concern us?
Simon
Jeremy Boynes wrote:
> You misunderstand the purpose of SNAPSHOTs. They do not affect users as
> released code does not reference them. They provide a way for project
> developers to cooperate during a release development cycle without
> requiring everyone to build everything all the time (which as we have
> seen does not scale). They also provide a mechanism that does not
> require downstream developers to update references to every build
> number/timestamp every time a new unstable build is published (which
> does not scale either but for different reasons).
>
> There's a good reference on how Maven works here: http://
> www.mergere.com/m2book_download.jsp
>
> --
> Jeremy
>
> On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
>
>> I'm a bit concerned about moving to a highly modularized build where
>> all the dependencies between the modules are defined as latest
>> SNAPSHOT dependencies.
>>
>> By doing this we would solve the problem of the fragile monolothic
>> build, but we would create a different kind of fragility where
>> republication of a SNAPSHOT for one module can break the currently
>> published SNAPSHOTs of other modules that have dependencies on it.
>>
>> This kind of fragility would show up at runtime when a combination
>> of incompatible latest published SNAPSHOTs is brought together in
>> a user's environment. The only way to prevent this from happening
>> is to rebuild and republish all downstream dependent SNAPSHOTs
>> whenever an upstream SNAPSHOT is changed and republished, which
>> would effectively be re-introducing tight coupling by the back door.
>>
>> If the published downstream modules depend on upstream releases,
>> then this problem does not occur. It would still not be possible
>> for a user to combine all latest SNAPSHOTs and have the combination
>> work, but it would be possible to deduce from the dependency chain
>> which downstream modules were built and tested with a given release
>> of an upstream module, and reliably produce a working combination.
>>
>> A slight modification of this scheme would be to make downstream
>> modules explicitly dependent on timestamped versions of upstream
>> SNAPSHOTs, instead of being dependent on the latest published
>> SNAPSHOT. Moving to a different version of an upstream dependency
>> would require explicit action from a downstream dependency by
>> modifying its pom.xml file. This requires greater version dependency
>> awareness on the part of Tuscany developers, with the benefit that
>> by making version dependencies explicit rather than implicit, it
>> would be possible to create a tool that allows a user to bring
>> together a compatible set of timestamped SNAPSHOTs. This approach
>> solves the problem of "latest SNAPSHOT hell" without the overhead
>> of creating a lot of releases for relatively minor changes.
>>
>> Simon
>>
>> Jeremy Boynes wrote:
>>
>>> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>>>
>>>> I'm trying to understand the new modularized build scheme, and
>>>> have a few questions:
>>>>
>>>> I'm not quite sure what you mean by published dependencies?
>>>> releases? snapshots?
>>>>
>>> Anything that a module depends on that is not built by the current
>>> build run. It could be from Tuscany, it could be from another
>>> project; it could be released (preferable) or it could be a snapshot.
>>> Basically, if it's not built by the current run then it needs to
>>> have been published somewhere for the build to work.
>>>
>>>> What are the criteria for deciding to re-publish a Tuscany jar?
>>>
>>> For a release, we need to release it :-)
>>> For a snapshot, any committer can publish one at any time and
>>> should if there is function in there that other modules depend on.
>>> For example, adding a new annotation to spec would be a good reason
>>> to republish the spec snapshot.
>>>
>>>>
>>>> Is the online repository going to keep multiple levels of
>>>> published dependencies?
>>>
>>> It does. Releases generally live forever, snapshots get removed
>>> periodically when they are deemed obsolete. Published snapshots
>>> have a timestamp in the version so it is possible to refer to an
>>> older one if something in the latest causes problems; referring to
>>> an obsolete snapshot is generally problematic as at some point it
>>> will go away.
>>> HTH
>>> --
>>> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
You misunderstand the purpose of SNAPSHOTs. They do not affect users
as released code does not reference them. They provide a way for
project developers to cooperate during a release development cycle
without requiring everyone to build everything all the time (which as
we have seen does not scale). They also provide a mechanism that does
not require downstream developers to update references to every build
number/timestamp every time a new unstable build is published (which
does not scale either but for different reasons).
There's a good reference on how Maven works here: http://
www.mergere.com/m2book_download.jsp
--
Jeremy
On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
> I'm a bit concerned about moving to a highly modularized build where
> all the dependencies between the modules are defined as latest
> SNAPSHOT dependencies.
>
> By doing this we would solve the problem of the fragile monolothic
> build, but we would create a different kind of fragility where
> republication of a SNAPSHOT for one module can break the currently
> published SNAPSHOTs of other modules that have dependencies on it.
>
> This kind of fragility would show up at runtime when a combination
> of incompatible latest published SNAPSHOTs is brought together in
> a user's environment. The only way to prevent this from happening
> is to rebuild and republish all downstream dependent SNAPSHOTs
> whenever an upstream SNAPSHOT is changed and republished, which
> would effectively be re-introducing tight coupling by the back door.
>
> If the published downstream modules depend on upstream releases,
> then this problem does not occur. It would still not be possible
> for a user to combine all latest SNAPSHOTs and have the combination
> work, but it would be possible to deduce from the dependency chain
> which downstream modules were built and tested with a given release
> of an upstream module, and reliably produce a working combination.
>
> A slight modification of this scheme would be to make downstream
> modules explicitly dependent on timestamped versions of upstream
> SNAPSHOTs, instead of being dependent on the latest published
> SNAPSHOT. Moving to a different version of an upstream dependency
> would require explicit action from a downstream dependency by
> modifying its pom.xml file. This requires greater version dependency
> awareness on the part of Tuscany developers, with the benefit that
> by making version dependencies explicit rather than implicit, it
> would be possible to create a tool that allows a user to bring
> together a compatible set of timestamped SNAPSHOTs. This approach
> solves the problem of "latest SNAPSHOT hell" without the overhead
> of creating a lot of releases for relatively minor changes.
>
> Simon
>
> Jeremy Boynes wrote:
>
>> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>>> I'm trying to understand the new modularized build scheme, and
>>> have a few questions:
>>>
>>> I'm not quite sure what you mean by published dependencies?
>>> releases? snapshots?
>>>
>> Anything that a module depends on that is not built by the
>> current build run. It could be from Tuscany, it could be from
>> another project; it could be released (preferable) or it could be
>> a snapshot.
>> Basically, if it's not built by the current run then it needs to
>> have been published somewhere for the build to work.
>>> What are the criteria for deciding to re-publish a Tuscany jar?
>> For a release, we need to release it :-)
>> For a snapshot, any committer can publish one at any time and
>> should if there is function in there that other modules depend
>> on. For example, adding a new annotation to spec would be a good
>> reason to republish the spec snapshot.
>>>
>>> Is the online repository going to keep multiple levels of
>>> published dependencies?
>> It does. Releases generally live forever, snapshots get removed
>> periodically when they are deemed obsolete. Published snapshots
>> have a timestamp in the version so it is possible to refer to an
>> older one if something in the latest causes problems; referring
>> to an obsolete snapshot is generally problematic as at some point
>> it will go away.
>> HTH
>> --
>> 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: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Simon Nash <na...@hursley.ibm.com>.
I'm a bit concerned about moving to a highly modularized build where
all the dependencies between the modules are defined as latest
SNAPSHOT dependencies.
By doing this we would solve the problem of the fragile monolothic
build, but we would create a different kind of fragility where
republication of a SNAPSHOT for one module can break the currently
published SNAPSHOTs of other modules that have dependencies on it.
This kind of fragility would show up at runtime when a combination
of incompatible latest published SNAPSHOTs is brought together in
a user's environment. The only way to prevent this from happening
is to rebuild and republish all downstream dependent SNAPSHOTs
whenever an upstream SNAPSHOT is changed and republished, which
would effectively be re-introducing tight coupling by the back door.
If the published downstream modules depend on upstream releases,
then this problem does not occur. It would still not be possible
for a user to combine all latest SNAPSHOTs and have the combination
work, but it would be possible to deduce from the dependency chain
which downstream modules were built and tested with a given release
of an upstream module, and reliably produce a working combination.
A slight modification of this scheme would be to make downstream
modules explicitly dependent on timestamped versions of upstream
SNAPSHOTs, instead of being dependent on the latest published
SNAPSHOT. Moving to a different version of an upstream dependency
would require explicit action from a downstream dependency by
modifying its pom.xml file. This requires greater version dependency
awareness on the part of Tuscany developers, with the benefit that
by making version dependencies explicit rather than implicit, it
would be possible to create a tool that allows a user to bring
together a compatible set of timestamped SNAPSHOTs. This approach
solves the problem of "latest SNAPSHOT hell" without the overhead
of creating a lot of releases for relatively minor changes.
Simon
Jeremy Boynes wrote:
> On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
>
>> I'm trying to understand the new modularized build scheme, and have a
>> few questions:
>>
>> I'm not quite sure what you mean by published dependencies? releases?
>> snapshots?
>>
>
> Anything that a module depends on that is not built by the current
> build run. It could be from Tuscany, it could be from another project;
> it could be released (preferable) or it could be a snapshot.
>
> Basically, if it's not built by the current run then it needs to have
> been published somewhere for the build to work.
>
>> What are the criteria for deciding to re-publish a Tuscany jar?
>
>
> For a release, we need to release it :-)
> For a snapshot, any committer can publish one at any time and should if
> there is function in there that other modules depend on. For example,
> adding a new annotation to spec would be a good reason to republish the
> spec snapshot.
>
>>
>> Is the online repository going to keep multiple levels of published
>> dependencies?
>
>
> It does. Releases generally live forever, snapshots get removed
> periodically when they are deemed obsolete. Published snapshots have a
> timestamp in the version so it is possible to refer to an older one if
> something in the latest causes problems; referring to an obsolete
> snapshot is generally problematic as at some point it will go away.
>
> HTH
> --
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 6, 2007, at 11:41 AM, Jean-Sebastien Delfino wrote:
> I'm trying to understand the new modularized build scheme, and have
> a few questions:
>
> I'm not quite sure what you mean by published dependencies?
> releases? snapshots?
>
Anything that a module depends on that is not built by the current
build run. It could be from Tuscany, it could be from another
project; it could be released (preferable) or it could be a snapshot.
Basically, if it's not built by the current run then it needs to have
been published somewhere for the build to work.
> What are the criteria for deciding to re-publish a Tuscany jar?
For a release, we need to release it :-)
For a snapshot, any committer can publish one at any time and should
if there is function in there that other modules depend on. For
example, adding a new annotation to spec would be a good reason to
republish the spec snapshot.
>
> Is the online repository going to keep multiple levels of published
> dependencies?
It does. Releases generally live forever, snapshots get removed
periodically when they are deemed obsolete. Published snapshots have
a timestamp in the version so it is possible to refer to an older one
if something in the latest causes problems; referring to an obsolete
snapshot is generally problematic as at some point it will go away.
HTH
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> On Jan 5, 2007, at 5:03 PM, Slava Imeshev wrote:
>
>>
>> --- Jeremy Boynes <jb...@apache.org> wrote:
>>
>>> We ran into scalability issues in the past trying to build everything
>>> together all the time and have migrated away to a more modular
>>> structure.
>>
>> I'd say that the system should be able to be re-build
>> from scratches, whether it is a monolithic script or
>> a set of modules. That's what is called a clean build.
>
> The thing is, a clean build of what?
>
> Up until now (including M2) we had a monolithic build based on mvn -
> the only way someone could build any part of the tree was to check out
> the root (tuscany/java) and build everything. This gave us two big
> problems: Firstly, there were periods of time when, due to
> circumstances outside our control, parts of the build failed which
> prevented anyone from working on bits after the failures. Secondly,
> people making changes to one part would need to make sure they were
> tested (and any issue fixed) across the entire tree even in areas that
> they had no real experience with. It became very clear in the M2
> timeframe that we could not scale if we continued with this monolithic
> approach. We made the decision to modularize the project build.
>
> The key thing here is that each module should be buildable
> independently based on published dependencies. A clean build of a
> module should work even if no other modules have been built locally
> first.
>
>>
>>> Rather than put it all back together like this, would it
>>> be possible to have separate modules in Parabuild for the different
>>> areas? For example, modules for:
>>> * spec
>>> * sdo
>>> * das
>>> * sca kernel
>>> * sca standalone runtime
>>> * and individual sca services (e.g. axis2 based ones)
>>
>> Yes, why not. But isn't it what the quoted script does?
>
> Not quite. The script passes context from one module to another in the
> form of artifacts installed in the local maven repository.
>
>>
>>> Each of these modules should build on their own but for that to work
>>> we need to be more diligent about publishing SNAPSHOTs - e.g. we
>>> should consider republishing the SNAPSHOT of spec.
>>
>> Is it possible to build it w/o publishing snapshots?
>
> Yes but that does not reflect the end-user experience we want to
> ensure works. For example, Toni's build should have worked based
> purely on building the "sca kernel" module. The build failed because
> the online snapshots it would have used were out of date - which is a
> real failure because the spec jars were changed and not republished.
>
>>
>> Also, what do you think about the aforementioned build script?
>
> I think it takes us back to a couple, monolithic build. One fix would
> be to clean out the local maven repo between modules, but I think it
> would be preferable to split it into modules.
>
> FWIW, the modules I think are important are those we would expect a
> user to build. In terms of SVN these are:
> https://svn.apache.org/repos/asf/incubator/tuscany/java/
> spec
> sdo
> das
> sca/kernel
> sca/runtime/standalone
>
> plus others as we finish re-orging the services tree
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I'm trying to understand the new modularized build scheme, and have a
few questions:
I'm not quite sure what you mean by published dependencies? releases?
snapshots?
What are the criteria for deciding to re-publish a Tuscany jar?
Is the online repository going to keep multiple levels of published
dependencies?
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 5, 2007, at 5:03 PM, Slava Imeshev wrote:
>
> --- Jeremy Boynes <jb...@apache.org> wrote:
>
>> We ran into scalability issues in the past trying to build everything
>> together all the time and have migrated away to a more modular
>> structure.
>
> I'd say that the system should be able to be re-build
> from scratches, whether it is a monolithic script or
> a set of modules. That's what is called a clean build.
The thing is, a clean build of what?
Up until now (including M2) we had a monolithic build based on mvn -
the only way someone could build any part of the tree was to check
out the root (tuscany/java) and build everything. This gave us two
big problems: Firstly, there were periods of time when, due to
circumstances outside our control, parts of the build failed which
prevented anyone from working on bits after the failures. Secondly,
people making changes to one part would need to make sure they were
tested (and any issue fixed) across the entire tree even in areas
that they had no real experience with. It became very clear in the M2
timeframe that we could not scale if we continued with this
monolithic approach. We made the decision to modularize the project
build.
The key thing here is that each module should be buildable
independently based on published dependencies. A clean build of a
module should work even if no other modules have been built locally
first.
>
>> Rather than put it all back together like this, would it
>> be possible to have separate modules in Parabuild for the different
>> areas? For example, modules for:
>> * spec
>> * sdo
>> * das
>> * sca kernel
>> * sca standalone runtime
>> * and individual sca services (e.g. axis2 based ones)
>
> Yes, why not. But isn't it what the quoted script does?
Not quite. The script passes context from one module to another in
the form of artifacts installed in the local maven repository.
>
>> Each of these modules should build on their own but for that to work
>> we need to be more diligent about publishing SNAPSHOTs - e.g. we
>> should consider republishing the SNAPSHOT of spec.
>
> Is it possible to build it w/o publishing snapshots?
Yes but that does not reflect the end-user experience we want to
ensure works. For example, Toni's build should have worked based
purely on building the "sca kernel" module. The build failed because
the online snapshots it would have used were out of date - which is a
real failure because the spec jars were changed and not republished.
>
> Also, what do you think about the aforementioned build script?
I think it takes us back to a couple, monolithic build. One fix would
be to clean out the local maven repo between modules, but I think it
would be preferable to split it into modules.
FWIW, the modules I think are important are those we would expect a
user to build. In terms of SVN these are:
https://svn.apache.org/repos/asf/incubator/tuscany/java/
spec
sdo
das
sca/kernel
sca/runtime/standalone
plus others as we finish re-orging the services tree
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Slava Imeshev <vi...@viewtier.com>.
--- Jeremy Boynes <jb...@apache.org> wrote:
> We ran into scalability issues in the past trying to build everything
> together all the time and have migrated away to a more modular
> structure.
I'd say that the system should be able to be re-build
from scratches, whether it is a monolithic script or
a set of modules. That's what is called a clean build.
> Rather than put it all back together like this, would it
> be possible to have separate modules in Parabuild for the different
> areas? For example, modules for:
> * spec
> * sdo
> * das
> * sca kernel
> * sca standalone runtime
> * and individual sca services (e.g. axis2 based ones)
Yes, why not. But isn't it what the quoted script does?
> Each of these modules should build on their own but for that to work
> we need to be more diligent about publishing SNAPSHOTs - e.g. we
> should consider republishing the SNAPSHOT of spec.
Is it possible to build it w/o publishing snapshots?
Also, what do you think about the aforementioned build script?
Slava
>
> --
> Jeremy
>
> On Jan 5, 2007, at 4:04 PM, Slava Imeshev wrote:
>
> >
> > --- Toni Menzel <to...@gmx.de> wrote:
> >
> >> I did this:
> >> svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
> >> cd sdo;mvn clean install
> >> cd ../sca;mvn clean install
> >>
> >> the second mvn call breaks with missing dependency.
> >>
> >> @Slava, can you rebuild your question, don't know what you are
> >> talking
> >> about exactly..?
> >
> > We have these builds configured for Tuscany but apparently after
> > recent changes they are not doing much.
> >
> > If I had a command line sequence I could set it up so that it
> > runs the build after every checkin and sends notifications
> > if they break the build. That'd give an opportunity to fix
> > the build quickly rather than after someone discovers it
> > does not build.
> >
> > The closes that we could get based on the docs is
> >
> > export JAVA_HOME=/opt/jrockit-R26.4.0-jdk1.5.0_06
> > export ANT_HOME=/opt/apache-ant-1.6.5
> > export MAVEN_HOME=/opt/maven-2.0.4
> > export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$ANT_HOME/bin
> >
> >
> > echo ==== Building SDO =============
> > mvn -N
> > cd $PARABUILD_BUILD_DIR/spec
> > mvn -N
> > cd $PARABUILD_BUILD_DIR/sdo
> > mvn -N
> >
> > echo ==== Building sdo.spec project =============
> > cd $PARABUILD_BUILD_DIR/spec/sdo-api
> > mvn
> >
> > echo ==== Building sdo.tools project =============
> > cd $PARABUILD_BUILD_DIR/sdo/impl
> > mvn
> >
> > echo ==== Building sdo.tools project =============
> > cd $PARABUILD_BUILD_DIR/sdo/tools
> > mvn
> >
> > echo ==== Building sdo.samples project =============
> > cd $PARABUILD_BUILD_DIR/sdo/sample
> > mvn
> >
> >
> > echo ==== Building SCA =============
> > cd $PARABUILD_BUILD_DIR/spec/sca
> > mvn -e
> > cd $PARABUILD_BUILD_DIR/spec/commonj
> > mvn -e
> > cd $PARABUILD_BUILD_DIR/sca
> > mvn -e
> >
> > But with this some tests are failing so I am not sure if this
> > sequence is
> > correct.
> >
> > That's why I was wondering what is the official build sequence to
> > build
> > tuscany-java from scrates.
> >
> > Slava
> >
> >
> >>
> >> Toni
> >>
> >>
> >>
> >> Slava Imeshev schrieb:
> >>> Guys,
> >>>
> >>> If you tell me how to build tuscany from a command line at one
> >>> shot. I can make sure that such
> >>> errors are caught immeditely.
> >>>
> >>> Slava
> >>>
> >>>
> >>> --- Toni Menzel <to...@gmx.de> wrote:
> >>>
> >>>
> >>>> Hi!
> >>>>
> >>>> I just tried to build tuscany from source for the first time.
> >>>> Building sdo works out-of-the-box but the sca breaks with the
> >>>> following
> >>>> message:
> >>>> Downloading:
> >>>> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-
> >>>> r0.95-1.0-incubator-SNAPSHOT.jar
> >>>> [WARNING] Unable to get resource from repository
> >>>> apache.ws.m1.snapshots
> >>>> (http://ws.zones.apache.org/repository)
> >>>> [INFO]
> >>>> -------------------------------------------------------------------
> >>>> -----
> >>>> [ERROR] BUILD ERROR
> >>>> [INFO]
> >>>> -------------------------------------------------------------------
> >>>> -----
> >>>> [INFO] Failed to resolve artifact.
> >>>>
> >>>> Missing:
> >>>> ----------
> >>>> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
> >>>>
> >>>> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
> >>>> .m2/settings.xml, but this doesn't work either..
> >>>>
> >>>> is there any known issue with this revision or am i missing
> >>>> something?
> >>>>
> >>>> thanks in advance,
> >>>> Toni
> >>>>
> >>>>
> >>>> PS: I tried using a fresh local mvn repository, too :-(
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> 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
> >>>
> >>
> >>
> >> --
> >> Toni Menzel
> >> http://www.tonit.com
> >> mailto:tonimenzel@gmx.de
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Jeremy Boynes <jb...@apache.org>.
We ran into scalability issues in the past trying to build everything
together all the time and have migrated away to a more modular
structure. Rather than put it all back together like this, would it
be possible to have separate modules in Parabuild for the different
areas? For example, modules for:
* spec
* sdo
* das
* sca kernel
* sca standalone runtime
* and individual sca services (e.g. axis2 based ones)
Each of these modules should build on their own but for that to work
we need to be more diligent about publishing SNAPSHOTs - e.g. we
should consider republishing the SNAPSHOT of spec.
--
Jeremy
On Jan 5, 2007, at 4:04 PM, Slava Imeshev wrote:
>
> --- Toni Menzel <to...@gmx.de> wrote:
>
>> I did this:
>> svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
>> cd sdo;mvn clean install
>> cd ../sca;mvn clean install
>>
>> the second mvn call breaks with missing dependency.
>>
>> @Slava, can you rebuild your question, don't know what you are
>> talking
>> about exactly..?
>
> We have these builds configured for Tuscany but apparently after
> recent changes they are not doing much.
>
> If I had a command line sequence I could set it up so that it
> runs the build after every checkin and sends notifications
> if they break the build. That'd give an opportunity to fix
> the build quickly rather than after someone discovers it
> does not build.
>
> The closes that we could get based on the docs is
>
> export JAVA_HOME=/opt/jrockit-R26.4.0-jdk1.5.0_06
> export ANT_HOME=/opt/apache-ant-1.6.5
> export MAVEN_HOME=/opt/maven-2.0.4
> export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$ANT_HOME/bin
>
>
> echo ==== Building SDO =============
> mvn -N
> cd $PARABUILD_BUILD_DIR/spec
> mvn -N
> cd $PARABUILD_BUILD_DIR/sdo
> mvn -N
>
> echo ==== Building sdo.spec project =============
> cd $PARABUILD_BUILD_DIR/spec/sdo-api
> mvn
>
> echo ==== Building sdo.tools project =============
> cd $PARABUILD_BUILD_DIR/sdo/impl
> mvn
>
> echo ==== Building sdo.tools project =============
> cd $PARABUILD_BUILD_DIR/sdo/tools
> mvn
>
> echo ==== Building sdo.samples project =============
> cd $PARABUILD_BUILD_DIR/sdo/sample
> mvn
>
>
> echo ==== Building SCA =============
> cd $PARABUILD_BUILD_DIR/spec/sca
> mvn -e
> cd $PARABUILD_BUILD_DIR/spec/commonj
> mvn -e
> cd $PARABUILD_BUILD_DIR/sca
> mvn -e
>
> But with this some tests are failing so I am not sure if this
> sequence is
> correct.
>
> That's why I was wondering what is the official build sequence to
> build
> tuscany-java from scrates.
>
> Slava
>
>
>>
>> Toni
>>
>>
>>
>> Slava Imeshev schrieb:
>>> Guys,
>>>
>>> If you tell me how to build tuscany from a command line at one
>>> shot. I can make sure that such
>>> errors are caught immeditely.
>>>
>>> Slava
>>>
>>>
>>> --- Toni Menzel <to...@gmx.de> wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> I just tried to build tuscany from source for the first time.
>>>> Building sdo works out-of-the-box but the sca breaks with the
>>>> following
>>>> message:
>>>> Downloading:
>>>> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-
>>>> r0.95-1.0-incubator-SNAPSHOT.jar
>>>> [WARNING] Unable to get resource from repository
>>>> apache.ws.m1.snapshots
>>>> (http://ws.zones.apache.org/repository)
>>>> [INFO]
>>>> -------------------------------------------------------------------
>>>> -----
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> -------------------------------------------------------------------
>>>> -----
>>>> [INFO] Failed to resolve artifact.
>>>>
>>>> Missing:
>>>> ----------
>>>> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
>>>>
>>>> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
>>>> .m2/settings.xml, but this doesn't work either..
>>>>
>>>> is there any known issue with this revision or am i missing
>>>> something?
>>>>
>>>> thanks in advance,
>>>> Toni
>>>>
>>>>
>>>> PS: I tried using a fresh local mvn repository, too :-(
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>>
>>
>>
>> --
>> Toni Menzel
>> http://www.tonit.com
>> mailto:tonimenzel@gmx.de
>>
>>
>> ---------------------------------------------------------------------
>> 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: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Slava Imeshev <vi...@viewtier.com>.
--- Toni Menzel <to...@gmx.de> wrote:
> I did this:
> svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
> cd sdo;mvn clean install
> cd ../sca;mvn clean install
>
> the second mvn call breaks with missing dependency.
>
> @Slava, can you rebuild your question, don't know what you are talking
> about exactly..?
We have these builds configured for Tuscany but apparently after
recent changes they are not doing much.
If I had a command line sequence I could set it up so that it
runs the build after every checkin and sends notifications
if they break the build. That'd give an opportunity to fix
the build quickly rather than after someone discovers it
does not build.
The closes that we could get based on the docs is
export JAVA_HOME=/opt/jrockit-R26.4.0-jdk1.5.0_06
export ANT_HOME=/opt/apache-ant-1.6.5
export MAVEN_HOME=/opt/maven-2.0.4
export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$ANT_HOME/bin
echo ==== Building SDO =============
mvn -N
cd $PARABUILD_BUILD_DIR/spec
mvn -N
cd $PARABUILD_BUILD_DIR/sdo
mvn -N
echo ==== Building sdo.spec project =============
cd $PARABUILD_BUILD_DIR/spec/sdo-api
mvn
echo ==== Building sdo.tools project =============
cd $PARABUILD_BUILD_DIR/sdo/impl
mvn
echo ==== Building sdo.tools project =============
cd $PARABUILD_BUILD_DIR/sdo/tools
mvn
echo ==== Building sdo.samples project =============
cd $PARABUILD_BUILD_DIR/sdo/sample
mvn
echo ==== Building SCA =============
cd $PARABUILD_BUILD_DIR/spec/sca
mvn -e
cd $PARABUILD_BUILD_DIR/spec/commonj
mvn -e
cd $PARABUILD_BUILD_DIR/sca
mvn -e
But with this some tests are failing so I am not sure if this sequence is
correct.
That's why I was wondering what is the official build sequence to build
tuscany-java from scrates.
Slava
>
> Toni
>
>
>
> Slava Imeshev schrieb:
> > Guys,
> >
> > If you tell me how to build tuscany from a command line at one shot. I can make sure that such
> > errors are caught immeditely.
> >
> > Slava
> >
> >
> > --- Toni Menzel <to...@gmx.de> wrote:
> >
> >
> >> Hi!
> >>
> >> I just tried to build tuscany from source for the first time.
> >> Building sdo works out-of-the-box but the sca breaks with the following
> >> message:
> >> Downloading:
> >> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
> >> [WARNING] Unable to get resource from repository apache.ws.m1.snapshots
> >> (http://ws.zones.apache.org/repository)
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> [ERROR] BUILD ERROR
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> [INFO] Failed to resolve artifact.
> >>
> >> Missing:
> >> ----------
> >> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
> >>
> >> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
> >> .m2/settings.xml, but this doesn't work either..
> >>
> >> is there any known issue with this revision or am i missing something?
> >>
> >> thanks in advance,
> >> Toni
> >>
> >>
> >> PS: I tried using a fresh local mvn repository, too :-(
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> --
> Toni Menzel
> http://www.tonit.com
> mailto:tonimenzel@gmx.de
>
>
> ---------------------------------------------------------------------
> 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: tuscany-sca revision 493223 does not build? (mvn claims missing
jar dependency)
Posted by Toni Menzel <to...@gmx.de>.
I did this:
svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ .
cd sdo;mvn clean install
cd ../sca;mvn clean install
the second mvn call breaks with missing dependency.
@Slava, can you rebuild your question, don't know what you are talking
about exactly..?
Toni
Slava Imeshev schrieb:
> Guys,
>
> If you tell me how to build tuscany from a command line at one shot. I can make sure that such
> errors are caught immeditely.
>
> Slava
>
>
> --- Toni Menzel <to...@gmx.de> wrote:
>
>
>> Hi!
>>
>> I just tried to build tuscany from source for the first time.
>> Building sdo works out-of-the-box but the sca breaks with the following
>> message:
>> Downloading:
>> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
>> [WARNING] Unable to get resource from repository apache.ws.m1.snapshots
>> (http://ws.zones.apache.org/repository)
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to resolve artifact.
>>
>> Missing:
>> ----------
>> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
>>
>> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
>> .m2/settings.xml, but this doesn't work either..
>>
>> is there any known issue with this revision or am i missing something?
>>
>> thanks in advance,
>> Toni
>>
>>
>> PS: I tried using a fresh local mvn repository, too :-(
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Toni Menzel
http://www.tonit.com
mailto:tonimenzel@gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency)
Posted by Slava Imeshev <vi...@viewtier.com>.
Guys,
If you tell me how to build tuscany from a command line at one shot. I can make sure that such
errors are caught immeditely.
Slava
--- Toni Menzel <to...@gmx.de> wrote:
> Hi!
>
> I just tried to build tuscany from source for the first time.
> Building sdo works out-of-the-box but the sca breaks with the following
> message:
> Downloading:
> http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
> [WARNING] Unable to get resource from repository apache.ws.m1.snapshots
> (http://ws.zones.apache.org/repository)
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> Missing:
> ----------
> 1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
>
> I added http://people.apache.org/repo/m2-snapshot-repository/ to my
> .m2/settings.xml, but this doesn't work either..
>
> is there any known issue with this revision or am i missing something?
>
> thanks in advance,
> Toni
>
>
> PS: I tried using a fresh local mvn repository, too :-(
>
> ---------------------------------------------------------------------
> 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
tuscany-sca revision 493223 does not build? (mvn claims missing jar
dependency)
Posted by Toni Menzel <to...@gmx.de>.
Hi!
I just tried to build tuscany from source for the first time.
Building sdo works out-of-the-box but the sca breaks with the following
message:
Downloading:
http://ws.zones.apache.org/repository/org.osoa/jars/sca-api-r0.95-1.0-incubator-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache.ws.m1.snapshots
(http://ws.zones.apache.org/repository)
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.osoa:sca-api-r0.95:jar:1.0-incubator-SNAPSHOT
I added http://people.apache.org/repo/m2-snapshot-repository/ to my
.m2/settings.xml, but this doesn't work either..
is there any known issue with this revision or am i missing something?
thanks in advance,
Toni
PS: I tried using a fresh local mvn repository, too :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Maven dependencies question
Posted by "Jiang, Ning (Willem)" <Ni...@iona.com>.
Hi Frank,
It seems a little strange, but it make sense.
We can use the provided in the dependency scope to make sure we will not pack the jars which can get from the runtime environment, but we also need to make sure our runtime environment provids the jars.
Cheers,
Willem.
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: 1/6/2007 6:00
To: tuscany-dev@ws.apache.org
Subject: RE: Maven dependencies question
Thanks Willem. So I guess I'll just add the extra test scope dependency,
even though it seems a little strange given no direct use of it.
Thanks,
Frank.
"Jiang, Ning \(Willem\)" <Ni...@iona.com> wrote on 01/04/2007
10:50:15 PM:
> Hi Frank,
>
> Maven help us to manage the dependencies by using the pom.xml which
> we can define the dependency relationship.
> The dependency relationship can be used when maven need to setup the
> class path or do the packaging.
> Here is some note for "provided" that you can get from the book
> "Better Builds with Maven":
>
> "You should note that you're using a provided scope instead of the
> default compile scope. The reason is that this dependency will
> already be present in the environment (being the J2EE application
> server) where your EJB will execute. You make this clear to Maven by
> using the provided scope; this prevents the EAR module from
> including the J2EE JAR when it is packaged.Even though this
> dependency is provided at runtime, it still needs to be listed in
> the POM so that the code can be compiled."
>
> And if your module A unit test need the C jar in the runtime,
> because you had set C jar as the provided scope in the other module
> B, you own A module will not take this dependency from module B even
> your have the dependence from B. So you need to add the C jar's
> dependency as the <scope> test </scope> in the module A's pom.xml :).
>
>
> Willem.
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Fri 1/5/2007 11:08
> To: tuscany-dev@ws.apache.org
> Subject: Maven dependencies question
>
> I think I need some help form somebody with a better understanding (than
> me) of how maven dependencies work.
>
> Because the Java sdo/impl project includes an optional stax
> loader/serializer it includes this in its pom.xml file:
>
> <!-- dependencies for optional StAX functions -->
> <dependency>
> <groupId>stax</groupId>
> <artifactId>stax-api</artifactId>
> <version>1.0.1</version>
> <scope>provided</scope>
> <optional>true</optional>
> </dependency>
>
> One of the new implementation classes in the the sdo/impl project also
> uses the StAX function itself, internally in its implementation.
>
> Now, in the sdo/tools project, we have a test program that calls the
> implementation class that uses the StAX stuff (indirectly though an SDO
> helper interface). Note that the test program in the sdo/tools project
has
> no import or direct use of any StAX interfaces.
>
> However, when we now run mvn in the sdo/tools project, the test program,
> mentioned above, fails with the following error:
>
> java.lang.NoClassDefFoundError:
> javax/xml/stream/XMLStreamException
>
> I was able to fix the problem by copying the stax dependency from the
> sdo/impl pom.xml file and adding it to the pom.xml in the sdo/tools
> project, but this seems a bit ridiculous, since as I mentioned above,
the
> use of stax is really only in the sdo/impl project.
>
> Can anybody see what the problem might be, or suggest how to fix this?
>
> Thanks in advance,
> Frank.
>
>
> ---------------------------------------------------------------------
> 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: Maven dependencies question
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Thanks Willem. So I guess I'll just add the extra test scope dependency,
even though it seems a little strange given no direct use of it.
Thanks,
Frank.
"Jiang, Ning \(Willem\)" <Ni...@iona.com> wrote on 01/04/2007
10:50:15 PM:
> Hi Frank,
>
> Maven help us to manage the dependencies by using the pom.xml which
> we can define the dependency relationship.
> The dependency relationship can be used when maven need to setup the
> class path or do the packaging.
> Here is some note for "provided" that you can get from the book
> "Better Builds with Maven":
>
> "You should note that you're using a provided scope instead of the
> default compile scope. The reason is that this dependency will
> already be present in the environment (being the J2EE application
> server) where your EJB will execute. You make this clear to Maven by
> using the provided scope; this prevents the EAR module from
> including the J2EE JAR when it is packaged.Even though this
> dependency is provided at runtime, it still needs to be listed in
> the POM so that the code can be compiled."
>
> And if your module A unit test need the C jar in the runtime,
> because you had set C jar as the provided scope in the other module
> B, you own A module will not take this dependency from module B even
> your have the dependence from B. So you need to add the C jar's
> dependency as the <scope> test </scope> in the module A's pom.xml :).
>
>
> Willem.
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Fri 1/5/2007 11:08
> To: tuscany-dev@ws.apache.org
> Subject: Maven dependencies question
>
> I think I need some help form somebody with a better understanding (than
> me) of how maven dependencies work.
>
> Because the Java sdo/impl project includes an optional stax
> loader/serializer it includes this in its pom.xml file:
>
> <!-- dependencies for optional StAX functions -->
> <dependency>
> <groupId>stax</groupId>
> <artifactId>stax-api</artifactId>
> <version>1.0.1</version>
> <scope>provided</scope>
> <optional>true</optional>
> </dependency>
>
> One of the new implementation classes in the the sdo/impl project also
> uses the StAX function itself, internally in its implementation.
>
> Now, in the sdo/tools project, we have a test program that calls the
> implementation class that uses the StAX stuff (indirectly though an SDO
> helper interface). Note that the test program in the sdo/tools project
has
> no import or direct use of any StAX interfaces.
>
> However, when we now run mvn in the sdo/tools project, the test program,
> mentioned above, fails with the following error:
>
> java.lang.NoClassDefFoundError:
> javax/xml/stream/XMLStreamException
>
> I was able to fix the problem by copying the stax dependency from the
> sdo/impl pom.xml file and adding it to the pom.xml in the sdo/tools
> project, but this seems a bit ridiculous, since as I mentioned above,
the
> use of stax is really only in the sdo/impl project.
>
> Can anybody see what the problem might be, or suggest how to fix this?
>
> Thanks in advance,
> Frank.
>
>
> ---------------------------------------------------------------------
> 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: Maven dependencies question
Posted by "Jiang, Ning (Willem)" <Ni...@iona.com>.
Hi Frank,
Maven help us to manage the dependencies by using the pom.xml which we can define the dependency relationship.
The dependency relationship can be used when maven need to setup the class path or do the packaging.
Here is some note for "provided" that you can get from the book "Better Builds with Maven":
"You should note that you're using a provided scope instead of the default compile scope. The reason is that this dependency will already be present in the environment (being the J2EE application server) where your EJB will execute. You make this clear to Maven by using the provided scope; this prevents the EAR module from including the J2EE JAR when it is packaged.Even though this dependency is provided at runtime, it still needs to be listed in the POM so that the code can be compiled."
And if your module A unit test need the C jar in the runtime, because you had set C jar as the provided scope in the other module B, you own A module will not take this dependency from module B even your have the dependence from B. So you need to add the C jar's dependency as the <scope> test </scope> in the module A's pom.xml :).
Willem.
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Fri 1/5/2007 11:08
To: tuscany-dev@ws.apache.org
Subject: Maven dependencies question
I think I need some help form somebody with a better understanding (than
me) of how maven dependencies work.
Because the Java sdo/impl project includes an optional stax
loader/serializer it includes this in its pom.xml file:
<!-- dependencies for optional StAX functions -->
<dependency>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
<version>1.0.1</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
One of the new implementation classes in the the sdo/impl project also
uses the StAX function itself, internally in its implementation.
Now, in the sdo/tools project, we have a test program that calls the
implementation class that uses the StAX stuff (indirectly though an SDO
helper interface). Note that the test program in the sdo/tools project has
no import or direct use of any StAX interfaces.
However, when we now run mvn in the sdo/tools project, the test program,
mentioned above, fails with the following error:
java.lang.NoClassDefFoundError:
javax/xml/stream/XMLStreamException
I was able to fix the problem by copying the stax dependency from the
sdo/impl pom.xml file and adding it to the pom.xml in the sdo/tools
project, but this seems a bit ridiculous, since as I mentioned above, the
use of stax is really only in the sdo/impl project.
Can anybody see what the problem might be, or suggest how to fix this?
Thanks in advance,
Frank.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org