You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tuscany.apache.org by lr...@apache.org on 2007/03/10 00:31:17 UTC

svn commit: r516600 - /incubator/tuscany/java/pom.xml

Author: lresende
Date: Fri Mar  9 15:31:10 2007
New Revision: 516600

URL: http://svn.apache.org/viewvc?view=rev&rev=516600
Log:
Reverting 516588

Modified:
    incubator/tuscany/java/pom.xml

Modified: incubator/tuscany/java/pom.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom.xml?view=diff&rev=516600&r1=516599&r2=516600
==============================================================================
--- incubator/tuscany/java/pom.xml (original)
+++ incubator/tuscany/java/pom.xml Fri Mar  9 15:31:10 2007
@@ -37,35 +37,9 @@
     </build>
 
     <profiles>
-        <!-- default profile that builds everything that is working-->
-        <profile>
-            <id>stable</id>
-            <activation>
-	        <activeByDefault>true</activeByDefault>
-            </activation>
-            <modules>
-                <module>pom/parent</module>
-                <module>buildtools</module>
-                <module>spec/commonj</module>
-                <module>spec/sdo-api</module>
-                <module>spec/sca-api-r0.95</module>
-                <module>spec/sca-api-r1.0</module>
-                <module>sdo</module>
-                <module>das</module>
-                <module>sca/composite-plugin</module>
-                <module>sca/kernel</module>
-                <module>sca/runtime</module>
-                <module>sca/core-samples</module>
-                <module>sca/integration-test</module>
-                <module>sca/extensions\spring</module>
-                <module>sca/services/transaction/transaction.geronimo</module>
-                <module>sca/services/persistence/common</module>
-            </modules>
-        </profile>
-
         <!-- default profile that builds everything -->
         <profile>
-            <id>all-integration</id>
+            <id>all</id>
             <modules>
                 <module>pom/parent</module>
                 <module>buildtools</module>



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-commits-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jim Marino <jm...@myromatours.com>.
On Mar 12, 2007, at 2:15 PM, Luciano Resende wrote:

> Jim said:
>> The trunk has been quite stable for some time.
>
> What's your scope of trunk ?  Following the instructions in
> https://svn.apache.org/repos/asf/incubator/tuscany/java/ 
> BUILDING.txt nothing
> get's built. Trying to build the sca profile or going directly to  
> java/sca
> give me an error, as there is no pom.xml available after Jeremy  
> changed the
> sca pom.xml to pom/sca.
That is exactly the correct and documented behavior because we don't  
build everything at once. Ironically, Jeremy proposed removing the  
pom as inappropriate but several people objected, so it was left in  
place. Please see to the following discussion for details:

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14396.html

> Also, couple modules does not built as of today, due
> to changes in kernel, and there is no documentation of what's  
> working or
> not.

The persistence modules and wsdl haven't yet been updated from the  
release. I forgot to do that as I had a few left-over things in my  
mvn repo and will go ahead and update them. This is hardly unstable,  
just a few pom updates I forgot to make over the weekend. Mia culpa.

> And if you have to try to figure this out, you have to try each
> module/project inside sca and try to figure out what's failing and  
> what's
> not.  Is this considered stable ?
>
Each extension should have their own section of the wiki with this  
type of info. I started to do that for the ones I care about.
>
> Based on some e-mails I've read on this list, looks like if we  
> really want
> to expand out Tuscany SCA community, we really need some  
> improvement over
> what we have today around build and probably other areas as well.  
> Also,
> being able to build multiple modules at once, should not break the
> modularity policy.
We can build multiple modules today, e.g. kernel. Building from root  
won't work because of different versions required by extensions  
modules. Jeremy suggested a way to build assemblies. Why not adopt  
that approach?

> Or maybe I'm really missing something, and maybe someone
> could share with me an easy way to verify and build multiple  
> modules for the
> SCA project in trunk as currently I'm using a pretty old technique, a
> build.bat that builds the modules i know are working.
>
It's called "continuous integration": http://www.martinfowler.com/ 
articles/continuousIntegration.html

Note the article is linked from our developer instructions:

http://cwiki.apache.org/TUSCANY/sca-java-development.html

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by ant elder <an...@gmail.com>.
LOL, you'll need to do a bit better than that to educate us as from all the
posts to this thread it doesn't seem like 'most people' understand the
proposal or think it will fix the problem. How about setting up something
somewhere to demonstrate what you are proposing?

   ...ant

On 3/13/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 12, 2007, at 4:05 PM, ant elder wrote:
>
> >
> > He didn't give much detail, and hasn't replied when i asked for
> > more about
> > what he was proposing (unless I missed the email?)
>
> Got better things to do - most people understood it which was enough
> for me. You might want to read up on the maven-assembly-plugin.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 12, 2007, at 4:05 PM, ant elder wrote:

>
> He didn't give much detail, and hasn't replied when i asked for  
> more about
> what he was proposing (unless I missed the email?)

Got better things to do - most people understood it which was enough  
for me. You might want to read up on the maven-assembly-plugin.

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by ant elder <an...@gmail.com>.
On 3/13/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Mar 13, 2007, at 3:38 AM, Paul Fremantle wrote:
>
> >> > AFAICT the full top-level
> >> > build is the only way people have found very easy to use so far.
> >> To be more accurate, it's the only way people working for a specific
> >> vendor have found easy. Others who don't work for that vendor are not
> >> having problems.
> >
> > Jim
> >
> > If those people are co-committers on this project I don't see what
> > relevance that has. If they are having problems then they are having
> > problems. This comment is not constructive and not conducive to any of
> > the objectives of an incubating project.
> >
> > Paul
>
> Paul,
>
> I agree it's not constructive. Not that this is an excuse but I and
> others on the project are pretty frustrated with all of the non-
> constructive things that are occurring. My frustration just showed
> through.


Lets try to fix this. Could you say more specifically what it is you are
finding frustrating so we can try to resolve the problems?

   ...ant

Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jim Marino <jm...@myromatours.com>.
>
> I disagree that this proved unworkable, could you give some concrete
> examples of how you think its been unworkable so we can way those  
> against
> the benefits a full top-level build provides?
Don't you remember all of the build breaks we had in the past or the  
issues we had with the releases? Also, the top-down build forces all  
extensions to be on the same level of kernel.

> AFAICT the full top-level
> build is the only way people have found very easy to use so far.
To be more accurate, it's the only way people working for a specific  
vendor have found easy. Others who don't work for that vendor are not  
having problems.

> It works
> just fine in the integration branch.
>
>> If people don't want to to a full build
>> > from the top they can ignore the top-level pom.xml.
>> What is wrong with Jeremy's proposal to use assemblies?
>
>
> He didn't give much detail, and hasn't replied when i asked for  
> more about
> what he was proposing (unless I missed the email?)
>
I thought he explained it pretty well. I'd suggest looking at the  
Maven manual (or book) for more detail if necessary.

>> Modules can still be
>> > released individually or in smaller groups with any specific
>> > version name as
>> > desired, but build the trunk from the top gets all the modules
>> > built with
>> > the latest code all using the latest SNAPSHOT version name as this
>> > is what
>> > people want and expect.
>>
>> So if I have an extension that works off 2.0 kernel only and the
>> kernel in trunk is at 3.0 what happens? How does that get built and
>> released? Maybe you can get this setup in the integration branch for
>> us to look at?
>
>
> Thats easy, if that's the case then it would not be part of the  
> full build.
> This wouldn't be the usual case for most extensions but for those  
> that want
> to be back level then not having them part of the full build is  
> fine and no
> worse than the current situation.
So then we don't really have a top-down build at all. I think you  
will find Jeremy's approach the best way to handle this.

Jim




---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by ant elder <an...@gmail.com>.
On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Mar 12, 2007, at 3:00 PM, ant elder wrote:
>
> > I agree with what Bert are Luciano are saying and I'm having the same
> > problems while trying to get the Axis2 binding going again in
> > trunk. Many
> > people have been having trouble with this for months now and have been
> > coming up with their own pom.xml files or bat scripts or whatever
> > to work
> > around these problems ( or creating their own branch or just giving
> > up and
> > going away). I think its time we reviewed this modularity strategy
> > and try
> > to find something that more people are happy with.
> >
> > Isn't the only real problem with having a top level pom.xml to
> > enable a full
> > build is that mixing different version levels in a single reactor
> > build
> > confuses maven. To fix this lets just go back to having a single
> > version
> > used by all the modules in trunk.
> -1 this forces all extensions to use the latest trunk, which proved
> unworkable and which seems to be causing problems in the integration
> branch with all the profile changes and build breaks.


I disagree that this proved unworkable, could you give some concrete
examples of how you think its been unworkable so we can way those against
the benefits a full top-level build provides? AFAICT the full top-level
build is the only way people have found very easy to use so far. It works
just fine in the integration branch.

> If people don't want to to a full build
> > from the top they can ignore the top-level pom.xml.
> What is wrong with Jeremy's proposal to use assemblies?


He didn't give much detail, and hasn't replied when i asked for more about
what he was proposing (unless I missed the email?)

> Modules can still be
> > released individually or in smaller groups with any specific
> > version name as
> > desired, but build the trunk from the top gets all the modules
> > built with
> > the latest code all using the latest SNAPSHOT version name as this
> > is what
> > people want and expect.
>
> So if I have an extension that works off 2.0 kernel only and the
> kernel in trunk is at 3.0 what happens? How does that get built and
> released? Maybe you can get this setup in the integration branch for
> us to look at?


Thats easy, if that's the case then it would not be part of the full build.
This wouldn't be the usual case for most extensions but for those that want
to be back level then not having them part of the full build is fine and no
worse than the current situation.

   ...ant

Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>
> On Mar 12, 2007, at 3:57 PM, Jean-Sebastien Delfino wrote:
>
>> [snip]
>> Jim Marino wrote:
>>> -1 this forces all extensions to use the latest trunk, which proved 
>>> unworkable and which seems to be causing problems in the integration 
>>> branch with all the profile changes and build breaks.
>>>
>>
>> FYI the integration branch has been building OK for a while now. I 
>> think that there was an issue at some point in some Windows 
>> environments with the latest Maven surefire plugin complaining when 
>> you had "C:\Program Files" (with a space) on the path but this was 
>> happening too in the trunk for SDO for example,  has been fixed now 
>> (by specifying surefire version 2.3), and had nothing to do with the 
>> build structure anyway.
>
> Then why do the stable and unstable profiles change so often?
>
> Jim
>
>

Maybe because we're doing much work to integrate all the pieces :) It 
takes a lot of energy to bring up extensions, samples, and integration 
tests and the stable profile reflects what we've been able to stabilize 
(and we could use any help with this work by the way). The unstable 
profile is for work in progress and can change quickly as well if people 
work fast :)

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jim Marino <jm...@myromatours.com>.
On Mar 12, 2007, at 3:57 PM, Jean-Sebastien Delfino wrote:

> [snip]
> Jim Marino wrote:
>> -1 this forces all extensions to use the latest trunk, which  
>> proved unworkable and which seems to be causing problems in the  
>> integration branch with all the profile changes and build breaks.
>>
>
> FYI the integration branch has been building OK for a while now. I  
> think that there was an issue at some point in some Windows  
> environments with the latest Maven surefire plugin complaining when  
> you had "C:\Program Files" (with a space) on the path but this was  
> happening too in the trunk for SDO for example,  has been fixed now  
> (by specifying surefire version 2.3), and had nothing to do with  
> the build structure anyway.

Then why do the stable and unstable profiles change so often?

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Jim Marino wrote:
> -1 this forces all extensions to use the latest trunk, which proved 
> unworkable and which seems to be causing problems in the integration 
> branch with all the profile changes and build breaks.
>

FYI the integration branch has been building OK for a while now. I think 
that there was an issue at some point in some Windows environments with 
the latest Maven surefire plugin complaining when you had "C:\Program 
Files" (with a space) on the path but this was happening too in the 
trunk for SDO for example,  has been fixed now (by specifying surefire 
version 2.3), and had nothing to do with the build structure anyway.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jim Marino <jm...@myromatours.com>.
On Mar 12, 2007, at 3:00 PM, ant elder wrote:

> I agree with what Bert are Luciano are saying and I'm having the same
> problems while trying to get the Axis2 binding going again in  
> trunk. Many
> people have been having trouble with this for months now and have been
> coming up with their own pom.xml files or bat scripts or whatever  
> to work
> around these problems ( or creating their own branch or just giving  
> up and
> going away). I think its time we reviewed this modularity strategy  
> and try
> to find something that more people are happy with.
>
> Isn't the only real problem with having a top level pom.xml to  
> enable a full
> build is that mixing different version levels in a single reactor  
> build
> confuses maven. To fix this lets just go back to having a single  
> version
> used by all the modules in trunk.
-1 this forces all extensions to use the latest trunk, which proved  
unworkable and which seems to be causing problems in the integration  
branch with all the profile changes and build breaks.

> If people don't want to to a full build
> from the top they can ignore the top-level pom.xml.
What is wrong with Jeremy's proposal to use assemblies?

> Modules can still be
> released individually or in smaller groups with any specific  
> version name as
> desired, but build the trunk from the top gets all the modules  
> built with
> the latest code all using the latest SNAPSHOT version name as this  
> is what
> people want and expect.

So if I have an extension that works off 2.0 kernel only and the  
kernel in trunk is at 3.0 what happens? How does that get built and  
released? Maybe you can get this setup in the integration branch for  
us to look at?

Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by ant elder <an...@gmail.com>.
I agree with what Bert are Luciano are saying and I'm having the same
problems while trying to get the Axis2 binding going again in trunk. Many
people have been having trouble with this for months now and have been
coming up with their own pom.xml files or bat scripts or whatever to work
around these problems ( or creating their own branch or just giving up and
going away). I think its time we reviewed this modularity strategy and try
to find something that more people are happy with.

Isn't the only real problem with having a top level pom.xml to enable a full
build is that mixing different version levels in a single reactor build
confuses maven. To fix this lets just go back to having a single version
used by all the modules in trunk. If people don't want to to a full build
from the top they can ignore the top-level pom.xml. Modules can still be
released individually or in smaller groups with any specific version name as
desired, but build the trunk from the top gets all the modules built with
the latest code all using the latest SNAPSHOT version name as this is what
people want and expect.

   ...ant

On 3/12/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Jim said:
> >The trunk has been quite stable for some time.
>
> What's your scope of trunk ?  Following the instructions in
> https://svn.apache.org/repos/asf/incubator/tuscany/java/BUILDING.txt
> nothing
> get's built. Trying to build the sca profile or going directly to java/sca
> give me an error, as there is no pom.xml available after Jeremy changed
> the
> sca pom.xml to pom/sca. Also, couple modules does not built as of today,
> due
> to changes in kernel, and there is no documentation of what's working or
> not. And if you have to try to figure this out, you have to try each
> module/project inside sca and try to figure out what's failing and what's
> not.  Is this considered stable ?
>
>
> Based on some e-mails I've read on this list, looks like if we really want
> to expand out Tuscany SCA community, we really need some improvement over
> what we have today around build and probably other areas as well. Also,
> being able to build multiple modules at once, should not break the
> modularity policy. Or maybe I'm really missing something, and maybe
> someone
> could share with me an easy way to verify and build multiple modules for
> the
> SCA project in trunk as currently I'm using a pretty old technique, a
> build.bat that builds the modules i know are working.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>
> On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Mar 12, 2007, at 12:57 PM, Bert Lamb wrote:
> >
> > > On 3/10/07, ant elder < ant.elder@gmail.com> wrote:
> > >> I think we really have to do something as its way to hard to get
> > >> things
> > >> built right now and I'm positive this is putting people off.
> > >
> > > It is actively putting me off right now.  The build problems with
> > > Tuscany are quite off putting.  Anything that can be done to rectify
> > > this and document the correct way to build, and to ensure that those
> > > instructions continue to work would be greatly appreciated.
> > The trunk has been quite stable for some time. What problems are you
> > having when building? Have you tried the 2.0 alpha as you can avoid
> > having to build source altogether?
> >
> > FYI there is documentation on building Java SCA at:
> >
> > http://cwiki.apache.org/TUSCANY/sca-java-development.html
> >
> > If something is unclear, let me know and I will try my best to answer
> > questions.
> >
> > Jim
> >
> > >
> > > -Bert
> > >
> > > ---------------------------------------------------------------------
> > > 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: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Luciano Resende <lu...@gmail.com>.
Jim said:
>The trunk has been quite stable for some time.

What's your scope of trunk ?  Following the instructions in
https://svn.apache.org/repos/asf/incubator/tuscany/java/BUILDING.txt nothing
get's built. Trying to build the sca profile or going directly to java/sca
give me an error, as there is no pom.xml available after Jeremy changed the
sca pom.xml to pom/sca. Also, couple modules does not built as of today, due
to changes in kernel, and there is no documentation of what's working or
not. And if you have to try to figure this out, you have to try each
module/project inside sca and try to figure out what's failing and what's
not.  Is this considered stable ?


Based on some e-mails I've read on this list, looks like if we really want
to expand out Tuscany SCA community, we really need some improvement over
what we have today around build and probably other areas as well. Also,
being able to build multiple modules at once, should not break the
modularity policy. Or maybe I'm really missing something, and maybe someone
could share with me an easy way to verify and build multiple modules for the
SCA project in trunk as currently I'm using a pretty old technique, a
build.bat that builds the modules i know are working.

-- 
Luciano Resende
http://people.apache.org/~lresende

On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Mar 12, 2007, at 12:57 PM, Bert Lamb wrote:
>
> > On 3/10/07, ant elder <an...@gmail.com> wrote:
> >> I think we really have to do something as its way to hard to get
> >> things
> >> built right now and I'm positive this is putting people off.
> >
> > It is actively putting me off right now.  The build problems with
> > Tuscany are quite off putting.  Anything that can be done to rectify
> > this and document the correct way to build, and to ensure that those
> > instructions continue to work would be greatly appreciated.
> The trunk has been quite stable for some time. What problems are you
> having when building? Have you tried the 2.0 alpha as you can avoid
> having to build source altogether?
>
> FYI there is documentation on building Java SCA at:
>
> http://cwiki.apache.org/TUSCANY/sca-java-development.html
>
> If something is unclear, let me know and I will try my best to answer
> questions.
>
> Jim
>
> >
> > -Bert
> >
> > ---------------------------------------------------------------------
> > 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: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Bert Lamb <al...@pobox.com>.
So, yes, I have no trouble building the kernel or the runtime (which
I'm sure is where you are spending the bulk of your time), but when I
attempt to build the extensions I get this error:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) org.apache.tuscany.sca.services.idl:wsdl:jar:0.1-pre-spec-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file
-DgroupId=org.apache.tuscany.sca.services.idl -DartifactId=wsdl \
          -Dversion=0.1-pre-spec-20070206.014758-3 -Dpackaging=jar
-Dfile=/path/to/file

  Path to dependency:
  	1) org.apache.tuscany.sca.extensions.axis2:tuscany-axis2:jar:1.0-incubator-SNAPSHOT
  	2) org.apache.tuscany.sca.services.idl:wsdl:jar:0.1-pre-spec-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
  org.apache.tuscany.sca.extensions.axis2:tuscany-axis2:jar:1.0-incubator-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  sateh (http://maven.sateh.com/maven2//),
  apache.incubator (http://people.apache.org/repo/m2-incubating-repository/),
  apache.ws.m1.snapshots (http://ws.zones.apache.org/repository),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache.ws (http://ws.zones.apache.org/repository/)


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12 seconds
[INFO] Finished at: Mon Mar 12 17:03:22 EDT 2007
[INFO] Final Memory: 10M/18M
[INFO] ------------------------------------------------------------------------

Ok, so I assume I need to build the services directory first before I
can build the extensions.  No dice:

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

GroupId: org.apache.tuscany.sca
ArtifactId: parent
Version: 1.0-incubator-SNAPSHOT

Reason: Unable to download the artifact from any repository

  org.apache.tuscany.sca:parent:pom:1.0-incubator-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.incubator (http://people.apache.org/repo/m2-incubating-repository/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)


[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
org.apache.tuscany.sca:parent for project:
org.apache.tuscany.sca.services:parent:pom:null
	at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
	at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
	at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: org.apache.tuscany.sca:parent for project:
org.apache.tuscany.sca.services:parent:pom:null
	at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1161)
	at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674)
	at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416)
	at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192)
	at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
	at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
	at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
	... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.tuscany.sca:parent' not found in repository: Unable to
download the artifact from any repository

  org.apache.tuscany.sca:parent:pom:1.0-incubator-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.incubator (http://people.apache.org/repo/m2-incubating-repository/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

	at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:513)
	at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1157)
	... 17 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository

  org.apache.tuscany.sca:parent:pom:1.0-incubator-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.incubator (http://people.apache.org/repo/m2-incubating-repository/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:136)
	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
	at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:467)
	... 18 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException:
Unable to download the artifact from any repository
	at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:260)
	at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124)
	... 20 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Mon Mar 12 16:56:42 EDT 2007
[INFO] Final Memory: 1M/2M
[INFO] ------------------------------------------------------------------------


Which I assume is related to some changes made recently to the parent
poms to get them released.

This is just what I've been trying to work out today, but usually when
I attempt an update there is something like this going on.

-Bert


On 3/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
> On Mar 12, 2007, at 12:57 PM, Bert Lamb wrote:
>
> > On 3/10/07, ant elder <an...@gmail.com> wrote:
> >> I think we really have to do something as its way to hard to get
> >> things
> >> built right now and I'm positive this is putting people off.
> >
> > It is actively putting me off right now.  The build problems with
> > Tuscany are quite off putting.  Anything that can be done to rectify
> > this and document the correct way to build, and to ensure that those
> > instructions continue to work would be greatly appreciated.
> The trunk has been quite stable for some time. What problems are you
> having when building? Have you tried the 2.0 alpha as you can avoid
> having to build source altogether?
>
> FYI there is documentation on building Java SCA at:
>
> http://cwiki.apache.org/TUSCANY/sca-java-development.html
>
> If something is unclear, let me know and I will try my best to answer
> questions.
>
> Jim
>
> >
> > -Bert
> >
> > ---------------------------------------------------------------------
> > 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: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jim Marino <jm...@myromatours.com>.
On Mar 12, 2007, at 12:57 PM, Bert Lamb wrote:

> On 3/10/07, ant elder <an...@gmail.com> wrote:
>> I think we really have to do something as its way to hard to get  
>> things
>> built right now and I'm positive this is putting people off.
>
> It is actively putting me off right now.  The build problems with
> Tuscany are quite off putting.  Anything that can be done to rectify
> this and document the correct way to build, and to ensure that those
> instructions continue to work would be greatly appreciated.
The trunk has been quite stable for some time. What problems are you  
having when building? Have you tried the 2.0 alpha as you can avoid  
having to build source altogether?

FYI there is documentation on building Java SCA at:

http://cwiki.apache.org/TUSCANY/sca-java-development.html

If something is unclear, let me know and I will try my best to answer  
questions.

Jim

>
> -Bert
>
> ---------------------------------------------------------------------
> 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: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Bert Lamb <al...@pobox.com>.
On 3/10/07, ant elder <an...@gmail.com> wrote:
> I think we really have to do something as its way to hard to get things
> built right now and I'm positive this is putting people off.

It is actively putting me off right now.  The build problems with
Tuscany are quite off putting.  Anything that can be done to rectify
this and document the correct way to build, and to ensure that those
instructions continue to work would be greatly appreciated.

-Bert

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by ant elder <an...@gmail.com>.
I think we really have to do something as its way to hard to get things
built right now and I'm positive this is putting people off. So if this side
tree approach will work then it sounds really good to me. Could you describe
a bit more about what this side tree would look like? Would it be building
the latest source of all the various Tuscany modules it uses or would it
just be using the published releases or snapshots of those modules?

   ...ant

On 3/10/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> Thanks
>
> Perhaps we could set up a side tree with a number of projects that
> built different assemblies (including all the dependencies people
> wanted for them). That way the "build-it-all" approach could be used
> for those assemblies and we wouldn't hit the version skew problems
> doing it naively from the root would cause?
>
> That would also allow people to develop in a modular way, with others
> managing the aggregation of those modules into different assemblies
> (a bit like people assemble Linux distros out of many (hundreds of
> modules).
>
> --
> Jeremy
>
> On Mar 9, 2007, at 3:31 PM, lresende@apache.org wrote:
>
> > Author: lresende
> > Date: Fri Mar  9 15:31:10 2007
> > New Revision: 516600
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=516600
> > Log:
> > Reverting 516588
> >
> > Modified:
> >     incubator/tuscany/java/pom.xml
> >
> > Modified: incubator/tuscany/java/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom.xml?
> > view=diff&rev=516600&r1=516599&r2=516600
> > ======================================================================
> > ========
> > --- incubator/tuscany/java/pom.xml (original)
> > +++ incubator/tuscany/java/pom.xml Fri Mar  9 15:31:10 2007
> > @@ -37,35 +37,9 @@
> >      </build>
> >
> >      <profiles>
> > -        <!-- default profile that builds everything that is
> > working-->
> > -        <profile>
> > -            <id>stable</id>
> > -            <activation>
> > -             <activeByDefault>true</activeByDefault>
> > -            </activation>
> > -            <modules>
> > -                <module>pom/parent</module>
> > -                <module>buildtools</module>
> > -                <module>spec/commonj</module>
> > -                <module>spec/sdo-api</module>
> > -                <module>spec/sca-api-r0.95</module>
> > -                <module>spec/sca-api-r1.0</module>
> > -                <module>sdo</module>
> > -                <module>das</module>
> > -                <module>sca/composite-plugin</module>
> > -                <module>sca/kernel</module>
> > -                <module>sca/runtime</module>
> > -                <module>sca/core-samples</module>
> > -                <module>sca/integration-test</module>
> > -                <module>sca/extensions\spring</module>
> > -                <module>sca/services/transaction/
> > transaction.geronimo</module>
> > -                <module>sca/services/persistence/common</module>
> > -            </modules>
> > -        </profile>
> > -
> >          <!-- default profile that builds everything -->
> >          <profile>
> > -            <id>all-integration</id>
> > +            <id>all</id>
> >              <modules>
> >                  <module>pom/parent</module>
> >                  <module>buildtools</module>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-commits-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: svn commit: r516600 - /incubator/tuscany/java/pom.xml

Posted by Jeremy Boynes <jb...@apache.org>.
Thanks

Perhaps we could set up a side tree with a number of projects that  
built different assemblies (including all the dependencies people  
wanted for them). That way the "build-it-all" approach could be used  
for those assemblies and we wouldn't hit the version skew problems  
doing it naively from the root would cause?

That would also allow people to develop in a modular way, with others  
managing the aggregation of those modules into different assemblies  
(a bit like people assemble Linux distros out of many (hundreds of  
modules).

--
Jeremy

On Mar 9, 2007, at 3:31 PM, lresende@apache.org wrote:

> Author: lresende
> Date: Fri Mar  9 15:31:10 2007
> New Revision: 516600
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=516600
> Log:
> Reverting 516588
>
> Modified:
>     incubator/tuscany/java/pom.xml
>
> Modified: incubator/tuscany/java/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/tuscany/java/pom.xml? 
> view=diff&rev=516600&r1=516599&r2=516600
> ====================================================================== 
> ========
> --- incubator/tuscany/java/pom.xml (original)
> +++ incubator/tuscany/java/pom.xml Fri Mar  9 15:31:10 2007
> @@ -37,35 +37,9 @@
>      </build>
>
>      <profiles>
> -        <!-- default profile that builds everything that is  
> working-->
> -        <profile>
> -            <id>stable</id>
> -            <activation>
> -	        <activeByDefault>true</activeByDefault>
> -            </activation>
> -            <modules>
> -                <module>pom/parent</module>
> -                <module>buildtools</module>
> -                <module>spec/commonj</module>
> -                <module>spec/sdo-api</module>
> -                <module>spec/sca-api-r0.95</module>
> -                <module>spec/sca-api-r1.0</module>
> -                <module>sdo</module>
> -                <module>das</module>
> -                <module>sca/composite-plugin</module>
> -                <module>sca/kernel</module>
> -                <module>sca/runtime</module>
> -                <module>sca/core-samples</module>
> -                <module>sca/integration-test</module>
> -                <module>sca/extensions\spring</module>
> -                <module>sca/services/transaction/ 
> transaction.geronimo</module>
> -                <module>sca/services/persistence/common</module>
> -            </modules>
> -        </profile>
> -
>          <!-- default profile that builds everything -->
>          <profile>
> -            <id>all-integration</id>
> +            <id>all</id>
>              <modules>
>                  <module>pom/parent</module>
>                  <module>buildtools</module>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-commits-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