Home » Archived » B3 » Building non-Eclipse things with b3
|
| Re: Building non-Eclipse things with b3 [message #488227 is a reply to message #488226] |
Sat, 26 September 2009 09:26   |
|
Hi Oisin,
I think it's essential that the models that we now create can cover all sorts of use-cases. As with P2, the objectives
with B3 is to be generic. It's not supposed to be bound to OSGi or even to Java.
P2's initial objective was to replace the old update manager so they focused on the use-cases involving features and
bundles first. In some respect, perhaps they were too focused but on the other hand, it gave the project the traction it
needed to become successful. I think we can learn two lessons from that. The first being that it is extremely important
to think it all thorough, both in breadth and in depth, before the implementation starts (and not focus on PDE during
that phase). The second is that we should start with the use-cases that will give us the most traction. It's my belief
that we will do that by focusing on the PDE build as the first candidate. It is a complex use-case with many demands not
seen elsewhere which is good. One thing to be extra careful about when the implementation starts is that the core must
be kept generic. The first phase is supposed to give us the design/architecture that asserts that.
- thomas
On 09/26/2009 11:01 AM, Oisin Hurley wrote:
> Is it a design goal that the b3 'core' should be able to build all sorts
> of gear, including banging together non-Eclipse and non-OSGi artifacts
> to create simple deliverables like JAR files? Looking at the models, I
> think that this is on the table - which makes me think that there should
> be some concrete use-cases that can serve as tests for success.
> Perhaps it's more urgent to be the PDE build successor and get that
> sorted out before reaching for more general goals...
>
> --oh
|
|
|
| Re: Building non-Eclipse things with b3 [message #488228 is a reply to message #488226] |
Sat, 26 September 2009 09:39 |
|
Hi Oisin,
I think it's essential that the models that we now create can cover all sorts of use-cases. As with P2, the objective
with B3 is to be generic. It's not supposed to be bound to OSGi or even to Java.
P2's initial objective was to replace the old update manager so they focused on the use-cases involving features and
bundles first. In some respect, perhaps they were too focused, but on the other hand, it gave the project the traction
it needed to become successful. I think we can learn two lessons from that; The first being that it is extremely
important to think it all trough, both in breadth and in depth, before the implementation starts (and not focus on PDE
during that phase). The second is that we should start with the use-cases that will give us the most traction. It's my
belief that we will do that by focusing on the PDE build as the first candidate. It is a complex use-case with many
demands not seen elsewhere which is good. One thing to be extra careful about when the implementation starts is that the
core must be kept generic. The first phase is supposed to give us the design/architecture that asserts that.
- thomas
On 09/26/2009 11:01 AM, Oisin Hurley wrote:
> Is it a design goal that the b3 'core' should be able to build all sorts
> of gear, including banging together non-Eclipse and non-OSGi artifacts
> to create simple deliverables like JAR files? Looking at the models, I
> think that this is on the table - which makes me think that there should
> be some concrete use-cases that can serve as tests for success.
> Perhaps it's more urgent to be the PDE build successor and get that
> sorted out before reaching for more general goals...
>
> --oh
|
|
|
| Re: Building non-Eclipse things with b3 [message #488233 is a reply to message #488228] |
Sat, 26 September 2009 13:46 |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Agree with Thomas,
b3 should be agnostic to what is being built.
It is important to have a model that has enough descriptive power to
cover other domains than OSGi/Eclipse. So, if anyone has ideas for
domains that we should look at as a "use-case test" I am very interested
in doing the exercise. (An expert in such a domain is required - or it
will take too long).
Although it may have an effect on the model, we are going to focus on
PDE and Java first.
- henrik
Thomas Hallgren wrote:
> Hi Oisin,
> I think it's essential that the models that we now create can cover all
> sorts of use-cases. As with P2, the objective with B3 is to be generic.
> It's not supposed to be bound to OSGi or even to Java.
>
> P2's initial objective was to replace the old update manager so they
> focused on the use-cases involving features and bundles first. In some
> respect, perhaps they were too focused, but on the other hand, it gave
> the project the traction it needed to become successful. I think we can
> learn two lessons from that; The first being that it is extremely
> important to think it all trough, both in breadth and in depth, before
> the implementation starts (and not focus on PDE during that phase). The
> second is that we should start with the use-cases that will give us the
> most traction. It's my belief that we will do that by focusing on the
> PDE build as the first candidate. It is a complex use-case with many
> demands not seen elsewhere which is good. One thing to be extra careful
> about when the implementation starts is that the core must be kept
> generic. The first phase is supposed to give us the design/architecture
> that asserts that.
>
> - thomas
>
> On 09/26/2009 11:01 AM, Oisin Hurley wrote:
>> Is it a design goal that the b3 'core' should be able to build all sorts
>> of gear, including banging together non-Eclipse and non-OSGi artifacts
>> to create simple deliverables like JAR files? Looking at the models, I
>> think that this is on the table - which makes me think that there should
>> be some concrete use-cases that can serve as tests for success.
>> Perhaps it's more urgent to be the PDE build successor and get that
>> sorted out before reaching for more general goals...
>>
>> --oh
>
|
|
|
| Re: Building non-Eclipse things with b3 [message #488234 is a reply to message #488228] |
Sat, 26 September 2009 13:53 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Agree with Thomas,
b3 should be agnostic to what is being built.
It is important to have a model that has enough descriptive power to
cover other domains than OSGi/Eclipse. So, if anyone has ideas for
domains that we should look at as a "use-case test" I am very interested
in doing the exercise. (An expert in such a domain is required - or it
will take too long).
Although it may have an effect on the model, we are going to focus on
PDE and Java first.
I am currently working on the interfaces for build units representing
Java (jar based), and PDE (osgi and feature) components. (This
corresponds to the Buckminster component types and their attributes. In
b3 we felt that it would be good to formalize the interfaces as real
callable interfaces. I am mentioning this, as anyone wanting to add
support to some other domain, should probably start at that end -
thinking about what compromises a "build unit" in the domain, and the
interface of such a unit (i.e. what is it someone expects to get from
such a unit).
BTW - did you have a particular domain in mind?
- henrik
Thomas Hallgren wrote:
> Hi Oisin,
> I think it's essential that the models that we now create can cover all
> sorts of use-cases. As with P2, the objective with B3 is to be generic.
> It's not supposed to be bound to OSGi or even to Java.
>
> P2's initial objective was to replace the old update manager so they
> focused on the use-cases involving features and bundles first. In some
> respect, perhaps they were too focused, but on the other hand, it gave
> the project the traction it needed to become successful. I think we can
> learn two lessons from that; The first being that it is extremely
> important to think it all trough, both in breadth and in depth, before
> the implementation starts (and not focus on PDE during that phase). The
> second is that we should start with the use-cases that will give us the
> most traction. It's my belief that we will do that by focusing on the
> PDE build as the first candidate. It is a complex use-case with many
> demands not seen elsewhere which is good. One thing to be extra careful
> about when the implementation starts is that the core must be kept
> generic. The first phase is supposed to give us the design/architecture
> that asserts that.
>
> - thomas
>
> On 09/26/2009 11:01 AM, Oisin Hurley wrote:
>> Is it a design goal that the b3 'core' should be able to build all sorts
>> of gear, including banging together non-Eclipse and non-OSGi artifacts
>> to create simple deliverables like JAR files? Looking at the models, I
>> think that this is on the table - which makes me think that there should
>> be some concrete use-cases that can serve as tests for success.
>> Perhaps it's more urgent to be the PDE build successor and get that
>> sorted out before reaching for more general goals...
>>
>> --oh
>
|
|
|
| Re: Building non-Eclipse things with b3 [message #488336 is a reply to message #488234] |
Mon, 28 September 2009 09:12 |
Oisin Hurley
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
| Henrik Lindberg wrote on Sat, 26 September 2009 09:53 |
It is important to have a model that has enough descriptive power to
cover other domains than OSGi/Eclipse. So, if anyone has ideas for
domains that we should look at as a "use-case test" I am very interested
in doing the exercise. (An expert in such a domain is required - or it
will take too long).
|
My day-to-day work stuff has a lot of Maven involved in it, and I and
my customers would very much like the get Maven build process and
the Eclipse building-using-maven-as-a-delegate working in some kind
of harmnious and scalable fashion. I'm hoping that b3 can offer enough
access in terms of extensions and interfaces to allow a very smooth
integration to work, in headless and IDE builds. As you already know,
this is one reason why the build model is so important - it's something
that can be built up by multiple contributors, sourced from different
metadata providers and then consumer by multiple build delegates.
I'll bring this up at the ESE in more detail, since I've not got my head
fully around the models content just yet!
| Quote: |
Although it may have an effect on the model, we are going to focus on
PDE and Java first.
|
That makes sense as the more pressing case.
| Quote: |
I am currently working on the interfaces for build units representing
Java (jar based), and PDE (osgi and feature) components. (This
corresponds to the Buckminster component types and their attributes. In
b3 we felt that it would be good to formalize the interfaces as real
callable interfaces. I am mentioning this, as anyone wanting to add
support to some other domain, should probably start at that end -
thinking about what compromises a "build unit" in the domain, and the
interface of such a unit (i.e. what is it someone expects to get from
such a unit).
|
+1 I definitely agree there needs to be formal interfaces, not only
for programmatic access, but for managing the lifecycle of the
software itself - breaking APIs causes many issues in some extensible
build mechanisms that live out there at the moment.
| Quote: |
BTW - did you have a particular domain in mind?
|
I'm currently thinking of Apache Karaf Features (which are a little
like Eclipse Features) and how to support them in tools. Probably
a bit early yet in the play, however. What I am really interested in
is being able to interact with b3 at points such as after the model
is constructed, as the model is constructed, being able to intercept
calls to fetch dependencies, query how capabilities have been
resolved and basically dig in at the lowest possible level with the
build execution, so that I can build tools to debug and analyze the
buld content and process and isolate issues. And of course, to
ensure that I'm not having to use internal APIs to do that kind of
thing 
cheers
--oh
|
|
|
| Re: Building non-Eclipse things with b3 [message #488358 is a reply to message #488336] |
Mon, 28 September 2009 12:01 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Oisin Hurley wrote:
> Henrik Lindberg wrote on Sat, 26 September 2009 09:53
>> It is important to have a model that has enough descriptive power to
>> cover other domains than OSGi/Eclipse. So, if anyone has ideas for
>> domains that we should look at as a "use-case test" I am very
>> interested in doing the exercise. (An expert in such a domain is
>> required - or it will take too long).
>
>
> My day-to-day work stuff has a lot of Maven involved in it, and I and
> my customers would very much like the get Maven build process and
> the Eclipse building-using-maven-as-a-delegate working in some kind
> of harmnious and scalable fashion. I'm hoping that b3 can offer enough
> access in terms of extensions and interfaces to allow a very smooth
> integration to work, in headless and IDE builds. As you already know,
> this is one reason why the build model is so important - it's something
> that can be built up by multiple contributors, sourced from different
> metadata providers and then consumer by multiple build delegates.
>
> I'll bring this up at the ESE in more detail, since I've not got my head
> fully around the models content just yet!
>
ok - there are lots of things to talk about...
> Quote:
>> I am currently working on the interfaces for build units representing
>> Java (jar based), and PDE (osgi and feature) components. (This
>> corresponds to the Buckminster component types and their attributes.
>> In b3 we felt that it would be good to formalize the interfaces as
>> real callable interfaces. I am mentioning this, as anyone wanting to
>> add support to some other domain, should probably start at that end -
>> thinking about what compromises a "build unit" in the domain, and the
>> interface of such a unit (i.e. what is it someone expects to get from
>> such a unit).
>
>
> +1 I definitely agree there needs to be formal interfaces, not only
> for programmatic access, but for managing the lifecycle of the software
> itself - breaking APIs causes many issues in some extensible
> build mechanisms that live out there at the moment.
>
Glad we agree - I want this to be something that b3 does in a strong
way. The interface is just a start. More ideas are welcome.
> Quote:
>> BTW - did you have a particular domain in mind?
>
>
> I'm currently thinking of Apache Karaf Features (which are a little
> like Eclipse Features) and how to support them in tools. Probably
> a bit early yet in the play, however. What I am really interested in
> is being able to interact with b3 at points such as after the model
> is constructed, as the model is constructed, being able to intercept
> calls to fetch dependencies, query how capabilities have been
> resolved and basically dig in at the lowest possible level with the
> build execution, so that I can build tools to debug and analyze the
> buld content and process and isolate issues. And of course, to
> ensure that I'm not having to use internal APIs to do that kind of thing :)
>
Debugging ideas looks intereting. I was thinking that we provide events
as the engine is performing its work. Let say an event before and after
each "phase" or "step". This means it is possible to look at the model
before being adviced, and then after being adviced, and again before a
particular build action again provides advice.
Thus, armed with a listener, it is possible to set real breakpoints and
inspect the model.
If debug events are delivered synchronously, it would make it possible
to write a cool "build system debugger" that allows the user to step
between the predetermined breakpoints (before/after, etc.) and it could
show the resulting build model using an EMF generated UI. Lots of
opportunity for someone to add cool features.
(This triggered another idea... will make a separate post).
> cheers
> --oh
|
|
| | | | | |
| Re: Building non-Eclipse things with b3 [message #489235 is a reply to message #489224] |
Fri, 02 October 2009 00:15 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/2/09 12:16 AM, Werner Keil wrote:
> Re: UI, how about i18n and Globalization ?;-)
>
> I'd be happy to help on that as committing member of the Babel project.
>
Sounds great, we are grateful for all contributions.
What do you see as the I18N and G11N issues for b3?
I can think of a few:
- The UI (naturally) where we naturally would use the standard
mechanisms for NLS, and external strings for everything user facing.
- We would prefer to use English as the language in debug output, and
possibly also in logs - as these are most often sent to eclipse in bug
reports.
- As b3 will be processing elements named by users, these elements may
be in non-English languages, and proper care must be taken to assure
that such things can be built.
- Adapters to different types of repositories may produce exceptions in
non-English, in the rare case that exception text has to be parsed, this
needs to be supported by a language extension to b3 (or it would not
know how to make sense of the exception).
- Concrete syntax (for instance build advice, properties) will most
likely not be translated. That would be like translating the keywords in
a programming language (this usually leads to disaster as it is not
possible to share such files).
Do you see more issues/situations where I18N and G11N needs to be taken
into consideration?
> And I'm currently involved in a major Build project of server-side
> elements of an otherwise P2-based Eclipse project.
> We got some approaches there which could match well with B3.
>
I am very interested in hearing more about these approaches - do they
relate to I18N, G11N specifically - or are these approaches in general
to building for/with PDE/p2 ?
Regards
- henrik
|
|
|
| Re: Building non-Eclipse things with b3 [message #489548 is a reply to message #489235] |
Sun, 04 October 2009 18:49 |
Werner Keil
Messages: 1087
Registered: July 2009 |
Senior Member |
|
|
Thanks for the outline of possible topics.
I agree, that at least build targets or commands usually won't need to be
translated.
Nor would a "help" or about if just run in the command line need to be.
On a rich (PDE Tools) UI I would not say so, but that is something most
Eclipse projects lack so far.
Also multilingual tutorials which so far very few projects spend time on
(STEM is among the first, we started to put up Spanish translations, German
following in the next few weeks)
If B3 maybe together with the Athena project aims to support Continuous
Integration on a Build Server, then Babel may not only help, but for its own
(respective those of all translated Eclipse.org projects ;-) "message
bundles" could greatly profit from a better build system. Right now, nightly
builds are almost impossible due to P2-related issues.
This to answer your question seems to be a problem more on the P2 or PDE
side, but ideally this should also not persist for future Eclipse versions.
If regular (Daily or Weekly) builds were available in the same quality for
Babel translations, then the outcome of translated messages is far easier
and sooner visible and can be tested than at the moment.
It seems, there is no codebase right now or existing project to build upon
(except those 4 listed) ?
I cannot say how much of the improved (fully Ant and CI/Hudson friendly)
Build scripts I may share or disclose, as they serve our CRM, but the
general ideas should be no problem.
I also think, B4 might be even better, also thinking towards E4 rather than
3.x ;-)
Can anybody (existing committer) be listed as "Interested Party"? I either
as myself or for the Babel project would be happy to be.
Werner
|
|
|
| Re: Building non-Eclipse things with b3 [message #489552 is a reply to message #489548] |
Sun, 04 October 2009 19:04 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/4/09 8:49 PM, Werner Keil wrote:
> I agree, that at least build targets or commands usually won't need to
> be translated.
> Nor would a "help" or about if just run in the command line need to be.
> On a rich (PDE Tools) UI I would not say so, but that is something most
> Eclipse projects lack so far.
> Also multilingual tutorials which so far very few projects spend time on
ok, then we see things the same way. And b3 will have a translateable UI.
> If B3 maybe together with the Athena project aims to support Continuous
> Integration on a Build Server, then Babel may not only help, but for its
> own (respective those of all translated Eclipse.org projects ;-)
> "message bundles" could greatly profit from a better build system. Right
> now, nightly builds are almost impossible due to P2-related issues.
> This to answer your question seems to be a problem more on the P2 or PDE
> side, but ideally this should also not persist for future Eclipse versions.
>
The current ambition of the b3 project is not to replace the role played
by CI tools such as Hudson, but there is some overlap as b3 can do some
things more efficiently than just a CI server.
I have seen some posts regarding Babel and issues with p2 (size, speed,
etc.) but I have not looked into the issues with any detail. I would
imagine that a process consisting of building the language packs per
project and then aggregating the end result (using for instance
Buckminster Aggregator) would make it possible to set up decent process.
When eating an elephant, it is best to do it in slices ;)
> If regular (Daily or Weekly) builds were available in the same quality
> for Babel translations, then the outcome of translated messages is far
> easier and sooner visible and can be tested than at the moment.
>
I should be possible to do this today with for instance Buckminster.
> It seems, there is no codebase right now or existing project to build
> upon (except those 4 listed) ?
>
I am not sure I quite follow you there...
> I cannot say how much of the improved (fully Ant and CI/Hudson friendly)
> Build scripts I may share or disclose, as they serve our CRM, but the
> general ideas should be no problem.
>
great.
> I also think, B4 might be even better, also thinking towards E4 rather
> than 3.x ;-)
>
:)
> Can anybody (existing committer) be listed as "Interested Party"? I
> either as myself or for the Babel project would be happy to be.
>
sure - for starters, just list yourself on the b3 wikipage.
- henrik
|
|
|
| Re: Building non-Eclipse things with b3 [message #578124 is a reply to message #488228] |
Sat, 26 September 2009 13:46 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Agree with Thomas,
b3 should be agnostic to what is being built.
It is important to have a model that has enough descriptive power to
cover other domains than OSGi/Eclipse. So, if anyone has ideas for
domains that we should look at as a "use-case test" I am very interested
in doing the exercise. (An expert in such a domain is required - or it
will take too long).
Although it may have an effect on the model, we are going to focus on
PDE and Java first.
- henrik
Thomas Hallgren wrote:
> Hi Oisin,
> I think it's essential that the models that we now create can cover all
> sorts of use-cases. As with P2, the objective with B3 is to be generic.
> It's not supposed to be bound to OSGi or even to Java.
>
> P2's initial objective was to replace the old update manager so they
> focused on the use-cases involving features and bundles first. In some
> respect, perhaps they were too focused, but on the other hand, it gave
> the project the traction it needed to become successful. I think we can
> learn two lessons from that; The first being that it is extremely
> important to think it all trough, both in breadth and in depth, before
> the implementation starts (and not focus on PDE during that phase). The
> second is that we should start with the use-cases that will give us the
> most traction. It's my belief that we will do that by focusing on the
> PDE build as the first candidate. It is a complex use-case with many
> demands not seen elsewhere which is good. One thing to be extra careful
> about when the implementation starts is that the core must be kept
> generic. The first phase is supposed to give us the design/architecture
> that asserts that.
>
> - thomas
>
> On 09/26/2009 11:01 AM, Oisin Hurley wrote:
>> Is it a design goal that the b3 'core' should be able to build all sorts
>> of gear, including banging together non-Eclipse and non-OSGi artifacts
>> to create simple deliverables like JAR files? Looking at the models, I
>> think that this is on the table - which makes me think that there should
>> be some concrete use-cases that can serve as tests for success.
>> Perhaps it's more urgent to be the PDE build successor and get that
>> sorted out before reaching for more general goals...
>>
>> --oh
>
|
|
|
| Re: Building non-Eclipse things with b3 [message #578137 is a reply to message #488228] |
Sat, 26 September 2009 13:53 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Agree with Thomas,
b3 should be agnostic to what is being built.
It is important to have a model that has enough descriptive power to
cover other domains than OSGi/Eclipse. So, if anyone has ideas for
domains that we should look at as a "use-case test" I am very interested
in doing the exercise. (An expert in such a domain is required - or it
will take too long).
Although it may have an effect on the model, we are going to focus on
PDE and Java first.
I am currently working on the interfaces for build units representing
Java (jar based), and PDE (osgi and feature) components. (This
corresponds to the Buckminster component types and their attributes. In
b3 we felt that it would be good to formalize the interfaces as real
callable interfaces. I am mentioning this, as anyone wanting to add
support to some other domain, should probably start at that end -
thinking about what compromises a "build unit" in the domain, and the
interface of such a unit (i.e. what is it someone expects to get from
such a unit).
BTW - did you have a particular domain in mind?
- henrik
Thomas Hallgren wrote:
> Hi Oisin,
> I think it's essential that the models that we now create can cover all
> sorts of use-cases. As with P2, the objective with B3 is to be generic.
> It's not supposed to be bound to OSGi or even to Java.
>
> P2's initial objective was to replace the old update manager so they
> focused on the use-cases involving features and bundles first. In some
> respect, perhaps they were too focused, but on the other hand, it gave
> the project the traction it needed to become successful. I think we can
> learn two lessons from that; The first being that it is extremely
> important to think it all trough, both in breadth and in depth, before
> the implementation starts (and not focus on PDE during that phase). The
> second is that we should start with the use-cases that will give us the
> most traction. It's my belief that we will do that by focusing on the
> PDE build as the first candidate. It is a complex use-case with many
> demands not seen elsewhere which is good. One thing to be extra careful
> about when the implementation starts is that the core must be kept
> generic. The first phase is supposed to give us the design/architecture
> that asserts that.
>
> - thomas
>
> On 09/26/2009 11:01 AM, Oisin Hurley wrote:
>> Is it a design goal that the b3 'core' should be able to build all sorts
>> of gear, including banging together non-Eclipse and non-OSGi artifacts
>> to create simple deliverables like JAR files? Looking at the models, I
>> think that this is on the table - which makes me think that there should
>> be some concrete use-cases that can serve as tests for success.
>> Perhaps it's more urgent to be the PDE build successor and get that
>> sorted out before reaching for more general goals...
>>
>> --oh
>
|
|
|
| Re: Building non-Eclipse things with b3 [message #578292 is a reply to message #488234] |
Mon, 28 September 2009 09:12 |
Oisin Hurley
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
Henrik Lindberg wrote on Sat, 26 September 2009 09:53
> It is important to have a model that has enough descriptive power to
> cover other domains than OSGi/Eclipse. So, if anyone has ideas for
> domains that we should look at as a "use-case test" I am very interested
> in doing the exercise. (An expert in such a domain is required - or it
> will take too long).
My day-to-day work stuff has a lot of Maven involved in it, and I and
my customers would very much like the get Maven build process and
the Eclipse building-using-maven-as-a-delegate working in some kind
of harmnious and scalable fashion. I'm hoping that b3 can offer enough
access in terms of extensions and interfaces to allow a very smooth
integration to work, in headless and IDE builds. As you already know,
this is one reason why the build model is so important - it's something
that can be built up by multiple contributors, sourced from different
metadata providers and then consumer by multiple build delegates.
I'll bring this up at the ESE in more detail, since I've not got my head
fully around the models content just yet!
Quote:
> Although it may have an effect on the model, we are going to focus on
> PDE and Java first.
That makes sense as the more pressing case.
Quote:
> I am currently working on the interfaces for build units representing
> Java (jar based), and PDE (osgi and feature) components. (This
> corresponds to the Buckminster component types and their attributes. In
> b3 we felt that it would be good to formalize the interfaces as real
> callable interfaces. I am mentioning this, as anyone wanting to add
> support to some other domain, should probably start at that end -
> thinking about what compromises a "build unit" in the domain, and the
> interface of such a unit (i.e. what is it someone expects to get from
> such a unit).
+1 I definitely agree there needs to be formal interfaces, not only
for programmatic access, but for managing the lifecycle of the
software itself - breaking APIs causes many issues in some extensible
build mechanisms that live out there at the moment.
Quote:
> BTW - did you have a particular domain in mind?
I'm currently thinking of Apache Karaf Features (which are a little
like Eclipse Features) and how to support them in tools. Probably
a bit early yet in the play, however. What I am really interested in
is being able to interact with b3 at points such as after the model
is constructed, as the model is constructed, being able to intercept
calls to fetch dependencies, query how capabilities have been
resolved and basically dig in at the lowest possible level with the
build execution, so that I can build tools to debug and analyze the
buld content and process and isolate issues. And of course, to
ensure that I'm not having to use internal APIs to do that kind of
thing :)
cheers
--oh
|
|
|
| Re: Building non-Eclipse things with b3 [message #578307 is a reply to message #578292] |
Mon, 28 September 2009 12:01 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Oisin Hurley wrote:
> Henrik Lindberg wrote on Sat, 26 September 2009 09:53
>> It is important to have a model that has enough descriptive power to
>> cover other domains than OSGi/Eclipse. So, if anyone has ideas for
>> domains that we should look at as a "use-case test" I am very
>> interested in doing the exercise. (An expert in such a domain is
>> required - or it will take too long).
>
>
> My day-to-day work stuff has a lot of Maven involved in it, and I and
> my customers would very much like the get Maven build process and
> the Eclipse building-using-maven-as-a-delegate working in some kind
> of harmnious and scalable fashion. I'm hoping that b3 can offer enough
> access in terms of extensions and interfaces to allow a very smooth
> integration to work, in headless and IDE builds. As you already know,
> this is one reason why the build model is so important - it's something
> that can be built up by multiple contributors, sourced from different
> metadata providers and then consumer by multiple build delegates.
>
> I'll bring this up at the ESE in more detail, since I've not got my head
> fully around the models content just yet!
>
ok - there are lots of things to talk about...
> Quote:
>> I am currently working on the interfaces for build units representing
>> Java (jar based), and PDE (osgi and feature) components. (This
>> corresponds to the Buckminster component types and their attributes.
>> In b3 we felt that it would be good to formalize the interfaces as
>> real callable interfaces. I am mentioning this, as anyone wanting to
>> add support to some other domain, should probably start at that end -
>> thinking about what compromises a "build unit" in the domain, and the
>> interface of such a unit (i.e. what is it someone expects to get from
>> such a unit).
>
>
> +1 I definitely agree there needs to be formal interfaces, not only
> for programmatic access, but for managing the lifecycle of the software
> itself - breaking APIs causes many issues in some extensible
> build mechanisms that live out there at the moment.
>
Glad we agree - I want this to be something that b3 does in a strong
way. The interface is just a start. More ideas are welcome.
> Quote:
>> BTW - did you have a particular domain in mind?
>
>
> I'm currently thinking of Apache Karaf Features (which are a little
> like Eclipse Features) and how to support them in tools. Probably
> a bit early yet in the play, however. What I am really interested in
> is being able to interact with b3 at points such as after the model
> is constructed, as the model is constructed, being able to intercept
> calls to fetch dependencies, query how capabilities have been
> resolved and basically dig in at the lowest possible level with the
> build execution, so that I can build tools to debug and analyze the
> buld content and process and isolate issues. And of course, to
> ensure that I'm not having to use internal APIs to do that kind of thing :)
>
Debugging ideas looks intereting. I was thinking that we provide events
as the engine is performing its work. Let say an event before and after
each "phase" or "step". This means it is possible to look at the model
before being adviced, and then after being adviced, and again before a
particular build action again provides advice.
Thus, armed with a listener, it is possible to set real breakpoints and
inspect the model.
If debug events are delivered synchronously, it would make it possible
to write a cool "build system debugger" that allows the user to step
between the predetermined breakpoints (before/after, etc.) and it could
show the resulting build model using an EMF generated UI. Lots of
opportunity for someone to add cool features.
(This triggered another idea... will make a separate post).
> cheers
> --oh
|
|
| | | | | |
| Re: Building non-Eclipse things with b3 [message #579893 is a reply to message #489224] |
Fri, 02 October 2009 00:15 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/2/09 12:16 AM, Werner Keil wrote:
> Re: UI, how about i18n and Globalization ?;-)
>
> I'd be happy to help on that as committing member of the Babel project.
>
Sounds great, we are grateful for all contributions.
What do you see as the I18N and G11N issues for b3?
I can think of a few:
- The UI (naturally) where we naturally would use the standard
mechanisms for NLS, and external strings for everything user facing.
- We would prefer to use English as the language in debug output, and
possibly also in logs - as these are most often sent to eclipse in bug
reports.
- As b3 will be processing elements named by users, these elements may
be in non-English languages, and proper care must be taken to assure
that such things can be built.
- Adapters to different types of repositories may produce exceptions in
non-English, in the rare case that exception text has to be parsed, this
needs to be supported by a language extension to b3 (or it would not
know how to make sense of the exception).
- Concrete syntax (for instance build advice, properties) will most
likely not be translated. That would be like translating the keywords in
a programming language (this usually leads to disaster as it is not
possible to share such files).
Do you see more issues/situations where I18N and G11N needs to be taken
into consideration?
> And I'm currently involved in a major Build project of server-side
> elements of an otherwise P2-based Eclipse project.
> We got some approaches there which could match well with B3.
>
I am very interested in hearing more about these approaches - do they
relate to I18N, G11N specifically - or are these approaches in general
to building for/with PDE/p2 ?
Regards
- henrik
|
|
|
| Re: Building non-Eclipse things with b3 [message #580996 is a reply to message #489235] |
Sun, 04 October 2009 18:49 |
Werner Keil
Messages: 1087
Registered: July 2009 |
Senior Member |
|
|
Thanks for the outline of possible topics.
I agree, that at least build targets or commands usually won't need to be
translated.
Nor would a "help" or about if just run in the command line need to be.
On a rich (PDE Tools) UI I would not say so, but that is something most
Eclipse projects lack so far.
Also multilingual tutorials which so far very few projects spend time on
(STEM is among the first, we started to put up Spanish translations, German
following in the next few weeks)
If B3 maybe together with the Athena project aims to support Continuous
Integration on a Build Server, then Babel may not only help, but for its own
(respective those of all translated Eclipse.org projects ;-) "message
bundles" could greatly profit from a better build system. Right now, nightly
builds are almost impossible due to P2-related issues.
This to answer your question seems to be a problem more on the P2 or PDE
side, but ideally this should also not persist for future Eclipse versions.
If regular (Daily or Weekly) builds were available in the same quality for
Babel translations, then the outcome of translated messages is far easier
and sooner visible and can be tested than at the moment.
It seems, there is no codebase right now or existing project to build upon
(except those 4 listed) ?
I cannot say how much of the improved (fully Ant and CI/Hudson friendly)
Build scripts I may share or disclose, as they serve our CRM, but the
general ideas should be no problem.
I also think, B4 might be even better, also thinking towards E4 rather than
3.x ;-)
Can anybody (existing committer) be listed as "Interested Party"? I either
as myself or for the Babel project would be happy to be.
Werner
|
|
|
| Re: Building non-Eclipse things with b3 [message #581014 is a reply to message #489548] |
Sun, 04 October 2009 19:04 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/4/09 8:49 PM, Werner Keil wrote:
> I agree, that at least build targets or commands usually won't need to
> be translated.
> Nor would a "help" or about if just run in the command line need to be.
> On a rich (PDE Tools) UI I would not say so, but that is something most
> Eclipse projects lack so far.
> Also multilingual tutorials which so far very few projects spend time on
ok, then we see things the same way. And b3 will have a translateable UI.
> If B3 maybe together with the Athena project aims to support Continuous
> Integration on a Build Server, then Babel may not only help, but for its
> own (respective those of all translated Eclipse.org projects ;-)
> "message bundles" could greatly profit from a better build system. Right
> now, nightly builds are almost impossible due to P2-related issues.
> This to answer your question seems to be a problem more on the P2 or PDE
> side, but ideally this should also not persist for future Eclipse versions.
>
The current ambition of the b3 project is not to replace the role played
by CI tools such as Hudson, but there is some overlap as b3 can do some
things more efficiently than just a CI server.
I have seen some posts regarding Babel and issues with p2 (size, speed,
etc.) but I have not looked into the issues with any detail. I would
imagine that a process consisting of building the language packs per
project and then aggregating the end result (using for instance
Buckminster Aggregator) would make it possible to set up decent process.
When eating an elephant, it is best to do it in slices ;)
> If regular (Daily or Weekly) builds were available in the same quality
> for Babel translations, then the outcome of translated messages is far
> easier and sooner visible and can be tested than at the moment.
>
I should be possible to do this today with for instance Buckminster.
> It seems, there is no codebase right now or existing project to build
> upon (except those 4 listed) ?
>
I am not sure I quite follow you there...
> I cannot say how much of the improved (fully Ant and CI/Hudson friendly)
> Build scripts I may share or disclose, as they serve our CRM, but the
> general ideas should be no problem.
>
great.
> I also think, B4 might be even better, also thinking towards E4 rather
> than 3.x ;-)
>
:)
> Can anybody (existing committer) be listed as "Interested Party"? I
> either as myself or for the Babel project would be happy to be.
>
sure - for starters, just list yourself on the b3 wikipage.
- henrik
|
|
|
Goto Forum:
Current Time: Tue Apr 16 12:03:44 GMT 2024
Powered by FUDForum. Page generated in 0.50025 seconds |
] 
Search
Help
Register
Login
Home
