Re: C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]

[Gilles Scokart]

According to me, you might enounter some issues when working with C/C++.

The major issue that I see is that ivy can handle any kind of dependencies
provided that the dependencies are files.  And the natural way of managing
dependencies in C++ is to use directories.

In C++ your compile dependencies are header files, while in java its jars.
Usually, you will have quiet a lot of header files. Probably too much to
list all of them in a dependency descriptor.

So, to work around the fact that ivy only manipulate dependnecies with file,
you will probably have to ter/zip/... when publish and untar/unzip/.. when
you are resolving dependencies.  This is feasible, but might be too heavy in
some case.

And by the way, one of the most popular issue in ivy is [1] Enable file
directory as artifact. 


[1] https://issues.apache.org/jira/browse/IVY-209


Gilles

2008/1/10, Dominique Devienne <[EMAIL PROTECTED]>:
>
> On Jan 10, 2008 11:26 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On Jan 10, 2008 6:13 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > First what I mean by language agnostic is that Ivy can handle any kind
> of
> > artifacts, and not only jars. So in your case you can easily declare
> that
> > your module publishes several artifacts, one being the jar, and the
> others
> > being platform specific zips. Then you can split your platform specific
> zips
> > in separate configurations (one by platform). This declaration goes in
> the
> > module ivy file in the repository. Then you can ask Ivy to resolve the
> > platform specific configuration you need depending on the platform you
> make
> > your build on. And once you get the zip on your local filesystem you can
> do
> > whatever you want with it like you did before, Ivy being used only for
> > provisioning.
>
> Yes, this gives me an idea about the process, thanks. I was expecting
> a bit more, in term of path assembling, as doing a transitive addition
> of all artifact dirs into a path is something that only a
> dependency-aware task can do well I think, but OTOH limiting yourself
> to doing only one thing well is always a good design decision in my
> book. I'll need to dig this more on my own now. --DD
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Gilles Scokart

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Gilles Scokart]

2008/1/10, Dominique Devienne <[EMAIL PROTECTED]>:
>
>
> it was successful enough to still be in use today more than 2 years
> after I'm gone, mostly untouched.
>
>
I think this is very usual.  Once a build system is ok, no-one want to take
the risk to change it, and often no-one can change it anymore.

This is why black magic should be avoided.  And this is why good
documentation techniques are required.

If you have ever maintained a generic build script written by someone else
you probably understand what I mean.

I think this is the major challenge in the build managment today.  And that
will be the challenge for such a project.

-- 
Gilles Scokart

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Gilles Scokart]

I never thought to overwrite macro to customize a generic build script.  Can
macro be overwritten?



2008/1/10, Wolfgang Häfelinger <[EMAIL PROTECTED]>:
>
> >> it is certainly something that already exists in the wild.  Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO  in The Hague. Ca. 90% of our Java
> projects are using AntEpoline, the remaining mainly Maven I.
>
> Here's how a typical build file looks like:
>
> 
>   
>
>   
> 
>   
>
>   
> 
>   
>   
>   
> 
>   
> 
>
>
-- 
Gilles Scokart

Re: AW: ProjectHelper : parsing from InputStream

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> <[EMAIL PROTECTED]> writes:
> 
> >> -Ursprüngliche Nachricht-
> >> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> >> The problem is a bit more complex than just
> allowing a different
> >> source.  The main problem are build files that do
> not specify a
> >> basedir attribute on the project tag since Ant
> then uses the directory
> >> holding the build file to resolve relative file
> references - which
> >> certainly doesn't work if it doesn't have a File
> reference pointing to
> >> the input.
> >
> >
> > Could the API require specifying the basedir?
> 
> It could.  Or instead require a ResourceFactory
> returning Resources
> that map to Files (like Matt suggests).
> 
> I really like the ResourceFactory idea but it can't
> be as generic as
> it sounds unless we change a lot of Ant tasks.
> 

True, I didn't think it through as far as you go
below.  :)

> Right now we need the basedir attribute to resolve
> relative file names
> for attribute setters that use the setFoo(File a)
> signature.
> 

Right, but all such _should_ be delegated to the
Project instance.  If not, sorry, can't help ya...

> If my build file doesn't contain any relative path
> at all, then there
> is no reason to set (or require) a basedir or a
> ResourceFactory at
> all.
> 

So would that be an error condition? 
IllegalStateException?

> If it does, then the resolved Resources must be
> Resources that can be
> turned into Files or I can't give the tasks what
> they are asking for.
> 
> The ResourceFactory approach would work great for
> setFoo(Resource a)
> attribute setters, but we don't haven them at all
> and we'd need to
> retrofit it into all existing tasks.
> 

One concept that I had discussed with someone here
(Kev?  Alexey?) was some kind of resource that would
deliver a tempfile for another resource.  This might
work in simple situations.  It also occurs to me that
certain resources might themselves implement
ResourceFactory, e.g. files and urls, which can pretty
easily return a relative file.  A buildfile specifying
no basedir would, IMHO, seem to be fairly well
represented by a FileResource that, as a
ResourceFactory, would resolve relative paths against
".".  So that might provide some opportunities as
well.

-Matt

> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Arrenbrecht]

On Jan 11, 2008 5:14 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Gilles Scokart" <[EMAIL PROTECTED]> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script.  
> > > Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD

That is correct. However, being able to do it still beats not being
able to. It allows for a better balancing of accommodating yet another
esoteric hook request and making the template yet more complex vs.
just telling someone to inline and tweak the template for their
esoteric case.

And being able to learn from looking at the imported script is also
very valuable.

But I think we understand each other, basically. ;)

-peo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

"Gilles Scokart" <[EMAIL PROTECTED]> writes:

> I never thought to overwrite macro to customize a generic build script.  Can
> macro be overwritten?

Sure, it's just another Ant task that has been defined.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Dominique Devienne]

On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Gilles Scokart" <[EMAIL PROTECTED]> writes:
>
> > I never thought to overwrite macro to customize a generic build script.  Can
> > macro be overwritten?
>
> Sure, it's just another Ant task that has been defined.

But my point is that most of the time, you never want to override
things (macros or target), but augment them with some kind of pre or
post processing. Peo's point of simply copy-pasting the "abstract"
build code to fully override the target duplicates that code, and
makes build maintenance all the more difficult. That's the well known
issue with code generator and code wizards when it's done in a one-of
way. Copy-pasting a target content shows failure of the generic build
to be flexible, and should be the exception rather than the rule, and
actually frowned upon IMHO. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Niamath Khan]

Please unsubscribe me from the following list.
 


- Original Message 
From: Peter Arrenbrecht <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Friday, January 11, 2008 10:40:40 AM
Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java 
projects

On Jan 11, 2008 5:14 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Gilles Scokart" <[EMAIL PROTECTED]> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script.  
> > > Can
> > > macro be overwritten?
> >
> > Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing. Peo's point of simply copy-pasting the "abstract"
> build code to fully override the target duplicates that code, and
> makes build maintenance all the more difficult. That's the well known
> issue with code generator and code wizards when it's done in a one-of
> way. Copy-pasting a target content shows failure of the generic build
> to be flexible, and should be the exception rather than the rule, and
> actually frowned upon IMHO. --DD

That is correct. However, being able to do it still beats not being
able to. It allows for a better balancing of accommodating yet another
esoteric hook request and making the template yet more complex vs.
just telling someone to inline and tweak the template for their
esoteric case.

And being able to learn from looking at the imported script is also
very valuable.

But I think we understand each other, basically. ;)

-peo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]