Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » Packaging
Packaging [message #486616] Fri, 18 September 2009 08:30 Go to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi,

I just found out about this proposal and it sounds very promising to me.
Since this seems to be the place to throw in ideas, I'd like to throw in
mine.
For me, packaging is an important aspect of the build process. I
personally like the simple 'unzip' paradigma of eclipse, but many users
are more familiar with installers, package managers and similar
concepts. Also some eclipse based products require a more sophisticated
process than 'unzip' to properly function.
From what I know, the EPP project is working on installers for Eclipse
based products, and since this project is about simplifying software
build and assembly, here is what I'd really love to see:
The ability to create installers/packages for different operating
systems as easy as it currently is to create an update-site with
buckminster.
Best would be if the actual (platform agnostic) data
(plugins/features/...) would be in one file and the system specific
installer (exe, deb, rpm,...) would be a separate file that fetches
those bundles from the data file that match the platform it's executed on.
This would safe a lot of disc space since you don't need every bundle in
every platform combination and would make it easy to distribute a
cross-platform eclipse product on a single CD for all platform combinations.

Best regards,
Johannes
Re: Packaging [message #486619 is a reply to message #486616] Fri, 18 September 2009 08:54 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2492
Registered: July 2009
Senior Member
From a b3 perspective this is not difficult to do - the model has more
expressive power than Buckminster when it comes to handling a mix of
platform specific and agnostic parts in one invocation.

The idea for b3 is also to make it easy to inject meta data
translation/actions in an aspect oriented way. In Buckminster a CSPEX is
required inside the component where additional actions are wanted, or a
new component type must be implemented. Using a CSPEX does not work when
it is not possible to place it inside the source for the component, and
the same action has to be repeated in all components where it is wanted.
Implementing a component type requires a lot more effort.

Instead, in b3 I want it to be possible to declare things like "All
features that match criteria X should have action Y"

For the second part of your idea - being able to install code packaged
as you suggest is outside the scope of b3 - but I don't see anything
that would prevent building the output as conveniently as Buckminster
produces an update site.

Regards
- henrik

Johannes Utzig wrote:
> Hi,
>
> I just found out about this proposal and it sounds very promising to me.
> Since this seems to be the place to throw in ideas, I'd like to throw in
> mine.
> For me, packaging is an important aspect of the build process. I
> personally like the simple 'unzip' paradigma of eclipse, but many users
> are more familiar with installers, package managers and similar
> concepts. Also some eclipse based products require a more sophisticated
> process than 'unzip' to properly function.
> From what I know, the EPP project is working on installers for Eclipse
> based products, and since this project is about simplifying software
> build and assembly, here is what I'd really love to see:
> The ability to create installers/packages for different operating
> systems as easy as it currently is to create an update-site with
> buckminster.
> Best would be if the actual (platform agnostic) data
> (plugins/features/...) would be in one file and the system specific
> installer (exe, deb, rpm,...) would be a separate file that fetches
> those bundles from the data file that match the platform it's executed on.
> This would safe a lot of disc space since you don't need every bundle in
> every platform combination and would make it easy to distribute a
> cross-platform eclipse product on a single CD for all platform
> combinations.
>
> Best regards,
> Johannes
Re: Packaging [message #486624 is a reply to message #486619] Fri, 18 September 2009 09:08 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Henrik,

yeah, it's clear that the 2nd Part is out-of-scope, I was just competing
my christmas wish list :)
But do you think it could be in-scope to somewhat join efforts with the
EPP team to make their work easily usable (out-of-the-box at best) from
within b3? That's how I understood the proposal at least:

"Bridging discontinuities between building and provisioning software.
Software developers are linked in an iterative chain of building and
provisioning, in which the output of a given build becomes an input in a
subsequent build. Today, the tools and processes of building and
provisioning are poorly integrated, resulting in broken hand-offs and
wasted effort across the cycle. Automating the connection between each
link in the chain will be a goal of this project"

Best regards,
Johannes

Henrik Lindberg schrieb:
> From a b3 perspective this is not difficult to do - the model has more
> expressive power than Buckminster when it comes to handling a mix of
> platform specific and agnostic parts in one invocation.
>
> The idea for b3 is also to make it easy to inject meta data
> translation/actions in an aspect oriented way. In Buckminster a CSPEX is
> required inside the component where additional actions are wanted, or a
> new component type must be implemented. Using a CSPEX does not work when
> it is not possible to place it inside the source for the component, and
> the same action has to be repeated in all components where it is wanted.
> Implementing a component type requires a lot more effort.
>
> Instead, in b3 I want it to be possible to declare things like "All
> features that match criteria X should have action Y"
>
> For the second part of your idea - being able to install code packaged
> as you suggest is outside the scope of b3 - but I don't see anything
> that would prevent building the output as conveniently as Buckminster
> produces an update site.
>
> Regards
> - henrik
>
> Johannes Utzig wrote:
>> Hi,
>>
>> I just found out about this proposal and it sounds very promising to me.
>> Since this seems to be the place to throw in ideas, I'd like to throw
>> in mine.
>> For me, packaging is an important aspect of the build process. I
>> personally like the simple 'unzip' paradigma of eclipse, but many
>> users are more familiar with installers, package managers and similar
>> concepts. Also some eclipse based products require a more
>> sophisticated process than 'unzip' to properly function.
>> From what I know, the EPP project is working on installers for
>> Eclipse based products, and since this project is about simplifying
>> software build and assembly, here is what I'd really love to see:
>> The ability to create installers/packages for different operating
>> systems as easy as it currently is to create an update-site with
>> buckminster.
>> Best would be if the actual (platform agnostic) data
>> (plugins/features/...) would be in one file and the system specific
>> installer (exe, deb, rpm,...) would be a separate file that fetches
>> those bundles from the data file that match the platform it's executed
>> on.
>> This would safe a lot of disc space since you don't need every bundle
>> in every platform combination and would make it easy to distribute a
>> cross-platform eclipse product on a single CD for all platform
>> combinations.
>>
>> Best regards,
>> Johannes
Re: Packaging [message #486632 is a reply to message #486624] Fri, 18 September 2009 09:31 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2492
Registered: July 2009
Senior Member
Johannes Utzig wrote:
> Hi Henrik,
>
> yeah, it's clear that the 2nd Part is out-of-scope, I was just competing
> my christmas wish list :)
> But do you think it could be in-scope to somewhat join efforts with the
> EPP team to make their work easily usable (out-of-the-box at best) from
> within b3?

Absolutely.

> That's how I understood the proposal at least:
>
> "Bridging discontinuities between building and provisioning software.
> Software developers are linked in an iterative chain of building and
> provisioning, in which the output of a given build becomes an input in a
> subsequent build. Today, the tools and processes of building and
> provisioning are poorly integrated, resulting in broken hand-offs and
> wasted effort across the cycle. Automating the connection between each
> link in the chain will be a goal of this project"
>
Yes, that is a goal.

As we are just starting out, we felt there was a need to establish the
fundamental models first, as it otherwise is difficult to have a
rational discussion about the "higher levels" (Do we have Actions? If
so, what are they? How do we know which build actions to apply to
different types of units? etc. etc.). Idea being that the fundamental
models gets revised as more and more ideas and requirements are added.

What else would you like for Christmas :) ?

- henrik

> Henrik Lindberg schrieb:
>> From a b3 perspective this is not difficult to do - the model has
>> more expressive power than Buckminster when it comes to handling a mix
>> of platform specific and agnostic parts in one invocation.
>>
>> The idea for b3 is also to make it easy to inject meta data
>> translation/actions in an aspect oriented way. In Buckminster a CSPEX
>> is required inside the component where additional actions are wanted,
>> or a new component type must be implemented. Using a CSPEX does not
>> work when it is not possible to place it inside the source for the
>> component, and the same action has to be repeated in all components
>> where it is wanted. Implementing a component type requires a lot more
>> effort.
>>
>> Instead, in b3 I want it to be possible to declare things like "All
>> features that match criteria X should have action Y"
>>
>> For the second part of your idea - being able to install code packaged
>> as you suggest is outside the scope of b3 - but I don't see anything
>> that would prevent building the output as conveniently as Buckminster
>> produces an update site.
>>
>> Regards
>> - henrik
>>
>> Johannes Utzig wrote:
Re: Packaging [message #486656 is a reply to message #486632] Fri, 18 September 2009 10:26 Go to previous message
Oisin Hurley is currently offline Oisin Hurley
Messages: 204
Registered: July 2009
Senior Member
Henrik Lindberg wrote on Fri, 18 September 2009 09:31

As we are just starting out, we felt there was a need to establish the
fundamental models first <...snip/...> Idea being that the fundamental
models gets revised as more and more ideas and requirements are added.



+1 the more feedback we can get about the needs of people
using this software, the more relevant it will be.

--oh
Re: Packaging [message #571265 is a reply to message #486616] Fri, 18 September 2009 08:54 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2492
Registered: July 2009
Senior Member
From a b3 perspective this is not difficult to do - the model has more
expressive power than Buckminster when it comes to handling a mix of
platform specific and agnostic parts in one invocation.

The idea for b3 is also to make it easy to inject meta data
translation/actions in an aspect oriented way. In Buckminster a CSPEX is
required inside the component where additional actions are wanted, or a
new component type must be implemented. Using a CSPEX does not work when
it is not possible to place it inside the source for the component, and
the same action has to be repeated in all components where it is wanted.
Implementing a component type requires a lot more effort.

Instead, in b3 I want it to be possible to declare things like "All
features that match criteria X should have action Y"

For the second part of your idea - being able to install code packaged
as you suggest is outside the scope of b3 - but I don't see anything
that would prevent building the output as conveniently as Buckminster
produces an update site.

Regards
- henrik

Johannes Utzig wrote:
> Hi,
>
> I just found out about this proposal and it sounds very promising to me.
> Since this seems to be the place to throw in ideas, I'd like to throw in
> mine.
> For me, packaging is an important aspect of the build process. I
> personally like the simple 'unzip' paradigma of eclipse, but many users
> are more familiar with installers, package managers and similar
> concepts. Also some eclipse based products require a more sophisticated
> process than 'unzip' to properly function.
> From what I know, the EPP project is working on installers for Eclipse
> based products, and since this project is about simplifying software
> build and assembly, here is what I'd really love to see:
> The ability to create installers/packages for different operating
> systems as easy as it currently is to create an update-site with
> buckminster.
> Best would be if the actual (platform agnostic) data
> (plugins/features/...) would be in one file and the system specific
> installer (exe, deb, rpm,...) would be a separate file that fetches
> those bundles from the data file that match the platform it's executed on.
> This would safe a lot of disc space since you don't need every bundle in
> every platform combination and would make it easy to distribute a
> cross-platform eclipse product on a single CD for all platform
> combinations.
>
> Best regards,
> Johannes
Re: Packaging [message #571304 is a reply to message #486619] Fri, 18 September 2009 09:08 Go to previous message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Henrik,

yeah, it's clear that the 2nd Part is out-of-scope, I was just competing
my christmas wish list :)
But do you think it could be in-scope to somewhat join efforts with the
EPP team to make their work easily usable (out-of-the-box at best) from
within b3? That's how I understood the proposal at least:

"Bridging discontinuities between building and provisioning software.
Software developers are linked in an iterative chain of building and
provisioning, in which the output of a given build becomes an input in a
subsequent build. Today, the tools and processes of building and
provisioning are poorly integrated, resulting in broken hand-offs and
wasted effort across the cycle. Automating the connection between each
link in the chain will be a goal of this project"

Best regards,
Johannes

Henrik Lindberg schrieb:
> From a b3 perspective this is not difficult to do - the model has more
> expressive power than Buckminster when it comes to handling a mix of
> platform specific and agnostic parts in one invocation.
>
> The idea for b3 is also to make it easy to inject meta data
> translation/actions in an aspect oriented way. In Buckminster a CSPEX is
> required inside the component where additional actions are wanted, or a
> new component type must be implemented. Using a CSPEX does not work when
> it is not possible to place it inside the source for the component, and
> the same action has to be repeated in all components where it is wanted.
> Implementing a component type requires a lot more effort.
>
> Instead, in b3 I want it to be possible to declare things like "All
> features that match criteria X should have action Y"
>
> For the second part of your idea - being able to install code packaged
> as you suggest is outside the scope of b3 - but I don't see anything
> that would prevent building the output as conveniently as Buckminster
> produces an update site.
>
> Regards
> - henrik
>
> Johannes Utzig wrote:
>> Hi,
>>
>> I just found out about this proposal and it sounds very promising to me.
>> Since this seems to be the place to throw in ideas, I'd like to throw
>> in mine.
>> For me, packaging is an important aspect of the build process. I
>> personally like the simple 'unzip' paradigma of eclipse, but many
>> users are more familiar with installers, package managers and similar
>> concepts. Also some eclipse based products require a more
>> sophisticated process than 'unzip' to properly function.
>> From what I know, the EPP project is working on installers for
>> Eclipse based products, and since this project is about simplifying
>> software build and assembly, here is what I'd really love to see:
>> The ability to create installers/packages for different operating
>> systems as easy as it currently is to create an update-site with
>> buckminster.
>> Best would be if the actual (platform agnostic) data
>> (plugins/features/...) would be in one file and the system specific
>> installer (exe, deb, rpm,...) would be a separate file that fetches
>> those bundles from the data file that match the platform it's executed
>> on.
>> This would safe a lot of disc space since you don't need every bundle
>> in every platform combination and would make it easy to distribute a
>> cross-platform eclipse product on a single CD for all platform
>> combinations.
>>
>> Best regards,
>> Johannes
Re: Packaging [message #571343 is a reply to message #486624] Fri, 18 September 2009 09:31 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2492
Registered: July 2009
Senior Member
Johannes Utzig wrote:
> Hi Henrik,
>
> yeah, it's clear that the 2nd Part is out-of-scope, I was just competing
> my christmas wish list :)
> But do you think it could be in-scope to somewhat join efforts with the
> EPP team to make their work easily usable (out-of-the-box at best) from
> within b3?

Absolutely.

> That's how I understood the proposal at least:
>
> "Bridging discontinuities between building and provisioning software.
> Software developers are linked in an iterative chain of building and
> provisioning, in which the output of a given build becomes an input in a
> subsequent build. Today, the tools and processes of building and
> provisioning are poorly integrated, resulting in broken hand-offs and
> wasted effort across the cycle. Automating the connection between each
> link in the chain will be a goal of this project"
>
Yes, that is a goal.

As we are just starting out, we felt there was a need to establish the
fundamental models first, as it otherwise is difficult to have a
rational discussion about the "higher levels" (Do we have Actions? If
so, what are they? How do we know which build actions to apply to
different types of units? etc. etc.). Idea being that the fundamental
models gets revised as more and more ideas and requirements are added.

What else would you like for Christmas :) ?

- henrik

> Henrik Lindberg schrieb:
>> From a b3 perspective this is not difficult to do - the model has
>> more expressive power than Buckminster when it comes to handling a mix
>> of platform specific and agnostic parts in one invocation.
>>
>> The idea for b3 is also to make it easy to inject meta data
>> translation/actions in an aspect oriented way. In Buckminster a CSPEX
>> is required inside the component where additional actions are wanted,
>> or a new component type must be implemented. Using a CSPEX does not
>> work when it is not possible to place it inside the source for the
>> component, and the same action has to be repeated in all components
>> where it is wanted. Implementing a component type requires a lot more
>> effort.
>>
>> Instead, in b3 I want it to be possible to declare things like "All
>> features that match criteria X should have action Y"
>>
>> For the second part of your idea - being able to install code packaged
>> as you suggest is outside the scope of b3 - but I don't see anything
>> that would prevent building the output as conveniently as Buckminster
>> produces an update site.
>>
>> Regards
>> - henrik
>>
>> Johannes Utzig wrote:
Re: Packaging [message #571439 is a reply to message #486632] Fri, 18 September 2009 10:26 Go to previous message
Oisin Hurley is currently offline Oisin Hurley
Messages: 204
Registered: July 2009
Senior Member
Henrik Lindberg wrote on Fri, 18 September 2009 09:31
> As we are just starting out, we felt there was a need to establish the
> fundamental models first <...snip/...> Idea being that the fundamental
> models gets revised as more and more ideas and requirements are added.


+1 the more feedback we can get about the needs of people
using this software, the more relevant it will be.

--oh
Previous Topic:model reviews - as attachements?
Next Topic:advice in b3
Goto Forum:
  


Current Time: Sat Apr 19 11:44:00 EDT 2014

Powered by FUDForum. Page generated in 0.01869 seconds