Home » Archived » B3 » bundle batch compile without eclipse
| |
| Re: bundle batch compile without eclipse [message #488763 is a reply to message #488717] |
Wed, 30 September 2009 07:55   |
 Laurent LE GOFF
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi Henrik,
Sorry, I don't know well what Buckminster do. I thought that Buckminster automate building, packaging and testing. I'm sure that it is a great tool.
We use BundleCreator in an integration environnement where we use OpenEmbedded to package a custom linux, where bundles contains jni driver to hardware and GWT Site webs.
Actually buckminster makes a lot of things but the XML declarative approach of it make it a bit hard to quickly approach from a basic user point of view in an heterogeneous environnment.
the advantage of BundleCreator is:
- it is small and do the job, just compile and package in jar without Eclipse, with just one command line:
* jre = 100MO (in my debian os) + ecj = 1.6MO + BundleCreator = 150Ko
* an administrator with no knowledge of eclipse and java can easily execute the tool (this was our first requirement).
- it is conform to OSGI spec but use special eclipse files like build.properties and .classpath.
- no svn, no resource mapping there's already good tool that do this job.
- can be easily introduce in a heterogeneous compilation environnement, C compile, jni shared library.
the main advantages of this tool is it's simplicity usage (as GNU tool does) and it's small footprint.
thanks 
Laurent
|
|
|
| Re: bundle batch compile without eclipse [message #488799 is a reply to message #488763] |
Wed, 30 September 2009 09:13 |
|
Hi Laurent,
Some comments on the advantages and some clarifications regarding Buckminster. Some of it may sound like negative
criticism but my intention is to understand more about your tool what it provides that we can use. So please bear with me.
On 09/30/2009 09:55 AM, Laurent LE GOFF wrote:
> ... Actually buckminster makes a lot
> of things but the XML declarative approach of it make it a bit hard to
> quickly approach from a basic user point of view in an heterogeneous
> environnment.
>
You should not need to be exposed to XML if your objective is to build bundles, features, and update sites with
Buckminster in a standard way. Every action that is performed is derived from the existing artifacts (manifest,
properties, classpath, feature.xml, etc.).
If you want to add things, like inject a code obfuscation or similar, then you will have to alter the generated model
which at present requires some XML skills since that is the format chosen for the model persistence. But for most cases,
you don't need that. Compiling, packaging, code-signing etc. is all automatic.
One objective with b3 is to leverage existing meta-data so that you don't need to maintain redundant information. There
should be no need for scripts as long as you don't do very special things.
> the advantage of BundleCreator is:
> - it is small and do the job, just compile and package in jar without
> Eclipse, with just one command line: * jre = 100MO (in my debian os) +
> ecj = 1.6MO + BundleCreator = 150Ko
How does your tool handle things like version qualifier replacement?
Will your tool use the PDE compiler so that you get warnings and errors from erroneous declarations in manifests,
build.properties, etc.)?
Will your tool consider other builders that are declared in the .properties file of a plug-in project?
With b3, we would like to build the project headlessly in the exact same way that it is built from within your IDE. So
any technology that is introduced must work for both scenarios. This is one of the key advantages with Buckminster b.t.w.
> * an administrator with no knowledge of eclipse and java can easily
> execute the tool (this was our first requirement).
b3 should be no different. Executing a build must be very simple.
> - it is conform to OSGI spec but use special eclipse files like
> build.properties and .classpath.
In b3, we plan to have meta-data extractors that, among other things, can make sense of an OSGi bundle (through it's
manifest, properties, classpath, etc.). Since b3 in itself will be built on OSGi technology, it can be extended with new
commands and new intelligent recognition of existing meta-data.
What kind of extensions are possible with your tool and what extension framework is used?
> - no svn, no resource mapping there's already good tool that do this job.
What other tool would you use in combination with your tool to make sense of the dependencies that are declared in
features and map them against svn repositories, p2 repositories, etc.? How can those tools share this information with
your tool?
> - can be easily introduce in a heterogeneous compilation environnement,
> C compile, jni shared library.
b3 will enable this in two ways:
a) by introducing new meta-data extractors for environments that are not readily recognized and thus make such
environments part of the overall build model.
b) it can be used it as a separate tool in for instance an ant-script or a makefile.
I.e. it's either the build orchestrator or used as part of something bigger.
What support does your tool add in this area? Do you provide ant-tasks or similar?
Regards,
Thomas Hallgren
|
|
|
| Re: bundle batch compile without eclipse [message #579834 is a reply to message #488717] |
Wed, 30 September 2009 07:55 |
Laurent LE GOFF
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi Henrik,
Sorry, I don't know well what Buckminster do. I thought that Buckminster automate building, packaging and testing. I'm sure that it is a great tool.
We use BundleCreator in an integration environnement where we use OpenEmbedded to package a custom linux, where bundles contains jni driver to hardware and GWT Site webs.
Actually buckminster makes a lot of things but the XML declarative approach of it make it a bit hard to quickly approach from a basic user point of view in an heterogeneous environnment.
the advantage of BundleCreator is:
- it is small and do the job, just compile and package in jar without Eclipse, with just one command line:
* jre = 100MO (in my debian os) + ecj = 1.6MO + BundleCreator = 150Ko
* an administrator with no knowledge of eclipse and java can easily execute the tool (this was our first requirement).
- it is conform to OSGI spec but use special eclipse files like build.properties and .classpath.
- no svn, no resource mapping there's already good tool that do this job.
- can be easily introduce in a heterogeneous compilation environnement, C compile, jni shared library.
the main advantages of this tool is it's simplicity usage (as GNU tool does) and it's small footprint.
thanks :)
Laurent
|
|
|
| Re: bundle batch compile without eclipse [message #579851 is a reply to message #579834] |
Wed, 30 September 2009 09:13 |
|
Hi Laurent,
Some comments on the advantages and some clarifications regarding Buckminster. Some of it may sound like negative
criticism but my intention is to understand more about your tool what it provides that we can use. So please bear with me.
On 09/30/2009 09:55 AM, Laurent LE GOFF wrote:
> ... Actually buckminster makes a lot
> of things but the XML declarative approach of it make it a bit hard to
> quickly approach from a basic user point of view in an heterogeneous
> environnment.
>
You should not need to be exposed to XML if your objective is to build bundles, features, and update sites with
Buckminster in a standard way. Every action that is performed is derived from the existing artifacts (manifest,
properties, classpath, feature.xml, etc.).
If you want to add things, like inject a code obfuscation or similar, then you will have to alter the generated model
which at present requires some XML skills since that is the format chosen for the model persistence. But for most cases,
you don't need that. Compiling, packaging, code-signing etc. is all automatic.
One objective with b3 is to leverage existing meta-data so that you don't need to maintain redundant information. There
should be no need for scripts as long as you don't do very special things.
> the advantage of BundleCreator is:
> - it is small and do the job, just compile and package in jar without
> Eclipse, with just one command line: * jre = 100MO (in my debian os) +
> ecj = 1.6MO + BundleCreator = 150Ko
How does your tool handle things like version qualifier replacement?
Will your tool use the PDE compiler so that you get warnings and errors from erroneous declarations in manifests,
build.properties, etc.)?
Will your tool consider other builders that are declared in the .properties file of a plug-in project?
With b3, we would like to build the project headlessly in the exact same way that it is built from within your IDE. So
any technology that is introduced must work for both scenarios. This is one of the key advantages with Buckminster b.t.w.
> * an administrator with no knowledge of eclipse and java can easily
> execute the tool (this was our first requirement).
b3 should be no different. Executing a build must be very simple.
> - it is conform to OSGI spec but use special eclipse files like
> build.properties and .classpath.
In b3, we plan to have meta-data extractors that, among other things, can make sense of an OSGi bundle (through it's
manifest, properties, classpath, etc.). Since b3 in itself will be built on OSGi technology, it can be extended with new
commands and new intelligent recognition of existing meta-data.
What kind of extensions are possible with your tool and what extension framework is used?
> - no svn, no resource mapping there's already good tool that do this job.
What other tool would you use in combination with your tool to make sense of the dependencies that are declared in
features and map them against svn repositories, p2 repositories, etc.? How can those tools share this information with
your tool?
> - can be easily introduce in a heterogeneous compilation environnement,
> C compile, jni shared library.
b3 will enable this in two ways:
a) by introducing new meta-data extractors for environments that are not readily recognized and thus make such
environments part of the overall build model.
b) it can be used it as a separate tool in for instance an ant-script or a makefile.
I.e. it's either the build orchestrator or used as part of something bigger.
What support does your tool add in this area? Do you provide ant-tasks or similar?
Regards,
Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Tue Apr 16 11:00:02 GMT 2024
Powered by FUDForum. Page generated in 0.70835 seconds |
] 
Search
Help
Register
Login
Home
I just write a short message for now
