Home » Archived » Buckminster » Recommended approach?
|
| Re: Recommended approach? [message #387947 is a reply to message #387938] |
Fri, 17 July 2009 16:57   |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Happy to hear that things have worked out well so far.
A general advice is to start by deciding on the granularity of your
components. What are the things you want to name, version and manage.
Next step is to think about where such a named component comes from
(built from source, in a repo, downloaded, generated by another
component, or they just exists in the filesystem somewhere, etc.)
You could treat every jar as a component - or you could treat a
collection of jars as a component. If you already handle jars as 'jar'
or 'maven' components, an alternative is to write a CSPEC for a feature
like component - this way you do not have to add CSPEX to the individual
jars - which may be difficult if they are 3d party jars.
If you are generating the components from some other build. You could
have a component that represents this build (a CSPEC) and use Generators
for the components it builds. The components it builds could have CSPECs
in them and use the buckminster component type.
When you have the component structure worked out - you should be able to
materialize the server setup as well.
When you want to materialize both the client and the server you need to
write an MSPEC - which directs the materializer to put things in
different locations (without it you get everything in one 'pile').
I hope that gives you some ideas...
- henrik
Roland Tepp wrote:
> Hi,
>
> We currently have our own build system for building a product that has a
> server part (JBoss) and a client (Eclipse RCP).
>
> The build process is currently such that firts the server
> libraries/modules are built first (by a regular ant build) and then
> special client versions of these libraries are copied to the plug-ins
> after which the plug-ins themselves are built using headless eclipse
> build into the end product.
>
> This is what we have and although it is far from optimal, it has served
> us ... more or less okay. However, as the software grows the overhead of
> maintaining and setting up the workspace is growing daily and we are at
> the point where setting up the new workspace is simply put unacceptably
> complex and almost unmaintainable by hand ...
>
> From what I understand, this is supposed to be (one of) the sweetspots
> of using Bucky, so I am on the quest of sreamlining the setup of the dev
> environment.
>
> So far I've managed to use buckminster to set up our target platform and
> check out all the plug-ins necessary for developing our RCP plug-ins
> (that is without server side modules). This was surprisingly simple and
> after few initial roadbumps I got everything materialized (big thanks to
> you, guys).
>
> Now the next step is to get the necessary server side and 3rd party
> libraries materialized as well...
>
> My question is - would anyone have a good suggestion how to proceed.
>
> My initial impulse would be to define these "library projects" as
> additional dependencies through CSPEX declarations (pity the editor for
> that is not as nice as for CSPEC)
>
> However I have a distinct feeling the the better way would be to
> reorganize this particular build proces to be a little more explicit
> about these dependencies, but I fail currently to see how to do achieve
> that. Maybe some sort of "virtual"
>
> My goal would be to get away from this manual copy phase (at least in
> the dev environment) and I wonder if maybe Buckminster can offer me some
> way of hadling this?
>
> I'm sorry if anything above does not make sense... I have really not
> enough experience building and managing comprehensive CI and build
> systems - just some vague idea that things could be much better...
>
|
|
|
| Re: Recommended approach? [message #467851 is a reply to message #387947] |
Mon, 03 August 2009 07:46 |
Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Hey Henrik,
Thanks for the reply. I was on a vacation (thank you, it was very nice
indeed ;) ) so I just got to read your reply.
I'll be giving my questions/comments below...
17.07.2009 19:57, Henrik Lindberg kirjutas:
> A general advice is to start by deciding on the granularity of your
> components. What are the things you want to name, version and manage.
I think that part has been sort of decided for a long time and it's a
kind of mess...
Maybe we can clean it up some... ;)
> Next step is to think about where such a named component comes from
> (built from source, in a repo, downloaded, generated by another
> component, or they just exists in the filesystem somewhere, etc.)
>
Everything we have - our own server side and eclipse projects and 3rd
party libraries - is kept in an SVN repository.
"Server side" projects are plain old java (eclipse) projects with their
own ANT build.xml files. Some of them build only one jar, some build
multiple jar files, and there are few jars that are built with source
from at least 2 projects.
I know it's a mess and that is partly why we want to move to a more
structured setup.
> You could treat every jar as a component - or you could treat a
> collection of jars as a component. If you already handle jars as 'jar'
> or 'maven' components, an alternative is to write a CSPEC for a feature
> like component - this way you do not have to add CSPEX to the individual
> jars - which may be difficult if they are 3d party jars.
>
Okay, I had to read this few times over to understand what you are
saying.... :)
So what you are saying is that I can specify a "component" for every jar
or a group of jars at will.
We have a sort of pseudo project in SVN repository that contains all the
3rd party library jar's that are being used in any of our
projects/plug'ins. Additionally we have recently gone osgi with some of
the 3rd party libraries and these are kept as well as projects of their
own in the SVN.
The OSGi'fied projects are a simple matter as they can easily be
referenced as osgi component types.
Now, the 3rd party jar files are a different matter.
As they are all kept in a separate pseudo-project in an svn repo, what
would be Your recommendation for these? Would I have to create a single
"lib" component for the SVN project containing required jar files or
specify separate CSPEC for each (set of?) jar files used in my plug-ins?
How do I specify multiple cspecs inside same folder or repository
location (one for each jar or set of jars)?
How do I make these jar files to be copied to their respective plug-ins?
> If you are generating the components from some other build. You could
> have a component that represents this build (a CSPEC) and use Generators
> for the components it builds. The components it builds could have CSPECs
> in them and use the buckminster component type.
>
Ouch ... that went right over my head ... :)
I can understand component for a build (that would be a java project),
but Generators is something I have no experience with (as of yet)...
> When you have the component structure worked out - you should be able to
> materialize the server setup as well.
> When you want to materialize both the client and the server you need to
> write an MSPEC - which directs the materializer to put things in
> different locations (without it you get everything in one 'pile').
>
> I hope that gives you some ideas...
Thank you, I think I can start making few small steps forward and I'll
aske some more as I make progress...
--
Roland
|
|
|
| Re: Recommended approach? [message #468080 is a reply to message #467851] |
Tue, 04 August 2009 01:36 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi Roland,
Sorry about the comments that went by in the stratosphere :)
Hard to know how much anyone has looked at Buckminster already.
When I responded, the Buckminster Book was starting to come together,
but some of the things I wanted to point out were not covered yet. They
are now - the current draft (0.5) is quite decent and explains most of
what I said.
I will dive in with some more details here...
Roland Tepp wrote:
> Hey Henrik,
>
> Thanks for the reply. I was on a vacation (thank you, it was very nice
> indeed ;) ) so I just got to read your reply.
>
Good - I spent summer writing the Bucky Book :) Which was fun...
> Everything we have - our own server side and eclipse projects and 3rd
> party libraries - is kept in an SVN repository.
>
ok - that works.
> "Server side" projects are plain old java (eclipse) projects with their
> own ANT build.xml files. Some of them build only one jar, some build
> multiple jar files, and there are few jars that are built with source
> from at least 2 projects.
>
> I know it's a mess and that is partly why we want to move to a more
> structured setup.
>
>> You could treat every jar as a component - or you could treat a
>> collection of jars as a component. If you already handle jars as 'jar'
>> or 'maven' components, an alternative is to write a CSPEC for a feature
>> like component - this way you do not have to add CSPEX to the individual
>> jars - which may be difficult if they are 3d party jars.
>>
> Okay, I had to read this few times over to understand what you are
> saying.... :)
>
> So what you are saying is that I can specify a "component" for every jar
> or a group of jars at will.
>
yes (more below).
> We have a sort of pseudo project in SVN repository that contains all the
> 3rd party library jar's that are being used in any of our
> projects/plug'ins. Additionally we have recently gone osgi with some of
> the 3rd party libraries and these are kept as well as projects of their
> own in the SVN.
>
> The OSGi'fied projects are a simple matter as they can easily be
> referenced as osgi component types.
>
yes, that is a good way of making them managed.
> Now, the 3rd party jar files are a different matter.
>
> As they are all kept in a separate pseudo-project in an svn repo, what
> would be Your recommendation for these? Would I have to create a single
> "lib" component for the SVN project containing required jar files or
> specify separate CSPEC for each (set of?) jar files used in my plug-ins?
>
I am thinking a "OurLib" which consists of all the jar files. The
simplest is that this is one component, and if there are dependencies
outside the set of jars in OurLib, then these dependencies are described
in this component. It is one component with one CSPEC. You just ignore
the dependencies between the jars. There is a compromise here between
amount of work, and amount of unused jars brought into projects.
> How do I specify multiple cspecs inside same folder or repository
> location (one for each jar or set of jars)?
>
One project = one component = one CSPEC.
A component has attributes - it can have one attribute per jar for
instance which makes it possible for other components to reference the
jars individually. An attribute can also be a group of other attributes,
so you can create arbitrary collections of "jars that go together".
So simplest possible representation of OurLib is that it has one
attribute which consists of all of the jar files. With a bit more work,
one attribute per jar, and one or several groupings that makes sense to
how they are consumed.
> How do I make these jar files to be copied to their respective plug-ins?
>
The other components simply reference "OurLib#someJar" to get that jar
file, or collection of jarfiles depending on what "someJar" represents.
a component can include this list of jars with other attributes from
other components and itself, and then invoke an action on such a set
(for instance make a copy, zip them up, etc.).
>> If you are generating the components from some other build. You could
>> have a component that represents this build (a CSPEC) and use Generators
>> for the components it builds. The components it builds could have CSPECs
>> in them and use the buckminster component type.
>>
> Ouch ... that went right over my head ... :)
>
Right now you have the jars in SVN. But say you had them in some legacy
CM system and a legacy build system needs to be executed in order for
the jars to be produced. You could handle this in your OurLib component
as something that is generated. There are two ways - an action can
produce more than one result - that is like calling a getter method that
in addition to returning the value also makes sure other properties
are up to date so their getters does not have to execute something. Or
you can generate attributes that represent components, by using
"Generators" (see below).
> I can understand component for a build (that would be a java project),
> but Generators is something I have no experience with (as of yet)...
>
Generators can be used in both cases (if jars are static in your SVN or
build by some other system/process). A Generated component is one that
is represented by an attribute (which can be an action) in its hosting
component. Such a generated component can have dependencies etc. but
there is naturally more work in setting this up.
Our standard example is that you have an UML model from which you
generate code. The model component is then typically set up to Generate
the component(s) (both physically (generating java code, a plugin etc.)
through some model action), and in meta data (through declarations in
the CSPEC). i.e. the generated component does not exist untill the model
component is used and is told to generate it. The act of generating it
can be hidden so there is only one place where this is triggered, and
the rest of the components that make use of the generated (java)
component(s) does not need to know this. This makes it easier to later
refactor the build (as you avoid a tangled web of actions to generate
things).
>
>> When you have the component structure worked out - you should be able to
>> materialize the server setup as well.
>> When you want to materialize both the client and the server you need to
>> write an MSPEC - which directs the materializer to put things in
>> different locations (without it you get everything in one 'pile').
>>
>> I hope that gives you some ideas...
>
> Thank you, I think I can start making few small steps forward and I'll
> aske some more as I make progress...
>
Take a look at the examples in the Buckminster Book. There is one that
is called "Hello XML world" that pulls in external jar files - one from
a download site, and one that was built separately. The mechanism used
there is the simplest possible while still making it somewhat interesting.
The CSPEC chapter covers attributes, actions, and generators, with
details in the reference section on available actors (the parts that
actually execute the actions - which can be written in ANT by the way,
so your existing ANT scripts can possibly be reused). You can also look
at how Buckminster handles the "plain" java component types (jars and
maven components) by default in the component type reference.
Hope that made some of the earlier comments easier to understand.
Regards
- henrik
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:52:35 GMT 2024
Powered by FUDForum. Page generated in 0.02735 seconds |
] 
Search
Help
Register
Login
Home
