Nabble - Eclipse

build equinox

2009-11-29T10:19:15Z

Hello,

I have cvs co org.eclipse.equinox, but how do I build it? Can I read somewhere how it should be done?

Thanks,

Eric J.

_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

From forum: Equinox - Dev

Re: Newsreader 0.6.0

2009-11-29T08:39:47Z

Hi Wim,

How goes the newsreader move over to ECF (i.e. at osuosl location?). If
this is waiting on something from me or anything else that I can effect
please let me know.

Scott

Wim Jongman wrote:
> Version 0.6.0 for OSX is available on http://wiki.eclipse.org/newsreader
>
> Best regards,
>
> Wim
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@...
> https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: Module dependencies not working properly in m2eclipse?

2009-11-29T07:54:34Z

Switching from 0.9.8 to 0.9.9 fixed the problem. I had to point the eclipse update site to http://m2eclipse.sonatype.org/update-dev/ to get the latest dev version (0.9.9).

Peter De Maeyer wrote:

I have a parent project A with child projects (aka. modules) A1, A2 and A3. There are (compile) dependencies from A2->A1 and from A3->A2 and A3->A1. However, the dependencies created in the workspace are A1->A, A2->A, A3->A1 and A3->A, which is incorrect!

I have tried opening/closing projects, doing repeated "Maven->Update Project Configuration" , fiddling with the Maven properties... At some point during the experiments the properties were correct, but they went all wrong again as soon as I saved the .pom file again with a minor change.

At this point, the Maven properties for the projects are (I have tried different settings):

Project A:
"Skip Maven compiler plugin when processing resources" [checked]
"Resolve dependencies from Workspace projects" [unchecked]
"Include modules" [unchecked]

Projects A1, A2, A3:
"Skip Maven compiler plugin when processing resources" [checked]
"Resolve dependencies from Workspace projects" [checked]
"Include modules" [unchecked]

This problem is very frustrating for me, since I can't get anything to compile.

Peter

From forum: Maven Eclipse - User

Build with dependencies created during validate.

2009-11-29T07:52:30Z

Hello,

I'm looking for a way to get a pom.xml working that copies two dependencies to the local repository during the validate phase.

It works fine from the command line, but when run in m2eclipse I receive "Missing artifact" errors.

I've tried creating a separate m2 builder that just runs the validate phase, but still get the same messages.

I've also tried configuring the dependency plugin with "<failOnWarning>true</failOnWarning" but that had no effect.

The copying of the dependencies is done using a <goal>install-file</goal>.

Is there any way to convince m2eclipse to run a build target without it analyzing the dependencies first? Or a way to have it ignore missing dependencies?

Kenny
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: Maven Eclipse - User

orkut - Arvind kumar C wants you to join orkut!

2009-11-29T05:17:32Z

Arvind kumar C wants you to join orkut.

Join now!

what you can do on orkut:
	Connect with friends and family using scraps and instant messaging	Discover new people through friends of friends and communities	Share your videos, pictures, and passions all in one place
Stop sending me emails \| Help Center

_______________________________________________
birt-report-engine-dev mailing list
birt-report-engine-dev@...
https://dev.eclipse.org/mailman/listinfo/birt-report-engine-dev

From forum: Eclipse BIRT - Report Engine - Dev

equinox aspects/weaving in 3.4

2009-11-29T00:30:19Z

Hi all,

I'm trying to use equinox aspects (recently renamed equinox weaving) with a 3.4.1-based target platform. (Let me know if there's a better place for this question. The site is out-of-date wrt recent changes.)

Quick-start instructions work fine in my Eclipse 3.5.1-based target platforms. In 3.4.1-based platforms, there's no weaving. The bundles are resolved but not active. org.eclipse.equinox.weaving.

Is there a prior version of equinox-aspects that works under 3.4.1?

aspectj-1.0.0.200906171200 requires org.eclipse.equinox.service.weaving package. In 3.5 this is provided by org.eclipse.osgi - 3.5.1R35x_v20090827, but 3.4 does not have it in org.eclipse.osgi_3.4.2R34x_v20080826-1230. Attempting to upgrade causes the p2 dependency solver to complain that the original version-specific constraints cannot be satisfied. (And I'm not sure that's the only problem.)

If I change the 3.4 version requirements to permit the updated org.eclipse.orgi (and change the *.ini files), will it work?

Also, where's the CVS repository? The new one (dev.eclipse.org:/cvsroot/rt/org.eclipse.equinox) doesn't seem to work,and I see no incubating components in the old one.

Thanks!

References:
site?: http://www.eclipse.org/equinox/incubator/aspects/index.php
quickstart: http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php
rename: https://www.blogger.com/comment.g?blogID=18490491&postID=2734033852728096950&page=0&token
migration: http://wiki.eclipse.org/Equinox_Eclipse_to_RT_Migration

_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

From forum: Equinox - Dev

Problem with adding comm.jar as a library inside my bundle

2009-11-28T23:41:21Z

Hello all.

I am trying to add comm.jar (javax.comm implementation) inside my bundle
by putting it inside a directory in my bundle (called lib) and adding
the following to my manifest.mf (no other bundle uses this comm.jar
library so I prefer keeping it just inside my bundle instead of making
it a separate bundle):

Bundle-ClassPath: ., lib/comm.jar

However, the classes inside the javax.comm package are not available
inside my bundle. Are there any other steps that I need to take to make
that library added to my bundle's classpath?

Many thanks
Ali
_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

From forum: Equinox - Dev

Re: AspectJ and code coverage?

2009-11-28T19:42:00Z

Hi,

I don't know if there should be a difference, but my environment does not have Maven, just the eclipse plugins. The configuration is just some AspectJ projects and Java projects, the emma is configured for my junit tests, the instrumentation is not in-place. The project code is compile time woven, no LTW here.

I hope that helps,
Mike

Also, it is eclipse 3.4.2, recent aspectj, not sure what version.

On Sat, Nov 28, 2009 at 3:21 PM, oliver <boehm@...> wrote:

Hello Michael,

the plugin works as I tried it today. And there is also a maven plugin available for Emma. But when I tried to generate the reports with it I got a

java.lang.IllegalStateException: class [patterntesting.runtime.BrokenAspect] appears to be instrumented already

from the Emma plugin.

regards
Oliver

Am 28.11.2009 um 15:31 schrieb Michael McCray:

I am successfully using Eclpise + AJDT + EclEmma. The coverage does work, but sometimes there are strange consequences of woven code that doesn't get covered, but at least you can get pretty close to what you would expect.

It would be nice if it were AspectJ smart.

Mike

On Sat, Nov 28, 2009 at 2:09 AM, Wim Deblauwe <wim.deblauwe@...> wrote:

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Michael D. McCray
Consultant - Technology Partners, Inc.
President - Object Nirvana, Inc.
Maker of
My People Database
- automation for what you do with your friends and family, and a place to store your stories and information.
Website: http://www.mypeopledatabase.com/
Transcendental Beans Database
- an aspect oriented database system,
the future of data storage
Website: http://www.objectnirvana.com
Open source version: http://transcendentalbeans.dev.java.net/
Tweat Market - Twitter Dating Client
http://www.tweatmarket.com/
Blog: http://aodbms.blogspot.com
Email: mike@...
Twitter: http://twitter.com/seagullmike
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Oliver Böhm
boehm@...

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Michael D. McCray
Consultant - Technology Partners, Inc.
President - Object Nirvana, Inc.
Maker of
My People Database
- automation for what you do with your friends and family, and a place to store your stories and information.
Website: http://www.mypeopledatabase.com/
Transcendental Beans Database
- an aspect oriented database system,
the future of data storage
Website: http://www.objectnirvana.com
Open source version: http://transcendentalbeans.dev.java.net/
Tweat Market - Twitter Dating Client
http://www.tweatmarket.com/
Blog: http://aodbms.blogspot.com
Email: mike@...
Twitter: http://twitter.com/seagullmike

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: AspectJ and code coverage?

2009-11-28T13:21:30Z

Hello Michael,

the plugin works as I tried it today. And there is also a maven plugin available for Emma. But when I tried to generate the reports with it I got a

java.lang.IllegalStateException: class [patterntesting.runtime.BrokenAspect] appears to be instrumented already

from the Emma plugin.

regards

Oliver

Am 28.11.2009 um 15:31 schrieb Michael McCray:

I am successfully using Eclpise + AJDT + EclEmma. The coverage does work, but sometimes there are strange consequences of woven code that doesn't get covered, but at least you can get pretty close to what you would expect.

It would be nice if it were AspectJ smart.

Mike

On Sat, Nov 28, 2009 at 2:09 AM, Wim Deblauwe <wim.deblauwe@...> wrote:

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Michael D. McCray
Consultant - Technology Partners, Inc.
President - Object Nirvana, Inc.
Maker of
My People Database
- automation for what you do with your friends and family, and a place to store your stories and information.
Website: http://www.mypeopledatabase.com/
Transcendental Beans Database
- an aspect oriented database system,
the future of data storage
Website: http://www.objectnirvana.com
Open source version: http://transcendentalbeans.dev.java.net/
Tweat Market - Twitter Dating Client
http://www.tweatmarket.com/
Blog: http://aodbms.blogspot.com
Email: mike@...
Twitter: http://twitter.com/seagullmike
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Oliver Böhm

boehm@...

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Newsreader 0.6.0

2009-11-28T12:57:25Z

Version 0.6.0 for OSX is available on http://wiki.eclipse.org/newsreader

Best regards,

Wim
_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: AspectJ and code coverage?

2009-11-28T10:37:54Z

Hi,

I did some work recently to ensure AspectJ works better with Cobertura
- but I think that was when AspectJ was run after Cobertura (ltw
scenario) rather than before. When you say "does not work" - does it
crash? or is there a problem with the instrumentation it adds?

cheers,
Andy

2009/11/28 Michael McCray <mike@...>:

> I am successfully using Eclpise + AJDT + EclEmma. The coverage does work,
> but sometimes there are strange consequences of woven code that doesn't get
> covered, but at least you can get pretty close to what you would expect.
>
> It would be nice if it were AspectJ smart.
>
> Mike
>
>
> On Sat, Nov 28, 2009 at 2:09 AM, Wim Deblauwe <wim.deblauwe@...>
> wrote:
>>
>> Hi,
>>
>> is there anybody who is using AspectJ with a code coverage tool. We are
>> using Cobertura and Maven2, but that does not work when you start to add an
>> aspect to your code and you need to use the ajc compiler. I just checked
>> with Atlassian and Clover cannot seem to manage it according to them.
>> Anybody knows a workaround? I don't want to have code coverage on the
>> aspect, I just don't want to loose the coverage on my regular java classes.
>>
>> regards,
>>
>> Wim
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
>
> --
> Michael D. McCray
> Consultant - Technology Partners, Inc.
> President - Object Nirvana, Inc.
> Maker of
> My People Database
> - automation for what you do with your friends and family, and a place to
> store your stories and information.
> Website: http://www.mypeopledatabase.com/
> Transcendental Beans Database
> - an aspect oriented database system,
> the future of data storage
> Website: http://www.objectnirvana.com
> Open source version: http://transcendentalbeans.dev.java.net/
> Tweat Market - Twitter Dating Client
> http://www.tweatmarket.com/
> Blog: http://aodbms.blogspot.com
> Email: mike@...
> Twitter: http://twitter.com/seagullmike
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: rest API work

2009-11-28T08:41:12Z

Hi Andre,

Andre Dietisheim wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Scott
>
> while working with the existing API (by Holger) I noticed some issues,
> I'd love to get your feeback on and hopefully get a solution for my
> usecase. The issues exist in the former incarnation and your new
> implementation. I did not use your new version yet, just looked through
> the code:
>
> - - The current implementation allways creates a fresh instance of the
> httpClient:
>
> RestClientService:
> protected Object callHttpMethod(final IRemoteCall call, final
> IRestCallable callable) throws ECFException {
> String uri = prepareRequestURI(call, callable);
> HttpMethod httpMethod = createHttpMethod(uri, call, callable);
> // add additional request headers
> addRequestHeaders(httpMethod, call, callable);
> HttpClient httpClient = new HttpClient();
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I need the httpClient to be reused in order to keep the HTTP session
> state and so that existing cookies are re-sent in a later call.
> As far as I understand the code so far the user programmer holds the
> instance of the RestClientService.and may decide whether to reuse it or
> not. It should therefore be sufficient to move the httpClient to an
> instance variable of RestClientService.
>

This can/could be fairly easily done (i.e make it an option to create a
new HttpClient or reuse an existing one), but it would be an addition.
Please open an enhancement request to this effect (i.e. 'reuse
httpclient for rest calls' or something like that), and we'll get to it.

> - - I need to be able to elaborate on the specific HTTP error.In some
> cases my REST service answers 404 to signal me that there's no
> information present. I'll have to react by not showing any information
> for this call. On the other hand I'd have to popup an error for any
> other error that may occur (authentication, transport etc.). I'd suggest
> to pass an IStatus to the ECFException instead of a plain string. I'll
> then be able to fetch it's code.
>

The newly revised RestClientContainer and RestClientService classes
can/would/do allow subclassing to implement alternative strategies for
particular rest APIs...e.g. for handling http responses in custom ways
for a particular rest api. That is, it's intended that for *some* rest
clients, subclasses of RestClientContainer and RestClientService might
be created to customize the runtime behavior (since rest is more a
family of protocols than it is a single protocol).

In addition, it's possible that we could introduce some more flexibility
into these classes....e.g. RestClientService...through some
generalization of the protected and public methods...or by introducing
interfaces for delegation.

Scott

_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Re: rest API work

2009-11-28T08:28:50Z

Hi Andre,

Andre Dietisheim wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Scott
>
> Your work on ECF Rest looks pretty interesting. Thanks! I tried to catch
> up with the latest but I have still some compilation errors in my
> workspace. I'd appreciate a lot if you could gimme some hints here:
>
> - - all org.eclipse.ecf.remoteservice.rest.resource.* bundles don't
> compile any longer. They're missing a
> org.eclipse.ecf.remoteservice.rest.resource.IRestResource class

These projects/bundles are no longer needed (i.e. the
org.eclipse.ecf.remoteservice.rest.resource.* bundles).

> - - org.eclipse.ecf.tests.remoteservice does not compile any more. It
> lacks a package org.eclipse.ecf.server.generic
>

This project/package is in the normal ECF location in CVS...i.e.

/cvsroot/rt
org.eclipse.ecf/server-side/bundles/org.eclipse.ecf.server.generic

> - - org.eclipse.ecf.tests.remoteservice.rest does not compile any longer.
> It complains about the following call to createContainer. It's says that
> it may only be applyable with the arguments String, Object[]
>
> AbstractRestTestCase:
> protected IContainer createRestContainer(String uri) throws
> ContainerCreateException {
> return getContainerFactory().createContainer(
> RestConstants.REST_CONTAINER_TYPE, uri);
> }
>
>

The createContainer(String,String) method in IContainerFactory was just
recently added. So the easiest/best thing to do would be to get the
source for the org.eclipse.ecf project into your workspace. It's at

/cvsroot/rt
org.eclipse.ecf/framework/bundles/org.eclipse.ecf

Scott

_______________________________________________
ecf-dev mailing list
ecf-dev@...
https://dev.eclipse.org/mailman/listinfo/ecf-dev

From forum: Eclipse ECF - Dev

Maven for dependencies, Eclipse for deployment (JSF, Hibernate project) - does not work

2009-11-28T08:03:22Z

I want: Project built by Maven (because I want the libraries downloaded automatically), and deployed on a server by Eclipse.

I have tried, but with no luck - I can get a project built by Maven, but without the option to deploy it on the server, or a Dynamic web page project that can easily be deployed on the server, but Maven install has no effect on it.

I am using Eclipse Java EE IDE for Web Developers Build id: 20090920-1017 and the built-in Maven.

Any ideas?

From forum: Maven Eclipse - User

Re: AspectJ and code coverage?

2009-11-28T06:31:47Z

I am successfully using Eclpise + AJDT + EclEmma. The coverage does work, but sometimes there are strange consequences of woven code that doesn't get covered, but at least you can get pretty close to what you would expect.

It would be nice if it were AspectJ smart.

Mike

On Sat, Nov 28, 2009 at 2:09 AM, Wim Deblauwe <wim.deblauwe@...> wrote:

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: AspectJ and code coverage?

2009-11-28T03:08:40Z

Hello,

we have the same tool chain (Cobertura/Maven2) and the same problems. At the moment we have disabled Cobertura because we didn't find a workaround. If somebody knows one I would be also interested in.

regards,
Oliver

Am 28.11.2009 um 09:09 schrieb Wim Deblauwe:

> Hi,
>
> is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.
>
> regards,
>
> Wim
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Oliver Böhm
boehm@...

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

BUILD STATUS:: 1.1.0 nightly build failed!

2009-11-28T01:31:45Z

Build summary for 1.1.4.v20091128-r5921
-----------------------------------
Build log: (/shared/rt/eclipselink/logs/bsb-1.1.0_nightly_091128-0305.log)
Build logs can be found on the download server at:
http://www.eclipse.org/eclipselink/downloads/build-failures.php
-----------------------------------

SVN Changes since Last Build:
------------------------------------------------------------------------
r5921 | egwin | 2009-11-27 10:07:39 -0500 (Fri, 27 Nov 2009)
Changed paths:
M /branches/1.1.0/trunk/build.properties
M /branches/1.1.0/trunk/build.xml
M /branches/1.1.0/trunk/uploadToMaven.xml
------------------------------------------------------------------------
r5698 | egwin | 2009-10-30 04:14:39 -0400 (Fri, 30 Oct 2009)
Changed paths:
M /branches/1.1.0/trunk/eclipselink-src.zip
M /branches/1.1.0/trunk/eclipselink.jar
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

AspectJ and code coverage?

2009-11-28T00:09:29Z

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Expanding 'standards' for build files.

2009-11-27T21:15:14Z

Hi Eric,

Just like you define property pair <name>.lib and <name>.jar for every
single jar file, I define property pair <name>.dir and <name>.lib for
every single jar file. In the case you show here, the property pair
are junit.dir and junit.lib, overwiteing junit.dir won't effect other
dependencies at all.

-Edwin

On 2009-11-27, at 7:35 PM, Eric Gwin <eric.gwin@...> wrote:

> Edwin,
>
> That is exactly what I meant by "forces an assumption of the
> directory". I'll illustrate what I'm talking about below:
>
> The scenarios below assume the use of ${user.home}/build.properties
> and/or ${user.home}/test.properties for variable redefinition (as is
> currently the standard).
>
> If I check for say ${external.depend.dir}/${junit.lib} as you
> suggest, the junit jar will ONLY be found in ${external.depend.dir},
> so if you want to use JUnit in say "C:\__mydeps\junit45" with a
> jarname of "junit-4.5.jar" where the default name is "junit.jar",
> you'd not only have to redefine ${junit.lib} to be "junit-4.5.jar",
> but you'd also have to set ${external.depend.dir} to be "C:\__mydeps
> \junit45", which would also force all other dependencies that use
> that dir to be searched for in that location as well.
>
> By using the three variable standards I suggested (.jar, .lib,
> and .dir) I can do what I want easily and with one line:
> junit.lib=C:\__mydeps\junit45\junit-4.5.jar
> ${external.depend.dir} is unaffected (so the rest of my dependencies
> can come from the default location, or I could set it to:
> external.depend.dir=C:\__mydeps
> and the rest of my dependencies would come from there independent of
> the lib definition. It is true, that ${junit.jar} would be set to
> the default of "junit.jar" but I don't care because the paths and
> the dependency checks will use ${<name>.lib} as will all log and
> error messages.
>
> At any rate, I don't want to belabor the point, and you have already
> stated you have no real preference. Therefore, for the ease of use
> and flexibility described above I continue to put forward my
> original proposal.
>
> Are there any other questions, or suggestions from the community?
>
> -Eric
>
>
> Edwin Tang wrote:
>> You can check for the existence of <name>.dir/<name.lib>.
>> <name>.dir can ony specify one location, but <name>.lib in your
>> proposal can only point to one library too.
>>
>> -Edwin
>>
>> -----Original Message-----
>> From: Eric Gwin Sent: Friday, November 27, 2009 12:39 PM
>> To: Dev mailing list for Eclipse Persistence Services
>> Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.
>>
>>
>> No it doesn't, because you cannot check for the existence of a
>> jarname only. It is associated with a path (if nothing else "."),
>> Therefore the check for the file forces an assumption of the
>> directory which is inherently limiting. Also your scenario removes
>> the possibility of storing one dependency in a separate location
>> (say for one-off testing of a dependency change).
>>
>> -Eric
>> Edwin Tang wrote:
>>
>>> The example code using the other option is like:
>>>
>>> common.plugin.dir=./plugins
>>> external.depends.dir=../external.lib
>>> junit.lib=junit-4.5.jar
>>> junit.dir=${external.depends.dir}
>>>
>>>
>>> after testing for existence of junit.lib and others...
>>> <path pathref="external.compile.deps.path">
>>> <pathelement ="${junit.dir}/${junit.lib}/>
>>> <pathelement="${jdbc.dir}/${jdbc.lib}"/>
>>> ...
>>> </path>
>>>
>>> It looks like there are no differences but personal preferences.
>>> Either option is fine for me.
>>>
>>> Thanks,
>>> Edwin
>>>
>>> -----Original Message-----
>>> From: Eric Gwin Sent: Friday, November 27, 2009 10:46 AM
>>> To: Dev mailing list for Eclipse Persistence Services
>>> Subject: Re: [eclipselink-dev] Expanding 'standards' for build
>>> files.
>>>
>>>
>>> So if you want to say use "junit.jar" as the filename, you only
>>> need to redefine ${junit.jar}, if you want a different directory
>>> to hold all your dependencies you only need to redefine $
>>> {external.depends.dir}, and if you want to do both and use a
>>> custom named xdb-11-rel2.jar, in a completely seperate location
>>> with the previous setup you could simply add a redefinition of $
>>> {xdb.lib}.
>>>
>>> -Eric
>>>
>>> Eric Gwin wrote:
>>>
>>>> It doesn't. It's more like: (values are just for example...):
>>>>
>>>> common.plugin.dir=./plugins
>>>> external.depends.dir=../external.lib
>>>> junit.jar=junit-4.5.jar
>>>> junit.lib=${external.depends.dir}/${junit.jar}
>>>>
>>>>
>>>> after testing for existence of junit.lib and others...
>>>> <path pathref="external.compile.deps.path">
>>>> <pathelement ="${junit.lib}/>
>>>> <pathelement="${jdbc.lib}"/>
>>>> ...
>>>> </path>
>>>>
>>>> That minimal redefinitions need to be made for jar names or dirs
>>>> if they are customized, and jars can be grouped together, or in
>>>> different dirs, as required by the developer/user. However, the
>>>> defined location can still be tested for (verify it is found),
>>>> before it is added to a classpath (which in many cases will cause
>>>> errors if it doesn't exist).
>>>>
>>>> -Eric
>>>>
>>>> Edwin Tang wrote:
>>>>
>>>>> Hi Gordon,
>>>>>
>>>>> If the proposal includes a plan to introduce <name>.dir for
>>>>> every single jar file, then there are no substantial differences
>>>>> between these 2 options.
>>>>>
>>>>> Thanks,
>>>>> Edwin
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gordon Yorke Sent: Friday, November 27, 2009 9:34 AM
>>>>> To: Dev mailing list for Eclipse Persistence Services
>>>>> Subject: Re: [eclipselink-dev] Expanding 'standards' for build
>>>>> files.
>>>>>
>>>>>
>>>>> I prefer Eric's proposal for <name>.jar, <name>.lib and <name>.dir
>>>>> --Gordon
>>>>>
>>>>> Edwin Tang wrote:
>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>> This is great initiative.
>>>>>>
>>>>>> Probably, instead of <name>.jar, <name>.lib and <name>.path, it
>>>>>> could better that we have
>>>>>> <name>.dir: the location of a jar file
>>>>>> <name>.lib: a jar file name
>>>>>> <name>.path: a path element defined by <pathelement path="$
>>>>>> {<name>.dir}/${<name>.lib}"/>
>>>>>>
>>>>>> The benifits of this option are:
>>>>>> 1. Users have full flexibility to able to customize <name>.dir,
>>>>>> <name>.lib, or both for every single jar file
>>>>>> 2. Avoid the difficulty to choose a sound property name -
>>>>>> <name>.jar or <name>.jarfile
>>>>>> 3. Be consistent with the TopLink test/build naming conventions
>>>>>>
>>>>>> Thanks,
>>>>>> Edwin
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric Gwin Sent: Thursday, November 26, 2009 8:06 AM
>>>>>> To: Dev mailing list for Eclipse Persistence Services
>>>>>> Subject: [eclipselink-dev] Expanding 'standards' for build files.
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm sending this out as a notification/proposal of some
>>>>>> additional standard conventions I plan on adding to our build
>>>>>> files after the branch.
>>>>>> - properties ending in .jar define jarfile names only (no
>>>>>> path)
>>>>>> - properties ending in .lib are fully qualified jars (path
>>>>>> and filename)
>>>>>> - properties ending in .dir are directory paths
>>>>>> - properties ending in .path are path refid names
>>>>>> (classpath fragments)
>>>>>> - targets beginning with test- are reserved for high level
>>>>>> test targets,
>>>>>> and are used in test results parsing
>>>>>> - targets typically use the form <action>-<object>-<type>
>>>>>> (ie. package-bundle-zip)
>>>>>>
>>>>>> Some are clarifications of standards already in place, but not
>>>>>> well publicized. However, with regard to .jar/.lib
>>>>>> and .dir/.path there is no current standard, and properties are
>>>>>> named and used in a fairly random mostly interchangeable way.
>>>>>> There are many reasons this is becoming an issue now, but here
>>>>>> are the biggest:
>>>>>> - bugs requesting the use of minimal classpaths necessitate
>>>>>> the need to individually
>>>>>> define libraries. However, the build has multiple entry
>>>>>> points so paths to those
>>>>>> libraries are relative to the entry point. So the need to
>>>>>> separate path from jar name.
>>>>>> - adding individual libraries (rather than
>>>>>> eclipselink.core.depend or eclipslink.oracle.depend
>>>>>> which list them all) also creates a need to separately
>>>>>> define directories and classpath subsets.
>>>>>>
>>>>>> For the most part I've tried to keep the usage most prevalent
>>>>>> for each postfix
>>>>>> -.lib was mostly used to define full paths to jars, while .jar
>>>>>> mostly defined jar names. However,
>>>>>> there are also a few non-conformant properties (eclipselink.jar.name
>>>>>> and .jarfile)
>>>>>> -.dir really hasn't changed at all, but there were a few uses
>>>>>> where it was a defining a pathref
>>>>>> -.path is pretty much new old pathrefs were either .dir
>>>>>> or .classpath
>>>>>>
>>>>>> While I needed to implement these changes for the oracle
>>>>>> modules for critical fixes in 2.0.0, I plan on implementing
>>>>>> these changes across the board after the branch and discussion
>>>>>> has occurred.
>>>>>>
>>>>>> Does anyone object to these standards, or have preferences
>>>>>> other than what I plan to implement? I can see .jarfile being
>>>>>> used as the standard postfix because the property can't easily
>>>>>> be confused with a static usage of a jar, but it wasn't
>>>>>> routinely used.
>>>>>>
>>>>>> Comments? (If I hear nothing from you I will assume it is
>>>>>> assent, and continue as outlined after the branch is complete.)
>>>>>>
>>>>>> -Eric
>>>>>> _______________________________________________
>>>>>> eclipselink-dev mailing list
>>>>>> eclipselink-dev@...
>>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>>> _______________________________________________
>>>>>> eclipselink-dev mailing list
>>>>>> eclipselink-dev@...
>>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>>>
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>
>>>>
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
>>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

[Fwd: BUILD STATUS:: 2.0 cb build complete.]

2009-11-27T18:21:12Z

FYI. First CB to pass on 2.0 branch (first two builds failed for setup
reasons. 2.0 is good to go... (though still in lock-down unless Peter or
Doug approve a merge).

-Eric

-------- Original Message --------
Subject: BUILD STATUS:: 2.0 cb build complete.
Date: Fri, 27 Nov 2009 21:17:52 -0500
From: eric.gwin@...
To: eric.gwin@...

Build summary for 2.0.0.v20091127-r5938
-----------------------------------
TEST-CORE-SRG
Tests run:683 Failures:0 Errors:0
TEST-JPA-SRG
Tests run:192 Failures:0 Errors:0
TEST-MOXY-SRG
Tests run:458 Failures:0 Errors:0
TEST-SDO-SRG
Tests run:120 Failures:0 Errors:0
TEST-DBWS-SRG
Tests run:14 Failures:0 Errors:0
TEST-DBWS-UTILS-SRG
Tests run:22 Failures:0 Errors:0
-----------------------------------

Build log: (/shared/rt/eclipselink/logs/bsb-2.0_cb_091127-2101.log)
-----------------------------------

SVN Changes since Last Build:
------------------------------------------------------------------------
r5938 | egwin | 2009-11-27 20:57:43 -0500 (Fri, 27 Nov 2009)
Changed paths:
M /branches/2.0/trunk/build.xml
------------------------------------------------------------------------

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Resolved... Re: BUILD STATUS:: 2.0 cb build failed!

2009-11-27T18:04:27Z

Ignore. I missed a step setting up the build machine for the new branch.

-Eric

eric.gwin@... wrote:

> Build summary for 2.0.0.v20091127-r5937
> -----------------------------------
> Build log: (/shared/rt/eclipselink/logs/bsb-2.0_cb_091127-1920.log)
> Build logs can be found on the download server at:
> http://www.eclipse.org/eclipselink/downloads/build-failures.php
> -----------------------------------
>
> SVN Changes since Last Build:
> ------------------------------------------------------------------------
> r5937 | egwin | 2009-11-27 18:39:46 -0500 (Fri, 27 Nov 2009)
> Changed paths:
> M /branches/2.0/trunk/uploadToMaven.xml
> ------------------------------------------------------------------------
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Expanding 'standards' for build files.

2009-11-27T16:35:03Z

Edwin,

That is exactly what I meant by "forces an assumption of the directory".
I'll illustrate what I'm talking about below:

The scenarios below assume the use of ${user.home}/build.properties
and/or ${user.home}/test.properties for variable redefinition (as is
currently the standard).

If I check for say ${external.depend.dir}/${junit.lib} as you suggest,
the junit jar will ONLY be found in ${external.depend.dir}, so if you
want to use JUnit in say "C:\__mydeps\junit45" with a jarname of
"junit-4.5.jar" where the default name is "junit.jar", you'd not only
have to redefine ${junit.lib} to be "junit-4.5.jar", but you'd also have
to set ${external.depend.dir} to be "C:\__mydeps\junit45", which would
also force all other dependencies that use that dir to be searched for
in that location as well.

By using the three variable standards I suggested (.jar, .lib, and .dir)
I can do what I want easily and with one line:
junit.lib=C:\__mydeps\junit45\junit-4.5.jar
${external.depend.dir} is unaffected (so the rest of my dependencies can
come from the default location, or I could set it to:
external.depend.dir=C:\__mydeps
and the rest of my dependencies would come from there independent of the
lib definition. It is true, that ${junit.jar} would be set to the
default of "junit.jar" but I don't care because the paths and the
dependency checks will use ${<name>.lib} as will all log and error
messages.

At any rate, I don't want to belabor the point, and you have already
stated you have no real preference. Therefore, for the ease of use and
flexibility described above I continue to put forward my original proposal.

Are there any other questions, or suggestions from the community?

-Eric

Edwin Tang wrote:

> You can check for the existence of <name>.dir/<name.lib>.
> <name>.dir can ony specify one location, but <name>.lib in your proposal can only point to one library too.
>
> -Edwin
>
> -----Original Message-----
> From: Eric Gwin
> Sent: Friday, November 27, 2009 12:39 PM
> To: Dev mailing list for Eclipse Persistence Services
> Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.
>
>
> No it doesn't, because you cannot check for the existence of a jarname
> only. It is associated with a path (if nothing else "."), Therefore the
> check for the file forces an assumption of the directory which is
> inherently limiting. Also your scenario removes the possibility of
> storing one dependency in a separate location (say for one-off testing
> of a dependency change).
>
> -Eric
>
> Edwin Tang wrote:
>
>> The example code using the other option is like:
>>
>> common.plugin.dir=./plugins
>> external.depends.dir=../external.lib
>> junit.lib=junit-4.5.jar
>> junit.dir=${external.depends.dir}
>>
>>
>> after testing for existence of junit.lib and others...
>> <path pathref="external.compile.deps.path">
>> <pathelement ="${junit.dir}/${junit.lib}/>
>> <pathelement="${jdbc.dir}/${jdbc.lib}"/>
>> ...
>> </path>
>>
>> It looks like there are no differences but personal preferences. Either option is fine for me.
>>
>> Thanks,
>> Edwin
>>
>> -----Original Message-----
>> From: Eric Gwin
>> Sent: Friday, November 27, 2009 10:46 AM
>> To: Dev mailing list for Eclipse Persistence Services
>> Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.
>>
>>
>> So if you want to say use "junit.jar" as the filename, you only need to
>> redefine ${junit.jar}, if you want a different directory to hold all
>> your dependencies you only need to redefine ${external.depends.dir}, and
>> if you want to do both and use a custom named xdb-11-rel2.jar, in a
>> completely seperate location with the previous setup you could simply
>> add a redefinition of ${xdb.lib}.
>>
>> -Eric
>>
>> Eric Gwin wrote:
>>
>>
>>> It doesn't. It's more like: (values are just for example...):
>>>
>>> common.plugin.dir=./plugins
>>> external.depends.dir=../external.lib
>>> junit.jar=junit-4.5.jar
>>> junit.lib=${external.depends.dir}/${junit.jar}
>>>
>>>
>>> after testing for existence of junit.lib and others...
>>> <path pathref="external.compile.deps.path">
>>> <pathelement ="${junit.lib}/>
>>> <pathelement="${jdbc.lib}"/>
>>> ...
>>> </path>
>>>
>>> That minimal redefinitions need to be made for jar names or dirs if
>>> they are customized, and jars can be grouped together, or in different
>>> dirs, as required by the developer/user. However, the defined location
>>> can still be tested for (verify it is found), before it is added to a
>>> classpath (which in many cases will cause errors if it doesn't exist).
>>>
>>> -Eric
>>>
>>> Edwin Tang wrote:
>>>
>>>
>>>> Hi Gordon,
>>>>
>>>> If the proposal includes a plan to introduce <name>.dir for every
>>>> single jar file, then there are no substantial differences between
>>>> these 2 options.
>>>>
>>>> Thanks,
>>>> Edwin
>>>>
>>>> -----Original Message-----
>>>> From: Gordon Yorke Sent: Friday, November 27, 2009 9:34 AM
>>>> To: Dev mailing list for Eclipse Persistence Services
>>>> Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.
>>>>
>>>>
>>>> I prefer Eric's proposal for <name>.jar, <name>.lib and <name>.dir
>>>> --Gordon
>>>>
>>>> Edwin Tang wrote:
>>>>
>>>>
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> This is great initiative.
>>>>>
>>>>> Probably, instead of <name>.jar, <name>.lib and <name>.path, it
>>>>> could better that we have
>>>>> <name>.dir: the location of a jar file
>>>>> <name>.lib: a jar file name
>>>>> <name>.path: a path element defined by <pathelement
>>>>> path="${<name>.dir}/${<name>.lib}"/>
>>>>>
>>>>> The benifits of this option are:
>>>>> 1. Users have full flexibility to able to customize <name>.dir,
>>>>> <name>.lib, or both for every single jar file
>>>>> 2. Avoid the difficulty to choose a sound property name - <name>.jar
>>>>> or <name>.jarfile
>>>>> 3. Be consistent with the TopLink test/build naming conventions
>>>>>
>>>>> Thanks,
>>>>> Edwin
>>>>>
>>>>> -----Original Message-----
>>>>> From: Eric Gwin Sent: Thursday, November 26, 2009 8:06 AM
>>>>> To: Dev mailing list for Eclipse Persistence Services
>>>>> Subject: [eclipselink-dev] Expanding 'standards' for build files.
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm sending this out as a notification/proposal of some additional
>>>>> standard conventions I plan on adding to our build files after the
>>>>> branch.
>>>>> - properties ending in .jar define jarfile names only (no path)
>>>>> - properties ending in .lib are fully qualified jars (path and
>>>>> filename)
>>>>> - properties ending in .dir are directory paths
>>>>> - properties ending in .path are path refid names (classpath
>>>>> fragments)
>>>>> - targets beginning with test- are reserved for high level test
>>>>> targets,
>>>>> and are used in test results parsing
>>>>> - targets typically use the form <action>-<object>-<type> (ie.
>>>>> package-bundle-zip)
>>>>>
>>>>> Some are clarifications of standards already in place, but not well
>>>>> publicized. However, with regard to .jar/.lib and .dir/.path there
>>>>> is no current standard, and properties are named and used in a
>>>>> fairly random mostly interchangeable way. There are many reasons
>>>>> this is becoming an issue now, but here are the biggest:
>>>>> - bugs requesting the use of minimal classpaths necessitate the
>>>>> need to individually
>>>>> define libraries. However, the build has multiple entry
>>>>> points so paths to those
>>>>> libraries are relative to the entry point. So the need to
>>>>> separate path from jar name.
>>>>> - adding individual libraries (rather than
>>>>> eclipselink.core.depend or eclipslink.oracle.depend
>>>>> which list them all) also creates a need to separately
>>>>> define directories and classpath subsets.
>>>>>
>>>>> For the most part I've tried to keep the usage most prevalent for
>>>>> each postfix
>>>>> -.lib was mostly used to define full paths to jars, while .jar
>>>>> mostly defined jar names. However,
>>>>> there are also a few non-conformant properties
>>>>> (eclipselink.jar.name and .jarfile)
>>>>> -.dir really hasn't changed at all, but there were a few uses where
>>>>> it was a defining a pathref
>>>>> -.path is pretty much new old pathrefs were either .dir or .classpath
>>>>>
>>>>> While I needed to implement these changes for the oracle modules for
>>>>> critical fixes in 2.0.0, I plan on implementing these changes across
>>>>> the board after the branch and discussion has occurred.
>>>>>
>>>>> Does anyone object to these standards, or have preferences other
>>>>> than what I plan to implement? I can see .jarfile being used as the
>>>>> standard postfix because the property can't easily be confused with
>>>>> a static usage of a jar, but it wasn't routinely used.
>>>>>
>>>>> Comments? (If I hear nothing from you I will assume it is assent,
>>>>> and continue as outlined after the branch is complete.)
>>>>>
>>>>> -Eric
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>
>>>
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
>>
>>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

BUILD STATUS:: 2.0 cb build failed!

2009-11-27T16:25:35Z

Build summary for 2.0.0.v20091127-r5937
-----------------------------------
Build log: (/shared/rt/eclipselink/logs/bsb-2.0_cb_091127-1920.log)
Build logs can be found on the download server at:
http://www.eclipse.org/eclipselink/downloads/build-failures.php
-----------------------------------

SVN Changes since Last Build:
------------------------------------------------------------------------
r5937 | egwin | 2009-11-27 18:39:46 -0500 (Fri, 27 Nov 2009)
Changed paths:
M /branches/2.0/trunk/uploadToMaven.xml
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Branch 2.0 Created...

2009-11-27T16:01:48Z

Oh, I guess I should make it official:

trunk is open for transactions! ...

-Eric

Eric Gwin wrote:

> And trunk has been updated to version 2.1.0
>
> I am setting up the nightly to run on trunk, 1.1.0, and 1.2 (for now
> 2.0 is still locked - show stopper mode)
> Continuous Builds will run on trunk, and 2.0 (to detect transactions).
>
> Early next week, I may setup CBs on 1.2 and 1.1.0 as well, but need to
> discuss with Peter and Doug first .
>
> -Eric
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Branch 2.0 Created...

2009-11-27T15:48:25Z

And trunk has been updated to version 2.1.0

I am setting up the nightly to run on trunk, 1.1.0, and 1.2 (for now 2.0
is still locked - show stopper mode)
Continuous Builds will run on trunk, and 2.0 (to detect transactions).

Early next week, I may setup CBs on 1.2 and 1.1.0 as well, but need to
discuss with Peter and Doug first .

-Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

EclipseLink 2.0.0 RC1 Complete...

2009-11-27T15:42:03Z

Web has been updated.

-Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

RE: Informally Promoted Build for wtp-R3.2.0-I: I-3.2.0-20091127073002

2009-11-27T14:39:12Z

Sure enough, org.eclipse.ui.wizards.datatransfer.ImportOperation has changed in a way that breaks a few of our (JSF Tools Project) tests. ImportOperation used to tolerate being constructed with an empty (but not null) path, and now it does not. We will need to change our test data and test utility slightly to accommodate the change.

- Ian

From: Ian Trimble
Sent: Friday, November 27, 2009 10:45 AM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Informally Promoted Build for wtp-R3.2.0-I: I-3.2.0-20091127073002

I’ve taken a look at the failing JSF test cases and have narrowed it down to all tests that use a specific JSF testing utility method (ProjectTestEnvironment.createFromZip(…)). This method creates an org.eclipse.ui.wizards.datatransfer.ImportOperation with an empty “containerPath”. Running the current JSF code under an older platform/WTP build (Galileo, or at least close to it) does not complain about this empty path. When I can find time, I will set up a newer build environment to see if the change is, as I suspect, to ImportOperation. I don’t think ImportOperation is necessarily flawed; I think it’s just no longer somehow dealing with being passed an empty path.

The short version is, JSF tests are currently failing due to how the tests are written, and not due to non-test code breakage. It’s highly doubtful that this could affect anyone else (but you’d be well-advised to check any of your code that uses ImportOperation).

Happy Thanksgiving, US folks,

- Ian

From: David M Williams [mailto:david_williams@...]
Sent: Friday, November 27, 2009 6:40 AM
To: wtp-dev@...
Subject: [wtp-dev] Informally Promoted Build for wtp-R3.2.0-I: I-3.2.0-20091127073002

At our status meeting last week, we decided we would not have a declared build this week, since so many were out on holiday.

But a few days after the meeting, some committers (not in the US :) said they would like a build promoted to 'downloads' to enable some early adopter testing and development, since M4 is not that far off.

So, I'll promote this latest build, but call it "informally promoted" instead of "declared" since it has not been tested as we normally do.

I will leave it "invisible" if you look at the plain downloads page,http://download.eclipse.org/webtools/downloads/, but if you know this whole URL you can get right to it.

Download Page:
http://download.eclipse.org/webtools/downloads/drops/R3.2.0/I-3.2.0-20091127073002/

Hopefully this will prevent people from casually downloading it, thinking it was just like every other I-build. Hopefully it is a good build, but since we have not smoke tested it, we can not confidently say much about it.

There are a few JUnit failures that appear significant. They occur in the JSF tests, but suspect they are due to changes made elsewhere?

_______________________________________________
wtp-dev mailing list
wtp-dev@...
https://dev.eclipse.org/mailman/listinfo/wtp-dev

From forum: Eclipse WTP - general

Re: RCP Application working through eclipse but not as an exported application

2009-11-27T13:05:55Z

Hi!

The runtime complains about the missing constraint because your
update.configurator starts later than the weaving.aspectj bundle, so
there are only those bundles available that are mentioned in the
config.ini at that point in time. Just mention aspectj.runtime and
aspectj.weaver in your config.ini as well and the missing constraint
error should go away.

-Martin

On 27.11.09 21:55, mikkel.t.andersen@... wrote:

> I am a afraid not, that was just because it was not startet yet... I do
> have org.aspectj.weaver plugin in my plugins folder.
>
> Den skrev Andrew Eisenberg <andrew@...>:
>> This line tells me that the weaver is not included in your target
>
>> platform. Is this true?
>
>
>
>> > Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver;
>
>> > bundle-version="0.0.0"
>
>> _______________________________________________
>
>> aspectj-dev mailing list
>
>> aspectj-dev@...
>
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re:Re: Re: RCP Application working through eclipse but not as an exported application

2009-11-27T12:55:26Z

I am a afraid not, that was just because it was not startet yet... I do have org.aspectj.weaver plugin in my plugins folder.

Den skrev Andrew Eisenberg <andrew@...>:

> This line tells me that the weaver is not included in your target
>
> platform. Is this true?
>
>
>
> > Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver;
>
> > bundle-version="0.0.0"
>
> _______________________________________________
>
> aspectj-dev mailing list
>
> aspectj-dev@...
>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re: Re: RCP Application working through eclipse but not as an exported application

2009-11-27T12:48:32Z

This line tells me that the weaver is not included in your target
platform. Is this true?

> Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver;
> bundle-version="0.0.0"
_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re: Re: RCP Application working through eclipse but not as an exported application

2009-11-27T11:31:13Z

On Nov 27, 2009 3:45pm, Martin Lippert <lippert@...> wrote:
> Hi Mikkel,
>
>
>
> I am not sure what the problem really is but there are several things you could check here:
>
>
>
> - Your aspect bundle defines a require-bundle on the several weaving bundles. This is not necessary and should not be the case for aspect bundles.

My aspect bundle also has alot of UI code in it, should I create a pure aspect plugin?
Is there anything I can put in my config.ini to get even more debug details?

>
>
>
> - Is the aop.xml file copied in your exported plugin? So is it really contained in the JAR file of your bundle in the META-INF directory?

I tripple checked that :) it is in there when exported... I also tried not having the plugin it as a jar-file but a folder-plugin... still no luck... should that matter ?

>
>
>
> - Try to change the start level of weaving.asepctj from 4 to 2 (in your config.ini).

I did that but then it complains about

!ENTRY org.eclipse.equinox.weaving.aspectj 4 0 2009-11-27 20:10:10.985
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Require-Bundle: org.aspectj.weaver; bundle-version="0.0.0"
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1068)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:557)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:464)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:248)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:445)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
[org.aspectj.osgi.service.weaving] info Starting AspectJ weaving service ...

I tried adding start in config.ini - (org.aspectj.weaver@2\:start ) but that gave exception on org.aspecj.runtime not resolved... so I added that aswell... then it started up with no exceptions, but still no weaving....

Do you have an exported demo.zip with a application that runs with aspects?

I run Ubuntu should that matter?

Any other suggestions are very much appriciated!

>
>
> HTH,
>
> Martin
>
>
>
>
>
>
>
> On 27.11.09 07:59, Mikkel Andersen wrote:
>
>
> I exported as a AspectJ supported product, I even checked that the .aj file
>
> is a .class file in the plugin...
>
>
>
> This is my AOP file that is in the META-INF folder...
>
>
>
>
>
>
>
>
>
>
> name="org.plugination.clubadmin.ui.aspects.PropertyChangeSupportAspect"/>
>
>
>
>
>
>
>
> And thats the manifest for the plugin with the aspect in...
>
>
>
> Manifest-Version: 1.0
>
> Bundle-RequiredExecutionEnvironment: JavaSE-1.6
>
> Bundle-ManifestVersion: 2
>
> Bundle-Name: Club Admin UI Plug-in
>
> Bundle-SymbolicName: org.plugination.clubadmin.ui;singleton:=true
>
> Bundle-Version: 1.0.0
>
> Bundle-Activator: org.plugination.clubadmin.ui.UiPlugin
>
> Bundle-Vendor: plugination.org
>
> Eclipse-SupplementBundle: org.plugination.clubadmin.core
>
> Require-Bundle: org.plugination.clubadmin.core,org.eclipse.core.runtim
>
> e,org.eclipse.ui,org.eclipse.jface.databinding,org.eclipse.ui.forms,o
>
> rg.plugination.transactionsystem,org.plugination.undosystem,org.plugi
>
> nation.reportsystem,org.plugination.persistencesystem,com.ibm.icu,org
>
> .eclipse.core.databinding,org.eclipse.core.databinding.beans,org.plug
>
> ination.ui,org.apache.log4j,org.aspectj.runtime;visibility:=reexport,
>
> org.aspectj.weaver;visibility:=reexport,org.eclipse.equinox.weaving.a
>
> spectj;bundle-version="1.0.0",org.eclipse.equinox.weaving.caching;bun
>
> dle-version="1.0.0",org.eclipse.equinox.weaving.caching.j9;bundle-ver
>
> sion="1.0.0",org.eclipse.nebula.widgets.datechooser;bundle-version="1
>
> .0.0",org.eclipse.nebula.widgets.formattedtext;bundle-version="1.0.0"
>
> Bundle-ActivationPolicy: lazy
>
> Export-Package: org.plugination.clubadmin.ui,org.plugination.clubadmin
>
> .ui.aspects
>
>
>
> I cannot see what is wrong? it seems like this line:
>
> info AspectJ Weaver Version 1.6.6 built on Wednesday Sep 30, 2009 at
>
> 18:55:14 GMT
>
> is the first line I am missing in the log file when running outside
>
> eclipse.... any thoughts on why that is not displayed or when it should be
>
> displayed?
>
> Does the plugins exported need to be folders rather then .jar files ? (does
>
> that matter for the weaver)
>
>
>
>
>
> On Fri, Nov 27, 2009 at 2:28 AM, Andrew Eisenbergandrew@...>wrote:
>
>
>
>
> It looks like your aspects have not been compiled properly. How did
>
> you export your product? Did you use the Export Product with AspectJ
>
> support?
>
>
>
> On Thu, Nov 26, 2009 at 11:41 AM, Mikkel Andersen
>
> mikkel.t.andersen@...> wrote:
>
>
> I followed this example
>
>
>
>
> http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php
>
>
> and created my own RCP app with a bundle that need weaving, and a bundle
>
> that weaves the aspect in, through LTW.
>
>
>
> This all works when running inside eclipse, but when I export the product
>
>
> it
>
>
> does not work.
>
>
>
> Here is the info I get when running inside eclipse
>
> [org.eclipse.equinox.weaving.hook] info adding AspectJ hooks ...
>
> [org.eclipse.equinox.weaving.
>
> aspectj] info Starting AspectJ weaving service ...
>
> [org.plugination.clubadmin.ui] info AspectJ Weaver Version 1.6.6 built on
>
> Wednesday Sep 30, 2009 at 18:55:14 GMT
>
> [org.plugination.clubadmin.ui] info register aspect
>
> org.plugination.clubadmin.ui.aspects.PropertyChangeSupportAspect
>
> [org.eclipse.equinox.weaving.aspectj] info weaving bundle
>
> 'org.plugination.clubadmin.ui'
>
> [org.plugination.clubadmin.core] info AspectJ Weaver Version 1.6.6 built
>
>
> on
>
>
> Wednesday Sep 30, 2009 at 18:55:14 GMT
>
> [org.plugination.clubadmin.core] info register aspect
>
> org.plugination.clubadmin.ui.aspects.PropertyChangeSupportAspect
>
> [org.eclipse.equinox.weaving.aspectj] info weaving bundle
>
> 'org.plugination.clubadmin.core'
>
> ....
>
>
>
> And here is it when I run outside eclipse
>
> [org.eclipse.equinox.weaving.hook] info adding AspectJ hooks ...
>
> [org.aspectj.osgi.service.weaving] info Starting AspectJ weaving service
>
>
> ...
>
>
> and nothing else...
>
>
>
> This is the config.ini I use
>
>
>
> osgi.bundles=org.eclipse.equinox.common@2
>
>
> :start,org.eclipse.update.configurator@3
>
> :start,org.eclipse.equinox.weaving.aspectj@4
>
> :start,org.eclipse.core.runtime@start
>
>
> osgi.framework.extensions=org.eclipse.equinox.weaving.hook
>
> aj.weaving.verbose=true
>
> org.aspectj.weaver.showWeaveInfo=true
>
> osgi.clean=true
>
> org.aspectj.osgi.verbose=true
>
> eclipse.product=org.plugination.clubadmin.ui.product
>
>
>
>
>
> Any help is appriciated I am kindof lost right now... I am using the
>
>
> 1.6.6
>
>
> version with eclipse 3.5
>
>
>
> _______________________________________________
>
> aspectj-dev mailing list
>
> aspectj-dev@...
>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> aspectj-dev mailing list
>
> aspectj-dev@...
>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Need Help in deploying RPPS-Web

2009-11-27T11:30:18Z

Hi All,

I need some help in deploying the RPPS-Web application. We see the following error after deploying the application:

ERROR [main] RppsService$4.initialValue (RppsService.java:336) - java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

I have attached a few files for further information including
- Stack Trace
- User.xml - This file has a reference to the class that Tomcat is not able to find
- context.xml

I will appreciate if anyone can provide any pointers in resolving the errors.

--
Regards,
Daljeet Singh

27 Nov 2009 14:16:49,479 ERROR [main] ConfigurationHandler.configure (ConfigurationHandler.java:439) - org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

27 Nov 2009 14:16:49,488 ERROR [main] RppsService$4.initialValue (RppsService.java:336) - java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at org.eclipse.higgins.configuration.common.ConfigurableComponentFactoryHelper.getClassByName(ConfigurableComponentFactoryHelper.java:160)
at org.eclipse.higgins.configuration.common.ConfigurableComponentFactoryHelper.getInstanceFromClassName(ConfigurableComponentFactoryHelper.java:36)
at org.eclipse.higgins.configuration.xml.ClassInstanceHandler.getSetting(ClassInstanceHandler.java:82)
at org.eclipse.higgins.configuration.xml.MapHandler.getSetting(MapHandler.java:108)
at org.eclipse.higgins.configuration.xml.ConfigurationHandler.configure(ConfigurationHandler.java:425)
at org.eclipse.higgins.configuration.xml.ConfigurationHandler.configure(ConfigurationHandler.java:291)
at org.eclipse.higgins.rpps.core.impl.RppsService$4.initialValue(RppsService.java:331)
at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:141)
at java.lang.ThreadLocal.get(ThreadLocal.java:131)
at org.eclipse.higgins.rpps.core.impl.RppsService.userIdentifierExists(RppsService.java:4477)
at org.eclipse.higgins.rpps.servlet.InitializeServlet.init(InitializeServlet.java:39)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
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:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
27 Nov 2009 14:16:49,492 ERROR [main] InitializeServlet.init (InitializeServlet.java:42) - java.lang.NullPointerException

java.lang.NullPointerException
at org.eclipse.higgins.rpps.core.impl.RppsService.userIdentifierExists(RppsService.java:4477)
at org.eclipse.higgins.rpps.servlet.InitializeServlet.init(InitializeServlet.java:39)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
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:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
27 Nov 2009 14:16:50,791 ERROR [main] WSDDService.deployTypeMapping (WSDDService.java:560) - Unable to deploy typemapping: {http://tobj.core.rpps.higgins.parityinc.net}FormTO

java.lang.ClassNotFoundException: net.parityinc.higgins.rpps.core.tobj.FormTO
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:160)
at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:100)
at org.apache.axis.deployment.wsdd.WSDDTypeMapping.getLanguageSpecificType(WSDDTypeMapping.java:183)
at org.apache.axis.deployment.wsdd.WSDDService.deployTypeMapping(WSDDService.java:542)
at org.apache.axis.deployment.wsdd.WSDDService.initTMR(WSDDService.java:253)
at org.apache.axis.deployment.wsdd.WSDDService.<init>(WSDDService.java:233)
at org.apache.axis.deployment.wsdd.WSDDDeployment.<init>(WSDDDeployment.java:192)
at org.apache.axis.deployment.wsdd.WSDDDocument.setDocument(WSDDDocument.java:139)
at org.apache.axis.deployment.wsdd.WSDDDocument.<init>(WSDDDocument.java:65)
at org.apache.axis.configuration.FileProvider.configureEngine(FileProvider.java:179)
at org.apache.axis.AxisEngine.init(AxisEngine.java:172)
at org.apache.axis.AxisEngine.<init>(AxisEngine.java:156)
at org.apache.axis.server.AxisServer.<init>(AxisServer.java:88)
at org.apache.axis.server.DefaultAxisServerFactory.createServer(DefaultAxisServerFactory.java:109)
at org.apache.axis.server.DefaultAxisServerFactory.getServer(DefaultAxisServerFactory.java:73)
at org.apache.axis.server.AxisServer.getServer(AxisServer.java:73)
at org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase.java:185)
at org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase.java:396)
at org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java:112)
at org.apache.axis.transport.http.AxisServlet.init(AxisServlet.java:156)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
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:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://higgins.eclipse.org/sts/Configuration" xmlns:htf="http://higgins.eclipse.org/sts/Configuration">
<SettingHandlers>
<SettingHandler Type="htf:map" Class="java.util.Map" Handler="org.eclipse.higgins.configuration.xml.MapHandler"/>
<SettingHandler Type="htf:list" Class="java.util.List" Handler="org.eclipse.higgins.configuration.xml.ListHandler"/>
<SettingHandler Type="xsd:string" Class="java.lang.String" Handler="org.eclipse.higgins.configuration.xml.StringHandler"/>
<SettingHandler Type="xsd:boolean" Class="java.lang.Boolean" Handler="org.eclipse.higgins.configuration.xml.BooleanHandler"/>
<SettingHandler Type="xsd:anyURI" Class="java.net.URI" Handler="org.eclipse.higgins.configuration.xml.URIHandler"/>
<SettingHandler Type="htf:file" Class="java.io.FileInputStream" Handler="org.eclipse.higgins.configuration.xml.FileHandler"/>
<SettingHandler Type="htf:singleton" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.SingletonHandler"/>
<SettingHandler Type="htf:instance" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.InstanceHandler"/>
<SettingHandler Type="htf:classinstance" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.ClassInstanceHandler"/>
<SettingHandler Type="htf:classsingleton" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.ClassSingletonHandler"/>
</SettingHandlers>
<Setting Name="UserProfile" Type="htf:map">
<Setting Name="ComponentSettings" Type="htf:map">

<Setting Name="IdentityAttributeService" Type="htf:map">
<Setting Name="ContextFactoryInstancesList" Type="htf:list">
<Setting Name="HibernateContextFactory" Type="htf:map">
<Setting Name="Instance" Type="xsd:string">HibernateContextFactory</Setting>
<Setting Name="ContextTypes" Type="htf:list">
<Setting Name="JenaContextType" Type="xsd:string">$context+hibernate</Setting>
</Setting>
</Setting>
</Setting>
<Setting Name="ContextIdsList" Type="htf:list">
<Setting Name="urn:userProfileContext" Type="htf:map">
<Setting Name="ContextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="ContextTypes" Type="htf:list">
<Setting Name="LDAPContextType" Type="xsd:string">$context+hibernate</Setting>
</Setting>
<Setting Name="ContextUris" Type="htf:list">
<Setting Name="DefaultContextUri" Type="xsd:anyURI">urn:Higgins-LDAP-Server</Setting>
</Setting>
<Setting Name="context.performauthentication" Type="xsd:string">false</Setting>
<Setting Name="context.uri" Type="xsd:anyURI">urn:userProfileContext/</Setting>
<Setting Name="schema.url" Type="xsd:anyURI">http://www.eclipse.org/higgins/ontologies/2008/7/userProfile</Setting>
<Setting Name="schema.file" Type="xsd:string">/org/eclipse/higgins/userprofile/idas/userProfile.owl</Setting>
<Setting Name="hibernateConfig" Type="htf:map">
<Setting Name="hibernate.dialect" Type="xsd:string">org.hibernate.dialect.MySQLDialect</Setting>
<Setting Name="hibernate.connection.driver_class" Type="xsd:string">com.mysql.jdbc.Driver</Setting>

<Setting Name="hibernate.connection.url" Type="xsd:string">jdbc:mysql://localhost/higgins_up_20090115?autoReconnect=true</Setting>
<Setting Name="hibernate.connection.username" Type="xsd:string">root</Setting>
<Setting Name="hibernate.connection.password" Type="xsd:string">higgins</Setting>



<Setting Name="hibernate.show_sql" Type="xsd:string">true</Setting>

<Setting Name="hibernate.default_entity_mode" Type="xsd:string">dom4j</Setting>
<Setting Name="hibernate.connection.autocommit" Type="xsd:string">false</Setting>
<Setting Name="hibernate.format_sql" Type="xsd:string">true</Setting>


<Setting Name="connection.pool_size" Type="xsd:string">5</Setting>

</Setting>
</Setting>
</Setting>
</Setting>

<Setting Name="UserAccountService" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>

<Setting Name="UserProfileService" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>

<Setting Name="UserLoginService" Type="htf:map">

<Setting Name="LoginModules" Type="htf:list">
<Setting Name="UserNamePasswordModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.UserNamePasswordModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
<Setting Name="IsapMd5PasswordModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.IsapMd5PasswordModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
<Setting Name="PrivateUserINumberModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.PrivateUserINumberModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
</Setting>
</Setting>
</Setting>
<Setting Name="HibernateContextFactory" Type="htf:classinstance">org.eclipse.higgins.idas.cp.hb.impl.ContextFactory</Setting>
<Setting Name="IdentityAttributeService" Type="htf:classsingleton">org.eclipse.higgins.idas.registry.IdASRegistry</Setting>
<Setting Name="UserLoginService" Type="htf:classinstance">org.eclipse.higgins.user.login.LoginService</Setting>
<Setting Name="UserAccountService" Type="htf:classinstance">org.eclipse.higgins.user.idas.account.AccountService</Setting>
<Setting Name="UserProfileService" Type="htf:classinstance">org.eclipse.higgins.user.idas.profile.ProfileService</Setting>
</Setting>
</Configuration>

<?xml version="1.0" encoding="UTF-8"?>

<Context path="/rpps-axis">


<Parameter name="CacheConfigurationBase" value="/usr/share/higgins/cache"/>
<Parameter name="CacheConfigurationFile" value="CacheConfiguration.xml" />


<Environment name="HigginsConfigurationBase" value="/usr/share/higgins" type="java.lang.String" override="false"/>
<Environment name="HigginsConfigurationFile" value="User.xml" type="java.lang.String" override="false"/>

<Environment name="AccessTokenMaxIdleTime" value="1800" type="java.lang.String" override="false" />
<Environment name="AccessTokenMaxLifeTime" value="86400" type="java.lang.String" override="false" />
<Environment name="AuthServiceEhcacheCnfUrl" value="/usr/share/higgins/cache/ehcache.xml" type="java.lang.String" override="false" />



<Resource name="rpps/cards" auth="Container" type="javax.sql.DataSource"
maxActive="150" maxIdle="30" maxWait="-1" removeAbandoned="true"
removeAbandonedTimeout="180" logAbandoned="true" username="higgins_rpps"
password="higginsRPPS" driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/higgins_TestCards?autoReconnect=true" />


<Resource name="rpps/up" global="rpps/up" auth="Container"
type="javax.sql.DataSource" username="higgins_rpps" password="higginsRPPS"
driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/higgins_up_rh156?autoReconnect=true&useUnicode=yes&characterEncoding=UTF-8"
removeAbandoned="true" removeAbandonedTimeout="180" logAbandoned="true"
maxActive="200" maxIdle="50" validationQuery="Select 1" />


<Resource name="cardsync/meta_hb" global="cardsync/meta_hb"
auth="Container" type="javax.sql.DataSource" username="higgins_cardsync"
password="password" driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/hcs_meta?autoReconnect=true&useUnicode=yes&characterEncoding=UTF-8"
maxActive="100" maxIdle="7" validationQuery="Select 1"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" />

















</Context>
_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

From forum: Higgins - Dev

Re: New intertype syntax ...new meaning?

2009-11-27T10:57:37Z

Currently, we just use a simple name filter for ajc$ proposals, but we
are using a more sophisticated approach to filter out ITDs on a type
that are not available in a particular context (eg- aspect-private
ITDs), and this could probably be applicable in the new situation as
well, but I'll have to think about it more.

On Fri, Nov 27, 2009 at 8:51 AM, Andy Clement <andrew.clement@...> wrote:

> I suspected AJDT may be removing them when it can, but on which of
> these does it base the decision to remove:
>
> - name
> - model
> - metadata
>
> if (1) it may need changing to (2) or (3) if I alter the naming
> scheme. But we knew there would be an impact on AJDT if this mangling
> change goes ahead.
>
> Andy
>
> 2009/11/26 Andrew Eisenberg <andrew@...>:
>> On Thu, Nov 26, 2009 at 9:54 PM, Andrew Eisenberg <andrew@...> wrote:
>>>> This does mean that today any java projects consuming the
>>>> type may well see ajc$blahblah as a horrid code completion suggestion
>>>> if working with instances of that type - so in some respects, changing
>>>> it to properly private is a good thing to do anyway...)
>>>
>>> Small point here... AJDT filters out all of these kinds of proposals,
>>> so you you should never see them.
>>>
>> Let me rephrase that slightly...it is possible to see them if you are
>> consuming an aspect from another project in a non-AJ project.
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re: Cannot get reference to the object

2009-11-27T10:53:56Z

target(ves) is failing because the Vessel object does not exist.
Since the pointcut runs *before* the call to new, there is no object
to bind.

However, changing call to execution should work (as long as you are
able to weave into the Vessel class's constructor).

On Fri, Nov 27, 2009 at 9:17 AM, ivlev jenia <jenia2009@...> wrote:

> pointcut instanceTracker(Vessel ves) :
> call(Vessel+.new(..))&&target(ves) ;
> before (Vessel ves) : instanceTracker(ves){// this is the place
> *************************
> System.out.println(thisJoinPoint);
> System.out.println(ves.getClass().getCanonicalName());
> }
>
> but at "this is the place" the
> compiler gives me warning : advice defined in cut has not been applied
> [Xlint:adviceDidNotMatch]
> What is the problem?????
>
> if i do :
>
>
> pointcut instanceTracker() :
> call(Vessel+.new(..)) ;
> before () : instanceTracker(){// this is the place
> *************************
> System.out.println(thisJoinPoint);
> // System.out.println(ves.getClass().getCanonicalName());
> }
>
>
> everything works
> anyone knows whats the problem?
>
> ________________________________
> Make your browsing faster, safer, and easier with the new Internet Explorer®
> 8. Optimized for Yahoo! Get it Now for Free!
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

RE: Informally Promoted Build for wtp-R3.2.0-I: I-3.2.0-20091127073002

2009-11-27T10:44:41Z

Happy Thanksgiving, US folks,

- Ian

_______________________________________________
wtp-dev mailing list
wtp-dev@...
https://dev.eclipse.org/mailman/listinfo/wtp-dev

From forum: Eclipse WTP - general