You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Sahoo <Sa...@Sun.COM> on 2010/03/21 02:18:09 UTC
trunk/webconsole fails to build
Hi,
After updating my workspace to svn rev#925708, I am doing a clean build
and I see compilation failures like this:
/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
cannot find symbol
[exec] symbol: class R4Package
/
I don't see any R4Package.class in bundlerepository-1.5.0-SNAPSHOT.jar,
that's recently built.
Is there a continuous integration job running for trunk? Can I see its log?
Thanks,
Sahoo
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 23.03.2010 11:59, Craig Phillips wrote:
> mvn == disaster
This sentence probably does not bring us anywhere here ....
>
> It's time to think outside the box;
>
> Let me introduce "source bundles"...
>
> I have enormous philosophy behind this, but I won't go there; I'll only
> "share" a demonstration and the eclipse workspace thereof;
Oh, btw: eclipse == disaster (just kidding, I am also using Eclipse)
>
> I "invented" source bundles... Simply put, it's a bundle without
> dot.class files... Instead, you put in dot.java files (and, the
> mechanics can be extended to any language, including scripted languages)...
>
> I took all the felix framework bundles, minus the "system bundle", off
> the trunk (and old trunk from last October -- it's only a demo, chill),
> and converted them to source bundles, outfitted the system bundle with a
> "builder" (takes a source bundle, looks at the manifest, and compiles
> the dot.java files and rezips the resultant "executable bundle");
>
> Unfortunately, due to mods to the system bundle and other various "spec"
> mods, I never gained traction; My true recourse is to simply ignore the
> detractors and move ahead with a standalone "builder", but that's
> politics and I won't go there either;
>
> The demo only works on windoze at the moment due to an issue with
> locating the "felix.jar" for compilation purposes (I have a hack for the
> mac, but ultimately I need a registration configuration entry)...
>
> Anyways, without further ado...
>
> demonstration: http://www.box.net/shared/4jssc5r69c
>
> eclipse workspace: http://www.box.net/shared/914tdoxcfp
>
> This has pretty much been put to bed since last November (I've been busy
> with real work... at least the kind that pays bills); It was a few
> nights and weekends...
>
> Cheers, Craig Phillips, Praxis Engineering
>
> PS - If you want to take this off line, I'd be happy... My intent was to
> give it to the community and let the community run with it; Although,
> due to politics, I never made an "introduction", but maybe it's time...
> Enough is enough; I never need mvn for anything; I have a src-bnd and I
> let the framework do the "build";
So this very much sounds like it could evolve into an URL handler, where
the URL might be something like src://.... and your builder gets the
package compiles and packages it and provides the InputStream to the result.
I am not even sure, this needs framework hacking: What you probable need:
* Implement an URL Handler to handle the special source bundles
being installed using special URLs
* Use the PackageAdmin service to find packages and classes installed
in the framework
* Use OBR to find packages not installed in the framework in a
remote repository (you probably don't want to install these
dependencies unless you build a build-machine)
Sounds like an intereting idea, but: Does this support automated builds
and publications ? How about end users ?
As for Apache: having source-only bundles is not a problem, because
(officially) the ASF only distributes sources [binaries are considered
convenience].
Regards
Felix
>
>
>
> From: Sahoo
> Sent: Tue 3/23/2010 5:20 AM
> To: dev@felix.apache.org
> Subject: Re: trunk/webconsole fails to build
>
>
> Obviously, I am not tracking all the conversation on this topic. I
> noticed there was a SNAPSHOT dependency introduced from webconsole to
> obr and that required me to do a build that includes at least those two
> modules. Since I did not carefully see what other modules have SNAPSHOT
> dependency among themselves, I decided to do a full build. You seem to
> be saying that you have fixed the SNAPSHOT dependency issue in
> webconsole, so that's great. Let me update webconsole to explore its
> dependency on obr bundle before unnecessarily taking your and other's time.
>
> About build failure, it will be definitely good if CI server sends build
> failure message to dev@ alerting people.
>
> Thanks,
> Sahoo
>
> Felix Meschberger wrote:
>> Hi,
>>
>> To build just the web console, you can update your webconsole folder and
>> just run the build in there. This should do the trick.
>>
>> [running the full Felix trunk build just to get the web console sounds
>> like massive overkill to me]
>>
>> On 23.03.2010 01:37, Sahoo wrote:
>>
>>> Can I update my top level Felix workspace and get the build to complete?
>>> Some tests seemed to fail for me last time, so I am little unsure at
>>>
>>
>> If you do a full build, the build will abort once a sub-project (module)
>> fails to build. This is probably another intereting point to know which
>> project actually failed to build.
>>
>> Regard
>> Felix
>>
>>
>>> this point. I want to build a web console with OBR plugin.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> I have fixed a number of issues around the bundle repository support
>>>> today. Thus the web console should build again.
>>>>
>>>> Thanks for reporting.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 21.03.2010 04:27, Sahoo wrote:
>>>>
>>>>
>>>>> This failure is introduced in rev #925279.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Sahoo wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>>> build and I see compilation failures like this:
>>>>>>
>>>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>>
>>>>>>
>>>>>> cannot find symbol
>>>>>> [exec] symbol: class R4Package
>>>>>> /
>>>>>> I don't see any R4Package.class in
>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>>
>>>>>> Is there a continuous integration job running for trunk? Can I see
>>>>>> its
>>>>>> log?
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>>
>
Re: trunk/webconsole fails to build
Posted by Guillaume Nodet <gn...@gmail.com>.
There's a huge problem imho in your view. Runtime dependencies are usually
not the same as build time dependencies. What if you need code generation
? What if you have a class that use some optional dependencies that you
don't want to include ? What if you need native code ?
You can only end up with a small subset of what will be needed in the real
world.
And in addition, that would not really help here, as the problem is really
that one bundle has been changed in an incompatible way, so not sure what
your tooling layer would bring here.
On Tue, Mar 23, 2010 at 11:59, Craig Phillips <lc...@praxiseng.com>wrote:
> mvn == disaster
>
> It's time to think outside the box;
>
> Let me introduce "source bundles"...
>
> I have enormous philosophy behind this, but I won't go there; I'll only
> "share" a demonstration and the eclipse workspace thereof;
>
> I "invented" source bundles... Simply put, it's a bundle without dot.class
> files... Instead, you put in dot.java files (and, the mechanics can be
> extended to any language, including scripted languages)...
>
> I took all the felix framework bundles, minus the "system bundle", off the
> trunk (and old trunk from last October -- it's only a demo, chill), and
> converted them to source bundles, outfitted the system bundle with a
> "builder" (takes a source bundle, looks at the manifest, and compiles the
> dot.java files and rezips the resultant "executable bundle");
>
> Unfortunately, due to mods to the system bundle and other various "spec"
> mods, I never gained traction; My true recourse is to simply ignore the
> detractors and move ahead with a standalone "builder", but that's politics
> and I won't go there either;
>
> The demo only works on windoze at the moment due to an issue with locating
> the "felix.jar" for compilation purposes (I have a hack for the mac, but
> ultimately I need a registration configuration entry)...
>
> Anyways, without further ado...
>
> demonstration: http://www.box.net/shared/4jssc5r69c
>
> eclipse workspace: http://www.box.net/shared/914tdoxcfp
>
> This has pretty much been put to bed since last November (I've been busy
> with real work... at least the kind that pays bills); It was a few nights
> and weekends...
>
> Cheers, Craig Phillips, Praxis Engineering
>
> PS - If you want to take this off line, I'd be happy... My intent was to
> give it to the community and let the community run with it; Although, due to
> politics, I never made an "introduction", but maybe it's time... Enough is
> enough; I never need mvn for anything; I have a src-bnd and I let the
> framework do the "build";
>
>
>
> From: Sahoo
> Sent: Tue 3/23/2010 5:20 AM
> To: dev@felix.apache.org
> Subject: Re: trunk/webconsole fails to build
>
>
>
> Obviously, I am not tracking all the conversation on this topic. I noticed
> there was a SNAPSHOT dependency introduced from webconsole to obr and that
> required me to do a build that includes at least those two modules. Since I
> did not carefully see what other modules have SNAPSHOT dependency among
> themselves, I decided to do a full build. You seem to be saying that you
> have fixed the SNAPSHOT dependency issue in webconsole, so that's great. Let
> me update webconsole to explore its dependency on obr bundle before
> unnecessarily taking your and other's time.
>
> About build failure, it will be definitely good if CI server sends build
> failure message to dev@ alerting people.
>
> Thanks,
> Sahoo
>
> Felix Meschberger wrote:
>
>> Hi,
>>
>> To build just the web console, you can update your webconsole folder and
>> just run the build in there. This should do the trick.
>>
>> [running the full Felix trunk build just to get the web console sounds
>> like massive overkill to me]
>>
>> On 23.03.2010 01:37, Sahoo wrote:
>>
>>
>>> Can I update my top level Felix workspace and get the build to complete?
>>> Some tests seemed to fail for me last time, so I am little unsure at
>>>
>>>
>>
>> If you do a full build, the build will abort once a sub-project (module)
>> fails to build. This is probably another intereting point to know which
>> project actually failed to build.
>>
>> Regards
>> Felix
>>
>>
>>
>>> this point. I want to build a web console with OBR plugin.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Felix Meschberger wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have fixed a number of issues around the bundle repository support
>>>> today. Thus the web console should build again.
>>>>
>>>> Thanks for reporting.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 21.03.2010 04:27, Sahoo wrote:
>>>>
>>>>
>>>>> This failure is introduced in rev #925279.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Sahoo wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>>> build and I see compilation failures like this:
>>>>>>
>>>>>>
>>>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>>
>>>>>> cannot find symbol
>>>>>> [exec] symbol: class R4Package
>>>>>> /
>>>>>> I don't see any R4Package.class in
>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>>
>>>>>> Is there a continuous integration job running for trunk? Can I see its
>>>>>> log?
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>>
>>>>>>
>>>>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: trunk/webconsole fails to build
Posted by Craig Phillips <lc...@praxiseng.com>.
mvn == disaster
It's time to think outside the box;
Let me introduce "source bundles"...
I have enormous philosophy behind this, but I won't go there; I'll only "share" a demonstration and the eclipse workspace thereof;
I "invented" source bundles... Simply put, it's a bundle without dot.class files... Instead, you put in dot.java files (and, the mechanics can be extended to any language, including scripted languages)...
I took all the felix framework bundles, minus the "system bundle", off the trunk (and old trunk from last October -- it's only a demo, chill), and converted them to source bundles, outfitted the system bundle with a "builder" (takes a source bundle, looks at the manifest, and compiles the dot.java files and rezips the resultant "executable bundle");
Unfortunately, due to mods to the system bundle and other various "spec" mods, I never gained traction; My true recourse is to simply ignore the detractors and move ahead with a standalone "builder", but that's politics and I won't go there either;
The demo only works on windoze at the moment due to an issue with locating the "felix.jar" for compilation purposes (I have a hack for the mac, but ultimately I need a registration configuration entry)...
Anyways, without further ado...
demonstration: http://www.box.net/shared/4jssc5r69c
eclipse workspace: http://www.box.net/shared/914tdoxcfp
This has pretty much been put to bed since last November (I've been busy with real work... at least the kind that pays bills); It was a few nights and weekends...
Cheers, Craig Phillips, Praxis Engineering
PS - If you want to take this off line, I'd be happy... My intent was to give it to the community and let the community run with it; Although, due to politics, I never made an "introduction", but maybe it's time... Enough is enough; I never need mvn for anything; I have a src-bnd and I let the framework do the "build";
From: Sahoo
Sent: Tue 3/23/2010 5:20 AM
To: dev@felix.apache.org
Subject: Re: trunk/webconsole fails to build
Obviously, I am not tracking all the conversation on this topic. I
noticed there was a SNAPSHOT dependency introduced from webconsole to
obr and that required me to do a build that includes at least those two
modules. Since I did not carefully see what other modules have SNAPSHOT
dependency among themselves, I decided to do a full build. You seem to
be saying that you have fixed the SNAPSHOT dependency issue in
webconsole, so that's great. Let me update webconsole to explore its
dependency on obr bundle before unnecessarily taking your and other's time.
About build failure, it will be definitely good if CI server sends build
failure message to dev@ alerting people.
Thanks,
Sahoo
Felix Meschberger wrote:
> Hi,
>
> To build just the web console, you can update your webconsole folder and
> just run the build in there. This should do the trick.
>
> [running the full Felix trunk build just to get the web console sounds
> like massive overkill to me]
>
> On 23.03.2010 01:37, Sahoo wrote:
>
>> Can I update my top level Felix workspace and get the build to complete?
>> Some tests seemed to fail for me last time, so I am little unsure at
>>
>
> If you do a full build, the build will abort once a sub-project (module)
> fails to build. This is probably another intereting point to know which
> project actually failed to build.
>
> Regards
> Felix
>
>
>> this point. I want to build a web console with OBR plugin.
>>
>> Thanks,
>> Sahoo
>>
>> Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> I have fixed a number of issues around the bundle repository support
>>> today. Thus the web console should build again.
>>>
>>> Thanks for reporting.
>>>
>>> Regards
>>> Felix
>>>
>>> On 21.03.2010 04:27, Sahoo wrote:
>>>
>>>
>>>> This failure is introduced in rev #925279.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Sahoo wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>> build and I see compilation failures like this:
>>>>>
>>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>
>>>>> cannot find symbol
>>>>> [exec] symbol: class R4Package
>>>>> /
>>>>> I don't see any R4Package.class in
>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>
>>>>> Is there a continuous integration job running for trunk? Can I see its
>>>>> log?
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>>
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 23.03.2010 10:20, Sahoo wrote:
> Obviously, I am not tracking all the conversation on this topic. I
> noticed there was a SNAPSHOT dependency introduced from webconsole to
> obr and that required me to do a build that includes at least those two
> modules. Since I did not carefully see what other modules have SNAPSHOT
> dependency among themselves, I decided to do a full build. You seem to
> be saying that you have fixed the SNAPSHOT dependency issue in
> webconsole, so that's great. Let me update webconsole to explore its
> dependency on obr bundle before unnecessarily taking your and other's time.
Hmm, you are scratching an interesting and important surface here: We
(bundle developers) should probably be more careful to (a) ensure our
SNAPSHOT dependencies are actually deployed to some SNAPSHOT repository
and (b) ensure we deploy our own SNAPSHOTs more regularly ...
>
> About build failure, it will be definitely good if CI server sends build
> failure message to dev@ alerting people.
It actually sends such failures to the commits list .... Maybe the
failures should go to the dev list while the successes may just as well
not be sent out alltogether.
I agree with Sahoo, that we should retarget the build failure messages.
Regards
Felix
>
> Thanks,
> Sahoo
>
> Felix Meschberger wrote:
>> Hi,
>>
>> To build just the web console, you can update your webconsole folder and
>> just run the build in there. This should do the trick.
>>
>> [running the full Felix trunk build just to get the web console sounds
>> like massive overkill to me]
>>
>> On 23.03.2010 01:37, Sahoo wrote:
>>
>>> Can I update my top level Felix workspace and get the build to complete?
>>> Some tests seemed to fail for me last time, so I am little unsure at
>>>
>>
>> If you do a full build, the build will abort once a sub-project (module)
>> fails to build. This is probably another intereting point to know which
>> project actually failed to build.
>>
>> Regards
>> Felix
>>
>>
>>> this point. I want to build a web console with OBR plugin.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> I have fixed a number of issues around the bundle repository support
>>>> today. Thus the web console should build again.
>>>>
>>>> Thanks for reporting.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 21.03.2010 04:27, Sahoo wrote:
>>>>
>>>>
>>>>> This failure is introduced in rev #925279.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Sahoo wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>>> build and I see compilation failures like this:
>>>>>>
>>>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>>
>>>>>>
>>>>>> cannot find symbol
>>>>>> [exec] symbol: class R4Package
>>>>>> /
>>>>>> I don't see any R4Package.class in
>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>>
>>>>>> Is there a continuous integration job running for trunk? Can I see
>>>>>> its
>>>>>> log?
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>>
>
Re: trunk/webconsole fails to build
Posted by Sahoo <sa...@sun.com>.
Obviously, I am not tracking all the conversation on this topic. I
noticed there was a SNAPSHOT dependency introduced from webconsole to
obr and that required me to do a build that includes at least those two
modules. Since I did not carefully see what other modules have SNAPSHOT
dependency among themselves, I decided to do a full build. You seem to
be saying that you have fixed the SNAPSHOT dependency issue in
webconsole, so that's great. Let me update webconsole to explore its
dependency on obr bundle before unnecessarily taking your and other's time.
About build failure, it will be definitely good if CI server sends build
failure message to dev@ alerting people.
Thanks,
Sahoo
Felix Meschberger wrote:
> Hi,
>
> To build just the web console, you can update your webconsole folder and
> just run the build in there. This should do the trick.
>
> [running the full Felix trunk build just to get the web console sounds
> like massive overkill to me]
>
> On 23.03.2010 01:37, Sahoo wrote:
>
>> Can I update my top level Felix workspace and get the build to complete?
>> Some tests seemed to fail for me last time, so I am little unsure at
>>
>
> If you do a full build, the build will abort once a sub-project (module)
> fails to build. This is probably another intereting point to know which
> project actually failed to build.
>
> Regards
> Felix
>
>
>> this point. I want to build a web console with OBR plugin.
>>
>> Thanks,
>> Sahoo
>>
>> Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> I have fixed a number of issues around the bundle repository support
>>> today. Thus the web console should build again.
>>>
>>> Thanks for reporting.
>>>
>>> Regards
>>> Felix
>>>
>>> On 21.03.2010 04:27, Sahoo wrote:
>>>
>>>
>>>> This failure is introduced in rev #925279.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Sahoo wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>> build and I see compilation failures like this:
>>>>>
>>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>
>>>>> cannot find symbol
>>>>> [exec] symbol: class R4Package
>>>>> /
>>>>> I don't see any R4Package.class in
>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>
>>>>> Is there a continuous integration job running for trunk? Can I see its
>>>>> log?
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>>
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 23.03.2010 16:01, Justin Edelson wrote:
> On Mar 23, 2010, at 7:36 AM, Felix Meschberger <fm...@gmail.com>
> wrote:
>
>> Hi,
>>
>> On 23.03.2010 14:56, Justin Edelson wrote:
>>> On Tue, Mar 23, 2010 at 4:12 AM, Felix Meschberger <fmeschbe@gmail.com
>>>> wrote:
>>>
>>>> If you do a full build, the build will abort once a sub-project
>>>> (module)
>>>> fails to build. This is probably another intereting point to know
>>>> which
>>>> project actually failed to build.
>>>>
>>> FWIW, Maven supports a command-line option which prevents a module
>>> build
>>> failure from stopping the build. Simply pass -fae to the mvn
>>> command, i.e.
>>> $ mvn -fae clean install
>>
>> Cool.
>>
>> What is the overall build status then ? Will Maven continue to build
>> and
>> still say "BUILD FAILED" at the end ?
>>
>
> Yes. fae stats for Fail At End.
>
> Obviously, a module build failure may cause another module's build to
> fail. So it's not magic, just occasionally useful :)
Thanks. Good to know.
Regards
Felix
>
> Justin
>
>> Regards
>> Felix
>>
>>>
>>> HTH,
>>> Justin
>>>
>
Re: trunk/webconsole fails to build
Posted by Justin Edelson <ju...@gmail.com>.
On Mar 23, 2010, at 7:36 AM, Felix Meschberger <fm...@gmail.com>
wrote:
> Hi,
>
> On 23.03.2010 14:56, Justin Edelson wrote:
>> On Tue, Mar 23, 2010 at 4:12 AM, Felix Meschberger <fmeschbe@gmail.com
>> >wrote:
>>
>>> If you do a full build, the build will abort once a sub-project
>>> (module)
>>> fails to build. This is probably another intereting point to know
>>> which
>>> project actually failed to build.
>>>
>> FWIW, Maven supports a command-line option which prevents a module
>> build
>> failure from stopping the build. Simply pass -fae to the mvn
>> command, i.e.
>> $ mvn -fae clean install
>
> Cool.
>
> What is the overall build status then ? Will Maven continue to build
> and
> still say "BUILD FAILED" at the end ?
>
Yes. fae stats for Fail At End.
Obviously, a module build failure may cause another module's build to
fail. So it's not magic, just occasionally useful :)
Justin
> Regards
> Felix
>
>>
>> HTH,
>> Justin
>>
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 23.03.2010 14:56, Justin Edelson wrote:
> On Tue, Mar 23, 2010 at 4:12 AM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> If you do a full build, the build will abort once a sub-project (module)
>> fails to build. This is probably another intereting point to know which
>> project actually failed to build.
>>
> FWIW, Maven supports a command-line option which prevents a module build
> failure from stopping the build. Simply pass -fae to the mvn command, i.e.
> $ mvn -fae clean install
Cool.
What is the overall build status then ? Will Maven continue to build and
still say "BUILD FAILED" at the end ?
Regards
Felix
>
> HTH,
> Justin
>
Re: trunk/webconsole fails to build
Posted by Justin Edelson <ju...@gmail.com>.
On Tue, Mar 23, 2010 at 4:12 AM, Felix Meschberger <fm...@gmail.com>wrote:
> If you do a full build, the build will abort once a sub-project (module)
> fails to build. This is probably another intereting point to know which
> project actually failed to build.
>
FWIW, Maven supports a command-line option which prevents a module build
failure from stopping the build. Simply pass -fae to the mvn command, i.e.
$ mvn -fae clean install
HTH,
Justin
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
To build just the web console, you can update your webconsole folder and
just run the build in there. This should do the trick.
[running the full Felix trunk build just to get the web console sounds
like massive overkill to me]
On 23.03.2010 01:37, Sahoo wrote:
> Can I update my top level Felix workspace and get the build to complete?
> Some tests seemed to fail for me last time, so I am little unsure at
If you do a full build, the build will abort once a sub-project (module)
fails to build. This is probably another intereting point to know which
project actually failed to build.
Regards
Felix
> this point. I want to build a web console with OBR plugin.
>
> Thanks,
> Sahoo
>
> Felix Meschberger wrote:
>> Hi,
>>
>> I have fixed a number of issues around the bundle repository support
>> today. Thus the web console should build again.
>>
>> Thanks for reporting.
>>
>> Regards
>> Felix
>>
>> On 21.03.2010 04:27, Sahoo wrote:
>>
>>> This failure is introduced in rev #925279.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Sahoo wrote:
>>>
>>>> Hi,
>>>>
>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>> build and I see compilation failures like this:
>>>>
>>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>
>>>> cannot find symbol
>>>> [exec] symbol: class R4Package
>>>> /
>>>> I don't see any R4Package.class in
>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>
>>>> Is there a continuous integration job running for trunk? Can I see its
>>>> log?
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>
Re: trunk/webconsole fails to build
Posted by Sahoo <sa...@sun.com>.
Can I update my top level Felix workspace and get the build to complete?
Some tests seemed to fail for me last time, so I am little unsure at
this point. I want to build a web console with OBR plugin.
Thanks,
Sahoo
Felix Meschberger wrote:
> Hi,
>
> I have fixed a number of issues around the bundle repository support
> today. Thus the web console should build again.
>
> Thanks for reporting.
>
> Regards
> Felix
>
> On 21.03.2010 04:27, Sahoo wrote:
>
>> This failure is introduced in rev #925279.
>>
>> Thanks,
>> Sahoo
>>
>> Sahoo wrote:
>>
>>> Hi,
>>>
>>> After updating my workspace to svn rev#925708, I am doing a clean
>>> build and I see compilation failures like this:
>>>
>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>> cannot find symbol
>>> [exec] symbol: class R4Package
>>> /
>>> I don't see any R4Package.class in
>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>
>>> Is there a continuous integration job running for trunk? Can I see its
>>> log?
>>>
>>> Thanks,
>>> Sahoo
>>>
Re: trunk/webconsole fails to build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I have fixed a number of issues around the bundle repository support
today. Thus the web console should build again.
Thanks for reporting.
Regards
Felix
On 21.03.2010 04:27, Sahoo wrote:
> This failure is introduced in rev #925279.
>
> Thanks,
> Sahoo
>
> Sahoo wrote:
>> Hi,
>>
>> After updating my workspace to svn rev#925708, I am doing a clean
>> build and I see compilation failures like this:
>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>> cannot find symbol
>> [exec] symbol: class R4Package
>> /
>> I don't see any R4Package.class in
>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>
>> Is there a continuous integration job running for trunk? Can I see its
>> log?
>>
>> Thanks,
>> Sahoo
>
Re: trunk/webconsole fails to build
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
this was not detected by Bamboo, as there is another issue before (sounds like not a new issue). Bamboo cannot compile the new OBR.
Regards,
Clement
Missing:
----------
1) org.codehaus.woodstox:stax2-api:jar:3.0.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.codehaus.woodstox -DartifactId=stax2-api -Dversion=3.0.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.codehaus.woodstox -DartifactId=stax2-api -Dversion=3.0.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.felix:org.apache.felix.bundlerepository:bundle:1.5.0-SNAPSHOT
2) org.codehaus.woodstox:woodstox-core-asl:jar:4.0.7
3) org.codehaus.woodstox:stax2-api:jar:3.0.1
----------
1 required artifact is missing.
for artifact:
org.apache.felix:org.apache.felix.bundlerepository:bundle:1.5.0-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
central (https://m2proxy.atlassian.com/repository/public)
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
On 21.03.2010, at 04:27, Sahoo wrote:
> This failure is introduced in rev #925279.
>
> Thanks,
> Sahoo
>
> Sahoo wrote:
>> Hi,
>>
>> After updating my workspace to svn rev#925708, I am doing a clean build and I see compilation failures like this:
>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54] cannot find symbol
>> [exec] symbol: class R4Package
>> /
>> I don't see any R4Package.class in bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>
>> Is there a continuous integration job running for trunk? Can I see its log?
>>
>> Thanks,
>> Sahoo
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Oops, it looks like the second problem has already been taken care of.
Sorry for the confusion.
Remains the first problem: moving the OBR stuff over to the
bundlerepository bundle.
Alternatively, the bundle could differentiate between the old API and
the newly provided API and provide more options in the latter case.
Regards
Felix
On 22.03.2010 09:08, Felix Meschberger wrote:
> Hi,
>
> The bundlerepository bundle has been disbanded into the core
> bundlerepository stuff and the Manifest parsing stuff moved to the new
> commons library/project.
>
> This creates some grieve for downstream users like Web Console but also
> other users of the bundlrepository.
>
> As for the Web Console, I think we should move the OBR support plugin
> out of the Web Console over to the bundlerepository plugin. This solves
> the more general problem of the current bundlerepository refactoring for
> the web console (and only for the web console).
>
> The more general problem is that of removing existing API: The old
> org.osgi.service.obr API has been replaced in the bundle repository
> trunk by the new o.a.felix.bundlerepository API. There may be very good
> reasons to do this. But it leeaves current users of the o.o.s.obr API
> out in the dark.
>
> WDYT of moving the obr bundle ? In the short term this looks to my like
> the only feasible solution to be able to cut a Web Console release soon.
>
> What do we do about the now missing API ? To we provide backwards
> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
> service) ? Do we simply abandon the old API and raise the bundle
> repository bundle to a new major version number ?
>
> Regards
> Felix
>
> On 21.03.2010 04:27, Sahoo wrote:
>> This failure is introduced in rev #925279.
>>
>> Thanks,
>> Sahoo
>>
>> Sahoo wrote:
>>> Hi,
>>>
>>> After updating my workspace to svn rev#925708, I am doing a clean
>>> build and I see compilation failures like this:
>>>
>>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>> cannot find symbol
>>> [exec] symbol: class R4Package
>>> /
>>> I don't see any R4Package.class in
>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>
>>> Is there a continuous integration job running for trunk? Can I see its
>>> log?
>>>
>>> Thanks,
>>> Sahoo
>>
Updated proposed release list (was: OBR Web Console Plugin)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi
On 22.03.2010 13:28, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 12:23, Felix Meschberger <fm...@gmail.com> wrote:
>> If you feel comfortable with the state of the bundlerepository and utils
>> projects, I could include them in my webconsole 3.0 release batch.
>>
>> WDYT ?
>>
>
> Sounds good to me.
Good. So I will shoot for the following releases then:
Web Console 3.0.0
Event Plugin 1.0.2 (adapted for JQuery UI)
Memory Usage Plugin 1.0.0 (new plugin)
UPNP Plugin 1.0.0 (new plugin)
Bundle Repository 1.6.0 (required by Web Console, new API)
Utils 1.0.0 (required by Web Console)
Regards
Felix
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 12:23, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 11:23, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> On 22.03.2010 10:17, Guillaume Nodet wrote:
> >>> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com>
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On 22.03.2010 09:35, Guillaume Nodet wrote:
> >>>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fmeschbe@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> The bundlerepository bundle has been disbanded into the core
> >>>>>> bundlerepository stuff and the Manifest parsing stuff moved to the
> new
> >>>>>> commons library/project.
> >>>>>>
> >>>>>> This creates some grieve for downstream users like Web Console but
> >> also
> >>>>>> other users of the bundlrepository.
> >>>>>>
> >>>>>
> >>>>> How so ? The bundlerepository bundle is supposed to embed those
> >>>>> dependencies, it should not affect the users at all. Or is that
> >> because
> >>>> the
> >>>>> web console was depending on those internal classes that have been
> >>>>> refactored ?
> >>>>
> >>>> Actually, I missed the point that old API is still supported ...
> Sorry.
> >>>>
> >>>> So, no problems.
> >>>>
> >>>> Still, the plugin should of course be able to cope with the situation
> >>>> where only the old API is available.
> >>>>
> >>>
> >>> Yeah, that'd be nice. It might require a bit more work and some
> features
> >>> might be disabled. For example, computing the dependencies would not
> be
> >> a
> >>> good idea i think because it might take a very long time.
> >>
> >> What dependencies to compute ? Do you mean the optional
> >> dependencies/requirements ?
> >>
> >
> > Yes. I think wit the previous version of the resolver, it would to
> > unnacceptable computation time for the web pages (if you have a repo of a
> > decent size), especially as you have no way to not compute optional
> > dependencies and those are wrongly marked as mandatory anyway. The new
> one
> > being 10 time faster leads to better results.
> >
> >
> >>
> >>>
> >>> What if we resurrect the old version of the plugin and use it if the
> new
> >> api
> >>> is not available ?
> >>> I.e. we would have both plugins and use the new one if possible or the
> >> old
> >>> one if not.
> >>
> >> I am trying to implement this right now.
> >>
> >> Nevertheless this would leave us with the SNAPSHOT dependency to the new
> >> API, which prevents the Web Console from being released at this time.
> >>
> >> How about just supporting the old API for now and for a next release
> >> provide a second plugin implementation supporting the new functionality
> >> of the new API ?
> >>
> >>
> > Yeah, or we would release bundlerepository now. That would be a good
> idea
> > anyway I think.
>
> Plus the new utils ?
>
Yes
>
> BTW: I am able to implement support for both the old OSGi API and the
> new Felix API ... So we would be in good shape in this respect.
>
> If you feel comfortable with the state of the bundlerepository and utils
> projects, I could include them in my webconsole 3.0 release batch.
>
> WDYT ?
>
Sounds good to me.
>
> Regards
> Felix
>
> >
> >
> >> Regards
> >> Felix
> >>>
> >>>
> >>>>
> >>>> Regards
> >>>> Felix
> >>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> As for the Web Console, I think we should move the OBR support
> plugin
> >>>>>> out of the Web Console over to the bundlerepository plugin. This
> >> solves
> >>>>>> the more general problem of the current bundlerepository refactoring
> >> for
> >>>>>> the web console (and only for the web console).
> >>>>>>
> >>>>>> The more general problem is that of removing existing API: The old
> >>>>>> org.osgi.service.obr API has been replaced in the bundle repository
> >>>>>> trunk by the new o.a.felix.bundlerepository API. There may be very
> >> good
> >>>>>> reasons to do this. But it leeaves current users of the o.o.s.obr
> API
> >>>>>> out in the dark.
> >>>>>>
> >>>>>
> >>>>> Not really. The bundlerepository has a "compatibility layer" that is
> >>>>> installed if the o.o.os.obr API is installed. Currently is not
> bundled
> >>>>> anymore, but if we change that, it should be almost transparent for
> >>>> users.
> >>>>>
> >>>>>>
> >>>>>> WDYT of moving the obr bundle ? In the short term this looks to my
> >> like
> >>>>>> the only feasible solution to be able to cut a Web Console release
> >> soon.
> >>>>>>
> >>>>>> What do we do about the now missing API ? To we provide backwards
> >>>>>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
> >>>>>> service) ? Do we simply abandon the old API and raise the bundle
> >>>>>> repository bundle to a new major version number ?
> >>>>>>
> >>>>>
> >>>>> Currently we have the wrappers already. if you installed the old obr
> >> api
> >>>>> first, the service should be registered.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Regards
> >>>>>> Felix
> >>>>>>
> >>>>>> On 21.03.2010 04:27, Sahoo wrote:
> >>>>>>> This failure is introduced in rev #925279.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Sahoo
> >>>>>>>
> >>>>>>> Sahoo wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
> >>>>>>>> build and I see compilation failures like this:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
> >>>>>>>> cannot find symbol
> >>>>>>>> [exec] symbol: class R4Package
> >>>>>>>> /
> >>>>>>>> I don't see any R4Package.class in
> >>>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
> >>>>>>>>
> >>>>>>>> Is there a continuous integration job running for trunk? Can I see
> >> its
> >>>>>>>> log?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Sahoo
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 11:23, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> On 22.03.2010 10:17, Guillaume Nodet wrote:
>>> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 22.03.2010 09:35, Guillaume Nodet wrote:
>>>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The bundlerepository bundle has been disbanded into the core
>>>>>> bundlerepository stuff and the Manifest parsing stuff moved to the new
>>>>>> commons library/project.
>>>>>>
>>>>>> This creates some grieve for downstream users like Web Console but
>> also
>>>>>> other users of the bundlrepository.
>>>>>>
>>>>>
>>>>> How so ? The bundlerepository bundle is supposed to embed those
>>>>> dependencies, it should not affect the users at all. Or is that
>> because
>>>> the
>>>>> web console was depending on those internal classes that have been
>>>>> refactored ?
>>>>
>>>> Actually, I missed the point that old API is still supported ... Sorry.
>>>>
>>>> So, no problems.
>>>>
>>>> Still, the plugin should of course be able to cope with the situation
>>>> where only the old API is available.
>>>>
>>>
>>> Yeah, that'd be nice. It might require a bit more work and some features
>>> might be disabled. For example, computing the dependencies would not be
>> a
>>> good idea i think because it might take a very long time.
>>
>> What dependencies to compute ? Do you mean the optional
>> dependencies/requirements ?
>>
>
> Yes. I think wit the previous version of the resolver, it would to
> unnacceptable computation time for the web pages (if you have a repo of a
> decent size), especially as you have no way to not compute optional
> dependencies and those are wrongly marked as mandatory anyway. The new one
> being 10 time faster leads to better results.
>
>
>>
>>>
>>> What if we resurrect the old version of the plugin and use it if the new
>> api
>>> is not available ?
>>> I.e. we would have both plugins and use the new one if possible or the
>> old
>>> one if not.
>>
>> I am trying to implement this right now.
>>
>> Nevertheless this would leave us with the SNAPSHOT dependency to the new
>> API, which prevents the Web Console from being released at this time.
>>
>> How about just supporting the old API for now and for a next release
>> provide a second plugin implementation supporting the new functionality
>> of the new API ?
>>
>>
> Yeah, or we would release bundlerepository now. That would be a good idea
> anyway I think.
Plus the new utils ?
BTW: I am able to implement support for both the old OSGi API and the
new Felix API ... So we would be in good shape in this respect.
If you feel comfortable with the state of the bundlerepository and utils
projects, I could include them in my webconsole 3.0 release batch.
WDYT ?
Regards
Felix
>
>
>> Regards
>> Felix
>>>
>>>
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> As for the Web Console, I think we should move the OBR support plugin
>>>>>> out of the Web Console over to the bundlerepository plugin. This
>> solves
>>>>>> the more general problem of the current bundlerepository refactoring
>> for
>>>>>> the web console (and only for the web console).
>>>>>>
>>>>>> The more general problem is that of removing existing API: The old
>>>>>> org.osgi.service.obr API has been replaced in the bundle repository
>>>>>> trunk by the new o.a.felix.bundlerepository API. There may be very
>> good
>>>>>> reasons to do this. But it leeaves current users of the o.o.s.obr API
>>>>>> out in the dark.
>>>>>>
>>>>>
>>>>> Not really. The bundlerepository has a "compatibility layer" that is
>>>>> installed if the o.o.os.obr API is installed. Currently is not bundled
>>>>> anymore, but if we change that, it should be almost transparent for
>>>> users.
>>>>>
>>>>>>
>>>>>> WDYT of moving the obr bundle ? In the short term this looks to my
>> like
>>>>>> the only feasible solution to be able to cut a Web Console release
>> soon.
>>>>>>
>>>>>> What do we do about the now missing API ? To we provide backwards
>>>>>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
>>>>>> service) ? Do we simply abandon the old API and raise the bundle
>>>>>> repository bundle to a new major version number ?
>>>>>>
>>>>>
>>>>> Currently we have the wrappers already. if you installed the old obr
>> api
>>>>> first, the service should be registered.
>>>>>
>>>>>
>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>> On 21.03.2010 04:27, Sahoo wrote:
>>>>>>> This failure is introduced in rev #925279.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sahoo
>>>>>>>
>>>>>>> Sahoo wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>>>>> build and I see compilation failures like this:
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>>>> cannot find symbol
>>>>>>>> [exec] symbol: class R4Package
>>>>>>>> /
>>>>>>>> I don't see any R4Package.class in
>>>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>>>>
>>>>>>>> Is there a continuous integration job running for trunk? Can I see
>> its
>>>>>>>> log?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sahoo
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 10:36, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 10:17, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> On 22.03.2010 09:35, Guillaume Nodet wrote:
> >>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com>
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> The bundlerepository bundle has been disbanded into the core
> >>>> bundlerepository stuff and the Manifest parsing stuff moved to the new
> >>>> commons library/project.
> >>>>
> >>>> This creates some grieve for downstream users like Web Console but
> also
> >>>> other users of the bundlrepository.
> >>>>
> >>>
> >>> How so ? The bundlerepository bundle is supposed to embed those
> >>> dependencies, it should not affect the users at all. Or is that
> because
> >> the
> >>> web console was depending on those internal classes that have been
> >>> refactored ?
> >>
> >> Actually, I missed the point that old API is still supported ... Sorry.
> >>
> >> So, no problems.
> >>
> >> Still, the plugin should of course be able to cope with the situation
> >> where only the old API is available.
> >>
> >
> > Yeah, that'd be nice. It might require a bit more work and some features
> > might be disabled. For example, computing the dependencies would not be
> a
> > good idea i think because it might take a very long time.
>
> What dependencies to compute ? Do you mean the optional
> dependencies/requirements ?
>
Yes. I think wit the previous version of the resolver, it would to
unnacceptable computation time for the web pages (if you have a repo of a
decent size), especially as you have no way to not compute optional
dependencies and those are wrongly marked as mandatory anyway. The new one
being 10 time faster leads to better results.
>
> >
> > What if we resurrect the old version of the plugin and use it if the new
> api
> > is not available ?
> > I.e. we would have both plugins and use the new one if possible or the
> old
> > one if not.
>
> I am trying to implement this right now.
>
> Nevertheless this would leave us with the SNAPSHOT dependency to the new
> API, which prevents the Web Console from being released at this time.
>
> How about just supporting the old API for now and for a next release
> provide a second plugin implementation supporting the new functionality
> of the new API ?
>
>
Yeah, or we would release bundlerepository now. That would be a good idea
anyway I think.
> Regards
> Felix
> >
> >
> >>
> >> Regards
> >> Felix
> >>
> >>>
> >>>
> >>>>
> >>>> As for the Web Console, I think we should move the OBR support plugin
> >>>> out of the Web Console over to the bundlerepository plugin. This
> solves
> >>>> the more general problem of the current bundlerepository refactoring
> for
> >>>> the web console (and only for the web console).
> >>>>
> >>>> The more general problem is that of removing existing API: The old
> >>>> org.osgi.service.obr API has been replaced in the bundle repository
> >>>> trunk by the new o.a.felix.bundlerepository API. There may be very
> good
> >>>> reasons to do this. But it leeaves current users of the o.o.s.obr API
> >>>> out in the dark.
> >>>>
> >>>
> >>> Not really. The bundlerepository has a "compatibility layer" that is
> >>> installed if the o.o.os.obr API is installed. Currently is not bundled
> >>> anymore, but if we change that, it should be almost transparent for
> >> users.
> >>>
> >>>>
> >>>> WDYT of moving the obr bundle ? In the short term this looks to my
> like
> >>>> the only feasible solution to be able to cut a Web Console release
> soon.
> >>>>
> >>>> What do we do about the now missing API ? To we provide backwards
> >>>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
> >>>> service) ? Do we simply abandon the old API and raise the bundle
> >>>> repository bundle to a new major version number ?
> >>>>
> >>>
> >>> Currently we have the wrappers already. if you installed the old obr
> api
> >>> first, the service should be registered.
> >>>
> >>>
> >>>
> >>>> Regards
> >>>> Felix
> >>>>
> >>>> On 21.03.2010 04:27, Sahoo wrote:
> >>>>> This failure is introduced in rev #925279.
> >>>>>
> >>>>> Thanks,
> >>>>> Sahoo
> >>>>>
> >>>>> Sahoo wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> After updating my workspace to svn rev#925708, I am doing a clean
> >>>>>> build and I see compilation failures like this:
> >>>>>>
> >>>>>>
> >>>>
> >>
> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
> >>>>>> cannot find symbol
> >>>>>> [exec] symbol: class R4Package
> >>>>>> /
> >>>>>> I don't see any R4Package.class in
> >>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
> >>>>>>
> >>>>>> Is there a continuous integration job running for trunk? Can I see
> its
> >>>>>> log?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Sahoo
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 10:17, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> On 22.03.2010 09:35, Guillaume Nodet wrote:
>>> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> The bundlerepository bundle has been disbanded into the core
>>>> bundlerepository stuff and the Manifest parsing stuff moved to the new
>>>> commons library/project.
>>>>
>>>> This creates some grieve for downstream users like Web Console but also
>>>> other users of the bundlrepository.
>>>>
>>>
>>> How so ? The bundlerepository bundle is supposed to embed those
>>> dependencies, it should not affect the users at all. Or is that because
>> the
>>> web console was depending on those internal classes that have been
>>> refactored ?
>>
>> Actually, I missed the point that old API is still supported ... Sorry.
>>
>> So, no problems.
>>
>> Still, the plugin should of course be able to cope with the situation
>> where only the old API is available.
>>
>
> Yeah, that'd be nice. It might require a bit more work and some features
> might be disabled. For example, computing the dependencies would not be a
> good idea i think because it might take a very long time.
What dependencies to compute ? Do you mean the optional
dependencies/requirements ?
>
> What if we resurrect the old version of the plugin and use it if the new api
> is not available ?
> I.e. we would have both plugins and use the new one if possible or the old
> one if not.
I am trying to implement this right now.
Nevertheless this would leave us with the SNAPSHOT dependency to the new
API, which prevents the Web Console from being released at this time.
How about just supporting the old API for now and for a next release
provide a second plugin implementation supporting the new functionality
of the new API ?
Regards
Felix
>
>
>>
>> Regards
>> Felix
>>
>>>
>>>
>>>>
>>>> As for the Web Console, I think we should move the OBR support plugin
>>>> out of the Web Console over to the bundlerepository plugin. This solves
>>>> the more general problem of the current bundlerepository refactoring for
>>>> the web console (and only for the web console).
>>>>
>>>> The more general problem is that of removing existing API: The old
>>>> org.osgi.service.obr API has been replaced in the bundle repository
>>>> trunk by the new o.a.felix.bundlerepository API. There may be very good
>>>> reasons to do this. But it leeaves current users of the o.o.s.obr API
>>>> out in the dark.
>>>>
>>>
>>> Not really. The bundlerepository has a "compatibility layer" that is
>>> installed if the o.o.os.obr API is installed. Currently is not bundled
>>> anymore, but if we change that, it should be almost transparent for
>> users.
>>>
>>>>
>>>> WDYT of moving the obr bundle ? In the short term this looks to my like
>>>> the only feasible solution to be able to cut a Web Console release soon.
>>>>
>>>> What do we do about the now missing API ? To we provide backwards
>>>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
>>>> service) ? Do we simply abandon the old API and raise the bundle
>>>> repository bundle to a new major version number ?
>>>>
>>>
>>> Currently we have the wrappers already. if you installed the old obr api
>>> first, the service should be registered.
>>>
>>>
>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 21.03.2010 04:27, Sahoo wrote:
>>>>> This failure is introduced in rev #925279.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Sahoo wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>>>> build and I see compilation failures like this:
>>>>>>
>>>>>>
>>>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>>>> cannot find symbol
>>>>>> [exec] symbol: class R4Package
>>>>>> /
>>>>>> I don't see any R4Package.class in
>>>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>>>
>>>>>> Is there a continuous integration job running for trunk? Can I see its
>>>>>> log?
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: OBR Web Console Plugin
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 10:08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 22.03.2010 09:35, Guillaume Nodet wrote:
> > On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> The bundlerepository bundle has been disbanded into the core
> >> bundlerepository stuff and the Manifest parsing stuff moved to the new
> >> commons library/project.
> >>
> >> This creates some grieve for downstream users like Web Console but also
> >> other users of the bundlrepository.
> >>
> >
> > How so ? The bundlerepository bundle is supposed to embed those
> > dependencies, it should not affect the users at all. Or is that because
> the
> > web console was depending on those internal classes that have been
> > refactored ?
>
> Actually, I missed the point that old API is still supported ... Sorry.
>
> So, no problems.
>
> Still, the plugin should of course be able to cope with the situation
> where only the old API is available.
>
Yeah, that'd be nice. It might require a bit more work and some features
might be disabled. For example, computing the dependencies would not be a
good idea i think because it might take a very long time.
What if we resurrect the old version of the plugin and use it if the new api
is not available ?
I.e. we would have both plugins and use the new one if possible or the old
one if not.
>
> Regards
> Felix
>
> >
> >
> >>
> >> As for the Web Console, I think we should move the OBR support plugin
> >> out of the Web Console over to the bundlerepository plugin. This solves
> >> the more general problem of the current bundlerepository refactoring for
> >> the web console (and only for the web console).
> >>
> >> The more general problem is that of removing existing API: The old
> >> org.osgi.service.obr API has been replaced in the bundle repository
> >> trunk by the new o.a.felix.bundlerepository API. There may be very good
> >> reasons to do this. But it leeaves current users of the o.o.s.obr API
> >> out in the dark.
> >>
> >
> > Not really. The bundlerepository has a "compatibility layer" that is
> > installed if the o.o.os.obr API is installed. Currently is not bundled
> > anymore, but if we change that, it should be almost transparent for
> users.
> >
> >>
> >> WDYT of moving the obr bundle ? In the short term this looks to my like
> >> the only feasible solution to be able to cut a Web Console release soon.
> >>
> >> What do we do about the now missing API ? To we provide backwards
> >> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
> >> service) ? Do we simply abandon the old API and raise the bundle
> >> repository bundle to a new major version number ?
> >>
> >
> > Currently we have the wrappers already. if you installed the old obr api
> > first, the service should be registered.
> >
> >
> >
> >> Regards
> >> Felix
> >>
> >> On 21.03.2010 04:27, Sahoo wrote:
> >>> This failure is introduced in rev #925279.
> >>>
> >>> Thanks,
> >>> Sahoo
> >>>
> >>> Sahoo wrote:
> >>>> Hi,
> >>>>
> >>>> After updating my workspace to svn rev#925708, I am doing a clean
> >>>> build and I see compilation failures like this:
> >>>>
> >>>>
> >>
> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
> >>>> cannot find symbol
> >>>> [exec] symbol: class R4Package
> >>>> /
> >>>> I don't see any R4Package.class in
> >>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
> >>>>
> >>>> Is there a continuous integration job running for trunk? Can I see its
> >>>> log?
> >>>>
> >>>> Thanks,
> >>>> Sahoo
> >>>
> >>
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OBR Web Console Plugin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.03.2010 09:35, Guillaume Nodet wrote:
> On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com> wrote:
>
>> Hi,
>>
>> The bundlerepository bundle has been disbanded into the core
>> bundlerepository stuff and the Manifest parsing stuff moved to the new
>> commons library/project.
>>
>> This creates some grieve for downstream users like Web Console but also
>> other users of the bundlrepository.
>>
>
> How so ? The bundlerepository bundle is supposed to embed those
> dependencies, it should not affect the users at all. Or is that because the
> web console was depending on those internal classes that have been
> refactored ?
Actually, I missed the point that old API is still supported ... Sorry.
So, no problems.
Still, the plugin should of course be able to cope with the situation
where only the old API is available.
Regards
Felix
>
>
>>
>> As for the Web Console, I think we should move the OBR support plugin
>> out of the Web Console over to the bundlerepository plugin. This solves
>> the more general problem of the current bundlerepository refactoring for
>> the web console (and only for the web console).
>>
>> The more general problem is that of removing existing API: The old
>> org.osgi.service.obr API has been replaced in the bundle repository
>> trunk by the new o.a.felix.bundlerepository API. There may be very good
>> reasons to do this. But it leeaves current users of the o.o.s.obr API
>> out in the dark.
>>
>
> Not really. The bundlerepository has a "compatibility layer" that is
> installed if the o.o.os.obr API is installed. Currently is not bundled
> anymore, but if we change that, it should be almost transparent for users.
>
>>
>> WDYT of moving the obr bundle ? In the short term this looks to my like
>> the only feasible solution to be able to cut a Web Console release soon.
>>
>> What do we do about the now missing API ? To we provide backwards
>> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
>> service) ? Do we simply abandon the old API and raise the bundle
>> repository bundle to a new major version number ?
>>
>
> Currently we have the wrappers already. if you installed the old obr api
> first, the service should be registered.
>
>
>
>> Regards
>> Felix
>>
>> On 21.03.2010 04:27, Sahoo wrote:
>>> This failure is introduced in rev #925279.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Sahoo wrote:
>>>> Hi,
>>>>
>>>> After updating my workspace to svn rev#925708, I am doing a clean
>>>> build and I see compilation failures like this:
>>>>
>>>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>>>> cannot find symbol
>>>> [exec] symbol: class R4Package
>>>> /
>>>> I don't see any R4Package.class in
>>>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>>>
>>>> Is there a continuous integration job running for trunk? Can I see its
>>>> log?
>>>>
>>>> Thanks,
>>>> Sahoo
>>>
>>
>
>
>
Re: OBR Web Console Plugin (was: trunk/webconsole fails to build)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 22, 2010 at 09:08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> The bundlerepository bundle has been disbanded into the core
> bundlerepository stuff and the Manifest parsing stuff moved to the new
> commons library/project.
>
> This creates some grieve for downstream users like Web Console but also
> other users of the bundlrepository.
>
How so ? The bundlerepository bundle is supposed to embed those
dependencies, it should not affect the users at all. Or is that because the
web console was depending on those internal classes that have been
refactored ?
>
> As for the Web Console, I think we should move the OBR support plugin
> out of the Web Console over to the bundlerepository plugin. This solves
> the more general problem of the current bundlerepository refactoring for
> the web console (and only for the web console).
>
> The more general problem is that of removing existing API: The old
> org.osgi.service.obr API has been replaced in the bundle repository
> trunk by the new o.a.felix.bundlerepository API. There may be very good
> reasons to do this. But it leeaves current users of the o.o.s.obr API
> out in the dark.
>
Not really. The bundlerepository has a "compatibility layer" that is
installed if the o.o.os.obr API is installed. Currently is not bundled
anymore, but if we change that, it should be almost transparent for users.
>
> WDYT of moving the obr bundle ? In the short term this looks to my like
> the only feasible solution to be able to cut a Web Console release soon.
>
> What do we do about the now missing API ? To we provide backwards
> compatible wrappers (including an o.o.service.obr.RepositoryAdmin
> service) ? Do we simply abandon the old API and raise the bundle
> repository bundle to a new major version number ?
>
Currently we have the wrappers already. if you installed the old obr api
first, the service should be registered.
> Regards
> Felix
>
> On 21.03.2010 04:27, Sahoo wrote:
> > This failure is introduced in rev #925279.
> >
> > Thanks,
> > Sahoo
> >
> > Sahoo wrote:
> >> Hi,
> >>
> >> After updating my workspace to svn rev#925708, I am doing a clean
> >> build and I see compilation failures like this:
> >>
> >>
> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
> >> cannot find symbol
> >> [exec] symbol: class R4Package
> >> /
> >> I don't see any R4Package.class in
> >> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
> >>
> >> Is there a continuous integration job running for trunk? Can I see its
> >> log?
> >>
> >> Thanks,
> >> Sahoo
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
OBR Web Console Plugin (was: trunk/webconsole fails to build)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
The bundlerepository bundle has been disbanded into the core
bundlerepository stuff and the Manifest parsing stuff moved to the new
commons library/project.
This creates some grieve for downstream users like Web Console but also
other users of the bundlrepository.
As for the Web Console, I think we should move the OBR support plugin
out of the Web Console over to the bundlerepository plugin. This solves
the more general problem of the current bundlerepository refactoring for
the web console (and only for the web console).
The more general problem is that of removing existing API: The old
org.osgi.service.obr API has been replaced in the bundle repository
trunk by the new o.a.felix.bundlerepository API. There may be very good
reasons to do this. But it leeaves current users of the o.o.s.obr API
out in the dark.
WDYT of moving the obr bundle ? In the short term this looks to my like
the only feasible solution to be able to cut a Web Console release soon.
What do we do about the now missing API ? To we provide backwards
compatible wrappers (including an o.o.service.obr.RepositoryAdmin
service) ? Do we simply abandon the old API and raise the bundle
repository bundle to a new major version number ?
Regards
Felix
On 21.03.2010 04:27, Sahoo wrote:
> This failure is introduced in rev #925279.
>
> Thanks,
> Sahoo
>
> Sahoo wrote:
>> Hi,
>>
>> After updating my workspace to svn rev#925708, I am doing a clean
>> build and I see compilation failures like this:
>>
>> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
>> cannot find symbol
>> [exec] symbol: class R4Package
>> /
>> I don't see any R4Package.class in
>> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>>
>> Is there a continuous integration job running for trunk? Can I see its
>> log?
>>
>> Thanks,
>> Sahoo
>
Re: trunk/webconsole fails to build
Posted by Sahoo <Sa...@Sun.COM>.
This failure is introduced in rev #925279.
Thanks,
Sahoo
Sahoo wrote:
> Hi,
>
> After updating my workspace to svn rev#925708, I am doing a clean
> build and I see compilation failures like this:
>
> /src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java:[904,54]
> cannot find symbol
> [exec] symbol: class R4Package
> /
> I don't see any R4Package.class in
> bundlerepository-1.5.0-SNAPSHOT.jar, that's recently built.
>
> Is there a continuous integration job running for trunk? Can I see its
> log?
>
> Thanks,
> Sahoo