Home » Archived » B3 » Packaging
| Packaging [message #486616] |
Fri, 18 September 2009 12:30  |
 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 12:54  |
Henrik Lindberg
Messages: 2509
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 13:08 |
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 13:31 |
Henrik Lindberg
Messages: 2509
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 #571265 is a reply to message #486616] |
Fri, 18 September 2009 12:54 |
Henrik Lindberg
Messages: 2509
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 13:08 |
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 13:31 |
Henrik Lindberg
Messages: 2509
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:
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 22:10:12 GMT 2024
Powered by FUDForum. Page generated in 0.03753 seconds |
] 
Search
Help
Register
Login
Home
