Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[buckminster-dev] Re: Buckminster Build Process : Some Questions

Thanks Ken :-)

"ken1 (Kenneth Ölwing)" <kenneth@xxxxxxxxx> wrote in message 
news:ebemi1$adl$1@xxxxxxxxxxxxxxxxx...
> Hi,
>
>> As you know, automated build conforms serveral actions / stages. I would 
>> like to know the followings with respect to the buckminster :
>>
>>    1.Is it possilbe to create a site as as result of build process like 
>> in Maven creates ?
>
> I'm guessing that with 'site' you refer to a web site with code 
> information etc...?

        Yes Ken.
>
> No, that kind of functionality is presently out of Buckminsters scope. 
> Buckminster focuses on materialization and building.
>
> As to 'possible' it still is of course. There's no reason Buckminster 
> can't provide the core functionality of materialization/build and that 
> 'actions' in components provides whatever type of support you'd want in 
> that direction. Or, build Eclipse plugin(s) and talk directly to 
> Buckminster API's.
>
>>    2.How it handles the JUnit tests ? Is it possible to produce a test 
>> report in HTML format ?
>
> It handles JUnit tests just fine, like any other Eclipse plugin. It's 
> important to remember that you *are* fully working inside Eclipse and thus 
> can reap all the benefits of it, including JUnit support.
>
>>    3.Is buckminster needs a central repository for dependencies ? or 
>> dependencies can be picked up from any location or filesystem
>>       paths ?
>
> In principle, yes - Buckminster can pick up dependencies from any 
> location. This is where the 'rmap' comes in; this is where you define the 
> mapping between 'this component name can be found in various formats in 
> these locations'. So, you might say that 'Buckminster needs a 
> repository' - but that is a flexible concept.
>
> The crucial point pertinent to your question is the generic use of 
> 'location'. We don't want to prescribe a certain format for a repository. 
> Instead Buckminster contains a generic framework in which normal Eclipse 
> plugins can be used to implement extension points that helps Buckminster 
> understand a specific repository (they can, as you know be extremely 
> different from one another). There's a bunch of repository providers 
> already - CVS, Subversion, Perforce, any URL-based location (including 
> Maven repositories).
>
> You might also want to look into the discussion on 'cspec' - this is the 
> internal format that Buckminster uses to 'understand' a component, but 
> again Buckminster doesn't prescribe that you actually must have a concrete 
> one. Instead, for example, the above mentioned Maven provider understands 
> POM's and can on-the-fly translate them to cspec's.
>
>>    4.After build process is finished, and I want to deploy these recently 
>> produced artifacts to remote server (HTTP or FTP), is there
>>      some standard functionality available as a part of Buckminster, 
>> which can handle this ?
>
> No, as we try to hold the core Buckminster functionality as general as 
> possible, this is not in scope. The details of how to deploy, the type of 
> the servers etc can be very different from user to user so this is best 
> left to the individual user/team/company/whatever.
>
> Actually, there are two different issues here: one is actual 'deployment' 
> (i.e. making the application ready to run, which I presume is what you're 
> after since you use 'deploy').

 No Ken, it was a wrong term used by me, it is basically upload as you have 
mentioned below.

>
> A similar issue is 'upload a component in a processed format to a 
> repository for later use in materializations'. This is about the scenario 
> where you wish to persist a binary form of a component you extracted in 
> source from, say, a Subversion repository.
>
>>    5.Is it possible to hook my own eclipse plugin into buckminster build 
>> process ? Like in Maven, you can write a plugin and call that to
>>       peform desired action ?
>
> Yes, most definitively. Pick your choice - the first level is simply to 
> make use of the (currently being implemented) Actors, essentially boiling 
> down to standard scripting in, say, Ant or Make. Just declare an action 
> and describe which Actor implementation that should be used for that 
> action and when the dependencies require the action to be run, it will be 
> executed.
>
> The second level is to actually create your own Actor, say if you want to 
> have much finer control of what should happen or need more information 
> from Buckminster/Eclipse API - or just want to support some other form of 
> scripting, perhaps another make utility. It's just an Eclipse extension 
> point, so it's easy to hook in an implementation.
>
> Or, in answer to your specific question - implement an Ant task or 
> something else that can be called from the used Actor.
>
>>    6.Is buckminster is able to pull artifacts from Maven 2 repositories ?
>>
>
> I'm unsure of where we stand with this at the moment, but I don't think we 
> have implemented that support yet.
>
>>     My aploligies if I have asked stupid questions!
>
> No need to apologize for asking questions! (and relevant ones, too :-)
>
>>
>>     Thanks for you help!
>>
>
> You're welcome. As you can perhaps see, there are some relevance to 
> comparing Buckminster/Eclipse and Maven (which I assume is what you're 
> doing), but there is not a direct one-to-one mapping.
>
> HTH,
>
> ken1
> 




Back to the top