Nabble - Ant - Dev

Re: Ivy Indexer

2009-11-25T10:34:50Z

IVY-1143 created for this thread and linked to IVYDE-134. A rough patch is
attached.

Jon

On Tue, Nov 24, 2009 at 7:32 AM, Jon Schneider <jschneider@...>wrote:

> > ---------------------------------------------
>
> > So Solr might be the easiest way of achieving an Ivy indexer.
>
>> Probably. As a side note, while thinking of installing a server side
>> component to provide search, I started to wonder why not use a
>> repository manager in that case. During devoxx I discussed with people
>> from artifactory, and their latest version is now supporting Ivy (may
>> still be limited, but they are working on improving that). They also
>> provide a REST api for their search feature, so maybe it would be
>> interesting and easy to use their software. But if we don't want to be
>> dependent on their API, maybe we can try to define some sort of
>> "standard" REST api to access a repository search feature. This is
>> something they are ok to discuss. Then any repository manager
>> implementing this api could be used.
>>
>> Note that compared to using artifactory, using solr still has the
>> advantage of being probably usable with any kind of Ivy repo, not just
>> artifactory, which has probably some limitations (because it has not
>> been designed as an Ivy repo manager, I suppose it has some proxying
>> and layout limitations).
>>
> ---------------------------------------------
>
> I think the Solr implementation could serve as a sort of "Reference
> Implementation" that we provide. If Artifactory then also provides an
> interface, all the better! Undoubtedly, it would help the folks at
> Artifactory if they had a reference implementation to base their product on.
>
> ---------------------------------------------
>
>> >
>> > I have to admit I am not a big fan of having to deploy a webapp next to
>> a dumb simple repo. On the other hand managing an index on the client side
>> depends enormously of the kind of repository (at work we have an ivy repo in
>> svn accessible form both http and checkouted), it would consume more
>> bandwidth, some publication locking would probably be in place, etc...
>>
>> I agree that having to deploy a webapp is an additional burden in the
>> build ecosystem setup. But now people are used to install a CI server,
>> a SCM server, and so on. So I don't think it should stop us, because I
>> think dealing with that from the client side only will have some
>> serious limitations.
>>
> ---------------------------------------------
>
> I think it is important to lure people in with the prospect of no
> additional webapps by allowing them to read an index on a remote filesystem
> directly, then allowing them to gradually come to terms with the fact that
> it it is more performant to allow a server to serve up the index and add
> complexity to their build ecosystem on their own timeline.
>
> ---------------------------------------------
> > Alternatively we could define a java interface to access a search
> > service (there's already one, but it is very limited), and have
> > different implementations: based ona local index as initially
> > suggested, using solr, artifactory, or any other. Then we are open to
> > the future.
> ---------------------------------------------
>
> I must be missing something... what java interface accesses a search
> feature currently?
>
> ---------------------------------------------
> > I think the transaction would be supported at the Lucene index level.
> ---------------------------------------------
>
> More specifically, the transaction is already at the publish level for the
> general use case since an index writer is opened for each publish and closed
> at the end of the publish, effectively committing the transaction.
>
> On a somewhat related point, are we still considering Solr or other repo
> managers for the additional duty of handling the indexing? Is there a use
> case where guaranteeing indexing concurrency apart from a simple lock
> strategy (block until the index lock is closed or a timeout is reached) is
> important?
>
> Jon
>

Re: Propose 1.7.2 Bugfix Release

2009-11-24T22:57:04Z

On 11/24/2009 05:10 AM, Stefan Bodewig wrote:

> On 2009-11-23, Jesse Glick<jesse.glick@...> wrote:
>
>> I'm not sure backporting bug fixes is worth the effort when there is
>> nothing in particular holding up a 1.8.0 release that I know of.
>
> Time, but that applies to any release.
>
> I am planning to volunteer as release manager for 1.8.0 by the end of
> the year - I had hoped to get to it earlier than that but real life got
> into the way.
>
> FWIW I wouldn't object a 1.7.2 release but completely lack the time to
> support it.
>
> From my POV the only things missing for a 1.8.0 release are proper
> documentation of target-group and better documentation on the include
> (and its difference WRT import) task. No biggies. I do have some
> concerns because of the exec unit tests failures.

So if people on this list think that 1.8.0 will come out in a reasonable
timeframe (and/or at least seriously discuss a timeframe so that people
looking for critical fixes can plan appropriately) then I can wait until
then.

Otherwise I'd be interested in branching from 1.7.1, picking a bunch of
bugs and merging in those patches. I think the criteria for fixes would
have to be something like:
- Someone cares enough about the particular issue that they say that it
should be specifically included
- Fix already exists
- Fix is reasonably easy to merge in (i.e. doesn't depend on some major
structural change for 1.8.0)
- Fix is backwards compatible (except in cases where backwards
compatible means "totally broken")

I would be willing to take a stab at it. I'm not an Ant committer (and
don't expect to be made one any time soon, given that I just "walked in
off the street" and you have no idea who I am) so we'd need to figure
out something from a technical perspective. Perhaps I could create a
local Mercurial clone of the repository and push changes to that, so
that each commit could be viewed individually (rather than a gigantic
patch at the end).

Thanks,

-Adam Batkin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

A Groovy frontend of Ant in the sandbox ?

2009-11-24T12:15:45Z

As I already wrote about it in this mailing list, I developed a groovy frontend to Ant.

As suggested by Stefan, I could have started its development directly in the sandbox. For some reason I didn't. But I am willing to push it here. So maybe someday there would be an official ASF release of it.

So I would like to know how to proceed. I think some legal review should be needed ? Should it have to be reviewed by the incubator ? A simple vote here is sufficient ?

About the license, initially I forked gant [1], which is under the ASL2. Then I changed the code, I am the only committer there. The result being under the ASL2 attributed to Russel Winder and me.
If you need some review, it is there [2].

Nicolas

[1] http://gant.codehaus.org/
[2] https://lunercp.svn.sourceforge.net/svnroot/lunercp/trunk/org.hibnet.gant/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-24T05:32:17Z

> ---------------------------------------------
> So Solr might be the easiest way of achieving an Ivy indexer.

> Probably. As a side note, while thinking of installing a server side
> component to provide search, I started to wonder why not use a
> repository manager in that case. During devoxx I discussed with people
> from artifactory, and their latest version is now supporting Ivy (may
> still be limited, but they are working on improving that). They also
> provide a REST api for their search feature, so maybe it would be
> interesting and easy to use their software. But if we don't want to be
> dependent on their API, maybe we can try to define some sort of
> "standard" REST api to access a repository search feature. This is
> something they are ok to discuss. Then any repository manager
> implementing this api could be used.
>
> Note that compared to using artifactory, using solr still has the
> advantage of being probably usable with any kind of Ivy repo, not just
> artifactory, which has probably some limitations (because it has not
> been designed as an Ivy repo manager, I suppose it has some proxying
> and layout limitations).
>

---------------------------------------------

I think the Solr implementation could serve as a sort of "Reference
Implementation" that we provide. If Artifactory then also provides an
interface, all the better! Undoubtedly, it would help the folks at
Artifactory if they had a reference implementation to base their product on.

---------------------------------------------

> >
> > I have to admit I am not a big fan of having to deploy a webapp next to a
> dumb simple repo. On the other hand managing an index on the client side
> depends enormously of the kind of repository (at work we have an ivy repo in
> svn accessible form both http and checkouted), it would consume more
> bandwidth, some publication locking would probably be in place, etc...
>
> I agree that having to deploy a webapp is an additional burden in the
> build ecosystem setup. But now people are used to install a CI server,
> a SCM server, and so on. So I don't think it should stop us, because I
> think dealing with that from the client side only will have some
> serious limitations.
>

---------------------------------------------

I think it is important to lure people in with the prospect of no additional
webapps by allowing them to read an index on a remote filesystem directly,
then allowing them to gradually come to terms with the fact that it it is
more performant to allow a server to serve up the index and add complexity
to their build ecosystem on their own timeline.

---------------------------------------------
> Alternatively we could define a java interface to access a search
> service (there's already one, but it is very limited), and have
> different implementations: based ona local index as initially
> suggested, using solr, artifactory, or any other. Then we are open to
> the future.
---------------------------------------------

I must be missing something... what java interface accesses a search feature
currently?

---------------------------------------------
> I think the transaction would be supported at the Lucene index level.
---------------------------------------------

More specifically, the transaction is already at the publish level for the
general use case since an index writer is opened for each publish and closed
at the end of the publish, effectively committing the transaction.

On a somewhat related point, are we still considering Solr or other repo
managers for the additional duty of handling the indexing? Is there a use
case where guaranteeing indexing concurrency apart from a simple lock
strategy (block until the index lock is closed or a timeout is reached) is
important?

Jon

Re: Propose 1.7.2 Bugfix Release

2009-11-23T21:10:54Z

On 2009-11-23, Jesse Glick <jesse.glick@...> wrote:

> I'm not sure backporting bug fixes is worth the effort when there is
> nothing in particular holding up a 1.8.0 release that I know of.

Time, but that applies to any release.

I am planning to volunteer as release manager for 1.8.0 by the end of
the year - I had hoped to get to it earlier than that but real life got
into the way.

FWIW I wouldn't object a 1.7.2 release but completely lack the time to
support it.

From my POV the only things missing for a 1.8.0 release are proper
documentation of target-group and better documentation on the include
(and its difference WRT import) task. No biggies. I do have some
concerns because of the exec unit tests failures.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-23T16:23:06Z

2009/11/21 Nicolas Lalevée <nicolas.lalevee@...>:

>
> Le 19 nov. 2009 à 12:06, Xavier Hanin a écrit :
>
>> I really like the idea to use a solr instance colocated with the repository.
>> I've seen a presentation on solr yesterday at devoxx, and it sounds like so
>> close to what we need. The only problem I see with it is that it requires to
>> install a server side component, getting closer to what repository managers
>> do. I'm not sure about why if we install a slor instance we wouldn't use it
>> to update the index too. Solr takes care of problems like transactions,
>> concurrency, so I think it's a perfect fit...
>
> I think the transaction would be supported at the Lucene index level. I don't think there is any mechanism to make solr manage an extra "data storage". As far as I remember Solr is just able to read the external "data storage" to index it.
> But what would work is a Solr deployed just next to an Ivy repository, let Ivy publish artifacts like it already does, but also make Ivy request Solr to index the newly published artifact.

Yes, this is exactly what I was thinking about.

>
> And spotted by a friend, Solr 1.4 [1] support replication in Java [2] ala rsync !
I'm not sure this is even necessary to use, except for very large
implementations of Ivy with huge repositories. Most of the time only
one solr instance should be enough.

>
> So Solr might be the easiest way of achieving an Ivy indexer.
Probably. As a side note, while thinking of installing a server side
component to provide search, I started to wonder why not use a
repository manager in that case. During devoxx I discussed with people
from artifactory, and their latest version is now supporting Ivy (may
still be limited, but they are working on improving that). They also
provide a REST api for their search feature, so maybe it would be
interesting and easy to use their software. But if we don't want to be
dependent on their API, maybe we can try to define some sort of
"standard" REST api to access a repository search feature. This is
something they are ok to discuss. Then any repository manager
implementing this api could be used.

Alternatively we could define a java interface to access a search
service (there's already one, but it is very limited), and have
different implementations: based ona local index as initially
suggested, using solr, artifactory, or any other. Then we are open to
the future.

Note that compared to using artifactory, using solr still has the
advantage of being probably usable with any kind of Ivy repo, not just
artifactory, which has probably some limitations (because it has not
been designed as an Ivy repo manager, I suppose it has some proxying
and layout limitations).

>
> I have to admit I am not a big fan of having to deploy a webapp next to a dumb simple repo. On the other hand managing an index on the client side depends enormously of the kind of repository (at work we have an ivy repo in svn accessible form both http and checkouted), it would consume more bandwidth, some publication locking would probably be in place, etc...

I agree that having to deploy a webapp is an additional burden in the
build ecosystem setup. But now people are used to install a CI server,
a SCM server, and so on. So I don't think it should stop us, because I
think dealing with that from the client side only will have some
serious limitations.

Xavier

>
> Nicolas
>
> [1] http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.4.0/CHANGES.txt
> [2] https://issues.apache.org/jira/browse/SOLR-561
>
>>
>> My 2 c.
>>
>> Xavier
>>
>> 2009/11/18 Jon Schneider <jkschneider@...>
>>
>>> While I digest Nicolas' novel :) (thanks for the additional insight on
>>> Lucene by the way), I will suggest one other idea.
>>>
>>> We could allow for the option of a Solr instance collocated with the
>>> repository on one machine to serve up the index stored on the repository.
>>> IvyDE could be configured by the user to either read the index directly
>>> from the remote filesystem or send its requests via HTTP to a Solr server.
>>> The Solr server would not be responsible for maintaining the index in the
>>> same way that Archiva/Nexus/Artifactory do, but would simply be a querying
>>> tool. In the case where Solr is serving the index, the index would still
>>> be
>>> maintained through some combination of the index ant task and the publish
>>> proxy.
>>>
>>> This way we don't get into the complexity of pushing out index updates to
>>> clients.
>>>
>>> The rsync strategy is a very intriguing idea though, especially in light of
>>> how Lucene segments its index in multiple files. What happens when
>>> optimize
>>> is called on the index and the segments are combined into one file? In
>>> this
>>> case, any search slaves would essentially have to download the whole index
>>> right? How much segmentation is considered too much segmentation before we
>>> optimize the index to cater to search speed over index publishing speed?
>>>
>>> I'll be trying to wrap this up enough (at least with the remote filesystem
>>> index read strategy) to make a patch so others can see it in action. We
>>> are
>>> a little busy at work, but I will be coming back to it in the coming days.
>>>
>>> Thanks for all the feedback so far,
>>> Jon
>>>
>>
>>
>>
>> --
>> Xavier Hanin - 4SH France - http://www.4sh.fr/
>> BordeauxJUG creator & leader - http://www.bordeauxjug.org/
>> Apache Ivy Creator - http://ant.apache.org/ivy/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Propose 1.7.2 Bugfix Release

2009-11-23T14:57:05Z

Adam Batkin wrote:
> I am sure that other people have their own pet bugs that they
> feel are absolutely critical and should be included too.

Candidates would be from among:

https://issues.apache.org/bugzilla/buglist.cgi?order=Importance&bug_severity=blocker&bug_severity=critical&bug_severity=regression&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&resolution=FIXED&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=1.8.0&product=Ant

after filtering out bugs only introduced by changes in dev sources.

I'm not sure backporting bug fixes is worth the effort when there is nothing in particular holding up a 1.8.0 release that I know of. To quote Stefan from three months ago:

"I really wouldn't want to go through the pain of merging the bug fixes into the 1.7 branch (I have been willing to do so about a year ago [...] but we have changed too
much in trunk after that)."

Of course if only a handful of "absolutely critical" bugs would be considered for 1.7.2 then the backporting may not be much work.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Propose 1.7.2 Bugfix Release

2009-11-23T13:24:53Z

Hi,

I would like to propose that there be a 1.7.2 Bugfix Only release.

In particular, I am interested in bug 43114:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43114
Though I am sure that other people have their own pet bugs that they
feel are absolutely critical and should be included too.

I am also willing to contribute my time toward putting the release
together, since from what I have read, that may be one of the biggest
things holding this back.

Thoughts? Where do we go from here? What can I do to help?

-Adam Batkin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Bug report for Ant [2009/11/22]

2009-11-22T15:08:02Z

+---------------------------------------------------------------------------+
| Bugzilla Bug ID |
| +---------------------------------------------------------------------+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned |
| | OPN=Reopened VER=Verified (Skipped Closed/Resolved) |
| | +-----------------------------------------------------------------+
| | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial |
| | | +-------------------------------------------------------------+
| | | | Date Posted |
| | | | +--------------------------------------------------+
| | | | | Description |
| | | | | |
| 1509|Opn|Enh|2001-04-25|Project object not fully functional in BuildEvents|
| 2743|New|Enh|2001-07-23|More sophisticated dependency analysis |
| 2811|New|Enh|2001-07-25|<depend> does not work when static final primitive|
| 3310|New|Enh|2001-08-28|Clear case files and directories |
| 5748|New|Enh|2002-01-08|Filtering, Default Filter |
| 5789|New|Enh|2002-01-10|Enhanced PVCS task. |
| 6606|Opn|Enh|2002-02-21|META-BUG problems with delegating classloaders |
| 6757|New|Enh|2002-02-28|adding visibility to tasks |
| 7546|New|Enh|2002-03-27|EjbJar:Borland Task doesn't allow alternate compil|
| 7712|New|Enh|2002-04-03|Provide patternset support for VSSGET task? |
| 8294|New|Enh|2002-04-19|<apply>: Allow <srcfile/> and <targetfile/> to app|
| 8866|New|Enh|2002-05-07|Signal handling in java task |
| 8895|New|Enh|2002-05-08|ant and/or antcall should support forking |
| 8972|New|Enh|2002-05-10|allow property expansion in <filterset> property v|
| 8981|New|Enh|2002-05-10|Tar task command additional features |
| 9294|New|Enh|2002-05-21|[PATCH] optional/j2ee/ServerDeploy OC4J Support |
| 9481|New|Enh|2002-05-29|Add a "prefix" attribute to ExpandProperties filte|
| 9784|New|Enh|2002-06-11|BuildNumber task: make more extendable... |
| 9995|Ass|Enh|2002-06-19|MKS Source Integrity tasks |
|10020|New|Enh|2002-06-19|<ejbjar>'s dependency behaviour should be more con|
|10231|New|Enh|2002-06-25|Need access to current file in SQLExec |
|10283|New|Enh|2002-06-27|Add a destfile to the uptodate task |
|10402|New|Enh|2002-07-02|adding the ability of html like whitespace preserv|
|11113|New|Enh|2002-07-24|keytool task |
|11560|Opn|Enh|2002-08-08|Taskdef does not apply reverseLoader policy on sta|
|12267|New|Enh|2002-09-03|Add ability to unzip into separate folders |
|12292|New|Enh|2002-09-04|[PATCH] enable <depends target=""/> tag inside tar|
|12334|New|Enh|2002-09-05|REQUEST: Ant task doesn't allow attachment of a bu|
|12518|New|Enh|2002-09-11|Gunzip & BUnZip2 add filesets, patternsets, and ov|
|12765|New|Enh|2002-09-18|"rmdir" and "deltree" patches for ftp task enhance|
|12964|New|Enh|2002-09-24|ANTLR only takes one input file at a time |
|13047|Inf|Enh|2002-09-26|Support for <property environment> and <exec> on O|
|13048|New|Enh|2002-09-26|Add an optional containsall attribute to LineConta|
|13371|New|Enh|2002-10-07|[PATCH] Contributed new CvsExportDiff task |
|13847|New|Nor|2002-10-22|pvcs task: wrong option (-r) specified for get (sh|
|13934|New|Enh|2002-10-24|Translate task shouldn't load default locale prope|
|13939|New|Enh|2002-10-24|Translate task should have better key matching cap|
|14320|New|Enh|2002-11-06|copy fileset followsymlinks="false" does not copy |
|14393|New|Enh|2002-11-08|Support use of jndi within ant |
|14512|New|Enh|2002-11-13|Allow creating database connection similar to <pat|
|14525|New|Enh|2002-11-13|Add failonerror attribute to serverdeploy vendor-s|
|14901|New|Enh|2002-11-27|[PATCH] Stub Generation enhancement for Borland J2|
|15031|Opn|Nor|2002-12-03|ANT <copy> with <fileset> does not spot bad symlin|
|15149|New|Enh|2002-12-06|Replace task |
|15244|New|Enh|2002-12-10|tar task should be able to store symbolic links as|
|15430|New|Enh|2002-12-17|Enhancement to ReplaceRegExp.java |
|15596|New|Enh|2002-12-21|Identity mapper in uptodate task. |
|15729|Ass|Nor|2002-12-31|StarTeam rootLocalFolder should be java.io.File |
|15747|New|Enh|2003-01-01|change tasks (e.g. Ant) to take urls as well as fi|
|15853|New|Enh|2003-01-07|Allow to plug-in different XML Catalog resolver in|
|15949|Opn|Enh|2003-01-10|please provide links to docs.xml and jakarta-site2|
|16131|New|Enh|2003-01-15|not possible to suppress "BUILD SUCCESSFUL" messag|
|16255|New|Enh|2003-01-20|XmlLogger without DOM tree |
|16427|New|Enh|2003-01-26|Output return value of setLastModified/document be|
|16469|New|Enh|2003-01-27|Apply task should allow parallel execution on diff|
|16494|New|Enh|2003-01-28|[PATCH] accessibility of Ant documentation |
|16562|New|Enh|2003-01-29|Can not accept characters from keyboard in a thre|
|16860|New|Enh|2003-02-06|Silent or Debug a single target |
|16896|New|Enh|2003-02-07|Support in ProjectHelper / ProjectHelperImpl to op|
|17074|New|Enh|2003-02-14|Contribution for WLSTOP |
|17181|New|Nor|2003-02-18|Build fails while trying to get VSS files by label|
|17372|New|Enh|2003-02-25|Enhancement of replace Task |
|17742|New|Maj|2003-03-06|PVCS task generates GET with promotion group incor|
|17781|New|Enh|2003-03-07|name attribute of record task is not relative to b|
|17829|New|Enh|2003-03-10|Allow ejbjar task to accept nested manifest |
|17850|New|Nor|2003-03-10|PVCS task dont work with promotion group |
|17961|New|Enh|2003-03-13|New task to collect services from a JAR |
|18043|New|Enh|2003-03-16|untar should recognize non-tar files instead of ex|
|18093|New|Enh|2003-03-18|<EAR> task proposed nested tasks to ease applicati|
|18154|New|Enh|2003-03-19|Improve exceptions and logging behavior of p4chang|
|18391|Opn|Enh|2003-03-26|RFE : ignoreMissingBuildFiles option for subant |
|18581|New|Enh|2003-04-01|ClearCase ChangeLog Task |
|18633|Ass|Nor|2003-04-02|starteam checkin task ignores the includes paramet|
|18732|New|Enh|2003-04-05|expand properties during -propertyfile processing |
|18807|New|Enh|2003-04-08|Pro*C |
|18850|New|Nor|2003-04-09|Visual Source Safe History Does Not Allow Specific|
|18930|New|Enh|2003-04-11|SQLExec Task does not work well with MS SQL Server|
|18997|New|Min|2003-04-14|Streateam: Call to BuildNumber.getDisplayString() |
|19077|New|Enh|2003-04-16|Telnet task doesn't support failure |
|19118|New|Enh|2003-04-17|JUnitReport does not fail when it encounters an in|
|19224|New|Enh|2003-04-22|The <javac> task should accept the 'dependcache' a|
|19252|New|Enh|2003-04-23|<untar> does not untar symbolic links properly |
|19386|New|Enh|2003-04-28|<filesmatch> condition evaluates to true when both|
|19470|New|Enh|2003-04-30|Use createViewLabel method of View class to create|
|19516|New|Enh|2003-05-01|uncompressed zipping takes too much memory |
|19673|New|Enh|2003-05-05|Add timeout attribute to serverdeploy vendor-speci|
|19712|New|Enh|2003-05-07|Add a task for SQLJ compilation |
|19714|New|Enh|2003-05-07|Nested element ("weblogic") of the "serverdeploy" |
|19964|New|Enh|2003-05-15|system property for a default timeout for tests |
|20128|New|Maj|2003-05-21|vssget command label problem |
|20207|New|Enh|2003-05-24|enhance telnet task to be able to gather read outp|
|20262|New|Enh|2003-05-27|RFE: allow not arround patternsets |
|20344|Opn|Enh|2003-05-29|[PATCH]Allows record task to use XmlRecorder |
|20485|New|Enh|2003-06-04|The <sync> task doesn't support the nested "filter|
|20547|New|Enh|2003-06-06|Make <batchtest> to ignore abstract test cases |
|20721|New|Enh|2003-06-12|no comment option for vsscheckout task |
|20867|Opn|Enh|2003-06-18|The possibility of getting properties from ant scr|
|20956|New|Enh|2003-06-20|java debugging and profiling |
|21058|New|Enh|2003-06-24|The ejbjar task should support the xmlcatalog data|
|21065|New|Enh|2003-06-24|new core task - MergeJavaDocs |
|21071|New|Enh|2003-06-25|Improve JUnit XML reporting when not using batchte|
|21192|New|Enh|2003-06-30|documentation hard to read because of incorrect bl|
|21249|New|Enh|2003-07-01|Add "getXxx()" and "clearXxx()" methods to Javadoc|
|21384|New|Nor|2003-07-07|vssget hanging |
|21414|New|Enh|2003-07-08|Bugzilla Report Generator Task |
|21424|New|Nor|2003-07-09|stcheckout task fails to obey "deleteuncontrolled |
|21494|New|Enh|2003-07-11|<property>: version of location to search parent d|
|21770|New|Enh|2003-07-21|ClassFileset should resolve vs. a classpath |
|22020|Opn|Enh|2003-07-31|[PATCH] addition of access atribute to <target..> |
|22067|Inf|Enh|2003-08-01|Logging of "Buildfile: *" directly to System.out i|
|22338|New|Enh|2003-08-12|add a "minversion" and a "version" attribute to ta|
|22370|New|Enh|2003-08-13|enhance <available> to test for owner, group and p|
|22378|New|Enh|2003-08-13|Borland Delphi/Kylix compiler support |
|22389|New|Enh|2003-08-13|Ant task to build VS.Net project file |
|22428|New|Enh|2003-08-14|PATCH - option to run tasks inside a loop |
|22460|New|Enh|2003-08-15|No access to the message output level from API |
|22554|New|Enh|2003-08-19|allow to specify Build file from OS environment va|
|22567|New|Enh|2003-08-19|Enhance "includes" and "excludes" attributes for S|
|22661|Opn|Nor|2003-08-22|Replace does not preserve line endings in multi li|
|22709|New|Enh|2003-08-25|SOS tasks should allow forward slashes in vssserve|
|22859|New|Enh|2003-09-01|Cross buildfile dependency |
|22883|New|Enh|2003-09-02|Enhancement to pvcs Operational Task |
|22889|New|Enh|2003-09-02|Add string formatting options to <property> |
|22901|Opn|Enh|2003-09-02|[Patch] -only option to execute target(s) without |
|23037|New|Enh|2003-09-09|[Patch] enhancement of org.apache.tools.ant.types.|
|23244|New|Enh|2003-09-18|New ImageSizeSelector |
|23261|New|Enh|2003-09-18|enhance <available type="symbolic_link" /> |
|23273|New|Nor|2003-09-19|Java task interprets it's arguments incorrectly if|
|23278|Unc|Enh|2003-09-19|Project.setName() does not replaceProperties() |
|23396|New|Enh|2003-09-24|New optional task ejbclientjar added |
|23404|New|Enh|2003-09-25|Allow Ant command-line property files to be loaded|
|23510|New|Enh|2003-09-30|provide a "append_unique" attribute for echo task |
|23541|Ass|Enh|2003-10-01|Enhance error messages of taskdef to say what real|
|23649|New|Enh|2003-10-07|Requirement for a method to not make entries in th|
|23660|New|Enh|2003-10-07|Added "Rename" action to the FTP task |
|23785|New|Enh|2003-10-13|[patch] Having <uptodate> execute a nested <sequen|
|23789|New|Enh|2003-10-13|warn if <delete task contains a fileset AND a dir |
|23829|New|Enh|2003-10-15|Enhancement to the Image Task |
|23869|New|Enh|2003-10-16|Add FTP prune capability |
|23873|New|Enh|2003-10-16|wlstop should allow user to stop a managed server |
|23874|New|Enh|2003-10-16|New wlstart task to start weblogic managed servers|
|23920|New|Nor|2003-10-19|Contains selector test fails on JDK 1.2.2 and IBM |
|23981|New|Nor|2003-10-21|Perforce tasks handle 'force' option oddly |
|23997|New|Enh|2003-10-22|Zip does not report "Nothing to do:", unlike tar a|
|24067|New|Enh|2003-10-23|[PATCH] <propertyfile> should not touch a file it |
|24089|New|Enh|2003-10-24|JSP whitespace reduction |
|24103|New|Enh|2003-10-24|edit the Windows registry |
|24106|New|Nor|2003-10-24|Suites are not reported correctly in JUnitReport |
|24167|New|Enh|2003-10-28|Enable password protection for zip creation. |
|24231|New|Enh|2003-10-29|command-line option to signify no more options |
|24259|New|Enh|2003-10-30|<unzip> to extract files with current time and dat|
|24260|New|Enh|2003-10-30|<unzip> seem extracting all files all the time. |
|24348|New|Nor|2003-11-03|soslabel task doesn't have certain attributes list|
|24431|New|Enh|2003-11-05|XML Logger marks compile-errors as warnings |
|24513|New|Enh|2003-11-07|vssget displays too much |
|24532|New|Enh|2003-11-09|ProjectHelp - refactored project help output |
|24694|Opn|Enh|2003-11-13|JAVA_HOME should be exported |
|24711|Opn|Enh|2003-11-14|[PATCH] macrodef child elements should use their d|
|24806|New|Enh|2003-11-19|Add merge as valid option for vssget writablefiles|
|24877|New|Enh|2003-11-21|exec task doesn't handle error conditions well |
|25205|New|Nor|2003-12-04|timeout on <junit> results in wrong timing informa|
|25379|New|Enh|2003-12-10|Cvs Tasks doesn't handle wildcards, so why not add|
|25601|New|Enh|2003-12-17|Please add force option to archival tasks jar/zip/|
|25655|New|Enh|2003-12-19|[PATCH] Dependencies with regular expressions |
|25704|New|Enh|2003-12-22|Support for Sun Solaris' Tar Format for long file |
|25745|New|Nor|2003-12-24|ClearCase Update task does not allow usage of the |
|25767|New|Enh|2003-12-26|Performance issues in JAXPUtils' use of SAXParser |
|25976|New|Enh|2004-01-08|ejbjar-support for orion-server |
|25998|Opn|Nor|2004-01-08|PropertyHelper - getPropertyHelper method should c|
|26026|New|Enh|2004-01-09|deleteuncontrolled parameter of stcheckout task sh|
|26027|New|Enh|2004-01-09|stcheckout and stcheckin are a little verbose |
|26145|New|Enh|2004-01-14|delete task and missing folders |
|26165|New|Enh|2004-01-15|Type checking in JUnit batchtest |
|26197|New|Nor|2004-01-16|Reference to realThing in UnknownElement.execute d|
|26308|New|Enh|2004-01-21|fail on verify errors in borland deployment tool |
|26453|New|Enh|2004-01-27|Exec task displays 'error' mesage "Result: XX" |
|26454|New|Enh|2004-01-27|exec task should not run if the resultproperty fla|
|26849|New|Enh|2004-02-11|[PATCH] Pathconvert output in xml format and write|
|26947|New|Enh|2004-02-15|ant.bat should detect if ANT_HOME ends in a backsl|
|27078|New|Enh|2004-02-19|add all optional jars to the classpath manifiest o|
|27118|New|Enh|2004-02-20|Add type overrides for import |
|27355|Inf|Cri|2004-03-02|question about VSS task in Ant1.5 |
|27596|New|Enh|2004-03-11|no way to verify JAR files as validly signed in An|
|27722|New|Enh|2004-03-16|Project description contains target description |
|27739|Ass|Nor|2004-03-17|sql insert statement fails on '--' strings |
|27771|New|Enh|2004-03-18|Make "Time Taken" in DefaultLogger optional |
|28049|New|Min|2004-03-30|sql task not able to import "windows UTF-8" |
|28099|New|Maj|2004-03-31|Problem with quotes in path |
|28101|New|Nor|2004-03-31|bootstrap.sh fails::qsh has limited space when run|
|28111|New|Nor|2004-03-31|property substitution is broken on os/400 |
|28124|New|Enh|2004-04-01|logging useless when using parallel task |
|28128|New|Enh|2004-04-01|<parallel> task needs cascade option |
|28228|New|Enh|2004-04-06|<classloader> task |
|28320|New|Enh|2004-04-09|copy task preserving permissions |
|28394|New|Enh|2004-04-14|Add "commentchars" attribute to Sql task |
|28398|New|Enh|2004-04-14|Add "file" option to PropertyFile's inner "entry" |
|28403|New|Enh|2004-04-15|Floating attribute for import task |
|28446|New|Enh|2004-04-17|Annotation or documentation nodes |
|28504|New|Enh|2004-04-20|[PATCH] Capitalize /ZIP|[JWE]AR/; update Zip.reset|
|28546|New|Enh|2004-04-22|Ant should offer hierarchical resource containment|
|28681|New|Enh|2004-04-29|[PATCH] Xml output for the SQL task |
|28729|New|Enh|2004-05-02|Introducing an <annotation> element |
|28882|New|Enh|2004-05-10|Add if and unless attributes to ProjectComponent. |
|28935|New|Enh|2004-05-12|Create .NET solution files |
|28984|New|Nor|2004-05-14|Optional ccm tasks only run on windows, patch for |
|28990|New|Enh|2004-05-14|Extend <java> task to provide <apply>-like feature|
|29045|New|Enh|2004-05-17|Updates to Move & Copy |
|29085|New|Enh|2004-05-19|Timestamps in jar-Manifest |
|29097|New|Enh|2004-05-19|<signjar> should be inside <jar> task in order for|
|29236|New|Enh|2004-05-26|Ant options on ant task |
|29248|New|Enh|2004-05-27|Ant does not automatically parallelize independent|
|29282|New|Enh|2004-05-28|Need a way to get generated jar file from EjbJar t|
|29347|New|Enh|2004-06-02|Recursive property expansion |
|29374|New|Enh|2004-06-03|Adding ant build script validation support |
|29396|New|Enh|2004-06-04|Allow P4Change to edit changelists as well |
|29633|New|Enh|2004-06-17|Need DirDiff Task |
|29729|New|Enh|2004-06-22|XSL StyleSheet for build scripts |
|29797|New|Enh|2004-06-25|Calling Ant from other Java Applications |
|29870|New|Enh|2004-06-30|Need a way to specify proxyHost and proxyPort to j|
|29986|New|Enh|2004-07-08|Recursive dependencies. |
|29997|Opn|Enh|2004-07-09|Implement wish list of functionality for <record/>|
|30145|New|Enh|2004-07-16|Sync/Copy task - add option to set property if som|
|30254|New|Enh|2004-07-22|xslt/style task not taking META-INF/services/javax|
|30288|New|Enh|2004-07-23|symmetric key generation & file encryption task |
|30380|New|Enh|2004-07-29|shutdown hook for xmllogger |
|30422|New|Enh|2004-07-31|[Patch] Mutual Exclusion Tasks |
|30488|New|Enh|2004-08-05|Option to show tasks in menu |
|30651|New|Enh|2004-08-13|Add ability to pass arbitrary arguments after a sp|
|30716|New|Enh|2004-08-17|javac task should have built in dependancy finder |
|30760|New|Nor|2004-08-19|sql task handle pl/sql with ';' in pl/sql code. (p|
|30795|New|Enh|2004-08-23|Delete task needs a 'verify' safety attribute |
|31005|New|Enh|2004-09-01|When a filter throws a BuildException, no indicati|
|31070|New|Enh|2004-09-06|Task for ISO cd image file generation. |
|31087|New|Enh|2004-09-07|Allow filtersets to be initialized from propertyse|
|31088|New|Enh|2004-09-07|Permit the token replacement filterreader to be in|
|31093|New|Nor|2004-09-07|tar task on Win2K incompatible with GNU tar 1.14 ?|
|31121|New|Enh|2004-09-08|echoproperties: Add suffix attribute and property |
|31165|New|Enh|2004-09-10|should we set networkaddress.cache.ttl to somethin|
|31235|New|Enh|2004-09-15|split junit-showoutput-tag in stdout/stderr |
|31258|New|Enh|2004-09-16|add build.compiler.executable default property |
|31271|New|Enh|2004-09-17|enhance copy task: error if tokenvalues are missin|
|31452|New|Enh|2004-09-28|StarTeam checlout enhancement |
|31588|New|Enh|2004-10-07|xdoc generation enhancements for Ant1.7 |
|31589|New|Nor|2004-10-07|Problems specific to OpenVMS |
|31591|New|Enh|2004-10-07|List of Java1.5 features to consider adding to Ant|
|31610|New|Enh|2004-10-09|[RFE][Patch] errorproperty attribute to <subant> t|
|31665|New|Enh|2004-10-12|[PATCH] set filename of default buildfile to allow|
|31744|New|Enh|2004-10-16|FTP subtasks should all share one connection |
|31779|New|Enh|2004-10-19|Problem with <input> task |
|31909|New|Nor|2004-10-27|vsscheckout doesn't support "writable" but the doc|
|32004|New|Enh|2004-11-01|junit's formatter using class name rather than tes|
|32041|New|Enh|2004-11-03|want to remember a value set within a task next ti|
|32089|New|Nor|2004-11-05|stcheckout sometimes creates folders instead of fi|
|32114|New|Enh|2004-11-08|javadoc package specifications |
|32129|New|Enh|2004-11-09|request to add purge, with recursive option comman|
|32142|New|Enh|2004-11-10|[PROPOSAL, PATCH] External public entity and new s|
|32379|New|Enh|2004-11-24|Enhance token definition for replacefilterfile in |
|32422|New|Nor|2004-11-28|[Patch] Additional clearcase task mkview/rmview |
|32526|New|Enh|2004-12-04|Add "whenempty" attribute to <fileset> |
|32545|New|Enh|2004-12-06|Add "p4tag" ant task for perforce optional tasks |
|32632|Opn|Enh|2004-12-10|pattern / nested patternset in filterset |
|32638|New|Enh|2004-12-10|Enhancement to <macrodef> to support new feature. |
|32683|New|Enh|2004-12-14|Java Target Needs Improved bootclasspath options |
|32725|New|Enh|2004-12-16|Default value for macrodef element parameter |
|32827|New|Enh|2004-12-23|Request for option to fail when filter tokens unde|
|32895|New|Enh|2004-12-30|add an invokation mode to xslt |
|32897|New|Enh|2004-12-31|[PATCH] New Logger: displays target's source file |
|32975|New|Enh|2005-01-06|Make XmlFormatter for junittask (optinally) lighte|
|32995|New|Nor|2005-01-07|StarTeam <checkin> doesn't add comment to new file|
|33026|New|Enh|2005-01-10|jar task fails when zipgroupfileset contains zip f|
|33031|New|Enh|2005-01-10|Building ejb for Websphere 5.1.1 |
|33057|New|Min|2005-01-12|VSS tasks do not handle CRLF in comments |
|33073|New|Enh|2005-01-12|Tasks created by <scriptdef> do not support nested|
|33169|New|Enh|2005-01-19|ClearCase update produces verbose output---request|
|33243|New|Enh|2005-01-25|Need a "meta data" facility. |
|33260|New|Nor|2005-01-27|p4change task does not set p4.change property corr|
|33333|New|Enh|2005-02-01|Enable <import> task within targets |
|33404|New|Enh|2005-02-04|Jar task supporting "replace token" using filterse|
|33480|New|Nor|2005-02-10|Please update doc with this note on why VSSGET get|
|33482|New|Enh|2005-02-10|include "ecj" build.compiler option |
|33506|New|Enh|2005-02-11|Provide a dateFormat attribute in the <stlabel> ta|
|33507|New|Enh|2005-02-11|Need way to have files retrieved via the <stchecko|
|33859|New|Nor|2005-03-05|SCP remoteTofile attribute not fully implemented |
|33868|New|Enh|2005-03-06|[PATCH] Xslt task should support "<?xml-stylesheet|
|33902|New|Nor|2005-03-08|clearcase clearaudit error after moving directorie|
|33928|New|Maj|2005-03-09|Output of "java" task and left quote |
|33939|New|Enh|2005-03-09|Added 'preservelastmodified' to scp task to retain|
|33955|New|Enh|2005-03-11|Tar task - username/uid settings are not carried o|
|34005|New|Enh|2005-03-14|spellcheck results from ant.apache.org manual |
|34054|New|Enh|2005-03-17|JUnitReport - Allow it to take name of xml files i|
|34116|New|Enh|2005-03-21|Example XML syntax for Ant manual + matching XSLs |
|34138|New|Enh|2005-03-22|Ant should use other compilers when Sun's Javac ca|
|34145|New|Enh|2005-03-23|InputRequest enhancement |
|34151|New|Nor|2005-03-23|need to propagage proxy information to <jarsigner>|
|34229|New|Nor|2005-03-30|Need ability to intercept calls to System.setSecur|
|34366|New|Enh|2005-04-08|Should be able to use <manifest> as a data type fo|
|34382|New|Nor|2005-04-09|Loss of Location information for sequential task o|
|34462|New|Enh|2005-04-14|Move optional jar files to a separate directory. |
|34507|New|Nor|2005-04-18|runant.py doesn't handle command with spaces in pr|
|34748|New|Enh|2005-05-04|[PATCH] JUnit Task enhancement to allow a single t|
|34777|New|Enh|2005-05-06|Support for Callable Statements in SQL task |
|34894|New|Enh|2005-05-12|ZIP integrity condition needed |
|34907|New|Enh|2005-05-13|Add Multipart subtype setting to MimeMailer |
|35044|New|Nor|2005-05-24|ccmcheckintask requires a file to work |
|35142|Opn|Enh|2005-05-31|generated manual pages do not adapt browser width;|
|35158|New|Enh|2005-06-01|Standard BuildListener for profiling Ant build |
|35192|New|Cri|2005-06-02|Receiving MessageFormat Parse Error when executing|
|35215|New|Nor|2005-06-03|Ant.bat with all parameters in ANT_ARGS always exi|
|35231|New|Enh|2005-06-06|Non-verbose 'preserve' in task 'zip' and 'jar' |
|35234|New|Enh|2005-06-06|Make the javah task fall back to executing javah c|
|35313|New|Cri|2005-06-10|PVCS task doesnt pull data |
|35464|New|Enh|2005-06-22|Add a dry run mode |
|35522|Opn|Nor|2005-06-28|no way to set java system options from comand line|
|35557|New|Enh|2005-06-30|Feature Request: XSLT pipe line task |
|35562|New|Nor|2005-06-30|sshexec corrupts output written to STDERR |
|35653|New|Nor|2005-07-07|PropertySet defined as a nested element in antcall|
|35657|New|Enh|2005-07-08|Add a "haltonerror" parameter to "xmlvalidate" |
|35776|Opn|Enh|2005-07-18|amend FileUtils to properly handle cygwin symbolic|
|35866|Ass|Enh|2005-07-26|JUnit task should show which test case failed |
|36048|New|Nor|2005-08-05|delete task option includeemptydirs: no deletion o|
|36085|New|Min|2005-08-08|p4counter task documentation is incorrect |
|36174|Ass|Enh|2005-08-12|Consider enabling java.net.useSystemProxies by def|
|36194|New|Nor|2005-08-15|FTP-Task cannot chmod directory permissions |
|36195|New|Enh|2005-08-15|upon failure - list the target(s) that were pursue|
|36270|New|Enh|2005-08-19|[PATCH] code to support browse task |
|36347|New|Nor|2005-08-24|antRun doesnt work properly on Solaris, so exec wi|
|36357|New|Enh|2005-08-25|Enhance P4Change by the ability to delete change l|
|36458|New|Nor|2005-09-01|problem with utf-8 encoding in <input> task |
|36464|New|Nor|2005-09-01|Wrong directory permissions from "tar" task |
|36503|New|Nor|2005-09-05|Starteam folders might have different working fol|
|36523|Ass|Nor|2005-09-06|<java> task, incompatibleWithSpawn is too restrict|
|36589|New|Enh|2005-09-10|You could enhance ant by "AOP" task,very useful in|
|36629|New|Nor|2005-09-13|Apt task fails when compile="false" specified |
|36641|Inf|Nor|2005-09-13|Problem in ClearCase task in SCM Optional SCM task|
|36653|Opn|Enh|2005-09-14|enable a "forking" XSLT task |
|36667|New|Enh|2005-09-15|Allow specification of a different logger for subt|
|36670|Inf|Enh|2005-09-15|xslt: support xalan traces |
|36851|New|Nor|2005-09-29|<tar> Task does not support multi-byte file names |
|36965|New|Nor|2005-10-07|Regression in wlserver task |
|37032|New|Enh|2005-10-11|2 new tasks for clearcase intregration |
|37127|Opn|Enh|2005-10-17|The Apt task needs a way to reference options decl|
|37200|New|Enh|2005-10-21|Split task |
|37286|New|Enh|2005-10-28|MacroDef Element Namespaces |
|37405|New|Enh|2005-11-08|optional delimiter attribute to the Replace task |
|37501|New|Nor|2005-11-14|IntrospectionHelper is not thread-safe |
|37728|New|Enh|2005-12-01|create a warningproperty attribute for the javadoc|
|37897|New|Nor|2005-12-14|ftp task very slow when depends=yes |
|37913|New|Enh|2005-12-14|Get and Post tasks: cookies not set when redirect |
|38245|Ass|Maj|2006-01-12|<sql> lacks any decent tests |
|38598|New|Enh|2006-02-09|SubSet Filter |
|38844|New|Enh|2006-03-03|ProjectHelper implementation that avoids re-parsin|
|38915|New|Enh|2006-03-10|${property_value} doesn't expand in description (F|
|38918|New|Enh|2006-03-10|Add 'real' overwrite support to Zip-based tasks |
|39000|New|Min|2006-03-16|j.u.concurrent in junit4 stack traces with timeout|
|39009|New|Enh|2006-03-17|scp task: includeEmptyDirs |
|39049|New|Enh|2006-03-21|Java task: add attribute to <sysproperty> which ta|
|39108|Opn|Nor|2006-03-26|FTP.java missing checks when file type is unknown |
|39164|Opn|Enh|2006-03-31|antlr task doesn't create output directory |
|39359|New|Nor|2006-04-19|Problems with OSD-5 filespecs and return codes on |
|39541|New|Enh|2006-05-10|<sql> output encoding support |
|39544|New|Enh|2006-05-10|<copy verbose="true" overwrite="false"> |
|39554|New|Enh|2006-05-11|Make sysproperty a top level element to set system|
|39597|New|Maj|2006-05-17|Reference not seen by top level tasks in sub-proje|
|39617|Opn|Enh|2006-05-19|The <tar> task should have an append attribute |
|39745|Inf|Enh|2006-06-07|Parts of ant cannot be compiled with sablevm |
|39782|New|Enh|2006-06-12|Add HelpTask |
|39786|New|Nor|2006-06-12|project.createTask() does not work for presets |
|39802|New|Enh|2006-06-13|Have "quiet" attribute for more file-based tasks |
|39841|New|Enh|2006-06-20|Support for POSIX.1-2001-compatible tars |
|39901|Inf|Enh|2006-06-26|Log4j Configurator Task |
|40059|New|Enh|2006-07-17|Add method to explicitly define symlinks in <tar> |
|40093|Opn|Nor|2006-07-22|ant.PropertyHelper reference not passed to called |
|40139|New|Enh|2006-07-30|support for properties within SELECTs of SQL task |
|40140|New|Enh|2006-07-31|Let task/types receive unexpanded attribute(s) |
|40157|New|Enh|2006-08-01|<scp> and <sshexec> Tasks to give meaningful errro|
|40235|New|Enh|2006-08-11|Subclass of JUnitTask that manages classpath depen|
|40448|New|Enh|2006-09-08|<exec>/<java>/<apply> should accept <envset> |
|40455|New|Nor|2006-09-10|ReaderInputStream handling character sets having p|
|40522|New|Nor|2006-09-15|[Patch] Fix coreloader so that it works |
|40561|New|Maj|2006-09-20|property expansion with prefix troubles in propert|
|40566|New|Nor|2006-09-21|Antunit doesnt exec sub java process; gets executi|
|40608|New|Enh|2006-09-26|<xmlvalidate>/<schemavalidate> would gain from a g|
|40632|New|Nor|2006-09-28|spawned process through exec task blocks parent ex|
|40642|New|Enh|2006-09-29|[PATCH] Ant.java support for logger configuration |
|40643|Inf|Enh|2006-09-29|Allow dependency injection on child tasks |
|40678|New|Enh|2006-10-04|[Patch] Allow macrodef to have arbitary xml elemen|
|40703|New|Enh|2006-10-07|Demo build file |
|40706|New|Enh|2006-10-07|SVN changelog task should use Subversion's --xml p|
|40725|New|Nor|2006-10-11|build does not fail if <property environment... fa|
|40760|New|Enh|2006-10-16|Notify property expansion |
|40871|New|Enh|2006-11-02|JJTree task doesn't support the new JJTree NODE_EX|
|40922|New|Enh|2006-11-07|Patch for MySQL support. |
|40946|New|Nor|2006-11-10|stcheckout ignores convertEOL when used with "asof|
|40977|New|Enh|2006-11-15|echoxml output encoding |
|40998|New|Enh|2006-11-19|fixcrlf should allow removing trailing spaces |
|41039|New|Nor|2006-11-24|ant.bat exit strategy improvements and issues |
|41125|New|Enh|2006-12-07|FilterReader classes should offer classpath, class|
|41237|Inf|Blk|2006-12-24|ANT_HOME is incorrectly... |
|41280|Opn|Nor|2007-01-02|APT Task doesn't fail if forked process dies with |
|41292|New|Nor|2007-01-04|javadoc task: sourcepath for JDK sources broken |
|41303|New|Nor|2007-01-05|P4Label task does not set label owner |
|41307|New|Nor|2007-01-05|Single quoted command line properties are evaluate|
|41356|New|Enh|2007-01-12|Output all checksums to single file |
|41400|New|Nor|2007-01-18|properties get double expanded in <assertPropertyE|
|41402|New|Maj|2007-01-18|The task ChangeLog doesn't work if the svn server |
|41413|Ass|Reg|2007-01-19|woproject woapplication copy to wrong directory |
|41534|New|Enh|2007-02-02|"quiet" Formatter for Ant's JUnit Task |
|41622|Opn|Blk|2007-02-15|ant.bat not working on win2k |
|41630|New|Maj|2007-02-16|missing -follow attribute to the CCMKLabel Task |
|41737|New|Min|2007-02-28|sqltask: Semicolon in c-style multiline comments f|
|41784|New|Enh|2007-03-07|for the apply task, resultproperty should be set w|
|41890|New|Nor|2007-03-19|exec > env > key value not set correctly. |
|41907|New|Enh|2007-03-20|Its nice to have a Task that can genarate certific|
|41924|New|Nor|2007-03-21|Untar target does not handle long filenames in POS|
|41961|New|Nor|2007-03-27|StarTeam Checkout does not update case of filename|
|41985|New|Enh|2007-03-29|Zip task doesnt pick up the read-only state of fil|
|41986|New|Enh|2007-03-29|Add 'quiet' attribute to 'copy' task |
|42044|New|Enh|2007-04-04|Multiple/composite logs for ant builds |
|42046|New|Nor|2007-04-04|properties get double-expanded in macrodefs |
|42143|New|Enh|2007-04-17|Boolean expressions in if and unless attributes |
|42304|New|Nor|2007-04-30|P4Label task doesn't support the new 'revision' fi|
|42410|New|Enh|2007-05-14|New ant task sugestion... <inject-xml> |
|42447|New|Enh|2007-05-17|Add support for conditions to echo task and arg el|
|42462|New|Enh|2007-05-20|Contributing optional task for ClearCase findmerge|
|42482|New|Nor|2007-05-21|ant and subant improperly passes references to mac|
|42500|New|Nor|2007-05-23|tar task is incompatible with BusyBox v1.3.1 (the |
|42511|New|Nor|2007-05-24|FixCrLf task changes file security settings on Win|
|42519|New|Nor|2007-05-25|Incomplete Junit reporter |
|42544|New|Nor|2007-05-29|cannot have multiple input tasks with command line|
|42594|New|Enh|2007-06-05|add a <checksummed> resource which can checksum a |
|42609|New|Min|2007-06-06|ant.bat -noclasspath in ANT_ARGS should clearclass|
|42631|New|Nor|2007-06-11|Antlib's xmlns "ant:current" ignored in scriptdef |
|42696|New|Maj|2007-06-19|OutOfMemoryError using unzip Task |
|42702|New|Enh|2007-06-20|resource enable ReplaceTokens filter |
|42742|New|Nor|2007-06-26|big Ant/Ivy builds run out of permanent memory. Cl|
|42787|New|Min|2007-07-01|Relax restricion on quiet and failonerror attribut|
|42788|New|Enh|2007-07-01|Add 'quiet' attribute to 'mkdir' task |
|42824|New|Nor|2007-07-05|p4labelsync cannot use revision paths with timesta|
|42828|New|Enh|2007-07-06|Preserve return code of called batch files from ex|
|42838|New|Enh|2007-07-09|Support for JSR 199: Java Compiler API |
|42964|Ass|Maj|2007-07-24|wrong target invoked (when project name is prefix |
|43004|Inf|Nor|2007-07-31|OutOfMemory caused by System.out when running simp|
|43032|New|Reg|2007-08-04|jar reports warning class modified in future on Wi|
|43139|New|Nor|2007-08-15|unjar task does NOT unjar JAR files > 10Gigabytes |
|43144|New|Nor|2007-08-16|tar task is very slow when a <zipfileset> is used |
|43186|New|Nor|2007-08-22|tar task does not add entries for folders |
|43271|New|Enh|2007-08-31|scp task should support setting permissions |
|43315|New|Enh|2007-09-05|scriptdef should be able to load multiple script f|
|43349|New|Enh|2007-09-10|Add ability to specify a multiplier to all memory |
|43362|New|Enh|2007-09-12|Add conditional attributes |
|43368|New|Enh|2007-09-12|ClearCase lsco fileset selector |
|43413|New|Maj|2007-09-18|ant sql task tries to execute commented lines with|
|43428|New|Enh|2007-09-19|Resource Framework: Reading attributes of a resour|
|43443|New|Nor|2007-09-21|STCHECKIN ignores the Include arg when AddUncontro|
|43447|New|Enh|2007-09-21|Use Java 5 attributes as a replacement for XDoclet|
|43546|New|Enh|2007-10-04|JUnit Test Filtering, junit task extension |
|43558|Opn|Enh|2007-10-04|Ant created zips do not set internal_file_attribut|
|43582|New|Enh|2007-10-09|Write log messages from test to AntUnit's log |
|43586|Opn|Nor|2007-10-10|java.io.FileNotFoundException: /home/***/apache-an|
|43630|New|Enh|2007-10-15|Add a "wsdl" Nested element to the Ant WAR task |
|43794|New|Nor|2007-11-04|Message about JAVA_HOME is confusing |
|43852|New|Nor|2007-11-13|No encoding support for <junitreport> |
|43907|New|Enh|2007-11-19|Feature request : Minify a set of JS/CSS files |
|43921|New|Nor|2007-11-20|JavaEnvUtils.getJreExecutable() returns wrong exec|
|43969|New|Nor|2007-11-26|JUnit4 tests marked @Ignore do not appear in XML o|
|44045|New|Enh|2007-12-08|example unit test cases to create new JUnitReport |
|44081|New|Enh|2007-12-14|compilerarg should support ranges |
|44220|New|Enh|2008-01-14|[Patch] Link to log files from junitreport generat|
|44236|New|Nor|2008-01-14|IsReachable Issue |
|44239|New|Enh|2008-01-15|Add ability of Ant resource classes to act as fact|
|44241|New|Enh|2008-01-15|add JavaConstantResource to read string constants.|
|44242|New|Enh|2008-01-15|Add <funtest> task for functional testing |
|44549|New|Cri|2008-03-06|Delete with an empty includesfile deletes all file|
|44660|New|Enh|2008-03-23|Task 'get' should display human readable error mes|
|44661|New|Enh|2008-03-23|Task 'get' should should allow alternative paths. |
|44718|New|Enh|2008-03-31|allow 'if' and 'unless' on macrodef |
|44740|New|Enh|2008-04-02|scp task (sftp) delete remote files |
|44756|Opn|Maj|2008-04-04|Can't get a class name or stack trace for NoClass|
|44795|New|Enh|2008-04-10|Provide facility to copy nested tasks as in MacroI|
|44816|New|Enh|2008-04-13|Enhancement to tar-task (and maybe zip-task) |
|44868|New|Enh|2008-04-24|tar - lzma compression |
|44900|Ass|Maj|2008-04-29|Using ant java api: Exec: Nested args are not pass|
|45057|New|Enh|2008-05-21|Support EOL conversion in tar/zip tasks |
|45089|New|Enh|2008-05-28|tstamp granularity attribute |
|45135|Opn|Reg|2008-06-05|Ant 1.7.0: a patternset reference cannot be redefi|
|45142|New|Maj|2008-06-05|Delete Action does not delete unix path with "\" i|
|45143|New|Nor|2008-06-05|add property setting to existing property evaluato|
|45228|New|Enh|2008-06-18|more specific Error Starting Modern Compiler messa|
|45262|New|Enh|2008-06-23|Request viewpathing support for Ant |
|45316|New|Maj|2008-07-01|Ant RPM task is unable to build RPM package due to|
|45429|New|Enh|2008-07-18|the zip package should support "more modern" zip f|
|45530|New|Nor|2008-08-03|ANT incorrectly copies env.variables with non-lati|
|45536|New|Nor|2008-08-04|JUnit PlainJUnitResultFormatter goes OOM at the en|
|45612|New|Enh|2008-08-11|[Patch] Subproject Addressing and Simulation Mode |
|45692|New|Enh|2008-08-26|Allow Antlibs to contribute version information & |
|45696|New|Enh|2008-08-27|Slow classpath building with referenced paths. |
|45718|New|Enh|2008-08-31|Enhance bzip2 for Hadoop |
|45750|New|Enh|2008-09-05|URI support as source |
|45786|Inf|Maj|2008-09-11|ANT and NFS, Delete task - "Unable to delete direc|
|45807|New|Enh|2008-09-15|Ant and optional libs as OSGi Bundles |
|45819|New|Enh|2008-09-16|[FilterSet] allow inclusion / exclusion patterns o|
|45860|New|Enh|2008-09-22|Optional classpath entry support for FTP task |
|46034|New|Enh|2008-10-17|[Main] Add support for build.ant as default build |
|46058|New|Maj|2008-10-21|Ant needs a streamable log format |
|46060|New|Trv|2008-10-21|ClassLoader task - will need manual documentation |
|46087|Inf|Enh|2008-10-25|Aggregating filesets is *functionally* possible an|
|46088|New|Enh|2008-10-25|Performance (speed) of large path(s) must be impro|
|46117|New|Enh|2008-10-29|Append property prefix to entries in property file|
|46135|Inf|Nor|2008-10-31|Regression: scriptcondition fails on 1.7.1 |
|46171|New|Enh|2008-11-09|Define standard directory layout |
|46305|Inf|Nor|2008-11-26|Hung forked JVM when reading from standard input |
|46326|Opn|Enh|2008-12-02|StarTeam: Use Cache Agent for Checkouts |
|46328|Inf|Nor|2008-12-02|Ant 1.6.5: FIXCRLF on Windows XP fails with IOExce|
|46331|New|Enh|2008-12-03|Get the related Task object from the Condition imp|
|46488|New|Enh|2009-01-07|Missing i18n support in ANT |
|46625|New|Nor|2009-01-29|large outputs from sshexec |
|46781|New|Enh|2009-02-27|<input><handler type="secure"/></input> with impl |
|46783|New|Nor|2009-03-01|erroronmissingdir not supported by javac task |
|46794|New|Enh|2009-03-03|ssl with ftp |
|46805|Opn|Nor|2009-03-05|ant exec hangs when invoking "asadmin.bat start-do|
|46842|New|Enh|2009-03-12|Support Classpath Wildcards |
|46877|New|Nor|2009-03-19|Taskdef uses wrong class loader |
|46895|New|Min|2009-03-23|Caching documents from ant.apache.org requires add|
|47002|New|Enh|2009-04-08|junitreport: expose classpath of internal XSLTProc|
|47003|New|Enh|2009-04-08|Add to ant lib classpath from within project file |
|47007|New|Nor|2009-04-09|On z/OS, environment variables mishandled when spe|
|47010|Inf|Enh|2009-04-09|Sync task cannot compare file contents |
|47035|Opn|Enh|2009-04-15|Property expansion in macro attributes and element|
|47047|New|Enh|2009-04-17|Add buildroot to RPM |
|47117|New|Enh|2009-04-29|Concat resource doesn't calculate its size |
|47119|New|Nor|2009-04-29|properties not expanded in default attributes |
|47126|New|Nor|2009-04-30|cvschangelog force <msg> encoding to platform defa|
|47153|New|Enh|2009-05-05|Support tar files > 8 GByte |
|47163|New|Enh|2009-05-07|Contributed task: #include |
|47168|New|Min|2009-05-08|Zipfileset does not include empty directories |
|47218|New|Enh|2009-05-19|Include element and attribute reference in manual |
|47254|New|Enh|2009-05-22|switch between light.exe and lit.exe |
|47303|New|Trv|2009-06-02|Copy failonerror is internally inconsistent with W|
|47373|New|Enh|2009-06-16|Zip.java patch to support setting last modified da|
|47381|New|Nor|2009-06-17|XmlProperty doesn't allow propertvalues with only |
|47414|New|Enh|2009-06-24|Add Ftp ant task timeout |
|47423|New|Enh|2009-06-25|next to attribute granularity: offset |
|47529|New|Nor|2009-07-14|[PATCH] allow flexible trunk, tag, and branch loca|
|47552|New|Enh|2009-07-20|scp task should support compression |
|47558|New|Nor|2009-07-22|Assertion status silently ignored by <junit> if un|
|47642|New|Nor|2009-08-04|PumpStreamHandler can interleave I/O in incorrect |
|47702|New|Enh|2009-08-18|enable resource collections in rmic |
|47704|New|Enh|2009-08-18|Allow Project to take an XMLCatalog instance for u|
|47715|New|Enh|2009-08-20|filterchain-based validation identifies line numbe|
|47775|New|Nor|2009-09-01|non forked ant java task exits immediately on Mac |
|47787|Inf|Reg|2009-09-04|FTP Optional task is not found ONLY WHEN run using|
|47790|Inf|Blk|2009-09-05|javadoc: don't create packagenames option if files|
|47821|Opn|Nor|2009-09-11|Touch task doesn't work on Solaris for a file whic|
|47854|New|Enh|2009-09-16|Ant can't run within another Java program |
|47860|New|Enh|2009-09-17|[PATCH] ftp task to provide feedback on succeeded/|
|47914|New|Maj|2009-09-28|< and > not quoted by quoteArgument causes failure|
|47955|New|Nor|2009-10-07|SchemaValidate doc. doesn't show task element name|
|47984|New|Maj|2009-10-12|Ant's regexp mapper expects that the regex matches|
|47995|New|Nor|2009-10-14|StarTeam: The 'StarTeam exclusive lock' option is |
|47996|New|Nor|2009-10-14|StarTeam: addUncontrolled option doesn't work |
|48001|New|Nor|2009-10-15|Document differences between tasks' usage of mappe|
|48008|Opn|Nor|2009-10-15|touch task truncates timestamps |
|48010|Inf|Cri|2009-10-16|'timeout' parameter not working in Sshexec task |
|48041|Inf|Maj|2009-10-22|javadoc task offline="true" doesn't work |
|48058|New|Enh|2009-10-26|tar task looses file permissions |
|48078|New|Nor|2009-10-28|Clarification for documentation for difference sel|
|48127|Inf|Maj|2009-11-04|build.xml:target crash |
|48128|New|Maj|2009-11-04|Ant input task failing to read input from console |
|48152|New|Nor|2009-11-06|Task ManifestClassPath fail to find suitable relat|
|48171|New|Enh|2009-11-11|task javadoc: add a refid kind of reference for th|
|48186|New|Nor|2009-11-12|ant.bat file ignores -noclasspath if it is the fir|
|48199|New|Enh|2009-11-15|add a configuration to set the build file name to |
|48212|Unc|Nor|2009-11-17|Ant-Doxygen |
|48225|New|Enh|2009-11-18|import task reference environment variable |
+-----+---+---+----------+--------------------------------------------------+
| Total 574 bugs |
+---------------------------------------------------------------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-21T10:52:14Z

Le 19 nov. 2009 à 12:06, Xavier Hanin a écrit :

> I really like the idea to use a solr instance colocated with the repository.
> I've seen a presentation on solr yesterday at devoxx, and it sounds like so
> close to what we need. The only problem I see with it is that it requires to
> install a server side component, getting closer to what repository managers
> do. I'm not sure about why if we install a slor instance we wouldn't use it
> to update the index too. Solr takes care of problems like transactions,
> concurrency, so I think it's a perfect fit...

I think the transaction would be supported at the Lucene index level. I don't think there is any mechanism to make solr manage an extra "data storage". As far as I remember Solr is just able to read the external "data storage" to index it.
But what would work is a Solr deployed just next to an Ivy repository, let Ivy publish artifacts like it already does, but also make Ivy request Solr to index the newly published artifact.

And spotted by a friend, Solr 1.4 [1] support replication in Java [2] ala rsync !

So Solr might be the easiest way of achieving an Ivy indexer.

I have to admit I am not a big fan of having to deploy a webapp next to a dumb simple repo. On the other hand managing an index on the client side depends enormously of the kind of repository (at work we have an ivy repo in svn accessible form both http and checkouted), it would consume more bandwidth, some publication locking would probably be in place, etc...

Nicolas

[1] http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.4.0/CHANGES.txt
[2] https://issues.apache.org/jira/browse/SOLR-561

>
> My 2 c.
>
> Xavier
>
> 2009/11/18 Jon Schneider <jkschneider@...>
>
>> While I digest Nicolas' novel :) (thanks for the additional insight on
>> Lucene by the way), I will suggest one other idea.
>>
>> We could allow for the option of a Solr instance collocated with the
>> repository on one machine to serve up the index stored on the repository.
>> IvyDE could be configured by the user to either read the index directly
>> from the remote filesystem or send its requests via HTTP to a Solr server.
>> The Solr server would not be responsible for maintaining the index in the
>> same way that Archiva/Nexus/Artifactory do, but would simply be a querying
>> tool. In the case where Solr is serving the index, the index would still
>> be
>> maintained through some combination of the index ant task and the publish
>> proxy.
>>
>> This way we don't get into the complexity of pushing out index updates to
>> clients.
>>
>> The rsync strategy is a very intriguing idea though, especially in light of
>> how Lucene segments its index in multiple files. What happens when
>> optimize
>> is called on the index and the segments are combined into one file? In
>> this
>> case, any search slaves would essentially have to download the whole index
>> right? How much segmentation is considered too much segmentation before we
>> optimize the index to cater to search speed over index publishing speed?
>>
>> I'll be trying to wrap this up enough (at least with the remote filesystem
>> index read strategy) to make a patch so others can see it in action. We
>> are
>> a little busy at work, but I will be coming back to it in the coming days.
>>
>> Thanks for all the feedback so far,
>> Jon
>>
>
>
>
> --
> Xavier Hanin - 4SH France - http://www.4sh.fr/
> BordeauxJUG creator & leader - http://www.bordeauxjug.org/
> Apache Ivy Creator - http://ant.apache.org/ivy/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-21T10:46:28Z

Le 18 nov. 2009 à 20:17, Jon Schneider a écrit :

yep, it merges them all in one.

> In this
> case, any search slaves would essentially have to download the whole index
> right?

exactly. The publisher of the indexes shouldn't do any optimization on the indexes. The receiver shouldn't do either to have the same files as the publisher. On the client side it may be interesting to optimize the index for performance: it will just maintain two indexes, one for synchronizing with the publisher, and a clone which is then optimized.

> How much segmentation is considered too much segmentation before we
> optimize the index to cater to search speed over index publishing speed?

It is done automatically by Lucene itself with the merge policy:
http://lucene.apache.org/java/2_9_1/api/core/org/apache/lucene/index/MergePolicy.html

Nicolas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

RE: Feature Request - import task use environment variable

2009-11-19T04:26:31Z

The idea of the ANT_IMPORT_PATH is to provide a list of possible locations to import a file from. Our shop places software either in $HOME/local (if you're compiling from source and do an "ant install"), $HOME/rpm (if you've installed from an rpm), or / (if installed as root). This setup would allow me to set ANT_IMPORT_PATH to "$HOME/local:$HOME/rpm:/" and include the file with a simple import statement. I'm looking to place the search paths in a variable (similar to CPLUS_INCLUDE_PATH for g++ compiler) and have the import task use the first found file.

If I use the current implementation, I'd have to add a number of path elements to the build.xml file. I prefer to keep the build.xml file as small and clean as possible, so I'd prefer not to do this.

smime.p7s (6K) Download Attachment

Re: Ivy Indexer

2009-11-19T03:06:52Z

I really like the idea to use a solr instance colocated with the repository.
I've seen a presentation on solr yesterday at devoxx, and it sounds like so
close to what we need. The only problem I see with it is that it requires to
install a server side component, getting closer to what repository managers
do. I'm not sure about why if we install a slor instance we wouldn't use it
to update the index too. Solr takes care of problems like transactions,
concurrency, so I think it's a perfect fit...

My 2 c.

Xavier

2009/11/18 Jon Schneider <jkschneider@...>

> While I digest Nicolas' novel :) (thanks for the additional insight on
> Lucene by the way), I will suggest one other idea.
>
> We could allow for the option of a Solr instance collocated with the
> repository on one machine to serve up the index stored on the repository.
> IvyDE could be configured by the user to either read the index directly
> from the remote filesystem or send its requests via HTTP to a Solr server.
> The Solr server would not be responsible for maintaining the index in the
> same way that Archiva/Nexus/Artifactory do, but would simply be a querying
> tool. In the case where Solr is serving the index, the index would still
> be
> maintained through some combination of the index ant task and the publish
> proxy.
>
> This way we don't get into the complexity of pushing out index updates to
> clients.
>
> The rsync strategy is a very intriguing idea though, especially in light of
> how Lucene segments its index in multiple files. What happens when
> optimize
> is called on the index and the segments are combined into one file? In
> this
> case, any search slaves would essentially have to download the whole index
> right? How much segmentation is considered too much segmentation before we
> optimize the index to cater to search speed over index publishing speed?
>
> I'll be trying to wrap this up enough (at least with the remote filesystem
> index read strategy) to make a patch so others can see it in action. We
> are
> a little busy at work, but I will be coming back to it in the coming days.
>
> Thanks for all the feedback so far,
> Jon
>

--
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

Re: Feature Request - import task use environment variable

2009-11-18T21:15:43Z

On 2009-11-18, Kantor, H Steve Jr CIV NSWC PC <harry.kantor@...> wrote:

> I would like to have the import task use an environment variable
> (ANT_IMPORT_PATH) when importing files.

Can't this already be done?

<property environment="env"/>
<import file="${env.ANT_IMPORT_PATH}"/>

> Is there any interest in this?

Right now I don't see the general use, but maybe I'm overlooking
something. In what way would the change improve the current
implementation that would be difficult/cumbersome to do right now?

Please note that in svn's trunk <import> supports importing resource
collections and thus opens up a whole lot of new possibilities.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-18T20:53:50Z

On 2009-11-18, Matt Benson <gudnabrsam@...> wrote:

> Stefan, I don't see that info there, so I'll note here that the proxy
> to configure to see p.a.o immediately is 140.211.11.10:80 .

Thanks.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-18T11:17:23Z

While I digest Nicolas' novel :) (thanks for the additional insight on
Lucene by the way), I will suggest one other idea.

We could allow for the option of a Solr instance collocated with the
repository on one machine to serve up the index stored on the repository.
IvyDE could be configured by the user to either read the index directly
from the remote filesystem or send its requests via HTTP to a Solr server.
The Solr server would not be responsible for maintaining the index in the
same way that Archiva/Nexus/Artifactory do, but would simply be a querying
tool. In the case where Solr is serving the index, the index would still be
maintained through some combination of the index ant task and the publish
proxy.

This way we don't get into the complexity of pushing out index updates to
clients.

The rsync strategy is a very intriguing idea though, especially in light of
how Lucene segments its index in multiple files. What happens when optimize
is called on the index and the segments are combined into one file? In this
case, any search slaves would essentially have to download the whole index
right? How much segmentation is considered too much segmentation before we
optimize the index to cater to search speed over index publishing speed?

I'll be trying to wrap this up enough (at least with the remote filesystem
index read strategy) to make a patch so others can see it in action. We are
a little busy at work, but I will be coming back to it in the coming days.

Thanks for all the feedback so far,
Jon

Re: Ivy Indexer

2009-11-18T10:04:46Z

On Tuesday 17 November 2009 16:55:21 Jon Schneider wrote:

> > When you say "anywhere you choose", is it limited to a location on the
> > filesystem? Or do you intend to make use of ivy repositories
>
> access/publish
>
> > mechanism to store the index remotely? With filesystem only the usage
> > sounds rather limited. With ivy repository mechanism you can store your
> > index on the same kind of store as where you put your modules, but you
>
> will
>
> > need a more advanced syntax to configure it, and more advanced
> >
> > implementation.
>
> Right now it is limited to locations on the filesystem. I agree, the
> repository mechanism would be more flexible, but I do need to evaluate the
> performance of storing/reading the index across different storage mediums.
>
> > So you will have to deal with index locking during updates, which may
> > become a contention point, and be difficult to implement if you want to
> >
> > allow using any repo to store the index.
>
> Thanks for bringing this point up. Lucene offers a write lock contention
> mechanism, but I do need to tread carefully here.
>
> > If the index grows, accessing the index from a remote box may become
> > long. If you think big, you will have to find a way to transfer index
> > updates to the clients which is optimizing the network, such as
> > transferring diffs or something similar. But this becomes difficult to
> > implement, unless you
>
> want
>
> > to rely on existing technology for that (such as a SCM).
>
> I am having trouble trying to manufacture a scalability problem here (with
> my unscientific approach). I am up to 1,149 jars containing class types
> with over 28,700 types in my test repository and the index is at 39 mb.

Did you tried to compress it ? I would expect that the index would be
transferred compressed over the network.

> I've pushed the index out on a remote filesystem, and the quick search
> opens the index in 219 ms. After the index reader is opened, subsequent
> searches return in the microsecond range until the reader becomes stale
> from a commit and is reopened.
>
> Interesting point about the growth of the index based on the topology of
> the repository: modules with hundreds or thousands of revisions (e.g.
> nightly builds) do not add much bulk to the index because there is so much
> overlap in type names across the builds. The duplicate type names get
> optimized down.
>
>
> The last time I worked with Lucene we implemented a such diff and publish
>
> > mecanism for Lucene indexes, and it was working quite well. Solr does
> > have a
> > mecanism for such things too, but the last time I checked it was just
> > relying
> > on rsync. If somebody is interested I can take some time to explain it
> > here.
>
> Not totally convinced that a scalability problem is out of the question,
> I'm interested in what you have to offer on this point, Nicolas.

We used a feature of Lucene which allows to merge two indexes, adding every
Lucene document from one index into another [1].
The issue here is that Lucene has no notion of replacing a document. So a
Lucene index update was both a Lucene index with the new indexed data and a
list of the ids of the documents to delete or update. Then applying an index
update on a "full" index is deleting the specified list of documents and
merging the index update in the full index.

Note that it only works if a Lucene document can be uniquely identified. For
the Ivy use case I think this can fit as the unique id would be the
org#module;revision

To track the version of the index, Lucene itself provides a version number
[2]. I don't remember well if we can rely safely on it. I think we did, but
it might work only if the exact same version of Lucene is used everywhere, as
the segment merging algorithm would be the same. At least the Lucene API
doesn't garanty that a merge of two indexes produce the same version, the API
just garanties that it will be upper on each "commit".

In our use case we had the situation where there was an indexer and sevral
search slaves. The indexer was responsible to publish a full index and a set
of index updates. So that a search slave starting empty will just get the full
index. And along the time, a slaves asks the indexer just updates
corresponding to its version. So there may be situation were the slave is a
little late, and will get sevral updates to apply. And sometimes so late that
the slave will get a full index, as the indexer just maintains a finite set
of index updates.

That scenario is corresponding quite well of one of the case described where
an Ivy repository is managed on the server side.

Managing it from the client side maybe more complex, as Lucene only support
only one writer at a time. But we can imagine that each time there is a
publish, there would also be a "publication" of an "index update". Then the
complexity is reported on a periodic purge of old updates and a build of a
full index: which client would be "elected" to do it ? And how do we deal
with simultaneous publication ?

Few words on Solr's [3] index replication mechanism. As previously wrote, the
transport of the files is done by some rsync. This is actually quite smart
knowing how the Lucene indexer works with files.
First it never modifies files or never append data to a file. Once wrote a
file doesn't change (see the API it is relying on [4]). So a diff between two
versions of an index is some deleted files and some new files.
Secondly, when we index new data on a already filled index, as Lucene doesn't
modify any file, it will actually create an internal "segment" containing the
new indexed data. Opening an new IndexReader on the new version of the index
is then taking into consideration the added segment. As we index data, there
are then more and more segments. To avoid having to many files, sometimes it
decides to merge sevral little segments into a bigger one [5]. So we can say
that a Lucene index is composed of big old files and little new ones.
So this quite perfect for rsync. The more you rsync, the less you have to
transport on each run.

We didn't like relying on some platform dependant tool and we liked the idea
that an index update is just a zip of files (we actaully had some other data
to update, so one file for all). What we implemented is actually quite
similar to how Lucene works with its internal "segments": the update contains
just the new indexed data, older update being the full index itself.

I don't think Ivy should rely on rsync either, but probably we could use the
same kind of mechanism rsync use. It would be quite easy to implement as
there would be no binary diff. It doesn't solve the critical case where there
is a simultaneous publication though.

I am starting to have ideas, but I think that this mail is already too long,
let's take a breath :)

Nicolas

[1]
http://lucene.apache.org/java/2_9_1/api/all/org/apache/lucene/index/IndexWriter.html#addIndexes%28org.apache.lucene.index.IndexReader[]%29
[2]
http://lucene.apache.org/java/2_9_1/api/all/org/apache/lucene/index/IndexReader.html#getVersion%28%29
[3] http://lucene.apache.org/solr/
[4]
http://lucene.apache.org/java/2_9_1/api/all/org/apache/lucene/store/Directory.html
[5]
http://lucene.apache.org/java/2_9_1/api/all/org/apache/lucene/index/MergePolicy.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-18T07:21:28Z

Stefan, I don't see that info there, so I'll note here that the proxy
to configure to see p.a.o immediately is 140.211.11.10:80 .

On Nov 17, 2009, at 10:52 PM, Stefan Bodewig wrote:

> On 2009-11-17, Jon Schneider <jkschneider@...> wrote:
>
>> The "svn up" on people.apache.org updated contributors.html, but
>> the change
>> was not reflected on the site. I assume there is some other job
>> that picks
>> up changes or this is done at release time?
>
> Ah, yes, I forgot that. people.apache.org is not the live site, it is
> rsynced to the public site once an hour (or any x hours, the details
> escape me). I think there is a paragraph or two somewhere on
> http://www.apache.org/dev/ that also shows how to configure your proxy
> if you want to review the contents of people.apakche.org.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

AW: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-17T23:29:41Z

I updated the docs.xml with these information.

Jan

>-----Ursprüngliche Nachricht-----
>Von: Stefan Bodewig [mailto:bodewig@...]
>Gesendet: Mittwoch, 18. November 2009 05:52
>An: dev@...
>Betreff: Re: svn commit: r880829 -
>/ant/core/trunk/xdocs/contributors.xml
>
>On 2009-11-17, Jon Schneider <jkschneider@...> wrote:
>
>> The "svn up" on people.apache.org updated contributors.html,
>but the change
>> was not reflected on the site. I assume there is some other
>job that picks
>> up changes or this is done at release time?
>
>Ah, yes, I forgot that. people.apache.org is not the live site, it is
>rsynced to the public site once an hour (or any x hours, the details
>escape me). I think there is a paragraph or two somewhere on
>http://www.apache.org/dev/ that also shows how to configure your proxy
>if you want to review the contents of people.apakche.org.
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@...
>For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r881624 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs: SubAnt.java optional/PropertyFile.java

2009-11-17T20:59:47Z

On 2009-11-18, <jglick@...> wrote:

>> } catch (IOException x) {
>> propertyfile.delete(); // possibly corrupt
>> throw new BuildException(x, getLocation());
>> } finally {
>> os.close();
>> }

Is this going to work on an OS that locks files by default? I mean,
will the task be able to delete the file before it is closed?

It may be a good idea to use FileUtils.tryHardToDelete anyway (and
FileUtils.close 8-).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-17T20:52:30Z

On 2009-11-17, Jon Schneider <jkschneider@...> wrote:

> The "svn up" on people.apache.org updated contributors.html, but the change
> was not reflected on the site. I assume there is some other job that picks
> up changes or this is done at release time?

Ah, yes, I forgot that. people.apache.org is not the live site, it is
rsynced to the public site once an hour (or any x hours, the details
escape me). I think there is a paragraph or two somewhere on
http://www.apache.org/dev/ that also shows how to configure your proxy
if you want to review the contents of people.apakche.org.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Feature Request - import task use environment variable

2009-11-17T15:27:19Z

All,

I would like to have the import task use an environment variable (ANT_IMPORT_PATH) when importing files. Is there any interest in this? I've already implemented and can provide a patch for testing.

Thanks,
Harry

smime.p7s (6K) Download Attachment

Re: Ivy Indexer

2009-11-17T08:30:05Z

2009/11/17 Jon Schneider <jkschneider@...>

>
> > If the index grows, accessing the index from a remote box may become
> long.
> > If you think big, you will have to find a way to transfer index updates
> to
> > the clients which is optimizing the network, such as transferring diffs
> or
> > something similar. But this becomes difficult to implement, unless you
> want
> > to rely on existing technology for that (such as a SCM).
>
> I am having trouble trying to manufacture a scalability problem here (with
> my unscientific approach). I am up to 1,149 jars containing class types
> with over 28,700 types in my test repository and the index is at 39 mb.
> I've pushed the index out on a remote filesystem, and the quick search
> opens the index in 219 ms. After the index reader is opened, subsequent
> searches return in the microsecond range until the reader becomes stale
> from
> a commit and is reopened.
>

Yes, I think the main point is to "get" the index locally. At 39mb depending
on your bandwidth to the remote server it can take time... and having to
doanload the full index each time it is modified sounds scary. But maybe
Nicolas has good things to share about that.

Xavier

--
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

Re: Ivy Indexer

2009-11-17T07:55:21Z

> When you say "anywhere you choose", is it limited to a location on the
> filesystem? Or do you intend to make use of ivy repositories
access/publish
> mechanism to store the index remotely? With filesystem only the usage
> sounds rather limited. With ivy repository mechanism you can store your
> index on the same kind of store as where you put your modules, but you
will
> need a more advanced syntax to configure it, and more advanced
> implementation.

Right now it is limited to locations on the filesystem. I agree, the
repository mechanism would be more flexible, but I do need to evaluate the
performance of storing/reading the index across different storage mediums.

> So you will have to deal with index locking during updates, which may
> become a contention point, and be difficult to implement if you want to
> allow using any repo to store the index.

Thanks for bringing this point up. Lucene offers a write lock contention
mechanism, but I do need to tread carefully here.

> If the index grows, accessing the index from a remote box may become long.
> If you think big, you will have to find a way to transfer index updates to
> the clients which is optimizing the network, such as transferring diffs or
> something similar. But this becomes difficult to implement, unless you
want
> to rely on existing technology for that (such as a SCM).

I am having trouble trying to manufacture a scalability problem here (with
my unscientific approach). I am up to 1,149 jars containing class types
with over 28,700 types in my test repository and the index is at 39 mb.
I've pushed the index out on a remote filesystem, and the quick search
opens the index in 219 ms. After the index reader is opened, subsequent
searches return in the microsecond range until the reader becomes stale from
a commit and is reopened.

Interesting point about the growth of the index based on the topology of the
repository: modules with hundreds or thousands of revisions (e.g. nightly
builds) do not add much bulk to the index because there is so much overlap
in type names across the builds. The duplicate type names get optimized
down.

The last time I worked with Lucene we implemented a such diff and publish
> mecanism for Lucene indexes, and it was working quite well. Solr does have
> a
> mecanism for such things too, but the last time I checked it was just
> relying
> on rsync. If somebody is interested I can take some time to explain it
> here.
>

Not totally convinced that a scalability problem is out of the question, I'm
interested in what you have to offer on this point, Nicolas.

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-17T06:59:18Z

Yep, the site is typically updated on-demand, apparently from
Stefan's last email by simply doing an svn up in people.apache.org:/
www/ant.apache.org, which appears to have been done. :)

On Nov 17, 2009, at 8:56 AM, Jon Schneider wrote:

> 2009/11/17 Nicolas Lalevée <nicolas.lalevee@...>
>
>> Actually the last time I generated ant's site, I just downloaded a
>> standard
>> velicity 1.4 binary distrib and did:
>> ant -f docs.xml -Dvelocity.dir=..../velocity-1.4
>>
>> Just like the inline doc says. And it worked like a charm.
>> I am not sure what is the best though.
>>
>> Nicolas
>
>
>
> Sounds valid to me too.
>
> The "svn up" on people.apache.org updated contributors.html, but
> the change
> was not reflected on the site. I assume there is some other job
> that picks
> up changes or this is done at release time?
>
> Jon

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-17T06:56:00Z

2009/11/17 Nicolas Lalevée <nicolas.lalevee@...>

> Actually the last time I generated ant's site, I just downloaded a standard
> velicity 1.4 binary distrib and did:
> ant -f docs.xml -Dvelocity.dir=..../velocity-1.4
>
> Just like the inline doc says. And it worked like a charm.
> I am not sure what is the best though.
>
> Nicolas

Sounds valid to me too.

The "svn up" on people.apache.org updated contributors.html, but the change
was not reflected on the site. I assume there is some other job that picks
up changes or this is done at release time?

Jon

Re: Ivy Indexer

2009-11-17T06:50:11Z

On Tuesday 17 November 2009 15:18:13 Xavier Hanin wrote:

> 2009/11/16 Jon Schneider <jkschneider@...>
>
> > On Sat, Nov 14, 2009 at 9:42 AM, Xavier Hanin <xavier.hanin@...
> >
> > >wrote:
> > >
> > > One thing I'm not sure to fully understand: it seems that you plan to
> >
> > store
> >
> > > the index on the client (say the developer's box), according to your
> > > example
> > > with dir="${ivy.settings.dir}/index". But it also seems like every
> > > client will have the responsibility to maintain the index, is that
> > > right?
> >
> > Sound's
> >
> > > strange, there's probably something I miss?
> >
> > As a best practice recommendation, I would suggest that the index be
> > stored on the same box as the repository (of course, I think the index
> > task and the
> > proxying resolver should allow for the index to be stored anywhere you
> > choose).
>
> When you say "anywhere you choose", is it limited to a location on the
> filesystem? Or do you intend to make use of ivy repositories access/publish
> mechanism to store the index remotely? With filesystem only the usage
> sounds rather limited. With ivy repository mechanism you can store your
> index on the same kind of store as where you put your modules, but you will
> need a more advanced syntax to configure it, and more advanced
> implementation.
>
> > I do not see any reason for there to be more than one index per
> > repository.
> >
> > This single index should be as close to representative of the real-time
> > state of the repository as possible. In the case where repository
> > artifacts
> > are added mainly through publish/deliver/install and these tasks are
> > routed through the indexing proxy, the index will always match the
> > real-time state of the repository. In the case where repository
> > artifacts are added manually by a repository administrator, the index
> > will lack the types defined in these artifacts until the administrator
> > runs the index task.
> >
> > Thus, the responsibility for maintaining the index belongs with the some
> > combination of the proxying resolver and the index task, their precise
> > relationship being defined by the use case.
>
> So you will have to deal with index locking during updates, which may
> become a contention point, and be difficult to implement if you want to
> allow using any repo to store the index.
>
> > All clients would then read from the same index. The Quick Search
> > feature only reads the index, it does not modify it.
>
> If the index grows, accessing the index from a remote box may become long.
> If you think big, you will have to find a way to transfer index updates to
> the clients which is optimizing the network, such as transferring diffs or
> something similar. But this becomes difficult to implement, unless you want
> to rely on existing technology for that (such as a SCM).

The last time I worked with Lucene we implemented a such diff and publish
mecanism for Lucene indexes, and it was working quite well. Solr does have a
mecanism for such things too, but the last time I checked it was just relying
on rsync. If somebody is interested I can take some time to explain it here.

Nicolas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-17T06:31:19Z

On Tuesday 17 November 2009 05:51:59 Stefan Bodewig wrote:

> On 2009-11-16, Matt Benson <gudnabrsam@...> wrote:
> > *I* still don't know how to re-generate the site. :/
>
> The hardest part used to be getting a working Anakia[1] installation.
>
> I see there is a binary release available now, even if the Anakia
> homepage says otherwise[2]. I have never tried that but use a checked
> out svn tree of the ASF site myself, but let's assume it somehow gives
> you a directory of jars in ANAKIA somewhere.
>
> In Ant's top level directory there is a docs.xml build file, run Ant on
> it providing the path to ANAKIA as property site.dir (the build file
> expects the jars to be in ANAKIA/lib), i.e.
>
> ant -f docs.xml -Dsite.dir=ANAKIA

Actually the last time I generated ant's site, I just downloaded a standard
velicity 1.4 binary distrib and did:
ant -f docs.xml -Dvelocity.dir=..../velocity-1.4

Just like the inline doc says. And it worked like a charm.
I am not sure what is the best though.

Nicolas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Ivy Indexer

2009-11-17T06:18:13Z

2009/11/16 Jon Schneider <jkschneider@...>

> On Sat, Nov 14, 2009 at 9:42 AM, Xavier Hanin <xavier.hanin@...
> >wrote:
>
> > One thing I'm not sure to fully understand: it seems that you plan to
> store
> > the index on the client (say the developer's box), according to your
> > example
> > with dir="${ivy.settings.dir}/index". But it also seems like every client
> > will have the responsibility to maintain the index, is that right?
> Sound's
> > strange, there's probably something I miss?
> >
>
> As a best practice recommendation, I would suggest that the index be stored
> on the same box as the repository (of course, I think the index task and
> the
> proxying resolver should allow for the index to be stored anywhere you
> choose).

When you say "anywhere you choose", is it limited to a location on the
filesystem? Or do you intend to make use of ivy repositories access/publish
mechanism to store the index remotely? With filesystem only the usage sounds
rather limited. With ivy repository mechanism you can store your index on
the same kind of store as where you put your modules, but you will need a
more advanced syntax to configure it, and more advanced implementation.

> I do not see any reason for there to be more than one index per
> repository.
>
> This single index should be as close to representative of the real-time
> state of the repository as possible. In the case where repository
> artifacts
> are added mainly through publish/deliver/install and these tasks are routed
> through the indexing proxy, the index will always match the real-time state
> of the repository. In the case where repository artifacts are added
> manually by a repository administrator, the index will lack the types
> defined in these artifacts until the administrator runs the index task.
>
> Thus, the responsibility for maintaining the index belongs with the some
> combination of the proxying resolver and the index task, their precise
> relationship being defined by the use case.
>

So you will have to deal with index locking during updates, which may become
a contention point, and be difficult to implement if you want to allow using
any repo to store the index.

>
> All clients would then read from the same index. The Quick Search feature
> only reads the index, it does not modify it.
>
If the index grows, accessing the index from a remote box may become long.
If you think big, you will have to find a way to transfer index updates to
the clients which is optimizing the network, such as transferring diffs or
something similar. But this becomes difficult to implement, unless you want
to rely on existing technology for that (such as a SCM).

So IMO for this to be useful for most situations it needs to designed
carefully.

Xavier
--
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

AW: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T23:53:52Z

>Since I don't remember whether there is a cron job updating the site I
>usually log in to people.apache.org and run svn up in
>/www/ant.apache.org/ (make sure your umask is 002 before you do that so
>the pages remain group writable).

While I knew the first paragraphs this one is new to me, so thanks for
that ;-)

Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T20:58:20Z

I'm going to try this in the near future. :)

On Nov 16, 2009, at 10:51 PM, Stefan Bodewig wrote:

> On 2009-11-16, Matt Benson <gudnabrsam@...> wrote:
>
>> *I* still don't know how to re-generate the site. :/
>
> The hardest part used to be getting a working Anakia[1] installation.
>
> I see there is a binary release available now, even if the Anakia
> homepage says otherwise[2]. I have never tried that but use a checked
> out svn tree of the ASF site myself, but let's assume it somehow gives
> you a directory of jars in ANAKIA somewhere.
>
> In Ant's top level directory there is a docs.xml build file, run
> Ant on
> it providing the path to ANAKIA as property site.dir (the build file
> expects the jars to be in ANAKIA/lib), i.e.
>
> ant -f docs.xml -Dsite.dir=ANAKIA
>
> After that the pages in docs/ should be up-to-date and need to be
> committed.
>
> Since I don't remember whether there is a cron job updating the site I
> usually log in to people.apache.org and run svn up in
> /www/ant.apache.org/ (make sure your umask is 002 before you do
> that so
> the pages remain group writable).
>
> Stefan
>
> [1] http://velocity.apache.org/anakia/releases/anakia-1.0/
>
> [2] http://velocity.apache.org/download.cgi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T20:51:59Z

On 2009-11-16, Matt Benson <gudnabrsam@...> wrote:

> *I* still don't know how to re-generate the site. :/

The hardest part used to be getting a working Anakia[1] installation.

I see there is a binary release available now, even if the Anakia
homepage says otherwise[2]. I have never tried that but use a checked
out svn tree of the ASF site myself, but let's assume it somehow gives
you a directory of jars in ANAKIA somewhere.

In Ant's top level directory there is a docs.xml build file, run Ant on
it providing the path to ANAKIA as property site.dir (the build file
expects the jars to be in ANAKIA/lib), i.e.

ant -f docs.xml -Dsite.dir=ANAKIA

After that the pages in docs/ should be up-to-date and need to be
committed.

Since I don't remember whether there is a cron job updating the site I
usually log in to people.apache.org and run svn up in
/www/ant.apache.org/ (make sure your umask is 002 before you do that so
the pages remain group writable).

Stefan

[1] http://velocity.apache.org/anakia/releases/anakia-1.0/

[2] http://velocity.apache.org/download.cgi

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T10:51:16Z

On Mon, Nov 16, 2009 at 11:19 AM, Stefan Bodewig <bodewig@...> wrote:

> do you know how to re-generate Ant's site or do you need a hand?
>

Honestly, I don't. I could use a hand.

Jon

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T09:25:37Z

*I* still don't know how to re-generate the site. :/

And apparently I'm not receiving commit mails yet... but I'll soon
fix that. Welcome, Jon!

On Nov 16, 2009, at 11:19 AM, Stefan Bodewig wrote:

> welcome, Jon!
>
>> URL: http://svn.apache.org/viewvc?rev=880829&view=rev
>
> do you know how to re-generate Ant's site or do you need a hand?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: svn commit: r880829 - /ant/core/trunk/xdocs/contributors.xml

2009-11-16T09:19:58Z

welcome, Jon!

> URL: http://svn.apache.org/viewvc?rev=880829&view=rev

do you know how to re-generate Ant's site or do you need a hand?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...