Turning off old vmbuild.apache.org in 24 hours

[Brett Porter]

Hi,

While the Ant nightlies haven't been moved yet, I believe Antoine is  
working on it. All of the content that exists on the existing machine  
resides on the new one so nothing will be lost when the old server is  
turned off.


We're planning to do that in 24 hours, so this might mean you are  
without nightlies for a period until the new ones are set up. Any  
issues?


Thanks,
Brett

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

Re: Last chance: vmbuild migration & ant nightlies

[Brett Porter]

Hi Matt,

No, not too late. Sorry, I've been a bit slow getting things wrapped  
up here.


Are you able to migrate the content across if I give you access to  
the new box? I assume you just want the same set up.


Alternatively, you might consider whether it's worth having an  
individual zone you can self administer instead.


Cheers,
Brett

On 08/08/2007, at 2:16 AM, Matt Benson wrote:


Brett:

Am I too late in speaking up for the group?  AFAIK we
do want our nightly builds to continue; at least *I*
do.

-Matt

--- Brett Porter <[EMAIL PROTECTED]> wrote:


Hi Antoine, all,

A reminder from my earlier mail...

Currently, it appears that Ant is running nightly
builds on vmbuild,
which is being migrated to a new (better) machine.
Is this process
still needed, or does anything else from ~antoine
need to be
recovered before the old instance is turned off?

Thanks,
Brett



-

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







__ 
__
Building a website is a piece of cake. Yahoo! Small Business gives  
you all the tools to get online.

http://smallbusiness.yahoo.com/webhosting


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

Last chance: vmbuild migration & ant nightlies

[Brett Porter]

Hi Antoine, all,

A reminder from my earlier mail...

Currently, it appears that Ant is running nightly builds on vmbuild,  
which is being migrated to a new (better) machine. Is this process  
still needed, or does anything else from ~antoine need to be  
recovered before the old instance is turned off?


Thanks,
Brett

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

Re: Ant and vmbuild (was: Commons Math, Commons Nightlies, vmbuild)

[Brett Porter]

Hi,


From commons-dev:


On 14/07/07, Phil Steitz <[EMAIL PROTECTED]> wrote:

I think Ant may be using something like our nightly script on vmbuild.
 Might be good to give them heads up on moving vmbuild.


Is Ant impacted if we move the current vmbuild server, or are you just
using a copy of the commons script elsewhere (or is this something
completely different, like vmgump)?

Thanks,
Brett

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

Re: OT - Maven woes

[Brett Porter]

Instead of the manifest entries (which you are filtering from your own
manifest file), you can use the  configuration to the
JAR plugin (or do both).

http://maven.apache.org/guides/mini/guide-manifest.html

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

Hi Brett,

Thanks for taking the time to trouble-shoot this - I *really*
appreciate all the help so far.

I've fixed the missing resource problem, but the Manifest file is
still not being updated in the jar file.

I have a Manifest.mf file in my src/main/resources dir, it is being
updated with the build time correctly (and put in
target/classes/META-INF.  I now want this to be used in the jar
plugin:


org.apache.maven.plugins
maven-jar-plugin



 - 
${build.time}






jar





The jar plugin is simply creating a default manifest file and ignoring
the resources file.  What I really want is the src/main/resources
Manifest.mf to be appended to the end of the auto-generated
Manifest.mf

Kev

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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

Re: OT - Maven woes

[Brett Porter]

I was able to add test resources without changing the POM and they
were correctly copied (unfiltered). Do you have a 
element in the POM that might be interfering with it?

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

> > Sorry, but I'm not sure I can help much more as that's inside the
> > custom test cases.
> >

Hi, sorry to bother you again,

The problem is related to a single image in the src/test/resources
directory.  When I use filters, it seems that this file is no longer
copied to the correct location for when surefire runs the unit tests.

My guess is that I need to specify a  block in the pom
which includes graphics files (.png)

Kev

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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

Re: OT - Maven woes

[Brett Porter]

Did you run a clean after the change to make sure the bogus filtered
resources got copied again properly?

Sorry, but I'm not sure I can help much more as that's inside the
custom test cases.

- Brett

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

> The example basically does "copy everything from src/main/resources
> with filters". I assume you have images in there too.

No, I just checked, it's a common library that is re-used for
different web-apps, but it doensn't contain any images, but then with
the filtering switched on, all the images based tests break.

>
> You should setup a separate resource directory for filtering - maybe
> replace the one in the example with src/main/filtered-resources. Or,
> you can add an includes or excludes to the one in the example.
>

ok, I did as suggested and added a src/main/filter-resources dir and
modified the pom, I'm now getting NullPointerException (s), something
fishy is definately happening with filters/resources:

---
Battery: com.seanergie.entities.ColorTest
---
Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 0.016 sec

class org.apache.maven.surefire.battery.JUnitBattery.testAverage()
Time elapsed: 0 sec  <<< FAILURE!

[ stdout ] ---



[ stderr ] ---



[ stacktrace ] ---

java.lang.NullPointerException
at org.apache.commons.io.IOUtils.copy(IOUtils.java:996)
at org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:217)
at com.seanergie.persistence.File.getDefaultIcon(File.java:325)
at 
com.seanergie.persistence.ImageFileTest.constructTestImageFile(ImageFileTest.java:18)
at com.seanergie.entities.ColorTest.testAverage(ColorTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.battery.AbstractBattery.executeTestMethod(AbstractBattery.java:124)
at 
org.apache.maven.surefire.battery.AbstractBattery.executeTestMethods(AbstractBattery.java:70)
at 
org.apache.maven.surefire.battery.AbstractBattery.execute(AbstractBattery.java:49)
at 
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:220)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)

> It's 4pm here (Sydney, Australia).
>
Ok, I'm not keeping you up at some ridiculous hour

Kev

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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

Re: OT - Maven woes

[Brett Porter]

The example basically does "copy everything from src/main/resources
with filters". I assume you have images in there too.

You should setup a separate resource directory for filtering - maybe
replace the one in the example with src/main/filtered-resources. Or,
you can add an includes or excludes to the one in the example.

It's 4pm here (Sydney, Australia).

- Brett

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Here's a working example: http://jira.codehaus.org/browse/MNG-2561

Hi, thanks for the cookbook example.

My problem now is that if I use filtering, I get exceptions thrown
during testing, these exceptions aren't thrown if I remove the
filter/resources sections from my pom.  Is this a known issue?  Is
there anything I have to do to get my tests to pass without throwing
exceptions?

some output:

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
java.util.zip.ZipException: oversubscribed literal/length tree
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.
java:1165)
at com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader
.java:1276)
at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.j
ava:1362)
at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1
579)
at javax.imageio.ImageIO.read(ImageIO.java:1400)
at javax.imageio.ImageIO.read(ImageIO.java:1322)
at com.seanergie.persistence.ImageFile.initSizes(ImageFile.java:101)
at com.seanergie.persistence.ImageFile.(ImageFile.java:63)
at com.seanergie.persistence.ImageFileTest.constructTestImageFile(ImageF
ileTest.java:18)

As I said, if I remove the resources/filters from the pom, the tests
pass, so there's something fishy going on when maven uses filters.

Thanks for your help so far (btw what time is it for you?)

Kev

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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

Re: OT - Maven woes

[Brett Porter]

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

And with the antrun plugin, ok I can get  to generate the
value I'm after, and I can use copy/replace to filter it into the
file, but what phase/goal do I need to set so that ant will execute
before the jar file is built?  I thought process-classes as
process-resources seems to occur before compilation.


Anything before 'package' is fine, with process-resources being the
most sensible. Just as long as you aren't overwriting it again with
the resources plugin itself.

Your best bet is probably to generate a filter.properties in the
"generate-resources" phase that has the value, then use the filtering
you had configured to copy the resource itself.

Here's a working example: http://jira.codehaus.org/browse/MNG-2561

- Brett

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

Re: OT - Maven woes

[Brett Porter]

On 15/09/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:

How the hell did anyone convince anyone else to use this crap?!


Well, since you asked so nicely... :)


I'm truly at my wit's end regarding such a simple task, here is what I
currently have in my pom.xml:


If you use ant tasks, you can only use them with other ant tasks. The
ant properties are not fed back into the Maven build by the antrun
plugin.

So, you'll need to filter it into the file using your own  task.


I know some of the maven devs lurk here (from time to time), if any of
them could shed some light on this.


You'll likely get more help on [EMAIL PROTECTED]



Do I have to write a  plugin (mojo?) for this?


That's another option.



This has to be the second most frustrating piece of software I've
encountered - right after Oracle.


Well now, that comparison is just mean! :)

- Brett

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

Re: .cvsignore ===> .svnignore

[Brett Porter]

.svnignore doesn't do anything. The svn:ignore properties would have
been populated from .cvsignore when the repository was first
converted, but after that those files can be removed.

To edit the property, use:

svn propedit svn:ignore .

Then commit that change.

Cheers,
Brett

On 23/06/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

I have renamed all the .cvsignore into .svnignore and committed my
change. Did not get prompted for a commit message.
The question is also :

in lib/optional, the file .svn/dir-prop-base did not change.

$ cat dir-prop-base
K 10
svn:ignore
V 19
jdepend*.jar
s*.jar
END

So most of my optional jars are listed when I do a svn status, except
jdepend.

Does one have to run an administrative command to update the directory
properties, or do they have to be updated by hand separately ?

Regards,
Antoine

[EMAIL PROTECTED] wrote:
>> Should we rename the .cvsignore files to .svnignore ?
>>
>> Or are we supposed to enter a line in
>> .$HOME/.subversion/config to say we want to use .cvsignore instead ?
>>
>
>
> I would go the "clean svn way". If using a .cvsignore and a redirect is
> often used (and not only for historical reasons) we can do that.
> But I think having a clean-svn-way (.svnignore or whatever) is much more
> clearer. We dont have cvs any more.
>
>
> Jan
>
>


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





--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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

Re: suggestion refactor SCM

[Brett Porter]

On 9/29/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> Just a worry about dependencies.  If Ant has to rely on other code
> from within maven for a set of maven plugins to run, we end up with a
> horrible interdependency (Maven needs Ant <-> Ant needs some % of
> Maven) just to compile ant.  Could get nasty.  But I agree if the
> work is there and the code can be taken and made common between
> projects, why not?

Mavne, in general, doesn't need ant. Of course, ant tasks in this code
would require ant, but if they are here I assumed they would be an
antlib, not a part of the ant build.

> (When you first replied Brett, I checked out the source in svn web
> thingy and I saw a fair bit of codehaus imports - I personally don't
> have any good experience (as a user) of anything from codehaus so I'm
> wary of that code, but you obviously have a more in depth view)

The main part should only require plexus-utils, which we are trying to
migrate to unify under commons-exec and commons-io.

> My thoughts were that in the future you'd download a base-ant, and
> then depending on the SCM you use you'd download the scm-provider-
> ant.jar
>
> eg
>
> base-ant1.8.jar + svn-ant.jar
>
> Each antlib is going to be tiny compared to the amount you have to
> download for all SCM functionality that we currently have (I'm still
> on dial-up here so download speed and size of code is important to
> me :) )

All the providers together aren't that large, though you do need the
option to add other providers later.

> The hard part is defining a consistent interface which is applicable
> to all SCM systems, without dropping down to lowest common denominator.

Yep, we've held some discussions around this and there is still some
work to do to get to a good common api. Other things particular to an
SCM should then be exposed by extensions.

- Brett

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

Re: suggestion refactor SCM

[Brett Porter]

I'd also agree with that. We fully intended to make Maven2 plugins
work as Ant tasks :)

So with a wrapper,
http://maven.apache.org/maven2/scm/maven-scm-plugin/
these goals would become tasks and their parameters would match up
what's on the individual pages.

Thoughts?

- Brett

On 9/29/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote:
> > > From: Steve Loughran [mailto:[EMAIL PROTECTED]
> > >
> > > Jose Alberto Fernandez wrote:
> > > > But here we seem to be talking about a new family of generic tasks,
> > > > If this works well, we could deprecate the old tasks and eventually
> > in a
> > > > couple of versions remove them.
> > > >
> > > > Jose Alberto
> > >
> > > generic is good, provided
> > >   -we can have a conceptual model that is consistent across all SCM
> > > systems.
> > >   -we can deal with extensibility through antlibs. I suppose  you'd
> > have
> > > a new type,
> > >SCMbackend that every backend would implement; declaring a new
> > > backend would
> > >let you register it.
> > >
> > > Question: could you just get away with some mixin import lib that
> > > declared the appropriate macros for the appropriate platform?
> > >
> >
> > Well, it seems that the maven people have such a thing to some extend
> > already. This new antlib tasks could use that support.
> >
> > Hey, maybe maven-scm could host and provide the antlib for these tasks.
> > Or maybe they are willing to move it to our sandbox.
> > I still think, it will be a good idea if we continue to get involved to
> > help define the overall picture from the ANT perspective.
>
> With my Maven SCM Committer hat on I would not object to hosting the Ant
> tasks under Maven SCM if that's what you guys feel is right. Your call
> but I'm +1 to having them under Maven SCM.
>
> > At the end of the day we would have to decide if we would like to
> > provide these libraries as part of our release, provide some 3rd party
> > goodies that you can download as part of ANT, or just tell people about
> > their existence somewhere.
>
> --
> Trygve
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: suggestion refactor SCM

[Brett Porter]

On 9/27/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> d - none of the above

I know you are talking about an interface at the Ant task level, but I
should also point out that this was one of the things I was referring
to offering up Antlibs for if there was interest.

http://svn.apache.org/viewcvs.cgi/maven/scm/trunk/maven-scm-api/
http://svn.apache.org/viewcvs.cgi/maven/scm/trunk/maven-scm-providers/
(we don't currently have one for darcs...)

Cheers,
Brett

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

Re: Maven and Ant collaboration on task codebase

[Brett Porter]

On 9/21/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> yes, we can discuss it :)
> 
> I do actually agree that execution and JAR files ought to be structured
> so that they can be reused. The code in there is some of the best
> debugged stuff out there in Java for doing both.

Ok - good that we agree on the fundamental point :)

> But I dont want to break ant or make Ant1.7 slip in the process; and we
> cannot change the public interfaces for all the existing classes.

Right. That was the first point I listed about backwards compat, and
your facade plan would allow that. This in a beyond-Ant-1.7 timeframe
sounds fine by me too - I would expect the time taken to get the
refactoring happening, tests done, library documented would exceed
that anyway. And hopefully there will be people outside of Ant willing
to contribute to the effort.

> which leaves a design like
> 
> -move execution, Jar support self contained packages in the ant codebase
> -provide self contained API with unit tests for that functionality.
> -retain the existing stuff as facades

yep.

> -release a separate ant-execution library, at exactly the same frequency
> as ant point releases.

I'm not sure that this is required. Surely an Ant release can just use
the last release of that library, whenever and whatever that was. If
there is a real need to get a certain fix or feature in, then driving
the release of that library before Ant needs to happen. This isn't
cumbersome if the development of the library is set up to allow
frequent releases (ie, a stable branch all the reliable fixes and
improvements go onto).

> The latter is going to be problematic, and here's why. If there is one
> thing that always causes grief in Ant, its JAR files sticking other Jars
> inside. Groovy, jython, maven-artifact-ant-2.0-beta-1-dep; all
> incorporate other things like regexp, jsch, whatever into their JAR,
> creating lots of classpath conflict. If we integrate execution into ant,
> either within ant.jar or as an associated JAR, we cannot make it
> possible for someone to stick an inconsistent version in, -or at least
> we cannot make it possible for someone like me to ship a 3rd party ant
> task that also includes an updated version of the libraries.

Ok, I did fix your main gripes in the artifact ant tasks for b1 :) No
libraries other than Maven ones and plexus (these need to change too
eventually, but they don't have many 3rd party users right now, and
none that are writing ant tasks).

Anyway, this was my 3rd point in the original email. It is an issue,
but it can be resolved by incorporating that code in a different
package structure. This should be a relatively simple task:
- get release being used from svn (externals?)
- copy sources into ant source tree/temp source directory, mapping
paths from o/a/commons/exec -> o/a/tools/ant/exec
- replace package statement in source files

It is a bit gruesome, but it does work.

What are the alternatives to this? You can keep the source in the Ant
tree, but you still need to do the package munging in reverse:
- keep the above layout, but build "ant-exec" library from the source
tree after copying and adjusting the packages to something different
from what Ant uses
- build the "ant-exec" library separately, after ant is built, based
on those sources. This would tie the exec library release to the Ant
release.

To me, moving the code to commons (or similar subspace of the ant SVN
tree), with its own release cycle and incorporating it back into the
Ant bootstrap rather than the other seems the more natural option.
We're faced with a similar problem in Maven 2 and that is the approach
we plan to take. In fact, since this will be a standalone Java app, we
could probably share it.

Is this feasible, or am I missing something?

Cheers,
Brett

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

Maven and Ant collaboration on task codebase

[Brett Porter]

Hi,

I'm basically looking for some opportunities for sibling Apache
communities to work together in an area we have some overlap, and
wanted to see what thoughts the Ant community had on this. I've
invited folks on the Maven lists to follow this thread here too, so if
you see some strange faces - that might be it.

This has been discussed before here briefly by myself and Vincent
Massol, and is also inspired by the original Ant2 proposal by Peter
Donald which he has reviewed recently:
http://blogs.codehaus.org/people/vmassol/archives/001036_id_love_reusable_ant_tasks.html
http://codemyth.blogspot.com/2005/09/no-shared-vision-no-ant2.html

I'm not asking to revisit something that has already failed, BTW, but
am looking for a best path forward.

Maven is finding ourselves in the position now of wanting to reuse a
lot of the Ant task code. Some that particularly spring to mind:
- Exec
- compiler tasks
- archiving (jar, zip, tar)

We're not the first to have encountered this: other projects have
forked this code before. Eventually, the archiving tasks found their
way to jakarta commons-compress, and I've recently started
commons-exec with others to try and build reusable code from the Exec
tasks. commons-jci exists which came from Cocoon and could potentially
be merged with the Ant code for javac. There are others like
commons-io that share much code with Ant. At this point, I'm hoping to
start fleshing them out and using them instead of our own forked
versions (that mostly came via Avalon and have since permuted).

On the flip side, Maven has a number new tasks we are building that
could be used in Ant. We've already done so for dependency management,
but we have libraries for SCM (support for CVS, SVN, Clearcase,
Perforce and Starteam and IIUC it goes beyond the support provided by
Ant), Wagon (scp/sftp/http/ftp/file/scm transport through a common
API) and we are also planning others, like a generic issue tracking
interface library.
Probably most notable would be the various reports like the SCM change
logs, release notes, and so on.

Then there are others we have started together (and not progressed
much yet): commons-openpgp.

I think there is a definite need for these libraries to be separate
from Ant so that they can be used in other places where Ant is not
available. I know you can use Ant via the Java API, but Vincent
illustrates that it can be a bit verbose, and you end up with a rather
large dependency full of unneeded tasks and bindings to the Ant
project. These are still
options under Maven though, BTW - there are several ways to use Ant
"as is" if that is the best solution for the person in question.

My main concern is that with all these libraries, that the refactoring
may not be used in Ant, which means that should Ant expand or fix bugs
in its code, that is not propagated to the code others are using.

So, my question is - what is the road map for Ant 1.8 (possibly 1.7)
and beyond? It seems antlibs is becoming the way to extend Ant - is it
possible that more of the task code may be moved into that? If so, is
it possible that task code may be decoupled from Ant, or a smaller set
of types might be established? For example, Maven2 plugins can run
without
dependencies (like in ant, by reflecting execute), but also has a 5K
library with an implementable interface and logging provision. I
understand some tasks may require the basic fileset/path/etc support -
could they be made into a smaller API to allow better separation of
the antlibs?

Does the practice of creating commons libs like we have been doing
work for Ant, and would you accept patches to integrate them back into
Ant? I think this is the best first step, but see a few issues:
- backwards compatibility: Probably fine for the task usage, but I'm
not sure of the public API of the tasks may already be in use in java
code that could be affected by this
- JDK requirement: we've typically moved to support a minimum of 1.3
and sometimes 1.4
- JAR hell: harder to bootstrap Ant given dependencies that probably
need Ant to build (we encounter the same issue with Maven), and don't
want to get into issues of someone using different versions of the
libraries in their own tasks if it conflicts with Ant. Should be
easily
overcome by repackaging/recompiling the sources of the commons
libraries with a new package for the main Ant distributable (which
brings it back to the current solution at runtime, but allows more
flexibility for those that use the code aside of Ant).

Of course, if it is not seen as beneficial to Ant in any way, then I'm
happy to continue building up the common libraries as we've started,
and run the risk of having to fix similar bugs. The stability of the
Ant code base suggests this risk is quite low.

What benefits are there for Ant? A warm fuzzy feeling?  :)  As I
mentioned, I hope that Maven will produce more plugins that are useful
from Ant. We also have a growing and active community that code at
Apache (and those that build plug

Re: Updates to the Maven Artifact Ant tasks

[Brett Porter]

On 6/8/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Is settings.xml documented anywhere?

http://maven.apache.org/maven2/maven-settings/settings.html

> 
> I just found last week where java1.5 puts its proxy settings, but a bit
> of it is "use the browser" which is inadequate. We really need a
> commons-proxy-setup library to do this for standalone apps in a
> consistent manner.

Sounds like a reasonable idea.

> Here in ant-land, we've done two things to make the stuff work better
> 
> 1.

Are these the same points you added below?

> 1. build file tests; check handling of missing required items, etc, etc.
> ant-testutils is the jar for this.

Ok, that will be worth a look. I'm pretty flat out for the next ocuple
of weeks, then JavaOne, then holidays - so I'll revisit this next
month :)

Is this still going to give enough time to prepare for Ant 1.7?

> 2. I'd like to be able to create a mini-pom on the fly. I do this with
> echo today, and will move to echoproperties before long

I thought about this, actually. So declaring it inside the  tag
instead of loading from a file? Should be pretty straightforward as
long as the setters are in place.

> 3. Absence of a .pom file should not constitute a failure, if the jar is
> there. When hand patching stuff into a local cache, I have to hand
> generate stub poms just to stop it breaking

Right... JIRA'd.

> 4., if it doesnt already, localRepository should take a File type and
> make an absolute URL of it:
> 
>   

Yep, that's what it does.

> 5. something to map from (artifact,groupid,version) to the path to a
> jar, to a pom, or the base dir. Here is my macro to get the dest
> directory, used when copying in local stuff.

I thought that was why dependencies had a fileset ID, so you didn't
need to worry about constructing paths, or knowing where the local
repository is if using external config?

Anyway, happy for this to go into JIRA. It can use the code already in
Maven to set the property and it would be flexible across layouts.

The proxy idea in a later email is also good, JIRA'd.

- Brett

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

Re: Updates to the Maven Artifact Ant tasks

[Brett Porter]

On 6/8/05, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
> I would use PropertyHelper instead:
> 
> http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/PropertyHelper.java?view=markup
> 
> Here is an example:
> 
> http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/XMLDOM.java?view=markup
> http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/test.xml?rev=1.9&view=markup
> 
> In this way, instead of
> 
>  expression="project.parent.artifactId"
>  pomRefId="maven.project" />
> 
> One could do something like:
> 
>  value="${maven.project:project.parent.artifactId}">

This looks good, but looking at the examples you gave, I don't see any
use of the PropertyHelper? I will have to spend some more time with it
later on.

> Please do, I will use it right away.

http://www.ibiblio.org/maven2/org/apache/maven/maven-artifact-ant/2.0-SNAPSHOT/maven-artifact-ant-2.0-20050608.072503-1-dep.jar

Thanks,
Brett

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

Updates to the Maven Artifact Ant tasks

[Brett Porter]

Hi,

This is primarily for Steve and Nicola Ken as I'm not sure if/how
closely they follow the Maven lists.

Just wanted to let you know about the changes I dropped in for the
dependencies and related tasks. Hopefully it is inline with the
feedback you'd been providing.

- added the ability to exclude specific transitive dependencies from
being pulled in from a specific dependency
- ability to use a POM to specify dependencies and repositories, in
addition to the ant types
- full support for external configuration (proxies, authentication
info, repository mirrors, local repository location). The search order
is ~/.ant/settings.xml, then ~/.m2/settings.xml
- ability to export properties or references from the pom:
  
   (not sure
whether this is a useful thing or not - I just thought references made
sense for object types)

This is only in the SVN version at the moment - if you'd like a
development build published just let me know.

Are there other features you see being needed, or is the focus now on
the error handling, validation and testing? Here I only mean Ant
specific things, as other features added to Maven like the dependency
path reporting, version ranges and conflict resolution will work from
the tasks as is, I think.
The only thing I've got left on my list is to incoporate the Maven
profiles support, but we need to play with that more on our end first.

Cheers,
Brett

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

Re: and m2

[Brett Porter]

On 5/17/05, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> I've used a more lenient model for my transitive dependency. The exact
> version used to build something is recorded, but which version of a
> given dependency to use is left up to the client. 

This is pretty much what is in Maven (and the artifact tasks) at the
moment. It uses the "nearest" definition for conflict resolution. So
declaring in the POM of the current project can ensure a particular
version, otherwise you'll get one at depth 1, etc.

> A colleage proposed an interesting idea of using predicates to state
> compatibility between components the different version of a component.

What we have is pretty basic, and we're definitely looking to improve
it with some other types of resolution, such as what you've described.
Ideally, a project would declare the minimum version it needs to work
(and if applicable, maximum - or perhaps even known incompatible
versions in between). The final project should use the most recent
version allowed by all of the definitions (on the assumption that the
most recent is backwards compatible and has less bugs than earlier
versions :)

Again, local definition of an explicit version will ensure you get
what you ask for.

This also has important consequences for making builds reproducible in
the future, too - obviously if the version remains flexible at the
point it is published then it might not be the same later on. There
needs to be a point during QA where you can lock it down to a version.

if you'd like to track the feature, http://jira.codehaus.org/browse/MNG-303

Cheers,
Brett

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

Re: and m2

[Brett Porter]

> I have a couple more things to ask. Where should the discussion on the
> Maven Ant tasks take place IYO?

Probably users@maven.apache.org (dev@ is fine too if you are more
comfortable there). Thanks.

Cheers,
Brett

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

Re: and m2

[Brett Porter]

On 5/16/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Example: fetching commons-logging 1.04

Hi Steve,

I'm going to work through the issues you filed here. We have planned
for the next release some filtering. Ideally, it shouldn't be needed,
but some projects will always build one bundle for you and let you
guess which bits need which dependencies, so the user needs full
control. There are definitely problems with some of the metadata -
particularly in commons, and unfortunately I didn't get a whole lot of
interest from commons developers at the time, so I'm fixing things
myself.

Aside from that, for commons-logging, I think you actually want
commons-logging-api which has no dependencies, right?

Cheers,
Brett

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

Re: PGP tasks

[Brett Porter]

On 5/9/05, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Depends on what we intend to do there.  commons-pgp or even
> commons-openpgp if we want to stick with PGP might be better (we may
> include support for encryption and decryption as well, that's why I
> don't like "signing").

Commons PGP sounds good, at least for now. Beauty of sandboxes and SVN
is that it can be renamed :)

> Brett, do you want to spread this to the maven dev-list (I'm

Will do.

Cheers,
Brett

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

Re: Ant 1.6.3

[Brett Porter]

> > Would be an interesting experiment to see how often it blows up :)
> 
> As soon as the branch really becomes warranted since you start to do
> serious new development on HEAD.  8-) The merge will probably only
> ever be possible without conflicts when you wouldn't need a branch
> anyway.

Not necessarily. Quite often a bugfix on a branch will occur somewhere
that HEAD hasn't been touched, so it will apply seamlessly. It's not
like the merge needs to go the other way :)

Once a conflict occurs, a manual merge can be done to resolve it and
the branch tagged so that future merges can be done from that tag
onwards.

anyway, probably something more suited to another list :)

Cheers,
Brett

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

Re: Ant 1.6.3

[Brett Porter]

> Wearing my Gump hat, this sounds really bad.  If we introduce a new
> feature in Ant we use Gump to testdrive it for backwards
> compatibility.  Having known bugs inside the test drive doesn't seem a
> good idea to me.

sounds like a feature request for gump: automatically merge the branch
and fail if there are conflicts, then fall back to just using HEAD.
(of course, it does not commit the merger, just does the cvs update -j
... -j ... bit).

Would be an interesting experiment to see how often it blows up :)

Cheers,
Brett

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

Re: Task for Reading POMs

[Brett Porter]

We have built exactly this, however it is not really in a release
state just yet. It will be used in Maven 1.1. I'd be happy to discuss
it further on the Maven developer list.

Cheers,
Brett

On Wed, 18 Aug 2004 10:36:53 -0400, Kyle Adams <[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
> 
> > This probably isn't going to be as easy as you hope - for instance
> > POMs often rely on property interpolation and inheritence of other
> > files.
> 
> Which is why I'm extending XmlProperty.  XmlProperty provides the
> property interpolation (with semanticAttributes turned on) and by
> extending it, my custom task can handle inheritance.  But I'd be open to
> other methods of reading a POM, including...
> 
> > Is there any reason not to use org.apache.maven.MavenUtils?
> 
> Good question (though perhaps better suited for Maven's developer
> list).  In a perfect world, I'd love to use the same classes that Maven
> uses for reading in POMs.  In that same vein, I'd love to see Java tool
> makers standardize on a schema for project descriptors, so you could
> have one POM that Eclipse, JBuilder, Java Studio Creator, Ant, Maven,
> and [insert your favorite IDE/project/build tool here] would know how to
> read.
> 
> But...
> 
> Those classes are currently bundled up into the Maven JAR, and there's
> a high degree of dependency on other Maven-specific classes.  I ran into
> this while writing Ant tasks that wrapped around Maven's dependency
> verifier and the artifact plugin.  Looking at MavenUtils code, it
> appeared to be the same situation (correct me if I'm wrong).
> 
> I'd jump all over using those classes if they were separated out into a
> sort of jPOM project :-) with a generic API for reading/writing a
> standard POM and a lightweight, non-Maven-specific, library-type JAR.  I
> think that would also make a standardized POM much more attractive to
> Java tool developers.
> 
> Am I out in left field here, or does that sound reasonable?
> 
> 
> 
> Kyle
> 
> _
> 
> Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: Task for Reading POMs

[Brett Porter]

This probably isn't going to be as easy as you hope - for instance
POMs often rely on property interpolation and inheritence of other
files.

Is there any reason not to use org.apache.maven.MavenUtils?

- Brett

On Mon, 16 Aug 2004 12:45:24 -0400, Kyle Adams <[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
> 
> > I think that's what "JAM" does. Don't know the URL off the top of my
> head.
> 
> The URL is http://www.javagen.com/jam.jsp and I'm actually working on
> this task in relation to JAM :-)  JAM can't directly read a POM; rather
> there are Maven plugins provided as part of JAM that allow you to
> generate JAM-specific config files from a POM.  In the interest of
> tighter integration with Maven, I'd like to create an Ant task that
> could read the POM directly and bypass the "keep JAM config files in
> sync with POM" step.
> 
> I've been looking around XmlProperty and noticed a bit of oddness when
> it comes to the visibility of the methods.  Some, like
> addNodeRecursively(Node, String, Object) are private.  Then
> addNodeRecusively calls processNode(Node, String, Object), which is
> public.  Finally, addNodeRecursively(Node, String) uses the default
> package visibility.
> 
> It would be nice (from my perspective) if all of the methods above were
> protected, making it easy for me to extend XmlProperty and create a
> PomProperty task.  Is there a ryhme or reason for their existing
> visibilities that I'm missing?
> 
> 
> 
> Kyle
> 
> _
> 
> Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: Task for Reading POMs

[Brett Porter]

I think that's what "JAM" does. Don't know the URL off the top of my head.

On Fri, 13 Aug 2004 11:56:41 -0400, Kyle Adams <[EMAIL PROTECTED]> wrote:
> Before I go re-inventing the wheel, I wanted to check and see if anyone
> else was working/had worked on scratching the same itch:
> 
> I'd like to be able to utilize Maven's POM for describing a project;
> XmlProperty gets me most of the way there, but there are a few things
> (like imported POMs) that it doesn't handle.  Consequently I'd like the
> write a PomProperty (probably extending XmlProperty) to handle these
> extra bits of functionality.
> 
> Thanks,
> Kyle
> 
> _
> 
> Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: -p and "" target

[Brett Porter]

yes, it is! Sorry... still getting used to gmail laying everything out together.

We had exactly the same problem in Maven just recently - but -p does
something different there :)

(embarressedly goes back to lurking)

Cheers,
Brett

On Wed, 30 Jun 2004 09:51:35 +1000, Conor MacNeill
<[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
> > seems that old commons-cli beta we are using is buggy.
> >
> > Can you file this in JIRA so I don't forget, and I'll try using a
> > released version of it :)
> >
> > Cheers,
> > Brett
> >
> 
> Wrong list, perhaps?
> 
> Conor
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: -p and "" target

[Brett Porter]

seems that old commons-cli beta we are using is buggy.

Can you file this in JIRA so I don't forget, and I'll try using a
released version of it :)

Cheers,
Brett

On Tue, 29 Jun 2004 18:23:35 +0100, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
> 
> >Should the "" target be invoked when Ant is executed
> >in -p mode?
> >
> >
> No, it should not!.
> 
> but it does, so this is a bug!
> 
> Peter
> 
> 
> 
> >-Matt
> >
> >
> >
> >__
> >Do you Yahoo!?
> >New and Improved Yahoo! Mail - Send 10MB messages!
> >http://promotions.yahoo.com/new_mail
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

RE: Ant 1.6 and Jelly/Maven (was Re: [GUMP@lsd]: ant-1.5/ant-1.5 failed)

[Brett Porter]

Ok, I've gotten myself on [EMAIL PROTECTED] because I'm interested in that 
anyway, so
I won't cross-post to gump again :)

> > This would be contributing to Maven's failure with Ant 1.6 
> then, too.
> 
> Quite possible.
> 
> I didn't know that Maven had a problem with Ant 1.6, even 
> though I am subscribed to the Maven dev list.  We really 
> should collaborate on issues like this - if you Maven guys 
> have trouble with Ant, please tell us Ant guys.

We did discuss it on dev for a while. dIon made the changes and we rolled it
back when we saw some incompatibilities.

There's nothing insurmountable there, but its going to require some
incompatible changes to be made, and'll have to wait until after 1.0. This
is the only reason it hasn't been taken any further just yet.

The future versions of Maven will probably use Maven differently and Jelly
sparingly, so it may be a non-issue.

> The on-topic part for Gump: If Maven could 
> be built by Gump, we might have seen this issue long before 
> Ant 1.6.0 was released.

:)

I'm actually working on this right now. I'm going to make a custom build
somewhat like the bootstrap but simpler. I was worried about the ant issue -
but if there is an ant-1.5 build then that is perfect for now. I'll post
separately to gump.

> Back to the issue at hand.  I'm sort of stuck here.  I don't 
> know anything about Jelly and Jelly development has stopped 
> AFAICT.  There doesn't seem to be anybody left I could ask 
> questions or who'd apply patches should that become 
> necessary.  It may very well be an issue like 

> where we can't fix Ant, but can provide a work-around so that code works
with Ant 1.5.x and 1.6.x afterwards.

Yes, James' public apology for Jelly probably doesn't bode well for its
future :)

This looks like the right track for the issue, although to be honest I think
I know about as much as you do at this point. I haven't looked in much depth
at the bindings of Maven to Ant in the past as I joined Maven after it was
in its current state.

> If Maven has the same problems, at least you could help me track it down.
I'm more than willing to get this resolved and we should try to do so (after

> Easter since I'll be offline during the holidays) in any way that works
for you.

My focus is elsewhere presently, but I'm happy to work with you on this
wherever I can help out.

> Yes, I understand that.  We know pretty well that the change broke some
things, but we did so consciously to solve a whole slew of other issues and
won't > revert it.

I think it's great. It should be a lot better to Maven, but the fact that it
will change will flow on to users currently, so we've bumped the upgrade to
1.1 or whatever comes next.

> How does Maven integrate with Ant?  The classloading changes shouldn't
affect Maven unless it runs Ant via the command line interface or the new
Launcher > class.  Do you have any details here?

commons-grant. It defines a derived AntClassLoader, AntProject and
propshandler to integrate a jelly context.

Cheers,
Brett

RE: [GUMP@lsd]: ant-1.5/ant-1.5 failed

[Brett Porter]

Hi Stefan,

This would be contributing to Maven's failure with Ant 1.6 then, too. We had
to roll that back. Additionally, the classloader changes caused a few
problems.

I'd be interested to hear what you find out regarding 1.6 and Jelly.

Cheers,
Brett

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, 8 April 2004 3:51 PM
> To: general@gump.apache.org
> Cc: [EMAIL PROTECTED]
> Subject: Re: [EMAIL PROTECTED]: ant-1.5/ant-1.5 failed
> 
> 
> The build fails because Gumpy passes quite a few command line 
> arguments to bootstrap.sh that are not expected.
> 
> In particular the -Xbootclasspath option kills Ant.
> 
> System properties as well as the -verbose switch shouldn't 
> apply to