Apache infra is moving out of California, they've been working on it most of
the week-end but there's still some broken servers. And people.apache.org is
one of them.

I'd suggest commenting out this repository meanwhile...

On 10/24/06, Lance Waterman <[EMAIL PROTECTED]> wrote:

Thanks Maciej - that seemed to clear things up.

I am having some trouble with the following:

Downloading:
http://people.apache.org/repo/m2-incubating-repository/xdoclet/xjav
adoc/1.1-j5/xjavadoc-1.1-j5.pom
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: xdoclet:xjavadoc

Reason: Error getting POM for 'xdoclet:xjavadoc' from the repository:
Error
tran
sferring file
  xdoclet:xjavadoc:pom:1.1-j5

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  ibiblio (http://www.ibiblio.org/maven2),
  intalio (http://pxe.intalio.org/public/maven2),
  snapshots (http://snapshots.maven.codehaus.org/maven2),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository
)


I've tried several times - anyone else experiencing problems with this
repository?

Thanks,

Lance


On 10/24/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
>
> forgot some checkins, should be better now.
>
> On 10/24/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
> >
> > I just sync'ed up and am seeing the following build error? I did a
clean
> > before trying the build.
> >
> > [INFO] [compiler:compile]
> > Compiling 66 source files to
> > C:\repositories\ode-update\bpel-compiler\target\cla
> > sses
> > [INFO]
> >
------------------------------------------------------------------------
> > [ERROR] BUILD FAILURE
> > [INFO]
> >
------------------------------------------------------------------------
> > [INFO] Compilation failure
> >
> >
> >
>
C:\repositories\ode-update\bpel-compiler\src\main\java\org\apache\ode\bpel\compi
> > ler\wsdl\WSDLFactoryBPEL20.java:[40,23] cannot find symbol
> > symbol  : variable NS_WSBPEL_2004_03
> > location: class org.apache.ode.bpel.compiler.bom.Constants
> >
> >
> >
>
C:\repositories\ode-update\bpel-compiler\src\main\java\org\apache\ode\bpel\compi
> > ler\wsdl\WSDLFactoryBPEL20.java:[40,52] cannot find symbol
> > symbol  : variable NS_WSBPEL_PARTNERLINK_2004_03
> > location: class org.apache.ode.bpel.compiler.bom.Constants
> >
> >
> >
>
C:\repositories\ode-update\bpel-compiler\src\main\java\org\apache\ode\bpel\compi
> > ler\wsdl\WSDLFactoryBPEL20.java:[55,78] cannot find symbol
> > symbol  : variable NS_WSBPEL_PARTNERLINK_2004_03
> > location: class org.apache.ode.bpel.compiler.bom.Constants
> >
> >
> >
>
C:\repositories\ode-update\bpel-compiler\src\main\java\org\apache\ode\bpel\compi
> > ler\BpelCompiler.java:[549,42] cannot find symbol
> > symbol  : variable NS_WSBPEL_2004_03
> > location: class org.apache.ode.bpel.compiler.bom.Constants
> >
> >
> >
>
C:\repositories\ode-update\bpel-compiler\src\main\java\org\apache\ode\bpel\compi
> > ler\BpelCompiler20.java:[59,24] cannot find symbol
> > symbol  : variable NS_WSBPEL_2004_03
> > location: class org.apache.ode.bpel.compiler.bom.Constants
> >
> > On 10/24/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
> > >
> > > The trunk has been updated with a refactored BPEL Compiler. This new
> > > compiler no longer uses the bpel-parser, bpel-bom modules. These
> modules
> > > have been removed. The FSA-based parser has been replaced with a
> > standard
> > > SAX-based DOM-builder. The BOM has been demoted. It is now a package
> of
> > > the
> > > bpel-compiler module. This new BOM is now a collection of
> BPEL-specific
> > > classes that wrap DOM-elements with handy getters, much like
XMLBeans
> > but
> > > more flexible. Also, some dependencies have changed. The compiler
API
> > > "capi"
> > > has been moved into the bpel-compiler module from the bpel-api
module.
> > > This
> > > means that the expression language modules bpel-el-xpath* now depend
> on
> > > the
> > > bpel-compiler, and not the other way around. The compiler depends on
> > these
> > > modules at runtime only via dynamic class-loading. Sounds
complicated,
> > but
> > > really makes things a lot simpler. It also makes it much much easier
> to
> > > write extension activities. Hooray.
> > > -mbs
> > >
> > >
> >
> >
>
>


Reply via email to