issues with ant
On 11/11/2010 03:35 PM, Stefan Bodewig wrote: javac should do what Ant does for it in the Java5 case. If the user only specifies -target but not -source, assume the user wanted the same version as well (and vice versa). Probably would be beneficial. I can file an issue for it in the Java bug tracker. But there may be compatibility issues with making a change like that, too. I wasn't complaining about JDBC breaking backwards compatibility - I understand it has to be done from time to time. Well, they could have simply introduced Driver2 extends Driver for the new methods, and checked instanceof Driver2 before calling them. Fully compatible, simple, no need for reflection (well technically instanceof + cast are reflective, but no java.lang.reflect.*). Too late. [url=http://www.gochinashop.com/]wholesale gucci clothing[url/] [url=http://www.clothingsmall.com/]cheap burberry clothing[url/] -- View this message in context: http://ant.1045680.n5.nabble.com/issues-with-ant-tp5501076p5501076.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
Any updates on #52621 and what we want the behavior to be in 1.8.3? My suggestion still stands to restore the 1.8.2 behavior by default but add an optional parameter to implement the fix of #42046 where needed; can do the implementation if you agree. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Sorry for the Radio Silence
Hi all, unfortunately I've been travelling a bit lately and have been busy with other real life issues so the 1.8.3 release is a getting delayed. I expect to be able to breathe again by the weekend - maybe I'll then have a chance to read the Ant2 thread as well 8-) Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 2012-02-21, Jesse Glick wrote: Any updates on #52621 and what we want the behavior to be in 1.8.3? My suggestion still stands to restore the 1.8.2 behavior by default but add an optional parameter to implement the fix of #42046 where needed; Works for me. I wouldn't want us to issue a warning if the parameter isn't set, just add the attribute and update the FAQ. can do the implementation if you agree. If you can beat me to it, please do. I can manage the required merging for the 1.8.x branch before re-rolling the release. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Mandatory svnpubsub migration by Jan 2013
On 2012-02-20, Nicolas Lalevée wrote: We already did the migration of our sites to svnpubsub. We still need to migrate our dist folder. AFAIU it is quite trivial. Instead of putting files manually into people.a.o:/www/www.apache.org/dist/ant/ we would have to commit them into a svn [1]. Deleting files from our main dist is just about doing some svn rm. And the ASF archive doesn't apply the svn rm so everything committed once gets into the archive. That's my understanding as well. And if we are willing to, we have at our disposal de dev space where release to be voted upon can be staged [2]. And once the vote pass, just a svn cp dev/xxx release/xxx svn rm dev/xxx does the actually publishing (it seems there are restrictions on svn mv). I know I'd be using that rather than my user space on people.ao A thing to note though: I guess that with svnpubsub, we cannot have symlinks The -current symlinks are frownded upon by now anyway. They seem to mess up mirrors. We could easily live without them IMHO. We then just need to create an INFRA ticket asking for the transition. I guess we want the svn notifications sent to notificati...@ant.apache.org. Once the infra has created our space, we would just need to check in the current content of our dist. Currently KEYS is a (sym)link to a checked out copy from somewhere else. Once we have svnpubsub in place I'd suggest we make the dist repository the canonical place for storing PGP keys. A side effect will probably that ivy/updatesite/trunk/dist will disappeared from our svn. Maybe it would help in the management of the new Eclipse update site [3] [4]. Is this something that has to be resolved before the transition? If so, don't rush it - we still have a few months until the migration must be complete. I willing to ask for the migration this week unless there's some concern. No concerns except for the Eclipse update site that I don't understand anyway ;-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Unit testing has long been considered important for Ant. A published report a few years ago (can't find it now) showed our code coverage was among the highest of the open source projects that they reported on, as I recall. It has often happened that committers push back on code submissions asking that unit tests be included. Other types of tests are welcome too, though. Integration tests such as you suggest for plugins, functional tests across classes. My own preference in development generally is to create a regression test for each bug report before fixing it to make sure it doesn't come back to bite us. But of course all of that is up to the people who make code submissions. The overhead of maintaining a large testing suite in open source projects tends to limit them to unit tests + some other tests for expected pain points. How easy is't to unit test additional plugins. When you rely a lot on context, you need to create a similar context for testing. Is't going to be easy ? Writing and testing tasks independently will allow a lot of plugins to exist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
It sounds like you are both are on a similar wavelength. Let me see if I
understand.
A new style of build (while maintaining the old style, of course) would
be to declare some combination of resources to have similar states and
transitions between states. So something like this (just as an example
of a made-up syntax):
states
state name=no-java-src newstate=curr-src-present
detect=${no-java-src-present}
transition target=checkout-java-src /
/state
state name=out-of-date newstate=curr-src-present
detect=${java-src-present}
transition target=update-java-src /
/state
state name=curr-src-present newstate=compiled-java-src
transition target=compile-java-src /
/state
state name=curr-src-present newstate=no-java-src
transition target=remove-java-src /
/state
/states
resources
path=src/main/org/apache/tools/**/*.java /
statechange from=no-java-src to=curr-src-present /
statechange from=out-of-date to=curr-src-present /
statechange from=curr-src-present to=compiled-java-src /
statechange from=curr-src-present to=no-java-src /
/resources
and so on. The statechanges here are single steps from state to state,
but presumably the from and to statechanges could be many steps away and
Ant would find the best (for some value of best - fewest nodes, least
cost?) DAG from one to the other.
Then to run the build you identify some combination of resources and
states you want to end up in gathered together in another target or
something similar. Is that the idea?
On 2/19/2012 1:26 PM, Dominique Devienne wrote:
On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokartgscok...@gmail.com wrote:
For me, one feature for a 2,0 would be a different style of dependency
tree that would allow better parallel execution (on the same machine,
or why not on distributed machines).
Agreed. I was in fact thinking of this one as well when I wrote my
integrated build generator/manipulator.
I see the 'targets' being more declarative, becoming a state
transition saying : I need this resources in that state, I will use
this other resources (and I don't want the to change during my
execution, and I will produce this other resources in that other
state.
Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
you know the graph of actions to transition all input files/resources
and come up with the optimum way to achieve the stated goals given the
hardware resources (single cpu computer, multi-core computer, grid of
computers). That's basically Makefile territory in a way, and similar
to what Peter'soutofdate does as well. Right now Ant's targets
typically deal with macro dependencies (build all .class file before
building all .jar ones), and not micro dependencies at the file
level, so the opportunities to do stuff in parallel are lessened IMHO.
One reason Ant doesn't care much about this kind of parallelism is
that Javac is fast-enough and cannot be distributed really, and it's
the compilation of native languages like C++ that benefit most from
those, and that's not Ant's territory in fact.
The dependency tree would be an logical engine finding the shortest
path to go to the desired state, using parallel/distributed processing
when possible.
That's what I miss with existing build system : I want to go as
quickly as possible to a desired build state (from a current state).
Have you read the 4 part series about how Google does its builds?
Below's a link to part#4. --DD
http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
